Deque Web Accessibility Checklist

Based on WCAG 2.1 AA

Background ......................................................................................................................................................................... 2
Web Content Accessibility Guidelines ............................................................................................................................ 2
Accessibility Training....................................................................................................................................................... 2
Deque Accessibility Evaluation Software ........................................................................................................................ 2
Section 1: Structure and Semantics .................................................................................................................................... 3
General Notes About Semantic Markup: ........................................................................................................................ 3
Page Title ........................................................................................................................................................................ 3
Page Language ................................................................................................................................................................ 4
Headings ......................................................................................................................................................................... 5
Landmarks ...................................................................................................................................................................... 6
Lists ................................................................................................................................................................................. 7
Tables.............................................................................................................................................................................. 8
Iframes ............................................................................................................................................................................ 9
Markup Validity............................................................................................................................................................. 10
Other Semantic Elements ............................................................................................................................................. 11
Section 2: Links and Navigation ........................................................................................................................................ 12
Links .............................................................................................................................................................................. 12
Site Navigation .............................................................................................................................................................. 14
Navigation within the Same Page ................................................................................................................................. 15
Reading Order and Focus Order ................................................................................................................................... 16
Section 3: Images and Visual Design ................................................................................................................................. 17
Images .......................................................................................................................................................................... 17
Color and Contrast ........................................................................................................................................................ 19
Text Styles, Resize, Reflow, and Zoom .......................................................................................................................... 20
Visual Cues .................................................................................................................................................................... 22
Responsive and Adaptive Design .................................................................................................................................. 23
Section 4: Multimedia, Animations, and Motion .............................................................................................................. 24
Audio and Video ........................................................................................................................................................... 24
Animation, Motion, and Timed Content ....................................................................................................................... 27
Section 5: User Input, Forms, and Dynamic Content ........................................................................................................ 28
Device-Independent User Input (Keyboard, Mouse, Touch, Voice, etc.) ...................................................................... 28
Form Inputs, Labels, and Instructions ........................................................................................................................... 31
Form Validation and Feedback ..................................................................................................................................... 34
Dynamic Content (JavaScript, Single-Page Apps, etc.) .................................................................................................. 36
Custom JavaScript/ARIA Components .......................................................................................................................... 37
CAPTCHA....................................................................................................................................................................... 41
Avoid CAPTCHAs if Possible .......................................................................................................................................... 41

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems Page 1
Background

Deque recommends using a combination of software tools and informed human analysis – using a checklist such as the
one in this document – to test web accessibility.

Web Content Accessibility Guidelines

