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.
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
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
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.
Get in touch
Either contact us using the details below, or fill out this form to send your message. If you’ve got a brief ready then attach that too. We’ll get back to you as soon as possible. email@example.com+44 (0) 20 3137 5612 86-90 Paul Street, Shoreditch, London EC2A 4NE