Accessibility for individuals with disabilities

[ethindp]

Introduction

Though getting a GUI toolkit off the ground is fun, more often than not the issue of accessibility to individuals is overlooked. This is usually not a deliberate design decision (though organizations like Telegram have made it pretty clear they have absolutely zero interest in actually working on this in their desktop app at least); usually, this is purely a problem of "we didn't think about it". This viewpoint is understandable; a sited individual, for example, does not need to think or worry about vision loss for a (hopefully) very, very long time, and so it is understandable that this would not be a major consideration. However, there are indeed individuals that do not have vision, and it is in the best interest of designers of UI toolkits that this not be discarded.

To be fair, this is not just the fault of individuals without disabilities; individuals with disabilities have advocate groups like the American Council of the Blind (ACB) but have yet to clearly document procedures for making user interfaces, devices, etc. accessible. Though organizations like the ACB have held conferences and events and have advertised in newspapers, they have done so in such a way that the average reader either never actually hears about them or reads them, or (in the context of advertisements/editorials/etc.) words them in such a way that the average reader automatically discards them as uninteresting or not useful. There are standards for making accessible user interfaces for environments like web browsers, such as ARIA or WCAG, and for other interfaces (or at least parts of them) like ISO/IEC 24786:2009 (which covers accessibility settings screens), but these standards aren't well advertised or well-known, leading to this issue.

Various individuals with disabilities, however, including myself, have come together to begin rectifying this problem, with the full understanding that fixing this issue may take longer than our lifetimes. With that said, however, it is worth beginning it now instead of requiring the next generation to pick up the peaces. As such, I am initiating this discussion to get the ball rolling for SixtyFPS. (As an aside, I really love the concept, and if all the necessary core elements are there I'll definitely be tinkering around with it, because it looks like one of the best UI frameworks I've found to date for Rust.) I won't go into extreme detail about how accessibility is implemented -- this post is getting fairly long already -- but I'll briefly touch on the different ways this can be accomplished, and we can figure out what to tackle first.

Accessibility overview

There are generally two ways accessibility of a user interface can be implemented, as pertaining to blind users (the others like high contrast are by far much simpler and can easily and trivially be done):

• Event-driven: the user interface contains events like focus events, text change events, etc., that are reacted to, and information is conveyed this way through either a screen reader API, text-to-speech technology, or via self-voicing (that is, recorded audio is used to narrate the UI). This is by far the simplest but has some major drawbacks as well.
• Accessibility toolkit integration: the framework integrates and complies with an accessibility toolkit like UI Automation (UIA), IAccessible2 (IA2) and the Gnome Accessibility Toolkit (ATK). Screen readers or accessibility testing applications (called accessibility clients) can then interact with the user interface using the relevant accessibility APIs that they support, and a consistent user experience is created as a result. This is the best option, and is consistent across all applications that implement and comply with it, but the major drawback to it is that this is also the most time-consuming.

I'm not sure which method you guys will end up choosing, but I would love to see SixtyFPS be yet another accessible GUI framework in Rust. I know this post was a bit formal but I thought I'd get the ball rolling at least.

[Be-ing]

This has briefly been discussed before: #32.

I think collaborating on AccessKit could be a good idea.