Web Content Accessibility Guidelines (WCAG)

So you want to make your website or app accessible to as many audiences as possible? In which case, you’ve probably heard of Web Content Accessibility Guidelines (WCAG).

These guidelines are now (as of June 2018) in version 2.1, having evolved with the adoption of modern devices and browsers.

Many WCAG requirements may seem like common sense, but they need to be planned into a website or app from its first planning stages, as the implications on a project are wider than just its design or development. All content production could be affected, as will the tone of voice of the copy (and hence potentially the business).

In most circumstances, typical website audiences don’t tend to require more than a Level A rating, but certain environments have specific Web Content Accessibility Guidelines (WCAG) requirements, and this is often something you’ll see in a web development brief from a healthcare or education client.

Level A

• All non-text media should have text equivalents
• Alternatives for prerecorded video and audio
• Instructions do not rely on solely sensory characteristics (size, shape, location)
• Structure and relationships  and content reading sequence can be programmatically determined
• Colour is not used as the sole means of conveying information
• Controls for pausing sound are available
• All functionality should be keyboard accessible
• if suddenly not using the tab keyboard button to change the currently focussed element, you must warn the user.
• Time limits can be turned off or adjusted etc.
• Moving, blinking or auto-updating content can be paused or hidden.
• No more than three flashes per second or no opposing flashes involving a saturated flash or the combined area of flashes occupied occupies no more than 25% of any 10-degree visual field on the screen at the typical viewing distance
• Method to skip content blocks that occur on multiple web pages
• Page titles describe topic and purpose
• Focus order can be navigated sequentially
• Purpose of link can be determined from the link text alone or link text and programmatically determined context
• The default language of the page can be programmatically determined
• Don’t change the order or appearance of elements as you’re focussing on them.
• Don’t change the information surrounding a dropdown field on changing the value unless you’ve warned the user.
• Describe errors to users in the text
• Labels are required when content requires user input
• Use valid markup language
• Set name and role or all user interface components within the markup

Level AA

Meet Level A, and:

• Captions on all audio
• Descriptions of all audio
• Text/background contrast ratio of at least 4.5:1
• Text can be resized up to 200%
• More than one way to locate a page within the site
• Headings describe topics or purpose
• Make it clear which field input you’re currently entering information into
• Human language can be programmatically determined
• Navigation and components should appear consistently
• Validation suggestions should be shown to the user i.e. if it’s an email field, they should be told that that’s the correct format to enter
• Web forms for financial, legal or other data must either have a confirm stage, a validation process or be reversible

Level AAA

Meet Level AA, and:

• Provide signed language versions of all video content
• Extended written descriptions of all audio content
• Alternatives to any time-based media (live and prerecorded)
• Text / background contrast ratio of least 7:1
• No background sound (or can be disabled)
• Blocks of text:
  • Foreground and background colours can be selected by the user
  • No more than 80 characters wide
  • At least line and a half line spacing within paragraphs
  • Text can be resized up to 200% without requiring horizontal scrolling
• No images of text
• You should be able to scroll, navigate, zoom in/out, press buttons, check checkboxes, etc. without using the mouse (just the keyboard)
• No timing necessary anywhere
• Interruptions/alerts can be suppressed by the user
• Remembers data entered by the user even if their session expires i.e. using cookies
• No more than 3 flashes per second
• Show location within the content (i.e. breadcrumbs, secondary navigation bars)
• Be able to identify the purpose of text links without clicking on them
• Section headings used to organise content
• Unusual words and abbreviations are defined
• Reading level of no more than a 11-14-year-old’s ability
• Identifying specific pronunciation of words where meaning is ambiguous 
• Only change the context of the page by user request
• Help icons and tooltips/explanations available where unclear
• All web forms must either have a confirm stage, a validation process or be reversible

If you’d like to find out how Purr could help with implementing Web Content Accessibility Guidelines into your web or app project, use the form below to get in touch.