Text-link in the Personal Toolbar is not accessible and its context is missing
Categories
(Firefox :: Bookmarks & History, defect, P3)
Tracking
()
People
(Reporter: ayeddi, Assigned: ayeddi)
References
(Blocks 2 open bugs)
Details
(Keywords: access, Whiteboard: [sng][places-a11y])
Attachments
(2 files)
STR:
- Ensure a screen reader is running
- Open a new profile or a fresh build of the Firefox
- Open a New Tab page (since by default Nightly is showing the Bookmarks toolbar on the New Tab page only)
- Ensure the Bookmarks toolbar is shown (i.e. via the Customizable UI) and, if there are any pre-installed bookmarks, remove them. If there is an
Import bookmarks...
button, right click/context menu >Remove from toolbar
- Confirm, there are no bookmarks shown on the Bookmarks toolbar and review the screen reader announcement for this empty state panel.
Expected:
- When navigated to the empty bookmarks message with a screen reader and
Tab
keypress, the link is announced, it's role (link
) is announced, and the grouping is mentioned alongside with the context (the static text):
For quick access, place your bookmarks here on the bookmarks toolbar. Manage bookmarks..., link
Actual:
- When a screen reader is used, the link is not announced as such.
- Nothing is read by the screen reader from the context of the link, even in the browse mode on Windows, thus the context is missing for the screen reader user. Only VoiceOver can get to the static text, though it is not expected for a user to reverse the navigation trying to find some static text that is not mentioned elsewhere. NVDA announces only:
Bookmarks tool bar, text frame
(where theBookmarks tool bar
is a label for the entire Bookmarks toolbar, thus only thetext frame
is announced as the message for a user with an empty toolbar)
Notes:
- Code responsible for this link-text
- Test case that is currently expected to fail a11y-checks:
browser/base/content/test/about/browser_aboutNewTab_bookmarksToolbarEmpty.js
- when this bug is fixed, thefail-if
notation should be removed from its test manifest. - Remediation includes 2 actions:
- add grouping that is labeled by the text (excluding the link itself to avoid any redundancy)
- add
role=link
to the link-text element - it's not an ideal solution markup-wise, but since there is a legacy custom event logic that has already been provided to the grouping element, we can avoid rewriting it in this case.
Updated•11 months ago
|
Comment 1•11 months ago
|
||
The severity field is not set for this bug.
:mak, could you have a look please?
For more information, please visit BugBot documentation.
Updated•10 months ago
|
Updated•10 months ago
|
Comment 2•10 months ago
|
||
The severity field for this bug is set to S3. However, the accessibility severity is higher, .
:mak, could you consider increasing the severity?
For more information, please visit BugBot documentation.
Assignee | ||
Comment 3•9 months ago
|
||
Ensure the Manage bookmarks
control is marked up as a link and is accessible to assistive technology.
Also, by adding a role="alert"
to the grouping, we are making sure that a screen reader like NVDA would be able to hear the static text on the Personal toolbar message when navigating the browser UI and that it would be announced to a user whenever this message is added to the toolbar, i.e. when the user removes the last bookmark from the Bookmarks Toolbar.
Updated•9 months ago
|
Assignee | ||
Comment 4•9 months ago
|
||
Note: when the bug 682811 is resolved, we would need to check if the toolbar is being announced to a user when it is un-hidden. Per Jamie's comment in Phab:
If you hide and then show the toolbar, does this "alert" get reported? If so, that might be a bit annoying. Hopefully, it doesn't, but that would be because of bug 682811. If we ever get around to fixing bug 682811, it probably will, but I guess we can deal with this then.
Assignee | ||
Updated•9 months ago
|
Comment 6•9 months ago
|
||
bugherder |
Comment 7•9 months ago
|
||
Re: https://phabricator.services.mozilla.com/D209588#7199065
Well, the item can also appear when manually hiding/showing the toolbar, right? Does the alert fire in that case?
What happens if the bookmarks toolbar is set to "only show on new tab", and the toolbar appears/disappears based on tabswitches or navigation?
(I tried to check myself with NVDA on Windows but struggled to understand under what circumstances the alert is announced. Based on some of the recent discussion, I'm also unclear on whether other AT / OS combinations would behave differently)
Updated•9 months ago
|
Reproducible on a 2024-05-05 Nightly build on Windows 10.
Verified as fixed on Firefox Nightly 128.0a1 and Firefox 127.0b2 on Windows 10, macOS 14.
Assignee | ||
Comment 9•9 months ago
•
|
||
(In reply to :Gijs (he/him) from comment #7)
Re: https://phabricator.services.mozilla.com/D209588#7199065
Well, the item can also appear when manually hiding/showing the toolbar, right? Does the alert fire in that case?
What happens if the bookmarks toolbar is set to "only show on new tab", and the toolbar appears/disappears based on tabswitches or navigation?
(I tried to check myself with NVDA on Windows but struggled to understand under what circumstances the alert is announced. Based on some of the recent discussion, I'm also unclear on whether other AT / OS combinations would behave differently)
Thank you for pointing to this setting - I confirmed on Win+NVDA that the alert is not announced when a new tab with this notification is opened. Also, I've encountered a few other message bars that were opened with the tab/window and none of them were announced unless navigated to with a screen reader. It seems appropriate, because the focus lands on the awesomebar and the message bars are placed in the DOM and visually after it.
The change does not create any interruptions in the flow.
[Editing to add: macOS+VO is not announcing the alert too, when a new tab is opened]
Description
•