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




17 years ago
a year ago


(Reporter: jay, Unassigned)


(Blocks: 2 bugs, {access, topembed-})

access, topembed-
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: DUPEME, URL)


(3 attachments, 1 obsolete attachment)



17 years ago
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.

Comment 1

17 years ago
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")>

Comment 2

17 years ago
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.

Comment 3

17 years ago
It's not just onclick, it is event handling,, ie onfocus...

Comment 4

17 years ago
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.
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 6

17 years ago
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).

Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX

Comment 8

17 years ago
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 → ---

Comment 11

17 years ago
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 

Comment 12

17 years ago
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

Comment 15

17 years ago
What about allowing anything with an onclick to be in the tab order, so that
Enter can activate the element?

Comment 16

17 years ago
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?

Comment 17

17 years ago
changing priority to P4
Priority: -- → P4


17 years ago
Keywords: topembed

Comment 18

17 years ago
nsbeta1+ per Nav triage team
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2

Comment 19

17 years ago
nsbeta1- per ADT triage team


17 years ago
Blocks: 24413

Comment 20

17 years ago
topembed- per EDT triage.  Aaron, let us know if this is the wrong decision.
Keywords: topembed → topembed-

Comment 21

17 years ago
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.

Comment 22

17 years ago
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

Comment 24

14 years ago
(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?

Comment 26

14 years ago
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

Comment 27

13 years ago
Created attachment 225573 [details]
file from bug URI


13 years ago
Blocks: 342901
No longer blocks: 121114


12 years ago
Blocks: 368883
No longer blocks: 342901

Comment 28

12 years ago
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

Comment 29

12 years ago
Created attachment 264602 [details]
hover without anchor but no focus


12 years ago
Attachment #264602 - Attachment description: hover without anchor → hover without anchor but no focus

Comment 30

12 years ago
Created attachment 264610 [details]
hover without anchor but no focus

reduced test case
Attachment #264602 - Attachment is obsolete: true


10 years ago
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Created attachment 495351 [details]

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-
You need to log in before you can comment on or make changes to this bug.