Open
Bug 563911
Opened 14 years ago
Updated 1 year ago
Extraneous tabstop when navigating from the tab bar to the Add-ons Manager and Preferences categories list
Categories
(Firefox :: Keyboard Navigation, defect, P5)
Tracking
()
NEW
People
(Reporter: MarcoZ, Unassigned)
References
Details
(Keywords: access, Whiteboard: [rewrite])
STR: 1. Open Tools/Add-Ons. 2. focus lands on an "unknown object" as the screen reader says. 3. Press Tab. Result: Focus is now in the list of manager categories. 4. Press Shift+Tab. Result: No change. Expected: Land on tab bar. 5. Press Shift+Tab again. Result: Now landed on tab bar. 6. Press Tab. Expected: Land in list of categories. Actual: No response, focus doesn't seem to shift. 7. Press Tab again. Result: Focus now lands in the Manager categories list.
Reporter | ||
Comment 1•10 years ago
|
||
I now also see this when opening the in-content Tools/Options dialog. And probably also the ones introduced in bug 1021618.
Reporter | ||
Comment 2•10 years ago
|
||
This is still happening in current nightlies, and has become more apparent now that Settings has also been moved to a content tab. Blair, any good idea about why this is happening?
Flags: needinfo?(bmcbride)
Comment 3•10 years ago
|
||
No :\ Lets get this in the backlog.
Flags: needinfo?(bmcbride) → firefox-backlog+
Updated•10 years ago
|
Component: Add-ons Manager → Keyboard Navigation
Product: Toolkit → Firefox
Summary: Extraneous tabstop when navigating from the tab bar to the Add-Ons Manager categories list → Extraneous tabstop when navigating from the tab bar to the Add-ons Manager and Preferences categories list
Updated•10 years ago
|
Flags: qe-verify?
Reporter | ||
Comment 4•6 years ago
|
||
This is still the case today. Jamie, do we want this to be a P5 or rather a P3?
Flags: needinfo?(jteh)
Priority: -- → P5
Comment 5•6 years ago
|
||
(In reply to Marco Zehe (:MarcoZ) from comment #4) > This is still the case today. I do see the extraneous tab stop, but for me, focus is very clearly on the "application" accessible (XUL <page>) for that tab stop. There's no "unknown" accessible anywhere. Marco, can you confirm this? > Jamie, do we want this to be a P5 or rather a > P3? I think this could be a p5, especially because this is the same behaviour we have on web pages (the body itself has a tab stop). However, it's worth noting that this seems a lot more obscure without a fix for bug 580537.
Flags: needinfo?(jteh)
Reporter | ||
Comment 6•6 years ago
|
||
(In reply to James Teh [:Jamie] from comment #5) > (In reply to Marco Zehe (:MarcoZ) from comment #4) > > This is still the case today. > > I do see the extraneous tab stop, but for me, focus is very clearly on the > "application" accessible (XUL <page>) for that tab stop. There's no > "unknown" accessible anywhere. Marco, can you confirm this? Yes, final focus is indeed on an application accessible. However, when the menus close, there is still some chatter going on where NVDA speaks "unknown" for one pass of "Add-Ons Manager". It basically repeats things twice, once with unknown, once without a role announcement, this is when focus is on the application role. > > Jamie, do we want this to be a P5 or rather a > > P3? > > I think this could be a p5, especially because this is the same behaviour we > have on web pages (the body itself has a tab stop). However, it's worth > noting that this seems a lot more obscure without a fix for bug 580537. Agreed. Leaving on P5, then.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•