WCAG vs real users' opinions - html

Question

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:
JavaScript-based style switcher interface. E.g. to switch between black-on-white and white-on-black color schemes.
Alternate stylesheets. Same purpose as JS switcher, but a different implementation.
High-contrast CSS border around all buttons. (High-contrast background color not sufficient.)
Don't let the DOM update without user intervention (e.g. due to remote event), even with aria-live="polite".
No CSS background colors anywhere. (Seriously.)
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.

Answer 1

1. 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.

Answer 2

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.