How to Meet WCAG (Quick Reference)

https://www.w3.org/WAI/WCAG21/
Admin
A customizable quick reference tool for Web Content Accessibility Guidelines (WCAG) 2 requirements,...
Tokens:10,337
Snippets:38
Trust Score:10
Update:1 year ago
Show doc for...
Tokens:
Raw
### Situation D: Short Text Alternatives for Time-Based Media

Source: https://www.w3.org/WAI/WCAG21/quickref

Techniques for providing short text alternatives for non-text content that is time-based media (live audio-only, live video-only), a test/exercise invalid if text, or primarily intended for sensory experience. These methods ensure accessibility by offering descriptive labels or alternatives.

```APIDOC
Situation D: Short Text Alternatives for Time-Based Media, Tests, or Sensory Experiences

This section details techniques for providing short text alternatives for specific types of non-text content.

Techniques:

1.  **G68: Providing a short text alternative that describes the purpose of live audio-only and live video-only content**
    *   Purpose: To describe the purpose of live audio-only and live video-only content.
    *   Applies to: Live audio-only and live video-only content.

2.  **G100: Providing a short text alternative which is the accepted name or a descriptive name of the non-text content**
    *   Purpose: To use an accepted or descriptive name for non-text content.
    *   Applies to: Non-text content where a standard name exists or a descriptive name is sufficient.

3.  **ARIA6: Using aria-label to provide labels for objects**
    *   Purpose: To provide a text label for an element using the `aria-label` attribute.
    *   Usage: `<element aria-label="Description">...</element>`
    *   Applies to: Any HTML element requiring a label.

4.  **ARIA10: Using aria-labelledby to provide a text alternative for non-text content**
    *   Purpose: To associate text from another element (using its ID) as a text alternative for non-text content.
    *   Usage: `<element aria-labelledby="id-of-label-element">...</element>`
    *   Applies to: Non-text content that needs to be labeled by existing text.

5.  **G196: Using a text alternative on one item within a group of images that describes all items in the group**
    *   Purpose: To provide a single text alternative for a group of images if one image represents the entire group.
    *   Applies to: Groups of images where one serves as a collective representation.

6.  **H2: Combining adjacent image and text links for the same resource**
    *   Purpose: To combine adjacent image and text links that point to the same resource.
    *   Usage: Ensure the image and text link are perceived as a single unit.
    *   Applies to: Scenarios where an image and text are used together as a link.

7.  **H37: Using alt attributes on img elements**
    *   Purpose: To provide text alternatives for `<img>` elements using the `alt` attribute.
    *   Usage: `<img src="image.jpg" alt="Description of image">`
    *   Applies to: All `<img>` elements.

8.  **H53: Using the body of the object element**
    *   Purpose: To provide text alternatives within the `<object>` element's `<body>` for content that cannot be rendered.
    *   Usage: `<object data="file.pdf"><body>Text alternative for PDF</body></object>`
    *   Applies to: `<object>` elements.

9.  **H86: Providing text alternatives for emojis, emoticons, ASCII art, and leetspeak**
    *   Purpose: To provide text alternatives for character-based representations like emojis, emoticons, ASCII art, and leetspeak.
    *   Applies to: Content using these character-based forms.

10. **PDF1: Applying text alternatives to images with the Alt entry in PDF documents**
    *   Purpose: To provide text alternatives for images within PDF documents using the 'Alt' text property.
    *   Applies to: Images embedded in PDF documents.
```

--------------------------------

### General Techniques for Name, Role, Value

Source: https://www.w3.org/WAI/WCAG21/quickref

General principles and techniques for exposing name, role, and value information, applicable across various technologies.

```APIDOC
G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes
  - Description: A general technique that emphasizes using platform or markup features to ensure components have accessible names, roles, and can notify of state changes.
  - Applicable Situations: Situation A.
  - Related Techniques: H91, H44, H64, H65, H88, ARIA16.
```

```APIDOC
G135: Using the accessibility API features of a technology to expose names and roles, to allow user-settable properties to be directly set, and to provide notification of changes
  - Description: Leverages the native accessibility APIs of a technology (e.g., operating system, UI framework) to provide essential accessibility information.
  - Applicable Situations: Situation C.
  - Related Techniques: PDF10, PDF12.
```

```APIDOC
G10: Creating components using a technology that supports the accessibility API features of the platforms on which the user agents will be run to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes
  - Description: Focuses on building custom components using technologies that inherently support accessibility APIs for robust name, role, and state exposure.
  - Applicable Situations: Situation D.
  - Related Techniques: ARIA4, ARIA5, ARIA16.
```

--------------------------------

### G62: Providing a glossary

