Re: Applicability of native semantics when ARIA roles used

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

Received on Thursday, 24 August 2017 16:44:23 UTC