Closed
Bug 1410757
Opened 7 years ago
Closed 5 years ago
[a11y] Tab tool tip info difficult to access for screen reader users
Categories
(Firefox :: Tabbed Browser, enhancement, P3)
Firefox
Tabbed Browser
Tracking
()
RESOLVED
FIXED
Firefox 70
Tracking | Status | |
---|---|---|
firefox70 | --- | fixed |
People
(Reporter: Jamie, Assigned: Jamie)
References
Details
(Keywords: access)
Attachments
(1 file)
Several pieces of information are provided via tool tips for browser tabs:
1. The tab container name.
2. The labels for the close tab and mute buttons.
3. the e10s process id for the tab.
For a screen reader user, these are very difficult to access. One has to route the mouse to the tab (or button therein) and then find the tool tip in the accessibility tree. This is very complicated and a lot of screen reader users won't be able to manage it. Furthermore, even if they could, this is not particularly intuitive or discoverable. Finally, right now, the close and mute buttons are completely unlabelled, which is an a11y crime no matter which way you look at it. :)
I suggest that the tool tip label be exposed as the "description" for accessibility purposes.
1. In XUL, this happens automatically when the tooltiptext attribute is used. There's obviously some reason this isn't used here, though.
2. The other way to do this is to set aria-describedby on each tab pointing at a node which contains the tool tip text. The problem here is that the text is currently only created when the user mouses over the tab, and there's only one tool tip.
2.1. Ideally, each tab would always expose its tool tip text as its description, even if it didn't have focus. That would require an invisible node for each tab containing its description, and it'd somehow have to be updated whenever something changed.
2.2. Failing that, I think it'd be acceptable to only set aria-describedby while the tab has focus. That means the description would only have to be calculated when the tab is focused or moused over. Unfortunately, the tab that is focused and the tab that is being moused over might be different. That doesn't fix the problem for the buttons, however, as they can't get focus. I think those are less important though.
Note that this would address part 1 of bug 1280549 (making the container type for a given tab accessible via the tab bar).
CCing Yura and Marco for their thoughts.
Updated•7 years ago
|
Priority: -- → P3
Assignee | ||
Comment 1•5 years ago
|
||
The tool tip for a browser tab exposes information such as the process ids (on Nightly) and the container tab name.
It appears when a user mouses over the tab, but this isn't really accessible to screen reader users.
Ideally, we'd expose this information as the accessible description for all browser tabs.
However, doing this for all tabs and keeping it up to date is rather difficult and potentially expensive.
Instead, just expose this description for a tab when it gets focus; i.e. the user has to focus the tab bar to access it.
To enable this, XUL tab elements now fire an AriaFocus event on the ARIA focused tab when the ariaFocusedItem property is set.
Pushed by mzehe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c25628ad5a4c
Expose the info provided in the tool tip for the focused browser tab as the tab's accessible description. r=Gijs
Comment 3•5 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox70:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70
Updated•5 years ago
|
Assignee: nobody → jteh
You need to log in
before you can comment on or make changes to this bug.
Description
•