Comment 1 by benjaminhawkeslewis on 2008-08-22 09:30
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

Comment 2 by vtsaran (in reply to comment 1) on 2008-08-22 17:49
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?

Comment 3 by jteh on 2008-08-23 06:12
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.

Comment 4 by jteh on 2008-12-05 02:51
Has anyone managed to test this with a Firefox 3.1 nightly yet?

Comment 6 by vtsaran on 2009-05-25 17:28
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.

Comment 7 by jteh on 2009-05-26 00:22
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?
Changes:
Changed title from "NVDA does not always read off-screen content on web pages" to "Use accessible description for links when name is a non-breaking space"

Comment 8 by vtsaran on 2009-05-29 00:05
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.

Comment 10 by MarcoZ on 2009-05-29 06:24
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.

Comment 11 by jteh on 2009-06-15 08:55
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.
Changes:
Changed title from "Use accessible description for links when name is a non-breaking space" to "Use name instead of content for links when content is a non-breaking space"

Comment 12 by jteh on 2009-06-25 02:37
Fixed in new misc-deps; see r3019.
Changes:
State: closed

Comment 13 by vtsaran on 2009-07-12 00:12
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.
Changes:
State: reopened

Comment 14 by pvagner on 2009-07-12 06:54
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 .

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.

Comment 15 by jteh (in reply to comment 13) on 2009-07-13 02:10
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.

Comment 16 by jteh on 2011-02-22 08:12
Closing again as fixed as per comment:15 and no response from reporter. Fixed by 84a851a.
Changes:
Milestone changed from None to 2009.1
State: closed