Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
nvaccessAuto opened this issue Jan 1, 2010 · 14 comments

Comments

@nvaccessAuto
Copy link

Reported by vtsaran on 2008-08-20 18:19
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.
@nvaccessAuto
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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?

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

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"

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

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"

@nvaccessAuto
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

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.

@nvaccessAuto
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant