WCAG Checklist

Principle 1: Perceivable

Guideline 1.1: Text Alternatives

1.1.1: Non-Text Content

  • If short alt text is sufficient to describe an image, provide the short text via the alt attribute.

  • If short alt text is insufficient to describe a complex image, such a chart, graph, or diagram, also include a nearby text description that provides the same information.

  • Provide descriptive alt text for images used as buttons or links. The alt text should be sufficient to describe the purpose of the link or the button without surrounding context.

  • For images that should be ignored by assistive technology (such as decorative images), implement the images as CSS background images, or provide a null alt attribute and no title attribute.

  • Avoid adjacent links to the same destination Combine images and adjacent text that link to the same location into a single link. The image should have a null alt attribute, and the adjacent text should describe the purpose of the link.

Guideline 1.2: Time-Based Media

1.2.1: Pre-recorded Audio-only and Video-only

  • For pre-recorded audio (without video), provide a descriptive transcript that includes dialog and all other meaningful sound.

  • For pre-recorded video (without audio), provided a text alternative that provides the same information presented

1.2.2: Captions for Pre-recorded Content

  • Provide captions for prerecorded audio content in synchronized media.

1.2.3: Alternatives for Video

  • Provide a transcript or audio descriptions for videos.

1.2.4: Captions for Live Content

  • Provide captions for multimedia that contains live audio.

Guideline 1.3: Adaptable

1.3.1: Information and Relationships

  • Use ARIA landmarks and ARIA labels to identify regions of a page.

  • Correctly use semantic HTML to mark up structure (headings, lists, links, buttons, labels, fieldsets, and legends).

  • Ensure that text that is visually styled as a heading is marked up as a heading.

  • Reserve <a> tags for links and tags for buttons. Avoid using using <a> tags for button functionality. Avoid using <div>, <span>, etc. to emulate link or button functionality.
  • Correctly use tables for tabular data. Use table semantics appropriately (including <caption>, <th>, and scope). Avoid layout tables. When layout tables are unavoidable, use role="presentation".

  • Correctly use semantic HTML to mark up emphasis (including <em>, <strong><blockquote>).
  • Do not use white space characters for layout.

  • Avoid adding meaningful content by using the CSS :before and :after pseudo-elements via the content property.

1.3.2: Meaningful Sequence

  • Ensure that the page reading order is sensible when all styles are turned off.

  • Use CSS to lay out the page in a way that is sensible, intuitive, and compatible with the reading order presented by the DOM. Do not use CSS in a way to position content in a way that suggests a relationship different than the DOM.

  • If a layout table must be used, ensure it makes sense when linearized.

1.3.3: Sensory Characteristics

  • Do not identify elements on the page based solely visual characteristics such as position, size, shape, or color (e.g. “Click the square blue button” or “click the link in the left sidebar”).

  • Do not rely on rely on sound to convey information (e.g. “Begin the ask at the beep”)

  • Provide text alternatives for any symbols. Do not rely on a symbol alone to convey information.

Guideline 1.4: Distinguishable

1.4.1: Use of Color

  • When conveying information through color, also convey information through text.

  • Do not use color alone to indicate information about form labels (e.g. marking invalid fields in red). Always use a non-visual method in addition to color.

  • Do not use color alone to distinguish links from surrounding text. Make sure links are apparent without color vision. If a non-color cue is not present by default, then the contrast ratio between the link and the surrounding text must be at least 3:1, and the link must get some kind of color indication (e.g. underline) on hover and focus.

  • Use colors and other cues (e.g. symbols, patterns, stripes, hatching, line thickness, dotted or dashed lines) redundantly to convey information. Make sure that a text equivalent is also easily available.

1.4.2: Audio Control

  • Do not have audio that plays automatically on the page. When providing audio, also provide an easy way to disable the audio and adjust the volume.

