Creating HTML5 Techniques for WCAG 2.0
Written by Joshue O Connor Wednesday, 01 February 2012
Developing HTML 5 techniques for WCAG 2.0
This task force is a joint Web Content Accessibility Guidelines (WCAG) and Protocols and Formats Working group (PFWG) venture. The aim of the task force is to develop HTML5 Techniques for WCAG 2.0: Techniques and Failures for Web Content Accessibility Guidelines 2.0. The group will focus on developing new HTML5 techniques as well as upgrading suitable HTML4 techniques to make them applicable to both versions. The task force will coordinate with the Web Content Accessibility Guidelines Working Group to refine and publish these techniques.
Why is this work important?
A major reason to document techniques for HTML5 now is to discover and solve accessibility authoring issues in the HTML5 specification. There is some urgency to this work as the task force may find gaps in the HTML5 specification or areas where it is not possible to document techniques that are sufficient to conform to WCAG 2.0 in HTML 5. It will actively provide this information as input to the HTML Accessibility Task Force. This task force is a group dedicated to advocating for accessibility, and improving it in HTML5.
Joshue O Connor of the NCBI Centre for Inclusive Technology and James Nurthen of Oracle are both task force facilitators. Our main role in the task force is to set agenda, lead meetings, determine consensus, and be the primary liaison to the working groups.
While direct involvement in this new group is only open to either members of WCAG and PFWG, we want to hear what you think of HTML5 accessibility. So get in touch, comment, get involved!
Comments (2)
Questions about HTML5 and accessibility
That’s great news. It’s obviously very important—and urgent!—work. I look forward to hearing how you get on.
I’ve a few questions about HTML5 and accessibility alright…
canvaselement have a Document Object Model, so that assistive technology will be able to access it?headelement in an HTML5 webpage?sectionandarticleelements, each with their ownh1element—or is it better to stick to the usual hierarchical model of headings throughout a webpage?I guess the answer will be “Wait and see”!
Regards,
Alan.
Questions about HTML5 and accessibility
Thanks for the comment and questions.
Regarding the
canvaselement. It currently doesn't have a DOM, and you are right that it makes AT accessing the content very difficult (read 'impossible'). There are options being looked at such as implementing a shadow DOM, an aDom (or accessibility DOM) or some kind of dynamic 'on the fly DOM'. There are other flaws with it, and in short it is a long way off being accessible. There are lots of cool things that can be done visually, but it is semantically very limited (read 'non-existent') in terms of it's architecture. In fairness the lack of DOM etc is originally by design, and where there are alternatives natively in the markup language they should be used. The spec advises this. However, authors will do their own thing and use it anyway!Re: Use of the
headelement. Yup, still do it. Header meta data is still useful (if oft miss used) and represent a part of a valid, well formed HTML document. So do still use it.Re: The new headers algorithm. I suggest doing the latter and sticking to the way they have always been done. There is an interesting bug which is a result of browsers not implementing the algorithm correctly. So point your browser at the website 'Accessible Culture' for an interesting read of the article "JAWS, IE and Headings in HTML5".