637578 - Expose how accessible name was determined

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

NVDA generally renders the content of elements in its representation of a document. This allows it to provide the most detailed and accurate information, including semantic information about descendant elements (e.g. that a link is a graphic link) and text formatting information. (Text formatting isn't currently supported for Gecko documents, but this is planned.) However, there are times when authors override the name of an element because the content isn't useful. In these cases, NVDA should render the name instead of the content.

The name of a Gecko accessible object can be determined from several different sources:
1. from the content of the element; e.g. <a href="#">name</a>.
2. from attributes; e.g. <a href="#" title="name">&nbsp;</a> or <a href="#" aria-label="name">content</a>.
3. from content outside of the node; e.g. <div id="label">name</div><div role="radio" aria-labelledby="label">content</div>.

NVDA (and potentially other ATs that don't use ISimpleDom) needs to know how the name was determined so it can decide whether to render the name (for cases 2 and 3) instead of the content (for case 1).

This could be done via an object attribute. One possibility is nameFromInnerContent:true or nameInContent:true. Another possibility is nameIsVisible:true, since if the name is visible, it should be in content. Neither of these exposes all three possibilities; I can't think of a good way to do so that isn't very XML specific (and thus a bad fit for accessibility standards). I'm also not sure if cases 2 and 3 need to be treated separately or not.

A more drastic measure would be to change the content provided via accessibility APIs for elements where the name is overridden. However, this is probably a much bigger job and has the potential to cause major regressions/compatibility breaks.

Comment 1

[James Teh [:Jamie]]

This is blocking proper support for aria-label in NVDA and is a common complaint.

This has been discussed in the IA2 working group and is covered by this proposal: https://wiki.mozilla.org/Accessibility/IA2_1.3#Explicit_name_.5BYELLOW.5D

As I explained here:
http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2011-July/001509.html
I prefer the flag rather than a separate name property. Today, I've also queried as to why this can't simply be another object attribute rather than a new method. This would have the added benefit of allowing us to use it before IA2 1.3 is released.

If others agree that this is okay, it'd be good to get this implemented sooner rather than later.

Comment 2

[James Teh [:Jamie]]

Btw, if we used an object attribute, it would be explicitName:true.

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

Fine with me. Alex?

Comment 4

[James Teh [:Jamie]]

Actually, I was incorrect. The last post of importance was:
http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2011-July/001515.html
Here, it was suggested that the method be called isNamePreferred and that it be part of the IAccessibleText interface. I guess this makes sense, though an object attribute would probably serve just as well. IA2 discussion ongoing.

Comment 5

[James Teh [:Jamie]]

It looks like we've settled on an object attribute named explicit-name.

Comment 6

[alexander :surkov (:asurkov)]

It should make the attribute getting slower on name calculation. Would it be reasonable to wait for new API and expose it via it only? So that if you do a classic way of attribute getting then you don't see that attribute.

Comment 7

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #6)
> It should make the attribute getting slower on name calculation.
Out of curiosity, why is this? I understand that you obviously don't want to calculate the name when fetching attributes, but for something like aria-label, I would have thought this would be pretty fast to check for. That said, I guess the title attribute isn't as simple, since you don't know whether you'll use it.

> Would it be
> reasonable to wait for new API and expose it via it only? So that if you do
> a classic way of attribute getting then you don't see that attribute.
I guess this is fine if it has a real perf impact. NVDA's virtual buffer backend fetches all attributes at once, but we can add an extra call easily enough. It needs to be clearly documented somewhere, though.

Comment 8

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #7)
> (In reply to alexander :surkov from comment #6)
> > It should make the attribute getting slower on name calculation.
> Out of curiosity, why is this? I understand that you obviously don't want to
> calculate the name when fetching attributes, but for something like
> aria-label, I would have thought this would be pretty fast to check for.
> That said, I guess the title attribute isn't as simple, since you don't know
> whether you'll use it.

before you do next step in name calculation you should ensure the previous step returns an empty string. If you have like
<input id="input"><label for="input">it's a label</label> then we go into label subtree to get a text and check if it's empty. If we reached "name from subtree" item then we need to calculate to see if it's empty to fallback into tooltips. We could do different optimizations but formally we need to do complete algorithm.

> > Would it be
> > reasonable to wait for new API and expose it via it only? So that if you do
> > a classic way of attribute getting then you don't see that attribute.
> I guess this is fine if it has a real perf impact. NVDA's virtual buffer
> backend fetches all attributes at once, but we can add an extra call easily
> enough. It needs to be clearly documented somewhere, though.

Yes. Do you recall if new API has an option to get all attributes or subset of attributes?

Comment 9

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #8)
> <input id="input"><label for="input">it's a label</label>
Inputs are a case I hadn't considered. If I'm not missing something, explicit-name should always be true there, as Gecko never tries to calculate the name for an input except from author supplied labels.(It's also not useful for screen readers, as we always render content for inputs anyway, even if they do have a label.) In contrast, links might derive their name from content.

Comment 10

[alexander :surkov (:asurkov)]

True, or consider a button instead input. Of course we'll do a check whether the role allows the name from subtree but it's optimization I told about.

Comment 11

[alexander :surkov (:asurkov)]

Attachment: patch

there's no many accessible having name from subtree rule so it shouldn't hit us too bad

Comment 12

[Trevor Saunders (:tbsaunde)]

Comment on attachment 670318 [details] [diff] [review]
patch

>@@ -1123,32 +1124,33 @@ Accessible::GetXULName(nsString& aName)
>           AppendTextEquivFromContent(this, labelAcc->GetContent(), &aName);
>       }
>     }
>   }
> 
>   // XXX If CompressWhiteSpace worked on nsAString we could avoid a copy
>   aName.CompressWhitespace();

sounds comment is out of date, remove it?

>+  // No accessible name but empty 'alt' attribute is present. If further name
>+  // computation algorithm doesn't provide non empty name then it means
>+  // an empty 'alt' attribute was used to indicate a decorative image (see
>+  // nsIAccessible::name attribute for details).

can we please point at something other than xpcom interfaces for explanation of internal apis?

>-  // No name from HTML or ARIA
>-  if (!mContent->GetAttr(kNameSpaceID_None, nsGkAtoms::value, aName) &&
>-      !mContent->GetAttr(kNameSpaceID_None, nsGkAtoms::alt, aName)) {
>+  // Note: No need to check @value attribute since it results in anonymous text
>+  // node. The name is calculated from subtree in this case.
>+  if (!mContent->GetAttr(kNameSpaceID_None, nsGkAtoms::alt, aName)) {

any good reason to make this change now?  It seems like a pretty unrelated behavior change, so why not put it in own bug?

>diff --git a/accessible/tests/mochitest/name/markup.js b/accessible/tests/mochitest/name/markup.js
>--- a/accessible/tests/mochitest/name/markup.js

David thinks he canrise above a mortal and understand this stuff, and volunteered to review these tests so r? him for that

>+++ b/accessible/tests

Comment 13

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #11)
> Created attachment 670318 [details] [diff] [review]
> patch
> 
> there's no many accessible having name from subtree rule so it shouldn't hit
> us too bad

I didn't look at which roles they were, so I'm not sure how frequentthe accessibles themselves are, but I found 33 occurencies of eFromSubtree in RoleMap.h and 42 if you also count eFromSubtreeIfRec out of a total of ~130 roles which is about 1/4

Comment 14

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #12)

> >-  if (!mContent->GetAttr(kNameSpaceID_None, nsGkAtoms::value, aName) &&
> >-      !mContent->GetAttr(kNameSpaceID_None, nsGkAtoms::alt, aName)) {
> >+  // Note: No need to check @value attribute since it results in anonymous text
> >+  // node. The name is calculated from subtree in this case.
> >+  if (!mContent->GetAttr(kNameSpaceID_None, nsGkAtoms::alt, aName)) {
> 
> any good reason to make this change now?  It seems like a pretty unrelated
> behavior change, so why not put it in own bug?

it doesn't change behavior, we con consider this as clean up. new bug for non behavioral thing I would avoid that.


(In reply to Trevor Saunders (:tbsaunde) from comment #13)

> I didn't look at which roles they were, so I'm not sure how frequentthe
> accessibles themselves are, but I found 33 occurencies of eFromSubtree in
> RoleMap.h and 42 if you also count eFromSubtreeIfRec out of a total of ~130
> roles which is about 1/4

eFromSubtreeIfRec don't count. The web page is 90% consist of things like divs and paragraphs that are eFromSubtreeIfRec.

Comment 15

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 670318 [details] [diff] [review]
patch

The test changes look straight forward to me. Interesting as well.

Comment 16

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #14)
> (In reply to Trevor Saunders (:tbsaunde) from comment #12)
> 
> > >-  if (!mContent->GetAttr(kNameSpaceID_None, nsGkAtoms::value, aName) &&
> > >-      !mContent->GetAttr(kNameSpaceID_None, nsGkAtoms::alt, aName)) {
> > >+  // Note: No need to check @value attribute since it results in anonymous text
> > >+  // node. The name is calculated from subtree in this case.
> > >+  if (!mContent->GetAttr(kNameSpaceID_None, nsGkAtoms::alt, aName)) {
> > 
> > any good reason to make this change now?  It seems like a pretty unrelated
> > behavior change, so why not put it in own bug?
> 
> it doesn't change behavior, we con consider this as clean up. new bug for
> non behavioral thing I would avoid that.

oh, I was willing to go dollars to doughnuts there was an ordering change here, but I was wrong.

> (In reply to Trevor Saunders (:tbsaunde) from comment #13)
> 
> > I didn't look at which roles they were, so I'm not sure how frequentthe
> > accessibles themselves are, but I found 33 occurencies of eFromSubtree in
> > RoleMap.h and 42 if you also count eFromSubtreeIfRec out of a total of ~130
> > roles which is about 1/4
> 
> eFromSubtreeIfRec don't count. The web page is 90% consist of things like
> divs and paragraphs that are eFromSubtreeIfRec.

yeah, probably / hopefully

Comment 17

[alexander :surkov (:asurkov)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/77181a4ff1b8

Comment 18

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/77181a4ff1b8

Comment 19

[James Teh [:Jamie]]

Many thanks!

We seem to be getting explicit-name:true for something like <div>Blah</div> which has no name. Is this intentional?

Comment 20

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #19)
> Many thanks!

yw :)
 
> We seem to be getting explicit-name:true for something like <div>Blah</div>
> which has no name. Is this intentional?

It wasn't intentional I think. So would it be reasonable if we expose explicit-name:true when no name iff it was left empty intentionally like <img alt="">?

Comment 21

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #20)
> So would it be reasonable if we expose
> explicit-name:true when no name iff it was left empty intentionally like
> <img alt="">?
Yes.

Comment 22

[alexander :surkov (:asurkov)]

I filed bug 805373