RE: Why are conflicts between native markup semantic and WAI-ARIA so complicated?

It is important to remember ARIA only changes the information communicated to the accessibility APIs, it does affect the graphical rendering or behavior of the browser.   The aria-hidden attribute is about hiding information from the accessibility APIs (not content being rendered graphically), and in this case on an a div element with the hidden attribute there is nothing to expose.  Hope this logic makes more sense.  

Jon


-----Original Message-----
From: Jason Markou <jason.markou@sydney.edu.au> 
Sent: Wednesday, May 2, 2018 2:07 AM
To: Jeremy Echols <jechols@uoregon.edu>; Tobias Bengfort <tobias.bengfort@posteo.de>; WAI IG <w3c-wai-ig@w3.org>
Subject: RE: Why are conflicts between native markup semantics and WAI-ARIA so complicated?

The problem with the first two examples is that div's are non-semantic elements - so there are no native semantics for ARIA to override.  

In the second example adding aria-label="foo" does not override or replace the div text as far as the AT is concerned. In fact screen readers won't voice the label at all in this example as the div hasn’t been assigned a role.

Jason

-----Original Message-----
From: Jeremy Echols <jechols@uoregon.edu> 
Sent: Wednesday, 2 May 2018 12:52 AM
To: Tobias Bengfort <tobias.bengfort@posteo.de>; WAI IG <w3c-wai-ig@w3.org>
Subject: RE: Why are conflicts between native markup semantics and WAI-ARIA so complicated?

I'm probably going to misspeak here, but this is my understanding: ARIA lets you tell assistive technology to interpret something differently from how the browser sees it.  ARIA cannot, however, change an element's behavior in any way.

When you say a div has the role of "button", you're telling the screen reader (or any piece of AT) that you have a button, but the browser won't actually treat that as a button if you don't also specify behavior via JavaScript.  So while ARIA "wins", you actually haven't done anything to change the element itself into a button.

With the ARIA label, it's very similar, but ARIA really does have complete control.  In this case, the element is nothing but a bit of text, so you have no behaviors to worry about.  You're simply telling any AT that the piece of text should be interpreted as if it were "foo" regardless of what the browser would render to screen.  e.g., there are no underlying behaviors or semantics that you have to worry about beyond the element's text.

The hidden element is also similar - the browser has been instructed via the "hidden" attribute not to render the element in any way.  It won't be rendered to the screen, it won't be sent to a screen reader, etc.  It's not that ARIA "loses" here; it's that the element doesn't get processed.  Since the element is irrelevant (per the definition of the "hidden" attribute), the ARIA attribute is also irrelevant.

-----Original Message-----
From: Tobias Bengfort <tobias.bengfort@posteo.de> 
Sent: Tuesday, May 01, 2018 12:42 AM
To: WAI IG <w3c-wai-ig@w3.org>
Subject: Why are conflicts between native markup semantics and WAI-ARIA so complicated?

I always assumed that WAI-ARIA will always override native semantics.
But now I found <https://protect-au.mimecast.com/s/NJ9ICXLKZoim18NAt6d9eS?domain=w3.org>.

Some examples:

- `<div role="button"></div>` has role "button" (ARIA wins)
- `<div aria-label="foo">bar</div>` has label "foo" (ARIA wins)
- `<div aria-hidden="false" hidden></div>` is hidden (native wins)

This seems overly complicated to me. What were the reasons this was decided?

tobias

Received on Wednesday, 2 May 2018 07:38:27 UTC