What Follows WCAG 2.0

Interesting ideas. I wonder if one reason some organizations do not promote their site's accessibility is that they fear it may be perceived as a challenge; that users will find fault with this or that page and consume staff bandwidth with their complaints. Best to be accessible, but not boast about it.

Hi Duff,

Let me try to tackle your brainteaser questions.

• Does the HTML example in the brain teaser conform to WCAG 2.0 guidelines Level A, AA or AAA, or does it fail Level A in at least one way?
  Answer: The 'faux' h2 heading (h3 wit htext size increased via CSS) fails WCAG failure F2, independent of whether heading levels have been used correctly.
• How do the WCAG 2.0 guidelines help you figure this out? Example: for SC 1.3.1 there's Technique H42, Example 2. Does this Technique mean that the brain teaser conforms to WCAG 2.0?
  Answer: It's pretty clear that the headings have not been used consistently to refelct the hierarchical structure of content. The example in H42 shows a properly strucutured example.
• Are either, neither or both of Success Criteria 1.3.1 and/or 2.4.3 (both Level A) violated in this example?
  Answer: SC 2.4.3 relates to meaningful focus order of content. The example has no focusable elements so SC 2.4.3 does not apply.
• Is SC 2.4.6 invoked? Does the brain teaser conform to this Success Criterion?
  Answer: 2.4.6 requires descriptive labels and headings. Since this is a mock-up of content it is difficultto judge, and there's certainly a scale from good to bad decriptiveness that makes it tricky to decide if a SC is met or not (pass or fail), That's down to the nature of content which is more varied than a binary conformance concept.
• Can this brain teaser actually conform to SC 1.3.1 and SC 2.4.3 without also conforming to SC 2.4.10 (Level AAA) and probably, SC 2.4.6 as well. What does that mean?
  Answer: SC 2.4.10 would look if distinct sections are identified, for example by a sub heading. How far 1.3.1 will go is a grey area how deep into the content headings must reach. Given differences in content this would be very hard to prescribe in a form valid for all cases. For a short and simple page, one h1 for content would do the trick. If there is clearly a hierarchy of content with visible subheadings 1.3.1 requires that these are implemented with strucutural mark-up. That's it, really.
• Does the in-line font-size change get the author off the hook because you'd claim they made the H3 into an H2 and thus "conveyed through presentation"?
  Answer: No because headings hierarchy is not (just) for presentation, users of assistive technology (e.g. screen reader users) should also be able to work out a meaningful hierarchy.
• What's the simplest, easiest and profoundly the only right way to make this lame excuse for content tolerably accessible (assuming you agree that it's wrong as-is). HINT: Just add a single word, no other changes required.
  Answer: No idea what you are getting at here...
