Lead UX Designer
To be fully accessible to disabled people, design and development need to work together. This means that there are two parts to accessibility work for designers:
How to Design for Visual Accessibility in 8 Easy Steps
Reference WCAG 2.0, 1.4.3, AA
Use the sliders to adjust text and background colors until you reach a contrast level you're happy with.
The results show up under the foreground slider. Ideally they look like the example on the left, with all green Pass values.
WCAG AA is the industry standard for accessibility. Shoot for passing at least that for all text. For bold text larger than 14px, you can get away with passing only the Large Text WCAG AA test, as shown on the right.
WebAIM contrast checker
There are many tools for contrast checking and adjusting on the web. I use WebAIM's Contrast Checker. Enter the hexcode for your text color into the Foreground Color textfield and the hexcode for the background into the Background Color field.
Higher contrast benefits almost everybody who doesn't have perfect vision. That includes the roughly 8% of American men who are color blind, as well as most middle-aged and older people. It's not a pleasant thought, but our eyes are affected by age. Just like old car head lights, over the years human corneas get yellow and foggy.
Reference WCAG 2.0, 1.1.1, A
Complex text alternatives near the image
Here's a bar graph with a table underneath. The table serves as a text alternative to the graph.
To reduce clutter, the table can be hidden under an expand/collapse element.
In user testing I've noticed that sighted people with a background in finance or engineering often trust the data more if they can see the table in addition to the graph. It's just one more example of how addressing accessibility improves usability for many.
Complex text alternatives inside the image
Here's an example of a chart from Yahoo Finance that definitely needs a visible text alternative. It's a combined line graph and bar graph. The designer has incorporated a text alternative at the top left of the chart. It's the little table of values.
This can only serve as a text alternative, if it is actually coded as text. Adding text to an image in Photoshop doesn't help.
Simple text alternatives (alt attributes)
Here is an example of three very simple images. You don't need to add any visible alternate text to your design for these images, unless you want to.
Elements on the page that aren't text may need text alternatives. This applies to images and graphs that convey facts. So for example a pie chart that shows investment allocations needs a text alternative. The stock photo of an actor smiling at a laptop does not.
If the information conveyed can be summed up in a sentence or two, it can be coded as an alt attribute. But if it's more complicated than that, your design needs to include a space on the page where it is shown.
A word about content writing
Content writers play an important role in making the web accessible to disabled users. The W3C Web Accessibility Initiative have a concise overview about writing for accessibility to get you started.
Reference WCAG 2.0, 1.4.1, A
When conveying information, don't use color alone. You can still use color to convey information, e.g. through color coding bars in a bar graph. It's just that you need to supplement it with another distinguishing feature that can be seen by those who don't see color well.
Here are a couple of markers that work in different situations, depending on what you're trying to convey.
Reference WCAG 2.0, 1.2.1, A
Audio and video require transcripts
For usability and search engine optimization, place the transcript on the same page as the audio or video. Many people like to scan the transcript before (or instead of) watching the video.
Here's an example of what it can look like when the first paragraph of the transcript is shown and the rest is under a link.
Add a pause button, so your audience can focus on what's important.
The human brain is adapted to notice things that move. When you are trying to read something, and there's constant movement at the edge of your vision, reading comprehension is going to suffer. For people with cognitive disabilities, even minor distractions can kill their focus. That's why it's an accessibility requirement to avoid continous motion. You can choose to stop the movement programmatically, or give the user a way of stopping things that distract them.
What not to do
This screenshot is from the US Post Office tracking feature. Can you tell which elements you can click on or hover over? This is what happens when you use the same color for headings and links and don't underline links -- you end up with a significant usability issue.
When the user hovers over an interactive element or places focus on it, the element needs to react in an obvious way. Unfortunately the W3C hasn't defined what exactly that means, so it's a judgment call.
In many cases, the simplest way of complying with this requirement is to let the browser take care of it. But you can also specify the behavior for hovering and focusing. Here are some examples to get you started.
Follow established conventions or go skeumorphic
In this illustration of sliders and grippies, on the other hand, it's fairly obvious what you can do with each element. That's because they all either follow well-established conventions, or mimic offline controls.
As you can see, you can use flat design and still communicate affordance.
Underline text links
For links, the simplest way of showing that they are clickable is to underline them. Depending on the context, there are other conventions, such as icons, backgrounds and borders, that can be used to clearly mark text as clickable.
Whichever way you go, make sure that it's visible without user action and doesn't rely on color alone.
Affordance has to be obvious
Affordance is the quality in an object that suggests how it can be used. For example the shape of a mug handle suggests that it can be used to pick up and hold the mug. If you have to use words to instruct people in how to use something, the affordance is not obvious enough.
Three things are required for affordance to be obvious to everybody:
HTML is accessible by default.
Yes, HTML is accessible the same way modern cars are safe. You still have to operate them carefully or you can hurt yourself and others. You can use HTML to create an accessible site, but it's not going to happen by itself.
Show me where in the current version of WCAG it says that. (Spoiler: It doesn't.)
Accessible sites are ugly, boring and have limited functionality
If your accessible site is ugly, boring or has limited functionality, it's because the people who created it didn't know what they were doing or couldn't be bothered. It takes effort, less than you think, but still effort, to learn how to design and code accessibly.
Let's create a separate site just for disabled people!
Creating a separate site for disabled people is rarely suggested in good faith. The plan is usually to create it on a shoestring budget and then not maintain it.
If you're concerned about being compliant with accessibility laws, such as the ADA in the US or the DDA in the UK, the bad news is that a separate site is non-compliant. Separate but equal ain't.
My web consultancy says they can make my site accessible.
Sure they can! Send me a link to a site of theirs that they claim is accessible and let me at it with a validation tool. $20 says that it will take me less than 30 minutes to find 100 accessibility issues. Until I've seen their existing work, I'm going to take their claim with a grain of salt. Caveat emptor!
Fair warning -- I actually believe that disabled people are important and that all commercial sites should be accessible to them. So this is where I rant.
Typical change font size feature
To be accessible, your site needs [visible feature]
Maybe, maybe not. There are visible features that are required, e.g. transcripts of videos. But the features that are hyped by untrained lay people as must-haves, often help mostly people who don't identify as disabled. I have no beef with able-bodied people who forgot to bring their reading glasses. But let's keep our focus on the main target audience of accessibility initiatives - people with ongoing impairments that limit major life activities.
A text-size changing feature visible on every page, is an example of this phenomenon. People with serious longterm vision impairment usually have figured out several ways of making text large enough for them to see. They use the browser's zoom feature, several different screen magnifiers, screen readers and creative combinations of these. The thing about text size features is that only some sites have them, and you never know where they're going to be placed or if they will be available on all pages. Dedicated disability aids on the other hand, work on all (or many) sites and the user learns how to adapt them to their own needs over time.
Most likely you're going to get more bang for your accessibility buck by investing it in training and testing, rather than on building features proposed by people who have no training in web site accessibility.
It would be great if we could all just install the magical accessibility plugin on our sites and they'd be perfectly accessible to everyone. But that's not how it works.
Maybe one day... 💭🦄
Eventually accessibility will become standard operating procedure throughout everything you do. You won't even notice it. Except when you use your competitor's site you'll be annoyed because you can't use the TAB key to navigate around forms and you have to squint to read the low-contrast text. And where did they hide the video transcripts?
3. Start small
To minimize risk and disruption, it's a good idea to start with just one project. Once you've figured out how to do accessibility from start to finish on one or two smaller projects, use the learnings to scale up to more teams and projects bit by bit.
Don't be tempted to go all in, or you risk a backlash. Accessibility is not rocket science but it takes emotional work. Factor that into your plan and you're golden.
4. Test, test, test
Untested software is buggy. That's an axiom of software development and it definitely applies to accessibility.
Testing needs to be done in several different ways:
The people who are testing for accessibility will need thorough training in things to look for. Validation software, e.g. is very prone to reporting bugs that aren't. Screen readers, on the other hand, can lull you into complacency so you won't even notice that it skipped entire sections of the page.
The best testers bring a QA mindset to the task.
Once you're confident that you are on the road to accessibility success, you can go public with it:
8. Get Serious
Typical output from automated HTML validation. So far it takes a human to tell that "dellfmr.FMR.publicEnrollment..." is incorrect and what it should say instead. But this could obviously be done better and faster through machine learning.
MADE IN PIXEL TOGETHER
Go to Linked In
Return to Home Page