298572 - Missing acc. name for XUL label and description tags

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[parente]

XUL description and label tags do not report their values in the accessible name 
field. Current code is flattening subtree (which works for HTML) but needs to 
read value attr for XUL.

Attaching patch momentarily.

Comment 1

[parente]

Attachment: Reads value attr instead of flattening subtree

Bug 280065 dependent on this fix

Comment 2

[Aaron Leventhal]

We better make sure this doesn't make Window-Eyes speak each label twice, since
a <label control="foo-id"> will already expose its text in the accName of the
control it points to.

Pete, contact me and I'll show you how to get a copy of Window-Eyes if you don't
already have one.

Comment 3

[Aaron Leventhal]

Comment on attachment 187122 [details] [diff] [review]
Reads value attr instead of flattening subtree

r=aaronlev assuming you test and make sure that labels don't get spoken twice
in xul dialogs as you tab through.

Comment 4

[parente]

How do I make WindowEyes speak a XUL label? It's not focusable so tabbing to it 
won't work. What are the nav keys for exploring a window?

The patch needs to change anyways. XUL labels have their text in the value 
attribute, but XUL descriptions have text between start and end tags. The 
XULTextAccessible should either check the tag atom or, instead of type checking, 
check for a value attribute first, try to get text from there, and fallback on 
the inner text.

Comment 5

[parente]

You can ask WindowEyes to read an entire window by pressing Ctrl-Shift-W. Doing 
this in the Preferences dialog where there are a number of labels works 
correctly. No labels are repeated.

(In reply to comment #3)
> (From update of attachment 187122 [details] [diff] [review] [edit])
> r=aaronlev assuming you test and make sure that labels don't get spoken twice
> in xul dialogs as you tab through.
> 

Comment 6

[Aaron Leventhal]

Comment on attachment 187122 [details] [diff] [review]
Reads value attr instead of flattening subtree

Actually a <description> can have rich subcontent rather than using the value
attribute. I'm not sure if <label> can do that.

So, you have to check to see if the value attribute was empty first. 

You can use the return values from content->GetAttr() to see if what it
returned was empty.

If still empty, then do the AppendFlatStringFromSubTree as we used to.

I think we don't need the QI to nsIDOMXULDescriptionElement any more, but you
would still need to see if mDOMNode is null.

Comment 7

[parente]

Attachment: Returns value if exists else inner content

Comment 8

[Aaron Leventhal]

Comment on attachment 187207 [details] [diff] [review]
Returns value if exists else inner content

Fix the indent on the these lines:
+  if (!content) {
   return NS_ERROR_FAILURE;
 }

Comment 9

[parente]

Attachment: Fixes indent nit

Weird. Indent is correct in source but comes out wrong in the diff. No tabs
detected. Hmm.

Comment 10

[parente]

Attachment: Fixes indent nit

Found another indent problem.

Comment 11

[Mike Kaply [:mkaply]]

Comment on attachment 187222 [details] [diff] [review]
Fixes indent nit

a=mkaply

Comment 12

[Aaron Leventhal]

Thanks Peter.

Checking in nsXULTextAccessible.cpp;
/cvsroot/mozilla/accessible/src/xul/nsXULTextAccessible.cpp,v  <-- 
nsXULTextAccessible.cpp
new revision: 1.13; previous revision: 1.12
done

Comment 13

[Aaron Leventhal]

This wasn't supposed to get checked in while they prepare the beta.

Will check in tomorrow or asap.

Comment 14

[Aaron Leventhal]

Checking in accessible/src/xul/nsXULTextAccessible.cpp;
/cvsroot/mozilla/accessible/src/xul/nsXULTextAccessible.cpp,v  <-- 
nsXULTextAccessible.cpp
new revision: 1.15; previous revision: 1.14
done

Comment 15

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381