Re: Opening thoughts on WAI-ARIA in HTML5

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

    Most of those look good.

> + Backward [compatibility] to ARIA, including the role attribute.

    I strongly oppose the |role| attribute. From what I can tell, it's
nothing more than a poor workaround for XML's lack of attribute
minimization. Take the following example:

| <span role="wairole:checkboxtristate" [...] > [...] </span>

    What happens if we replace this with a namespaced attribute of the
same name as the role?

| <span wairole:checkboxtristate="true" [...] > [...] </span>

    Well, what do you know! The exact same number of characters! You may
ask, however, what happens if there is more than one WAI-ARIA role.
Well, the WAI-ARIA Role specification doesn't define how multiple roles
from that namespace interact or even entertain the possibility, so it's 
kind of a moot question.

    Another problem is that HTML doesn't have any defined way of handling
namespaces. Since the |role| attribute (as currently defined) requires
namespaces, it can't be used in HTML without the addition of namespaces
to the syntax.

    Here's how I'd like to see this handled:

HTML and XHTML:
| <span wairole="checkboxtristate"> [...] </span>

    This would take a single value (since the existing spec only
really defines using one WAI-ARIA role at a time anyway) and would
map it to the following in XHTML:

| <span wairole:checkboxtristate="true"> [...] </span>

    Controls that overlap attributes in the WAI-STATE specification (such
as |readonly|, |disabled| and |checked|) would then be allowed on all 
HTML elements, but they would be treated as aliases for WAI-STATE
attributes in question and would otherwise be ignored for elements that
they are invalid for in HTML 4.01. (Thus, Internet Explorer's use of
|disabled| on non-control elements would become valid.) Note, however,
that these elements would still be limited to their range of values they
had in HTML 4.01, with the exception of new attributes and values
introduced in Web Forms 2.0.

    This would allow you to do the following...

| <span wairole="checkboxtristate" checked disabled> [...] </span>

    ...as opposed to the following plus two namespace declarations...

| <span role="wairole:checkboxtristate" aaa:checked="true"
| aaa:disabled="true"> [...] </span>

    For WAI-STATE attributes and values not covered by this, you'd still
have to use XHTML and the WAI-STATE namespace.

> + Allow for full interoperability with assistive technologies

    This is generally a good thing, but new HTML features should not 
necessarily be targeted towards legacy assistive technologies.

> + A preference for access to accessibility information via the DOM

    OK.

> + Reduced efforts by authors to support assistive technologies

    This one is critical. If your average MySpace user can't understand 
how to make their markup accessible, you might as well go back to the 
drawing board.

> + Support for the access element or a version of it.

    HTML 4.01 <label> elements (and the |accesskey| attribute) already 
handles part of this:

| <label for="username" accesskey="u">User Name</label>

    I think <link> could be adapted for this as well:

| <link rel="access" href="#username" title="User Name">

    Don't see a huge need for a new <access> element. I especially don't 
see the point of |targetrole|. Why would you want to have a single key 
assigned to multiple controls? That's just confusing.

> + Maintain equivalent or improved accessibility features of HTML 4.01

    I think most of the accessibility features in HTML 4.01 should be 
kept, but perhaps some should be replaced with better markup that will 
see greater use on the Web.

Received on Thursday, 2 August 2007 02:09:27 UTC