Source: https://www.w3.org/WAI/WCAG21/quickref

This general technique describes the process of providing a comprehensive glossary of terms used within a web page or site. It serves as a method for defining unusual words or phrases, supporting WCAG 2.1 SC 3.1.3.

```general
Technique G62: Providing a glossary

Purpose: To offer a centralized list of definitions for terms used in the content.

Implementation:
  - Create a dedicated page or section for the glossary.
  - List terms alphabetically with their definitions.
  - Link to the glossary from relevant parts of the content.

Related Techniques:
  - G101: Providing the definition of a word or phrase used in an unusual or restricted way
  - H40: Using description lists (HTML)
```

--------------------------------

### General Techniques for Input Assistance

Source: https://www.w3.org/WAI/WCAG21/quickref

General strategies for ensuring users can identify required fields, correct errors, and understand input requirements.

```APIDOC
G83: Providing text descriptions to identify required fields that were not completed
  - Description: Clearly indicate which form fields are mandatory using text labels or visual cues (e.g., an asterisk with a legend).
  - Example: A form label like "Username (required)".
  - Purpose: Informs users about mandatory input requirements.

G84: Providing a text description when the user provides information that is not in the list of allowed values
  - Description: When user input deviates from a predefined list of options (e.g., a dropdown selection), provide clear text explaining the issue.
  - Example: "Invalid selection. Please choose from the provided list."
  - Purpose: Guides users to correct selections when they pick an invalid option.

G85: Providing a text description when user input falls outside the required format or values
  - Description: If input does not match the expected format (e.g., date format, number range), provide specific textual feedback.
  - Example: "Please enter the date in YYYY-MM-DD format."
  - Purpose: Helps users understand and correct formatting errors.

G139: Creating a mechanism that allows users to jump to errors
  - Description: Provide a summary of errors at the top of a form with links that jump directly to the corresponding fields.
  - Purpose: Improves navigation for users encountering multiple form errors.
```

--------------------------------

### HTML Techniques for Name, Role, Value

Source: https://www.w3.org/WAI/WCAG21/quickref

Techniques using HTML features and attributes to ensure user interface components have accessible names, roles, and values.

```APIDOC
H91: Using HTML form controls and links
  - Description: Demonstrates how to correctly implement HTML form controls and links to ensure they are accessible, including proper labeling.
  - Applicable Situations: Situation A.
  - Related Techniques: G108, H44, H64, H65, H88.
```

```APIDOC
H44: Using label elements to associate text labels with form controls
  - Description: Associates a visible text label with a form control using the HTML <label> element and its 'for' attribute.
  - Applicable Situations: Situation A.
  - Related Techniques: G108, H91, H65.
```

```APIDOC
H64: Using the title attribute of the iframe element
  - Description: Provides a title for an iframe element using the 'title' attribute, which can serve as an accessible name.
  - Applicable Situations: Situation A.
  - Related Techniques: G108, H65.
```

```APIDOC
H65: Using the title attribute to identify form controls when the label element cannot be used
  - Description: Uses the 'title' attribute to provide an accessible name for form controls when the <label> element cannot be directly associated.
  - Applicable Situations: Situation A.
  - Related Techniques: G108, H91, H44, H64.
```

```APIDOC
H88: Using HTML according to spec
  - Description: Ensures that HTML is implemented according to the official specifications, which inherently supports accessibility features.
  - Applicable Situations: Situation A.
  - Related Techniques: G108, H91.
```

--------------------------------

### Advisory Techniques: CSS Layout

Source: https://www.w3.org/WAI/WCAG21/quickref

An advisory technique recommending the use of CSS margin and padding for layout design instead of spacer images, promoting cleaner code and better accessibility.

```APIDOC
Advisory Techniques: CSS Layout

This advisory technique promotes modern CSS practices for layout.

1.  **C18: Using CSS margin and padding rules instead of spacer images for layout design**
    *   Purpose: To use CSS `margin` and `padding` properties for creating space and controlling layout, rather than relying on transparent spacer images.
    *   Benefits: Reduces HTTP requests, improves code maintainability, and avoids semantic issues associated with spacer images.
    *   Usage: `selector { margin: 10px; padding: 5px; }`
    *   Applies to: Layout design and spacing within web pages.
```

--------------------------------

### General Techniques for Media Accessibility

Source: https://www.w3.org/WAI/WCAG21/quickref

This section details general techniques for ensuring media accessibility, including creating captions for live synchronized media, providing open or closed captions, offering a second audio track for descriptions, and incorporating narration into the soundtrack.

