### 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: `...` * 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: `...` * 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 `` elements using the `alt` attribute. * Usage: `Description of image` * Applies to: All `` elements. 8. **H53: Using the body of the object element** * Purpose: To provide text alternatives within the `` element's `` for content that cannot be rendered. * Usage: `Text alternative for PDF` * Applies to: `` 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