RE: ARIA role restrictions in HTML5

One concern I have with ARIA use without structural supports is that these
accessibility benefits will be limited to users of screen readers.  For
example, if ARIA headings placed on divs are used to meet WCAG conformance
– the indication of headings will not be apparent to a user with custom
style sheets – unless CSS selectors are used to account for ARIA roles.
  I wonder if there is some recommendation that can be made to allow the
benefits promoted in the accessibility APIs to also benefit custom style
sheet users by instructing browsers to apply are roles matching HTML
elements to the style defined in CSS?



Similarly, the benefits afforded to users with motor disabilities and low
vision by being able to click on a label when explicit labels are used are
lost when aria-labelledby is used.



For these reasons, relying on ARIA lone to meet WCAG conformance can pose
issues until user agents can translate this programmatic information into
equivalent experiences across user groups..



Jonathan



*From:* Steve Faulkner [mailto:faulkner.steve@gmail.com]
*Sent:* Thursday, March 21, 2013 5:43 AM
*To:* Bryan Garaventa
*Cc:* David Ashleydale; Jonathan Avila; w3c-wai-ig@w3.org
*Subject:* Re: ARIA role restrictictions in HTML5



Hi Bryan,

ARIA is implemented in browsers, once implemented features are very rarely
removed.

The hope is that with the addition of new native HTML controls in HTML5,
developers will use these instead of rolling their own, but from experience
we know that even basic controls such as buttons that have been around
since HTML 2.0 are still not used in some circumstances (For example the
Gmail UI contains  literally hundreds of controls but the vast majority are
built from divs and spans with ARIA added).

So while it is obviously better that native controls are used as they have
role,state, property information built in as well as keyboard interaction,
this is often not the case.

Also it should be noted that HTML5 fills in some of the gaps, but does not
fill in all of the gaps and that will be the case for the forseeable future.

I wrote this a few years ago (needs updating), but it is still the case:
HTML5 and the myth of WAI-ARIA redundance
http://blog.paciellogroup.com/2010/04/html5-and-the-myth-of-wai-aria-redundance/

with regards

--
SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>



On 20 March 2013 19:29, Bryan Garaventa <bryan.garaventa@whatsock.com>
wrote:

My concern is that ARIA works well right now when properly implemented.



Many others have thought the same, and have implemented  ARIA within web
applications across the web, not just on single page implementations, but
have built ARIA support into CMSs as well.



In short, ARIA is now entrenched in the web, and it will likely never leave
it regardless what the standards are.



So it would be good to know whether ARIA recognition will ever be pulled
out of browser and Assistive Technology support, sort of like pulling out
the rug from all of these implementations, making previously accessible
components suddenly inaccessible?



----- Original Message -----

*From:* David Ashleydale <david@randomlife.com>

*To:* Bryan Garaventa <bryan.garaventa@whatsock.com>

*Cc:* Jonathan Avila <jon.avila@ssbbartgroup.com> ; w3c-wai-ig@w3.org

*Sent:* Wednesday, March 20, 2013 12:07 PM

*Subject:* Re: ARIA role restrictictions in HTML5



It's funny -- I always thought that ARIA would be kind of a preview for
HTML 5. That the ARIA attributes would become part of the HTML spec.



But it doesn't seem to be turning out like that.



David

On Wednesday, March 20, 2013, Bryan Garaventa wrote:

I agree, anchor elements work well for this purpose, especially for
graceful degradation with radio buttons.



Regarding buttons, I often see A tags styled as buttons for form submission
elements.



Not having the ability to put role="button" on such elements to aid screen
reader interaction, would impair accessibility, not enhance it. The same is
true for Toggle Buttons, and Checkboxes.



A tags are also used for Listbox Option elements, which is also used to
support graceful degradation.



This brings me to a question I've been wondering about.



Is HTML5 supposed to replace ARIA, or will they work together? In other
words, will components built using current standards compliant ARIA still
be valid ten or twenty years from now?





----- Original Message -----

*From:* Jonathan Avila

*To:* w3c-wai-ig@w3.org

*Sent:* Wednesday, March 20, 2013 7:25 AM

*Subject:* ARIA role restrictictions in HTML5



I was looking at the latest draft version of the HTML5 specification and
noticed in the implicit aria semantics table it indicates that only a
limited set of ARIA roles can be used with certain elements such as the
anchor element to conform to the HTML5 specification.  Specifically you
could not use a role of button, radio button, etc. on anchor elements.
This seems problematic but makes good semantic sense.  One advantage of
using anchors with hrefs for diverse ARIA roles is there is some
progressive enhancement support.



http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-implicit-aria-semantics



Jonathan