1.4.3: Color Contrast

  • Use a contrast ratio between text and background that is at least 4.5:1. Ideally, use a contrast ratio that is at least 7:1. This applies to text and images of text.

  • For text that is at least 24px and normal weight or 19px and bold, use a contrast ratio that is at least 3:1. Ideally, use a contrast ratio that is at least 4.5:1. This applies to text and images of text.

1.4.4: Resize Text

  • Provide responsive styles such that horizontal scrolling is not required, content is not lost, and functionality is not lost when the page is zoomed to 200%.

  • Ensure that text and controls resize successfully when the font is resized to 200%. Text, controls, and other content should not be clipped, truncated, obscured, or otherwise illegible when the font is resized.

  • Define texts and text containers in relative units (percents, ems, rems) rather than in pixels.

1.4.5: Images of Text

  • Avoid images of text, unless a specific presentation of the text is essential to its meaning (e.g. a logo).

  • For images of text, provide alt text that matches the text in the image.

Principle 2: Operable

Guideline 2.1: Keyboard Accessible

2.1.1: Keyboard Operable

  • Ensure all functionality can be used by a keyboard alone, without requiring a specific timing for the keyboard strokes, unless the underlying function of the interaction requires movement (e.g. handwriting).

  • Ensure all form controls can be filled out and submitted using a keyboard only. Ensure all interactions can be triggered using a keyboard only. Ensure that all links (including emulated links) can be activated using a keyboard only.

  • Avoid access keys. If access keys must be implemented, they should not conflict with browser shortcuts.

  • Do not use scripts to remove focus from an element until the user moves focus manually.

2.1.2: No Keyboard Trap

  • Ensure keyboard focus is never trapped on an element without an obvious way to move focus out of the element.

Guideline 2.2: Enough Time

2.2.1: Timing Adjustable

  • Do not require time limits to complete tasks unless necessary. If a time limit is necessary, one of the following should be true:

    • the time limit is at least 20 hours
    • there is a way to deactivate the time limit
    • there is a way to extend the time limit to at least 10 times the normal duration.

2.2.2: Pause, Stop, Hide

  • Items on the page should not automatically move, blink, scroll, or update, including carousels. If content does automatically move, blink, scroll, or update, provide a way to pause, stop, or hide the moving, blinking, scrolling, or updating.

Guideline 2.3: Seizures

2.3.1: Limited Flashing

  • Do not provide any content that flashes more than three times in any 1-second period.

Guideline 2.4: Navigable

2.4.1: Bypass Blocks

  • Provide a link at the top of each page that skips directly to the main content area, past any repeated blocks. Optionally, provide links at the top of the page to skip to each area of the content.

2.4.2: Pages Have Titles

  • Provide a unique, descriptive <title> on each page using the element.

2.4.3: Focus Order

  • Create a logical tab order through links, form controls, and objects.

  • When inserting dynamic content into the DOM, insert the content immediately after the triggering element, or use scripting to manage focus in an intuitive way. When content is removed from the DOM, manage focus in an intuitive way.

  • Ensure that dialogs, expandable menus, and other triggered interactive elements follow their trigger control in the sequential navigation order. When such elements are dismissed, ensure that focus is placed back on their trigger.

  • Make sure that content that should not be able to receive focus cannot receive focus (e.g. when a modal or overlay is present, ensure that page elements behind the modal or overlay cannot receive focus).

  • Avoiding using tabindex with values greater than 0.

  • For single page applications, place focus on the page title when each new page is loaded.

2.4.4: Link Text in Context

  • Use link text that is sufficient to convey the purpose of the link out of context. Avoid unclear link text such as “Click Here”, “Read More”, etc. If the link text alone cannot be made sufficient, use a combination of link text, title, ARIA description, surrounding sentence, or surrounding list item.

  • Provide a descriptive alt attribute for Images used as buttons or links. The alt attribute should be sufficient to describe the purpose of the link or the button without surrounding context.

2.4.5: Multiple Ways

  • Ensure that more than one way is available to find webpages on the site. Options include:

    • list of related content
    • table of contents
    • site map
    • site search

