Web Content Accessibility Guidelinesfor People Who Haven't Read Them

Alan Dalton takes a detailed look at WCAG on this UN International Day of Persons with Disabilities. Remember, Christmas is a time of good will to all, no matter if you have difficulty seeing, hearing, reading, or just have a very shiny nose.

Brought to you by The CSS Layout Workshop. Does developing layouts with CSS seem like hard work? How much time could you save without all the trial and error? Are you ready to really learn CSS layout?

Ive been a huge fan of the Web Content Accessibility Guidelines 2.0 since the World Wide Web Consortium (W3C) published them, nine years ago. Ive found them practical and future-proof, and Ive found that they can save a huge amount of time for designers and developers. You can apply them to anything that you can open in a browser. My favourite part is when I use the guidelines to make a website accessible, and then attend user-testing and see someone with a disability easily using that website.

Today, the United Nations International Day of Persons with Disabilities, seems like a good time to re-read Laura Kalbags explanation of why we should bother with accessibility. That should motivate you to devour this article.

If you havent read the Web Content Accessibility Guidelines 2.0, you might find them a bit off-putting at first. The editors needed to create a single standard that countries around the world could refer to in legislation, and so some of the language in the guidelines reads like legalese. The editors also needed to future-proof the guidelines, and so some terminologysuch as time-based media and programmatically determinedcan sound ambiguous. The guidelines can seem lengthy, too: printing the guidelines, the Understanding WCAG 2.0 document, and the Techniques for WCAG 2.0 document would take 1,200 printed pages.

This festive season, lets rip off that legalese and ambiguous terminology like wrapping paper, and seein a single articlewhat gifts the Web Content Accessibility Guidelines 2.0 editors have bestowed upon us.

Can your users perceive the information on your website?

The first guideline has criteria that help you prevent your users from asking What the **** is this thing here supposed to be?

1.1.1 Text is the most accessible format for information. Screen readerssuch as the VoiceOver setting on your iPhone or the TalkBack app on your Android phoneunderstand text better than any other format. The same applies for other assistive technology, such as translation apps and Braille displays. So, if you have anything on your webpage thats not text, you must add some text that gives your user the same information. You probably know how to do this already; for example:

• for images in webpages, put some alternative text in an alt attribute to tell your user what the image conveys to the user;
• for photos in tweets, add a description to make the images accessible;
• for Instagram posts, write a caption that conveys the photos information.

The alternative text should allow the user to get the same information as someone who can see the image. For websites that have too many images for someone to add alternative text to, consider how machine learning and Dynamically Generated Alt Text mightmightbe appropriate.

You can probably think of a few exceptions where providing text to describe an image might not make sense. Remember I described these guidelines as practical? They cover all those exceptions:

• User interface controls such as buttons and text inputs must have names or labels to tell your user what they do.
• If your webpage has video or audio (more about these later on!), you mustat leasthave text to tell the user what they are.
• Maybe your webpage has a test where your user has to answer a question about an image or some audio, and alternative text would give away the answer. In that case, just describe the test in text so your users know what it is.
• If your webpage features a work of art, tell your user the experience it evokes.
• If you have to include a Captcha on your webpageand please avoid Captchas if at all possible, because some users cannot get past themyou must include text to tell your user what it is, and make sure that it doesnt rely on only one sense, such as vision.
• If youve included something just as decoration, you must make sure that your users assistive technology can ignore it. Again, you probably know how to do this. For example, you could use CSS instead of HTML to include decorative images, or you could add an empty alt attribute to the img element. (Please avoid that recent trend where developers add empty alt attributes to all images in a webpage just to make the HTML validate. Youre better than that.)

(Notice that the guidelines allow you to choose how to conform to them, with whatever technology you choose. To make your website conform to a guideline, you can either choose one of the techniques for WCAG 2.0 for that guideline or come up with your own. Choosing a tried-and-tested technique usually saves time!)

