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

Hi Paul,

> "My reading of WCAG is that 1.3.1 always required the visually distinct page sections to be either programmatically determinable or available in text even back in the day before landmarks and HTML5 structural sectioning elements.”

I think if we ask (the medium to old-timers?) whether they failed pages for not including (hidden) headings or text to label regions of the page before 2012(ish), the answer would be no.

I didn’t, mostly because we didn’t really have the concept of standardised regions that you should label, it simply wasn’t on the radar until a simple solution came along.

Regardless of that, I think David makes a good point about the difficulty of adding failures (and thank-you David for highlighting it so effectively!) Putting dates on techniques/failures might pave the way for a standard model for updates, and WCAG.next should certainly consider it.

At the very least techniques & failures could be tagged with the version of WCAG they apply from, and therefore slot into conformance models fairly easily.

There is something else, but this may be a pandoras box, in which case tell me to shut up!

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?

-Alastair

Received on Wednesday, 27 April 2016 16:30:16 UTC