What You Need to Know About WCAG 2.1
This post originally appeared on viget.com.
This summer, W3C rolled out additions to its guidelines on web accessibility. Here’s what you need to know:
Background on WCAG
The Web Content Accessibility Guidelines (WCAG) 2.0 have been the international standard for accessibility since the European Union adopted them in 2016. WCAG 2.1 adds new requirements to each of the three compliance levels (A, AA, and AAA). Here at Viget, we aim to comply with WCAG Level A on all projects and we work with clients to determine which aspects of AA and AAA compliance are appropriate for their audiences.
What’s New in Level A
Label and name text should match on HTML elements (2.5.3). It’s important to note that this standard isn’t necessarily referring to the
name attribute on input elements. For some elements, identifiable text could be a label, the text inside the element or the
Don’t rely on device motion or wild pointer gestures for functionality (2.5.4 & 2.5.1). This one may seem like a no-brainer, but as digital experiences continue to push the limits, accessibility can be forgotten. That doesn’t mean you can’t use gestures and motion, but add a boring old button as a fallback.
Keep an eye on keyboard shortcuts (2.1.4). Any added keyboard shortcuts should be remappable or able to be turned off. A secondary recommendation is to only listen for keyboard shortcuts when an item is in focus.
Actions on mouse-down are a thing of the past (2.5.2). When the user clicks, they should always have the option to cancel the action. This is good UX, but also allows the user to make mistakes without, say, spending $200 by accident or sending a message before it’s ready.
What’s New in Level AA
Sites must work in portrait and landscape orientation (1.3.4). Don’t lock the viewport to portrait orientation on mobile. Sorry, but just don’t.
Input purpose can be programmatically determined (1.3.5). This can be accomplished using the autocomplete attribute and/or the
type attribute. The
name attribute also plays a role here. If you have
<input type="text" name="first-name">, the browser will typically auto-fill your name for you, if allowed to use autocomplete.
Content should reflow down to 320px wide (1.4.10). You’ve likely been looking for a magic number to keep designers and front-end developers on the same page when it comes to responsive UI. Now, you have it.
Contrast requirements now apply to UI elements and graphics (1.4.11). Any interactive element or important graphic must have a 3:1 minimum contrast ratio with its background color.
Allow custom stylesheets to change font properties (1.4.12). If a user has a custom stylesheet configured to maintain readability across sites, then your styles should not override it. W3C identifies line height, letter spacing, word spacing, and margins on paragraph and heading elements as key properties that users should be able to override.
Hover-triggered content has 3 new rules (1.4.13).
Hoverable. The user must be able to hover over the additional content without it disappearing.
Persistent. The content remains visible until the user chooses to dismiss it.
Dismissible. Without moving your mouse or focus, the user can dismiss the content. Usually this is done with the ESC key.
Status messages are marked as such (4.1.3). If you update the user on the success or failure of an action, or otherwise provide status updates, that text must be marked appropriately, either by the
roleattribute or by utilizing an aria-live element.
What’s New in Level AAA
Purpose of icons, regions, etc can be programmatically determined (1.3.6). You must indicate, via some text,
role, or another attribute, the purpose of icons, regions and UI components.
Users should be aware of any inactivity timeouts under 20 hours (2.2.6). If a user could lose data due to a timeout of less than 20 hours, you must let them know. If someone’s going to lose those Hamilton tickets if they leave the page open for an hour, they should know that from the start.
Interactive-triggered animations and motion can be turned off (2.3.3).
Target size should be 44px by 44px (2.5.5). WCS has identified this base size for targets (buttons, links, etc.) as 44px by 44px. One key exception: this standard is not required if the target can be accessed via another link or control on the same page that is 44px by 44px. This has been a long-established standard in Apple’s Human Interface Guidelines for iOS, which has now been extrapolated for the web.
Don’t use platform-specific inputs (2.5.6). This standard aims to allow users to switch between modes of input while interacting with content.
WCAG aims to make the web a more accessible place for all. The standards all come with the caveat that elements essential to the information being presented may not comply. I encourage you to be an advocate for accessibility on digital project teams. Understanding the standards is the first step in making your sites more accessible to all. In some places, compliance is the law. In all places, compliance is helping build a more inclusive web.
For more from Viget on web accessibility, check out #accessibility.