Use name instead of content for links when content is a non-breaking space

[vtsaran]

NVDA does not always read off-screen content on web pages.
To repro:

1. Go to mail.yahoo.com and login with your username/passwd.
2. If you are not automatically transfered to the classic version, click on the "Classic Mail" link at the top of the page.
3. Display the list of messages in your inbox by either choosing "check mail" or pressing ALT+SHIFT+2 if using Firefox.
4. Right underneath the checkbox that allows the user to select a message there is a link that allows to either flag the message or clear the flag for a previously-flagged message.

This link has an off-screen text that either says "flag this message" or "clear the flag".
NVDA totally ignores this text where other screen readers don't.

[benjaminhawkeslewis]

As far as I can tell this is not text positioned off-screen with CSS, but rather a TITLE attribute on an empty A element with HREF (the visible content being provided, to some users, with background-image). Here's the DOM extracted from Firebug:

<a 
title="Flag this message" 
href="showFolder;_ylt=AokEn5N8GtV6E5E3hSQVG8bGAL4X?fid=Inbox&amp;sort=date&amp;order=down&amp;startMid=0&amp;.rand=1040505845&amp;da=0&amp;mid=1_1423_AEbPjkQAAN8wR5ZU1w8DpDKw%2Bsg&amp;mcrumb=zI1g7MGph9F&amp;flag=1"
class="greyed"> </a>

The reliance on background-image and the omission of link text are both authoring errors.

In terms of how to handle these errors, I'd suggest that as this A element has an HREF and is likely a control, either Gecko or NVDA should use the TITLE attribute to repair the A element's missing link text.

Compare:

 http://www.w3.org/TR/UAAG10-TECHS/topics.html#link-techniques

[vtsaran]

Replying to benjaminhawkeslewis:

As far as I can tell this is not text positioned off-screen with CSS, but rather a TITLE attribute on an empty A element with HREF (the visible content being provided, to some users, with background-image). Here's the DOM extracted from Firebug:

Yes, this is correct. Confirmed.
In view of the circumstances, a work-around still needs to be found. A feature request, perhaps?

[jteh]

Does NVDA detect that there is a link present and just say "link"? If so, please try this with a Firefox 3.1 nightly if you haven't already. If I remember correctly, there was a fix included in Firefox 3.1 to use the title attribute for the link name when no content was provided.

[jteh]

Has anyone managed to test this with a Firefox 3.1 nightly yet?

[vtsaran]

Just tested this with beta4 of Firefox 3.5 and the problem is still there, i.e NVDA reads the link but not the hidden text of the link.

[jteh]

Firefox 3.5 does expose the title as the accessible name if there is no content for a link. However, the problem here is that there *is* content; a non-breaking space ( ). We could try to hack around this in NVDA, but it really is an authoring bug. We could file a bug against Mozilla to take this into account or hack around it in NVDA, but maybe there is a case where a non-breaking space is intentionally used to produce a whitespace only link.

Note that if we hack around this in NVDA, it won't fix tabbing to the link; there is no accessible name, so it will be reported as such.

Also, the link is inside an ARIA checkbox. Is the checkbox the point of interest or the link?

[vtsaran]

I guess, we are interested in both the checkbox and the link (for backward compatibility).
We should probably be talking to Mozilla about this since I am not sure that   can be considered to be a content.

[MarcoZ]

I've filed  MozillaBug:495390 for discussion on this issue. It's not a bug per se, in that our algorithm works correctly. This would be a special case to shield users from these questionable design choices.

[jteh]

 MozillaBug:495390 is now fixed. However, this still doesn't solve the problem for NVDA, as we render the content for links instead of the name.

It's difficult to know when we should render the content and when we should render the name. We render the content so that we include information about objects inside the link; e.g. graphics. However, when aria-name or aria-labelledby is used, we really should use the name. One possible solution might be to always use the name if there are no children.

[jteh]

Fixed in new misc-deps; see r3019.

[vtsaran]

I think the issue is fixed as far as tabbing and shift+tabbing is concerned. However, NVDA still does not render the TITLE of the link into the virtual buffer. For example, when navigating through checkboxes with quicknav keys, NVDA only speaks "checkbox link". Alternatively, when tabbing to the checkbox, NVDA announces the title of the link.

[pvagner]

I am not sure this still belongs to this ticket but I have found another strange case NVDA does not render.
When link text is nested inside a span.
To reproduce:
1) go to the  http://identi.ca/jteh
2) Navigate to the second heading level 2 saying "SUBSCRIPTIONS"
3) Examine link or links inside the list below this heading.

Current result:
NVDA report these links as empty text.

Expected result:
NVDA should render title or a text of the link eventhough it is nested in a <span>.

Note:
It may be more difficult to work out what to do in such a situation because there is also an image inside the link.

[jteh]

Replying to vtsaran:

NVDA still does not render the TITLE of the link into the virtual buffer. For example, when navigating through checkboxes with quicknav keys, NVDA only speaks "checkbox link".

Are you running an NVDA snapshot after r3019 and a Firefox 3.6pre build? I hear "Flag this message link" when I navigate between links in the buffer. The "Flag this message" text is the title of the link.

I do notice that the checkbox (which is the parent of the link) has a name of "Clear flag", which NVDA does not render into the buffer. This doesn't make any sense to me; you have an unchecked checkbox named "Clear flag" containing a link named "Flag this message". We have to decide which content to render for that control and the link wins. If they were separate controls, they would be rendered separately, but the checkbox has children, so we assume the children will contain useful content.

[jteh]

Closing again as fixed as per comment:15 and no response from reporter. Fixed by changeset:main,0.1.125.