Re: Applicability of native semantics when ARIA roles used

On 28/08/2017 02:39, Jonathan Avila wrote:
>>   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.

What is missing, in this case, is a clear algorithm (in the ARIA spec, 
perhaps?) that defines how user agents should handle the situation. As 
nothing is codified in spec anywhere, it's not surprising that UAs do 
their own heuristics/error correction when encountering potential 
conflicts like this one.

I'd hope that when (if?) the Accessibility Object Model (AOM) Phase 4 is 
implemented in browsers 
(http://wicg.github.io/aom/explainer.html#phase-4-full-introspection-of-an-accessibility-tree) 
- which sadly may be a long way off - it will be possible to then also 
write JS-based unit tests to ensure that UAs behave according to this 
(as yet not defined) algorithm.

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Monday, 28 August 2017 07:56:23 UTC