Re: Element.getComputedRole()

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.