Design for accessibility is not limited to end users and physical differences.
Things like UI design and UX are not just for users. Writing reusable, and documented code helps the next developer and your future self for easier accessibility.
Some things you just do, because that's the way to do it. You drive on the right side of the road (which may be the left side in some countries) even if you are alone on the road. You get out of bed even in the weekend and you have no other plans.
In programming, you do a few things even if you don't "have to". Like in a Linux style CLI application, you handle the -v command line option even if you know which version you have installed, and --help listing all the command words (or whatever). Any "proper" Linux CLI application has these elements.
I can imagine a discipline of programming where it would be equally self-evident that you prepare for users with disabilities, even if you don't know of any specific case right now. Even for internal tools, you might next week have a new colleague who can't make use of all the internal tools, because they miss the universal access adaptations.
No Linux programmer writes from scratch a command processor for handling -v and --help; there are libraries for that. There are libraries for creating Windows Help pages as well. To make universal access universal, we would need tools at a similar level for creating UA user interfaces. Then we could teach and enforce a discipline where UA adaptations is as obvious as a command processor for parsing the --help option.
I am sure that many examples of such libraries & tools exist, but they are not being universally promoted. They are not being taught as a basic element of UI design and development. If they were, "We see no need for UA" would be like saying "We see no need for processing the backspace key".
I think that it is reasonable to say that a programmer who is writing an application with a user interface, that is to be used by anyone other than him/herself, should establish a habit of considering whether (s)he should make provision for accessibility by individuals with disabilities. However, if the application, by virtue of its known 'context' will not, in fact, be used by such individuals, the considerable extra time and effort that would be needed to build in such provision cannot be justified on any rational grounds. I disagree, also, that provision for disabilities is something that can be included as simply as adding a library and some text to handle -v or --help. To do it properly requires that the relevant issues be considered throughout the design and coding process.
Far too many times have I seen developers claim that they design for accessibility, but without having a clue about how to do it. More or less of the kind: "If this text is too small to read, press this button to enlarge it", in dozen varieties.
Lots of developers have read checklists of how to design for this and that disability. When they sit down at their keyboards, they (vaguely) remember twelve of the twentyfour rules, implement the six that cost next to zero, and proclaim "We have made a serious effort".
The checklist should have had a second column, next to the "Do you design for...", to check "...and we regularly (e.g. for every major release) use people that actually have these disabilities as testers, to verify that the software actually works fine for them". If the developers were truly honest, that would reduce the percentage of those really designing for disabilities to a fraction.
There is a middle-between: You can do some testing yourself, simulating vision problems by smearing vaseline on your glasses, or covering the screen with a big board that has only a small hole that you can move sideways or up and down (tunnel vision), or turn off the screen (total darkness). You can get hold of a braille line - verifying that it shows the right text makes you feel like a first grader leaning his first letter! You can turn down the color saturation to grayscale as a (poor) simulation of color blindness. Use heavy gloves, or mittens, for keyboard input. Turn off the sound, or select e.g. sewage pipe acoustics on your sound card. ...
But few developers do even such testing. The better of them keep the list of twentyfour points to remember handy, and may actually use them as a checklist before release. Yet, for the great majority, it is plain theoretical work, never tested in practice. Compare it to making a major release of source code that has never been passed through a compiler before the release date.
Developers of software specifically aimed at a disabled group are of course different - they have testes with the disabilities in question. I am talking about developers who make software for the general market, with disabled users only as a small fragment of the user group.
We use QA testers that use tools such as: WAVE and Siteimprove Accessibility Checker, etc. and we work off of test cases.
We also have been doing this a while now, and have a feel for what really works and doesn't work, based on feedback from users with visual impairments.
WAVE and Siteimprove are software tools that are based on official standards. They hook into the Chrome browser nicely, but WAVE I believe has a standalone package too. See: WAVE Web Accessibility Tool[^]
I wasn't aware of this tool - thanks a lot for the link.
It certainly looks as if you are doing things properly. So don't take my general critical comments to the way developers handle accessibility as aimed at you. Quite to the contrary: They could learn something from you!
We do the red/green colour change thing but only with additional text cues for those who have difficulty with red/green - sometimes it is a different shaped icon altogether such as a red X vs a green tick/check mark.
- I would love to change the world, but they won’t give me the source code.
Last Visit: 19-Jan-20 23:18 Last Update: 19-Jan-20 23:18