1764137 - Use correct aria-role for the synced-tabs setup flow

Status: RESOLVED FIXED

(Toolkit :: UI Widgets, defect, P2)

Description

[Sam Foster [:sfoster] (he/him)]

We're currently using the NamedDeck for this sequence of steps. But as this is currently used exclusively for tabbed panels it hard-codes a role of "tabpanel" and a linked button, which isn't applicable in this case.

One solution would be to make NamedDeck a more generic base class and create a more tab-ish element for those tab cases.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 3

[James Teh [:Jamie]]

Moving back to Firefox: General, as this is not an issue with the APIs themselves.

Comment 4

[Sam Foster [:sfoster] (he/him)]

(In reply to Sam Foster [:sfoster] (he/him) from comment #0)

One solution would be to make NamedDeck a more generic base class and create a more tab-ish element for those tab cases.

Moving this to XUL widget, I think those are the next steps.

Comment 5

[Sarah Clements [:sclements]]

Morgan, I could use advice on what the most appropriate aria role for the sync tabs setup flow should be (see first three steps in the figma [here])(https://www.figma.com/file/SE4xHgOW84yLiv7vFugm9R/Firefox-View-Stepping-Stone?node-id=1954%3A27936). Would role=dialog make sense?

Comment 6

[Morgan Reschenberg [:morgan]]

I'm gonna toss this over to our a11y front-end engineer who just got back from leave -- Anna, what do you think?

Comment 7

[Sarah Clements [:sclements]]

Regarding a potential solution to making the NamedDeck component more reusable, a quick fix would be to add this condition here, which is what the NamedDeckButton component does (in the same file). And then we'd pass whatever role UX deems appropriate into the named-deck element in firefoxview.html.

      if (!this.hasAttribute("role")) {
        view.setAttribute("aria-labelledby", `${this.id}-button-${name}`);
        view.setAttribute("role", "tabpanel");
      }

Comment 8

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

(In reply to Sarah Clements [:sclements] from comment #5)

Morgan, I could use advice on what the most appropriate aria role for the sync tabs setup flow should be (see first three steps in the figma [here])(https://www.figma.com/file/SE4xHgOW84yLiv7vFugm9R/Firefox-View-Stepping-Stone?node-id=1954%3A27936). Would role=dialog make sense?

Hi Sarah,

I think the tabs setup/sync flow does not need a role of dialog, because this flow is embedded in the page and does not require any specific navigation for a user.

The Fx Checklist component could be role="region" for some encapsulation, but the most important part would be to mark the Progress Bar component as such by either HTML5 <progress> element/WAI example or ARIA role="progressbar"/on MDN.*

I hope that helps, but let me know if I can provide any further information.

*updated to add examples

Comment 9

[Sarah Clements [:sclements]]

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

(In reply to Sarah Clements [:sclements] from comment #5)

Morgan, I could use advice on what the most appropriate aria role for the sync tabs setup flow should be (see first three steps in the figma [here])(https://www.figma.com/file/SE4xHgOW84yLiv7vFugm9R/Firefox-View-Stepping-Stone?node-id=1954%3A27936). Would role=dialog make sense?

Hi Sarah,

I think the tabs setup/sync flow does not need a role of dialog, because this flow is embedded in the page and does not require any specific navigation for a user.

to confirm I'm understanding you correctly - the set up flow containers (steps 1 - 3 in figma "mobile tabs in progress") don't need a role whatsoever, only certain elements do such as the progress bar element you mentioned?

The Fx Checklist component could be role="region" for some encapsulation, but the most important part would be to mark the Progress Bar component as such by either HTML5 <progress> element/WAI example or ARIA role="progressbar"/on MDN.*

I'm not certain I understand what is meant by the checklist component. When I click on that figma link I see the "mobile tabs in progress step 2" with the "Sync Firefox on your phone or tablet" under Tab Pickup section.... are you referring to that whole component?

Comment 10

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

Attachment: Fx Checklist component.png

(In reply to Sarah Clements [:sclements] from comment #9)

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

(In reply to Sarah Clements [:sclements] from comment #5)

Morgan, I could use advice on what the most appropriate aria role for the sync tabs setup flow should be (see first three steps in the figma [here])(https://www.figma.com/file/SE4xHgOW84yLiv7vFugm9R/Firefox-View-Stepping-Stone?node-id=1954%3A27936). Would role=dialog make sense?

Hi Sarah,

I think the tabs setup/sync flow does not need a role of dialog, because this flow is embedded in the page and does not require any specific navigation for a user.

to confirm I'm understanding you correctly - the set up flow containers (steps 1 - 3 in figma "mobile tabs in progress") don't need a role whatsoever, only certain elements do such as the progress bar element you mentioned?

Correct, because the containers are placed within another content that remains available for users during the process (the dialog would work more like an overlay or like on the about:welcome page it would take over the entire page instead, plus the welcome page allows).

The Fx Checklist component could be role="region" for some encapsulation, but the most important part would be to mark the Progress Bar component as such by either HTML5 <progress> element/WAI example or ARIA role="progressbar"/on MDN.*

I'm not certain I understand what is meant by the checklist component. When I click on that figma link I see the "mobile tabs in progress step 2" with the "Sync Firefox on your phone or tablet" under Tab Pickup section.... are you referring to that whole component?

This is the component I was also referring to. For me the entire Figma page/node would open with all 3 steps of the flow, so I dug into the component level and used the component's name from the file to refer to it. The screenshot of that specific component that is Fx Checklist in Figma is attached. This is the section of the Firefox View that we are talking about, right? The rest of the page does not change within this Figma node/page.

While the stepper from the about:welcome page could be somehow reused in the Fx View, I think the progressbar does describe the component much better and would correspond better with it visual appearance and the %% completed pattern used. This should not affect consistency of components within the Firefox for that same reason - the components appear visually different and do function differently as well.

I hope this helps.

Comment 11

[Sarah Clements [:sclements]]

Ray, can you give this a priority please?

The progress bars in the mobile setup flow (see screenshot in the comment above) are already using the correct semantic elements per comment 8, so the only thing to do here is to remove the role=tabpanel from the setup flow containers since this is incorrect and might be confusing for screen reader users.

Note to self: We might still want to give this a role=region so it matches what the Tab Pickup list has.

Comment 12

[Sarah Clements [:sclements]]

Attachment: Bug 1764137 - Add correct aria-roles to named-deck in firefoxview r=Gijs

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/33a3e6eafcdb
Add correct aria-roles to named-deck in firefoxview r=Gijs

Comment 14

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/33a3e6eafcdb