An article by Anne Gibson on A List Apart has caused some discussion lately. The starting point for her article is an established definition by W3C, in which web accessibility is described as the use of the Web by people with disabilities. The author would like to take the emphasis off disability and put it on technology.
Note: This post was originally published in German on February 9, 2015, as Die zu kurze Messlatte.
Web site owners often have a clearly defined target audience in mind. Defining target groups facilitates the choice of marketing instruments and forms of expression. One thing a target group does not determine is the users of a website. Actual users of web sites are hard to detect, and nobody can be sure whether the person purchasing a online product is a youth or her grandparents. It is the same with disability: It is a priori not clear whether a user or a customer is dependent on certain aspects of web accessibility due to a disability or not.
It’s not about a specific disability. Accessibility affects all aspects of web design. A website that is more or less accessible, will be beneficial to all users, and – probably more important – create no disadvantage to anybody.
The technical analysis is not enough
The article by Anne Gibson mention above describes approaches to achieve an accessible web design without having to deal with the issue of „disability“. Existing input and output devices are pointed out and a routine is explained how they can be included in quality assurance. The article describes further measures to assure web accessibility, all of which are sensible and uncontroversial. The author is explicitly familiar with the subject and is aware of the communications problems when a web site must be accessible and usable for people with disabilities.
In the ALA article, information about different ways that people with disabilities use the technology is presented superficially. Accessibility requirements are translated into technical criteria and the user (with a disability) is referred to more or less incidentally. In my view, such a cutback of accessibility to a technical consideration is inadequate for the following reasons:
- If a particular input or output device is named, it must also be handled the way it is handled by (disabled) users. What does it do for anyone knowing about the existence of a screenreader as an output device without being familiar with it’s abundant keyboard shortcuts? Of what avail is it knowing about a head mouse when the precise settings for it’s operation are not known? In this respect, web developers must deal with the tools and modes of working of disabled users when they want to develop accessible web pages and applications.
- Of course, web developers can rely on widely accepted documentation and compatibility charts to produce accessible code, but whether Web content is accessible or not, depends on many other factors. The killer argument against this approach is that accessibility would then be bound to the use of assistive technology. Accessible web design does mean technical accessibility through assistive technology, but enabling people to use the web pages is the more challenging part. In addition, content-related aspects come into play, ranging from choosing meaningful alternative text for images to the use of sign language. Not by any stretch of the imagination could the diversity of topics and scenarios be covered by a checklist without having dealt extensively with disabilities.
- Finally, technological progress is a problem. When W3C releases new technologies as a web standard, they must be accessibility supported, but only two instances for each feature are required to consider the feature accessibility supported and thus accessible. For example, the accessible design of advanced components is only possible using WAI-ARIA; and yet when running different browser-screen reader combinations some attributes will work well and others not at all, while some components can only be made accessible for certain browser-screen reader combinations. Furthermore this policy requires that users must typically work with current software to use modern web technologies.
I believe that it is shortsighted to blind out the term „disability“ and that that will not change the willingness and ability of web developers to attain accessible web pages. The reasons why accessibility remains an ongoing issue is to be found in the attitude of web development and society. If, in everyday life, someone has no contacts with people with disabilities and the resulting disadvantages they experience, they will generally not use accessibility as a benchmark for their own work.
The exclusion of disability in daily life certainly has to do with our own fears, perhaps because one can not imagine anything worse than being blind or being bound to a a wheelchair. However, it also has to do with general prejudgments and ignorance, that people with disabilities supposedly cannot use a computer. Actually, the opposite is true: Computers are not only used by disabled people as work equipment, but also as assistive technologies. Assistive technologies require that reasonable code is produced, although that is not true in all situations.
To that extent, web developers can’t help it that they forget or exclude accessibility – so that’s the way it goes in many other areas of life, be it in architecture, education, or tourism. But fading down „disability“ when it comes to accessibility, will only increase this form of discrimination.
Accessibility is closely linked to disability. As long as the vast majority of websites do not even meet the minimum requirements of accessibility, it can hardly be expected that web developers will improve accessibility when the word „disability“ is ignored. on the contrary: Web developers need to work a lot closer with users, including disabled users, so that all users get a better user experience on the Web. It is important to recognize the disadvantage caused by a disability and to draw the consequences for one’s own work.
Accessibility as part of UX
Usually, knowing about the meaning of certain measures clears the way for taking action accordingly. After all, other „features“ on a web page may be implemented, even if the price is astronomical and the benefits are not worth mentioning. It’s a matter of priorities, whether users and thus accessibility are at the heart of web development.
Once confronted with accessible web design, some unsubstantiated counter-arguments may pop up from the management such as „We know our users‘. A representative survey among users would probably show that a significant proportion of users is color blind or confronted with other difficulties. Even a broken arm can temporarily lead to a situation where certain criteria of accessibility become important. Other aspects play a role, such as the reading glasses which were forgotten on the bedside table or the wireless mouse with empty batteries.
Even if all users are known personally, as may happen in a small intranet, many individual restrictions related to computer use won’t be generally known. Sometimes usability problems arise in the course of time. An – admittedly a bit older – study published by Microsoft assumes that about 57% of all adult users benefit from accessibility.
In reality, accessibility is as much a part of UX as technology, creativity and usability. I would even argue that accessibility has a decisive influence on UX, and only when a web site or application is accessible, can it have a positive experience for the majority of users. Wherever the importance of accessibility is exactly located a good software must match many parameters for a positive user experience, and an accessible Web design is undoubtedly one of them.
A defensive posture is not required. Anyone only in the slightest interested in usability is already concerned with accessibility. Accessibility is usability in context of disability.
4 Gedanken zu “Are we coming too short? – Accessibility is usability in context of disability”
This may be a translation issue, but my point is the opposite: accessibility should be so „baked in“ to every process that you shouldn’t be able to avoid it, extract it, or remove it.
If you’re a developer and someone says „cut the accessibility features“ you should be able to say „that’s not possible. They’re not separate features.“
If you’re a designer and someone says „skip the accessibility testing“, you should be able to say, „That’s not possible. It’s part of our testing suite.“
If you’re a UX designer and someone says „We’re not designing for accessibility, skip it,“ you should *already* be able to say „That’s not possible, they’re built into your audience.“
To accomplish this state where accessibility is as much a part of the process as every other standard, we have put a ton of attention on failing processes, training everyone to recognize accessibility issues, using hardware and software, user interviews, usability testing, etc. To make it so we can stop talking about accessibility with our clients we have to constantly talk about improving it within our shops. And we can’t do that effectively as long as we’re allowing ourselves to think about people who need accessibility as „them“.
So I agree with what you’re saying about development and testing but not why you’re saying it. As long as we in IT treat accessibility as an add on for an out-group, we can’t get there.
I understood your intention in your article and I sincerly think it is good work. Perhaps you are lucky enough to work in an environment where that works well.
The quality of web sites in terms of accessibility is generally not that good. My experience is that companies producing web sites and applications are not prepared to take time or money to get accessibility testing integrated, and without experts defining test criteria the results are also not too good anyway. Perhaps the unsatisfactory situation is unique to Germany, but I don’t think so. Perhaps we are also talking about different products/companies/types of web pages.
I know there are lots of people working on the web who do an excellent job, also on accessibility. But they are still a minority. Also, a lot of code labelled „accessible“ is in fact not accessible. Unfortunately, it spreads anyway, seemingly untested.
I am sure it is a matter of perspective. As a screenreader user I personally have the impression, that currently accessibility is moving backwards and not forwards. One reason among many others is ignorance – I still get mails of the liking „How do you read web pages.“ That is why I think test criteria alone won’t help that much.
Thank you for this translation. I agree with this critique of the ALA article. I also believe that making people fully aware of the hug pay offs of designing accessible sites – pointing out the electronic curb cuts of accessible sites can also help in erasing the misconceptions that many poepl currently have about web accessibility. Accessible site = better code = more maintainable code = faster code = better UX = better return on investment.