438325 - Link with title and an image that has neither alt nor title doesn't get an accessible name.

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

On www.musicload.de, there are links that have a title attribute, and an embedded image. However, that embedded image has neither an alt nor a title attribute. In this case, we do not honour the link's title. The link accessible does not receive a name.

I believe that, if no "on-screen" name is preseent, we should fallback to using the title attribute, if supplied along with the html:a tag.

The priorities should be:
1. If a link has screen text, use it.
2. If it has an image, use the logic we have (alt and title of the html:img tag).
3. If the above are not present, and the html:a tag has a title, use that for an accessible name.

Comment 1

[Marco Zehe (:MarcoZ)]

Attachment: Simple testcase

Comment 2

[Marco Zehe (:MarcoZ)]

Attachment: Patch

If the children don't return an accessible, try the title attribute of the html:a tag.
Note that I don't check whether the call to content->getAttr actually returns true or false, since the result will be the same if there's no title: An empty string, so this test would be superflous, since there's no other course of action anyway.

Comment 3

[Marco Zehe (:MarcoZ)]

Attachment: Patch with Mochitest

Comment 4

[alexander :surkov (:asurkov)]

1) XUL label tries to get "value" attribute and then name from children. I think xul and html labels should have similar algorithm
2) Should we try to get the name like we do usually? because we ignore ARIA for example in this case, right?

Comment 5

[Marco Zehe (:MarcoZ)]

(In reply to comment #4)
> 1) XUL label tries to get "value" attribute and then name from children. I
> think xul and html labels should have similar algorithm

No, because the value for links contains the URL, we wouldn't want that as the name as the first try.

> 2) Should we try to get the name like we do usually? because we ignore ARIA for
> example in this case, right?

The ARIA link test still passes, so I am not sure what you're getting at here.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to comment #5)
> (In reply to comment #4)
> > 1) XUL label tries to get "value" attribute and then name from children. I
> > think xul and html labels should have similar algorithm
> 
> No, because the value for links contains the URL, we wouldn't want that as the
> name as the first try.

So I guess we should fix it for xul label, right?

> > 2) Should we try to get the name like we do usually? because we ignore ARIA for
> > example in this case, right?
> 
> The ARIA link test still passes, so I am not sure what you're getting at here.
> 

Do we have tests you describe in the bug (replace title attribute on ARIA equivalent)?

Comment 7

[Marco Zehe (:MarcoZ)]

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > 1) XUL label tries to get "value" attribute and then name from children. I
> > > think xul and html labels should have similar algorithm
> > No, because the value for links contains the URL, we wouldn't want that as the
> > name as the first try.
> So I guess we should fix it for xul label, right?

I don't think so. With XUL:label elements, the value attribute usually contains the screen text/caption. Or, this text is enclosed within opening and closing XUL:label tags. XUL:label tags don't have a title attribute, so this bug does not apply to them.

> > > 2) Should we try to get the name like we do usually? because we ignore ARIA for
> > > example in this case, right?
> > The ARIA link test still passes, so I am not sure what you're getting at here.
> Do we have tests you describe in the bug (replace title attribute on ARIA
> equivalent)?

Do you mean a div whose role is "link" and which has a title?

Comment 8

[alexander :surkov (:asurkov)]

(In reply to comment #7)

> Do you mean a div whose role is "link" and which has a title?
> 

I think of 

<span id="label">hello</span>
<a id="LinkWithTitleAndProperImage" href="http://www.mozilla.org"
    aria-labelledby="label"><img src="moz.png" alt="MoFo home yet again"/></a>

Comment 9

[Marco Zehe (:MarcoZ)]

(In reply to comment #8)
> I think of 
> 
> <span id="label">hello</span>
> <a id="LinkWithTitleAndProperImage" href="http://www.mozilla.org"
>     aria-labelledby="label"><img src="moz.png" alt="MoFo home yet again"/></a>

Yes, in all cases the image's info, or an empty string, is used, aria-labelledby does currently not work on links. However I believe this should be dealt with in a separate bug, agreed?

Comment 10

[alexander :surkov (:asurkov)]

(In reply to comment #9)
> (In reply to comment #8)
> > I think of 
> > 
> > <span id="label">hello</span>
> > <a id="LinkWithTitleAndProperImage" href="http://www.mozilla.org"
> >     aria-labelledby="label"><img src="moz.png" alt="MoFo home yet again"/></a>
> 
> Yes, in all cases the image's info, or an empty string, is used,
> aria-labelledby does currently not work on links. However I believe this should
> be dealt with in a separate bug, agreed?
> 

Marco, does nsHyperTextAccessible::GetName() helps here?

Comment 11

[Marco Zehe (:MarcoZ)]

(In reply to comment #10)
> Marco, does nsHyperTextAccessible::GetName() helps here?
No, it simply appends the text it has to anything that might be before it. How should it help?

Comment 13

[alexander :surkov (:asurkov)]

(In reply to comment #11)
> (In reply to comment #10)
> > Marco, does nsHyperTextAccessible::GetName() helps here?
> No, it simply appends the text it has to anything that might be before it. How
> should it help?
> 

Not sure I followed you. Actually I meant to call something like

AppendFlatStringFromSubtree()
GetHTMLName(label, false)

Comment 14

[Marco Zehe (:MarcoZ)]

(In reply to comment #13)
> Not sure I followed you. Actually I meant to call something like
> 
> AppendFlatStringFromSubtree()
> GetHTMLName(label, false)

Where? Can you put this idea into a patch? I am not sure I understand what you're trying to do.

Comment 15

[alexander :surkov (:asurkov)]

Attachment: patch3

Comment 16

[Marco Zehe (:MarcoZ)]

Comment on attachment 325936 [details] [diff] [review]
patch3

r=me with the two other testcases added, as discussed over IRC:

1. A link with onscreen text and title, where onscreen text is accessible name.
2. A link with an image. Image has alt, link has title. accessible name is text of image's alt attribute.

Comment 17

[alexander :surkov (:asurkov)]

Attachment: patch4

with Marco's comments

Comment 18

[Marco Zehe (:MarcoZ)]

Comment on attachment 325953 [details] [diff] [review]
patch4

Thanks!

Comment 19

[alexander :surkov (:asurkov)]

checked in on mozilla-central

Comment 20

[Marco Zehe (:MarcoZ)]

Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008062603 Minefield/3.1a1pre. Now JAWS must just stop its extra processing and expose the name that we give it, but other screen readers are fine now.