Open Bug 112393 Opened 23 years ago Updated 2 years ago

How will keyboard users access Anchors that don't have a URI?


(Core :: DOM: Core & HTML, defect, P4)






(Reporter: jay, Unassigned)


(Blocks 1 open bug, )


(Keywords: access, topembed-, Whiteboard: DUPEME)


(3 files, 1 obsolete file)

The example shows the case where: 
mouse users can click on 3 anchors in the page.
keyboard users can only activate 2 anchors.

tabIndex and IMG will also need to be considered
There must be a better reference, I cannot find it right now.
I didn't understand this until viewing the source of the example.

The first two "anchors" are HTML "href" attributes of an "a" tag.

The third, however, uses:

  <a tabindex="1" onclick=alert("OK")>

I'm sure this is a dup but I couldn't find it. It was about whether we should
fire onclick when hitting enter on an anchor.
CC'ing aaronl since it's about accessibility, maybe he remembers it.
It's not just onclick, it is event handling,, ie onfocus...
I can't find a dupe, but I really thought there was one.

What the W3C recommends here is really overkill - that a user be able to fire an
event by selecting from a list of all the event handlers for a given element.

I think Fabian's suggestion in comment #2 is not a bad real-world solution -
fire the onclick handler when enter is pressed.

However, looking at IE - I see that they allow you to focus there, but enter
doesn't fire the onclick handler. Strange - that doesn't seem right either.
Perhaps they goofed there.
Whiteboard: DUPEME
Fireing onclick when hitting enter on a link is just wrong, we can't do that. If
the page designers want their pages to work for people who are not able to use
the keyboard, they can do that by listening to more than one type of event, or
by using javascript: URL's in their links. It's not the browsers job to do
illogical things to work around what site developlers explicitely code up on
their pages. Marking WONTFIX.
Closed: 23 years ago
Resolution: --- → WONTFIX
JS wrote:
If the page designers want their pages to work for people who are not able to use
the keyboard,

this bug is about enabling keyboard users, the coding may not be the most
logical, but demonstrates that keboard users are currently excluded rather than
people who cannto use the keyboard.

if I've misunderstood please elaborate.
Resolution: WONTFIX → ---
If the site uses "onclick='...'" they're explicitly saying, do '...' when a user
*clicks* on this link, or whatever the node is. If the site wants to be
accessible to people who are not using a mouse, then they should *not* rely on
events such as onclick and onmouse*, there are other options (for onclick at least).

Closed: 23 years ago23 years ago
Resolution: --- → WONTFIX
My clients/students have mental health problems, and/or learning difficulties,
and or challenging behaviour.
Many cannot use a mouse effectively(possibly due to medication) however tabbing
and a wheel are effective.
Others will have different input requirements.

I've added a few more links that should give a flavour of the reasons why we
need to enable this bug.

these only work in ie6, in no case is the desired action a change of location.
It is important that keyboard users have access to these types of interaction. 
How does IE6 deal with this?
Seems like I've missed the point here (as Jonathan pointed out in private
email), re-opening. How does IE6 deal with anchors with no href wrt tabbing?
Resolution: WONTFIX → ---
can someone please explain why you guys don't go out and sue all of the web 
authors for designing inaccessible sites? (said a user who hates the onclick 
in IE6 with win'98

tabbing works for

Anchor + URI
Anchor + tabindex
IMG + tabindex

but not

onmousewheel events seem to be compromised for some situations see
bug 111647 the first example given.
at users may have very particular requirements regarding I/O, and interfaces
need to be as flexible as is reasonable.

apologies for confusion caused by using onclick.
Confirming, tabbing to an anchor that has a tabindex should work whether or not
the anchor has a href. Over to bryner, who I've believe has worked on tabbing
issues before.
Assignee: jst → bryner
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
-> 1.0, nominating for beta1.
Keywords: nsbeta1
Target Milestone: --- → mozilla1.0
What about allowing anything with an onclick to be in the tab order, so that
Enter can activate the element?
My bad, I realize my last question was already discussed. Anyway, I still think
people should be able to tab to anything with an onclick handler and hit Enter
on it to fire the click -- why is that "just wrong"? Where does it say that we
can't simulate a mouse click with the keyboard?
changing priority to P4
Priority: -- → P4
Keywords: topembed
nsbeta1+ per Nav triage team
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2
nsbeta1- per ADT triage team
Blocks: uaag
topembed- per EDT triage.  Aaron, let us know if this is the wrong decision.
Keywords: topembedtopembed-
You made the right decision. This is a deeper issue that other browsers don't
always handle correctly either. We'll revisit this at some later point.
onclick is evil for keyboard users. We're supposed to know this, but we make
this very mistake in our own XUL.

In the element properties windows (metadata.xul), we use we use <label
class="text-link" onclick="blah"> instead of <html:a> 

This makes it so keyboard users cannot tab to the items in an element properties
window (bug 121114).

Is there any good reason that keyboard users shouldn't be able to tab to items
with onclick, and fire them with enter?
Blocks: 121114
This is fixed on latest trunk now, no? Didn't we implement tabindex="" on all
elements recently?
QA Contact: stummala → ian
(In reply to comment #23)
> This is fixed on latest trunk now, no? Didn't we implement tabindex="" on all
> elements recently?

This isn't really fixed imo, because we don't do what IE does. The link without
the URL is tabbable in IE without manually making it so with tabindex.
Not in my tests, it isn't:

Are you sure?
No you're right. I wasn't looking at the fact that the example URL originally
posted to this bug has a tabindex set. In fact, it is even tabbable in Mozilla
1.8a5, because of the tabindex fix. Not sure why it's not showing a dotted
outline though. I think we should keep this bug open until the default focus
indication is fixed.
Assignee: bryner → aaronleventhal
Keywords: access
Attached file file from bug URI
Blocks: keya11y
No longer blocks: 121114
Blocks: fox3key
No longer blocks: keya11y
would like to widen the scope of this bug, Aaron, Hixie or another please second.

hover in SVG does not require an anchor, but focus does at present...

see attachment
Attached image hover without anchor but no focus (obsolete) —
Attachment #264602 - Attachment description: hover without anchor → hover without anchor but no focus
reduced test case
Attachment #264602 - Attachment is obsolete: true
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Attached file testcase
I've chanced upon this situation during testing a form for keyboard users navigation by tab button. I simplified it focused to the problem. (and titivated a little).

This is the most relevant filing, So: 

Before filing any new bug there is a question:

This form "breaks" at 2nd <input> element during tab-browsing. (the funny stuff is the keypress event). Is this a normal behavior or not? The situation is the interesting, if somebody only uses keyboard (currently tab button) for navigation. (msie goes forward)

(This testcase contains a sample how use anchor with tabindex with javascript and without URI. (That's just a titivation nothing else))

Any opinion?
Attachment #495351 - Flags: review?(jst)
> This is the most relevant filing

It's really not...  Or rather, "most relevant" is not a good metric if it's still unrelated.  Your testcase has no anchors without URIs, so has nothing whatsoever to do with this bug.
Comment on attachment 495351 [details]

r- based on bz's previous comment.
Attachment #495351 - Flags: review?(jst) → review-
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.