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

Accessibility audit #911

Open
annabu opened this issue Sep 20, 2016 · 10 comments

Comments

Projects
None yet
8 participants
@annabu
Copy link

commented Sep 20, 2016

WIP Notes (proper audit tbd)

  • Colors should be audited to be AA compliant (they need to be correct color ratio for the given font size - https://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-contrast)
  • Tabbing should take you to the expected section (and there should be a visual cue i.e. focus state) that lets you know.
  • Icons should have labels (even if they are hidden so that screen readers can read it if necessary).
  • Colors should not indicate "state" (color blind people will not be able to see red is an error, green is success). Help text and descriptions should be present.
  • Reassess tabindex (file menu has a tabindex=-1 which is what the user expects to get to first when they tab)
@ivanov

This comment has been minimized.

Copy link
Member

commented Sep 20, 2016

Thanks for getting the ball rolling on this, @annabu - we need all the help we can get not being familiar with this kind of stuff.

@willingc

This comment has been minimized.

Copy link
Contributor

commented Sep 20, 2016

@annabu Thanks for taking this on ☀️

@annabu

This comment has been minimized.

Copy link
Author

commented Sep 22, 2016

For the audit, the big take away is that you cannot successfully use the application without a mouse and that not everything is labeled. Main fixes I see right now are:

  1. Add aria elements to markup to help screen readers (See: http://heydonworks.com/practical_aria_examples/)
    • buttons and icons should have aria-label (title attributes does not suffice for accessibility)
    • add aria to reference context (see example link)
    • add aria-hidden for content that does not need to be read by screen readers
  2. Make sure everything has a focus state (http://a11yproject.com/posts/never-remove-css-outlines/)
  3. Fix tab order for elements (easier once we get the focus state back in, but the success would be taking all primary actions without using a mouse).

Just some consideration moving forward for things that are built:

I recommend that people also download this chrome extension. It lets you audit the page you're in and see what accessibility problems there are on the page: bit.ly/a11y-devtools

@annabu annabu changed the title [wip] accessibility audit Accessibility audit Sep 22, 2016

@willingc

This comment has been minimized.

Copy link
Contributor

commented Sep 22, 2016

@annabu Thanks for doing the audit and sharing your tips on tools and resources too. 🌻

For all, there's also a very good guide re: accessibility at the US Government's 18F site: https://pages.18f.gov/accessibility/

@jasongrout jasongrout referenced this issue Sep 28, 2016

Closed

Fix keyboard interactions for dialogs #1001

0 of 3 tasks complete
@jasongrout

This comment has been minimized.

Copy link
Contributor

commented Sep 28, 2016

Make sure everything has a focus state (http://a11yproject.com/posts/never-remove-css-outlines/)
Fix tab order for elements (easier once we get the focus state back in, but the success would be taking all primary actions without using a mouse).

+1! I've found this very frustrating that we don't show focus state and that tabIndex settings are kind of weird, especially for dialogs. I opened #1001 to deal with keyboard issues for dialogs.

@ellisonbg ellisonbg added this to the 1.0 milestone Oct 13, 2016

@annabu

This comment has been minimized.

Copy link
Author

commented Oct 17, 2016

Here's a good read for why you shouldn't ever clear the focus state: https://sarbbottam.github.io/accessibility,/css/2016/09/29/keyboard-accessibility-and-lost-focus/

@ivanov

This comment has been minimized.

Copy link
Member

commented Jul 17, 2017

cross linking jupyter/notebook#1801 - specifically this comment

@Neurrone

This comment has been minimized.

Copy link

commented Jul 17, 2017

@ivanov will be happy to provide more detail than that comment if it helps.

@jasongrout jasongrout removed this from the 1.0 milestone Sep 5, 2018

@saulshanabrook saulshanabrook added this to the Future milestone Sep 10, 2018

@shshkr

This comment has been minimized.

Copy link

commented May 13, 2019

HTML Color Contrast Tool
I created a general tool for calculating contrast ratio from html files. While it still needs some improvement, I thought this tool could be helpful in the initiative to make JupyterLab more accessible.

@Neurrone

This comment has been minimized.

Copy link

commented May 13, 2019

Some other useful things:

  • Axe, an open source engine that does automated accessibility checks to catch low hanging fruit. It can be run manually on a page by using the Axe extensions for Chrome and Firefox.
  • React-Axe, which runs Axe automatically when the DOM changes. This is extremely useful during development.
  • The jsx a11y EsLint plugin has some overlap, but has some rules of its own not covered by Axe. This provides faster feedback, as it appears in your IDE.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.