WCAG 2.1 — New Accessibility Standard is Now Official!
tl;dr
A new version of the most important standards on web accessibility in the world has been published! On June 5, Web Content Accessibility Guidelines (WCAG) version 2.1 officially became a W3C Recommendation.
All of WCAG 2.0 still applies and is incorporated into WCAG 2.1. The new version also includes additional success criteria to help make mobile technology more accessible, and to provide more assistance for people that have low vision or cognitive issues.
Why Accessibility?
Many people have disabilities that affect their ability to access the web.
Depending on the situation, people with disabilities may leverage special tools and technologies to interact with the web. For example, someone who is blind may use a screen reader that reads websites out loud and provides flexible keyboard-based website navigation tools.
Websites need to be coded in specific ways to work well with assistive technology, and to provide a good experience for people of all abilities.
Fortunately, there are some excellent guidelines and resources on how to do it.
Accessibility Standards and WCAG
The World Wide Web Consortium (W3C) is the main standards body that helps organize the World Wide Web. The W3C publishes guidelines for making websites accessible to people with disabilities.
Since 2008, the W3C’s latest accessibility standard has been the Web Content Accessibility Guidelines (WCAG) 2.0. This is the most important international standard for web accessibility. Many government standards around the world either directly reference this standard, or publish their own standards that are closely based on it. It is written in a very flexible way that will stay relevant as technology evolves.
WCAG 2.0 includes three levels of compliance, ranging from basic (level A) to extremely comprehensive (level AAA). The most common target for compliance is the middle level, AA.
WCAG 2.1 is Official
On June 5, 2018, WCAG 2.1 became an official standard, with the W3C moving it to Recommendation status. If you already invested in bringing your website up to speed with WCAG 2.0 don’t worry, your work is not wasted. All of WCAG 2.0 still applies and is incorporated into WCAG 2.1. The new version also includes 17 additional success criteria to help make mobile technology more accessible, and to provide assistance for people that have low vision or cognitive issues.
Am I in trouble if my site is not WCAG 2.1 compliant?
There’s not a clear answer to this question; there are a lot of situational qualifiers.
For many websites there is no legal obligation to be accessible. The decision is a moral and ethical one, with some business considerations. On the business side, if you have an accessible site and your main competitor doesn’t, you may have an advantage reaching some additional customers.
Other sites may have contractual or regulatory obligations to meet a certain standard, potentially based on industry. If that’s the case, whether you need to hit WCAG 2.1 or not will depend on how agreements are written up. If you are on the hook to specifically hit WCAG 2.0 you may not need to immediately update, but that may change when your contract renews.
The Americans with Disabilities Act, specifically ADA Title III, can also have a big impact on accessibility obligations when your business is considered a public accommodation. This is another murky area of law, as the ADA legislation itself includes no details on how online properties should be handled, and the courts have been left to decide. If you are covered by ADA Title III, the safest move would be to ensure your website complies with WCAG 2.1, level AA.
What should I do about these new standards if I don’t have any obligations to be accessible?
As I have written and spoken about in in the past. I’m a big advocate of inclusive design practices. By building in accessibility, you will make your site available to people whose disabilities require accommodations. You will also make it more comfortable to work with for everyone else.
If you are starting a new website project, I’d recommend using the new standards, WCAG 2.1 AA, as a target. Even hitting level A will be a big help.
WCAG 2.1 — More Information on the Changes
If you are interested in the types of new requirements that were published, a list is below. This list is simplified to show the main point of each success criterion.
Check out the W3C list of what’s new in WCAG 2.1 for the comprehensive, official version.
Level A — New Success Criteria
Character Key Shortcuts — If you have an application with single character keyboard shortcuts, don’t force a user to use your shortcuts. Allow the user to turn shortcuts off or remap them using non-printable keyboard characters like control and alt.
That way people can avoid accidentally initiating a shortcut, such as if using voice inputs.
Character Key Shortcuts details from W3C
Pointer Gestures — If an action requires a multi-point touch or path based gesture to execute, there must be an easier option to accomplish the same thing.
That way people with restricted movement in their hands or coordination challenges (e.g. Cerebral Palsy) can still zoom a map with a simple action (e.g. zoom button) even if they can’t easily pinch and zoom with their hands.
Pointer Gestures details from W3C
Pointer Cancellation — When people start clicking a button with a mouse and realize that they are starting to click the wrong thing, they have a way to back out and abort their action by moving their mouse before releasing the button. Similarly on touch screens, if you start touching the wrong button you can move your finger off of the button before picking it up off the screen, and cancel.
That way it will be easier to undo mistakes before they cause any problems or extra work.
Pointer Cancellation details from W3C
Label in Name — In the back end code for buttons and other user interface components, the names for the component must match the label that displays to users.
If things are not coded that way, and a label that displays on a form button is “save,” but the name in the back end code is “submit,”every time you try to say “save” nothing will happen — and you won’t know the real trigger word is “submit.”
Label in Name details from W3C
Motion Actuation — If you have functionality that requires moving a device around to kick off an action, there needs to be an optional way to kick off that same action with a standard UI component like a button.
That way people that have a mobile device mounted to a wheelchair can still use the functionality. It also won’t be problematic for people with conditions like tremors where their hands may shake.
Level AA — New Success Criteria
Orientation — Content on mobile devices should be fully functional if your device is oriented either portrait or landscape.
That way people with devices secured to wheelchairs in a single orientation will be able to access all functionality.
Identify Input Purpose — Form fields must be tagged or identified in a way so that other technologies know the data that should go in each field.
That way someone that has difficulty typing a lot of data can have form fields filled in for them automatically by their browser or assistive technology.
Identify Input Purpose details from W3C
Identify Purpose — Identify the purpose of page elements like UI components, icons and regions through on page tagging and markup.
That way someone can use their own favorite technology to map navigation or UI elements to symbols or hot keys that they can understand and use more easily. Someone can also use their own assistive technology to filter out non-core content regions.
Identify Purpose details from W3C
Reflow — When you zoom in on text, nothing should get cut off and the scrolling should only go in one direction (e.g. vertical scroll down the page). This should support zooming content to 400% of its native size.
That way people with low vision can easily zoom without introducing new navigation challenges like both horizontal and vertical scrolling requirements. This is very similar to how many responsive design websites already work.
Non-Text Contrast — On user interface components and on graphics required to understand context, use at least a 3:1 contrast ratio.
That way someone with poor vision will be able to clearly understand the page.
Non-text Contrast details from W3C
Text Spacing — Spacing in text like line height, paragraph breaks, letter spacing and word spacing should be able to be adjusted larger to reduce visual clutter and improve readability, without losing content or functionality.
That way someone with dyslexia or poor vision can use their own user style sheets to override the default website styles and improve their ability to use the website.
Content on Hover or Focus — Sometimes when you move your mouse over an object on a page, or tab in through the keyboard, some content on the page will pop-up. That content shouldn’t automatically go away when you move your mouse, but it should be dismissable if desired.
That way users with screen magnifiers will have a chance to go and read the pop-ups before they disappear.
Content on Hover or Focus details from W3C
Status Messages — Allow any status messages that you display to be tagged in a way that assistive technologies like screen readers will be aware of them without the user having to navigate over and give focus to the status message.
That way the user will have full knowledge of important updates the page is giving, like whether an action to submit information succeeded or failed.
Level AAA — New Success Criteria
Timeouts — Warn site users when information they are filling in could be lost after a period of inactivity — including letting them know up front how much inactivity time will clear the data.
That way the user will not be surprised that the data they were filling in on the form got cleared just because they took a break from the form for a bit.
Animation from Interactions — Your visitors can disable motion animation on the page.
That way people with disorders where symptoms are triggered by on-screen motion have an option to have an online experience without discomfort.
Animation from Interactions details from W3C
Target Size — Anything requiring pointer input like a mouse click, has a target to click on that is fairly large — at least a square of 44 x 44 pixels.
That way it will be easier to hit buttons and harder to accidentally hit the wrong button.
Concurrent Input Mechanisms — Don’t restrict people from using different input devices- even switching around while in the middle of an activity.
People may benefit from using different types of input devices. For instance, someone might have a touch screen tablet paired with a Bluetooth keyboard and mouse.
By allowing people to switch at any time, you can allow them to find the best input type for their action. If they prefer to navigate with a touch screen and enter form data with a keyboard, they will be able to do so.
