computedRole/computedName

[Alice Boxhall]

We've implemented this behind a flag for now [1], and we're not wedded to keeping it, but would love to have a discussion about what we want to expose regarding a11y information in the DOM.

There's been a bunch of discussion around this all over the place:

- On the PFWG mailing list https://lists.w3.org/Archives/Public/public-pfwg/2014Oct/0120.html

- On Specifiction http://discourse.specifiction.org/t/dom-apis-to-expose-accessible-role-states-properties/693

- On the Chromium intent to implement thread https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/computedRole/blink-dev/WToTEn4lveY/0DDozNNQqE8J

- On the w4.org bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27294

- On Alex's blog: http://asurkov.blogspot.com/2014/11/accessibility-goes-into-dom.html

Steve Faulkner put together a helpful list of use cases [2]. Essentially, these comprise:

- feature detection use cases (what role was actually applied?)

- extension development (e.g. finding things in the page with a given applied role, regardless of whether the role was explicit or implicit), and 

- testing/debugging (assert that a particular role was applied, assert that computed text is not empty or wrong).

My questions, then, are:

- How important are these use cases?

- What use cases for accessing accessibility information from the DOM do these properties not cover? (My reading of Alex's objections is that these two methods don't provide enough information, and providing enough information would bloat the DOM API, so we need a better mechanism.)

- Would you be interested in trying this API out behind a flag? The implementation is, obviously, pretty straight forward [3].

Cheers,

Alice

[1] https://www.chromestatus.com/features/5530552681627648

[2] https://www.w3.org/wiki/HTML/accAPI/

[3] https://codereview.chromium.org/742353004/

[annevk]

For .computedRole I don't really get why that's not folded into .role. It doesn't really seem worth it to have a distinct getter.

[Alexander Surkov]

Hi, Alice. I can see two large use cases that the approach of DOM extensions doesn't cover. This is automatic accessibility testing of the web content, to make it happen you have to have similar API that assistive technologies have. The second one is assistive technologies themselves, either web page hosted or in form of browser add-ons like ChromeVox. Thus I support the idea of separate accessibility API for the web in place of DOM extensions approach. Having two similar technologies same time probably is source of confusion and misuse.

Btw, in case of Firefox computedX implementation must be a bit more tricky as we don't currently have a way to shutdown accessibility engine once it was started.

Thank you.

Alexander.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAMQHGLz4GBkEZLK1JH9Sf7XtQxVrnvVe0c_2uU6SGGdYW2GczQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Dominic Mazzoni]

On Fri, Mar 13, 2015 at 2:35 AM, annevk <ann...@annevk.nl> wrote:

For .computedRole I don't really get why that's not folded into .role. It doesn't really seem worth it to have a distinct getter.

Because computedRole is not the same as role, just like getComputedStyle is not the same as style?

computedRole tells you (1) the role mapping of an html element, and (2) whether or not a role you specified was actually recognized by the browser.

On Fri, Mar 13, 2015 at 8:02 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

Hi, Alice. I can see two large use cases that the approach of DOM extensions doesn't cover. This is automatic accessibility testing of the web content, to make it happen you have to have similar API that assistive technologies have. The second one is assistive technologies themselves, either web page hosted or in form of browser add-ons like ChromeVox. Thus I support the idea of separate accessibility API for the web in place of DOM extensions approach. Having two similar technologies same time probably is source of confusion and misuse.

A separate API for assistive technology development and cross-platform accessibility testing sounds great, but I'm not convinced that just because we want those, we can't have any support for DOM accessibility APIs.

What about feature detection, though? As ARIA continues to grow, I think it'd be great if an app could write logic of the form: if the browser supports this ARIA role, I want to implement accessibility this way, but if not, I'll fall back on a simpler approach. It's such a common technique for almost everything else in HTML5, I think it'd be really useful for accessibility.

I think both of those are an argument in favor of just a few key accessibility attributes, not a complete API.

 

