Keyboard and general accessibility

[patrickhlauke]

It would be nice if the components also worked for keyboard users (also providing the focus styling defined in the Material Design guidelines) and assistive technologies...

[OscarGodson]

http://www.google.com/design/spec/usability/accessibility.html

[hai-cea]

Yep - totally agree. Working on cleaning up components to account for this. This is done for Icon Buttons and the other components will follow.

Check out http://material-ui.com/ and hit the tab key. :)

[gavrochelegnou]

It would be great to implement aria roles on every widget.
For example on the dialog :
http://www.nczonline.net/blog/2013/02/12/making-an-accessible-dialog-box/
For dropdown menu :
http://staff.washington.edu/tft/tests/menus/html5/
Many examples :
http://heydonworks.com/practical_aria_examples/

[marcysutton]

I would recommend auditing your project with the Chrome Accessibility Developer Tools and reading up on accessibility best practices, there are many issues beyond just keyboard tabbing: https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en

[hai-cea]

Thanks @marcysutton - I'll check it out.

[matthewoates]

https://github.com/rackt/react-a11y should be much more friendly @hai-cea. https://www.youtube.com/watch?v=z5e7kWSHWTg&t=644

[mmrtnz]

@matthewoates Thanks for showing this to us :)

[vujita]

I use a chrome extension that helps detect accessibility. I really want to use this lib, but I need it to be able to pass this tools checks at least

[sshirley]

I totally agree, Vujita. We're currently using Material-UI on a project at work but it's now hurting us because it's far from 508 compliant. Are contributions welcome?

[nathanmarks]

@sshirley Contributions are welcome but this is not a high priority until we get closer to a stable API. (v1.0)

[taddgiles]

I'm trying to understand the current plan on accessibility improvements. The roadmap for the "next" release has "Better accessibility support" on the list, but I don't see accessibility called out in the next milestone or the next project. Is accessibility a priority in the "next" release? If so, are there any details that could be shared? Also, if we wanted to contribute help on accessibility in the "next" release is there a component or area you'd recommend we could work on?

[citelao]

A brief look at some of the components shows that many could be improved fairly easily.

Some things I noticed:

• Modal dialogs and drawers do not lock focus within them, creating a poor experience with keyboard navigation. If it grays out the UI, it should gray constrain keyboard navigation to within. Menus do this fine, so this should be easy to implement.
• Esc does not dismiss popover menus

[oliviertassinari]

Better accessibility is one of the motivations of the ongoing rewrite of Material-UI that will be published under v1. I don't think that there is much value at keeping this issue open. We have learned that accessibility is important and we now try to better support it. Let's stick to specific component issues for the upstream work.
@patrickhlauke Thanks for the feedback ❤️

[mush42]

Hi everyone,

I am a visually impaired developer (relying on a screen reader) using Material UI in my projects. I am really interested in implementing aria-related stuff.

Are you guys accepting pull requests on these issues right now?

[oliviertassinari]

@mush42 we are trying to respect accessibility best practices on the v1-alpha branch. If you find any issue, feel free to report it, or even better, submit a pull request.

[natedsaint]

Has this actually been implemented? We're on 3.9.4 and don't see a clear explanation of how to make things accessible: it does seem anything that utilizes Typography will get the props passed down to the dynamically generated Component that becomes the dom node, so we could theoretically pass any aria-labels down that get passed via ...other (hence https://next.material-ui.com/components/breadcrumbs/#accessibility). Is this the recommended method for all components?

[oliviertassinari]

@natedsaint I'm not sure to understand the link between making the components keyboard accessible (issue description) and having an accessibility section on each page of the documentation. Do you have a specific issue?

[natedsaint]

Sorry let me explain: I originally came upon this via #633, which lead me here, then #168, also closed in favor of this. My assumption was the accessibility issues were to be resolved in one big pass in v1-alpha but I don't see conclusions on that.

[oliviertassinari]

@natedsaint We try to fix the accessibility issues as they are reported. You can find them under https://github.com/mui-org/material-ui/labels/accessibility. Did you discover a new one?

[natedsaint]

The biggest part was this concern from #633: It appears several components dont expose ARIA roles

We're looking into how accessible our site is, and applying aria-labels will fix many issues for us. Digging through the code, it appears that many components use Typography under the covers and you can pass props which end up on the resulting DOM node through ...other in the props, but there are cases where the label or role needs to be on a button. Digging through the code I don't see any places where it's made clear how we make these things reader-accessible, or tag them for usability testing.