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

Link destination anchors should not be treated as links #47

Closed
nvaccessAuto opened this Issue Jan 1, 2010 · 4 comments

Comments

Projects
None yet
1 participant
@nvaccessAuto
Copy link

nvaccessAuto commented Jan 1, 2010

Reported by jteh on 2008-03-18 22:39
In HTML, there are two uses for the tag:

  1. The HREF attribute refers to a destination so that when the link is activated, the browser will jump to that destination.
  2. The NAME attribute creates a link destination which can be referenced elsewhere.
    When there is no HREF attribute, the element is not a link (i.e. it does not jump to another destination).

Unfortunately, Firefox exposes A elements without an HREF attribute as links to accessibility APIs. Imho, this is a bug in Firefox; see MozillaBug:423603. However, this has been done for a long time and IE apparently does it as well, so fixing the issue in Firefox may cause breakage. Thus, the change needs to be made in the NVDA gecko_ia2 backend.

Two methods can be used to determine whether there is no HREF attribute:

  • The link object will not have the linked state set.
  • The accessible value will be empty.
    Either of these methods can be used. If no HREF is detected, the backend should ignore the link object (but still render everything below).
@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

Comment 1 by benjaminhawkeslewis on 2008-03-19 07:16
If no HREF is detected, the backend should ignore the link object (but still render everything below).

I'm not 100% clear what this suggestion entails. It might prove problematic if anchor elements are not announced at all, since even if an anchor has no HREF it might still have behaviour attached with scripting.

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

Comment 2 by jteh (in reply to comment 1) on 2008-03-19 13:03
Replying to benjaminhawkeslewis:

I'm not 100% clear what this suggestion entails. It might prove problematic if anchor elements are not announced at all, since even if an anchor has no HREF it might still have behaviour attached with scripting.

True, but this is also true for spans, divs, etc. Basically, we will treat anchors without an HREF attribute as if they were spans. Clickables are currently not announced, but once they are, this will work for named anchors as well with no additional change.

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

Comment 3 by jteh on 2008-03-20 02:38
On further reflection, although it is a little confusing, it does make sense for named linked destinations to be exposed to accessibility APIs. As a screen reader, we don't want to report these as links to the user, but it might be useful for jumping to places of interest on a page, as these are often marked by named linked destinations/anchors. To allow for this functionality in future if it is desired, I have modified NVDA to simply not report these as links, rather than losing this information in the backend. Committed in r1846.
Changes:
State: closed

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

Comment 4 by jteh on 2008-03-26 08:52
Oops. Thought I had committed when i hadn't. Correct revision is r1858.

@nvaccessAuto nvaccessAuto added this to the 2009.1 milestone Nov 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.