1576509 - Make the contextual feature recommender (CFR) usable by keyboard users

Status: VERIFIED FIXED

(Firefox :: Messaging System, defect, P1)

Description

[Asa Dotzler [:asa]]

Right now, the contextual feature recommender adds a "Recommendations" button to the addressbar which does not get announced to screen reader users unless they happen to stumble upon it. We should figure out how to make this feature more obvious to screen reader users.

Comment 1

[Emily McMinn :emcminn]

(In reply to Asa Dotzler [:asa] from comment #0)

Right now, the contextual feature recommender adds a "Recommendations" button to the addressbar which does not get announced to screen reader users unless they happen to stumble upon it. We should figure out how to make this feature more obvious to screen reader users.

I've been investigating and it looks like the "correct" approach would be to give the contents of the button an aria-role of "alert", which should announce it to the screen reader as soon as the content becomes visible. The big issue with that is that it seems VoiceOver (mac) doesn't currently recognize aria-roles at all, so it would only be a partial solution.

Comment 2

[James Teh [:Jamie]]

(In reply to Emily McMinn :emcminn from comment #1)

I've been investigating and it looks like the "correct" approach would be to give the contents of the button an aria-role of "alert", which should announce it to the screen reader as soon as the content becomes visible.

That's true, but there are two gotchas there:

1. The button is currently just labelled "Recommendation". I'm not sure if hearing just "alert, Recommendation" is going to make any sense to the user. I tend to think those labels need to be more descriptive anyway; e.g. "Feature recommendation", "Add-on recommendation", as is indicated by the category icons. However, I wonder whether we might need to go a step further than that with our message; e.g. "Feature recommendation available". A message different to the label will require the message to be somewhere other than the button.
2. If you put role="alert" on the button, the alert role will override the button role. That is, the user will hear it get reported as an 'alert" when they tab to the button instead of hearing it reported as a "button". That could be confusing, since the user won't know how to interact with it.

The big issue with that is that it seems VoiceOver (mac) doesn't currently recognize aria-roles at all, so it would only be a partial solution.

Firefox support for Mac accessibility is limited and broken at best, unusable at worst, so we shouldn't use Mac as a baseline for support here. I'd focus on Windows with NVDA for now. (That said, once our Mac support does improve, anything we do here will start working there, too.)

Comment 3

[Emily McMinn :emcminn]

(In reply to James Teh [:Jamie] from comment #2)

1. The button is currently just labelled "Recommendation". I'm not sure if hearing just "alert, Recommendation" is going to make any sense to the user. I tend to think those labels need to be more descriptive anyway; e.g. "Feature recommendation", "Add-on recommendation", as is indicated by the category icons. However, I wonder whether we might need to go a step further than that with our message; e.g. "Feature recommendation available". A message different to the label will require the message to be somewhere other than the button.

We're currently using the same string for label and title/tooltip, but we could probably add a more detailed string for the button title that could then be read as the alert. "[Type] recommendation available" would probably be pretty doable if we're able to use the Fluent strings.

2. If you put role="alert" on the button, the alert role will override the button role. That is, the user will hear it get reported as an 'alert" when they tab to the button instead of hearing it reported as a "button". That could be confusing, since the user won't know how to interact with it.

I've been experimenting with putting the role="alert" on the label so that the button role doesn't get overridden, but putting the message somewhere other than the button might be the best approach since that would also make having a different string a little easier - we could write an sr-only alert that is triggered by the button switching from "hidden" to "display:block", for example.

Firefox support for Mac accessibility is limited and broken at best, unusable at worst, so we shouldn't use Mac as a baseline for support here. I'd focus on Windows with NVDA for now. (That said, once our Mac support does improve, anything we do here will start working there, too.)

Good to know!

Comment 4

[Emily McMinn :emcminn]

Attachment: Bug 1576509 - Added a screen-reader visible description to the recommendation button.

Comment 5

[Emily McMinn :emcminn]

Hi Asa, I've got a quick patch put together but I don't know if it'll work as expected, since I don't have a Windows setup - if you want to give it a try and let me know if it does what I think it does, feedback would be welcome :)

Comment 6

[Asa Dotzler [:asa]]

(In reply to Emily McMinn :emcminn from comment #5)

Hi Asa, I've got a quick patch put together but I don't know if it'll work as expected, since I don't have a Windows setup - if you want to give it a try and let me know if it does what I think it does, feedback would be welcome :)

I don't have a build environment (been a couple of years since I did) but if you could trigger a try build with your patch (something I don't know how to do) I'd be more than happy to test that out. Also, adding Marco to this bug because he's a more experienced screen reader tester than I am.

Comment 7

[James Teh [:Jamie]]

Marco, can you give this a spin please? Thanks!

Comment 8

[Marco Zehe (:MarcoZ)]

Unfortunately, this does not yet do what we want. The alert appears, gets a label, and is associated to the button as its description, but it does not get spoken by NVDA when I activate the first of the CFRs from the about:newtab dev tools. The reason is probably because due to the way this patch is written, this recommendation available alert is already present upon start of Firefox. Automatic speaking only triggers when it appears, and not if something appears that has this thing as its description.

Comment 9

[James Teh [:Jamie]]

Thanks much for your work on this, Emily. Getting this kind of thing working just the right way is a little tricky. :)