This checklist is based on the Web Content Accessibility Guidelines 2.1, W3C World Wide Web Consortium
Recommendation 05/06/2018 (https://www.w3.org/TR/2018/REC-WCAG21-20180605/, Latest version at
https://www.w3.org/TR/WCAG21/).

Accessibility Training
• Find detailed online accessibility courses and reference materials on Deque University.
• Experienced Deque web accessibility instructors are also available

Deque Accessibility Evaluation Software

axe DevTools is an automated and guided accessibility testing solution for Component Developers, Front-End Developers,
Native Mobile App Developers and Test Engineers that allows you to easily find and fix 76-84% of accessibility errors
before your applications get out of development. Solutions for Unit Testing, Test Automation, and integration with
popular testing frameworks such as Selenium and QUnit, combined with in-browser testing using Deque's Attest
extensions for Chrome and Firefox, allow you incorporate accessibility testing into your existing local development and
testing environment.

axe Auditor is a manual accessibility testing solution for Accessibility Testing Specialists that allows you to optimize your
accessibility testing, tracking, and reporting with step-by-step guidance and report building. Based on The Deque Way of
accessibility testing, your QA team can run both manual and automated tests in the same interface, and without needing
to be accessibility experts themselves, they can create precise, consistent accessibility issue reports for developers to
resolve, then rerun tests on new builds and across multiple browsers to verify requirements have been met.

axe Monitor is an enterprise-level scanning and reporting tool that can evaluate the web accessibility of entire web sites,
including password-protected areas. axe Monitor can implement use case scripts, allow custom reporting options based
on WCAG or Section 508 guidelines, and allow scheduled monitoring of accessibility on projects of any scale or
complexity. It is designed to work in conjunction with the axe DevTools Browser Extension for Chrome and Firefox.

axe, the Accessibility Engine, is Deque's free, open-source JavaScript accessibility rules library and browser extension. It
was developed to be fast and to return zero false errors or duplicate results, and it is available as a GitHub repository,
browser plugin, or framework integration.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems Page 2
Section 1: Structure and Semantics

General Notes About Semantic Markup:

If the technology used provides semantic structure to convey the relationships between information:

• Use semantic markup to mark emphasized or special text.

• Use text to convey information that is conveyed by variations of presentation of text.
• Separate information and structure from presentation. Do not use style to convey structure.

Page Title
Topic Technique WCAG AA
Markup Correct markup: The page <title> MUST be present and MUST contain text. Required
WCAG 2.4.2
Meaningful Accurate and informative: The page <title> MUST be accurate and informative. Required
Text WCAG 2.4.2
Dynamic pages: The page <title> of dynamic pages (e.g. in single page apps) Required
MUST be updated when the purpose of the page changes. WCAG 2.4.2
User Actions: If a page is the result of a user action or scripted change of context, Best practice
the text of the <title> SHOULD describe the result or change of context to the
user.
Concise: The <title> SHOULD be concise. Best practice

Unique: The page <title> SHOULD be unique, if possible. Best practice

Unique info first: Unique information SHOULD come first in the <title>. Best practice
Match heading: The page <title> SHOULD match (or be very similar to) the top Best practice
heading (ideally marked as <h1>) in the main content.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems Page 3
Page Language
Topic Technique WCAG AA
Page Page Language: The primary language of the page MUST be identified accurately, using a Required
Language standard language code, on the <html> element (e.g. <html lang="en"> or <html WCAG 3.1.1
lang="fr">).
Language Language of Parts: Inline language changes MUST be identified with a valid lang Required
of Parts attribute. WCAG 3.1.2
Language Two-character language code: The language code SHOULD be designated with a Best practice
Code standard two-character ISO 639-1 code (e.g. lang="en") to achieve maximum support
across screen readers and browsers, though other codes (e.g. lang="en-us") are
technically allowable.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems Page 4
Headings
Topic Technique WCAG AA
Headings to Bypass Bypass blocks: Screen readers allow users to navigate by headings, so Required
Blocks of Content headings are an effective way to bypass blocks of content, as required by WCAG 2.4.1
WCAG 2.4.1. Note: Headings are not absolutely required by WCAG to pass
2.4.1, but are highly recommended, along with landmarks and skip links.
Meaningful Text Accurate, informative section labels: Headings MUST be accurate and Required
informative, as labels for the sections of text they describe. WCAG 1.3.1
WCAG 2.4.6
Brevity: Heading text SHOULD be concise and relatively brief. Best practice
Heading Markup Use real headings: Text that acts as a heading visually or structurally SHOULD Best practice
be designated as a true heading (<h1>, <h2>, etc.) in the markup.
Heading Markup for Headings Only: Text that does not act as a heading Best practice
visually or structurally SHOULD NOT be marked as a heading.
Outline/Hierarchy of Content outline: Headings SHOULD convey a clear and accurate structural Best practice
Content outline of the sections of content of a web page.
Consecutive levels: Headings SHOULD NOT skip hierarchical levels. Best practice
First heading in the main content: The beginning of the main content SHOULD Best practice
start with <h1>.
One <h1>: Most web pages SHOULD have only one <h1>. Best practice

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems Page 5
Landmarks
Topic Technique WCAG AA
Landmarks to Bypass blocks: Screen readers allow users to navigate by landmarks, so landmarks Required
Bypass Blocks of are an effective way to bypass blocks of content, as required by WCAG 2.4.1. WCAG 2.4.1
Content Other methods may be used as well as — or instead of — landmarks, such as skip
links, headings, expand/collapse regions, etc.
Landmark Page layout groupings: Landmarks SHOULD be used to accurately designate pre- Best practice
Structural defined parts of the layout (e.g. the header, navigation, main content, and
Organization footer).
Content within landmarks: All text SHOULD be contained within a landmark Best practice
region.
Landmark names: Multiple instances of the same type of landmark SHOULD be Best practice
distinguishable by different discernible names (using aria-label or aria-
labelledby).
Only one instance of some landmarks: A page SHOULD NOT contain more than Best practice
one instance of each of the following landmarks: header/banner, main, and
footer/contentinfo.
Limit the number of landmarks: The total number of landmarks SHOULD be Best practice
minimized to the extent appropriate for the content.
Note: Having a large number of landmarks defeats the main purpose of
landmarks, which is to make it easy to navigate quickly to sections of the layout.
Markup Markup: Landmarks MAY be designated with either HTML tags or their equivalent Best practice
ARIA roles (e.g. <header> or role="banner", <nav> or
role="navigation", <main> or role="main", <footer> or
role="contentinfo", etc.).

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems Page 6
Lists
Topic Technique WCAG AA
Markup List markup: Lists MUST be constructed using the appropriate semantic markup (i.e. <ul> or Required
<ol> with <li> child elements, or <dl> with <dt> and <dd> child elements). WCAG 1.3.1

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems Page 7
Tables
Topic Technique WCAG AA
Table Header tag: Table headers MUST be designated with <th>. Required
Headers WCAG 1.3.1
Meaningful header: Data table header text MUST accurately describe the category of the Required
corresponding data cells. WCAG 1.3.1
Header and data cell associations: Table data cells MUST be associated with their Required
corresponding header cells. WCAG 1.3.1
Note: Use of scope (<th scope="col"> and <th scope="row">) is highly
recommended, though not always necessary (i.e. if all cells in the first row are marked as
<th> without scope, most modern screen readers will infer that the scope is the column
below each header cell).
Group header associations: Table data group headers (if any) MUST be associated with their Required
corresponding data cell groups (e.g. via scope="rowgroup" or scope="colgroup"). WCAG 1.3.1
Complex header associations: Header/data associations that cannot be designated with Required
<th> and scope MUST be designated with the headers and id attributes. WCAG 1.3.1
Nested or split tables: Data table headers and data associations MUST NOT be referenced Required
across nested, merged, or separate tables. WCAG 1.3.1
Tabular Tables: Tabular data SHOULD be represented in a <table>. Best practice
Data Note: Even if the data are not represented in a table, WCAG 1.3.1 requires the data to be
associated with their labels.
Caption Caption: Data tables SHOULD have a programmatically-associated <caption> or name Best practice
(e.g. via aria-label or aria-labelledby).
Note: In most circumstances, <caption> is preferred, because it is the native method of
giving a name to a table, and the <caption> is visible and available to all users by default.
Meaningful caption: The name or <caption> of a data table SHOULD describe the identity Best practice
or purpose of the table accurately, meaningfully, and succinctly.
Unique caption: The name or <caption> of each data table SHOULD be unique within the Best practice
context of other tables on the same page.
Layout Avoid layout tables: Tables SHOULD NOT be used for the purpose of purely visual (non-data) Best practice
Tables layout.
Avoid headers in layout tables: Layout tables MUST NOT contain headers. Best practice

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems Page 8
Iframes
Topic Technique WCAG AA
iframe title attribute Meaningful iframe title attribute: The iframe title attribute (on the parent Required
page) MUST be accurate and descriptive. WCAG 2.4.1
Unique title attributes: Every iframe SHOULD have a unique title (in the context Best practice
of the page).
Hidden or empty iframes: Hidden frames or frames that do not convey content Best practice
to users SHOULD be hidden from assistive technologies using aria-
hidden="true".
Page <title> of Page title of embedded page: The source page of an iframe (the page Required
Embedded Page embedded in the iframe) MUST have a valid, meaningful <title>. WCAG 2.4.2

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems Page 9
Markup Validity
Topic Technique WCAG AA
Unique Identifiers Unique IDs: IDs MUST be unique within a web page. Required
WCAG 4.1.1
Unique Names: The "accessible names" of elements, when provided, of block level Best practice
elements (e.g. landmarks, tables, iframes, etc.) SHOULD be unique within a web
page.
Note: The accessible name is determined by attributes or elements such as aria-
label, aria-labelledby, alt, <caption>, etc. Refer to the Accessible Name
and Description Computation for details.
One Attribute Instance: Elements MUST NOT contain more than one instance of Required
the same attribute. WCAG 4.1.1
Well Formed Closing Tags: Elements must not be missing closing tags. Required
DIV or P element must not be nested within a LABEL element. WCAG 4.1.1
Element must not contain duplicate attributes.
Nesting and Parent-Child Relationships: Markup MUST adhere to required parent-child Required
Relationships relationships of elements and attributes. WCAG 4.1.1
ARIA relationships: ARIA relationships (e.g. parent-child, aria-owns, etc.) SHOULD Required
adhere to WAI-ARIA Authoring Practices WCAG 4.1.1
Deprecated Deprecated Markup should not be used. Best practice
Markup

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 10

Other Semantic Elements
Topic Technique WCAG AA
Headings See the requirements for headings. Required
(Multiple)
Landmarks See the requirements for landmarks. Required
(Multiple)
Lists See the requirements for lists. Required
(Multiple)
Tables See the requirements for tables. Required
(Multiple)
Links See the requirements for links. Required
(Multiple)
Emphasis and Emphasis: Critical emphasis in the text SHOULD be conveyed in a text- Best practice
Highlighting based format, not visual styling alone.
Highlighting markup: Highlighted text SHOULD be marked with the <mark> Best practice
element.
Text-based highlighting: Critical highlighted text SHOULD be supplemented Best practice
with a text-based method to convey the meaning of the highlighting.
Quotations Blockquote: The <blockquote> element SHOULD be used to designate long Best practice
(block level) quotations.
Indentation: The <blockquote> element SHOULD NOT be used for visual Best practice
styling (indentation) alone.
Inline quotations: The <q> element (for inline quotations) SHOULD NOT be Best practice
used as the only way to designate quotations, due to poor support in
screen readers and some browsers.
Strikethrough/Delete Strikethrough markup: Strikethrough text SHOULD be marked with the Best practice
and Insert <del> element.
Strikethrough supplemental text: Critical strikethrough text MUST be Best practice
supplemented with a text-based method to convey the meaning of the
strikethrough.
Insert markup: Text designated for insertion SHOULD be marked with the Best practice
<ins> element.
Insert supplemental text: Critical text designated for insertion MUST be Best practice
supplemented with a text-based method to convey the meaning of the
insertion.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 11

Section 2: Links and Navigation

Links
Topic Technique WCAG AA
Semantic Link markup: Links MUST be semantically designated as such. Required
Markup and Note: Ideally this means using an <a> element with a valid href value. In rare WCAG 4.1.2
Purpose problematic cases, setting role="link" (and adding all other aspects of
link functionality) may be acceptable.
Links versus buttons: Links SHOULD be used only for actions that take the Best practice
user to other locations and SHOULD NOT be used for button-like
functionality.
Note 1: "Other locations" means other web pages, or to other locations in
the same web page. Typically, the URL will change after activating a link.
Note 2: "Button-like functionality" means scripted features, including
submitting forms.
Link Text Discernible text: A link MUST have programmatically discernible text, as Required
determined by the accessible name calculation algorithm. WCAG 4.1.2
Distinguishable link purpose: The purpose of each link MUST be Required
understandable and distinguishable from other links on the same page, WCAG 2.4.4
either from the link text alone (ideally), or from the immediate surrounding
context of the link.
Avoid "link" (or similar) in the link text: The link text SHOULD NOT state its Best practice
semantic role (e.g. don't say "link to..."), because screen readers already
state the role before reading the link text.
Consistent link text across pages: Links to the same destinations MUST be Required
consistently identified with the same (or very similar) link text across all WCAG 3.2.4
pages of the site.
Links opening in new tab or window: A link that opens in a new window or Best practice
tab SHOULD indicate that it opens in a new window or tab.
Links to non-HTML files: A link to a file or destination in a non-HTML format Best practice
(e.g. MS Word, PDF, plain text, etc.) SHOULD indicate the type of file or
destination.
Links to external sites: A link to an external site MAY indicate that it leads to Best practice
an external site.
Keyboard Keyboard-focusable: Links MUST be keyboard-focusable. Required
Accessibility WCAG 2.1.1
Keyboard activation: Links MUST activate with the enter/return key. Required
WCAG 2.1.1
Focus Order Focus order: The navigation order of focusable elements (links, form Required
elements, etc.) MUST be logical and intuitive. WCAG 2.4.3

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 12

Topic Technique WCAG AA
Tabindex: The tabindex attribute SHOULD NOT be used with positive Best practice
values to customize the tab order (e.g. don't use tabindex="1").
Link Colors, Links visually distinguishable from non-links: Links MUST be visually Required
Contrast, and distinguishable from surrounding non-link text. WCAG 1.4.1
Styles
Color as a way to visually distinguish links: Color alone MUST NOT be used as Required
the only way to distinguish links from surrounding text unless the color WCAG 1.4.1
contrast between the link and the surrounding text is at least 3:1 and an
additional differentiation (e.g. underline, outline, etc.) is provided when the
link is hovered or receives focus.
Link contrast: Links MUST have a contrast ratio of 4.5:1 (for small text) or 3:1 Required
(for large text) against their background. WCAG 1.4.3
Target Size Target size: Links SHOULD measure a minimum of 44px by 44px. Best practice
Note: Inline links in paragraphs or blocks of text MAY be smaller.
Visual Focus Focus indicator: All links MUST show a visual focus indicator when in focus. Required
Indicator WCAG 2.4.7
Enhanced focus indicator: Links MAY have enhanced visual focus indicator Best practice
styles.
Small focus indicators: The contrast of all small visual focus indicators Best practice
(smaller than 3px by 3px) against the background SHOULD be at least 4.5 to
1.
Large focus indicators: The contrast of all large visual focus indicators (at Best practice
least 3px by 3px) against the background SHOULD be at least 3 to 1.
Visual Hover Enhanced hover indicator: Links SHOULD have enhanced visual hover Best practice
Indicator indicator styles.
Hover cursor style: On hover over a link, the mouse cursor SHOULD appear Best practice
as the pointer style, to provide a visual confirmation of the link role.
Note: On most browsers, the pointer style is represented by an icon of a
hand with the index finger pointing forward.
In-Page Skip navigation: A keyboard-functional "skip" link SHOULD be provided to Required
Navigation allow keyboard users to navigate directly to the main content. WCAG 2.4.1
Note 1: The "skip" link SHOULD be the first focusable element on the page. (This technique is
Note 2: The "skip" link MUST be either visible at all times or visible on one way to satisfy
keyboard focus. this requirement)
Note 3: "Skip" links, landmarks (e.g. <nav>, <main>, etc.), and page table of
contents are each valid and sufficient methods to satisfy the WCAG 2.4.1
requirement to allow users to bypass blocks of content. Ideally the design
would include all of these techniques, where appropriate.
Page table of contents: A table of contents for the page MAY be included at Required
the top of the content or in the header. WCAG 2.4.1
Note: Ideally, the links in the table of contents SHOULD correspond to the (This technique is
heading structure in the page content. one way to satisfy
this requirement)

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 13

Site Navigation
Topic Technique WCAG AA
Consistency Consistent Navigation Patterns: Navigation patterns that are repeated on web pages Required
MUST be presented in the same relative order each time they appear and MUST NOT WCAG 3.2.3
change order when navigating through the site.
Consistent Identification: Elements such as labels, names, and text alternatives for Required
content that have the same functionality across multiple screens must be consistently WCAG 3.2.4
identified.
Multiple Multiple ways: Multiple ways must be available to find other web pages on the site — Required
ways at least two of: a list of related pages, table of contents, site map, site search, or list of WCAG 2.4.5
all available web pages.
Navigation Markup: A navigation list SHOULD be designated with the <nav> element or Best practice
lists role="navigation". See also landmarks.
Visible "you are here" indicator: A navigation list SHOULD include a visible method of Best practice
informing users which page within the navigation list is the currently active/visible
page.
Non-visual "you are here" indicator: A navigation list SHOULD include a method Best practice
available to assistive technologies of informing non-visual users which page within the
navigation list is the currently active/visible page.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 14

Navigation within the Same Page
Topic Technique WCAG AA
Methods to Bypass Bypass blocks: A method MUST exist to bypass repeated blocks of content. Required
Blocks of Content Possible techniques applicable to almost all pages include skip links, headings, WCAG 2.4.1
and landmarks. It's best to use all of these techniques, if possible. Other
techniques include page-specific table of contents links and
expandable/collapsible regions.
Reading/Focus Reading Order: The reading and navigation order MUST be logical and intuitive. Required
Order WCAG 1.3.2
Focus Order: The navigation order of focusable elements MUST be logical and Required
intuitive. WCAG 2.4.3
Skip Links Provide a skip link: A keyboard-functional "skip" link SHOULD be provided to Best practice
allow keyboard users to navigate directly to the main content.
First focusable element: The "skip link" SHOULD be the first focusable element Best practice
on the page.
Skip link visibility: A skip link MUST be either visible at all times or visible on Best practice
keyboard focus.
Table of Contents Table of contents links: A table of contents for the page MAY be included at the Best practice
top of the content or in the header.
Reflect the heading structure: If a table of contents for the page is included, it Best practice
SHOULD reflect the heading structure of the page.
Paginated Views Visual "you are here" indicator: A paginated view SHOULD include a visible Best practice
method of informing users which view is the currently active/visible view.
Non-visual "you are here" indicator: A paginated view SHOULD include a method Best practice
available to assistive technologies of informing non-visual users which view is the
currently active/visible view.
Single-Key Single-key shortcuts: If a single-character-key shortcut exists, then at least one of Required
Shortcuts the following MUST be true: single-character-key shortcuts can be turned off, WCAG 2.1.4
remapped, or are only active when the relevant user interface component is in (WCAG 2.1)
focus.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 15

Reading Order and Focus Order
Topic Technique WCAG AA
Reading Reading Order: The reading order MUST be logical and intuitive. Required
Order Note: The default reading order is determined by the order of the elements in the DOM. WCAG 1.3.2
Focus Focus Order: The navigation order of focusable elements MUST be logical and intuitive. Required
Order Note 1: Focusable elements include links, form inputs and controls, buttons, and any WCAG 2.4.3
element with a tabindex value of 0 or greater.
Note 2: The default reading order is determined by the order of the focusable elements
in the DOM.
Note 3: Use the tab key to navigate forward through focusable elements, and shift + tab
to navigate backward.
Tabindex Positive values: A tabindex of positive values (e.g. tabindex="1", tabindex="2", Best practice
etc.) SHOULD NOT be used, because the result is almost always an illogical reading
and/or tab order.
Zero: Use tabindex="0" to make a custom widget or control focusable, if it is not Best practice
already focusable.
Note: Use natively focusable elements whenever possible (e.g. links, form inputs and
controls, buttons), rather than custom controls, for simplicity in markup and
implementation.
Negative 1: Use tabindex="-1" to allow JavaScript to send the focus to an element, Best practice
without putting it in the focus order.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 16

Section 3: Images and Visual Design

Images
Topic Technique WCAG AA
Informative Images Alternative text: The image MUST have alternative text. Refer to the Required
and Active Images (e.g. techniques for various image types: WCAG 1.1.1
links, buttons, or • images using <img>
controls) • active images
• form input images
• SVG using <img>
• SVG using <svg>
• HTML5 canvas
• icon fonts
Meaningful description: Alternative text MUST be meaningful (accurately Required
conveying the purpose of the image, and the author's intent in a way that is WCAG 1.1.1
useful to those who cannot see the image).
Note 1: Image links SHOULD describe the link destination.
Note 2: Button/control links SHOULD describe the purpose and/or resulting
action of the button or control.
Concise: The length of the alternative text for informative images SHOULD be Best practice
concise (no more than about 250 characters).
Avoid restating that the element is an image: Alternative text SHOULD NOT Best practice
include words that identify the element as a graphic or image (e.g. avoid
phrases like "graphic of," or "image of," etc.), because screen readers already
state the role (e.g. by saying "graphic" then reading the alternative text).
Unessential images Unessential Images: Images that do not convey content, are decorative, or Best practice
(Purely Decorative or are redundant to content that is already conveyed in text SHOULD be given
Redundant, and not null (empty) alternative text (alt=""), ARIA role="presentation", or
Active) implemented as CSS backgrounds.
Complex Images Complex Images: Complex images MUST be briefly described using alt text Required
AND MUST have a more complete extended description. WCAG 1.1.1
Note: It is not "wrong" to provide descriptive alternative text in these
instances, but it is highly discouraged if the image is truly unessential.
Background images Informative background images: If a background image conveys information, Required
alternative text MUST be provided (e.g. via regular visible text, by adding WCAG 1.1.1
role="image" and aria-label, or by other means).
Active background images: If a background image is the only "content" in an Required
active element (e.g. a link, button, or control), the active element MUST have WCAG 1.1.1
an accessible name (e.g. via aria-label or similar).
Color contrast of small text: Small text (under 18 point regular font or 14 Required
point bold font) MUST have a contrast ratio of at least 4.5 to 1 with the WCAG 1.4.3
background.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 17

Topic Technique WCAG AA
Color contrast of large text: Large text (at or over 18 point or 14 point bold) Required
MUST have a contrast ratio of at least 3 to 1 with the background. WCAG 1.4.3
Unessential background images: Alternative text SHOULD NOT be provided Best practice
for unessential background images.
Images of Text No Images of Text: An image MUST NOT include informative text if an Required
equivalent visual presentation of the text can be rendered using real text WCAG 1.4.5
(unless the text is essential — such as a logo — or the font, size, color, and
background are customizable.).
Color contrast of small text: Small text (under 18 point regular font or 14 Required
point bold font) MUST have a contrast ratio of at least 4.5 to 1 with the WCAG 1.4.3
background.
Color contrast of large text: Large text (at or over 18 point or 14 point bold) Required
MUST have a contrast ratio of at least 3 to 1 with the background. WCAG 1.4.3
Animated Images See the requirements for Animation, Motion, and Timed Content Required
(Multiple)
Image CAPTCHA Alternative text: Image CAPTCHA elements MUST have alternative text Required
describing the purpose of the image. WCAG 1.1.1
Sensory alternatives: Image CAPTCHA elements MUST be supplemented with Required
at least one auditory alternative method. WCAG 1.1.1
Deafblind access: At least one text-based alternative SHOULD be provided Best practice
that allows users who are both deaf and blind to pass the CAPTCHA.
Note: Deafblind users typically use screen readers to convert text to braille,
using a refreshable braille device.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 18

Color and Contrast
Topic Technique WCAG AA
Use of color Use of color: Any information conveyed by color MUST be accompanied by a Required
programmatically-discernible text alternative. WCAG 1.4.1
Visible Alternative: Any information conveyed by color MUST be accompanied by a Required
visible alternative (text, image, etc.) that does not depend on color for meaning. WCAG 1.4.1
Color Small Text Contrast: Small text (under 18 point regular font or 14 point bold font) Required
Contrast MUST have a contrast ratio of at least 4.5 to 1 with the background. WCAG 1.4.3
Note: The contrast rule also applies to images of text, even though images of text
are discouraged.
Large Text Contrast: Large text (at or over 18 point or 14 point bold) MUST have a Required
contrast ratio of at least 3 to 1 with the background. WCAG 1.4.3
Note: The contrast rule also applies to images of text, even though images of text
are discouraged.
UI Component Contrast: The contrast of UI control boundaries compared to Required
adjacent areas MUST be at least 3 to 1 to distinguish the UI control from the WCAG 1.4.11
adjacent areas. (WCAG 2.1)
Visual Focus Indicator Contrast: The contrast of all visual focus indicators against the Required
background MUST be at least 3 to 1. WCAG 1.4.11
(WCAG 2.1)
High Retain Visible Information: Web content SHOULD retain all essential visual Best practice
Contrast information in Windows High Contrast Mode.
Mode
Don't Override: The design SHOULD NOT override Windows High Contrast Mode. Best practice

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 19

Text Styles, Resize, Reflow, and Zoom
Topic Technique WCAG AA
Text Resize and Reflow Resize Text 200%: The page SHOULD be functional when only the text is Required
magnified to 200% of its initial size. WCAG 1.4.4
Mobile Zoom: The page MUST allow users to zoom in on mobile devices (The Required
following is NOT allowed: <meta name="viewport" content="user- WCAG 1.4.4
scalable=no">)
One Scroll Direction Only: Content MUST NOT require scrolling in two Required
directions (both vertically and horizontally) — even when the viewport is set WCAG 1.4.10
or zoomed to 320 CSS pixels wide (for vertically-scrolling content) or 256 CSS (WCAG 2.1)
pixels high (for horizontally-scrolling content) — unless both scrolling
directions are essential to the usage or meaning of the content.
Text in Images No Images of Text: An image MUST NOT include informative text if an Required
equivalent visual presentation of the text can be rendered using real text WCAG 1.4.5
(unless the text is essential — such as a logo — or the font, size, color, and
background are customizable.).
Color contrast of small text: Small text (under 18 point regular font or 14 Required
point bold font) MUST have a contrast ratio of at least 4.5 to 1 with the WCAG 1.4.3
background.
Color contrast of large text: Large text (at or over 18 point or 14 point bold) Required
MUST have a contrast ratio of at least 3 to 1 with the background. WCAG 1.4.3
Text/Paragraph Styles Full Functionality with Altered Text Styles: In content implemented using Required
markup languages that support the following text style properties, no loss of WCAG 1.4.12
content or functionality occurs by setting all of the following and by changing (WCAG 2.1)
no other style property:
• Line height (line spacing) to at least 1.5 times the font size
• Spacing following paragraphs to at least 2 times the font size
• Letter spacing (tracking) to at least 0.12 times the font size
• Word spacing to at least 0.16 times the font size.
Line Spacing: Line spacing SHOULD be at least 1.5 within paragraphs. Best practice
Paragraph Spacing: Paragraph spacing SHOULD be at least 1.5 times larger Best practice
than the line spacing.
Word Spacing: Word spacing SHOULD be set to at least 0.16 times the font Best practice
size.
Letter Spacing: Letter spacing SHOULD be set to at least 0.12 times the font Best practice
size.
Line Justification: Text SHOULD NOT be full justified. Best practice
Column Width: The number of characters or glyphs per line in any section or Best practice
column of text SHOULD NOT exceed 80 (40 characters in Chinese, Japanese,
or Korean)
Font Legibility: Fonts SHOULD be easily readable by sighted users. Best practice
Color Contrast See the requirements for Color and Contrast. Required
(Multiple)
Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 20
Topic Technique WCAG AA
CSS-Generated Avoid CSS-Generated Content: CSS-generated content SHOULD be avoided Best practice
Content (unless it is for presentation/decorative purposes only).
Text Alternative for CSS-Generated Content: A text alternative for Required
informative CSS-generated content MUST be provided, AND the CSS- WCAG 1.3.1
generated text SHOULD be set to aria-hidden="true"
Decorative CSS-Generated Content: Decorative or redundant CSS-generated Best practice
content SHOULD be set to aria-hidden="true"
Emphasis and Emphasis: Critical emphasis in the text SHOULD be conveyed in a text-based Best practice
Highlighting format, not visual styling alone.
Highlighting markup: Highlighted text SHOULD be marked with the <mark> Best practice
element.
Text-based highlighting: Critical highlighted text SHOULD be supplemented Best practice
with a text-based method to convey the meaning of the highlighting.
Quotations Blockquote: The <blockquote> element SHOULD be used to designate long Best practice
(block level) quotations.
Indentation: The <blockquote> element SHOULD NOT be used for visual Best practice
styling (indentation) alone.
Inline quotations: The <q> element (for inline quotations) SHOULD NOT be Best practice
used as the only way to designate quotations, due to poor support in screen
readers and some browsers.
Strikethrough/Delete Strikethrough markup: Strikethrough text SHOULD be marked with the Best practice
and Insert <del> element.
Strikethrough supplemental text: Critical strikethrough text MUST be Best practice
supplemented with a text-based method to convey the meaning of the
strikethrough.
Insert markup: Text designated for insertion SHOULD be marked with the Best practice
<ins> element.
Insert supplemental text: Critical text designated for insertion MUST be Best practice
supplemented with a text-based method to convey the meaning of the
insertion.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 21

Visual Cues
Topic Technique WCAG AA
Visual Visual Meaning: Content MUST NOT rely solely on visual characteristics such as Required
Meaning shape, size, visual location, or orientation to convey meaning. WCAG 1.3.3
Color See the requirements for color and contrast. Required
(Multiple)
Visual Layout Visual Separation of Content Blocks: Blocks of content SHOULD be visually separated Best practice
and distinct from each other, via margins, padding, or other methods of achieving
visual "white space."
Label Proximity: Labels SHOULD be visually adjacent to their controls. Best practice
One Visual Focal Point: The layout SHOULD have only one main visual focal point. Best practice
Draw Attention: The design SHOULD draw attention to the intended visual focus Best practice
point.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 22

Responsive and Adaptive Design
Topic Technique WCAG AA
Device Orientation Horizontal or Vertical Orientation: Content MUST NOT restrict its view and Required
operation to a single display orientation, such as portrait or landscape, unless a WCAG 1.3.4
specific display orientation is essential. (WCAG 2.1)
Adaptive/ See the requirements for Text Styles, Resize, Reflow, and Zoom Required
Responsive Text (Multiple)
Other Adaptive/ Content that would cause scrolling in two directions (both horizontally and Required
Responsive vertically) MUST respond to the viewport size or zoom state by resizing and/or WCAG 1.4.10
Elements reflowing, at viewport resolutions of up to 320px for vertically-scrolling (WCAG 2.1)
content, and 256px for horizontally-scrolling content.
• Images
• Forms
• Tables
• Objects and Plugins
• UI Components
• Video
Simplification Simplified Content: Features of the content MAY be simplified, reduced in size, Best practice
or eliminated when magnified or when viewed on small viewports.
Simplified User Interface: Features of the interface SHOULD be simplified, Best practice
reduced in size, or eliminated when magnified or when viewed on small
viewports.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 23

Section 4: Multimedia, Animations, and Motion

Audio and Video

Topic Technique WCAG AA
Prerecorded Audio- Captions: Prerecorded video-only content MUST have synchronized captions. Required
Only WCAG 1.2.2
Transcript: All prerecorded audio MUST have a transcript of dialog, narration, Required
and other meaningful sounds. WCAG 1.2.1
Autoplay: A method MUST be provided to pause, stop, or hide any media Required
content that begins playing automatically and which lasts 5 seconds or more. WCAG 2.2.2
Audio Control: A mechanism MUST be provided to stop, pause, mute, or adjust Required
volume for audio that automatically plays on a page for more than 3 seconds. WCAG 1.4.2
Sign Language: Prerecorded audio-only content MAY include sign language Best practice
interpretation.
Background Sounds: Background sounds in prerecorded audio-only content Best practice
SHOULD be minimized (20dB lower than foreground sounds, except for
occasional sounds of no more than 2 seconds) or eliminated during narration
or dialog, or a method must be available to turn off background sounds.
Prerecorded Video- Alternative Text: Prerecorded video-only MUST include a text description. Required
Only (and video-like WCAG 1.2.1
animations)
Captions: Prerecorded video-only content MUST have synchronized captions. Required
WCAG 1.2.2
Audio Description: Prerecorded video-only content MUST include an audio Required
description (narrated video description) of important visual content. WCAG 1.2.5
Autoplay: A method MUST be provided to pause, stop, or hide any media Required
content that begins playing automatically and which lasts 5 seconds or more. WCAG 2.2.2
Flashing Content: A page MUST NOT contain content that flashes more than 3 Required
times per second unless that flashing content is sufficiently small, the flashes WCAG 2.3.1
are of low contrast, and do not violate general flash thresholds.
Prerecorded Alternative Text: Prerecorded video-only MUST include a text description of Required
Multimedia important visual content that is not conveyed through the audio (this can be WCAG 1.2.1
included in the transcript).
Transcript: Prerecorded video-only MUST have a text transcript of dialog, Required
narration, and other meaningful sounds. WCAG 1.2.1
Captions: Prerecorded video-only content MUST have synchronized captions. Required
WCAG 1.2.2
Audio Description: Prerecorded video-only content MUST include an audio Required
description (narrated video description) of important visual content. WCAG 1.2.5
Autoplay: A method MUST be provided to pause, stop, or hide any media Required
content that begins playing automatically and which lasts 5 seconds or more. WCAG 2.2.2
Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 24
Topic Technique WCAG AA
Audio Control: A mechanism MUST be provided to stop, pause, mute, or adjust Required
volume for audio that automatically plays on a page for more than 3 seconds. WCAG 1.4.2
Flashing Content: A page MUST NOT contain content that flashes more than 3 Required
times per second unless that flashing content is sufficiently small, the flashes WCAG 2.3.1
are of low contrast, and do not violate general flash thresholds.
Sign Language: Prerecorded video-only content MAY include sign language Best practice
interpretation.
Background Sounds: Background sounds in prerecorded audio-only and Best practice
prerecorded multimedia content SHOULD be minimized (20dB lower than
foreground sounds, except for occasional sounds of no more than 2 seconds)
or eliminated during narration or dialog, or a method must be available to turn
off background sounds.
Live Audio-Only Audio Control: A mechanism MUST be provided to stop, pause, mute, or adjust Required
volume for audio that automatically plays on a page for more than 3 seconds. WCAG 1.4.2
Autoplay: A method MUST be provided to pause, stop, or hide any media Required
content that begins playing automatically and which lasts 5 seconds or more. WCAG 2.2.2
Background Sounds: Background sounds in live audio-only content SHOULD be Best practice
minimized (20dB lower than foreground sounds, except for occasional sounds
of no more than 2 seconds) or eliminated during narration or dialog, or a
method must be available to turn off background sounds.
Captions: Live audio-only content SHOULD have synchronized captions. Best practice
Live Video-Only Captions: Live video-only content MUST have synchronized captions. Required
WCAG 1.2.4
Autoplay: A method MUST be provided to pause, stop, or hide any media Required
content that begins playing automatically and which lasts 5 seconds or more. WCAG 2.2.2
Flashing Content: Live video-only content MUST NOT contain content that Required
flashes more than 3 times per second unless that flashing content is sufficiently WCAG 2.3.1
small, the flashes are of low contrast, and do not violate general flash
thresholds.
Alternative Text: Live video-only MUST include a text description. Required
WCAG 1.2.1
Audio Description: Live video-only content SHOULD include an audio Best practice
description (narrated video description) of important visual content.
Live Multimedia Captions: Live multimedia content MUST have synchronized captions. Required
WCAG 1.2.4
Audio Control: A mechanism MUST be provided to stop, pause, mute, or adjust Required
volume for audio that automatically plays on a page for more than 3 seconds. WCAG 1.4.2
Autoplay: A method MUST be provided to pause, stop, or hide any media Required
content that begins playing automatically and which lasts 5 seconds or more. WCAG 2.2.2

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 25

Topic Technique WCAG AA
Background Sounds: Background sounds in live multimedia content SHOULD be Best practice
minimized (20dB lower than foreground sounds, except for occasional sounds
of no more than 2 seconds) or eliminated during narration or dialog, or a
method must be available to turn off background sounds.
Flashing Content: A page MUST NOT contain content that flashes more than 3 Required
times per second unless that flashing content is sufficiently small, the flashes WCAG 2.3.1
are of low contrast, and do not violate general flash thresholds.
Audio Description: Live multimedia content SHOULD include an audio Best practice
description (narrated video description) of important visual content.
Page Background Audio Control: A mechanism MUST be provided to stop, pause, mute, or adjust Required
Sounds volume for audio that automatically plays on a page for more than 3 seconds. WCAG 1.4.2
Autoplay: A method MUST be provided to pause, stop, or hide any media Required
content that begins playing automatically and which lasts 5 seconds or more. WCAG 2.2.2
If Informative: If the background sounds contain informative content, all of the Depends
requirements for prerecorded audio-only content apply (see above).
Page Background Autoplay: A method MUST be provided to pause, stop, or hide any media Required
Video content that begins playing automatically and which lasts 5 seconds or more. WCAG 2.2.2
Flashing Content: A page MUST NOT contain content that flashes more than 3 Required
times per second unless that flashing content is sufficiently small, the flashes WCAG 2.3.1
are of low contrast, and do not violate general flash thresholds.
See the requirements for color contrast (for text and UI elements overlayed on Required
top of video). WCAG 1.4.3
If Informative: If the background video contains informative content, all of the Depends
requirements for prerecorded video-only content apply (see above).
Media Players Media players themselves MUST be fully accessible (in particular to keyboard Required
users and screen reader users). See the requirements for: (Multiple)
• Media player keyboard accessibility
• Media player screen reader accessibility
• Captions, transcripts, audio descriptions within the media player
• User customization options within the media player
See also the requirements for Form Inputs, Labels, and Instructions
See also the requirements for Custom JavaScript/ARIA Components

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 26

Animation, Motion, and Timed Content
Topic Technique WCAG AA
Audio and Video See the audio and video requirements. Required
(Multiple)
Flashing Flashing: A page MUST NOT contain content that flashes more than Required
3 times per second unless that flashing content is sufficiently small, WCAG 2.3.1
the flashes are of low contrast, and do not violate general flash
thresholds.
Parallax Effects (backgrounds or Keyboard-Accessible: All content and features within parallax Required
foregrounds that move scrolling content MUST be accessible by keyboard. WCAG 2.1.1
separately from each other)
Text Color Contrast: The contrast of the text against all parts of a Required
moving background MUST be a minimum of 4.5 to 1 for small text WCAG 1.4.3
or 3 to 1 for large or bold text.
UI Component Color Contrast: The contrast of UI control Required
boundaries compared to adjacent areas SHOULD be 3 to 1 to WCAG 1.4.11
distinguish the UI control from the adjacent areas. (WCAG 2.1)
User Control of Timing Autoplay: A method MUST be provided to pause, stop, or hide any Required
media content that begins playing automatically and which lasts 5 WCAG 2.2.2
seconds or more.
Time Limits: A method MUST be provided to allow users to control Required
time limits by turning them off, adjusting them, or extending them WCAG 2.2.1
(unless the timing is essential or if the time limit is longer than 20
hours).
Replay Option: A method SHOULD be provided to allow users to Best practice
replay timed content that is finished or expired (unless replaying
the content fundamentally alters its purpose or meaning).

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 27

Section 5: User Input, Forms, and Dynamic Content

Device-Independent User Input (Keyboard, Mouse, Touch, Voice, etc.)

Topic Technique WCAG AA
Keyboard Focusable with Tab Key: Links, buttons, and interactive controls MUST be Required
keyboard-focusable. WCAG 2.1.1
Logical Tab Order: The navigation order of focusable elements MUST be Required
logical and intuitive. WCAG 2.4.3
No Positive tabindex Values: tabindex of positive values SHOULD NOT be Best practice
used.
Visual Focus Indicator: All focusable elements MUST have a visual focus Required
indicator when in focus. WCAG 2.4.7
Enhanced Visual Focus Indicator: Focusable elements SHOULD have Best practice
enhanced visual focus indicator styles.
Color Contrast of Visual Focus Indicator: The contrast of all large visual focus Required
indicators (at least 3px by 3px) against the background) SHOULD be at least 3 WCAG 1.4.11
to 1. (WCAG 2.1)
Keyboard Functionality: Functionality MUST be available using the keyboard, Required
unless the functionality cannot be accomplished in any known way using a WCAG 2.1.1
keyboard.
Keyboard Traps: Keyboard focus MUST NOT be locked or trapped in a Required
particular page element and the user MUST be able to navigate to and from WCAG 2.1.2
all navigable page elements using only a keyboard.
Keyboard Shortcuts: Page-specified shortcut keys and accesskeys MUST NOT Required
conflict with existing keyboard shortcuts in the browser, operating system, or WCAG 2.1.4
assistive technologies. (WCAG 2.1)
Custom Keystroke Instructions: When custom keyboard behavior is required Required
to use a component, keyboard instructions MUST be provided. WCAG 3.3.2
ARIA Widget Instructions: ARIA widgets that require more than just the Tab Best practice
key to interact with may be confusing to users (even when the widgets follow
the WAI-ARIA Authoring Practices), so you MAY provide keyboard
instructions.
Keyboard Focus Set Keyboard Focus: The focus MUST be purposely moved or set (via Required
Management During JavaScript) onto the appropriate element when the user's action requires a WCAG 2.4.3
Interactions change of context or location for effective keyboard or touch interaction.
No Lost Focus: The focus MUST NOT become lost or reset to the top of the Required
page, except when loading or re-loading a page. WCAG 2.4.3
Focus Target Has Text: When moving or setting focus, the destination Required
element MUST contain discernible text (either standard text or WCAG 1.3.1
programmatically-associated text).

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 28

Topic Technique WCAG AA
Mouse Click Target Size: The click target size SHOULD be at least 44 by 44 CSS pixels. Best practice
Note: Allowed exceptions include the following circumstances:
• The target is available through an equivalent control of at least 44 by
44 CSS pixels
• The target is inline (in a sentence or block of text)
• The target size is user-customizable
• The smaller target size is essential to the information or functionality
Visual Hover Indicator: An enhanced visual hover indicator SHOULD be Best practice
provided.
Pointer Cancellation: For functionality that can be operated using a single- Required
pointer, at least one of the following MUST be true: no down-event, can WCAG 2.5.2
abort/undo, up reversal, or essential. (WCAG 2.1)
Voice Visual Labels Match Programmatic Labels: The visual labels for links, buttons, Required
form elements, and other controls SHOULD match the programmatic labels WCAG 2.5.3
(to allow easy and intuitive voice commands). (WCAG 2.1)
All the keyboard requirements above apply. Required
(Multiple)
Touch Touch Functionality: Functionality MUST be available using standard touch Required
methods, unless the functionality cannot be accomplished in any known way WCAG 2.5.1
using a touch device. (WCAG 2.1)
Touch Functionality with Screen Reader Enabled: Functionality MUST be Required
available using screen reader touch methods (e.g. single tap or double tap WCAG 2.5.1
actions), unless the functionality cannot be accomplished in any known way (WCAG 2.1)
using a touch device.
Note: The touch actions with the screen reader turned on are completely
different from the touch actions when the screen reader is turned off.
Single pointer: Functionality MUST work with a single pointer (e.g. a single Required
finger), unless multipoint activation is essential. WCAG 2.5.1
(WCAG 2.1)
Touch cancellation: Touch events MUST NOT be activated on a down event Required
(use up events instead), to allow users to cancel, abort, or undo touch events, WCAG 2.5.2
unless the down event is essential. (WCAG 2.1)
Gesture-Only Functionality: Features MUST NOT depend on swipe or gesture Required
motions as the only activation method. WCAG 2.5.1
(WCAG 2.1)
Motion Actuation: Features MUST NOT depend on kinetic motion of the Required
device (e.g. shake, raise, lower, tilt). WCAG 2.5.4
(WCAG 2.1)
Focus Trap: Touch/gesture focus MUST NOT be locked or trapped in a Required
particular page element and the user MUST be able to navigate to and from WCAG 2.1.2
all navigable page elements using standard touch actions.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 29

Topic Technique WCAG AA
Touch Target Size: The click/touch target size SHOULD be at least 44x44 CSS Best practice
pixels, unless at least one of the following is true:
• There is an equivalent control on the same page that is at least 44x44
CSS pixels, OR
• The target is inline (in a sentence or block of text), OR
• The user agent controls the target size, OR
• The smaller size of the target is essential to the information being
conveyed.
Pointer Gestures: All functionality that uses multipoint or path-based Required
gestures for operation MUST be operable with a single pointer without a WCAG 2.5.1
path-based gesture, unless a multipoint or path-based gesture is essential.
Motion Actuation Motion Actuation: Functionality that can be operated by device or user Required
motion MUST also be operable by user interface components and MUST WCAG 2.5.4
allow the ability to disable motion actuation. (WCAG 2.1)

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 30

Form Inputs, Labels, and Instructions
Topic Technique WCAG AA
Labels for Inputs Programmatic Labels: Labels MUST be programmatically associated with Required
their corresponding elements. WCAG 1.3.1
Discernible Label Text: Labels MUST be available as programmatically Required
discernible text. WCAG 1.3.1
Meaningful Labels: Labels MUST be meaningful. Required
WCAG 1.3.1
Sensory Dependencies of Labels: Labels MUST NOT rely solely on references Required
to sensory characteristics. WCAG 1.3.3
Icons as Labels: Icons/graphics MAY be used as the only visual label Required
(without visual text) only if the meaning of the icon is visually self-evident WCAG 1.3.1
AND if there is a programmatically associated semantic label available to
assistive technologies.
Placeholder Text: Placeholder text is allowed but MUST NOT be used as the Required
only method of providing a label for a text input. WCAG 1.3.1
Visible Labels: Labels MUST be visible. Required
WCAG 3.3.2
Label in Name: For user interface components with labels that include text Required
or images of text, the name MUST contain the text that is presented WCAG 2.5.3
visually. (WCAG 2.1)
Matching Programmatic Label and Visual Label: The programmatic label Required
MUST include the same text presented in the visual label, to facilitate voice WCAG 2.5.3
activation. (WCAG 2.1)
Multiple Labels for One Input: When multiple labels are used for one Required
element, each label MUST be programmatically associated with the WCAG 1.3.1
corresponding element.
One Label for Multiple Inputs: When one label is used for multiple Required
elements, the label MUST be programmatically associated with each of the WCAG 1.3.1
corresponding elements.
Visually Adjacent Labels: A label SHOULD be visually adjacent to its Best practice
corresponding element.
Programmatically Adjacent Labels: A label SHOULD be adjacent in the DOM Best practice
to its corresponding element.
Labels for Groups of Programmatic Group Labels: Group labels MUST be programmatically Required
Inputs associated with the group if the individual labels for each element in the WCAG 1.3.1
group are insufficient on their own (e.g. a group of radio buttons that has a
group label plus individual labels for each radio option).
Discernible Text in Group Labels: Group labels MUST contain Required
programmatically discernible text. WCAG 1.3.1
Meaningful Group Labels: Group labels MUST be meaningful. Required
WCAG 1.3.1

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 31

Topic Technique WCAG AA
Sensory Dependencies of Group Labels: Group labels MUST NOT rely solely Required
on references to sensory characteristics. WCAG 1.3.3
Visible Group Labels: Group labels MUST be visible. Required
WCAG 3.3.2
Matching Programmatic Label and Visual Label: The programmatic label Required
MUST include the same text presented in the visual label, to facilitate voice WCAG 2.5.3
activation. (WCAG 2.1)
Visually Adjacent Group Labels: Group labels SHOULD be visually adjacent Best practice
to the grouped elements.
Programmatically Adjacent Group Labels: Group labels SHOULD be adjacent Best practice
in the DOM to the grouped elements.
Identify Input Purpose Identify Input Purpose: The purpose for each common input field that Required
collects an individual's personal data MUST be programmatically defined WCAG 1.3.5
based on the list of 53 Input Purposes for User Interface Components. (WCAG 2.1)
Instructions About Programmatic Association of Input Instructions: Instructions for an element Required
Inputs MUST be programmatically-associated with the element. WCAG 3.3.2
Programmatically-Discernible Text in Input Instructions: Instructions for an Required
element MUST be available as programmatically-discernible text. WCAG 3.3.2
Meaningful Input Instructions: Instructions for an element MUST be Required
meaningful. WCAG 3.3.2
Visible Input Instructions: Instructions for an element MUST be visible. Required
WCAG 3.3.2
Sensory Dependencies of Input Instructions: Instructions for an element Required
MUST NOT rely solely on references to sensory characteristics. WCAG 1.3.3
Hidden Input Instructions: If the instructions for an element are not critical, Best practice
the instructions MAY be hidden until the user requests them.
Visually Adjacent Input Instructions: Instructions for an element SHOULD be Best practice
visually adjacent to the element.
Programmatically Adjacent Input Instructions: Instructions for an element Best practice
SHOULD be adjacent in the DOM to the element.
Instructions About an Programmatic Association of Group Instructions: Instructions for groups or Required
Entire Form, a Group, or sections SHOULD be programmatically-associated with the group. WCAG 3.3.2
a Section
Programmatically-Discernible Text in Group Instructions: Instructions for Required
groups or sections MUST be programmatically-discernible. WCAG 3.3.2
Meaningful Group Instructions: Instructions for groups or sections MUST be Required
meaningful. WCAG 3.3.2
Visible Group Instructions: Instructions for groups or sections MUST be Required
visible. WCAG 3.3.2
Sensory Dependencies of Group Instructions: Instructions for groups or Required
sections MUST NOT rely solely on references to sensory characteristics. WCAG 1.3.3

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 32

Topic Technique WCAG AA
Hidden Form Instructions: If the instructions are not critical to understand Best practice
the purpose of a group or section, the instructions MAY be hidden until the
user requests them.
Visually Adjacent Group Instructions: Instructions for groups or sections Best practice
SHOULD be visually adjacent to the grouped elements.
Programmatically-Adjacent Group Instructions: Instructions for groups or Best practice
sections SHOULD be adjacent in the DOM to the grouped elements.
Required Fields Programmatic Designation: Required fields SHOULD be programmatically Best practice
designated as such.
Note: At a minimum, WCAG requires an informative error message about
the field after the user submits the form.
Visual Indicator: Required fields SHOULD have a visual indicator that the Best practice
field is required.
Data Input Restrictions Information About Data Input Restrictions: If a field allows only restricted Best practice
input (e.g. a certain date format, only integers, no more than 4 characters,
etc.), the restrictions SHOULD be communicated in the label or instructions.
Note: At a minimum, WCAG requires an informative error message about
the field after the user submits the form.
Disabled Fields Awareness of disabled fields: If awareness of a disabled field is essential to Required
understanding the content, an alternative way of communicating WCAG 1.3.1
information about the disabled field MUST be provided (because disabled
fields are not in the normal tab order by default, making it difficult for
screen reader users to discover them).
Time Limits Sufficient Time. Users MUST be allowed sufficient time to complete the Required
form, through at least one of the following methods: WCAG 2.2.1
• No time limit
• The ability to turn off the time limit
• The ability to extend the time limit
• The ability to adjust/customize time limit
• A minimum of 20 hours to complete the form
• Note: This requirement can be waived if the time limit is essential
to the meaning or purpose of the form (e.g. a timed auction).
Dynamic Forms See the requirements for Dynamic Content (JavaScript, Single-page Apps, Required
etc.) (Multiple)
Custom Form Inputs See the requirements for Custom JavaScript/ARIA Components) Required
(JavaScript/ARIA) (Multiple)

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 33

Form Validation and Feedback
Topic Technique WCAG AA
Labels and See the requirements and recommendations for Form Inputs, Labels, and Required
Instructions for Instructions, including: (Multiple)
Error Prevention • Labels for inputs
• Labels for groups of inputs
• Instructions about inputs
• Instructions about an entire form, a group, or a section
• Required fields (in the full list of recommendations)
• Data input restrictions (in the full list of recommendations)
• Disabled fields
• Time limits
Context-Sensitive Help: Context-sensitive help SHOULD be available. Best practice
Critical Error Web pages that process user input for any of the following: Required
Prevention • legal commitments, WCAG 3.3.4
• financial transactions,
• user-controllable data (e.g. user profile, social media posts, OR
• test/quiz responses
• MUST implement at least one of the following error prevention
techniques:
• Reversible: Submissions are reversible.
• Checked: Data entered by the user is checked for input errors and the
user is provided an opportunity to correct them.
• Confirmed: A mechanism is available for reviewing, confirming, and
correcting information before finalizing the submission.
Error Prevention (All All web pages that process user input SHOULD implement at least one of the Best practice
Circumstances) following error prevention techniques:
• Reversible: Submissions are reversible.
• Checked: Data entered by the user is checked for input errors and the
user is provided an opportunity to correct them.
• Confirmed: A mechanism is available for reviewing, confirming, and
correcting information before finalizing the submission.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 34

Topic Technique WCAG AA
Error Detection on Error Identification: If an error is automatically detected, the input with the Required
Submit error MUST be identified. Valid techniques include the following: WCAG 3.3.1
Add aria-invalid="true" to the input
Identify the input (referencing the label):
• in a simple JavaScript alert
• with information associated with the input via aria-describedby
(widely supported) or aria-errormessage (not yet widely
supported)
• with error text added to the input's label (other techniques are more
semantically correct, but this is a reliable method)
• with text on the web page (it may be appropriate to move the keyboard
focus to the error message)
• with an aria-live or role="alert" announcement
• with information about the error in the page <title> if the
submission causes a page reload or a new page load.
Dynamic Error Visible Real-Time Error Messages: Real-time error messages MAY be scripted to Best practice
Detection show on the screen for sighted users, but attempts to announce the real-time
messages to screen reader users can be problematic (see the next two rows
below). It is usually acceptable to wait to announce real-time errors until after
form submission, assuming that no data has been saved yet.
Live Announcements per Keystroke: ARIA live error messages SHOULD NOT be Best practice
scripted to occur with every keystroke (to avoid overwhelming screen reader
users), unless there is a delay built into the script to avoid announcements
while the user is actively typing.
Live Announcements on Leaving a Field: ARIA live error messages SHOULD NOT Best practice
be scripted to occur when a user leaves a field, because the aria-live
announcement will may conflict with the screen reader's attempt to read the
next element which receives focus, causing some information to be interrupted
or not announced at all.
Error Message Error Suggestion: If an input error is automatically detected, the item that is in Required
Characteristics error is identified and the error is described to the user in text. WCAG 3.3.3
Programmatically-Associated: Error feedback SHOULD be programmatically- Best practice
associated with the appropriate element.
Meaningful Error Message: Error feedback MUST clearly and accurately Best practice
describe the error and/or how to fix the error.
Visible Error Message: Error feedback MUST be visible. Required
WCAG 3.3.3
Success Messages Success Confirmation: The web page SHOULD confirm successful submission of Best practice
data. Possible techniques include the following:
• a simple JavaScript alert
• with confirmation text on the web page (it may be appropriate to move
the keyboard focus to the error message)
• with an aria-live or role="alert" announcement
• with the confirmation message in the page <title> if the submission
causes a page reload or a new page load.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 35

Dynamic Content (JavaScript, Single-Page Apps, etc.)
Topic Technique WCAG AA
Context Changes Context Changes on Focus: The focus MUST be purposely moved or set (via Required
JavaScript) onto the appropriate element when the user's action requires a WCAG 3.2.2
change of context or location for effective keyboard or touch interaction.
Finding Added Finding Added Content: Silence is bad. When screen reader users activate a Required
Content feature (link, button, control, etc.), or when an important part of the content WCAG 1.3.2
changes, they need to hear feedback. One of the basic challenges with dynamic
content is to figure out the best way to tell screen reader users about the
dynamic changes.
Keyboard Focus Set Keyboard Focus: The focus MUST be purposely moved or set (via JavaScript) Required
Management During onto the appropriate element when the user's action requires a change of WCAG 2.4.3
Interactions context or location for effective keyboard or touch interaction.
No Lost Focus: The focus MUST NOT become lost or reset to the top of the page, Required
except when loading or re-loading a page. WCAG 2.4.3
Focus Target Has Text: When moving or setting focus, the destination element Required
MUST contain discernible text (either standard text or programmatically- WCAG 1.3.1
associated text).
Timers Session Timeout – Timing Adjustable: If there is a session time limit, users MUST Required
be warned before the session ends and MUST be given time to save their data WCAG 2.2.1
and/or extend the session.
User Input and Input: See the requirements for Form Inputs, Labels, and Instructions
Feedback
Feedback: See the requirements for Form Validation and Feedback
User Input Methods See the requirements for Device-Independent User Input regarding: Required
• Mouse (Multiple)
• Keyboard
• Touch
• Voice

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 36

Custom JavaScript/ARIA Components
Topic Technique WCAG AA
Name Name of Interactive UI Elements: Every interactive UI element (e.g. links, Required
buttons, controls for custom widgets, form inputs/elements) MUST have a WCAG 4.1.2
name, according to the accessible name computation.
Note: The name can come from the native text of the element (e.g. link text,
<button> text), a value attribute (e.g. <input type="submit"
value="Name goes here">), the aria-label text, the text referred to via
the aria-labelledby ID value, or other attributes, such as title (depending
on context).
Name of Static Semantic Elements: The following semantic elements MUST have Required
an accessible name, according to the accessible name computation: WCAG 4.1.2
• Headings (or elements with role="heading")
• Images (or elements with role="image")
• Links (or elements with role="link"), via link text, aria-label (e.g.
when the link contains only a background image), or aria-
labelledby)
• Frames, via the title attribute
• Iframes, via the title attribute
Other Semantic Elements Benefitting from a Name: Examples of other semantic Best practice
elements that SHOULD have an accessible name, according to the accessible
name computation include:
• Landmarks (HTML 5 or ARIA landmarks); Names are especially helpful
when there are two of the same type of landmark on the same page,
such as two navigation landmarks
• Tables (via <caption>, aria-label, or aria-labelledby)
Role Role Specified: The semantic meaning of elements MUST be communicated via Required
appropriate native HTML element or ARIA role. WCAG 4.1.2
HTML versus ARIA Role: When an HTML element exists, the HTML element Best practice
SHOULD be used instead of the equivalent ARIA role, whenever possible.
Value Static ARIA Properties: Static ARIA properties (e.g. aria-valuemax), MUST be Required
specified. WCAG 4.1.2
Static Non-ARIA Properties: Static non-ARIA properties MUST be specified in text Required
(or alternative text). WCAG 4.1.2
Note: The static property may be included in the native text of an element, in its
label, in associated text (e.g. via aria-describedby), in adjacent text, or in
some other way that is available to assistive technologies.
Initial State: The initial state of a changeable UI element MUST be Required
programmatically designated (e.g. via ARIA attributes such as aria- WCAG 4.1.2
expanded="false", aria-selected="true", aria-sort="ascending",
etc.)

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 37

Topic Technique WCAG AA
ARIA State Changes: When the visual and/or functional state of an element Required
changes (e.g. aria-valuenow, aria-pressed, aria-expanded, aria- WCAG 4.1.2
checked), the ARIA state MUST be change accordingly. (WCAG 2.0)
WCAG 4.1.3
(WCAG 2.1)
Non-ARIA State Changes: If a state change cannot be communicated via a Required
change in an ARIA attribute, when the state change is the result of a user action WCAG 4.1.2
or request, the state change MUST be communicated to the user visually AND (WCAG 2.0)
MUST be communicated to assistive technologies using a technique such as: WCAG 4.1.3
• aria-live announcement (WCAG 2.1)
• ARIA alert (inject text into a pre-existing container with role="alert")
• Move keyboard focus to the announcement (warning: moving the focus
can be disorienting, so should be used with caution)
Keyboard Focus Set Keyboard Focus: The focus MUST be purposely moved or set (via JavaScript) Required
Management onto the appropriate element when the user's action requires a change of WCAG 2.4.3
During Interactions context or location for effective keyboard or touch interaction.
No Lost Focus: The focus MUST NOT become lost or reset to the top of the Required
page, except when loading or re-loading a page. WCAG 2.4.3
Focus Target Has Text: When moving or setting focus, the destination element Required
MUST contain discernible text (either standard text or programmatically- WCAG 1.3.1
associated text).
Keyboard See https://www.w3.org/TR/wai-aria-practices-1.1/#keyboard Best practice
Conventions
Instructions Instructions for Custom Widgets: Widgets with non-standard interaction models Best practice
SHOULD have instructions explaining how to use them.
See also the requirements for Form Inputs, Labels, and Instructions. Required
(Multiple)
Custom Widgets Accordion widgets SHOULD conform to WAI-ARIA Authoring Practices for Best practice
Accordions.
Alert widgets SHOULD conform to WAI-ARIA Authoring Practices for Alerts. Best practice
Alert Dialog widgets SHOULD conform to WAI-ARIA Authoring Practices for Alert Best practice
Dialogs.
Autocomplete widgets SHOULD conform to WAI-ARIA Authoring Practices for Best practice
Autocomplete widgets.
Breadcrumb widgets SHOULD conform to WAI-ARIA Authoring Practices for Best practice
Breadcrumbs.
Button widgets SHOULD conform to WAI-ARIA Authoring Practices for Buttons. Best practice
Button (Toggle) SHOULD conform to WAI-ARIA Authoring Practices for Buttons. Best practice
Carousel widgets (based on a Tab Panel) SHOULD conform to WAI-ARIA Best practice
Authoring Practices for Tab Panels.
Checkbox widgets SHOULD conform to WAI-ARIA Authoring Practices for Best practice
Checkboxes.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 38

Topic Technique WCAG AA
Checkbox (Tri-State) widgets SHOULD conform to WAI-ARIA Authoring Practices Best practice
for Checkboxes.
Combobox widgets SHOULD conform to WAI-ARIA Authoring Practices for Best practice
Comboboxes.
Dialog (Simple Modal) widgets SHOULD conform to WAI-ARIA Authoring Best practice
Practices for Modal Dialogs.
Dialog (Simple Alert Modal) widgets SHOULD conform to WAI-ARIA Authoring Best practice
Practices for Modal Dialogs.
Dialog (Message Modal) widgets SHOULD conform to WAI-ARIA Authoring Best practice
Practices for Modal Dialogs.
Dialog (Message Alert Modal) widgets SHOULD conform to WAI-ARIA Authoring Best practice
Practices for Modal Dialogs.
Disclosure (Show/Hide or Expand/Collapse) widgets SHOULD conform to WAI- Best practice
ARIA Authoring Practices for Disclosures.
Disclosure (Based on Details/Summary) widgets SHOULD conform to WAI-ARIA Best practice
Authoring Practices for Disclosures.
Feed widgets SHOULD conform to WAI-ARIA Authoring Practices for Feeds. Best practice
Grid widgets (Interactive Tabular Data and Layout Containers) SHOULD conform Best practice
to WAI-ARIA Authoring Practices for Grids.
Link widgets SHOULD conform to WAI-ARIA Authoring Practices for Links. Best practice
Listbox widgets SHOULD conform to WAI-ARIA Authoring Practices for List Best practice
Boxes.
Menu widgets SHOULD conform to WAI-ARIA Authoring Practices for Menus. Best practice
Menubar widgets SHOULD conform to WAI-ARIA Authoring Practices for Best practice
Menubars.
Menu Button widgets SHOULD conform to WAI-ARIA Authoring Practices for Best practice
Menu Buttons.
Navigation (Hierarchical) widgets with Expand/Collapse widgets SHOULD Best practice
conform to WAI-ARIA Authoring Practices for Disclosures.
Progress Bar (Bounded) widgets SHOULD conform to WAI-ARIA Authoring Best practice
Practices for Progress Bars.
Progress Bar (Unbounded) widgets SHOULD conform to WAI-ARIA Authoring Best practice
Practices for Progress Bars.
Radio and Radio Group widgets SHOULD conform to WAI-ARIA Authoring Best practice
Practices for Radio Groups.
Slider widgets SHOULD conform to WAI-ARIA Authoring Practices for Sliders. Best practice
Slider (Multi-Thumb) widgets SHOULD conform to WAI-ARIA Authoring Practices Best practice
for Multi-Thumb Sliders.
Spinbutton widgets SHOULD conform to WAI-ARIA Authoring Practices for Best practice
Spinbuttons.
Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 39
Topic Technique WCAG AA
Tab Panel widgets SHOULD conform to WAI-ARIA Authoring Practices for Tab Best practice
Panels.
Table widgets SHOULD conform to WAI-ARIA Authoring Practices for Tables. Best practice
Table (Responsive, Collapsible) widgets SHOULD maintain data relationships Best practice
through table structure, list hierarchy, and/or headings.
Table (Sortable) widgets SHOULD be constructed of a standard HTML table, if Best practice
possible, and make full use of ARIA sort attributes.
Toolbar widgets SHOULD conform to WAI-ARIA Authoring Practices for Toolbars. Best practice
Tooltip widgets SHOULD conform to WAI-ARIA Authoring Practices for Tooltips. Best practice
Tooltip Dialog widgets SHOULD conform to WAI-ARIA Authoring Practices for Best practice
Dialogs.
Tree View widgets SHOULD conform to WAI-ARIA Authoring Practices for Tree Best practice
Views.
Window Splitter widgets SHOULD conform to WAI-ARIA Authoring Practices for Best practice
Window Splitters.

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 40

CAPTCHA
Avoid CAPTCHAs if Possible
CAPTCHAs require human problem-solving skills — which can be difficult or impossible for users with cognitive disabilities
— and often require sensory abilities — which can be difficult or impossible for users who are blind, deafblind, or deaf. It
is best to avoid CAPTCHAs altogether, and instead implement smart algorithms that do not require human input.

Topic Technique WCAG AA

Text Text alternative describing the purpose: If the CAPTCHA is not text-based (e.g. Required
Alternatives image or audio), a text alternative MUST communicate the purpose of the WCAG 1.1.1
CAPTCHA, so that the user knows that this task must be completed before
proceeding to the next step.
Note 1: Ideally the alternative text would allow non-visual users to complete the
task, but at a minimum it should inform users of the purpose of the CAPTCHA.
Note 2: If there is an alternative CAPTCHA (e.g. in text elsewhere on the page, or in
audio), the user SHOULD be notified that the alternative exists, by mentioning it
either in the alternative text for the original CAPTCHA, or in the surrounding text.
Text-based CAPTCHA: A method SHOULD be available in a text-based format (either Best practice
as the main CAPTCHA or as an alternative) that can be converted by a screen
reader to braille output.
Note: Although WCAG does not require a text-based CAPTCHA, deafblind users
require a text-based method, because neither visual nor audio methods will be
sufficient.
Sensory Sensory alternative: If a non-visual user cannot pass the original CAPTCHA, an Required
Alternatives alternative method MUST be provided in another sensory modality (e.g. audio). WCAG 1.1.1
Keyboard User input controls in a CAPTCHA (or in an alternative representation) must meet Required
Accessibility all the keyboard functionality requirements. (Multiple)
Dynamic Any dynamic content in a CAPTCHA (or in an alternative method) must meet all the Required
Content dynamic content (JavaScript, AJAX) requirements. (Multiple)
Custom Any custom widgets in a CAPTCHA (or in an alternative method) must meet all the Required
Widgets custom widgets (JavaScript, ARIA) requirements. (Multiple)
Color and Any visual elements in a CAPTCHA (or in an alternative method) must meet all the Required
Contrast color and contrast requirements. (Multiple)

Deque Web Accessibility Checklist 2020.09.17 © Copyright 2020 Deque Systems P a g e 41