Jacob Jedryszek

Have you heard about accessibility? Do you know what that is? Do you know what it takes to make your website accessible?

Making your website accessible means providing the ability for everyone – regardless of disability or special needs – to use it.

Unfortunately, if you put together all accessibility specifications and print it, the stack will be higher than CN Tower in Toronto:

This is not very encouraging. Many people think that it is not worth the effort because the customer base with special needs is significantly low. However, there is a thing called situational disability that applies to all of us. Moreover, when we are building our websites with accessibility in mind, we make them better for everyone. Why? Because everybody is more comfortable when allowed to fill out forms on a website using just a keyboard (without mouse) and able to switch between fields fast. Generally, everybody likes it when the focus is set on the search bar for sites because 99% of the time, the first thing you do is search for something. Everybody likes properly matched colors (accessible contrast).

How do you get started? How to survive without reading tons of specifications?

3 steps to fulfill 80% standards with 20% effort

1. Make your website usable with keyboard only:
   • make sure that focus outline is visible all the time and user can determine which element is currently focused
   • no extra/unnecessary TAB stops
   • no tabstop traps (when you cannot get out of an element with the keyboard)
2. Implement smart focus management:
   • set focus on appropriate elements after user actions (e.g., when a user navigates to a page with a login form – set the focus on the login text field; in 90% of the cases the next user action will be entering the login)
   • restore focus to appropriate elements after user actions (e.g., when a user closes a menu, focus should be restored to the element that was focused on before opening the menu)
   • make tab order user-friendly (remove non-actionable and non-informative tab stops)
3. Make your website usable with screen reader:
   • When element gets focused, screen reader should provide meaningful information to the user (e.g., “image Satya Nadella” when focused on Satya’s image, or “menu collapsed” when focused on dropdown menu)
   • Min bar: make it good enough with one screen reader and one browser first. As of 2016-08-22 the best browser + screen reader combination is Firefox + NVDA (it has a text mode that prints output instead of converting it into speech: Tools -> Speech viewer)
   • Add aria tags to elements only when the screen reader cannot infer information from HTML (e.g., button element does not need role=’button’ as screen reader will infer it)

Good to know

1. Don’t focus too much on “being compliant to the standards” at the beginning. Just use the common sense and your intuition. You can deep dive into the standards later on.
2. Make your website’s most common scenarios work well first and focus on less popular pages later.
3. Only 20% of accessibility requirements can be verified by tools. The rest has to be verified manually by:
   • yourself
   • user study
   • an accessibility expert

Resources to get started

• Web Accessibility Tutorial
  • Especially: writing code checklist and design checklist
• Web Accessibility Resources by Marcy Sutton
  • Especially: examples of accessible websites
• Web Accessibility: Getting Started (Pluralsight)
• Examples:
  • ARIA examples
  • Open AJAX Accessibility examples
• Tools:
  • accessibility checkers
    • Accessibility Developer Tools for Chrome
    • aXe: the Accessibility Engine (chrome plugin and axe-core.js – that can be used in your unit tests)
  • Screen readers:
    • NVDA (it has text mode that prints output instead of converting it into speech: Tools -> Speech viewer)
    • JAWS
    • Narrator
  • Contrast:
    • Color contrast analyzer
    • Color combinations matcher
    • Color pallets you can use for your website
• W3C:
  • Design patterns/best practices, WAI-ARIA – when in doubt, check this succinct reference
  • Using ARIA in HTML
  • ARIA usage note – When you should use aria-* and when you should NOT
  • [SVG] Role model diagram – what aria properties/states apply to particular elements

Summary

If you are web developer you probably like when the tool you are using enables you to do everything without the mouse. This is thanks to keyboard accessibility, and smart focus management. If you play with color contrast analyzer you will notice that colors with good contrast are easier to read and simply just look better. Be aware that accessibility is about performance first. When your website is slow it can lead to unexpected focus behaviors, unwanted user actions, or moving content. How many times you tried to scroll to some part of website and it was moving because images were loading? I’m sure a lot.

What do you think? Is the website you are working on accessible? Have you ever even thought about it?