• Is the interpretation problem (if you agree there's a problem) due to lack of Techniques, or collisions between the Success Criteria themselves? Or maybe you are just rolling your eyes.
  Answer: An example such as the one given has many aspects pertaining to accessibility. These aspects are captured by the WCAG Success Criteria. Naturally, they interact, and this is inevitable. A headings hierarchy with non-descriptive headings helps no one. Good descriptive headings with a misleading semantic hierarchy is also bad. There may be different ways of slicing the cake but we should recognize that the issues with real-life content *are* quite complex (beyond giving a few rough and ready recommendations, which do no harm, of course).  But a thorough assessment of all issues pertaining to accessibility isn't easy, unfortunately - especilally as dynamic content makes testing ever more difficult.

Disclaimer: I am a member of the WCAG Working Group. You may follow me on Twitter under @wcagtest

Far from being an accessibility expert, dealing intensively with the  domain of accessibility now for a year or two, depending on how you count it, I have run into a number of issues that I think are the main show stoppers if we are into a wider adoption of WCAG or any such guidelines.

1. One aspect only comes into play indirectly, but I honestly believe the accessibility community is elitist. You are only allowed in, if you master very arcane knowledge. This elitist attitude has been one important driving factor why WCAG has become what it is. 
2. The goal of WCAG must have not been clear throughout its development – it seems to be more about correctness or righteousness than about practically achievable usefulness. WCAG fails to maximize effect (majority of content becomes reasonably accessible) and rather maximizes compliance (only 100% compliance acceptable)
3. WCAG itself is inaccessible for regular people on the intellectual level (which has been described already nicely in the previous comment).
4. A lot of potential users of WCAG would have to be non-experts - a vast amount of content nowadays by users who are no experts in text composition, accessibility or even information technology at large.
5. Even where users have some degree of expertise it is a major burden for them – in terms both of time to be invested as well as intellectual challenge how to go about it – to really make accessible the piece of content at hand. Duff's example is a very nice one - how do you resolve an inconsistency in the use of heading levels? It's simple - you don't unless someone is pointing a gun at you, so to speak. Also, I think there should be tools to support fixing this in the blink of an eye: push a button, make a simple choice, and some piece of software fixes it for you
6. AT tools that would be used by disabled people are far from living up to the potential fully conforming content would provide. Working for a software development company myself I can see how AT developers find it difficult to make sense out of WCAG 2, so I am not really surprised.
7. As it can become technically so challenging to rework existing content to make it accessible a number of experts recommend various steps that will make content appear dull and aseptic to many (non-disabled) users. You can't leave out the salt from the soup even if a substantial amount of the target group should avoid salt - rather, you'll have to be creative and find other ways.
8. And last but one biggest to me: a lot regular content as well is not fully accessible to regular users, and hey - we all can handle it. Just as an example - I have seen so many more or less confusing tables that I stopped counting a long time ago. There are some many ill-designed web pages and publications out there that a regular user can't fully access. It is naïve to believe we could fix this. Rather, we should find an approach that makes wise use of resource, for example to make such content at least as accessible as it is to non-disabled users. That's not perfect but it would be excessively useful if you measure the increase of overall accessibility.

My summary: WCAG itself so far is a third of the problem it tries to solve. Any next version of WCAG needs to pay tribute to reality in a drastically better way than today. So is WCAG wrong? No – it is great. As in: a great first step. Before WCAG  there «darkness was over the surface of the deep», now we are seeing light here and there. We need to cultivate further was WCAG 1 and WCAG 2 have started, so it's all turning into a garden full of sun (not an Intensive Care Unit brightly lit by artificial light). 

Olaf Drümmer

PS: Just as an illustration why regular users play an important role in content creation nowadays... there are couple of issues in this commenting form that practically can not be overcome:

• no option to use headings
• no visual feedback whether I was entering a minus sign or a dash (unless I use the em dash, which is wider than what we use where I live)
• no easy way to enter opening and closing quotation marks rather than inch/seconds or minute signs (this is not specific to this commenting form but to text editing on computers at large)
• no feedback whether applying bold or italics would convey the meaning of emphasis or string
• no option to indicate the language I am using (for example in case I injected a piece from some other language) 

It is interesting to see that these problems tend to exist also on a number of sites of accessibility proponents. Maybe it would good for themselves to live by the «eat your own dog food» principle?

As someone who has fought a personal battle with a small government for some sort of web accessibility compliance, and have finally managed to get a commitment to WCAG 2.0, by 2016, and now am tasked with commenting on the proposed translated WCAG 2.0 guidelines and some of the criteria, it strikes me immediately how cluttered, confused and unstructured they are, and that is probably a large part of why they are so unappealing to mainstream development.

Instead of handling techniques in a logical manner, for instance starting with big ticket items, wireframe, structure (use of headings), moving on to graphics and links (which in many ways belong together), onto forms and Javascript, or, laternatively, be divided up into approximate roles within a web development team, they seem to jump back and forth between all of those things. The initial approach was to translate and post each guideline as a subchapter within the chapter on accessibility, and I, even as a screen reader user of nearly 20 years and web accessibility "expert" for 2 or 3, find it awfully confusing.

Just by clearing up the structure, providing YouTube videos of each technique or guideline to explain its logic and applicability to end user, and putting guidelines together that logically belong together (there are many cases of a level A conformance for a certain guideline, followed by 1 or 2 different criteria, then followed by a level AAA compliance for the same guideline as the first), these could be made a lot more useful.

I find the 3 levels confusing and the AAA level unnecessary and over-the-top.

I believe a "basic" or "minimum" and an "advanced" level would be sufficient, and we may even ask ourselves why have multiple compliance levels, it is confusing, not to mention that the criteria seem inconsistent and, in parts, somewhat arbitrary. Of course the guidelines are aimed at serving an extremely diverse group of users, and what a dyslexic user will enjoy in terms of AAA (or any level) I may find a lot less useful than a level A compliance website.

All that being said, I do not mean to come off negative at the guidelines or the work that went into them. They are the best we have, they encapsulate most of the accessibility principles, and clearly a lot of hard work and thinking went into them. The problem is that, as pointed out, they have not evolved, they are to rigid (there is very little on Javascript and interactive design, but that is taking over the webworld, and can have a lot of accessibility benefits if implemented consistently). New and important standardization rules are needed, keyboard use within wigits for instance, (I realize there is on-going work on this, but it should be part of the accessibility guidelines, or at least developed with their input and linked to from WCAG). And, of course, that leaves out the fact that part of WCAG 2.0 criteria seemed to be aimed at longer documents, that usually are not HTML documents but in PDF form (Word or similar), yet WCAG 2.0 does not apply to these documents (which makes another case for why they may not e so popular, we can hardly expect mainstream developers to have to learn to deal with multiple standards for multiple document types with multiple test criteria).

I do not know if WCAG 3.0 is in the works, but I feel that we may not necessary need to start from scratch, not at all.

A revission and simplification of the current standard, with increased documentation and adding new emphasis may be sufficient (then again, I guess that is the standard definition of a version upgrade isn't it).

I do not claim nearly the same expertese as many people on the wEbaim list or who will correspond to this post, but as someone who is reviewing these things right now and actively pushing the accessibility agenda forward, I certainly have opinions, hopefully they can at least spark a discussion amongst the wise ones.