Re: Element.getComputedRole()

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