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.

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?

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.

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.

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?

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.

https://hg.mozilla.org/mozilla-central/rev/9d2586266fcd

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.

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

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