Menu
To make websites accessible, my policy so far has been to follow the WCAG--no more, no less. I assumed the WCAG was thorough and complete. Thus I assumed that if I followed every one of its recommendations, my sites would be irreproachable from an accessibility standpoint. Having spoken to a number of web users with disabilities, I've wondered if I should reconsider this policy.
These real users have told me that the following techniques are absolutely essential for any website, based on their experience:
aria-live="polite".Not every user cited every one of these techniques. This is just the union of the sets of suggestions made by all users. There have been other surprising suggestions as well; these are just the ones I remember.
What's notable about all of these suggestions is that, as far as I can tell, they're not WCAG recommendations. What do you make of this dissonance?
One the one hand, I have no reason to doubt that these techniques are important for the users with whom I spoke. They have no reason to be untruthful, or to exaggerate their needs. They seem to have a solid understanding of the assistive technologies they use, so I don't think they're merely miscommunicating, either.
On the other hand, if some people need these techniques, why aren't they in the WCAG? Is the WCAG incomplete? Or are these demands so idiosyncratic, so unique to these particular users, that it would be unwise to include them in the WCAG and implement them on every site?
Can the WCAG be relied upon as a correct and complete checklist for web accessibility? If so, do you have any thoughts on how that could be reconciled with the users' comments, and what might be an appropriate response when they request such techniques?
Edit based on conversation with Dryden Long
I should clarify that I don't expect the WCAG to be absolutely complete and to offer a solution for each and every last disabled user. Rather, I'm getting at whether a web developer can reasonably rely on the WCAG to make a site that's as accessible as practically possible. And, whether one needs to look outside the WCAG to achieve that goal.
396
WCAG 2.0 are great. They are the result of the work of approx. 200 people working on them during several years, including most of the best experts in web accessibility, representatives from people with disabilities, etc. They have long been discussed to reach a consensus that reflects the views from the different stakeholders (so that, say, accessible content can be created in an effective fashion, without sacrificing aesthetics, without putting a large burden on browsers, etc.) They synthesize many years of research and overcome many of the limitations of the older WCAG 1.0. They have also got the input from the community beyond W3C, receiving hundreds (and even thousands) of public comments every year through the public comments mailing list.
That said, WCAG 2.0 themselves recognize they are not perfect:
Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive, language, and learning areas. Authors are encouraged to [...] seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community.
From my perspective, maybe people with cognitive, language and learning disabilities have not been able to lobby and be represented at the relevant forums. Also, current research is proceeding to reach conclusive results regarding e.g. dyslexia.
As a result of that work in WCAG 2.0, a few dozens of success criteria were written, which establish the testable requirements an accessible content must abide by ("accessible" is here to be understood as "conforming to WCAG 2.0"). These sucess criteria are the core, normative content of WCAG 2.0, do not depend on the technology evolution, and thus are quite stable along time.
Then, there are several hundreds of techniques to implement these sucess criteria. Techniques are technology-dependent. They depend on the specific content type (e.g. you use different techniques to provide an alternate text in an HTML page and in a PDF document), but also on the evolution of browsers and assistive technologies, and, what not, on the evolution of web design itself.
That means several things:
Techniques aren't normative but informative. A WCAG Note on Understanding WCAG 2.0 explains that (boldface not in the original)
Note that all techniques are informative. The "sufficient techniques" are considered sufficient by the WCAG Working Group to meet the success criteria. However, it is not necessary to use these particular techniques. If techniques are used other than those listed by the Working Group, then some other method for establishing the technique's ability to meet the Success Criteria would be needed.
Besides, each and every technique includes a footer stating that
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
It makes sense that techniques are not normative, given that there are (maybe) other ways to reach conformance with success criteria. Imagine that, e.g. user agents (browsers and assistive technologies) start supporting picture descriptions embedded in picture files using IPTC IIM (International Press Telecommunications Council Information Interchange Model). They could perfectly become an acceptable way to satisfy Success Criterion 1.1.1 but would not be reflected (at least for now) in any technique.
Having a standardized recommendation to check and resort to is great, as it distills the knowledge of the industry on a single place, and provides a common aggreement on what is deemed to be considered "accessible" (hey, that what standards are for). However, Involving Users in Evaluating Web Accessibility is key to ensure universal accessibility. That makes sense: as other answers stated, different people with a broad range of abilities may have different needs which are only reflected in practice. I would add that different websites have different requirements which are not captured by a single, multi-purpose document. That said, you would not normally evaluate your site with people with disabilities if you are creating, for instance, the web page for your neighbourhood soccer team, but you would (ideally) do, for sure, if you are developing the website of a Premier League team.
All this does not make much difference with usual web development practices for usability: even though your client hands in a request-for-quotation document with the requirements and specification of the website, you would hold an interview with them, and have some usability testing done, conduct focus groups, etc. But you would neither do that for your neighbourhood team.
People with disabilities are used to dealing with inaccessible sites. The techier they are, the more used they are to resorting to "tricks" so as to gain access to otherwise inaccessible contents: "Yeah, you need to alt-space and then down and the menu will pop-out", "if you activate that hidden option in JAWS and activate virtual cursor it will read the fields in that page". Less tech-savvy users maybe do not know that sort of tricks, but they learn some tricks by heart on the sites they use most: "I need to type 'k' twice to select King's Station".
Research has found that results of evaluations by people with disabilities consistently exceed those of conformance testing. That is, users overcome some accessibility barriers by resorting to these "tricks". However, that should not divert the focus of conformance. Many people will not be knowleadgeable of those tricks, and even those who are will encounter poorer usability, will take more time to complete their tasks, and would be more prone to leave (or choose a competitor's site next time).
On the other hand, some techniques rely on the support of assistive technologies, whose use may require the user's expertise. For instance, technique C22 deals with using CSS to control visual presentation of text. The idea is quite simple (boldface added):
The objective of this technique is to demonstrate how CSS can be used to control the visual presentation of text. This will allow users to modify, via the user agent, the visual characteristics of the text to meet their requirement. The text characteristics include aspects such as size, color, font family and relative placement.
However, how can users modify via the user agent the visual characteristics of the text? This is a setting generally available, through different ways on different platforms. Some users may not be familiar enough with that, and find more convenient having an in-page button to switch to large-print, high-contrast text. Or some users prefer having that option readily available within the page.
All of the above present explanations of why WCAG 2.0 may not be sufficient. However, many of the cases you present are indeed considered by current WCAG 2.0 techniques
High-contrast CSS border around all buttons, background contrast not being enough, is the only thing that puzzles me and could deserve further investigation.
After that long-but-needed explanation, my summary advice is:
Test as you would do with any other usability test. That is, do not focus on the users reporting whether CSS background colors should not be specified, but check whether they can easily perform the tasks they are deemed to do on your website, or if they get stuck at some point. Same as you do not ask whether psychometric properties of a specific color are deemed to be atractive, but do test whether red buttons achieve a higher conversion rate in A/B tests.
Can the WCAG be relied upon as a correct and complete checklist for web accessibility? Clearly it is not the ultimate, theorem-provable, way to ensure everyone can access your website on equal footing. This is a matter of human-computer interaction, and as such it cannot be wholly captured by a limited set of guidelines. However, it is a reliable source that clearly covers most of the real-world use scenarios, and great advantage can be taken of it, if used as it is intended.
132
To the best of my knowledge, complying with WCAG 2 is considered sufficient for accessibility for legal purposes in most countries. But as you note, it can never cover every unique combination and circumstance of disability.
If you are following WCAG2 correctly, site visitors will be able to use assistive technology and tools to customise their experience. For example, using relative units like ems and percentages for font-sizes means that IE users can rely on the browser's text-resize tool to make the text the exact size they like (since IE hates pixel-sizes); making sure you don't put valuable information in background images or text in images means that the content is preserved if the visitor uses Window's high-contrast mode or makes their own user-stylesheet to get nice big highlights on focus. I do think the WCAG guideline for 'visible focus' is a bit soft - the default dotted outline is considered sufficient, but often gets lost on complex or colourful designs. I usually use the same effect for both :hover and :focus as I find it gives a more distinct result when tabbing through a page.
A lot of WCAG2 is actually about removing anything that would prevent customisation. On European sites I've seen the term 'barrier-free' used as a translation of 'accessibility', which I think is a good way to think about it. The content should be able to be poked and prodded to the user's liking without any loss of meaning.
Having some disabled customers/clients participate in your user-testing is a good idea for catching things that are not covered by WCAG2 but might still affect your specific target audience. For example, if you're making a site targeted at senior citizens you might want to check the size of buttons and links, since mobility can be restricted by age-related issues like arthritis.
As a developer, it's your responsibility to make sure all the content is exposed to the browser's accessibility engine; from there it gets exposed to either the user, the operating system, or assistive technology. You can't fix every problem for every user, but you can make sure your site is open and flexible.
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
