- From: James Craig <jcraig@apple.com>
- Date: Thu, 16 Oct 2014 22:30:23 -0700
- 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>
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.
Received on Friday, 17 October 2014 05:30:54 UTC