```General
G9: Creating captions for live synchronized media
G93: Providing open (always visible) captions
G87: Providing closed captions
G78: Providing a second, user-selectable, audio track that includes audio descriptions
G173: Providing a version of a movie with audio descriptions
G226: Providing audio descriptions by incorporating narration in the soundtrack
G8: Providing a movie with extended audio descriptions
G203: Using a static text alternative to describe a talking head video
```

--------------------------------

### WCAG Sufficient Techniques for Content on Hover or Focus

Source: https://www.w3.org/WAI/WCAG21/quickref

Highlights sufficient techniques for meeting Success Criterion 1.4.13, such as client-side scripting for hoverable/dismissible content and potential future techniques using ARIA and CSS.

```APIDOC
Sufficient Techniques for Success Criterion 1.4.13:

- **SCR39:** Making content on focus or hover hoverable, dismissible, and persistent (client-side script).
- **Potential Future Technique:** Using ARIA role="tooltip".
- **Potential Future Technique:** Using hover and focus pseudo classes (CSS).
```

--------------------------------

### HTML track element for Audio Descriptions

Source: https://www.w3.org/WAI/WCAG21/quickref

This technique describes using the HTML `<track>` element to provide audio descriptions for video content. It is an advisory technique for Success Criterion 1.2.5 (Audio Description Prerecorded).

```HTML
<video controls>
  <source src="movie.mp4" type="video/mp4">
  <track kind="descriptions" srclang="en" label="English Audio Description" src="audio-description.vtt">
  Your browser does not support the video tag.
</video>
```

--------------------------------

### SMIL Techniques for Media Accessibility

Source: https://www.w3.org/WAI/WCAG21/quickref

This entry covers various techniques using Synchronized Multimedia Integration Language (SMIL) for providing media accessibility features. These include providing captions and audio descriptions in SMIL 1.0 and SMIL 2.0 formats, as well as extended audio descriptions.

```SMIL
SM11: Providing captions through synchronized text streams in SMIL 1.0
SM12: Providing captions through synchronized text streams in SMIL 2.0
```

```SMIL
SM6: Providing audio description in SMIL 1.0
SM7: Providing audio description in SMIL 2.0
```

```SMIL
SM1: Adding extended audio description in SMIL 1.0
SM2: Adding extended audio description in SMIL 2.0
```

--------------------------------

### ARIA Techniques for Name, Role, Value

Source: https://www.w3.org/WAI/WCAG21/quickref

Techniques leveraging ARIA attributes to expose the name, role, and state of user interface components, crucial for accessibility.

```APIDOC
ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used
  - Description: Provides a method to associate a text label with a user interface element when a visible label is not present or feasible.
  - Applicable Situations: Situation A (Standard UI component in markup language).
  - Related Techniques: ARIA16, G108, H44, H65.
```

```APIDOC
ARIA16: Using aria-labelledby to provide a name for user interface controls
  - Description: Associates a user interface control with a visible label or other elements that provide its name, using the aria-labelledby attribute.
  - Applicable Situations: Situation A, Situation B, Situation D.
  - Related Techniques: ARIA14, G108, H44, H65.
```

```APIDOC
ARIA4: Using a WAI-ARIA role to expose the role of a user interface component
  - Description: Specifies the role of a custom UI component using ARIA role attributes, informing assistive technologies about its purpose.
  - Applicable Situations: Situation D.
  - Related Techniques: ARIA5, ARIA16, G10.
```

```APIDOC
ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component
  - Description: Exposes the current state and properties of a custom UI component (e.g., checked, expanded) using ARIA state and property attributes.
  - Applicable Situations: Situation D.
  - Related Techniques: ARIA4, ARIA16, G10.
```

--------------------------------

### Situation E: Text Alternatives for CAPTCHAs

Source: https://www.w3.org/WAI/WCAG21/quickref

Techniques for providing text alternatives for CAPTCHAs, ensuring accessibility for users who cannot solve the CAPTCHA through its primary modality.

```APIDOC
Situation E: Text Alternatives for CAPTCHAs

This section details techniques for ensuring CAPTCHAs are accessible.

Techniques:

1.  **G143: Providing a text alternative that describes the purpose of the CAPTCHA**
    *   Purpose: To provide a text alternative that explains the purpose of the CAPTCHA.
    *   Applies to: All CAPTCHA mechanisms.

2.  **G144: Ensuring that the Web Page contains another CAPTCHA serving the same purpose using a different modality**
    *   Purpose: To offer an alternative CAPTCHA modality (e.g., audio CAPTCHA if visual fails) for the same purpose.
    *   Applies to: CAPTCHAs where a different modality can be provided.
```

--------------------------------

### CSS Technique for Target Spacing

Source: https://www.w3.org/WAI/WCAG21/quickref

