Accessibility is not always in the forefront of our minds as designers and developers…but it’s important nonetheless. Here are a few quick realizations I have had in recent months:
Accessibility Is Not Just for the Visually Impaired
Often when someone mentions accessibility, we immediately think in terms of the visually impaired. While it is true that a lot of accessibility issues revolve around users with low or reduced vision (such as color contrast and keyboard navigation), these are not the only considerations to keep in mind.
Design and Write for Cognitive and Learning Disabilities
For example: some users may have cognitive disabilities which would make focusing on content difficult. Likewise, content that is poorly written, needlessly complex, or not chunked may be difficult for any user to read or understand.
These issues are so important, that the W3C has created a task force dedicated to accessibility for users with cognitive and learning disabilities.
Users with Temporary Disabilities Benefit from Accessibility, Too.
Accessibility can also help users with temporary disabilities. Ask yourself: what would happen if you broke your dominant arm? How difficult would it be to navigate your favorite sites using one hand and a keyboard? Imagine having to tab through page after page of un-focusable, unreadable content. See my point?
Use the Tools and Information Available…
There are plenty of tools available to help you address accessibility concerns. These include:
…but Don’t Rely on Tools Too Much.
Accessibility scanners are fantastic tools for assessing your site’s accessibility against the WCAG criteria, but remember…an accessibility scanner is just a scanner. They’re a collection of scripts that may not be performing tests on every piece of dynamically generated content on your site. For example: maybe your application generates an error prompt or additional forms under certain conditions? In cases like those, it’s easy to see how these tools can miss things. A knowledgeable human eye is needed.
That Being Said: Test Test Test!
Download any of the free screen readers like NVDA or Chromevox. Heck, if you’re reading this on MacOS, Apple’s own Voiceover is only a CMD + f5 away (or CMD + Touch IDx3 on newer Touch Bar-equipped MacBook Pros). I promise that after a few hours of tabbing through a site with a screen reader…and hearing it read through menu after menu aloud, you will have a newfound appreciation for what some of your users put up with and how necessary it is to champion accessibility.
:focus is !important
I read a great writeup recently on the :focus state by Eric Bailey. Remember that you can indicate focus not just with the outline property, but with borders, box shadows…etc. This flexibility is great when you want to stray away from the browser-defaults and keep with any existing styles or branding. Just remember to keep your contrast ratios in check, per the WCAG.
Also remember: keep every UI element that conveys important information or context focusable by the user. For example: a disabled form field may not be editable by the user, but it may contain important information that the user needs to be aware of. Perhaps it’s the review status of an application they submitted? Maybe it’s an address field that contains an error that needs to be corrected? You get the idea. Give your users access to the information they need.
Design Beyond the Letter of the Specs. Design in the Spirit of Accessibility.
If the bare-minimum requirements of accessibility guidelines doesn’t seem right for your users, exceed them. For example: newer WCAG 2.1 specs for non-text contrast explains that color contrast rules don’t apply to inactive (disabled) components:
“User Interface Components that are not available for user interaction (eg: a disabled control in HTML) are not required to meet contrast requirements in WCAG 2.1. An inactive user interface component is visible but not currently operable. Example: A submit button at the bottom of a form that is visible but cannot be activated until all the required fields in the form are completed.”https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html#intent
Once again: disabled fields may not technically be required to meet color contrast requirements, but if they communicate crucial information or context, then it’s in your user’s best interest to make this as visible as possible.
From my own experience I have found that good accessibility is a balancing act. You will be forced to juggle color contrasts, UI states, affordances, and brand consistency. Sometimes it’s simple and sometimes you will want to pull your hair out of your head and slam your laptop against the wall. In the end though, it’s worth it…and you’re making someones life just a little bit easier.