RE: In WCAG NEXT let's put a date field on failures

From: Alastair Campbell []
Sent: Wednesday, April 27, 2016 12:30 PM

I think part of the problem is that 1.3.1 (and 4.1.2 for web-apps) are in WCAG as SCs, but they are really the “size" of principles. When you create a page to be accessible (or audit a page), they hide a huge number of things you need to do or check.

1.3.1 means you have to go through every element on the page and ask yourself “is this the appropriate structure/semantics?”

Checking 1.3.1 & 4.1.2 usually takes more time than all the other SCs put together.

Perhaps if these were broken down more it would be easier to update them?

Do you have a proposal as to how you would maintain the technology-neutral and general approach of WCAG 2.0 while providing more normative detail in these areas?

For example, HTML and SVG are very different in regard to the kinds of structure that they support, even without considering other technologies which an author might use.

The supported structural and semantic distinctions change with each version of one of these languages. HTML may be heading toward a more rapid release process as well, which further accelerates the pace of change.

The above is a genuine question; I’m not trying to use it in support of an argument that more detailed success criteria in these areas are infeasible, but neither do I have a good answer – and these are very much the issues that were struggled with when WCAG 2 was under development.


This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.


Received on Wednesday, 27 April 2016 19:54:17 UTC