I'm now working on this. I have a working implementation (tested by Marco, Asa and me), but need to figure out localisation and write tests.

Comment 10

[James Teh [:Jamie]]

Attachment: Bug 1576509: Add a function to announce a message to screen reader users.

Comment 11

[James Teh [:Jamie]]

Attachment: Bug 1576509: Give the CFR address bar button a more descriptive tooltip/a11y label. Announce its appearance to screen reader users.

Comment 12

[James Teh [:Jamie]]

Attachment: Bug 1576509: When a CFR doorhanger is activated via the keyboard, focus its first element.

Previously, keyboard users had to press f6 several times to get to the doorhanger.
If a user is activating the doorhanger from the keyboard, it makes sense that they'd want to interact with it.

Comment 13

[James Teh [:Jamie]]

Note that the second and third patches here aren't complete, which is why I haven't specified a reviewer for them yet. I need to figure out how to localise the "Recommendation available" message and how to test the CFR doorhanger focus stuff. I'm posting them now in case anyone is interested in taking an early look and/or helping me out given the time pressure here.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e062c3bc7cbd
Add a function to announce a message to screen reader users. r=Gijs,yzen

Comment 16

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/e062c3bc7cbd

Comment 17

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/e062c3bc7cbd

Comment 18

[James Teh [:Jamie]]

Asa and I agree this should be a p1 for accessibility. However, we acknowledge there's a high likelihood this won't make it into 70 due to risk and timing. It should have been tracked as affecting 70 from the start, but wasn't due to oversight on our part.

Comment 19

[James Teh [:Jamie]]

Oops. This was already tracked as affecting 70. My bad.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0a7ca42f7bdc
When a CFR doorhanger is activated via the keyboard, focus its first element. r=andreio

Comment 21

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/0a7ca42f7bdc

Comment 22

[James Teh [:Jamie]]

Comment on attachment 9097554 [details]
Bug 1576509: When a CFR doorhanger is activated via the keyboard, focus its first element.

Beta/Release Uplift Approval Request

• User impact if declined: CFR recommendations will not be realistically usable by keyboard users, including screen reader users.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None. Please note that the other patches from this bug should NOT be uplifted.
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Straightforward patch which only affects keyboard activation of CFR doorhangers. Covered by automated tests.
• String changes made/needed: None.

Comment 23

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9097554 [details]
Bug 1576509: When a CFR doorhanger is activated via the keyboard, focus its first element.

A11y fix for skyline, OK for beta 14 uplift.
Just this patch.

Comment 24

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/releases/mozilla-beta/rev/3972e1aef6d2

Comment 25

[Liz Henry (:lizzard) (relman/hg->git project)]

Can you file a follow bug here for the remaining work and we can close this one for 70 and 71?
Otherwise this keeps showing up in queries the sheriffs and relman use to see what patches need to land.

Comment 26

[Andrei Oprea [:andreio]]

Done:

• Announce the CFR address bar button appearance to screen reader users, bug 1587809
• Add a screen-reader visible description to the recommendation button, bug 1587808

Hope I didn't miss anything :)

Comment 27

[Julien Cristau [:jcristau] (back April 22)]

Thanks Andrei!

Comment 28

[James Teh [:Jamie]]

Adjusting the summary to reflect what actually got fixed in both 70 and 71.

Comment 29

[Marius Coman [:mcoman], Ecosystem QA]

I have verified that this issue is no longer reproducible with the latest Firefox Nightly (71.0a1 Build ID - 20191010214019) and latest Firefox Beta (70.0b14 Build ID - 20191010142853) installed on Windows 10 x64, Arch Linux and Mac 10.14.5. Now, when the CFR doorhanger is activated via keyboard, the first element from inside of it is focused.

Comment 30

[Phabricator Automation]

Comment on attachment 9097553 [details]
Bug 1576509: Give the CFR address bar button a more descriptive tooltip/a11y label. Announce its appearance to screen reader users.

Revision D47718 was moved to bug 1587809. Setting attachment 9097553 [details] to obsolete.