1593649 - Accessibility problems on the Recommendations page

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect, P1)

Description

[Marco Zehe (:MarcoZ)]

STR, with the NVDA screen reader:

1. Open about:addons.
2. Make sure the Recommendations tab is selected (first of the list items).
3. Tab into the main chrome, where the search field is.

This has several problems:

The screen reader speaks a long chrome:// URL as the document area is being entered

This is due to the iframe that this inner document layer has not being labeled with a title attribute.

Problems with the "Search addons.mozilla.org" label

The virtual buffer does not show the text label or search button of the search field. Screen readers speak it only when tabbing to it because of the place holder, and when in focus mode. There is a label which also has a for attribute pointing to the search field, but the label has no text. The only thing that labels the field is the place holder which disappears as one starts typing.

The most clean solution would be to transfer that label to the actual label tag. That way, it would always stay visible, improving the experience for people with cognitive disabilities.

Problems with the More Options menu button

1. The More Options button next to the "Personalize your Nightly" heading is unlabeled.
2. The menu that this button opens works, but pressing Escape does not restore focus to the button when the menu closes. A similar technique should be used to manage focus as in one part of bug 1567600 for the add-ons list.

The different add-on tiles should be headings, so users can easily navigate to them

Similar techniques as in bug 567600 for the add-on tiles on the Extensions page should be employed. I realize that these branch out to AMO, which is a different team, but the front-end bits should be made more accessible here and possibly mirror the experience from the Extensions tab, for consistency.

Comment 1

[Mark Striemer [:mstriemer]]

I think these are mostly regressions from bug 1594392 but the cards themselves using headings was missed when we changed the other cards to use headings.

(In reply to Marco Zehe (:MarcoZ) from comment #0)

Problems with the "Search addons.mozilla.org" label

The virtual buffer does not show the text label or search button of the search field. Screen readers speak it only when tabbing to it because of the place holder, and when in focus mode. There is a label which also has a for attribute pointing to the search field, but the label has no text. The only thing that labels the field is the place holder which disappears as one starts typing.

The most clean solution would be to transfer that label to the actual label tag. That way, it would always stay visible, improving the experience for people with cognitive disabilities.

The Extensions and Themes tabs have a label for the search box: "Find more extensions" and "Find more themes" respectively. Do you think adding a "Find more add-ons" label on all the other pages would help here? I'd also be okay with having the placeholder as the label, I'd just want to check with product before we change the strings on Extensions and Themes if those cases are okay.

Problems with the More Options menu button

1. The More Options button next to the "Personalize your Nightly" heading is unlabeled.
2. The menu that this button opens works, but pressing Escape does not restore focus to the button when the menu closes. A similar technique should be used to manage focus as in one part of bug 1567600 for the add-ons list.

I wonder if 2. is platform specific, it works for me on Mac when closing the menu either with Escape or pressing Space/Enter on one of the items in the list. I changed how this worked in the header patch, so that if the menu was opened with the keyboard it would refocus the button that opened it when it was closed. I'll make sure we have a test for this.

The different add-on tiles should be headings, so users can easily navigate to them

Similar techniques as in bug 567600 for the add-on tiles on the Extensions page should be employed. I realize that these branch out to AMO, which is a different team, but the front-end bits should be made more accessible here and possibly mirror the experience from the Extensions tab, for consistency.

These are part of Firefox, similar to the cards on the list/details views, but have a different template that was missed in bug 1567600.

Comment 2

[Itiel]

(In reply to Mark Striemer [:mstriemer] from comment #1)

I think these are mostly regressions from bug 1594392

I'm pretty sure you mean bug 1525175 :-)

Comment 3

[Mark Striemer [:mstriemer]]

Sigh, thanks.

Comment 4

[Marco Zehe (:MarcoZ)]

(In reply to Mark Striemer [:mstriemer] from comment #1)

(In reply to Marco Zehe (:MarcoZ) from comment #0)

Problems with the "Search addons.mozilla.org" label

The virtual buffer does not show the text label or search button of the search field. Screen readers speak it only when tabbing to it because of the place holder, and when in focus mode. There is a label which also has a for attribute pointing to the search field, but the label has no text. The only thing that labels the field is the place holder which disappears as one starts typing.

The most clean solution would be to transfer that label to the actual label tag. That way, it would always stay visible, improving the experience for people with cognitive disabilities.

The Extensions and Themes tabs have a label for the search box: "Find more extensions" and "Find more themes" respectively. Do you think adding a "Find more add-ons" label on all the other pages would help here? I'd also be okay with having the placeholder as the label, I'd just want to check with product before we change the strings on Extensions and Themes if those cases are okay.

Yes, the other labels work fine, so if we could get this on the other pages, that would be good.

Problems with the More Options menu button

1. The More Options button next to the "Personalize your Nightly" heading is unlabeled.
2. The menu that this button opens works, but pressing Escape does not restore focus to the button when the menu closes. A similar technique should be used to manage focus as in one part of bug 1567600 for the add-ons list.

I wonder if 2. is platform specific, it works for me on Mac when closing the menu either with Escape or pressing Space/Enter on one of the items in the list. I changed how this worked in the header patch, so that if the menu was opened with the keyboard it would refocus the button that opened it when it was closed. I'll make sure we have a test for this.

The other menu you improved in bug 1567600 still work, it's this specific one on the Find New Add-Ons page that doesn't work like the others.
Having a test for this for all menus would be good, since then this cannot regress again.

Comment 5

[Mark Striemer [:mstriemer]]

Attachment: Bug 1593649 - Part 1: Fix a11y issues with about:addons header/recommendations r?robwu,rpl

Add a proper title and popup attributes to page-options button.
Make recommended card's add-on names headings.
Give the HTML pane a title so it reads better in screen readers.
Always include a label for the search box.
Clarify the label on the extension enable checkbox.

Comment 6

[Mark Striemer [:mstriemer]]

(In reply to Marco Zehe (:MarcoZ) from comment #4)

(In reply to Mark Striemer [:mstriemer] from comment #1)

(In reply to Marco Zehe (:MarcoZ) from comment #0)

Problems with the More Options menu button

1. The More Options button next to the "Personalize your Nightly" heading is unlabeled.
2. The menu that this button opens works, but pressing Escape does not restore focus to the button when the menu closes. A similar technique should be used to manage focus as in one part of bug 1567600 for the add-ons list.

I wonder if 2. is platform specific, it works for me on Mac when closing the menu either with Escape or pressing Space/Enter on one of the items in the list. I changed how this worked in the header patch, so that if the menu was opened with the keyboard it would refocus the button that opened it when it was closed. I'll make sure we have a test for this.

The other menu you improved in bug 1567600 still work, it's this specific one on the Find New Add-Ons page that doesn't work like the others.
Having a test for this for all menus would be good, since then this cannot regress again.

So I wrote up a patch for these issues, still unsure about what's up with this button. It always worked for me on Mac and Windows. When I tested with NVDA enabled on Windows though, it no longer worked. I found a GitHub issue [1] but I can't tell if they have some code that NVDA is preventing from working (which seems like is happening here) or if NVDA is supposed to do this automatically.

For now my patch doesn't fix this since it seems like it will require some more digging and I don't want that to block the other improvements we can make here.

[1] https://github.com/nvaccess/nvda/issues/7836

Comment 7

[James Teh [:Jamie]]

The problem with the menu button is that when it's activated by NVDA:

1. It doesn't focus the first menu item. We can probably live with this, though.
2. If you press down arrow and then escape, a11y focus ends up on an <addon-page-options> element. Poking with the console, it looks like DOM focus is still on the <panel-item> for the item selected with down arrow. I'm not actually sure how that's possible, given that the item is now hidden, but that's what I'm seeing. A11y is bouncing that focus up to <addon-page-options> because the subtree is inaccessible once hidden. NVDA doesn't switch back to browse mode because <addon-page-options> has a generic a11y role, which doesn't meet NVDA's criteria for a browse mode switch.

Note that if you activate the button from the keyboard, this all works as expected. And this is the crux of the problem. In browse mode, NVDA doesn't send a key press when you press space or enter; it simulates a mouse click. The reasons for this are messy, but in short, NVDA has to deal with the fact that the web is often ugly and many controls don't implement keyboard functionality correctly. NVDA can't know whether a control has proper keyboard support or not, so it always clicks, since the functionality should normally be equivalent. Note that you'll see the same behaviour with other screen readers as well. Even with voiceOver, many users will press VO+space instead of space, since VoiceOver users are taught to do most things using VoiceOver commands.

I imagine you're trying to differentiate between keyboard and mouse here due to focus styling, so fixing this without breaking that is going to be tricky.

Comment 8

[Mark Striemer [:mstriemer]]

Ah, I didn't realise that. It currently checks if the source is from the keyboard, so that would indeed be the issue. The code is there to focus the first menu item, sounds like removing the input source check will sort things out in NVDA.

Thanks for the info!

Comment 9

[Mark Striemer [:mstriemer]]

Attachment: Bug 1593649 - Part 2: Always set focus as if using the keyboard r?rpl

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ea1e107e1a59
Part 1: Fix a11y issues with about:addons header/recommendations r=robwu,rpl,fluent-reviewers,flod
https://hg.mozilla.org/integration/autoland/rev/a3ecf85a806a
Part 2: Always set focus as if using the keyboard r=rpl

Comment 11

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/ea1e107e1a59
https://hg.mozilla.org/mozilla-central/rev/a3ecf85a806a

Comment 12

[Alex Cornestean]

Hello,

Verified the fix on the latest Beta (72.0b5/20191210230245) under Windows 10 Pro 64-bit and MacOS Catalina 10.15 using NVDA screen reader and the built in Voice Over function on MacOS.

The areas checked for the bug fix are the ones mentioned in Comment 5 with the following results:

• the More Options button on the right side of the “Personalize Your Firefox” heading is now properly labeled. The menu list can be accessed with both Enter and Space when the button is focused. Both NVDA and Voice Over properly list the items in the menu. The list can be collapsed with the Escape key and focus will be restored on the More Options button.
• themes and add-ons names are now heading and properly identified by screen readers
• the search box is properly labeled
• the HTML panel has a title which is correctly identified by screen readers