Skip To Content
Accessibility

WCAG 2.1 Standards

Perceivable #

Info and interfaces must be shown in ways all users can perceive. Different stress cases don't stop users from reading, watching, or listening to your content.

Adaptability #

Content can be created in different ways without losing information or structure.

Mobile content is not limited by either a vertical or horizontal orientation and works properly on both. There are situations where someone may be unable to rotate it, such as mounted displays on wheelchairs or being in a high-pressure, low-time situation.

Input fields can programmatically determine what to fill in based on past information. Mail order forms can autofill addresses and payment info automatically. This helps this with cognitive or physical disabilities that'd have difficulties entering complex info repeatedly.

Distinguishable #

Users can properly see and hear content, telling it apart from the website's background.

Content shouldn't require two-dimensional scrolling for smaller screen sizes. The exception is for more complex content that can't be restricted to this size, like complicated graphs. But this shouldn't impact the entire site. This also applies when users zoom in to better read the text.

User and graphical interfaces (like buttons, form inputs, and bar charts) also must have enough color contrast with the background. Specifically a 3:1 contrast ratio.

Markdown-compatible paragraphs of text must still be readable (such as no overlaps) if users were to adjust the text styles to the below. Note that the site itself doesn't need these styles themselves, but they shouldn't make content unreadable.

All content that appears on hover must also meet the following rules:

Operable #

Interfaces and navigations must be operable. Different stress cases don't keep users from getting to all the pages and filling out the forms.

Keyboard Accessibility #

Ensuring all functionality is available for keyboard users.

Keyboard shortcuts implemented by hitting a single letter or character should meet the following rules:

Enough Time #

Ensure users have enough time to read the content.

Users should be told about the amount of time that needs to pass until a timeout that would cause any form of data loss. The limit should be conveyed in real-time if possible. The exception is if it preserves data for at least 20 hours afterward.

Seizures and Physical Reactions #

Content shouldn't cause these things. Duh.

Users should be able to disable any content with any kind of motion animation unless it is essential to function or information.

Input Modalities #

Users should be able to operate inputs in ways other than just the mouse and keyboard.

Any gestures that require users to click multiple points or trace their cursor along a path should have a single-point or standard input option. Exceptions if these types of inputs are essential for some reason.

Any single-pointer functionality should have at least one of the following functionalities (pointer cancellation):

Also, the visually presented label of each input should match that input's name property.

Functionalities activated by motions, like shaking the device, should have UI alternatives not reliant on the motion. Responses to the motion should also have an option to disable them and prevent future accidental activations unless it's essential to the functionality.

Targets for pointer inputs should be at least 44 x 44 pixels large. Exceptions are when:

Switching back and forth between the types of input (mouse, stylus VoiceOver, etc) doesn't render web content impossible to use or interact with. Exceptions are when they're essential based on security or user settings.

Understandable #

Info and interfaces must be understandable. Stress cases don't prevent users from understanding the site's intended meaning.

Robust #

Content should be robust enough that a wide array of user agents, like assistive tech, can reliably interpret it. Stress cases don't prevent users from accessing the content from a wide variety of devices.

Compatible #

Helps ensure web content is still compatible with current and future user agents and assistive tech.

Status messages can be programmatically seen (through markup like aria roles) so users with assistive tech can be made aware of them without focusing in on them.

Resources