1649268 - [Accessibility] Ensure multistage about:welcome meets accessibility standards

Status: RESOLVED FIXED

(Firefox :: Messaging System, enhancement, P1)

Description

[Punam Dahiya [:pdahiya]]

Scope of this bug is to run accessibility check on multistage about:welcome including high contrast mode, fix any open issues and ensure multistage welcome meet standards for accessible text

Comment 1

[Emily McMinn :emcminn]

Basic testing steps are:

• Create new profile
• Set browser.aboutwelcome.overrideContent to <JSON> (either in the profile or in about:config)
• Open about:welcome

Comment 2

[Emily McMinn :emcminn]

Attachment: aboutWelcomeSample-a11y.json

The attached JSON can be used to test about:welcome (including Fluent strings) as per the testing steps.

Comment 3

[Marco Zehe (:MarcoZ)]

Here's what I found:

Initial page

The first page of the wizard is OK. There's only some text, and the two buttons for Signing in if I have an account, or Start Setup. Both buttons are properly labeled.

Importing

On the next page, the one where I am offered to import, are a bunch of divs that are tagged with a role of "img", and which contain text like "chrome.google", "amzn", "youtube.youtube" etc. There is no indication what these are or should do. Are these browsers where I can import stuff from, or are these logins that were found in those other browsers? I have no clue.

Theme chooser

Choosing "Not Now", I get to the theme chooser. The buttons are labeled, but it is not indicated which one is selected. These should be converted to proper radio buttons, and the text for the fieldset/legend wrapper for these is already there. Since only one can ever be selected, either dark or light, the normal radio button pattern should definitely be used instead of these two buttons. Note that if you need to style them to look differently, take some inspiration from here to do that accessibly.

In conclusion

Both the second and third screen definitely need work.

Note that this only covers screen reader exposure. Visuals have to be done by a sighted team member. Asa volunteered to do that in a thread in Slack.

Comment 4

[Punam Dahiya [:pdahiya]]

Importing

On the next page, the one where I am offered to import, are a bunch of divs that are tagged with a role of "img", and which contain text like "chrome.google", "amzn", "youtube.youtube" etc. There is no indication what these are or should do. Are these browsers where I can import stuff from, or are these logins that were found in those other browsers? I have no clue.

Thanks Marco for helpful feedback, curious if screen reader was able to pick aria-label and title assigned to image divs container with text as "These sites were found on this device. Firefox does not save or sync data from another browser unless you choose to import it." before reading divs title with site name as "chrome.google", "amzn", "youtube.youtube" etc.

Comment 5

[Marco Zehe (:MarcoZ)]

To answer this, I invited you to the conversation I had on Slack with :emcminn on this subject. tl;dr The aria-label is not being picked up because it is on a generic container. Neither is the title. The tooltip is an anti-pattern for various user groups, and such vital information should not be hidden in a tooltip for said user groups in the first place, but put on the page in plain sight as a paragraph so it is clear to everyone what these are. Also, if the text divs like amzn have titles, because there is text, the title will never be picked up by screen readers. Not even when calculating the name for the parent div that has an img role.

Comment 6

[Emily McMinn :emcminn]

Attachment: JSON for about:welcome (obsolete)

Comment 7

[James Teh [:Jamie]]

I took another look at this:

1. I see there is a nav.steps element at the bottom of the document indicating which step of the process you're at. While the nav element is treated as a "landmark" and this does have an aria-label, NVDA ignores it completely because it contains no content (and landmarks need content to be useful).
   I'm not sure how the indication works visually; it looks like there's no text, so it's hard to come up with a good alternative for screen reader users. Can you explain what this looks like visually and what that tells the user?
2. In bug 1653322, the "These sites were found on this device..." text was apparently made accessible. However, I can't seem to get this to work, either with a clean profile or with the override from comment 2. I see a new override was attached in comment 6, but that was subsequently marked obsolete. Can you provide updated steps to test this?
3. The accessible radio buttons for choosing the theme (as implemented in bug 1653315) work well enough. One minor issue (which I don't consider blocking) is that the labels for these buttons are the title/tooltip, instead of the short labels/text content. For example, the label is "Inherit the appearance of your operating system for buttons, menus, and windows." instead of "Automatic". Ideally, the name should be "Automatic" and the description (secondary info) should be "Inherit the appearance of your operating system for buttons, menus, and windows."
   If you remove the (redundant) aria-label attribute from the parent label element, Firefox will correctly expose the text content as the label; e.g. "Automatic". The problem, though, is that the title isn't exposed as the description because the title attribute is on the label, not the input. This is a bit tricky to solve because you probably need the title attribute on the label visually.
   The best I could come up with was this, but it does duplicate the tooltip:
   <label title="Inherit the appearance of your operating system for buttons, menus, and windows."><input type="radio" aria-description="Inherit the appearance of your operating system for buttons, menus, and windows.">Automatic</label>

NI Asa for any visual a11y feedback.

Comment 8

[Emily McMinn :emcminn]

Jamie, thanks for the feedback! Sorry for the delay. I'll try to answer each point:

1. Visually, the nav steps are shaded markers at the bottom of the page, one for each step of the welcome experience, with the current one shaded to be darker than the others. The aria-label should read "welcome to Firefox, step x of y" - would the aria-label be exposed correctly if we gave the landmark an empty string for content? (I know that works as a trick to get background images to show up.) Alternatively, we could instead give the nav "welcome to Firefox, step x of y" as text content and hide it visually, and remove the aria-label. Do you have a preference/ know which approach would work better?

EDIT: Adding an empty <p/> element to the nav seems to do the trick in VoiceOver, and doesn't affect the nav visually. Would that work?

2. Since requesting this review, we actually made the decision to go with static site suggestions on this step instead of grabbing them from the user's device, so this text was made redundant and removed in bug 1640161. The site icons will still have their names as titles; but the disclaimer text isn't there. Sorry for missing that info!

3. If duplicating the tooltip is okay, then that solution sounds fine to me. I can give it a shot!

I can put these together into a patch; would it be okay if I marked you as a reviewer? Thanks again!

Comment 9

[James Teh [:Jamie]]

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

1. Visually, the nav steps are shaded markers at the bottom of the page, one for each step of the welcome experience, with the current one shaded to be darker than the others.

They're not interactive though, correct? That is, you can't click on them to go back and forth between the steps?

The aria-label should read "welcome to Firefox, step x of y" - would the aria-label be exposed correctly if we gave the landmark an empty string for content?

It already has an empty string, but that essentially means no content. A single space won't do it either, since that'll get stripped out by DOM. A `<br> should do it, though. Hopefully, that works for Mac too; I can't test that myself.

EDIT: Adding an empty <p/> element to the nav seems to do the trick in VoiceOver, and doesn't affect the nav visually. Would that work?

That doesn't work for NVDA, unfortunately. Part of the problem here is that this is an obscure use of landmarks; normally, landmarks contain a block of content. If the `<br> works for Mac, let's go with that. Otherwise, we might have to go with off-screen text, as much as that's a rather ugly hack. :)

2. Since requesting this review, we actually made the decision to go with static site suggestions on this step instead of grabbing them from the user's device, so this text was made redundant and removed in bug 1640161. The site icons will still have their names as titles; but the disclaimer text isn't there. Sorry for missing that info!

I don't know how this looks visually, but I find this really confusing. Essentially, I see this (semantics removed):

Import your passwords, bookmarks, and more
Coming from another browser? It’s easy to bring everything to Nightly.
youtube
facebook

This leaves me wondering: why are these sites listed? I don't have a bookmark or a password saved for them, so how is that relevant? I don't use Facebook, so why is Facebook here?

How is it communicated that these are just "examples" for a sighted user?

I can put these together into a patch; would it be okay if I marked you as a reviewer?

Certainly; I'm happy to review.

Comment 10

[Emily McMinn :emcminn]

I've moved the new fixes into a separate bug so they're easier to review: https://phabricator.services.mozilla.com/D87802 .

The nav steps aren't interactive, only visual. I'm not sure if there is a plan for making them interactive in the future.
I'll try adding a <br> instead of a <p/> as content, hopefully that works for both!

For the import sites, there's no explicit communication that the tiles are only examples. Originally, those five sites were the fallback for a user that had no importable sites. The tiles aren't interactive at all; they're just images (though they do change based on locale, I think it's a "top five most common" kind of thing). Knowing that, would you prefer that the images have no aria-labels and be treated as decorative?

Comment 11

