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

Status: NEW

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

Description

[jonathan chetwynd]

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

http://www.w3.org/TR/html4/struct/links.html#edef-A
There must be a better reference, I cannot find it right now.
sorry.

Comment 1

[Karl Johan Kleist]

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

[Fabian Guisset]

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

[jonathan chetwynd]

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

Comment 4

[Aaron Leventhal]

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.

Comment 5

[Johnny Stenback (:jst)]

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.

Comment 6

[jonathan chetwynd]

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.

Comment 7

[Johnny Stenback (:jst)]

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).

WONTFIX.

Comment 8

[jonathan chetwynd]

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.

http://www.peepo.com/2k1/mousewheel/tabindex.html
http://www.webreference.com/js/tips/010717.html
http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmousewheel.html 

Comment 9

[Johnny Stenback (:jst)]

How does IE6 deal with this?

Comment 10

[Johnny Stenback (:jst)]

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?

Comment 11

[timeless]

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 
event)

Comment 12

[jonathan chetwynd]

in IE6 with win'98

tabbing works for

Anchor + URI
Anchor + tabindex
IMG + tabindex

but not
Anchor
IMG

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.

Comment 13

[Johnny Stenback (:jst)]

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.

Comment 14

[Brian Ryner (not reading)]

-> 1.0, nominating for beta1.

Comment 15

[Aaron Leventhal]

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

Comment 16

[Aaron Leventhal]

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

[Sivakiran Tummala]

changing priority to P4

Comment 18

[Peter Trudelle]

nsbeta1+ per Nav triage team

Comment 19

[Peter Trudelle]

nsbeta1- per ADT triage team

Comment 20

[Dave Barrowman]

topembed- per EDT triage.  Aaron, let us know if this is the wrong decision.

Comment 21

[Aaron Leventhal]

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

[Aaron Leventhal]

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?

Comment 23

[Hixie (not reading bugmail)]

This is fixed on latest trunk now, no? Didn't we implement tabindex="" on all
elements recently?

Comment 24

[Aaron Leventhal]

(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.

Comment 25

[Hixie (not reading bugmail)]

Not in my tests, it isn't:
   http://www.hixie.ch/tests/evil/html/focus/001.html

Are you sure?

Comment 26

[Aaron Leventhal]

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.

Comment 27

[jonathan chetwynd]

Attachment: file from bug URI

Comment 28

[jonathan chetwynd]

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

[jonathan chetwynd]

Attachment: hover without anchor but no focus

Comment 30

[jonathan chetwynd]

Attachment: hover without anchor but no focus

reduced test case

Comment 31

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.

Comment 32

[Robert Utasi [:hunboy]]

Attachment: 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?

Comment 33

[Boris Zbarsky [:bzbarsky]]

> 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 34

[Johnny Stenback (:jst)]

Comment on attachment 495351 [details]
testcase

r- based on bz's previous comment.