|
Hard question, because the field so diverse. In a sense, accessibility is much more then just trying to make computers useable for the blind. At a fundamental level, it is about making software flexible enough to be used in different modalities. People with very little motor capabilities are quite capable of looking at a screen, but they need help moving the mouse and perhaps a good predictive onscreen keyboard to be able to type. Blind people on the other hand are mostly quite content with a standard keyboard, but they need a totally different way of output, like tactile braille or synthesized speech. For the output part, it boils down to having an API which makes a third party app (like a screen reader) able to traverse the logical structure of what the application is presenting on-screen. That is mostly a sort of tree which reflects which widget contains what, and the different types of content. Such an API, however, is not only required for screen readers, but also very useful for things like automated testing, for instance. So a web automation or testing framework could actually be written on top of the accessibility APIs, and sometimes actually is. I am rumbling about this to get you in the right mindset. Its so hard to not see the forest because of all the trees around... That said, if we're talking about web accessibility, the obvious recommendation is the WAI WCAG. Maybe not the best reference for learning on how to implement things, but its a good start. Depending on the platform you're at home with, there are screen readers (NVDA, Orca, BRLTTY) which are open source and can be studied. On the user side, and on the "how is this implemented" side. Installing NVDA on Windows and turning the monitor off is a good way to get your feet wet. It might feel strange at first, but you will notice that things can actually get done this way. Its also a good way to test a website if you have no specific accessibility knowhow yet. Just try to navigate and read its contents. |
Is it weird that I, as someone with normal sight, had never thought of that as a simple way of testing whether your software (and the whole operating system together with it) works correctly with screen readers? It's like there's some sort of unconscious bias which links typing on a computer with its monitor being turned on.
And I lived through the times when most computers didn't come with any pointing device, which led to most software back then being accessible to keyboard-only users (notable exceptions being things like Paintbrush, which required a mouse), so I understand the link between the lack of a device and software being designed to work well without that device.