Illustrates using CSS properties like 'min-width' and 'min-height' to ensure sufficient target spacing for pointer inputs, a sufficient technique for WCAG Success Criterion 2.5.8.

```css
.target-element {
  min-width: 24px;
  min-height: 24px;
  /* Additional styling for spacing */
}
```

--------------------------------

### PDF Techniques for Name, Role, Value

Source: https://www.w3.org/WAI/WCAG21/quickref

Techniques specific to PDF documents for providing accessible names, roles, and values for interactive form controls.

```APIDOC
PDF10: Providing labels for interactive form controls in PDF documents
  - Description: Ensures that interactive form controls within PDF documents have associated text labels that can be read by assistive technologies.
  - Applicable Situations: Situation C.
  - Related Techniques: G135, PDF12.
```

```APIDOC
PDF12: Providing name, role, value information for form fields in PDF documents
  - Description: Details how to correctly tag PDF form fields to expose their name, role, and current value to assistive technologies.
  - Applicable Situations: Situation C.
  - Related Techniques: G135, PDF10.
```

--------------------------------

### WCAG 2.1.1 Keyboard Accessibility Details

Source: https://www.w3.org/WAI/WCAG21/quickref

Defines the requirement for all content functionality to be operable via a keyboard interface without specific timing dependencies, with an exception for functions inherently requiring path-dependent input.

```APIDOC
Success Criterion 2.1.1: Keyboard (Level A)

Requirements:
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Notes:
- The exception relates to the underlying function, not the input technique (e.g., handwriting input vs. text input).
- Does not forbid providing mouse or other input methods in addition to keyboard operation.
```

--------------------------------

### G55 & H40: Linking to definitions using description lists

Source: https://www.w3.org/WAI/WCAG21/quickref

This combination of general and HTML techniques describes how to link to definitions of unusual words or phrases using HTML description lists (`<dl>`, `<dt>`, `<dd>`). It is a sufficient method for G101 and thus for WCAG 2.1 SC 3.1.3.

```general
Technique G55: Linking to definitions

Purpose: To provide a link to a definition of a word or phrase.

Implementation:
  - Use HTML elements like `<a>` to link to a definition.
  - Ensure the linked definition is accessible and clearly associated with the term.

Related Techniques:
  - G101: Providing the definition of a word or phrase used in an unusual or restricted way
  - H40: Using description lists (HTML)
```

```html
<p>The term <dfn>AJAX</dfn> is an acronym for Asynchronous JavaScript and XML.</p>

<p>For more information, see our <a href="#glossary">glossary</a>.</p>

<dl id="glossary">
  <dt>AJAX</dt>
  <dd>Asynchronous JavaScript and XML: A set of web development techniques that use JavaScript in the background to exchange data with the web server without reloading the entire page.</dd>
</dl>
```

--------------------------------

### WCAG 2.1 Techniques: Page Titled

Source: https://www.w3.org/WAI/WCAG21/quickref

Ensures web pages have descriptive titles that accurately reflect their topic or purpose. This involves using the HTML title element or equivalent mechanisms in other formats.

```general
G88: Providing descriptive titles for web pages
```

```html
H25: Providing a title using the title element
```

```pdf
PDF18: Specifying the document title using the Title entry in the document information dictionary of a PDF document
```

--------------------------------

### WCAG 4.1.3 Status Messages: General Techniques

Source: https://www.w3.org/WAI/WCAG21/quickref

General techniques that support WCAG 2.1 Success Criterion 4.1.3 (Status Messages), focusing on providing feedback for actions and input validation.

```APIDOC
G199: Providing success feedback when data is submitted successfully
  - Description: Ensure users receive clear feedback when an action, like form submission, is successful.
  - Implementation: Often combined with ARIA roles like `status` or `log` to announce success messages.
  - Example:
    ```html
    <form>
      <!-- form elements -->
      <button type="submit">Submit</button>
      <div id="submission-status" role="status" aria-live="polite" class="hidden"></div>
    </form>
    <script>
      const form = document.querySelector('form');
      const statusDiv = document.getElementById('submission-status');
      form.addEventListener('submit', (event) => {
        event.preventDefault();
        // Simulate submission
        setTimeout(() => {
          statusDiv.textContent = 'Form submitted successfully!';
          statusDiv.classList.remove('hidden');
        }, 1000);
      });
    </script>
    ```

G83: Providing text descriptions to identify required fields that were not completed
  - Description: Guide users by indicating which required fields were missed during form submission.
  - Implementation: Use visual cues and ARIA attributes (`aria-required`, `aria-describedby`) to link error messages to fields.

G84: Providing a text description when the user provides information that is not in the list of allowed values
  - Description: Inform users when their input deviates from expected formats or predefined options.
  - Implementation: Provide specific error messages, potentially using `aria-live` regions.

G85: Providing a text description when user input falls outside the required format or values
  - Description: Similar to G84, this focuses on input validation errors.
  - Implementation: Clear, actionable error messages are key.

G177: Providing suggested correction text
  - Description: Offer suggestions to help users correct input errors.
  - Implementation: Display suggested corrections near the erroneous input, possibly linked via `aria-describedby`.

G194: Providing spell checking and suggestions for text input
  - Description: Integrate spell-checking and provide suggestions for text input fields.
  - Implementation: Use browser-native spellcheck or custom JavaScript solutions, ensuring accessibility.

G193: Providing help by an assistant in the web page
  - Description: Offer assistance or guidance within the page context, which can include status updates or error explanations.
  - Implementation: Can involve dynamic content updates announced via ARIA live regions.
```

--------------------------------

### WCAG 1.4.13 Content on Hover or Focus Details

Source: https://www.w3.org/WAI/WCAG21/quickref

Details the requirements for content that appears on hover or focus, ensuring it is dismissible, hoverable, and persistent. Covers exceptions and notes on user agent controlled content like browser tooltips.

```APIDOC
Success Criterion 1.4.13: Content on Hover or Focus (Level AA)

Requirements:
Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following must be true:

1.  **Dismissible:** A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content.
2.  **Hoverable:** If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing.
3.  **Persistent:** The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Exception:
The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

Notes:
- User agent controlled content examples: browser tooltips created through the HTML title attribute.
- Custom tooltips, sub-menus, and nonmodal popups on hover/focus are covered.
- Applies to content *in addition* to the triggering component; hidden components made visible on focus (e.g., skip links) are not covered.
```

--------------------------------

### WCAG 2.1 Techniques: Bypass Blocks

Source: https://www.w3.org/WAI/WCAG21/quickref

Provides mechanisms to bypass blocks of content that are repeated on multiple web pages. This includes adding skip links or grouping content semantically.

```general
G1: Adding a link at the top of each page that goes directly to the main content area
```

```general
G123: Adding a link at the beginning of a block of repeated content to go to the end of the block
```

```general
G124: Adding links at the top of the page to each area of the content
```

```aria
ARIA11: Using ARIA landmarks to identify regions of a page
```

```html
H69: Providing heading elements at the beginning of each section of content
```

```pdf
PDF9: Providing headings by marking content with heading tags in PDF documents
```

```html
H64: Using the title attribute of the iframe element
```

```client-side-script
SCR28: Using an expandable and collapsible menu to bypass block of content
```

--------------------------------

### G70: Providing a function to search an online dictionary

Source: https://www.w3.org/WAI/WCAG21/quickref

This general technique involves integrating a search function that allows users to look up definitions of words or phrases in an external online dictionary. This supports WCAG 2.1 SC 3.1.3 by providing access to definitions for unusual terms.

```general
Technique G70: Providing a function to search an online dictionary

Purpose: To enable users to find definitions of unfamiliar terms via an external dictionary service.

Implementation:
  - Embed a search bar or link that directs users to a dictionary service.
  - Ensure the search function is easily discoverable and usable.

Related Techniques:
  - G101: Providing the definition of a word or phrase used in an unusual or restricted way
```

--------------------------------

### Client-Side Scripting for Validation and Alerts

Source: https://www.w3.org/WAI/WCAG21/quickref

Techniques involving client-side scripting to perform input validation and provide feedback to users about errors or required fields.

```javascript
SCR18: Providing client-side validation and alert
  - Description: Implement JavaScript to validate form inputs on the client side and display alerts or messages for errors.
  - Example:
    ```javascript
    function validateForm() {
      const email = document.getElementById('email');
      const emailValue = email.value;
      const emailError = document.getElementById('email-error');

      if (!emailValue.includes('@')) {
        email.setAttribute('aria-invalid', 'true');
        emailError.textContent = 'Please enter a valid email address.';
        emailError.style.display = 'block';
        return false;
      } else {
        email.setAttribute('aria-invalid', 'false');
        emailError.textContent = '';
        emailError.style.display = 'none';
        return true;
      }
    }
    ```
  - Purpose: Helps users correct mistakes before submission by providing immediate feedback.
```

```javascript
SCR32: Providing client-side validation and adding error text via the DOM
  - Description: Use JavaScript to dynamically add error messages to the DOM, often near the invalid input field, to provide context.
  - Example:
    ```javascript
    const passwordInput = document.getElementById('password');
    const passwordErrorSpan = document.createElement('span');
    passwordErrorSpan.id = 'password-error';
    passwordErrorSpan.className = 'error-message';
    passwordInput.parentNode.insertBefore(passwordErrorSpan, passwordInput.nextSibling);

    passwordInput.addEventListener('input', () => {
      if (passwordInput.value.length < 8) {
        passwordInput.setAttribute('aria-invalid', 'true');
        passwordErrorSpan.textContent = 'Password must be at least 8 characters.';
        passwordErrorSpan.style.display = 'block';
      } else {
        passwordInput.setAttribute('aria-invalid', 'false');
        passwordErrorSpan.textContent = '';
        passwordErrorSpan.style.display = 'none';
      }
    });
    ```
  - Purpose: Offers more integrated and accessible error reporting compared to simple alerts.
```

--------------------------------

### PDF Techniques for Input Assistance

Source: https://www.w3.org/WAI/WCAG21/quickref

Methods for indicating required fields and handling input errors within PDF forms.

```APIDOC
PDF5: Indicating required form controls in PDF forms
  - Description: Clearly mark required fields in PDF forms, typically using an asterisk (*) or explicit text.
  - Purpose: Ensures users know which fields must be completed.

PDF22: Indicating when user input falls outside the required format or values in PDF forms
  - Description: Provide clear instructions or error messages within the PDF form if user input does not meet format or value requirements.
  - Purpose: Guides users to provide correct data in PDF forms.
```

--------------------------------

### Situation F: Ignoring Non-Text Content

Source: https://www.w3.org/WAI/WCAG21/quickref

Techniques for marking non-text content so it is ignored by assistive technologies, indicating that text alternatives are not required for these elements.

```APIDOC
Situation F: Ignoring Non-Text Content

This section details techniques for marking non-text content to be ignored by assistive technologies.

Techniques:

1.  **C9: Using CSS to include decorative images**
    *   Purpose: To use CSS (e.g., `background-image`) for decorative images, which are typically ignored by assistive technology.
    *   Usage: `selector { background-image: url('decorative.png'); }`
    *   Applies to: Images that are purely decorative and do not convey information.

2.  **H67: Using null alt text and no title attribute on img elements for images that assistive technology should ignore**
    *   Purpose: To mark `<img>` elements as decorative by using an empty `alt` attribute (`alt=""`) and no `title` attribute.
    *   Usage: `<img src="decorative.png" alt="">`
    *   Applies to: Images that are purely decorative.

3.  **PDF4: Hiding decorative images with the Artifact tag in PDF documents**
    *   Purpose: To mark images as artifacts within PDF documents, causing them to be ignored by assistive technology.
    *   Applies to: Decorative images embedded in PDF documents.
```

--------------------------------

### Server-Side Script Technique for Default Language

Source: https://www.w3.org/WAI/WCAG21/quickref

Describes specifying the default language of a web page via the HTTP header, an advisory technique for WCAG Success Criterion 3.1.1.

```server-side-script
HTTP/1.1 200 OK
Content-Type: text/html
Content-Language: en

<!DOCTYPE html>
<html>
<head>
    <title>Page Title</title>
</head>
<body>
    <!-- Page content -->
</body>
</html>
```

--------------------------------

### WCAG Failures for Content on Hover or Focus

Source: https://www.w3.org/WAI/WCAG21/quickref

Lists common failures related to Success Criterion 1.4.13, including clipped/overlapped content due to text spacing adjustments and content not being hoverable or dismissible.

```APIDOC
Failures for Success Criterion 1.4.13:

- **F104:** Failure of Success Criterion 1.4.12 due to clipped or overlapped content when text spacing is adjusted.
- **F95:** Failure of Success Criterion 1.4.13 due to content shown on hover not being hoverable.
- Failure to make content dismissible without moving pointer hover or keyboard focus.
- Failure to meet by content on hover or focus not remaining visible until dismissed or invalid.
```

--------------------------------

### G112 & H54: Using inline definitions with dfn element

Source: https://www.w3.org/WAI/WCAG21/quickref

This combination of general and HTML techniques describes how to provide inline definitions for unusual words or phrases using the HTML `<dfn>` element. It is a sufficient method for G101 and thus for WCAG 2.1 SC 3.1.3.

```general
Technique G112: Using inline definitions

Purpose: To provide definitions for words or phrases directly within the text flow.

Implementation:
  - Use HTML elements like `<dfn>` to mark the first occurrence of a term being defined.
  - Place the definition nearby, often in parentheses or as a tooltip.

Related Techniques:
  - G101: Providing the definition of a word or phrase used in an unusual or restricted way
  - H54: Using the dfn element to identify the defining instance of a word (HTML)
```

