Hi. First, an introduction.
As part of my job, in the recent months, I had to assist a blind person in getting a braille display to work with modern desktop environments. He was perfectly happy to use mutt and vim to exchange mails and edit files and to use lynx to browse the web. Unfortunately, new administrative requirements demand procedures that only work within a javascript-enabled graphical web browser. Let me tell you, the support for blind people in GNOME is absolute crap: the focus gets lost, the braille display gets desynchronized. Even when it works, navigating between widgets with only the feedback of the braille display is a nightmare. This person is a brilliant mathematician. Had he been on the other side of the corridor, he would have been a brilliant computer scientist and a member of a team who uses FFmpeg in its workflow. The switch to Forgejo as is would have slammed the door at his potential contributions. A few days ago, a friend, who has very poor eyesight without being blind, was telling me that at the zoom level he needs to be able to read the text, most web applications become unusable. Their layout do not scale properly or the widgets take all the place and leave none for the contents. This is a consequence of poor design of the browser APIs with regard to zoomability and poor usage of these APIs by web developers who are thinking about disability only in an abstract matter. These issues are not anecdotal. Sight disabilities are very common. They come for almost everybody with old age. Note that both can be true at the same time: web interfaces can be a progress in visual accessibility over paper procedures, because of zoom and screen readers, and at the same time web interfaces can be a regress in visual accessibility over older tools used by early adopters, that are not encumbered by the flashiness of recent interfaces and have maturated in accessibility over years. The problems with accessibility are not only visual, they are also about the use of the mouse. There are multiple physical and motor disabilities that affect the use of the mouse more than the use of the keyboard, from arthritis to Parkinson's. I know somebody who got a permanent shoulder tendinitis from using the mouse over students' back: she can use a keyboard fine, but using a mouse, even the normal way, is painful. Touchpads or trackballs can help in some cases, they can be worse in other cases. Navigating in a graphical interface without the mouse, mostly with the tab key, can be extremely laborious and frustrating. It is even more so in web applications because the two layers of GUI interfere with each other, and caret browsing can only mitigate it a little. On some web applications, not using the mouse can even just be impossible when developers whip out their own widgets from elements the browser doesn't consider active and on which they just connect onmouse events. These accessibility problems exist in all web-based applications. They exist even more when the web application is young or lesser known, like Forgejo, because mature and famous applications will get pressure to fix them as much as possible. And these accessibility problems map directly to efficiency problems: it can be true at the same time that a web-based patch review system is a progress for people who only know the mail editor of GMail or Thunderbird and a regress for people who have the habit to reply to mail in the very same editor we use for development — Vim or Emacs typically. This is why it is extremely important that all the features of a web-based service be available also as low-level interfaces that can be plugged into more accessible tools. And it needs to be real. Lots of projects have this kind of things as APIs, but so little used that when people try to use them they realize that (1) it takes reimplementing a non-negligible part of the web-app just to reach the ability to use a basic feature and/or (2) the API they need does not work because of limitations or bugs, sometimes reported to the tracker years ago and not fixed. That leads me to the second part of this mail: practical questions about using Forgejo purely in command-line. It is something that was promised by people in favor of using this tool: that everything we could do in command-line, we would still be able to do in command-line, and that they would document how to do it. Time has passed, and that promise has still not been kept. So, proponents of Forgejo, please answer these questions: 1. How do we get a notification for every comment made on any pull request or issue, including threading information about who answers to whom? 2. How do we get notifications for actions done on the project, especially approving or closing a pull request? 3. How do we reply to one of the comments? 4. How do we close a pull request? 5. How do we approve a pull request to have it merged? Regards, -- Nicolas George _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
