Accessibility / a11y¶

Background info¶

Local coding projects should schedule an accessibility plan review with UX early in the project.
Part of that plan will likely be to schedule an internal review with UX towards the end of the project.
Most projects should, coordinated through UX, schedule a formal review by MIT Assistive Technology Information Center (ATIC) towards the end of the project. The process and expectations for this should be discussed during the initial accessibility plan review.
Use valid html 5 and our style guide to start out with a great baseline for accessible websites.
Run some local checks throughout your development process to fix any issues you can as they come up, but don’t stress about trying to pass every test on your own.
Ask UX if something concerns you that you can’t fix on your own so they can determine if they want to help now, or wait for the accessibility review at the end of the project.
Accessibility reviews from UX and ATIC will provide guidance on resolving any issues before or shortly after a project goes into production.

Discuss with UX whether an accessibility review is appropriate and who will lead the review.

All of our public GitHub repos are set to automatically check via AccessLint, which is great for what it is but is not a comprehensive Accessibility Plan.

The Web Accessibility Evaluation Tool (WAVE) is useful for checking single web pages. It can be installed as a browser extension for either Chrome or Firefox.
The Accessible Name & Description Inspector (ANDI) tool is a Javascript tool to evaluate a loaded webpage.
A screenreader like VoiceOver for the Mac or NVDA for Windows can be useful for user testing to confirm that elements are reachable, or that interactions will play out as expected. Articles like “Testing with Screen Readers” at WebAIM are also useful.