- From: Joshue O Connor <joshue.oconnor@cfit.ie>
- Date: Thu, 19 Jul 2007 22:31:17 +0100
- To: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Cc: public-html@w3.org
Al Gilman wrote: > To summarize, our goals for HTML 5 are as follow: > > + Support for issues highlighted in Table: 1 of the ARIA Roadmap > http://www.w3.org/TR/aria-roadmap/#html_support > + Backward compatability to ARIA, including the role attribute. > + Allow for full interoperability with assistive technologies > + A preference for access to accessibility information via the DOM > + Reduced efforts by authors to support assistive technologies > + Support for the access element or a version of it. > + Maintain equivalent or improved accessibility features of HTML 4.01 I am all for these points and I feel - in principle - that they represent a coherent and cohesive approach to the development of HTML 5 as well as new - hopefully - future proof accessibility features and much needed support for older already established accessibility authoring methods and modalities. I am however a little unsure of the language used - in particular - for the last point. >> + Maintain equivalent or improved accessibility features of HTML 4.01 Does this mean that HTML 5 _will_ continue to support @summary, @longdesc as well as headers/id? In reality, these are accessibility features that _do_ work - they may not be ideal but they do fly. Will they still be supported by HTML 5 as worthy legacy attributes or are they to be in all likelihood finally deleted? IMO it would be wise to support them but maybe not necessarily to _recommend_ them (if there are true advances in the specifications that are genuine improvements). At the very least this support could act as a device to help authors who understand how to implement these attributes successfully while they make the transition to new authoring methods - so in that context it would be wise to continue to provide support for them. If they are supported - and the spec also supports 'Backward compatibility to ARIA, including the role attribute' then that is one powerful spec - when combined with improved, easy to author, vendor supported, accessibility features. The spec will then both look forward and back. Maybe we should call this the Janus project? A couple of final thoughts: >> + Allow for full interoperability with assistive technologies This will obviously have to encompass legacy user agents also, see above. >> + A preference for access to accessibility information via the DOM While this in not a HTML WG issue it is still relevant: This would be ideal - in particular for dynamic content - and it is stated here as a preference. Many screen readers continue to use the Off Screen Model (OSM). Is it foreseen that most future iterations of screen readers will interrogate the DOM directly and not use the OSM? This is probably likely. AFAIK Dolphins' Supernova is the only screen reader that currently does this. Has the WG contacted any vendors like GW Micro and Freedom Scientific etc to see that they support this shift towards access to accessibility information via the DOM by changing the way their products work? Josh
Received on Thursday, 19 July 2007 21:32:04 UTC