[Athen] ARIA attributes

[Alex Umstead]

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> 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

> 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/20190418/38c5870e/attachment.html>