- From: Richard Schwerdtfeger <notifications@github.com>
- Date: Thu, 25 Aug 2016 12:53:10 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/553/242515005@github.com>
This is the first time I have seen this API work. There was a rumor that Mozilla and Google were working on one. That is an excellent question! Each platform accessibility API has a mapping for a custom role description. Look at the mapping for aria-roledescription: http://rawgit.com/w3c/aria/master/core-aam/core-aam.html However, that is a localized role name that is difficult to tee off of for an AT in and by itself. Microsoft's UI Automation has a notion of control patterns. (that include interfaces that can be called as well as properties that are exposed) that can be used for accessibility as well as automated testing. The combination of these control patterns forms a signature for which you can expose a standard recognized role and/or a custom role. An AT would look at the combination of control patterns to assess how to work with the new customer control. This is why we have been looking at the UIA model for custom controls. So, what we really need is a vehicle for discovery. UIA does do that by producing an "signature": tabular, scrollable, clickable, selectable, etc. These can be applied to objects like any other accessibility api. I brought the API you mentioned up on the ARIA call today and Microsoft said they were no longer involved with it. Whatever we do we need everyone playing in the same boat. Now, to understand Microsoft's perspective they have a common API strategy designed to work across all their platforms: XBox, Windows Desktop, Tablets, Phones. It is all UIA based. So, circling back to your question, combining common control patterns with existing role mappings and/or custom, localized roles is a way forward. Another possibility that was not adopted by browser manufactures was to have the role value be a name-spaced (I know the browser community hates those) value that could be converted to say a JSON object reference that allowed and AT to discover about the new custom role and how to interact with it. That would include information like inheritance. Originally, when we created ARIA we had role values that could be prefixed and converted to a semantic web RDF/OWL representation of that information. The browser vendors told us to get rid of it or they would not accept it and we lost the functionality. We certainly could do something like but find a way to ditch the name spaces. You can see remnants of this in the Chrome and Firefox MSAA/IA2 implementation where you have the xml-roles object attribute that exposes the content role value. That used to be name-spaced prefixed. Here is a reference information on UIA Control Patterns: https://msdn.microsoft.com/en-us/library/ms752362(v=vs.110).aspx -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/553#issuecomment-242515005
Received on Thursday, 25 August 2016 19:53:44 UTC