- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Mon, 28 Aug 2017 08:55:57 +0100
- To: w3c-wai-gl@w3.org
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