[Athen] ARIA attributes

[Bossley, Peter A.]

Alex is basically exactly correct.
ARIA that is made up will have no impact on accessibility whatsoever. ARIA roles that aren’t implemented properly will usually create more problems than it solves.
I would extend the technical description a tad; the browser reads the DOM (code of the web page,) and presents the browser’s interpretation of the DOM to the Accessibility API of the operating system. Screen readers, by and large anyway, read the accessibility API and interpret that output. So, in short, the website must implement the specification properly, and both the browser and assistive technology in question must support and implement the specification. If any of these things are not true, it can lead to problems.
For example, it is possible, and often does occur, that there is a lag between roles being part of the specification, or proposed for inclusion, and when those roles, states, and values are supported by the browser and screen readers in question. Older browsers or screen readers may not, and often times do not, fully work with the latest version of ARIA. This is why ARIA should not be used as a first-line solution to accessibility problems; and especially not ARIA that is simply proposed or newly included ARIA.
As an aside, this is also why pushing the browsers and assistive technology vendors to stick strictly to the specification is so important. It is challenging enough to ensure accessibility in this space, but all the more if browsers and assistive technologies don’t uniformly implement the specification.

From: athen-list <athen-list-bounces at mailman12.u.washington.edu> On Behalf Of Alex Umstead
Sent: Thursday, April 18, 2019 7:37 PM
To: Access Technology Higher Education Network <athen-list at u.washington.edu>
Subject: Re: [Athen] ARIA attributes

Hi Khoa,
I'll put it this way: if they think they can make up ARIA roles, states, and properties, they don't know much about ARIA. :)

ARIA only works (at least as I understand it) through the browser exposing information in very specific ways to the OS' accessibility API. If developers make up a role/state/property, the browser won't know how to expose it, and the screen reader won't know how to interpret it. Role="fish", for example, will not make JAWS or NVDA consider something to be a fish, because there's no such thing as a "fish" mapping in Windows' User Interface Automation API.

Here's some info on how ARIA roles are supposed to get mapped<https://www.w3.org/TR/core-aam-1.1/#roleMappingGeneralRules>. Again, this isn't necessarily how it all translates out in the real world, but should cover the scope of what you're running into.

I'd also share this Role Mapping Table<https://www.w3.org/TR/core-aam-1.1/#mapping_role_table> with them, and ask them to explain how (with what ATs and browser combinations) they're coming to the conclusion that fake ARIA works, and what criteria they're using to determine "works" vs "doesn't work."

Also, I'm wondering if they're looking at one really specific edge case -- role="text", which was proposed for the spec<https://www.w3.org/WAI/ARIA/track/issues/435>, but not added, and has unofficial support in Safari/VoiceOver on iOS and (I think?) in Chrome -- and assuming that what they can do in a really, really specific scenario applies everywhere.

You can also open up the accessibility inspector in Chrome or FF to get an idea of how elements are getting mapped in the accessibility tree, and then take screenshots of how their code gets translated out to screen readers. This won't necessarily correlate 1:1 with the OS' internal mappings, but should be enough to show them that their fake roles aren't actually changing anything.

Alex


On Thu, Apr 18, 2019 at 5:43 PM Khoa Pham <kpham at swccd.edu<mailto:kpham at swccd.edu>> wrote:
Hi All,

I recently had a discussion with a vendor on the non-accessible areas of their product. One of the things that was discussed was their use ARIA roles and states. I use AXE as one my tools to test for accessibility and would often run into these errors:


•         ARIA attributes must conform to valid names

•         ARIA attributes must conform to valid values

•         ARIA roles used must conform to valid values


I would check to make sure these errors are not false positives with the two sources below before notifying the vendor. Although they will look into these findings, I had mentioned that I have found similar errors in other products that seems to show made up ARIA roles, states, and values. Their response was it is acceptable to make up ARIA. This doesn’t sound right and I’ve tried to search for anything to confirm this statement, but have come up empty handed. Can anyone please provide me with an answer?


•         https://www.w3.org/TR/wai-aria-1.1/

•         https://www.w3.org/TR/wai-aria-practices-1.1/

•         https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques

Thank you,
Khoa
_______________________________________________
athen-list mailing list
athen-list at mailman12.u.washington.edu<mailto:athen-list at mailman12.u.washington.edu>
http://mailman12.u.washington.edu/mailman/listinfo/athen-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman12.u.washington.edu/pipermail/athen-list/attachments/20190423/0c542fa5/attachment.html>