1384822 - Disable onboarding feature in v56 branch for accessibility user

Status: RESOLVED WONTFIX

(Firefox :: New Tab Page, enhancement, P1)

Description

[[e-mail]]

As discussion with UX and PM, we'd like mitigate the impact of accessibility features for 8/2 code freeze. We can ship v56 with new accessibility-enabled addon version if we want.


The current state is the fox icon is not accessible but the button in notification will be accessible as the last item in the page. If User tap the button, the dialog is still unaccessible.

Comment 1

[[e-mail]]

Since accessibility reader is only running on single-process,
We can disable onboarding if firefox is running in single-process.

Comment 2

[[e-mail]]

As second thought, rely on `single-process` might filter out more users than the screen reader users.
Is there a suggest way to disable onboarding for screen reader users?

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

As I said during the meeting, I guess `aria-hidden` will enough? Anyway, Yura can confirm.

A bit more context here, since comment 0 is not really clear: I just found out that tour-overlay-opening buttons are accessible, but tour overlay itself is not. It's an unfortunately state where we will trap keyboard users in the overlay with no way out. Hence the suggestion to make sure everything is not visible, at least for Beta 56. We can get things uplifted to it if we done all the accessibility work on Nightly 57 and feel safe to do so, before Release 56.

If it's not possible to hide everything from accessibility technologies, I guess the next best thing would be at least make sure open and close buttons are accessible.

Comment 4

[Yura Zenevich [:yzen] (please use "needinfo")]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #3)
> As I said during the meeting, I guess `aria-hidden` will enough? Anyway,
> Yura can confirm.
> 
> A bit more context here, since comment 0 is not really clear: I just found
> out that tour-overlay-opening buttons are accessible, but tour overlay
> itself is not. It's an unfortunately state where we will trap keyboard users
> in the overlay with no way out. Hence the suggestion to make sure everything
> is not visible, at least for Beta 56. We can get things uplifted to it if we
> done all the accessibility work on Nightly 57 and feel safe to do so, before
> Release 56.
> 
> If it's not possible to hide everything from accessibility technologies, I
> guess the next best thing would be at least make sure open and close buttons
> are accessible.

From the technical standpoint aria-hidden does not affect keyboard navigation. It only hides part of the DOM tree from screen readers. So the solution for keyboard would be separate from aria-hidden. 

I think from the risk perspective disabling things for screen readers and keyboard is on the same level as making the UI actually accessible, what is different is the amount of the actual work and the size of the changes. I would suggest and am willing to for 56/57, if possible, to work on and land a11y improvements to onboarding (even after the 8/2). In case there's going to be a risk of not shipping accessible onboarding for 56, I can help with disabling it and landing it in beta? 

Reviews have been fast so far so if that carries on after branching it should be doable.

Comment 5

[[e-mail]]

As yura's comment, making UI accessible or hiding all accessibility feature has similar risk, 

Since we will work on the a11y support anyway (after 8/2), we could address this as known issue and wait for all a11y bug fixed and decide if we want uplift a11y changes to beta or disable a11y at beta v56.

Comment 6

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

This is an assigned P1 bug without activity in two weeks. 

If you intend to continue working on this bug for the current release/iteration/sprint, remove the 'stale-bug' keyword.

Otherwise we'll reset the priority of the bug back to '--' on Monday, August 28th.

Comment 7

[[e-mail]]

Since related bugs are uplifted to 56 beta, we don't need disable onboarding a11y in v56 \o/.

Comment 8

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

Closing this flag based on comment 7.