Btw, in case of Firefox computedX implementation must be a bit more tricky as we don't currently have a way to shutdown accessibility engine once it was started.

FWIW, that was a technical challenge we had to solve too. I think it was worth adding that support whether or not we ship this feature.

- Dominic

 

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CA%2BepNse9S8yucJcRBjt64%3DqURhWeeTFF8eogtsdP15g%2B1JapMg%40mail.gmail.com.

[David Bolter]

Aside:

On Fri, Mar 13, 2015 at 11:11 AM, 'Dominic Mazzoni' via Browser Accessibility

Btw, in case of Firefox computedX implementation must be a bit more tricky as we don't currently have a way to shutdown accessibility engine once it was started.

FWIW, that was a technical challenge we had to solve too. I think it was worth adding that support whether or not we ship this feature.

Agreed. For anyone interested the gecko bug is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=527003

Cheers,

D

[Alexander Surkov]

If we are both agree that we want web accessibility API then I'm still not sure I see the point of computedRole, because you can do something like

getElementById("myelm").accessibleElement.role;

which is equivalent to

getElementById("myelm").computedRole;

It's just matter of syntax.

Thanks.

Alex.

[Dominic Mazzoni]

On Fri, Mar 13, 2015 at 9:08 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

If we are both agree that we want web accessibility API then I'm still not sure I see the point of computedRole, because you can do something like

I'm not convinced I want a complete in-process web accessibility API, though. I'd say the #1 technical challenge of ChromeVox is dealing with iframes, and it's one of the main reasons we're moving away from running it inside each page. Many popular web apps make heavy use of iframes, and it doesn't make sense to create a new accessibility API that would be limited to one frame.

We've been working on a Chrome extension API to expose all of accessibility. I'd be delighted if we wanted to replace this with an open standard someday, but I think it should be something where a page (or app or extension) requests special permission to have accessibility access to all of your windows and tabs, and then it accesses their accessibility trees "out of process".

[Alexander Surkov]

If we had web accessibility API for "out of process" applications then it should be easy to have it for "in-process" apps too instead of providing a separate computedX API to them. I think people would want to create accessibility services integrated right into the web app, I recall I saw some similar stuff from aisquared, like tricky weby zooming technologies. In-process API may be restricted to the tab document making all iframe navigation seamless. If there's no cost of having in-process web a11y API then I would have it, people will find out how to use it.

[Dominic Mazzoni]

On Fri, Mar 13, 2015 at 9:48 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

If we had web accessibility API for "out of process" applications then it should be easy to have it for "in-process" apps too instead of providing a separate computedX API to them. I think people would want to create accessibility services integrated right into the web app, I recall I saw some similar stuff from aisquared, like tricky weby zooming technologies. In-process API may be restricted to the tab document making all iframe navigation seamless.

I'm okay with everything except that last sentence, because Chrome is moving towards having every iframe in a separate process.

I agree that if we had an out-of-process-capable accessibility API, we could provide some limited support for using it within the same security context (i.e. it could span some iframes but not all of them).

I'm just worried it will be years before we can finish something like that, while computedRole seems like low-hanging fruit. I'd just like to do both.

- Dominic

[Alexander Surkov]

On Fri, Mar 13, 2015 at 12:54 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

On Fri, Mar 13, 2015 at 9:48 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

If we had web accessibility API for "out of process" applications then it should be easy to have it for "in-process" apps too instead of providing a separate computedX API to them. I think people would want to create accessibility services integrated right into the web app, I recall I saw some similar stuff from aisquared, like tricky weby zooming technologies. In-process API may be restricted to the tab document making all iframe navigation seamless.

I'm okay with everything except that last sentence, because Chrome is moving towards having every iframe in a separate process.

ok, we have to deal with that somehow

 

I agree that if we had an out-of-process-capable accessibility API, we could provide some limited support for using it within the same security context (i.e. it could span some iframes but not all of them).

