When people ask what I do for a living, I reply “Web accessibility designer.” I’m proud of that fact; I get the chance to make the web better every working day.
This post will outline the tools I use on a regular basis. I am a Mac user first and foremost, but I have tried to call out cross-platform tools wherever possible.
To understand accessibility, I like to start with basic HTML, specifically HTML5.
HTML5 for great good
I am willing to bet many—(most?)—web practitioners use HTML5 in their projects. One of the best features HTML5 offers is semantic layout tags. You may know them as:
-
<header role="banner"> -
<nav role="navigation"> -
<main role="main"> -
<aside role="complementary"> -
<footer role="contentinfo"> -
<section> -
<article>
These tags help screen readers and other assistive devices navigate sites efficiently because they are interpreted as landmarks, or anchor-points in the markup. If a user wishes to jump from a long navigation menu into the content without tabbing indefinitely, they can open a navigation device called the rotor, select Landmark Navigation, and listen for “main”.
So why the role?
You may have noticed the role attribute on several tags. These are ARIA roles, and while not part of HTML5, they ensure a consistent landmark navigation experience for the widest possible audience. Non-semantic tags like <div> with a role attribute will provide the same experience as HTML5 landmark tags.
HTML5 also offers new input types, and better form validation and error handling. All of these benefits are available for the low cost of a <!DOCTYPE html> declaration.
For speed and DevTools!
I won’t wade into Browser A vs. Browser B–type debates—my primary concern is efficiency. I use Google Chrome because it is lightweight and has excellent developer tools. I prefer the way Chrome presents elements and CSS in the inspector panel.
I also use the Network tab to review load times and performance. With client-side frameworks like React and AngularJS, much of the accessibility is contained in bundled JavaScript files; page size and HTTP requests matter.
Scanning for secrets
Several companies have introduced plugins or add-ons to scan web pages for accessibility. My personal choice is the aXe brower plugin, available for Chrome and Firefox.
aXe reviews the rendered site, one page at a time. It looks for invalid markup, color contrast issues, keyboard traps, and a number of other violations. It can be configured as a browser plugin, unit test, or added to a continuous integration pipeline.
What’s so special about 4.5?
4.5 is the minimum required color contrast ratio to meet WCAG2 Level AA acceptance criteria. This means any foreground color must have a perceived brightness at least 4.5 times higher than a chosen background color. This simplifies a lot of color theory, but captures the essence of the requirement nicely.
Designers unite!
Color contrast starts with visual design. I like to create color combinations in simple Photoshop mockups, pairing type with varying backgrounds, button states, and gradients.
When I am satisified with these impression styles, I turn to two web-based tools to check, and if necessary modify, my color selections.
Test early, test often
Jonathan Snook maintains a simple color contrast picker that is my first stop. Enter a hex value for your foreground color, one for your background color, and view your results. Pay close attention to Contrast Ratio and WCAG 2 AA Compliant. If you are at or above 4.5 and YES, you are good to go.
If one or more colors aren’t cutting the mustard, check out the Tanaguru Contrast Finder. The Contrast Finder will ask for your hex values again, and provides a number of compliant alternatives. This is a critical feature if your design calls for difficult pairings like white over orange or light green.
Do not rely on color alone
One of the best pieces of advice I can give is do not rely on color alone to convey meaning or intent in your user interfaces.
There are eight distinct types of color blindness, including weakness or blindness to red, green, or blue, and partial or total monochromatic sight. In practical terms, color is an unreliable narrator without clear, concise textual descriptions.
I like the Colorblinding plugin for Chrome as a way to quickly test all eight types. Open your webpage or drag a PNG or JPEG into your browser, and select a type from the Colorblinding menu. Be sure to go through all eight types.
Keyboards are for navigation
The next thing in a good accessibility toolkit is a keyboard. If your keyboard is not comfortable while typing or reaching for modifier keys, now is a good time to upgrade. I am a fan of the Apple thin aluminum keyboard. It has a shallow tilt, and the right balance of touch responsiveness.
Accessibility testing requires a lot of typing and key combinations, usually including Control, Shift, Option, Tab, and arrow keys. I spend a good amount of time testing sites in a front-to-back, and back-to-front method. This includes checking links, opening new windows, and clicking on modal dialogs, fly out menus, and tabs.
I also type a lot of my findings into spreadsheets or ticketing software, so having a keyboard that is comfortable for long periods of use makes me more productive.
A brave new screen reading world
Screen readers are the final tool I use regularly. Because I work on a Mac, VoiceOver is available at the operating system level. VoiceOver gives me the ability to navigate by landmark roles, headers, lists, form elements, paragraphs, and individual elements.
By moving through a page one element at a time, then using the semantic shortcuts on a second pass, I build up my familiarity with the site or app quickly. This lets me get through the error logging, and then start looking at more subtle interactions that could be improved with markup or other allowances.
Windows has the cool toys
If you are a Windows user, check out JAWS for an enterprise screen reader solution, or NVDA for an open-source one. These two screen readers represent a large portion of the assitive device market, and are highly recommended.
It’s virtually real
The last tool I use regularly is Virtual Box. Virtual Box is a virtual machine software, that allows me to run Windows or Linux (mostly Windows) inside my Mac laptop. I pair Virtual Box with current Windows 7 and Windows 10 disk images direct from Microsoft.
By running Windows on the Mac, I can test with additional screen readers and Microsoft-specific web browsers. This gives me a better test coverage and helps alleviate browser-specific issues.
What next?
Still reading? Great! That’s all for today, but I plan to follow up with a second article, describing how I test for accessibility. The next article will focus less on the tools, and more on practical application.
These tools make it easier than ever to evaluate your site or application for web accessibility.
