Re: WCAG proposal for discussion

Hi Gregg,



I will leave the timings comments to others with more experience, I just wanted to pick up on this point:



“I continue to worry that we are / will throw away 90% of the good work we do because it isn’t measurable and generally applicable …

I would much rather we work on gathering all that we know, whether testable or not, and publishing it as a note on ‘how to make web content accessible to XXXXX  (e.g. people wth cognitive, language, and learning disabilities)”



I totally agree with the issue you raise, whilst the success criteria act as a very useful backbone of what ‘has to be done’, we see issues all the time that are usability based (therefore affect everyone, but people with disabilities more), or things that are contextual to the website and don’t fit under a guideline easily.



When it comes to how to present this information, I would again shy away from categorizing by disability. One of the best things about WCAG2 is that it is a coherent whole, each guideline is applicable in general and you don’t have to cross-reference against other categories.



If the best practices (or whatever they are called) are by disability, you are forced to think by audience. If you are designing one thing, you then have to work through different best-practices to check it works for different people. For example, if you are designing or developing a forms interface, you have to go through every set of best practices in order to find the relevant bits in each.



WCAG2 uses POUR, which is good for guidelines (I’ve not thought of a better way of categorizing them in general).



When I do training, I’ve iterated down to four main interaction styles, which has worked well for designers, developers, content people, and project managers. (It is a general way to work out if any interface is meeting the basics, and then expand to the detail of the guidelines.)



But for best-practices, I would recommend functional categories. E.g. layout & navigation, basic forms, colour use, content (headings, lists, alt text, labelling), video/multimedia, ARIA widgets.



The idea being that as a designer/developer you can sit down, work through one thing, and know everything you need to about making accessible layouts, it covers all the disabilities.



Sorry, relatively minor point at this stage, +1 to the general approach!



-Alastair