Intent to Implement: Element.computedRole/Element.computedLabel

[Alice Boxhall]

Contact emails

abox...@chromium.org, dmaz...@chromium.org

Spec

PFWG bug/discussion: https://www.w3.org/WAI/PF/Group/track/issues/427

DOM bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27294

Summary

Extend the Element interface as follows:

partial interface Element {

String computedRole();

String computedName();

}

This will be implemented behind the "experimental web platform features" flag in Chrome.

Motivation

Quoting from the PFWG bug: 

"""

Since the role attribute accepts a whitespace-delimited set of token values for applicable roles, the web application needs a way to determine which of those roles has been applied to a particular element. For example, given the following markup:

<el role="NewRole button link">

We may be able to assume that "button" will override the "link" role in any ARIA-compliant browser, since both of those roles are standard in ARIA 1.0, but what if the example role "NewRole" is added to ARIA 2.0 or another spec. The web application needs to know which role has been applied so it can control the behavior accordingly. 

"""

Regarding computedLabel, this will be useful for testing and debugging purposes, where it may be used to manually check what label a certain element exposes to accessibility, or in an automated testing context where assertions may be made about label content (e.g. non-empty, correctly localized, etc.)

Compatibility Risk

Low to moderate. The PFWG bug states that representatives from Chrome, IE and Mozilla have expressed interest (and the bug was filed by a Safari engineer). However, no full spec exists yet, nor any other implementation. The purpose of this implementation would be to explore use cases and help flesh out the spec.

Ongoing technical constraints

Requires core DOM code to be slightly more coupled to accessibility code (in order to retrieve the computed role/label).

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug?

https://crbug.com/442978

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5530552681627648

Requesting approval to ship?

No.

[Philip Jägenstedt]

Hi Alice,

https://www.w3.org/WAI/PF/Group/track/issues/427 requires a username
and password. Please make public any information in this issue that
might be relevant. In particular, I didn't spot any IE or Mozilla
feedback elsewhere.

I've read through the public-pfwg threads linked from
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27294#c1

At the end of that thread
<http://lists.w3.org/Archives/Public/public-pfwg/2014Nov/0191.html>,
James Craig <jcr...@apple.com> writes:
> Element.role will be the reflected string value:
>
> for <h1 role="fake">
>
> el.role -> read/write string "fake"
> el.computedRole -> readonly string "heading"

As illustrated by this example, I think computedRole is the first of
the tokens in the role attribute which is known by the browser (the
list is in AXObject.cpp) and falls back to the "default implicit ARIA
semantic" if none of the tokens are known:
https://html.spec.whatwg.org/#wai-aria

Do you also want to implement the role reflected attribute?

Some kind of preliminary spec would be nice. In Blink, the role
attribute is in HTMLAttributeNames.in only, which would suggest
putting role/computedRole on HTMLElement, i.e. file a spec bug at
<https://whatwg.org/newbug>. Whichever spec you target, seeing some
positive response from the spec editor would be encouraging.

The case for computedName (or is it computedLabel?) seems weaker. If
the primary purpose is testing, debugging and automated testing,
exposing it in Internals would seem to suffice. There was less
discussion about it, so I'm not sure what it should do.

Philip

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

In https://www.w3.org/Bugs/Public/show_bug.cgi?id=27297#c3 Hixie wrote:
> I don't see what HTML has to do with this. Sure, HTML defines some default
> semantics. So do, or might, SVG, MathML, HypotheticalRandomNewML, etc. The
> API has nothing to do with HTML itself as far as I can tell. It's either an
> ARIA feature, or maybe a DOM feature, or its own feature, IMHO.

So ignore my suggestion about HTMLElement. You can try with DOM, or
write a new spec.

Philip

[Dominic Mazzoni]

On Wed, Dec 17, 2014 at 2:07 AM, Philip Jägenstedt <phi...@opera.com> wrote:

The case for computedName (or is it computedLabel?) seems weaker. If
the primary purpose is testing, debugging and automated testing,
exposing it in Internals would seem to suffice. There was less
discussion about it, so I'm not sure what it should do.

I see this as potentially very useful for feature / capability detection and providing polyfills. As one example, there's a proposal that would allow you to specify a querySelector string in aria-labelledby instead of an IDREF. If that proposal ends up being implemented, an author would be able to detect if the feature is supported or not by using computedName/computedLabel.

[Philip Jägenstedt]

Can you describe in more detail what computedName/computedLabel should
do? Other than <label> elements associated with e.g. <input> and
aria-labelledby attributes, what other things have an influence?

Something like aria-labelledby="div > p" sounds curious, how would you
know whether to interpret "div > p" as a selector or as an id? It's
possible to have id="div > p" and getElementById("div > p") will find
that element, after all.

Philip

[Alice Boxhall]

On Fri, Dec 19, 2014 at 10:04 AM, Philip Jägenstedt <phi...@opera.com> wrote:

On Thu, Dec 18, 2014 at 6:57 PM, Dominic Mazzoni <dmaz...@chromium.org> wrote:
> On Wed, Dec 17, 2014 at 2:07 AM, Philip Jägenstedt <phi...@opera.com>
> wrote:
>>
>> The case for computedName (or is it computedLabel?) seems weaker. If
>> the primary purpose is testing, debugging and automated testing,
>> exposing it in Internals would seem to suffice. There was less
>> discussion about it, so I'm not sure what it should do.
>
>
> I see this as potentially very useful for feature / capability detection and
> providing polyfills. As one example, there's a proposal that would allow you
> to specify a querySelector string in aria-labelledby instead of an IDREF. If
> that proposal ends up being implemented, an author would be able to detect
> if the feature is supported or not by using computedName/computedLabel.

Can you describe in more detail what computedName/computedLabel should
do? Other than <label> elements associated with e.g. <input> and
aria-labelledby attributes, what other things have an influence?

This is specced here: http://www.w3.org/TR/wai-aria/roles#namecalculation

Element.computedName would return the name computed via this algorithm.

Something like aria-labelledby="div > p" sounds curious, how would you
know whether to interpret "div > p" as a selector or as an id? It's
possible to have id="div > p" and getElementById("div > p") will find
that element, after all.

This is off-topic for this discussion, but there is a discussion of this proposal on the PFWG mailing list if you're interested: http://lists.w3.org/Archives/Public/public-pfwg/2014Mar/0094.html

[Steve Faulkner]

Hi Alice,

I have started a wiki page to collect use cases

https://www.w3.org/wiki/HTML/accAPI/

On Thursday, 18 December 2014 23:21:55 UTC, Alice Boxhall wrote:

On Fri, Dec 19, 2014 at 10:04 AM, Philip Jägenstedt <phi...@opera.com> wrote:

On Thu, Dec 18, 2014 at 6:57 PM, Dominic Mazzoni <dmaz...@chromium.org> wrote:
> On Wed, Dec 17, 2014 at 2:07 AM, Philip Jägenstedt <phi...@opera.com>
> wrote:
>>
>> The case for computedName (or is it computedLabel?) seems weaker. If
>> the primary purpose is testing, debugging and automated testing,
>> exposing it in Internals would seem to suffice. There was less
>> discussion about it, so I'm not sure what it should do.
>
>
> I see this as potentially very useful for feature / capability detection and
> providing polyfills. As one example, there's a proposal that would allow you
> to specify a querySelector string in aria-labelledby instead of an IDREF. If
> that proposal ends up being implemented, an author would be able to detect
> if the feature is supported or not by using computedName/computedLabel.

Can you describe in more detail what computedName/computedLabel should
do? Other than <label> elements associated with e.g. <input> and
aria-labelledby attributes, what other things have an influence?

This is specced here: http://www.w3.org/TR/wai-aria/roles#namecalculation

Element.computedName would return the name computed via this algorithm.

Note the acc name and description stuff has been split out in ARIA 1.1
http://w3c.github.io/aria/accname-aam/accname-aam.html
and is undergoing updates.

 

[Philip Jägenstedt]

Is this implemented in Blink already? I see AXNodeObject::alternativeText but it doesn't seem very close to this algorithm. A particularly odd bit is "because it is possible to specify or alter textual content using CSS rules, it is necessary for user agents to combine such content" which would make it depend on rendering.

There's discussion in the W3C bug right now, and Steve started a wiki page, hopefully there will emerge a spec with enough details to evaluate.

An Intent to Implement doesn't need any LGTM to proceed, but nevertheless I hope there will be more feedback from API OWNERS.

>> Something like aria-labelledby="div > p" sounds curious, how would you
>> know whether to interpret "div > p" as a selector or as an id? It's
>> possible to have id="div > p" and getElementById("div > p") will find
>> that element, after all.
>
>
> This is off-topic for this discussion, but there is a discussion of this
> proposal on the PFWG mailing list if you're interested:
> http://lists.w3.org/Archives/Public/public-pfwg/2014Mar/0094.html

Thanks, the answer is something like aria-labelledby="select(div > p)" which is very unlikely to exist in the wild. I haven't seen selectors in attribute values like this elsewhere, but as you say that's off-topic.

Philip