1.2.1 If your website includes a podcast episode, speech, lecture, or any other recorded audio without video, you must include a transcription or some other text to give your user the same information. In a lot of cases, you might find this easier than you expect: professional transcription services can prove relatively inexpensive and fast, and sometimes a speaker or lecturer can provide the speech or lecture notes that they read out word-for-word. Just make sure that all your users can get the same information and the same results, whether they can hear the audio or not. For example, David Smith and Marco Arment always publish episode transcripts for their Under the Radar podcast.

Similarly, if your website includes recorded video without audiosuch as an animation or a promotional videoyou must either use text to detail what happens in the video or include an audio version. Again, this might work out easier then you perhaps fear: for example, you could check to see whether the animation started life as a list of instructions, or whether the promotional video conveys the same information as the About Us webpage. You want to make sure that all your users can get the same information and the same results, whether they can see that video or not.

1.2.2 If your website includes recorded videos with audio, you must add captions to those videos for users who cant hear the audio. Professional transcription services can provide you with time-stamped text in caption formats that YouTube supports, such as .srt and .sbv. You can upload those to YouTube, so captions appear on your videos there. YouTube can auto-generate captions, but the quality varies from impressively accurate to comically inaccurate. If you have a text version of what the people in the video saidsuch as the speech that a politician read or the bedtime story that an actor readyou can create a transcript file in .txt format, without timestamps. YouTube then creates captions for your video by synchronising that text to the audio in the video. If you host your own videos, you can ask a professional transcription service to give you .vtt files that you can add to a video elements track elementor you can handcraft your own. (A quick aside: if your website has more videos than you can caption in a reasonable amount of time, prioritise the most popular videos, the most important videos, and the videos most relevant to people with disabilities. Then make sure your users know how to ask you to caption other videos as they encounter them.)

1.2.3 If your website has recorded videos that have audio, you must add an audio description narration to the video to describe important visual details, or add text to the webpage to detail what happens in the video for users who cannot see the videos. (I like to add audio files from videos to my Huffduffer account so that I can listen to them while commuting.) Maybe your home page has a video where someone says, Id like to explain our new TPS reports while Bill Lumbergh, division Vice President of Initech appears on the bottom of the screen. In that case, you should add an audio description to the video that announces Bill Lumbergh, division Vice President of Initech, just before Bill starts speaking. As always, you can make life easier for yourself by considering all of your users, before the event: in this example, you could ask the speaker to begin by saying, Im Bill Lumbergh, division Vice President of Initech, and Id like to explain our new TPS reportsso you wont need to spend time adding an audio description afterwards.

1.2.4 If your website has live videos that have some audio, you should get a stenographer to provide real-time captions that you can include with the video. Ill be honest: this can prove tricky nowadays. The Web Content Accessibility Guidelines 2.0 predate YouTube Live, Instagram live Stories, Periscope, and other such services. If your organisation creates a lot of live videos, you might not have enough resources to provide real-time captions for each one. In that case, if you know the contents of the audio beforehand, publish the contents during the live videoor failing that, publish a transcription as soon as possible.

1.2.5 Remember what I said about the recorded videos that have audio? If you can choose to either add an audio description or add text to the webpage to detail what happens in the video, you should go with the audio description.

1.2.6 If your website has recorded videos that include audio information, you could provide a sign language version of the audio information; some people understand sign language better than written language. (You dont need to caption a video of a sign language version of audio information.)

1.2.7 If your website has recorded videos that have audio, and you need to add an audio description, but the audio doesnt have enough pauses for you to add an audio description narration, you could provide a separate version of that video where you have added pauses to fit the audio description into.

1.2.8 Lets go back to the recorded videos that have audio once more! You could add text to the webpage to detail what happens in the video, so that people who can neither read captions nor hear dialogue and audio description can use braille displays to understand your video.

1.2.9 If your website has live audio, you could get a stenographer to provide real-time captions. Again, if you know the contents of the audio beforehand, publish the contents during the live audio or publish a transcription as soon as possible.

(Congratulations on making it this far! I know that seems like a lot to remember, but keep in mind that weve covered a complex area: helping your users to understand multimedia information that they cant see and/or hear. Grab a mince pie to celebrate, and lets keep going.)

