Open Bug 112393 Opened 23 years ago Updated 2 years ago

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

Categories

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

defect

Tracking

()

mozilla1.2alpha

People

(Reporter: jay, Unassigned)

References

()

Details

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

Attachments

(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 http://www.w3.org/TR/html4/struct/links.html#edef-A There must be a better reference, I cannot find it right now. sorry.
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.
Status: UNCONFIRMED → RESOLVED
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.
Status: RESOLVED → UNCONFIRMED
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). WONTFIX.
Status: UNCONFIRMED → RESOLVED
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. 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
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?
Status: RESOLVED → UNCONFIRMED
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 event)
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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
-> 1.0, nominating for beta1.
Status: NEW → ASSIGNED
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: http://www.hixie.ch/tests/evil/html/focus/001.html 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
Status: ASSIGNED → NEW
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] testcase 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.

Attachment

General

Created:
Updated:
Size: