1850801 - The onboarding Shopping sidebar is not easily discoverable with a screen reader

Status: RESOLVED FIXED

(Firefox :: Messaging System, defect, P1)

Description

[Anna Yeddi [:ayeddi]]

Preconditions:

• Set the browser.shopping.experience2023.enabled - TRUE
• Set the browser.shopping.experience2023.optedIn - 0
• Turn on a screen reader (i.e. NVDA on Windows OS)

Steps to reproduce:

1. While the screen reader is running, reach the following link: https://www.amazon.com/dp/B07V6ZSHF4?th=1
2. Observe the announcement made by a screen reader

Expected result:

• The user who cannot see the screen is made aware that there is an opt-in message:
  • the screen reader announced the text of the opti-in message
  • (preferred) and the keyboard focus is placed on the Yes, try it control (so pressing Enter would activate this control)

Actual result:

• Screen reader is not announcing the opt-in message and the user who cannot see the sidebar would not be aware that there is, in fact, a new feature sidebar available for them to use (the screen reader would read the sidebar info at the very end of announcing the entire long product page content)
  • NVDA user feedback:

It turns out that it [the sidebar] did appear. I didn't realise it was a sidebar and there was no indication it had appeared, so I had no indication that I needed to focus the sidebar with f6 to access it. We probably need to figure out how to fix that; e.g. role="alert" or something so that it gets reported like doorhanger alerts.

Recommended solution:

1. Move the programmatic (and visual) focus to the Yes, try it button on the sidebar when the sidebar appears for the user and shows the opt-in message. Make sure to keep the role=alertdialog ARIA role on the message container so the message is announced by a screen reader when the focus lands on the container's control.

Comment 1

[Negin]

Hm seems like the container does have role=alertdialog so I'm a bit unsure of why it's not being announced to the SR until the end. I'll do some investigation, thanks for flagging this! Does it need aria-modal attribute as well? I'm not sure if the sidebar counts as a traditional modal but it seems to be a requirement for alertdialog if I'm understanding correctly.

<main class="screen FS_OPT_IN " role="alertdialog" pos="split" tabindex="-1" aria-labelledby="mainContentHeader">
...

Comment 2

[Anna Yeddi [:ayeddi]]

(In reply to Negin from comment #1)

Hm seems like the container does have role=alertdialog so I'm a bit unsure of why it's not being announced to the SR until the end. I'll do some investigation, thanks for flagging this!

<main class="screen FS_OPT_IN " role="alertdialog" pos="split" tabindex="-1" aria-labelledby="mainContentHeader">
...

Negin,
This is an expected behavior per ARIA specs for alertdialog:

Unlike alert, alertdialog can receive a response from the user. For example, to confirm that the user understands the alert being generated. When the alert dialog is displayed, authors SHOULD set focus to an active element within the alert dialog, such as a form control or confirmation button.
So by moving the focus on to the button, we'll just complete the requirement so the SR via our Accessibility API would get a signal to announce the content of the dialog.

Comment 3

[Negin]

(In reply to Anna Yeddi [:ayeddi] from comment #2)

(In reply to Negin from comment #1)

Hm seems like the container does have role=alertdialog so I'm a bit unsure of why it's not being announced to the SR until the end. I'll do some investigation, thanks for flagging this!

<main class="screen FS_OPT_IN " role="alertdialog" pos="split" tabindex="-1" aria-labelledby="mainContentHeader">
...

Negin,
This is an expected behavior per ARIA specs for alertdialog:

Unlike alert, alertdialog can receive a response from the user. For example, to confirm that the user understands the alert being generated. When the alert dialog is displayed, authors SHOULD set focus to an active element within the alert dialog, such as a form control or confirmation button.
So by moving the focus on to the button, we'll just complete the requirement so the SR via our Accessibility API would get a signal to announce the content of the dialog.

Ah my mistake, I misunderstood the requirement and the specs. Thanks for the quick response and clarity!

Comment 4

[Punam Dahiya [:pdahiya]]

(In reply to Anna Yeddi [:ayeddi] from comment #0)

Expected result:

• The user who cannot see the screen is made aware that there is an opt-in message:
  • the screen reader announced the text of the opti-in message

@ayeddi just clarifying, will changing role=alertdialog to role="alert" suffice above ask that is screen reader will announce opt-in message at the beginning and meets accessibility requirements. I understand it's not preferred solution but wanted to clarify incase recommended solution implementation turns out to be complex for MVP. Thanks!

• (preferred) and the keyboard focus is placed on the Yes, try it control (so pressing Enter would activate this control)

Comment 5

[Anna Yeddi [:ayeddi]]

(In reply to Punam Dahiya [:pdahiya] from comment #4)

(In reply to Anna Yeddi [:ayeddi] from comment #0)

Expected result:

• The user who cannot see the screen is made aware that there is an opt-in message:
  • the screen reader announced the text of the opti-in message

@ayeddi just clarifying, will changing role=alertdialog to role="alert" suffice above ask that is screen reader will announce opt-in message at the beginning and meets accessibility requirements. I understand it's not preferred solution but wanted to clarify incase recommended solution implementation turns out to be complex for MVP. Thanks!

• (preferred) and the keyboard focus is placed on the Yes, try it control (so pressing Enter would activate this control)

@pdahiya, it should suffice, but we would still need to test the implementation in both cases. Thank you for clarifying that!

Comment 6

[Negin]

Attachment: Bug 1850801 - The onboarding Shopping sidebar is not easily discoverable with a screen reader

Comment 7

[Negin]

Hi Anna! Using alert resolves the issue for NVDA/Windows. But using MacOS and the default/built-in accessibility VO - the sidebar content is still read at the end despite the change (unless I'm testing this incorrectly). I'm curious if you have any context into MacOS and whether a follow-up bug should be filed to further investigate?

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eda29eca9d6a
The onboarding Shopping sidebar is not easily discoverable with a screen reader r=omc-reviewers,emcminn

Comment 9

[Cristina Horotan [:chorotan]]

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

Comment 11

[Anna Yeddi [:ayeddi]]

:Negin, I've been trying to verify the fix on Windows and check the macOS behavior, but I cannot seem to trigger the sidebar to auto-open (the config is set to enabled but 0 for opted in prefs, as it's mentioned in the STR) - I had to manually activate the action button on the awesomebar to open the sidebar. Is it expected behavior now or what can I do for the sidebar to auto open with the opt-in invitation? Thank you in advance :)

Comment 12

[Shane Hughes [:aminomancer]]

(In reply to Anna Yeddi [:ayeddi] from comment #11)

:Negin, I've been trying to verify the fix on Windows and check the macOS behavior, but I cannot seem to trigger the sidebar to auto-open (the config is set to enabled but 0 for opted in prefs, as it's mentioned in the STR) - I had to manually activate the action button on the awesomebar to open the sidebar. Is it expected behavior now or what can I do for the sidebar to auto open with the opt-in invitation? Thank you in advance :)

Are you following the test plan exactly? Firefox only tries to auto-open the sidebar up to twice, and only once per 24 hours, so the steps may not work on an existing profile.

Comment 13

[Rares Doghi, Desktop QA]

Hi @Anna, the sidebar is being read out loud by the NVDA but its not focused on the "Yes Try it" button. Is that no longer a requirement ?

Comment 14

[Anna Yeddi [:ayeddi]]

(In reply to Rares Doghi, Desktop QA from comment #13)

Hi @Anna, the sidebar is being read out loud by the NVDA but its not focused on the "Yes Try it" button. Is that no longer a requirement ?

Focusing the Yes, try it is not a requirement for accessibility. Ideally, the Close button would be focused, but since the alert is announced, that is acceptable approach too.

Thank you for the investigation!

Comment 15

[Anna Yeddi [:ayeddi]]

Attachment: NVDA_speech_viewer_announcement_when_PDP_first_opened_and_onboarding_sidebar_is_shown.png

When the sidebar first opened, the alert is announced by a screen reader and then, for instance, NVDA proceeds with reading the title of the dialog and its included controls, as pictured