1.3.1 You must mark up your websites content so that your users browser, and any assistive technology they use, can understand the hierarchy of the information and how each piece of information relates to the rest. Once again, you probably know how to do this: use the most appropriate HTML element for each piece of information. Mark up headings, lists, buttons, radio buttons, checkboxes, and links with the most appropriate HTML element. If youre looking for something to do to keep you busy this Christmas, scroll through the list of the elements of HTML. Do you notice any elements that you didnt know, or that youve never used? Do you notice any elements that you could use on your current projects, to mark up the content more accurately? Also, revise HTML table advanced features and accessibility, how to structure an HTML form, and how to use the native form widgetsyou might be surprised at how much you can do with just HTML! Once youve mastered those, you can make your website much more usable for your all of your users.

1.3.2 If your webpage includes information that your user has to read in a certain order, you must make sure that their browser and assistive technology can present the information in that order. Dont rely on CSS or whitespace to create that order visually. Check that the order of the information makes sense when CSS and whitespace arent formatting it. Also, try using the Tab key to move the focus through the links and form widgets on your webpage. Does the focus go where you expect it to? Keep this in mind when using order in CSS Grid or Flexbox.

1.3.3 You must not presume that your users can identify sensory characteristics of things on your webpage. Some users cant tell what youve positioned where on the screen. For example, instead of asking your users to Choose one of the options on the left, you could ask them to Choose one of our new products and link to that section of the webpage.

1.4.1 You must not rely on colour as the only way to convey something to your users. Some of your users cant see, and some of your users cant distinguish between colours. For example, if your webpage uses green to highlight the products that your shop has in stock, you could add some text to identify those products, or you could group them under a sub-heading.

1.4.2 If your webpage automatically plays a sound for more than 3 seconds, you must make sure your users can stop the sound or change its volume. Dont rely on your user turning down the volume on their computer; some users need to hear the screen reader on their computer, and some users just want to keep listening to whatever they were listening before your webpage interrupted them!

1.4.3 You should make sure that your text contrasts enough with its background, so that your users can read it. Bookmark Lea Verous Contrast Ratio calculator now. You can enter the text colour and background colour as named colours, or as RGB, RGBa, HSL, or HSLa values. You should make sure that:

• normal text that set at 24px or larger has a ratio of at least 3:1;
• bold text that set at 18.75px or larger has a ratio of at least 3:1;
• all other text has a ratio of at least 4:1.

You dont have to do this for disabled form controls, decorative stuff, or logosbut you could!

1.4.4 You should make sure your users can resize the text on your website up to 200% without using their assistive technologyand still access all your content and functionality. You dont have to do this for subtitles or images of text.

1.4.5 You should avoid using images of text and just use text instead. In 1998, Jeffrey Veens first Hot Design Tip said, Text is text. Graphics are graphics. Dont confuse them. Now that you can apply powerful CSS text-styling properties, use CSS Grid to precisely position text, and choose from thousands of web fonts (Jeffrey co-founded Typekit to help with this), you pretty much never need to use images of text. The guidelines say you can use images of text if you let your users specify the font, size, colour, and background of the text in the image of textbut Ive never seen that on a real website. Also, this doesnt apply to logos.

1.4.6 Lets go back to colour contrast for a second. You could make your text contrast even more with its background, so that even more of your users can read it. To do that, use Lea Verous Contrast Ratio calculator to make sure that:

• normal text that is 24px or larger has a ratio of at least 4:1;
• bold text that 18.75px or larger has a ratio of at least 4:1;
• all other text has a ratio of at least 7:1.

1.4.7 If your website has recorded speech, you could make sure there are no background sounds, or that your users can turn off any background sounds. If thats not possible, you could make sure that any background sounds that last longer than a couple of seconds are at least four times quieter than the speech. This doesnt apply to audio Captchas, audio logos, singing, or rapping. (Yes, these guidelines mention rapping!)

1.4.8 You could make sure that your users can reformat blocks of text on your website so they can read them better. To do this, make sure that your users can:

• specify the colours of the text and the background, and
• make the blocks of text less than 80-characters wide, and
• align text to the left (or right for right-to-left languages), and
• set the line height to 150%, and
• set the vertical distance between paragraphs to 1 times the line height of the text, and
• resize the text (without using their assistive technology) up to 200% and still not have to scroll horizontally to read it.

By the way, when you specify a colour for text, always specify a colour for its background too. Dont rely on default background colours!

1.4.9 Lets return to images of text for a second. You could make sure that you use them only for decoration and logos.

Can users operate the controls and links on your website?

The second guideline has criteria that help you prevent your users from asking, How the **** does this thing work?

2.1.1 You must make sure that you users can carry out all of your websites activities with just their keyboard, without time limits for pressing keys. (This doesnt apply to drawing or anything else that requires a pointing device such as a mouse.) Again, if you use the most appropriate HTML element for each piece of information and for each form element, this should prove easy.

2.1.2 You must make sure that when the user uses the keyboard to focus on some part of your website, they can then move the focus to some other part of your webpage without needing to use a mouse or touch the screen. If your website needs them to do something complex before they can move the focus elsewhere, explain that to your user. These keyboard traps have become rare, but beware of forms that move focus from one text box to another as soon as they receive the correct number of characters.

2.1.3 Lets revisit making sure that you users can carry out all of your websites activities with just their keyboard, without time limits for pressing keys. You could make sure that your user can do absolutely everything on your website with just the keyboard.

2.2.1 Sometimes people need more time than you might expect to complete a task on your website. If any part of your website imposes a time limit on a task, you must do at least one of these:

• let your users turn off the time limit before they encounter it; or
• let your users increase the time limit to at least 10 times the default time limit before they encounter it; or
• warn your users before the time limit expires and give them at least 20 seconds to extend it, and let them extend it at least 10 times.

Remember: these guidelines are practical. They allow you to enforce time limits for real-time events such as auctions and ticket sales, where increasing or extending time limits wouldnt make sense. Also, the guidelines allow you to enforce a maximum time limit of 20 hours. The editors chose 20 hours because people need to go to sleep at some stage. See? Practical!

2.2.2 In my experience, this criterion remains the least well-knowneven though some users can only use websites that conform to it. If your website presents content alongside other content that can distract users by automatically moving, blinking, scrolling, or updating, you must make sure that your users can:

• pause, stop, or hide the other content if its not essential and lasts more than 5 seconds; and
• pause, stop, hide, or control the frequency of the other content if it automatically updates.

Its OK if your users miss live information such as stock price updates or football scores; you cant do anything about that! Also, this doesnt apply to animations such as progress bars that you put on a website to let all users know that the webpage isnt frozen.

(If this one sounds complex, just add a pause button to anything that might distract your users.)

2.2.3 Lets go back to time limits on tasks on your website. You could make your website even easier to use by removing all time limits except those on real-time events such as auctions and ticket sales. That would mean your user wouldnt need to interact with a timer at all.

2.2.4 You could let your users turn off all interruptionsserver updates, promotions, and so onapart from any emergency information.

2.2.5 This is possibly my favourite of these criteria! After your website logs your user out, you could make sure that when they log in again, they can continue from where they were without having lost any information. Do that, and youll be on everyones Nice List this Christmas.

2.3.1 You must make sure that nothing flashes more than three times a second on your website, unless you can make sure that the flashes remain below the acceptable general flash and red flash thresholds

2.3.2 or you could just make sure that nothing flashes more than three times per second on your website. This is usually an easier goal.

2.4.1 You must make sure that your users can jump past any blocks of content, such as navigation menus, that are repeated throughout your website. You know the drill here: using HTMLs sectioning elements such as header, nav, main, aside, and footer allows users with assistive technology to go straight to the content they need, and adding Skip Navigation links allows everyone to get to your main content faster.

2.4.2 You must add a proper title to describe each webpages topic. Your webpage wont even validate without a title element, so make it a useful one.

2.4.3 If your users can focus on links and native form widgets, you must make sure that they can focus on elements in an order that makes sense.

2.4.4 You must make sure that your users can understand the purpose of a link when they read:

• the text of the link; or
• the text of the paragraph, list item, table cell, or table header for the cell that contains the link; or
• the heading above the link.

You dont have to do that for games and quizzes.

