- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Fri, 17 Oct 2014 08:17:03 -0500
- To: James Craig <jcraig@apple.com>
- Cc: Chris Fleizach <cfleizach@apple.com>, David Bolter <dbolter@mozilla.com>, Dominic Mazzoni <dmazzoni@google.com>, PF <public-pfwg@w3.org>, Alexander Surkov <surkov.alexander@gmail.com>
- Message-ID: <OFA0274BF6.58AFCF04-ON86257D74.0048538D-86257D74.0048F8CB@us.ibm.com>
Alex asked how getComputedRole would work off list. Here is a pass: OK. so let's have the discussion. This is not a platform role it is the role that the browser knows about. So, in the following example: <section role="chapter group"> If the browser knew how to map a role of chapter it would return "chapter". If the browser did not know how to map a role of chapter then it would look to a role of group. If it knew how to map a group role it would return "group" If the browser did not know about a role of "group" it would return the default native ost language role value for the <section> element which should be "region" The only exception to this would be where the host language held restrictions on the use of role. For example, if you were not allowed to put a grid on <button> you would return a role of "button" I don't have an issue with querying accessibility information but I am very concerned about putting in a full blown a11y API. One of the values of what we have today is that developers who are not A11y gurus can have design discussions regarding how to produce an accessible UI based on semantics. IndieUI will address the effort having to address keyboard access - I hope. We need to remember that the level of a11y skills of this group far exceeds the average developer in a large company. The second issue is that going down this pass takes us well beyond what we were going to do for ARIA 1.1. Rich Rich Schwerdtfeger From: James Craig <jcraig@apple.com> To: David Bolter <dbolter@mozilla.com>, Alexander Surkov <surkov.alexander@gmail.com>, Dominic Mazzoni <dmazzoni@google.com> Cc: PF <public-pfwg@w3.org>, Chris Fleizach <cfleizach@apple.com> Date: 10/17/2014 12:31 AM Subject: Re: Element.getComputedRole() Alex Surkov wrote: >> 2) it doesn't make sense to expose accessible properties on every DOM >> element (like on inaccessible DOM elements) and Element API approach cannot ... >> I would design an Accessible interface instead following the accessibility >> desktop APIs. >> interface Accessible { >> string role; >> }; >> >> Then DOM Window object can be extended by: >> interface Window { >> Accessible getAccessibleFor(Node aNode); >> }; The "'Accessible' adjective used as noun" makes for awkward API. What about "AccessibleElement" or "AccessibilityElement" instead? interface AccessibilityElement { // Some of these might not need to be an accessors methods. Could be string properties as you suggested. String computedRole(); String computedLabel(); Element element(); // reverse relationship back to DOM element, or null. AccessibilityElement accessibilityParentElement(); Array accessibilityChildren(); }; partial interface Element { AccessibilityElement accessibilityElement(); }; Dominic wrote: > Sure, I think it's a good idea. > > How about getComputedAccessibleText next? > > In both Blink and WebKit I imagine we'll have to think about efficiency when implementing this - typically we enable accessibility lazily and then leave it on - at least for that page. We'd want to use the real accessibility code to compute this, but then disable accessibility support and clean up if it wasn't enabled previously. +Chris, who had similar concerns.
Attachments
- image/gif attachment: graycol.gif
Received on Friday, 17 October 2014 13:17:36 UTC