RE: Applicability of native semantics when ARIA roles used

>  It's because of apparent conflicts like this, that changing an element's implicit role is generally cautioned against. It's too easy to end up with an element that is one thing and has all its associated characteristics, but which is exposed with a completely different role in the accessibility tree.

As an FYI I ran some tests with Chrome and IE with changing a input type checkbox to role option and found that the checked state from the checkbox came over into UIA/MSAA on IE but not in Chrome.  So while the name coming over after the role change seems to work consistently between browsers other properties don't seem to be uniformly maintained during the change.  

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 2:26 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 18:30, Jonathan Avila wrote:
> 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.

That's not quite it. In your example, the browser recognises the element as an image in spite of the explicit role, not because of it.

<img alt="this" ...>

Is treated in exactly the same way as:

<img role="img" alt="this" ...>

Explicit roles only exist in the accessibility tree. So an img element with a role of heading is still an image, and the browser calculates an accessible name accordingly.

It's because of apparent conflicts like this, that changing an element's implicit role is generally cautioned against. It's too easy to end up with an element that is one thing and has all its associated characteristics, but which is exposed with a completely different role in the accessibility tree.

That said, the Acc Name and Description spec is one of the most difficult to read IMO. It could do with clarifying this, and a bunch of other things besides I think!



Léonie.

--
@LeonieWatson @tink@toot.cafe tink.uk Carpe diem

Received on Monday, 28 August 2017 01:39:30 UTC