W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2013

RE: ARIA role restrictions in HTML5

From: Jonathan Avila <jon.avila@ssbbartgroup.com>
Date: Fri, 22 Mar 2013 08:25:17 -0400
Message-ID: <5598c44b67cab56e4157be100f59d113@mail.gmail.com>
To: Joe Chidzik <joe.chidzik@abilitynet.org.uk>, Steve Faulkner <faulkner.steve@gmail.com>, Bryan Garaventa <bryan.garaventa@whatsock.com>
Cc: David Ashleydale <david@randomlife.com>, w3c-wai-ig@w3.org
[Joe Chidzik wrote] It is good practice to use appropriate HTML elements
first, and then fall back to ARIA for modifying an existing



My concern is what we agree upon as a good practice is just that “a good
practice” but not a requirement.  In practical terms developers will only
use ARIA headings for content that should be a native HTML heading and will
claim conformance to WCAG 2.  You can say this is bad coding or say what
you will but bad coding is not a failure of WCAG 2 or Section 508.  HTML
validation isn’t a requirement of WCAG 2 or Section 508 either.



Other WCAG sufficient techniques such as including off-screen text in links
are also seen as bad coding practices that should be avoided – yet they are
sufficient to meet the requirements.  The challenge would then be to apply
the accessibility supported conformance requirement as a functional
requirement to ensure the experience is equivalent to using native
elements.  Perhaps an update to the UAAG to translate ARIA roles and
properties into the features in user agents beyond the accessibility API.



Jonathan



*From:* Joe Chidzik [mailto:joe.chidzik@abilitynet.org.uk]
*Sent:* Friday, March 22, 2013 4:20 AM
*To:* Jonathan Avila; Steve Faulkner; Bryan Garaventa
*Cc:* David Ashleydale; w3c-wai-ig@w3.org
*Subject:* 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



[Joe Chidzik] It is good practise to use appropriate HTML elements first,
and then fall back to ARIA for modifying an existing element if a suitable
HTML element does not already exist. In this case, the standard h* HTML
elements exist for headings, and should be used in preference to a div+aria
heading code. Of course, standard HTML elements have CSS selectors, and so
are well covered for users who wish to use custom stylesheets.



One example I guess for use of an ARIA heading would be a hidden heading
for a sidebar on a webpage. This might not benefit from a visual heading as
would be visually distinct from the main content of the page. A hidden
heading, though, would serve screenreader users well e.g. <div
role=”heading” aria-level”2”>Secondary nav</div> (I don’t know how
appropriate this example be, I couldn’t think of a better one though).



Do you have a specific example in mind?
Received on Friday, 22 March 2013 12:25:50 GMT

This archive was generated by hypermail 2.3.1 : Friday, 22 March 2013 12:25:51 GMT