Closed Bug 1886807 Opened 4 months ago Closed 2 months ago

Text-link in the Personal Toolbar is not accessible and its context is missing

Categories

(Firefox :: Bookmarks & History, defect, P3)

defect

Tracking

()

VERIFIED FIXED
127 Branch
Accessibility Severity s2
Tracking Status
firefox127 --- verified
firefox128 --- verified

People

(Reporter: ayeddi, Assigned: ayeddi)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Keywords: access, Whiteboard: [sng][places-a11y])

Attachments

(2 files)

STR:

  1. Ensure a screen reader is running
  2. Open a new profile or a fresh build of the Firefox
  3. Open a New Tab page (since by default Nightly is showing the Bookmarks toolbar on the New Tab page only)
  4. 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
  5. Confirm, there are no bookmarks shown on the Bookmarks toolbar and review the screen reader announcement for this empty state panel.

Expected:

  1. 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:

  1. When a screen reader is used, the link is not announced as such.
  2. 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 the Bookmarks tool bar is a label for the entire Bookmarks toolbar, thus only the text frame is announced as the message for a user with an empty toolbar)

Notes:

  1. Code responsible for this link-text
  2. Test case that is currently expected to fail a11y-checks: browser/base/content/test/about/browser_aboutNewTab_bookmarksToolbarEmpty.js - when this bug is fixed, the fail-if notation should be removed from its test manifest.
  3. Remediation includes 2 actions:
    1. add grouping that is labeled by the text (excluding the link itself to avoid any redundancy)
    2. 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.
See Also: → 1887170
See Also: a11y_checks_focusable

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(mak)
Severity: -- → S3
Flags: needinfo?(mak)
Priority: -- → P3
Whiteboard: [sng][places-a11y]

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.

Flags: needinfo?(mak)

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.

Assignee: nobody → ayeddi
Status: NEW → ASSIGNED

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.

Blocks: 682811
Pushed by ayeddi@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/425b44586178
Ensure Text-link in the Personal Toolbar provides an interactive role. r=Jamie
No longer blocks: 682811
Depends on: 682811
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 127 Branch

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)

Flags: needinfo?(mak) → needinfo?(ayeddi)
Flags: qe-verify+

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.

Status: RESOLVED → VERIFIED

(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]

Flags: needinfo?(ayeddi)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: