Closed Bug 1576510 Opened 5 months ago Closed 3 months ago

Make toolbar badging accessible to screen reader users

Categories

(Firefox :: Messaging System, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 71
Iteration:
71.3 - Sept 30 - Oct 13
Tracking Status
firefox70 + wontfix
firefox71 + verified

People

(Reporter: asa, Assigned: andreio)

References

Details

(Keywords: access, github-merged, Whiteboard: [skyline] [access-p1])

Attachments

(2 files, 1 obsolete file)

Right now, the messaging system badging adds a blue dot to the upper right corner of toolbar buttons. These badges are not exposed to screen reader users and should be. We should figure out what the right approach is here, perhaps only announcing the badge when a user focuses the badged button.

Component: Disability Access → Messaging System

Our initial thinking is that we should use aria-describedby or aria-label/aria-labelledby to add a textual indication of the badge.

  1. What should the string be? "New feature" was our initial thought, but it seems there are plans to use badges for things other than new features. We either need a single consistent string that covers all cases generically, a set of category strings which can be set using some kind of category specifier, or a way to set a localisable string for each badge. The latter is the most flexible, but in some ways, it's least preferred because it doesn't provide a consistent user experience.
  2. aria-describedby would be easiest, as most things don't have descriptions (at least not critical descriptions), so this can take over the description rather than having to add to existing text.
  3. The problem with description is that it is secondary text. For example, screen reader users will hear this at the end of the announcement (after the label and control type) and they may have already skipped over the button at that point. If we really want to draw attention as the user is exploring, this might not be ideal. If that's a concern, we'll need to prefix the label.
    • Adding a prefix to the label will be tricky, as we don't want this text to be visible visually and there are several different ways used to label controls.
    • Can we reference the node itself with aria-labelledby? This does seem to work:
      data:text/html,<button id="foo" aria-labelledby="foo bar">foo</button><div id="bar" hidden>bar</div>
  4. If we use aria-labelledby or aria-describedby, the text has to be in a visually hidden node with an id somewhere. Where?
Priority: -- → P2
Whiteboard: [access-p1]
Keywords: access
Whiteboard: [access-p1] → [skyline] [access-p1]

I've posted an initial patch that puts together some of the ideas from comment #1.
Some comments:

  • I don't think the string that describes the notification has to be so restrictive. The badge has various customizable attributes, we can have a list of strings that describe different types of notifications: new feature, feature callout and others; and reference the correct one for each badge type.
  • All MozToolbarbutton elements that are badged include some hidden elements that we can use to hold this description.

In this patch I check if the badge has this additional label attribute defined which in turn can reference any fluent string ids with a explanation. The text is added to this toolbarbutton-text hidden node and the two are linked using aria-labelledby and a unique id.

Assignee: nobody → andrei.br92
Iteration: --- → 71.2 - Sept 16 - 29
Priority: P2 → P1

Can you request uplift to beta 70? This issue tagged as part of skyline and is set to P1, which makes it a blocker for the feature's release.

Flags: needinfo?(andrei.br92)
Iteration: 71.2 - Sept 16 - 29 → 71.3 - Sept 30 - Oct 13

This could still potentially land for Monday's build but if not, then it will likely miss 70 release.

Asa, I don't think that should block the feature. What do you think?

Flags: needinfo?(asa)

Optionally, we can relnote it as a known issue for screen reader users, if we don't get the fix in for 70.

I've spoken with Jim Thomas, Jamie Teh, and others about how much usage this feature is going to get in the near term and I'm OK with us not blocking 70 on this. We should still prioritize fixing it ASAP, like 71, so that when we do "turn up the volume" with badging it's accessible to all of our users.

Flags: needinfo?(asa)
Flags: needinfo?(andrei.br92)
Attachment #9097307 - Attachment is obsolete: true
Blocks: 1588215
Status: NEW → RESOLVED
Closed: 3 months ago
Keywords: github-merged
Resolution: --- → FIXED
Target Milestone: --- → Firefox 71

I have verified that this issue is no longer reproducible with the latest Firefox Nightly (71.0a1 Build ID - 20191006214844) installed, on Windows 10 x64, Arch Linux and Mac 10.14.5. I've inspected the "What's New" and the "Firefox Accounts" toolbar buttons using the "Accessibility" tool and I can confirm that the strings are successfully accessed by the screen reader software.

Status: RESOLVED → VERIFIED
Blocks: 1589802
Status: VERIFIED → RESOLVED
Closed: 3 months ago3 months ago

(In reply to Ed Lee :Mardak from comment #12)

https://hg.mozilla.org/mozilla-central/rev/39f853367dca

I incorrectly tagged this github PR as fixing this bug when instead it fixes bug 1588104.
This bug was already fixed.

Considering the above comment and based on comment 11 I am changing the status of this issue to VERIFIED - FIXED.

Status: RESOLVED → VERIFIED
No longer blocks: 1589802
You need to log in before you can comment on or make changes to this bug.