[Asa Dotzler [:asa]]

I've done a visual evaluation of the new multi-stage about:welcome and things look mostly good. I did find a few issues.

The focus indicator on the button is pretty low contrast and may not be visible to some users. This is a bit tricky because the outline is sort of a gradient and the brightest line in the middle of the focus gradient does meet the requirements but it's surrounded by lower contrast pixels that do not meet requirements and the average of the gradient also fails to meet requirements. This technically may not be a failure but it's on the edge.

The only other issues I found were in Windows high contrast mode (Windows Ease of Access settings -> High contrast -> Turn on high contrast.)

The two HCM issues are 1) the button loses its border so it's not obvious it's a button and 2) the pagination indicator disappears completely.

The text label for the button remains and it has a clear call to action ("Start setup" and "Start import") so users should be able to discern that it's clickable but without the button visual affordance, it's not as clear as it could be that it's a button and therefor actionable. Because the text clearly communicates that this is actionable, we may be able to get away without the border but a visible border in HCM would be great to have.

The missing page indicator is also probably not a blocker because it doesn't prevent users from engaging with the main feature, but it would be unfortunate if this indicator wasn't available to low vision users who have enabled Windows HCM.

Comment 12

[James Teh [:Jamie]]

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

The nav steps aren't interactive, only visual. I'm not sure if there is a plan for making them interactive in the future.

Okay. If these are ever made interactive, we'll need to completely revisit this.

For the import sites, there's no explicit communication that the tiles are only examples. Originally, those five sites were the fallback for a user that had no importable sites. The tiles aren't interactive at all; they're just images (though they do change based on locale, I think it's a "top five most common" kind of thing). Knowing that, would you prefer that the images have no aria-labels and be treated as decorative?

While I still find this UX confusing, based on your comment and feedback from others, I don't think this is specific to me as a screen reader user, but is rather an aspect of the UX. If we're showing these to sighted users, we should make them accessible to screen reader users too. If there were some explicit visual indication that these were decorative, that would be different. So let's leave this alone. The UX still bothers me, but general UX is not my domain.

Comment 13

[Emily McMinn :emcminn]

Hi Asa; I made a couple changes around the button contrast + added color inheritance to the indicators which should help them show up in HCM. Unfortunately I don't have a windows machine to test on. Would you mind running the new build and letting me know if it solves the issues? Try build is here: https://hg.mozilla.org/try/rev/2e26ea88380c79348601698739236184664ff33a

Comment 14

[Asa Dotzler [:asa]]

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

Would you mind running the new build and letting me know if it solves the issues? Try build is here: https://hg.mozilla.org/try/rev/2e26ea88380c79348601698739236184664ff33a

Yes! Will do this evening.

Comment 15

[Asa Dotzler [:asa]]

I've run the try build and it looks like the focus indicator on the button is still rgba(10, 132, 255, 0.3) according to dev tools. Strangely, it looks right when I'm using Firefox's dark theme where the indicator seems to be #0A84FF. Also, I see no improvement in the two Windows HCM issues. Could something be awry with the patch or the build I'm testing or some other error on my part?

Comment 16

[Emily McMinn :emcminn]

Hi Asa, it's probably not something you're doing :) the color inheritance can behave strangely. It might be best to take the HCM changes out of this patch and file a separate bug for them, so that someone with a windows build can play with them & find the right combination.

I'll double check the focus indicator and make sure I've got the correct values; thanks for the feedback!

Comment 17

[Emily McMinn :emcminn]

Closing this meta, since all the blocking bugs have been closed. :) Cheers!

Comment 18

[James Teh [:Jamie]]

While I realise a bug hasn't been opened for it yet, the high contrast mode bugs are not fixed yet. A bug needs to be filed for those, which should probably block (and reopen) this metabug. NI Asa to file the HCM bug.

Comment 19

[Asa Dotzler [:asa]]

I've filed bug 1662333 for the visual issues.

Comment 20

[Emily McMinn :emcminn]

Ahh sorry folks for the confusion, that's my fault. 1662143 was filed and triaged yesterday morning, I just forgot to make it blocking. Since it's been triaged already and is on folks' radar, I'll keep that one open. Thanks!

Comment 21

[Emily McMinn :emcminn]

All the blocking bugs have now been resolved, so I'm going to close this meta. Cheers!