2.4.6: Headings and Labels

  • Use descriptive, properly nested headings to structure content. Ensure that each page has an <h1> that is reserved for the title of the page. Do not skip heading levels.

  • Provide an HTML label with visual descriptive text for form control elements and elements that accept user input. If the element cannot use a label element, it should have a title attribute or an ARIA label. Avoid duplicated labels.

2.4.7: Focus Visible

  • Provide a focus style that makes it visually apparent which page element has current keyboard focus. Use focus styles that are more visually apparent than browser defaults.

  • Ensure that focus is on a visible element at all times.

  • Make sure that content that should not be able to receive focus cannot receive focus (e.g. when a modal or overlay is present, ensure that page elements behind the modal or overlay cannot receive focus).

Principle 3: Understandable

Guideline 3.1: Readable

3.1.1: Language of the Page

  • Provide a lang attribute on a page’s <html> element.

3.1.2: Language of Parts

  • Use the lang attribute to identify parts of the page whose language differ from the overall page language.

Guideline 3.2: Predictable

3.2.1: On Focus

  • When focus changes, do not also cause a change in page content, spawn a new browser window, or cause any other change that disorients the user.

3.2.2: On Input

  • When a user inputs information or interacts with a form control (e.g. a select, checkbox, or radio button), do not change the page content, change focus, launch an additional window, or otherwise disorient the user without informing the user ahead of time.

3.2.3: Consistent Navigation

  • Always present blocks and navigational elements that are repeated across pages throughout a site same relative order throughout the site.

  • Always present repeated navigation links in the same relative order across pages throughout a site.

3.2.4: Consistent Identification

  • For components that have the same functionality across multiple pages, label them consistently across pages.

Guideline 3.3: Input Assistance

3.3.1: Error Identification

  • If a user fails to complete a required form field, provide a text description to identify which required fields are not completed. Optionally, create a way for users to jump to errors. Optionally, set focus on a list or errors or on the first form field with the error.

  • Use aria-invalid on form fields to indicate errors.

  • If inline error messaged are used, associate the messages to their corresponding form controls using aria-describedby.

  • Do not rely on CSS alone (including color and :before and :after pseudo-elements) to indicate errors. Always include a non-styling method of indicating errors.

3.3.2: Labels or Instructions

  • Provide a visual HTML <label> with descriptive text for form control elements and elements that accept user input. If the element cannot use a label element, it should have a title attribute or an ARIA label. Do not use placeholder text in lieu of a <label>

  • Do not indicate required fields by using CSS alone (either color, or the :before and :after pseudo-elements and the content property).

  • Do not rely on placeholder text in lieu of an HTML <label>.

  • Use <fieldset> and <legend> to group related elements

  • Place instructions prior to the <form> element. Help text placed within a <form> element should be associated with form controls using aria-describedby.

3.3.3: Error Suggestion

  • If an input error is detected, provide suggestions for fixing the input.

3.3.4: Error Prevention (Legal, Financial, Data)

  • Provide easy ways to confirm, correct, or reverse a user action where a mistake would cause a serious consequence (e.g. submitting financial data, entering into a legal agreement, submitting test data, or purchasing a product).

Principle 4: Robust

Guideline 4.1: Compatible

4.1.1: Parsing

  • Avoid significant errors in HTML validation.

4.1.2: Name, Role, Value

  • Use the title attribute to provide accessible names to frames and iframes.

  • Provide accessible names to all interactive widgets by using <label> elements or ARIA labels, as appropriate.

  • Avoid creating custom widgets when a native HTML element already exists. Reserve <a> tags for links and <button> tags for buttons. Avoid using using <a> tags for button functionality. Avoid using <div>, <span>, etc. to emulate link or button functionality.

  • Custom user interface components should conform to the ARIA Authoring Practices Document. Use ARIA labels, descriptions, roles, states, and properties to expose information about the component. Custom user interface components should manage focus.

  • Use ARIA live regions to provide messages about updates to the page, such as when content is added or removed to the page.