The following is
NOT
the Web Content Accessibility Guidelines (WCAG) 2. It is a checklist that presents our recommendations for implementing the most common accessibility principles and techniques for those seeking WCAG conformance. The language used here significantly simplifies and condenses
the official WCAG 2.2 specification
and supporting materials to make it easier to implement and verify for web pages. The checklist contains links to the official success criteria.
Images, image buttons, and image map hot spots have appropriate, equivalent
alternative text
.
Images that do not convey content, are decorative, or contain content that is already conveyed in text are given empty alternative text (
alt=""
) or implemented as CSS backgrounds. All linked images have descriptive alternative text.
Equivalent alternatives to complex images are provided in context or on a separate linked page.
Guideline 1.2
Provide alternatives for time-based media.
NOTE: If the audio or video is designated as an alternative to web content (e.g., an audio or sign language version of a web page, for example), then the web content itself serves as the alternative.
A descriptive transcript
or
audio description is provided for non-live video.
NOTE: Only required if there is relevant visual content that is not presented in the audio.
When audio description cannot be added to video due to insufficient pauses in the audio, an alternative version of the video with pauses that allow audio descriptions is provided.
A descriptive transcript is provided for pre-recorded media that has a video track. For optimal accessibility, WebAIM strongly recommends transcripts for all multimedia.
Semantic markup
is appropriately used to designate headings, regions/landmarks, lists, emphasized or special text, etc.
Tables
are used for tabular data and data cells are associated with their headers. Data table captions, if present, are associated to data tables.
Text labels
are associated with form inputs. Related form controls are grouped with fieldset/legend. ARIA labelling may be used when standard HTML is insufficient.
Instructions do not rely upon shape, size, or visual location (e.g., "Click the square icon to continue" or "Instructions are in the right-hand column").
Instructions do not rely upon sound (e.g., "A beeping sound indicates you may continue.").
Color is not used as the sole method of conveying content or distinguishing visual elements.
Color alone is not used to distinguish
links
from surrounding text unless the
contrast ratio
between the link and the surrounding text is at least 3:1
and
an additional distinction (e.g., it becomes underlined) is provided when the link is hovered over and receives keyboard focus.
No loss of content or functionality occurs, and horizontal scrolling is avoided when content is presented at a width of 320 pixels.
This requires responsive design for most web sites. This is best tested by setting the browser window to 1280 pixels wide and then zooming the page content to 400%.
Content that requires horizontal scrolling, such as data tables, complex images (such as maps and charts), toolbars, etc. are exempted.
A contrast ratio of at least 3:1 is present for differentiating graphical objects (such as icons and components of charts or graphs) and author-customized interface components (such as buttons, form controls, and focus indicators/outlines).
At least 3:1 contrast is maintained in the various states (focus, hover, active, etc.) of author-customized interactive components.
No loss of content or functionality occurs when the user adapts paragraph spacing to 2 times the font size, text line height/spacing to 1.5 times the font size, word spacing to .16 times the font size, and letter spacing to .12 times the font size.
This is best supported by avoiding pixel height definitions for elements that contain text.
When additional content is presented on hover or keyboard focus:
The newly revealed content can be dismissed (generally via the Esc key) without moving the pointer or keyboard focus, unless the content presents an input error or does not obscure or interfere with other page content.
The pointer can be moved to the new content without the content disappearing.
The new content must remain visible until the pointer or keyboard focus is moved away from the triggering control, the new content is dismissed, or the new content is no longer relevant.
All page functionality is available using the
keyboard
, unless the functionality cannot be accomplished in any known way using a keyboard (e.g., free hand drawing).
Page-specified shortcut keys and accesskeys (accesskey should typically be avoided) do not conflict with existing browser and screen reader shortcuts.
Keyboard
focus is never locked or trapped at one particular page element. The user can navigate to and from all navigable page elements using only a keyboard.
If a keyboard shortcut uses printable character keys, then the user must be able to disable the key command, change the defined key to a non-printable key (Ctrl, Alt, etc.), or only activate the shortcut when an associated interface component or button is focused.
Guideline 2.2
Provide users enough time to read and use content.
If a page or application has a time limit, the user is given options to turn off, adjust, or extend that time limit. This is not a requirement for real-time events (e.g., an auction), where the time limit is absolutely required, or if the time limit is longer than 20 hours.
Automatically moving, blinking, or scrolling content (such as carousels, marquees, or animations) that lasts longer than 5 seconds can be paused, stopped, or hidden by the user.
Automatically updating content (e.g., a dynamically-updating news ticker, chat messages, etc.) can be paused, stopped, or hidden by the user or the user can manually control the timing of the updates.
No page content
flashes
more than 3 times per second unless that flashing content is sufficiently small and the flashes are of low contrast and do not contain too much red. (
See general flash and red flash thresholds
)
A link is provided to
skip navigation
and other page elements that are repeated across web pages.
While proper use of headings or regions/landmarks is sufficient to meet this success criterion, because keyboard navigation by headings or regions is not supported in most browsers, WebAIM recommends a "skip" link in addition to headings and regions.
The purpose of each link (or image button or image map hotspot) can be determined from the link text alone, or from the link text and its context (e.g., surrounding text, list item, previous heading, or table headers).
Links with the same text that go to different locations are readily distinguishable.
Multiple ways
are available to find other web pages on the site - at least two of: a list of related pages, table of contents, site map, site search, or list of all available web pages.
Page headings and labels for form and interactive controls are informative. Avoid duplicating heading and label text unless the structure provides adequate differentiation between them.
If a web page is part of a sequence of pages or within a complex site structure, an indication of the current page location is provided, for example, through breadcrumbs or specifying the current step in a sequence (e.g., "Step 2 of 5 - Shipping Address").
If a custom focus indicator or background color is in place, the focus indicator pixels must:
have at least 3:1 contrast between focused/unfocused states
be at least as large as the area of a 2 pixel thick perimeter surrounding the element. The formula
(width × 4) + (height × 4) = focus indicator area
can be used for rectangular components.
Guideline 2.5
Make it easier for users to operate functionality through various inputs beyond keyboard.
If multipoint or path-based gestures (such as pinching, swiping, or dragging across the screen) are not essential to the functionality, then the functionality can also be performed with a single point activation (such as activating a button).
To help avoid inadvertent activation of controls, avoid non-essential down-event (e.g.,
onmousedown
) activation when clicking, tapping, or long pressing the screen. For complex interactions (such as drag and drop),
onmousedown
can be used if an associated
onmouseup
(or similar) event can be aborted or reversed.
If an interface component (link, button, etc.) presents text (or images of text), the accessible name (label, alternative text, aria-label, etc.) for that component must include the visible text.
Functionality that is triggered by moving the device (such as shaking or panning a mobile device) or by user movement (such as waving to a camera) can be disabled and equivalent functionality is provided via standard controls like buttons.
Clickable targets are at least 44 by 44 pixels in size unless an alternative target of that size is provided, the target is inline (such as a link within a sentence), the target is not author-modified (such as a default checkbox), or the small target size is essential to the functionality.
Content does not require a specific input type, such as touch-only or keyboard-only, but must support alternative inputs (such as using a keyboard on a mobile device).
Pointer input target sizes are at least 24 by 24 pixels unless:
A 24 pixel diameter circle centered on the target element does not intersect with any other target or a 24 pixel circle centered on an adjacent target.
The functionality can be achieved in some other conformant manner.
The target is in a sentence or list.
The target size can't be modified or is essential to the functionality.
Words
that may be ambiguous, unfamiliar, or used in a very specific way are defined through adjacent text, a definition list, a glossary, or other suitable method.
The meaning of an unfamiliar abbreviation is provided by expanding it the first time it is used, using the
<abbr>
element, or linking to a definition or glossary.
A more understandable alternative is provided for content that is more advanced than can be reasonably read by a person with roughly 9 years of primary education.
If the pronunciation of a word is vital to understanding that word, its pronunciation is provided immediately following the word or via a link or glossary.
Guideline 3.2
Make Web pages appear and operate in predictable ways.
When a page element receives focus, it does not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user.
When a user inputs information or interacts with a control, it does not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user unless the user is informed of the change ahead of time.
Elements that have the same functionality across multiple web pages are consistently identified. For example, a search box at the top of the site should always be labeled the same way.
Substantial changes to the page, the spawning of pop-up windows, uncontrolled changes of keyboard focus, or any other change that could confuse or disorient the user must be initiated by the user. Alternatively, the user is provided an option to disable such changes.
Required inputs or inputs that require a specific format, value, or length provide this information within the element's label.
Form validation
errors are efficient, intuitive, and accessible. The error is clearly identified, quick access to the problematic element is provided, and the user can easily fix the error and resubmit the form.
If an input error is detected (via client-side or server-side validation), suggestions are provided for fixing the input in a timely and accessible manner.
Information that a user must re-enter to complete a single-session process must be auto-populated or available for the user to select, unless re-entering the information is essential to the functionality, the information poses security issues, or the previously-entered information is no longer valid.
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless the cognitive function test can be bypassed in some way, can be completed with assistance by some other mechanism, uses object recognition (such as "click on the photo of a flower"), or uses identification of non-text content provided by the user (such as a user-provided image).
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless the cognitive function test can be bypassed in some way or can be completed with assistance by some other mechanism.
Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Guideline 4.1
Maximize compatibility with current and future user agents, including assistive technologies.
NOTE: This success criterion is no longer useful and as of 2023 has been removed from WCAG. It previously required that significant HTML validation/parsing errors be avoided.
Markup is used in a way that facilitates accessibility. This includes following the HTML specifications and using forms, input labels, frame titles, etc. appropriately.
ARIA is used appropriately to enhance accessibility when HTML is not sufficient.
If an important status message is presented and focus is not set to that message, the message must be announced to screen reader users, typically via an ARIA alert or live region.
Institute for Disability Research, Policy, and Practice
Utah State University
6807 Old Main Hill
Logan, UT 84322-6807
435.797.7024
