Following an on-page anchor link loses the focus
Categories
(Core :: Layout, defect, P3)
Tracking
()
Accessibility Severity | s3 |
People
(Reporter: mozilla1, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: regression, testcase)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Reporter | ||
Comment 1•19 years ago
|
||
Reporter | ||
Comment 2•19 years ago
|
||
Reporter | ||
Updated•19 years ago
|
Comment 3•19 years ago
|
||
Reporter | ||
Comment 4•19 years ago
|
||
Comment 5•19 years ago
|
||
Updated•19 years ago
|
Updated•19 years ago
|
Comment 6•19 years ago
|
||
Comment 7•19 years ago
|
||
Comment 8•19 years ago
|
||
Comment 9•18 years ago
|
||
Updated•18 years ago
|
Updated•18 years ago
|
Updated•17 years ago
|
Updated•16 years ago
|
Comment 11•16 years ago
|
||
Comment 12•16 years ago
|
||
Comment 13•16 years ago
|
||
Comment 14•15 years ago
|
||
Updated•13 years ago
|
Comment 16•10 years ago
|
||
Comment 18•6 years ago
|
||
Comment 19•6 years ago
|
||
Comment 20•6 years ago
|
||
Comment 21•6 years ago
|
||
This bug is now 14 years old, is there any intention of fixing this?
This breaks the CSS-only approach to open a menu with a link to an anchor combined with :focus (& :focus-inside).
Comment 22•4 years ago
|
||
This breaks accessibility, especially skip links ( https://developer.mozilla.org/en-US/docs/Learn/Common_questions/HTML_features_for_accessibility ).
Updated•4 years ago
|
Comment 23•4 years ago
|
||
(In reply to gerrit.huebbers from comment #22)
This breaks accessibility, especially skip links ( https://developer.mozilla.org/en-US/docs/Learn/Common_questions/HTML_features_for_accessibility ).
What would you expect in the example on that page? The target is a section, which isn't focusable, so we can't focus it. This is frequently the case with skip links: the target isn't a focusable element. However, screen readers are informed of the target, and for non-screen reader user keyboard users, pressing tab will take you to the next link after the target.
Comment 24•4 years ago
|
||
(In reply to James Teh [:Jamie] from comment #23)
What would you expect in the example on that page? The target is a section, which isn't focusable, so we can't focus it. [...]
Please excuse my ambigious comment – I think you misunderstood what I wanted to convey: I provided that link for giving motivational context why working "jump-to-input-elements-and-place-the-cursor-there" anchors are important, namely for working skip links, especially for accessibility reasons (e.g. skipping to an input element and allowing to provide input), where every barrier and confusion removed makes a significant impact.
Imagine a skip link to directly jump to this Bugzilla's quick search box. You would have <a href="#quicksearch_top">Skip to Quicksearch</a>
as one of the first children of the <body>
element.
Try it out yourself: Skip to Quicksearch.
- Click that link in IE11, Edge, or Chrome, and a blinking cursor will appear in above search box, waiting for your input.
- Click that link in Firefox 1 to 76+, and you're lost.
Comment 25•4 years ago
|
||
Here is a further arguments in favor of working in-page anchors towards input elements:
For form validation errors, W3C's Web Accessibility Initiative recommends to provide direct links to the failing inputs. Such jump-to-field-for-correction links are described in WCAG's technique SCR32. They provide an example form with such jump-to-field-for-correction links, which surprisingly work in Firefox 77.0.1. I haven't understood yet, why that particular example works while in the general case it does not.
Comment 26•4 years ago
|
||
It's mind boggling this bug is open for 16 years.
It is preventing me from toggling anchor tags using CSS while keeping focus.
Comment 27•2 years ago
|
||
I can no longer reproduce this bug in 102.6.0 ESR, has this somehow been fixed?
Updated•1 year ago
|
Updated•1 year ago
|
Description
•