```html
<p>The term <dfn>WCAG</dfn> stands for Web Content Accessibility Guidelines.</p>
<p>WCAG provides recommendations for making web content more accessible.</p>
```

--------------------------------

### PDF Technique for Passage Language

Source: https://www.w3.org/WAI/WCAG21/quickref

Explains how to specify the language for a specific passage or phrase within a PDF document using the 'Lang' entry, supporting WCAG Success Criterion 3.1.2.

```pdf
/Lang (fr)
% ... text content for the passage ...
```

--------------------------------

### WCAG 2.1 Technique: G19 - No Flashing

Source: https://www.w3.org/WAI/WCAG21/quickref

Ensures that no component of the content flashes more than three times in any 1-second period. This is a general technique for managing temporal visual patterns.

```general
G19: Ensuring that no component of the content flashes more than three times in any 1-second period
```

--------------------------------

### WCAG 4.1.2 Failures: UI Control Accessibility

Source: https://www.w3.org/WAI/WCAG21/quickref

Common failures related to WCAG 2.1 Success Criterion 4.1.2 (Name, Role, Value), highlighting issues with custom controls, missing accessible names, and focus state determinability.

```APIDOC
F59: Failure of SC 4.1.2 - Scripted div/span as UI Control
  - Description: Using `<div>` or `<span>` as a user interface control without providing a `role` attribute.
  - Impact: Assistive technologies cannot identify the element's purpose or functionality.
  - Fix: Assign an appropriate ARIA `role` (e.g., `role="button"`, `role="checkbox"`).

F15: Failure of SC 4.1.2 - Incomplete Accessibility API Implementation
  - Description: Custom controls do not use or incompletely use an accessibility API.
  - Impact: Assistive technologies cannot access or interact with custom controls correctly.
  - Fix: Ensure custom controls expose their name, role, and state via the platform's accessibility API or ARIA.

F68: Failure of SC 4.1.2 - Missing Programmatically Determined Name
  - Description: A user interface control lacks a name that can be programmatically determined.
  - Impact: Users cannot identify the purpose of the control.
  - Fix: Provide an accessible name using methods like `aria-label`, `aria-labelledby`, or by associating a visible label with the control.

F79: Failure of SC 4.1.2 - Undeterminable Focus State or No Change Notification
  - Description: The focus state of a UI component is not programmatically determinable, or changes to focus state are not notified.
  - Impact: Users may not know which element has focus or when focus changes.
  - Fix: Ensure focus states are managed and communicated, potentially using ARIA attributes or by managing focus programmatically.

F86: Failure of SC 4.1.2 - Missing Names for Multi-part Form Fields
  - Description: Each part of a multi-part form field (e.g., US telephone number with separate fields for area code, prefix, line number) does not have a programmatically determinable name.
  - Impact: Users cannot associate labels with individual parts of the composite field.
  - Fix: Use `aria-labelledby` to associate a common label with each part, or provide individual labels.

F89: Failure of SC 2.4.4, 2.4.9, 4.1.2 - Image-Only Link Without Accessible Name
  - Description: An image is the sole content of a link, but it lacks an accessible name.
  - Impact: Users cannot understand the purpose of the link.
  - Fix: Provide an `alt` attribute for the image or use `aria-label` on the link.

F111: Failure of SC 1.3.1, 2.5.3, 4.1.2 - Visible Label, No Accessible Name
  - Description: A control has visible label text, but no accessible name is programmatically determined.
  - Impact: Assistive technologies cannot reliably associate the visible label with the control.
  - Fix: Ensure the visible label is correctly associated with the control using `for`/`id` attributes or ARIA attributes.
```

--------------------------------

### G101: Providing definitions for unusual words/phrases

Source: https://www.w3.org/WAI/WCAG21/quickref

This general technique covers providing definitions for words or phrases used in an unusual or restricted way, including idioms and jargon. It is a sufficient technique for WCAG 2.1 Success Criterion 3.1.3 (Unusual Words).

```general
Technique G101: Providing the definition of a word or phrase used in an unusual or restricted way

Purpose: To make specific definitions of words or phrases available when they are used in an unusual or restricted way, including idioms and jargon.

Applicability:
  - Situation A: If the word or phrase has a unique meaning within the web page.
  - Situation B: If the word or phrase means different things within the same web page.

Implementation Methods:
  - Linking to definitions (G55)
  - Using inline definitions (G112)
  - Providing a glossary (G62)
  - Providing a function to search an online dictionary (G70)

Related Techniques:
  - G55: Linking to definitions
  - G112: Using inline definitions
  - G62: Providing a glossary
  - G70: Providing a function to search an online dictionary
  - H40: Using description lists (HTML)
  - H54: Using the dfn element to identify the defining instance of a word (HTML)
```

