RE: Applicability of native semantics when ARIA roles used

What needs to be clarified in the name calculation spec is when and what is used to determine the accessible name from the native semantics when the role attribute is used.

I would assume <img role="heading" src="this.png" alt="This"> should not have an accessible name of "this" because alt is not a validate mechanism for an accessible name on a heading.  But what I hear you saying is that alt will be pulled in as a valid accessible name for the image but then the image role will be changed to a heading but the accessible name will be maintained.  This is not clear in the spec at what point this transubstantiation occurs.

Jonathan

Jonathan Avila
Chief Accessibility Officer
Level Access, inc. (formerly SSB BART Group, inc.)
(703) 637-8957
Jon.avila@levelaccess.com
Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
Looking to boost your accessibility knowledge? Check out our free webinars!

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

-----Original Message-----
From: Léonie Watson [mailto:tink@tink.uk] 
Sent: Thursday, August 24, 2017 12:44 PM
To: Jonathan Avila <jon.avila@levelaccess.com>; WCAG <w3c-wai-gl@w3.org>
Subject: 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 17:30:39 UTC