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)
Core
DOM: Core & HTML
Tracking
()
NEW
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.
Comment 1•23 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•23 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.
Reporter | ||
Comment 3•23 years ago
|
||
It's not just onclick, it is event handling,, ie onfocus...
Comment 4•23 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
Comment 5•23 years ago
|
||
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
Reporter | ||
Comment 6•23 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.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Comment 7•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 8•23 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.
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•23 years ago
|
||
How does IE6 deal with this?
Comment 10•23 years ago
|
||
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 → ---
Comment 11•23 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
event)
Reporter | ||
Comment 12•23 years ago
|
||
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•23 years ago
|
||
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
Comment 14•23 years ago
|
||
-> 1.0, nominating for beta1.
Comment 15•23 years ago
|
||
What about allowing anything with an onclick to be in the tab order, so that
Enter can activate the element?
Comment 16•23 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 18•23 years ago
|
||
nsbeta1+ per Nav triage team
Comment 19•23 years ago
|
||
nsbeta1- per ADT triage team
Comment 20•23 years ago
|
||
topembed- per EDT triage. Aaron, let us know if this is the wrong decision.
Comment 21•23 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•23 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
Comment 23•20 years ago
|
||
This is fixed on latest trunk now, no? Didn't we implement tabindex="" on all
elements recently?
QA Contact: stummala → ian
Comment 24•20 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.
Comment 25•20 years ago
|
||
Not in my tests, it isn't:
http://www.hixie.ch/tests/evil/html/focus/001.html
Are you sure?
Comment 26•20 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.
Reporter | ||
Comment 27•18 years ago
|
||
Updated•18 years ago
|
Updated•18 years ago
|
Reporter | ||
Comment 28•18 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
Reporter | ||
Comment 29•18 years ago
|
||
Reporter | ||
Updated•18 years ago
|
Attachment #264602 -
Attachment description: hover without anchor → hover without anchor but no focus
Reporter | ||
Comment 30•18 years ago
|
||
reduced test case
Attachment #264602 -
Attachment is obsolete: true
Comment 31•15 years ago
|
||
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Comment 32•14 years ago
|
||
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)
Comment 33•14 years ago
|
||
> 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•14 years ago
|
||
Comment on attachment 495351 [details]
testcase
r- based on bz's previous comment.
Attachment #495351 -
Flags: review?(jst) → review-
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•