2.4.5 You should give your users multiple ways to find any webpage within a set of webpages. Add site-wide search and a site map and youre done!

This doesnt apply for a webpage that is part of a series of actions (like a shopping cart and checkout flow) or to a webpage that is a result of a series of actions (like a webpage confirming that the user has bought what was in the shopping cart).

2.4.6 You should help your users to understand your content by providing:

• headings that describe the topics of you content;
• labels that describe the purpose of the native form widgets on the webpage.

2.4.7 You should make sure that users can see which element they have focussed on. Next time you use your website, try hitting the Tab key repeatedly. Does it visually highlight each item as it moves focus to it? If it doesnt, search your CSS to see whether youve applied outline: 0; to all elementsthats usually the culprit. Use the :focus pseudo-element to define how elements should appear when they have focus.

2.4.8 You could help your user to understand where the current webpage is located within your website. Add breadcrumb navigation and/or a site map and youre done.

2.4.9 You could make links even easier to understand, by making sure that your users can understand the purpose of a link when they read the text of the link. Again, you dont have to do that for games and quizzes.

2.4.10 You could use headings to organise your content by topic.

Can users understand your content?

The third guideline has criteria that help you prevent your users from asking, What the **** does this mean?

3.1.1 Lets start this section with the criterion that possibly takes the least time to implement; you must make sure that the users browser can identify the main language that your webpages content is written in. For a webpage that has mainly English content, use <html lang="en">.

3.1.2 You must specify when content in another language appears in your webpage, like so: <q>I wish you a <span lang="fr">Joyeux Nol</span>.</q>. You dont have to do this for proper names, technical terms, or words that you cant identify a language for. You also dont have to do it for words from a different language that people consider part of the language around those words; for example, <q>Come to our Christmas rendezvous!</q> is OK.

3.1.3 You could make sure that your users can find out the meaning of any unusual words or phrases, including idioms like stocking filler or Bah! Humbug! and jargon such as VoiceOver and TalkBack. Provide a glossary or link to a dictionary.

3.1.4 You could make sure that your users can find out the meaning of any abbreviation. For example, VoiceOver pronounces Xmas as Smas instead of Christmas. Using the abbr element and linking to a glossary can help. (Interestingly, VoiceOver pronounces abbr as abbreviation!)

3.1.5 Do your users need to be able to read better than a typically educated nine-year-old, to read your content (apart from proper names and titles)? If so, you could provide a version that doesnt require that level of reading ability, or you could provide images, videos, or audio to explain your content. (You dont have to add captions or audio description to those videos.)

3.1.6 You could make sure that your users can access the pronunciation of any word in your content if that words meaning depends on its pronunciation. For example, the word close could have one of two meanings, depending on pronunciation, in a phrase such as, Ready for Christmas? Close now!

3.2.1 Some users need to focus on elements to access information about them. You must make sure that focusing on an element doesnt trigger any major changes, such as opening a new window, focusing on another element, or submitting a form.

3.2.2 Webpages are easier for users when the controls do what theyre supposed to do. Unless you have warned your users about it, you must make sure that changing the value of a control such as a text box, checkbox, or drop-down list doesnt trigger any major changes, such as opening a new window, focusing on another element, or submitting a form.

3.2.3 To help your users to find the content they want on each webpage, you should put your navigation elements in the same place on each webpage. (This doesnt apply when your user has changed their preferences or when they use assistive technology to change how your content appears.)

3.2.4 When a set of webpages includes things that have the same functionality on different webpages, you should name those things consistently. For example, dont use the word Search for the search box on one webpage and Find for the search box on another webpage within that set of webpages.

3.2.5 Lets go back to major changes, such as a new window opening, another element taking focus, or a form being submitted. You could make sure that they only happen when users deliberately make them happen, or when you have warned users about them first. For example, you could give the user a button for updating some content instead of automatically updating that content. Also, if a link will open in a new window, you could add the words opens in new window to the link text.