I'm just worried it will be years before we can finish something like that, while computedRole seems like low-hanging fruit. I'd just like to do both.

Both Chrome and Firefox has own APIs, they can serve as a good base for that new web API, so we don't start from scratch. In Mozilla we started sketching the web API already, no ready proposal yet but it's much more than nothing. Having you on board I don't think it should take years, it's rather about months.

[Eitan Isaacson]

On Mar 13, 2015 3:33 PM, "Alexander Surkov" <surkov.a...@gmail.com> wrote:
>
>
>
> On Fri, Mar 13, 2015 at 12:54 PM, Dominic Mazzoni <dmaz...@google.com> wrote:
>>
>> On Fri, Mar 13, 2015 at 9:48 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:
>>>
>>> If we had web accessibility API for "out of process" applications then it should be easy to have it for "in-process" apps too instead of providing a separate computedX API to them. I think people would want to create accessibility services integrated right into the web app, I recall I saw some similar stuff from aisquared, like tricky weby zooming technologies. In-process API may be restricted to the tab document making all iframe navigation seamless.
>>
>>
>> I'm okay with everything except that last sentence, because Chrome is moving towards having every iframe in a separate process.
>
>
> ok, we have to deal with that somehow
>  

Firefox as well. It's been like that in FxOS for a while.

~ sent from my tiny device

[Alice Boxhall]

On Fri, Mar 13, 2015 at 12:33 PM, Alexander Surkov <surkov.a...@gmail.com> wrote:

On Fri, Mar 13, 2015 at 12:54 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

On Fri, Mar 13, 2015 at 9:48 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

If we had web accessibility API for "out of process" applications then it should be easy to have it for "in-process" apps too instead of providing a separate computedX API to them. I think people would want to create accessibility services integrated right into the web app, I recall I saw some similar stuff from aisquared, like tricky weby zooming technologies. In-process API may be restricted to the tab document making all iframe navigation seamless.

I'm okay with everything except that last sentence, because Chrome is moving towards having every iframe in a separate process.

ok, we have to deal with that somehow

 

I agree that if we had an out-of-process-capable accessibility API, we could provide some limited support for using it within the same security context (i.e. it could span some iframes but not all of them).

I'm just worried it will be years before we can finish something like that, while computedRole seems like low-hanging fruit. I'd just like to do both.

Both Chrome and Firefox has own APIs, they can serve as a good base for that new web API, so we don't start from scratch. In Mozilla we started sketching the web API already, no ready proposal yet but it's much more than nothing. Having you on board I don't think it should take years, it's rather about months.

Are you able to share at least the vague shape of the sketch at this point? I'm definitely interested in the possibilities, but share Dominic's concerns about frame boundaries.

And I can definitely see wanting to avoid having separate APIs which do the same thing. However, I think there are some valid reasons to make an exception here:

- Having methods directly on the element mean the barrier to use will be much lower - it can be a quick check in console or an assert in a JavaScript test without needing to spin up anything else

- We can implement them in such a way that we don't need to compute and maintain the entire accessibility tree (this is what we've done in Chrome) but can keep the scope very local

