- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Thu, 24 Aug 2017 14:10:45 -0400
- To: tink@tink.uk
- Cc: Jonathan Avila <jon.avila@levelaccess.com>, WCAG <w3c-wai-gl@w3.org>
The HTML5 specs say: "Note: In the majority of cases setting an ARIA role and/or aria-* attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser". https://www.w3.org/TR/html5/dom.html#aria-usage-note In the HTML5 specs, for the SELECT element, it says 'listbox' is the default role, for the button element , button is the default role and these should not be set via role attribute. For most other elements including IMG however, it only says 'any role' may be set. So setting the role that duplicates the native role is bad practice and leads to non-uniform and less robust experience across browser / AT. While that note in the HTML5 is good, perhaps the specs should explicitly state that for each element like it does for SELECT, BUTTON etc. When role=img is set for an img element, SRs look for the aria-label and in its absence fall back on the alt. Thanks and regards, On 8/24/17, Léonie Watson <tink@tink.uk> wrote: > On 24/08/2017 14:52, Jonathan Avila wrote: >> Leonie, thanks for your feedback. The ARIA in HTML document indicates " >> Adding an ARIA role overrides the native role semantics in the >> accessibility tree which is reported via the accessibility API, and >> therefore ARIA indirectly affects what is reported to a screen reader or >> other assistive technology." This would seem to imply adding the role >> could change the nature of the element. Thoughts? > > That's right, yes. > > In your example, the implicit role of the element was replaced by the > identical explicit role. > > <img role="img" src="this.png" alt="This"> > > So the browser would expose it as an image in the accessibility tree > whether it had the explicit role or not. > > If the explicit role was different from the implicit role, then it might > well cause confusion. For example: > > <img role="heading" src="this.png" alt="This"> > > The browser will display the image as you'd expect, but expose it in the > accessibility tree as a heading. > > To take another example: > > <button role="heading">This</button> > > The button would be displayed as a button in the browser and, given the > appropriate JavaScript, will also function like one. But in the > accessibility tree it would be exposed as a heading, meaning that a > screen reader user would be completely unaware that it was in fact a > button with some associated functionality. > > There are times when it's ok to change the implicit semantics of an > element though. This happens most often when an HTML element is > repurposed to create a pattern that doesn't exist natively in HTML (like > a set of tabpanels: > > <ul role="tablist"> > <li role="none"><a href="t1" role="tab">Apples</a></li> > <li role="none"><a href="t2" role="tab">Bananas</a></li> > </ul> > > So instead of a list of listitems, it is exposed in the accessibility > tree as a tablist of tabs. The listitems have their implicit role > removed entirely. > > The general rule of thumb is not to change implicit semantics unless you > have to. If you do, then make sure it doesn't break things, and that > whatever is exposed in the accessibility tree matches the visual and > functional presentation of the thing in question. > > Léonie. > > -- > @LeonieWatson @tink@toot.cafe tink.uk Carpe diem > > -- Sailesh Panchang Principal Accessibility Consultant Deque Systems Inc Phone 703-225-0380 ext 105 Mobile: 571-344-1765
Received on Thursday, 24 August 2017 18:11:09 UTC