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
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:10 UTC