--------------------------------

### PDF Technique for Default Page Language

Source: https://www.w3.org/WAI/WCAG21/quickref

Details how to set the default language for a PDF document using the '/Lang' entry in the document catalog, fulfilling WCAG Success Criterion 3.1.1.

```pdf
/Lang (en)
% ... document catalog entries ...
```

--------------------------------

### HTML Technique for Language of Page

Source: https://www.w3.org/WAI/WCAG21/quickref

Specifies the use of the 'lang' attribute on the HTML element to programmatically determine the default human language of a web page, as per WCAG Success Criterion 3.1.1.

```html
<html lang="en">
  <!-- Page content -->
</html>
```

--------------------------------

### PDF19: Specifying language in PDF documents

Source: https://www.w3.org/WAI/WCAG21/quickref

This technique explains how to specify the human language for a passage or phrase within PDF documents using the 'Lang' entry. It is a sufficient technique for WCAG 2.1 Success Criterion 3.1.2 (Language of Parts).

```APIDOC
PDF Document Language Specification:

Method: SetLangEntry

Description: Specifies the human language for a passage or phrase within a PDF document.

Parameters:
  - LangEntry (string): The language code (e.g., 'en-US', 'fr-CA') for the text passage.

Usage:
  Apply the LangEntry to the relevant text block or annotation within the PDF structure.

Example:
  // Conceptual representation of setting language for a text block
  pdfDocument.addText("This is English.", { lang: "en-US" });
  pdfDocument.addText("Ceci est en français.", { lang: "fr-FR" });

Related Techniques:
  - H58: Using language attributes to identify changes in the human language (HTML)
```

--------------------------------

### H58: Using language attributes in HTML

Source: https://www.w3.org/WAI/WCAG21/quickref

This technique describes how to use the `lang` attribute in HTML to identify changes in the human language of content. It is a sufficient technique for WCAG 2.1 Success Criterion 3.1.2 (Language of Parts).

```html
<p>This is English.</p>
<p lang="fr">Ceci est en français.</p>
<p>This is English again.</p>
```

--------------------------------

### WCAG 4.1.3 Status Messages: ARIA Roles

Source: https://www.w3.org/WAI/WCAG21/quickref

Details on using ARIA roles to convey status messages, including success/results, errors/warnings, and progress updates, as per WCAG 2.1 Success Criterion 4.1.3.

```APIDOC
ARIA22: Using role=status to present status messages
  - Purpose: To present status messages that advise on the success or results of an action, or the state of an application.
  - Usage: Apply `role="status"` to an element that will contain status messages.
  - Example:
    <div role="status">Your form was submitted successfully.</div>
  - Related Techniques: G199 (Providing success feedback when data is submitted successfully).

ARIA19: Using ARIA role=alert or Live Regions to Identify Errors
  - Purpose: To convey suggestions or warnings on the existence of an error, ensuring assistive technologies can present them.
  - Usage: Use `role="alert"` for critical, time-sensitive messages, or live regions for less urgent notifications.
  - Example (alert):
    <div role="alert">Please enter a valid email address.</div>
  - Example (live region):
    <div aria-live="polite">Your changes have been saved.</div>
  - Related Techniques: G83, G84, G85, G177, G194 (Various techniques for providing error descriptions and suggestions).
  - Note: `role="alert"` is primarily for changes of context that do not take place.

ARIA23: Using role=log to identify sequential information updates
  - Purpose: To present sequential information updates, such as chat messages or progress logs.
  - Usage: Apply `role="log"` to an element that will contain a series of updates.
  - Example:
    <div role="log" aria-live="polite">New message from John: Hello there!</div>

Using role="progressbar"
  - Purpose: To indicate the progress of an operation, such as a file upload or download.
  - Usage: Apply `role="progressbar"` to an element representing progress, often with `aria-valuenow`, `aria-valuemin`, and `aria-valuemax` attributes.
  - Example:
    <div role="progressbar" aria-valuenow="75" aria-valuemin="0" aria-valuemax="100">75% complete</div>
  - Related Techniques: G193 (Providing help by an assistant in the web page).
```

--------------------------------

### WCAG 2.1 Technique: C39 - CSS reduce-motion

Source: https://www.w3.org/WAI/WCAG21/quickref

Uses the CSS 'prefers-reduced-motion' media query to prevent or reduce animations triggered by user interactions. This technique is crucial for users sensitive to motion.

```css
C39: Using the CSS reduce-motion query to prevent motion
```
Tokens:
Raw