Designing for Web Accessibility in 60 Seconds

Published on by David A. Kennedy

You design on the web for a living, and want to put accessibility first. Let’s do this.

I’ve written on the topic before, but it occurred to me recently that while much of that advice holds true almost six years later, it leans technical. What do you do if what you have in front of you isn’t in code yet?

You need to ask intelligent questions. This will help you identify better directions within the constraint of accessibility. From there, you can determine where your design needs to strengthen in order to work for more people.

Focus on the Content and Information Design

Ask: Is the content specific enough in important areas?

People aren’t there to look at your design, they need to read the copy to get their task done. They’ll skim more than read. Look at content within headings, links, buttons and other spots that have calls to action. This copy should make sense on its own, without the context of any accompanying content on the page.

A few tips for your content:

  • When writing link text, describe the content of the target of the link.
  • When writing headings, keep them concise and use them to form an outline of the content of the page.

Ask: Where does the design’s visual hierarchy put pressure on the size of fonts and color of text?

Creating visual hierarchy within a design ranks the information on the page to influence the order a user might view it. However, once you start making decisions about type sizing, color, contrast, spacing and other elements, you can sacrifice accessibility if you’re not careful.

Avoid:

  • small font sizes.
  • low color contrast.
  • relying on color alone to communicate a message.
  • alignment that might cause challenges in creating the source order for the content.
  • using motion that can cause seizures or other motion sickness.

Be Mindful of Components and State

Ask: What components or elements try to do too much?

Many accessibility challenges arise when we take multiple components and try to make them work as one. Think the autocomplete and tooltip. Simplify.

Can you do without that complex component? If not, can you test it with people with disabilities to work through some assumptions? Are you including this component because it solves a problem or because many other organizations use something similar? Lots of questions, I know. But design is all about answering questions.

Ask: Are all of the design’s different state’s communicated in an accessible way?

A design’s states often get overlooked. Focus states, error states and the like add detail and communicate the full intention of a design. Take the time to create them so your design carries a sense of completeness.

Some states to pay attention to when designing:

  • Error states
  • Focus states
  • Selected states
  • Disabled states
  • Loading states

Eric Bailey has a list of even more states you might want to consider.

I recognize that the title might set off your clickbait alarm and that’s fair. True inclusive design requires much more effort. You may not be able to answer all of these questions in seconds, but you can still get a sense of where you design stands. That matters, and will make your work stronger in the end.


Tagged AccessibilityWeb Design