- Role and Name apply to virtually every single visible element - this is true of very few other attributes (focusability is one which comes to mind, but that's trivial to compute with 100% certainty in JS)

 

 

- Dominic

On Fri, Mar 13, 2015 at 12:17 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

On Fri, Mar 13, 2015 at 9:08 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

If we are both agree that we want web accessibility API then I'm still not sure I see the point of computedRole, because you can do something like

I'm not convinced I want a complete in-process web accessibility API, though. I'd say the #1 technical challenge of ChromeVox is dealing with iframes, and it's one of the main reasons we're moving away from running it inside each page. Many popular web apps make heavy use of iframes, and it doesn't make sense to create a new accessibility API that would be limited to one frame.

We've been working on a Chrome extension API to expose all of accessibility. I'd be delighted if we wanted to replace this with an open standard someday, but I think it should be something where a page (or app or extension) requests special permission to have accessibility access to all of your windows and tabs, and then it accesses their accessibility trees "out of process".

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CA%2BepNsfypYc0Y2oXx1H2BogsV7eGopqUeTke0Rt-3J4boddw3A%40mail.gmail.com.

[David Bolter]

On Fri, Mar 13, 2015 at 3:41 PM, 'Alice Boxhall' via Browser Accessibility Development 

Both Chrome and Firefox has own APIs, they can serve as a good base for that new web API, so we don't start from scratch. In Mozilla we started sketching the web API already, no ready proposal yet but it's much more than nothing. Having you on board I don't think it should take years, it's rather about months.

Are you able to share at least the vague shape of the sketch at this point?

I'd like to see that too :)

Alexander, last we spoke about it my understanding was that it would be compatible with having computed accessibility properties on elements and provide a way to go (back and forth) from an element to an accessible subtree for the cases where you want/need accessibles where there are no corresponding elements, e.g. for certain complex canvas solutions?

I know you wanted to work it out a bit more before proposing...

Cheers,

D

[Alexander Surkov]

Hi, Alice.

On Fri, Mar 13, 2015 at 3:41 PM, 'Alice Boxhall' via Browser Accessibility Development <browser-acce...@googlegroups.com> wrote:

On Fri, Mar 13, 2015 at 12:33 PM, Alexander Surkov <surkov.a...@gmail.com> wrote:

On Fri, Mar 13, 2015 at 12:54 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

On Fri, Mar 13, 2015 at 9:48 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

If we had web accessibility API for "out of process" applications then it should be easy to have it for "in-process" apps too instead of providing a separate computedX API to them. I think people would want to create accessibility services integrated right into the web app, I recall I saw some similar stuff from aisquared, like tricky weby zooming technologies. In-process API may be restricted to the tab document making all iframe navigation seamless.

I'm okay with everything except that last sentence, because Chrome is moving towards having every iframe in a separate process.

ok, we have to deal with that somehow

 

I agree that if we had an out-of-process-capable accessibility API, we could provide some limited support for using it within the same security context (i.e. it could span some iframes but not all of them).

I'm just worried it will be years before we can finish something like that, while computedRole seems like low-hanging fruit. I'd just like to do both.

Both Chrome and Firefox has own APIs, they can serve as a good base for that new web API, so we don't start from scratch. In Mozilla we started sketching the web API already, no ready proposal yet but it's much more than nothing. Having you on board I don't think it should take years, it's rather about months.

Are you able to share at least the vague shape of the sketch at this point? I'm definitely interested in the possibilities, but share Dominic's concerns about frame boundaries.

Sure. Most of the work we do is public. Here it is https://wiki.mozilla.org/Accessibility/WebAccessibilityAPI. It contains two things: web accessibility API for AT and API to make web page accessible.

 

And I can definitely see wanting to avoid having separate APIs which do the same thing. However, I think there are some valid reasons to make an exception here:

- Having methods directly on the element mean the barrier to use will be much lower - it can be a quick check in console or an assert in a JavaScript test without needing to spin up anything else

- We can implement them in such a way that we don't need to compute and maintain the entire accessibility tree (this is what we've done in Chrome) but can keep the scope very local

A lower barrier I tend to consider as disadvantage, in Firefox it's pretty tough to implement it out of context of the accessible tree, for example, for cases like aria-labelledby pointing to whole subtrees. If you can do that in Chrome then I think you can make 2nd item for web a11y API too.

 

