Re: Applicability of native semantics when ARIA roles used

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