Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ARIA roles to tabs - lumino update #132

Merged
merged 14 commits into from
Mar 11, 2021

Conversation

telamonian
Copy link
Member

From the original PR:

This builds on phosphorjs/phosphor#405 to also add ARIA roles to tabs. Merge phosphorjs/phosphor#405 first.

This PR takes all of the work done for phosphorjs/phosphor#406, a PR onto the old phosphor repo, and rebases it onto the latest lumino master.

This PR covers all of the following commits: jasongrout/phosphor@aria-menus...jasongrout:aria-tabs. In theory, all of the other commits listed in phosphorjs/phosphor#406 should be covered by #131, which merged all of the work from phosphorjs/phosphor#405 into lumino.

@jasongrout Can you please take a look and make sure this reflects your original work? Also, what would be a good way to double check that this work is still working as intended in the context of lumino?

@marthacryan
Copy link
Member

Just tried out these changes in JupyterLab - it does add aria roles to the tab bars, although I think there is overlap with this PR: jupyterlab/jupyterlab#9622 that might cause issues. Should we move those changes over to this PR instead? Looks like we'd be able to pass the aria-label to the TabBar, so that should be easy enough to change, but I'm not sure that the roles translate perfectly (for example, in this PR we're adding role="tablist" whereas in that PR we're adding role="navigation") - maybe @manfromjupyter can advise?

There's also a comment on the other PR about an issue with the way these tabs are created that might be good to address as part of this PR: jupyterlab/jupyterlab#9622 (comment)

@manfromjupyter I know you can't try these changes out easily so here's what attributes this PR adds to the tab bars:

  • aria-orientation (horizontal or vertical) - note: the orientation is currently set to horizontal in the side bars in JupyterLab because we're not correctly setting the orientation, so that would need to be fixed on the JL side.
  • role="tablist"
  • aria-label (We'd have to pass this as a parameter when creating the TabBar in JupyterLab)

And these attributes are added to the tabs:

  • id="tab-key-{x}" (for the first tab it'd be id="tab-key-0", second would be "tab-key-1", etc.)
  • role="tab"
  • aria-selected="{true/false}"

Should there be an aria-label attribute added to each tab as well? There is a title attribute that describes each tab's purpose, so I could see that working as a label?

@manfromjupyter
Copy link

manfromjupyter commented Feb 8, 2021

@marthacryan, I am assuming you are referring to this tablist in the screenshot below. If so it doesn't need the aria-orientation. The sidebars shouldn't receive this as their order does not matter to screereaders. It's vertical in design but screenreaders read it horizontally (it's just an unordered list of buttons) and reading it is read the same way (with a down arrow or an eventual tab once we get that working in one of the other open tickets).
tablist above main

The title attribute won't provide details to a screenreader but the text living under each tab should provide the necessary information so do not need the aria-label. Only part I could see overlap with other tickets would be if you wanted to add an aria-label for additional context if we don't think the users have it (ex. include "Notebook" in an aria-label before the "Untitled6.ipynb") because ".ipynb" may not be enough information for first time users or screenreader users.

I agree the aria-selected should be added, and the id's could be helpful but isn't necessary for the screenreader. In simpler words, I advise it be done in this way as shown in https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Tab_Role#example. Don't meant the html structure, it can remain as is, I just mean the attributes used.

The example they provide. Only thing that should change, in my opinion, is the tabs (buttons) in this example have tabindex="-1" but they should still be reachable by the screenreader in case the user wanted to switch to a different tab.

<div class="tabs">
  <div role="tablist" aria-label="Sample Tabs">
    <button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1" tabindex="0">
          First Tab
        </button>
    <button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2" tabindex="-1">
          Second Tab
        </button>
    <button role="tab" aria-selected="false" aria-controls="panel-3" id="tab-3" tabindex="-1">
          Third Tab
        </button>
  </div>
  <div id="panel-1" role="tabpanel" tabindex="0" aria-labelledby="tab-1">
    <p>Content for the first panel</p>
  </div>
  <div id="panel-2" role="tabpanel" tabindex="0" aria-labelledby="tab-2" hidden>
    <p>Content for the second panel</p>
  </div>
  <div id="panel-3" role="tabpanel" tabindex="0" aria-labelledby="tab-3" hidden>
    <p>Content for the third panel</p>
  </div>
</div>

Side Note: The aria-labeledby looks for the id of ex "tab-1" and grabs the text under it and that becomes the label for the panel (provides the added benefit of users knowing what the panel is called when jumping to it). Because a console, launcher, notebook, etc all will look differently and different ones may be open by default based on what one was open last it will save time and provide that much needed context for the screenreader users.

Copy link
Member

@marthacryan marthacryan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After discussion on the conflicts between this PR and the JupyterLab PR, I think this PR's aria labels are correct and this PR is ready to merge. I tested locally and it worked well - we should still look into the issue with tab bars I mentioned above, but that can be in a later PR. Thanks!

Copy link
Contributor

@blink1073 blink1073 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@blink1073 blink1073 merged commit e22c22f into jupyterlab:master Mar 11, 2021
@blink1073
Copy link
Contributor

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants