How to Fail at Accessibility – Several People Are Coding


Testing

What does accessibility on the web even mean? It is very broadly scoped, but thankfully also thoroughly documented. The W3C established what is known as the Web Content Accessibility Guidelines, or WCAG. If you check out this lovely doc, you’ll find everything you’ve ever wanted to know about web accessibility in a lengthy format.

A screenshot from the Web Content Accessibility Guidelines on W3C.org

These guidelines break down accessibility compliance to three grades: Levels A, AA, and AAA, with specific criteria for each on what is or isn’t WCAG compliant. Each level defines stricter adherence to supported accessible functionality, with Level A being the lowest level of compliance, and Level AAA being the most strict. At Slack, we aim to meet Level AA for all of our features, and for Level AAA compliance wherever possible.

The spectrum of human abilities and the technology to support them is infinitely broad, and there are complexities that even these guidelines don’t properly address. For now, we’ll get you started on four areas you can test now — the Hello, World of accessibility, if you will — and I’ll let you dig into more nuanced support later. These four areas are: color contrast, user interface zoom support, keyboard interaction models, and screenreader support.

🌈 Color Contrast

When looking at contrast, we’re not evaluating every last color across your beautiful website: instead we’re interested in making sure the information and interactive elements on your website are perceivable and understandable. That means, specifically, the body copy, large text (meaning anything bold 14pt or 18pt non-bold and up), and UI elements on your website, such as iconography and form elements.

A few examples of where to check for color contrast

The best tool for the job here is the Colour Contrast Analyzer, which lets you use an eyedropper or hex code to check foreground and background colors, and will immediately tell you whether or not you meet the criteria at the bottom. It should come as no surprise that light gray text on a white background does not meet the contrast requirement.

A pass and fail example within Colour Contrast Analyzer

🔎 User Interface Zoom

UI Zoom refers to the browser’s built-in zoom functionality that is toggled using CMD or CTRL +/ -. At Slack, our designers provide mock-ups at the different zoom levels we support whenever relevant. The easiest way to go about testing this is to simply zoom in a few levels and spend a day or two looking for broken areas in your interface.

An example of a design for various UI zoom levels

⌨️ Keyboard Navigation

Also known as the Keyboard Interaction Model. This refers to navigating your web content using only a keyboard, most commonly using the Tab and Shift + Tab keys to move forward and backward, and using Arrow keys, Enter, and Esc to interact with UI elements.

Every year in May, our accessibility team hosts a week-long challenge for Global Accessibility Awareness Day where they encourage us to put our mice away in our desk drawers, and spend the week using Slack only by keyboard. I remember trying this last year and finding both how many ways I was able to be more efficient, and also ways where I struggled because I didn’t know what the different common patterns are.

Within the Slack client, we provide this handy palette of key commands to help folks who may have mobility limitations, and also to enable people to become power users of Slack.

An example of the keyboard shortcut panel in Slack, toggled using CMD + /

In addition to keyboard-support, accessibility guidelines require that you indicate what has current focus, visualized here by a fuzzy blue ring.

An example focus ring that follows along as you tab around

An important thing to look out for while you’re testing out your interface is if you notice that you’re able to tab into a section, but then are unable to tab away from it. These are known as keyboard traps and should be avoided.

A cat falling into a trap. Don’t do this to your keyboard users.

💬 Screenreader support

If you’ve fixed up your keyboard interaction model, you’re already halfway there! Screenreaders are a type of assistive technology that audibly dictate what a user is currently interfacing with, particularly useful for folks with low or no vision.

If you have a Mac, screenreader software is built in with VoiceOver. To turn this on, open up Systems Preferences, navigate to the Accessibility tab, and enable VoiceOver. There are equivalent free software options for PCs as well, such as NVDA.

The toggle to enable VoiceOver on a Mac

Here’s a quick preview for what it’s like using a screenreader: you’ll notice as the keyboard focuses on an element, the screenreader will first announce what type of element it is, how it’s defined, and then will update as you’re interacting with it. Can you guess what interface this is just by listening?

An example using VoiceOver — check out the answer here!

Additionally, screen readers use what’s known as a rotor for quickly navigating around sections on a webpage. This is one of the reasons to make sure you’re using well-defined and semantic HTML markup to begin with, as that’s how the rotor indexes your content. You can pull the rotor up using Control + Option + U, and move left or right to access the different menus available.

An example of using the rotor tool with VoiceOver



Source link