Link Search Menu Expand Document

Accessibility

@INCOMPLETE

Table of Contents

What is Web Accessibility?

When most people think about accessibility, they think about the physical environment. Are there ramps and elevators available for people who can’t phyically use stairs? Are there raised bumps at street corners to alert people who are blind where the sidewalk ends and the street begins? Do TV shows and movies offer captions for the hearing impaired?

On the web, accessibility is very similar. When we build virtual spaces, we should make sure that everyone can access them. That includes people who can’t see, hear, or physically use a mouse or keyboard. While you aren’t responsible for the assistive technology they use, like screen readers, screen magnifiers, and keyboard alternatives, you are responsible for building things that are compatible with those technologies.

Designing Accessibly

Often, “making things accessible” is thought of as an extra step, and therefore an extra cost. Something that is tacked on at the end of a project to cater to some ridiculously small percentage of users, or as an obligatory step to avoid a lawsuit. That kind of attitude usually leads to very poor accessibility.

Image of a ramp placed above some stairs that has a large drop-off on the end and is completely inaccessible.

Image from Reddit

But it’s more helpful to think of it the other way around. If you were building a business or office space, would you want it constructed in a way that excluded people? Maybe with doorways too narrow for wheelchairs, or bathrooms allocated only for women, or exit signs that couldn’t be read by colorblind individuals? Of course not! So when you choose your doorway size, just pick a width that doesn’t unnecessarily make life harder for someone.

Intentionally making choices that work for everyone make things work better… for everyone. Most web developers are young and work in “ideal” circumstances: sitting comfortably at a desk with good lighting, a large monitor, and a good keyboard and mouse. But many of the people who use your app may not be. Even if they would never consider themselves disabled, a user who is outside and jostling their phone up and down as they walk will benefit from design choices that include larger buttons and higher color contrast.

The Four Principles of Accessibility: P. O. U. R.

Web Content Accessibility Guidelines are an international standard created and adopted by the World Wide Web Consortium (W3C). They outline a wide variety of ways to ensure that web content is accessible to as many users as possible, and will be linked to extensively throughout this document. Every guideline and recommendation is based on the following four principles:

  • Perceivable: Nothing should be invisible to all of a user’s senses. This includes information as well as interface components.
  • Operable: A site should never require a user to perform an action that they cannot perform. This particularly affects users who can’t see the screen or use a mouse.
  • Understandable: Content and inteface components should be clear and easy to understand.
  • Robust: Content should be compatible with all browsers and assistive technologies, and remain so even as technology changes.

Even if you don’t remember all of the specific rules below as you’re building things, if you can remember these four principles, you will probably end up following a good number of the rules be default. That said, please reference this page regularly to refresh on these rules and keep all our sites and apps in compliance with best practices.

Test Your Site with a Screen Reader

It’s impossible to get a really good feel for all the ways your site or app will be used without experiencing it for yourself. This is particularly important with screen readers and keyboard-only navigation, which guarantee your site is perceivable and operable. There are also subtle differences in keyboard behaviors when a screenreader is on compared to when it is off.

Most commercial screen readers and even open source screen readers are built for Windows PC. If you are using a Mac, you’ll need to use the built-in VoiceOver software to test if each part of your site or app can be accessed with it.

To Use Mac VoiceOver

  • Plug in headphones so you don’t drive everyone around you nuts.
  • Press command + F5 (the button with the microphone icon on it).
  • Click “Use VoiceOver”.
  • Make sure that your computer’s focus is on the window or tab of your app or web page.
  • Use arrow keys or tab and shift + tab to navigate around.

Helpful VoiceOver Shortcuts

  • contol + option and caps lock are the default options to trigger voice over shortcuts. Pressing either will count as VO below.
  • Press VO + u to open the “rotor”. Then use left and right arrows to switch between different sets of elements: landmarks, form elements, headers, etc. Then use up and down arrows to select which landmark, form element, header, etc to skip to. Press space to select.
  • Use VO + command + h to navigate directly by headings.
  • Use VO + shift + down to navigate INTO an element (like a table or list), then VO + shift + up to navigate back out.
  • Use VO + c to read a column header when in a table, or VO + c + c to read the whole column.
  • Use VO + r to read a row header when in a table, or VO + r + r to read the whole row.
  • Use VO + command + shift to change the voice settings.

Use Automated Tools to Help

Note: While helpful, absolutely NO automated tool can catch all accessibility errors. If you’re designing or building anything in the front end, you should be sure to read up on accessibility standards and have others look over your work.

While you’re coding, it may help to use an accessibility checker to help prevent easy mistakes. If you’re using VS Code, we recommend the “axe Accessibility Linter” by Deque Systems. If you install this plugin, each time you’re coding in HTML (or React or Vue or Angular), it will automatically highlight potential accessibiltiy issues with descriptions of how to fix them.

If you’re reviewing an existing web site or app, we recommend the Chrome plugin “axe DevTools”. This will add a new tab to your standard Chrome DevTools. While the premium, licensed version has more finesse, even the free version can run a full-page scan and help diagnose errors and give suggestions for fixing them. Keep in mind that this is an industry-leading tool by a major accessibility company, and by their own estimates, only finds 57% of the issues a professional audit would find.

Table of contents