Accessibility is Good Business
From a business perspective, it makes sense to design for accessibility. Why? Accessible websites are automatically SEO friendly (think: alt tags), reach more customers, are generally faster, and showcase best practices. Most of all, accessibility inherently brings usability. It’s a win-win for UX designers.
At BL3NDlabs (where I’m of Head of Design), I wrote this checklist to ensure consistency in our design and build process. These steps work with typical assistive tools including speech recognition, screen readers, and magnifiers.
We’ve written similar checklists for SEO, Content Strategy, User Research, overall Product Design, and Development. We clone these templates and save individual projects as child pages in our wiki. During project scoping, it’s the New Business Team’s and Project/Product Managers’ job to define accessibility requirements.
🔥Tip: make sure your team has an identified owner to document and share accessibility requirements.
Sorry, this list is not a silver bullet or a one-and-done tool. Accessibility takes thoughtful upfront work and consistent monitoring.
First, let’s start with a quick background. The World Wide Web Consortium (W3C) “is an international community that develops open standards to ensure the long-term growth of the Web.” The W3C develops Web Content Accessibility Guidelines (WCAG), covering a wide range of recommendations for making Web content more accessible.
WCAG 2.0 and WCAG 2.1 are the current “referenceable” standards. They have 10+ guidelines organized under four principles: perceivable, operable, understandable, and robust. For each, there are success tests at three levels: A, AA, and AAA. A has the least visual impact on design, where AAA significantly impacts design (for example, contrast constraints). If our client doesn’t have a benchmark, then we use WCAG AA as a default.
That’s a lot of versions and letters. At first, accessibility looks daunting. The WCAG realized this (I think), so they wrote this summary.
- Provide text alternatives for non-text content.
- Provide captions and other alternatives for multimedia.
- Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
- Make it easier for users to see and hear content.
- Make all functionality available from a keyboard.
- Give users enough time to read and use content.
- Do not use content that causes seizures or physical reactions.
- Help users navigate and find content.
- Make it easier to use inputs other than keyboard.
- Make text readable and understandable.
- Make content appear and operate in predictable ways.
- Help users avoid and correct mistakes.
- Maximize compatibility with current and future user tools.
Guidelines for Designers
Most designers want to know exactly how requirements like this might constrain them. Everyone wants to do the right thing, but it can easily be overwhelming with the number of resources out there. This documentation helps clarify expectations for my team. After all, designing for accessibility is not that hard. (H/T to the talented Pablo Stanley.)
Ethan Marcotte (wrote the book on responsive web design)
- Make text color contrast enough from its background. Ask for Contrast App (Mac App) or Stark. I like Stark since we can use it for our Sketch and Figma projects as a plugin rather than run a separate app. The Contrast App works well since you can test any application since it’s at the OS level.
- Use accessible color tools when developing palettes like Colorable, Color Review, Colorsafe, or Use All 5. Document them in your Design System.
- Don’t use color alone to identify information. Use patterns for color differentiation. Consider a color-blind mode toggle.
- Design w/ focus states.
- Use instructions and labels with form fields. Make sure they don’t disappear when the user starts to input text.
- Write relevant alt text (per any SEO requirements) for non-text content for screen readers.
- Use correct markup for content.
- Enable keyboard navigation. Can your user at least tab through?
- Allow for font resizing.
- Avoid using layout tables.
- Use stylesheets and div tags for visual layout.
- Use basic header information for data tables (the <th></th> element).
- Use linearized data tables for complex data.
- Ensure videos have supporting text transcripts and follow modern video best practices for accessibility.
Process, Process, Process
Remember, we make no guarantees that the client will not be sued. This “best-effort” process will differ if you’re starting from scratch vs. fixing an existing site. Either way, this is a continuous process that can be managed as part of maintenance activities over time to prevent accessibility emergencies due to lawsuit filings.
If you’re undertaking an accessibility review of an existing site, first gauge the LOE (level of effort). Once you do that, you will need to assess and prioritize enhancements. You can use Chrome extensions aXe Coconut, Google WAVE, or similar.
Sample aXe Instructions:
- Install aXe Coconut in-browser.
- Go to View > Developer > Developer Tools
- Select the aXe tab.
- Make sure the site you’re analyzing is loaded in Chrome. Click the “Analyze” button
- You’ll be presented with a list of items to adjust and a severity weighting.
- Add each item to a Google Sheet.
- Weigh each item according to severity as the highest value to the business.
- Weigh each item according to design/dev lift.
- Sort by highest value to the business, lowest LOE in design/dev.
- Build tickets into your roadmap as an Accessibility theme.
- Set a timer or create another project to repeat the cycle during development and post-launch.
New Project Process Checklist
- Checked there is enough contrast between text and its background color, everywhere
- Paired values of colors together (not only hues) to increase contrast
- Created and documented accessible color palettes in the design system
- Checked that I didn’t indicate important information using color alone
- Designed focus states to help users navigate and understand where they are on site
- Designed forms with labels that don’t disappear
- Wrote/used good alt text for images
- Been as consistent and clear as possible in layout and copy
- Used descriptive links/buttons
- Made sure I did not convey important information through images, color, or sensory characteristics alone
- Checked that accessibility testing is planned and will contribute to testing during Design QA
- If an experience could not be made accessible, created another route for users to get that information (example: highly interactive feature translated to a script)
- Used the correct HTML element for content
- Made sure the build supports keyboard navigation
- Used HTML landmarks
- Implemented good alt text for images
- Made sure to use focus states to help users navigate and understand where they are
- Reviewed the design spec to help users understand inputs, and help them avoid and correct mistakes
- Used ARIA attributes when applicable
- Given users a way to skip top-level navigation to access the main content
- Made links descriptive
- Avoided images and iconography in pseudo-elements
- Made SVGs accessible to assistive technology
- Hidden decorative elements from screen readers
- Created alternate routes for users to access information
- Made links should be visually identifiable and have clear :focus and :active states
- Check that the HTML document has a language attribute
Quality Assurance: I’ve...
- Run through each page with the WAVE/aXe Chrome Extension, notified my PM of any issues
- Made sure users can navigate through content using their keyboard
- Checked that users can navigate content using a screen reader and tested with one
- Checked that the general architecture and hierarchy of the content should make sense
- Reviewed charts and images for alt-text so that users with screen readers or users on a slow connection will still be able to understand the images
- Ensured decorative images are not visible to screen readers
Project/Product Managers: I’ve...
- Familiarized myself with the work associated with making content accessible
- Reviewed videos for the need for text transcripts
- Built-in time for accessibility during project planning and sprint planning
- Praised efforts to increase accessibility
- Been an advocate for accessibility
- Managed and enforced this list
More Favorite Accessibility Resources
- Subscribe to a11y Weekly
- Vox Accessibility Guidelines
- Manuel Matuzovic is so awesome on this topic
- Stripe Color Systems
- Inclusive Design Principles
- Inclusive Components
- UI Goodies Accessibility Guide
- Viget on Standards
- MIT Student Life
- Try the Funkify or Colorblindly Simulator Chrome plugins (note that I can’t guarantee the security of browser plugins)
- Accessibility Myths
I plan to keep this post updated as I improve this process. Subscribe in the footer below for updates...