On Fri, Oct 17, 2014 at 1:30 AM, James Craig <jcraig@apple.com> wrote: > 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? > I'm fine with AccessibleElement > > 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(); > I see the hand of OS X Accessibility Protocol designer :) what about AccessibleElement parent; > Array accessibilityChildren(); > }; > partial interface Element { > AccessibilityElement accessibilityElement(); > }; > this also works > > > 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 12:47:37 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:10 UTC