3.3.1 Users make mistakes when filling in forms. Your website must identify each mistake to your user, and must describe the mistake to your users in text so that the user can fix it. One way to identify mistakes reliably to your users is to set the aria-invalid attribute to true in the element that has a mistake. That makes sure that users with assistive technology will be alerted about the mistake. Of course, you can then use the [aria-invalid="true"] attribute selector in your CSS to visually highlight any such mistakes. Also, look into how certain attributes of the input element such as required, type, and list can help prevent and highlight mistakes.

3.3.2 You must include labels or instructions (and possibly examples) in your websites forms, to help your users to avoid making mistakes.

3.3.3 When your user makes a mistake when filling in a form, your webpage should suggest ways to fix that mistake, if possible. This doesnt apply in scenarios where those suggestions could affect the security of the content.

3.3.4 Whenever your user submits information that:

• has legal or financial consequences; or
• affects information that they have previously saved in your website; or
• is part of a test

you should make sure that they can:

• undo it; or
• correct any mistakes, after your webpage checks their information; or
• review, confirm, and correct the information before they finally submit it.

3.3.5 You could help prevent your users from making mistakes by providing obvious, specific help, such as examples, animations, spell-checking, or extra instructions.

3.3.6 Whenever your user submits any information, you could make sure that they can:

• undo it; or
• correct any mistakes, after your webpage checks their information; or
• review, confirm, and correct the information before they finally submit it.

Have you made your website robust enough to work on your users browsers and assistive technologies?

The fourth and final guideline has criteria that help you prevent your users from asking, Why the **** doesnt this work on my device?

4.1.1 You must make sure that your website works as well as possible with current and future browsers and assistive technology. Prioritise complying with web standards instead of relying on the capabilities of currently popular devices and browsers. Web developers didnt expect their users to be unwrapping the Wii U Browser five years agowho knows what browsers and assistive technologies our users will be unwrapping in five years time? Avoid hacks, and use the W3C Markup Validation Service to make sure that your HTML has no errors.

4.1.2 If you develop your own user interface components, you must make their name, role, state, properties, and values available to your users browsers and assistive technologies. That should make them almost as accessible as standard HTML elements such as links, buttons, and checkboxes.

and a partridge in a pear tree!

as that very long Christmas song goes. Weve covered a lot in this articlebecause your users have a lot of different levels of ability. Hopefully this has demystified the Web Content Accessibility Guidelines 2.0 for you. Hopefully you spotted a few situations that could arise for users on your website, and you now know how to tackle them.

To start applying what weve covered, you might like to look at Sarah Horton and Whitney Quesenberys personas for Accessible UX. Discuss the personas, get into their heads, and think about which aspects of your website might cause problems for them. See if you can apply what weve covered today, to help users like them to do what they need to do on your website.

How to know when your website is perfectly accessible for everyone

LOL! There will never be a time when your website becomes perfectly accessible for everyone. Dont aim for that. Instead, aim for regularly testing and making your website more accessible.

Web Content Accessibility Guidelines (WCAG) 2.1

The W3C hope to release the Web Content Accessibility Guidelines (WCAG) 2.1 as a recommendation (thats what the W3C call something that we should start using) by the middle of next year. Ten years may seem like a long time to move from version 2.0 to version 2.1, but consider the scale of the task: the editors have to update the guidelines to cover all the new ways that people interact with new technologies, while keeping the guidelines backwards-compatible. Keep an eye out for 2.1!

Youll go down in history

One last point: Ive met a surprising number of web designers and developers who do great work to make their websites more accessible without ever telling their users about it. Some of your potential customers have possibly tried and failed to use your website in the past. They probably wont try again unless you let them know that things have improved. A quick Twitter search for your websites name alongside phrases like assistive technology, doesnt work, or #fail can let you find frustrated usersso you can tell them about how youre making your website more accessible. Start making your websites work better for everyoneand please, let everyone know.

About the author

Alan Dalton worked for Irelands National Disability Authority for 9 years, mostly as Accessibility Development Advisor. That involved working closely with public sector bodies to make websites, services, and information more accessible to all users, including users with disabilities. Before that, he was a consultant and trainer for Software Paths Ltd. in Dublin. In his spare time, he maintains StrongPasswordGenerator.com to help people stay safe online, tweets, and takes photos.

More articles by Alan