Accessibility

Background info

Accessibility (shortened as a11y) is a primary consideration in our design and engineering processes. By foregrounding accessibility, we intend to make our web properties more equitable and usable for everyone.

The Libraries’ Accessibility Team (LAT), established in 2023, has adopted Inclusive Design as one of its guiding principles. Inclusive Design is similar to Universal Design, in that both explore the idea of meeting as many people’s needs as possible. Inclusive Design focuses more on individual needs, and acknowledges that multiple design approaches may be required to meet this goal.

We consider Inclusive Design to be an inherently aspirational goal, as more can always be done. This is also what makes it a useful framing device for accessibility work. The human experience is incredibly diverse, and a single design is not likely to meet every person’s needs. We can always strive to do better.

Goals

  • The site is usable by everyone.

  • The site meets as many people’s accessibility needs as possible.

  • Anyone that is authorized to use a site can actually use it.

    • Intentional access restrictions (like ‘MIT users only’) are okay.

  • The site is compliant with WCAG 2.1 AA guidelines.

Local software projects

Local projects should include an accessibility review. This should be added to the project timeline as early as possible in the scheduling process. The review plan should include a formal review by Disability and Access Services towards the end of the project. The process and expectations for this should be discussed during the initial accessibility planning, but it has typically gone as follows:

  • We develop an accessibility testing script (usually completed by someone in UXWS) and reach out to our contacts at DAS;

  • We meet with DAS to discuss what the app does and any specifics we’d like them to test;

  • We share the staging app with DAS, who complete their review and leave notes as issues a private GitHub repo;

  • We fix any open issues and confirm with DAS that they have been resolved.

While writing frontend code, keep the following tips in mind:

  • Use valid HTML5 and our style guide to start with a good baseline for usable and accessible websites.

    • All Rails apps should include our theme gem, which provides styles from the guide and various partials to improve accessibility.

  • Use semantic HTML elements and ARIA attributes where appropriate to help screen reader users navigate the page.

  • Ensure that every page has a logical tab structure.

  • Ensure that every page includes a skip link, so people using keyboard navigation can jump to the page’s main content. (A customizable skip link partial is included in the theme gem.)

  • Run local checks throughout your development process (see Accessibility testing.

  • Consult with colleagues in EngX and UXWS if you find an issue that you either can’t fix or your own, or aren’t sure how to fix. Open discussions about accessibility issues often lead to the best-designed solutions.

Accessibility testing

Automated testing

All of our public GitHub repos are set to automatically check via AccessLint. This is a useful tool, but is not a comprehensive accessibility plan.

Manual testing

  • For every pull request that touches a UI element, the author should run an accessibility checker tool to confirm that the change does not introduce an access barrier. In EngX, we use the following:

  • Some people navigate webpages by keyboard. To ensure accessibility for these users, it’s a good idea to attempt to navigate the site periodically using your keyboard (e.g., when a new feature is added to the UI). This can help confirm that UI elements flow in a logical order.

  • A screen reader 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.

    • While periodic screen reader testing can be helpful to identify issues, it has limited utility unless done by an expert user. (This will occur as part of the formal DAS review.)

Implementing open source or vended solutions

As with locally developed software, any open source or vended software that includes a UI should be evaluated for accessibility. Any vendor claims related to accessibility should be confirmed, to the extent we are able to do so. UXWS should be consulted for accessibility reviews of vended products.

Ideally, accessibility should be discussed early in vendor negotations, and any potential issues should be addressed with the vendor.

Resources