- Role and Name apply to virtually every single visible element - this is true of very few other attributes (focusability is one which comes to mind, but that's trivial to compute with 100% certainty in JS)

I think I missed the point.

 

 

 

- Dominic

On Fri, Mar 13, 2015 at 12:17 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

On Fri, Mar 13, 2015 at 9:08 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

If we are both agree that we want web accessibility API then I'm still not sure I see the point of computedRole, because you can do something like

I'm not convinced I want a complete in-process web accessibility API, though. I'd say the #1 technical challenge of ChromeVox is dealing with iframes, and it's one of the main reasons we're moving away from running it inside each page. Many popular web apps make heavy use of iframes, and it doesn't make sense to create a new accessibility API that would be limited to one frame.

We've been working on a Chrome extension API to expose all of accessibility. I'd be delighted if we wanted to replace this with an open standard someday, but I think it should be something where a page (or app or extension) requests special permission to have accessibility access to all of your windows and tabs, and then it accesses their accessibility trees "out of process".

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CA%2BepNsfypYc0Y2oXx1H2BogsV7eGopqUeTke0Rt-3J4boddw3A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAMQHGLxr9BiJp9HMiF3sUE-S-aAYPmio3eoisTeNGo_y77DY0g%40mail.gmail.com.

[Alexander Surkov]

yes

 

I know you wanted to work it out a bit more before proposing...

right but maybe it's time

Cheers,

D

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAEvucx8ydRDfnk_FOj5KT1MfF_NYuXP_6c4uLanoccadYNz1QQ%40mail.gmail.com.

[Anne van Kesteren]

On Fri, Mar 13, 2015 at 4:11 PM, 'Dominic Mazzoni' via Browser
Accessibility Development <browser-acce...@googlegroups.com>
wrote:

> On Fri, Mar 13, 2015 at 2:35 AM, annevk <ann...@annevk.nl> wrote:
>> For .computedRole I don't really get why that's not folded into .role. It
>> doesn't really seem worth it to have a distinct getter.
>
> Because computedRole is not the same as role, just like getComputedStyle is
> not the same as style?

I don't think you can contrast a single attribute with all of CSS. It
would be much better to contract role="" with e.g. type="" from
<input>.

> computedRole tells you (1) the role mapping of an html element, and (2)
> whether or not a role you specified was actually recognized by the browser.

Yes, <input>.type does much the same.


--
https://annevankesteren.nl/

[Dominic Mazzoni]

On Mon, Mar 16, 2015 at 12:43 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

Yes, <input>.type does much the same.

Ah, I see what you're getting at now. I'm open to considering that idea.

To make sure I understand correctly:

If you set the role attribute on an element, the JavaScript role property would only return the role that was parsed.

So: <div role="button"> would yield "button",

<div role="foobar"/> would yield the empty string, and

<div role="switch checkbox"/> would yield "switch" if the browser supports role=switch, and "checkbox" if it doesn't.

Going the other way: element.role = "button" would set the role attribute to "button",

element.role = "foobar" would clear the role attribute, and

element.role = "switch" would set the attribute to "switch" if the browser supports role=switch, and it would clear the role attribute if not.

Is that what you had in mind, Anne?

I think I'd be fine with that. I'm not sure what to do about computedName, but I admit I can't think of a use for that other than testing. Having a reflected role property is much more useful because it allows for feature detection.

- Dominic

[Anne van Kesteren]

On Mon, Mar 16, 2015 at 9:00 AM, Dominic Mazzoni <dmaz...@google.com> wrote:
> Is that what you had in mind, Anne?

Yes, pretty much.

I thought that maybe the setter should simply forward to
setAttribute(), so you could do things like

.role = "switch checkbox"
if .role == "switch" { ... } else { ... }

more easily. This is also what <input>.type does. E.g. setting .type
to "foobar" will get you <input type="foobar"> in the node tree, but
then getting .type will still return "text".

> I think I'd be fine with that. I'm not sure what to do about computedName,
> but I admit I can't think of a use for that other than testing. Having a
> reflected role property is much more useful because it allows for feature
> detection.

Perhaps a good first step would be to expose this to developer tools.
Then if there's usage and developers would like remote debugging of
the feature we can evaluate again whether it's worth adding.


--
https://annevankesteren.nl/