https://stackoverflow.com/questions/21415785
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian1. WCAG 2.0 Drawbacks
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.
2. Success criteria vs techniques
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 are a living document, they have been updated more or less once every year and a half since WCAG 2.0 were approved. Hint: you may use the Techniques for WCAG 2.0 Submission form to provide your input if you think a useful technique is not currently considered.
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.
3. Conformance vs accessibility-in-use
Testing with users
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.
Barriers and tricks in practice
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.
4. Techniques that support your user requirements
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
- JavaScript-based style switcher interface, and alternate stylesheets (served by the server) are both considered by technique C29 on Using a style switcher to provide a conforming alternate version, and also supported by technique G174 on Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast
- No CSS background colors anywhere is related to technique G148 on not specifying background color, not specifying text color, and not using technology features that change those defaults. I would not personally consider CSS background colors should be avoided. Sometimes, the problem is that you have only set background, but not foreground colors. Make sure that you both specify foreground and background, or none of them, to avoid mingling your style with user's.
- Don't let the DOM update without user intervention (even with ARIA polite) is related to techniques G75 on providing a mechanism to postpone any updating of content and G76 on Providing a mechanism to request an update of the content instead of updating automatically
High-contrast CSS border around all buttons, background contrast not being enough, is the only thing that puzzles me and could deserve further investigation.
Take-home message
After that long-but-needed explanation, my summary advice is:
- Get most familiar with WCAG 2.0 success criteria and understand why they are necessary. Get familiar with how people with disabilities use the web (I note you have already done that).
- Apply WCAG 2.0 techniques judiciously. You'll mostly be on the safe side if you stick to WCAG 2.0 techniques. However, always take into account the sucess criteria they respond to, and ask yourself if they are the best way to meet them. Choose the techniques that suit best to the specific website, audience, and your experience.
- Involve users with different abilities in web site development, testing and maintenance (I also note you are already doing that). You will probably have already tackled most potential accessibility barriers, but user evaluation will probably stick out a few more. After all, if you get user feedback detecting a problem, correct it.
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.
