DOCSEARCHbyAlgolia
Submit Docs

Actum Digital Accessibility Documentation

website·Indexed 34 days ago

https://accessibility.actumdigital.com/

Guidelines and resources for web accessibility, featuring detailed documentation on WCAG (Web Content Accessibility Guidelines) criteria, user preferences for color mode and font size, and a catalog of inaccessible components—including Modals, Accordions, Tabs, and Forms—to demonstrate common accessibility issues and their considerations.

Tokens
22.8K
Snippets
26
Records
155
Agent score
58%

What's inside Actum Digital Accessibility

  1. Implement programmatic input purpose for form accessibility

    To comply with WCAG 1.3.5, input fields that collect information about the user must be programmatically determinable. Providing only a <label> or a generic type attribute (like type="text") is insufficient. You must use the autocomplete attribute with a valid token to allow browsers and assistive technologies to provide autofill and custom iconography.

    Key Constraints:

    • Use the autocomplete attribute specifically for the user's own personal information.
    • Do not use autocomplete for fields collecting information about other people (e.g., guest email addresses in an invitation form).
    • Use kebab-case values (e.g., family-name) rather than camelCase (e.g., familyName).
    <!-- Correct Implementation -->
<label for="first-name">First Name</label>
<input autocomplete="given-name" type="text" id="first-name">

<label for="last-name">Last Name</label>
<input autocomplete="family-name" type="text" id="last-name">

  2. Learn web accessibility through Inaccessible Components

    The Inaccessible Components project provides a set of common web components (such as Accordions, Modals, and Tabs) to demonstrate frequent accessibility and usability issues. By comparing inaccessible versions with accessible versions, developers can learn both the 'what to do' and 'what not to do' when coding for accessibility. Each component example includes code for both versions, a description of the specific accessibility issues, and additional usability considerations.

  3. Understand WCAG Principles and Conformance Levels

    The Web Content Accessibility Guidelines (WCAG) are organized into four main principles that define how web content should be designed to be accessible:

    1. Perceivable: Information and UI components must be presentable to users in ways they can perceive.
    2. Operable: User interface components and navigation must be operable.
    3. Understandable: Information and the operation of the user interface must be understandable.
    4. Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.

    Conformance is measured by Success Criteria, which are categorized into three levels of increasing difficulty:

    • Level A: Essential standards. Failure to meet these often results in serious accessibility barriers that make a site impossible for some users to use.
    • Level AA: The recommended minimum standard for most websites to ensure accessibility for a wide range of users.
    • Level AAA: The highest level of conformance. While not always achievable for all content due to resource constraints, some criteria are applicable to most sites.

  4. Implement Audio Descriptions for Prerecorded Media (WCAG 1.2.5 AA)

    To meet WCAG Level AA conformance for Success Criterion 1.2.5, you must provide audio descriptions for all prerecorded synchronized media. This ensures that people who are blind or visually impaired can understand the visual information presented in the media. Unlike Level A (1.2.3), which allows a choice between a transcript or an audio description, Level AA explicitly requires the audio description.

  5. Implement WCAG Operable Guidelines

    The 'Operable' principle ensures that users can navigate and interact with the interface. Key guidelines include:

    • Keyboard Accessible (2.1): Ensure all functionality is available via keyboard without traps.
    • Enough Time (2.2): Provide users sufficient time to read and use content (e.g., adjustable timing, pausing auto-updating content).
    • Seizures and Physical Reactions (2.3): Avoid designs known to cause seizures, such as excessive flashing.
    • Navigable (2.4): Provide ways to help users find content and determine their location (e.g., page titles, focus order, and bypass blocks).
    • Input Modalities (2.5): Ensure functionality is operable through various inputs beyond just the keyboard.

  6. Provide alternatives for prerecorded audio-only content

    For prerecorded audio-only content (such as podcasts, speeches, or songs), provide a text transcript that conveys the same information as the audio. The transcript should include identified speakers (if there is more than one), all dialogues, and important sound effects. Timestamps should be included where necessary. The transcript should be placed as close as possible to the media content or linked directly.
    <audio>
  <source src="track.mp3" type="audio">
</audio>

<h3>Transcript</h3>
<p>[00:00:00] (John) Hello! In this video, we will cover keyboard access and visual focus.</p>
<p>[00:00:05] Many people cannot use a mouse and rely on the keyboard to interact with web content.</p>

  7. Implement accessible Card interaction and structure

    Follow these best practices to improve the accessibility of Card components:

    • Clickable Cards: To make a whole card clickable while maintaining a single semantic link, use a pseudo-element overlay on a single link. Note: Be aware that this may make text unselectable unless position: relative is applied to the text, though that may limit the clickable area.
    • Grouping Cards: When displaying multiple cards, wrap them in a list (<ul> and <li>). This allows screen readers to automatically announce the total number of cards to the user.
    • Visual Cues: Implement hover effects to help sighted mouse users identify that the card is interactive.
    • Heading Hierarchy: Ensure heading levels (e.g., <h3>, <h4>) are used logically based on the page's overall structure rather than hard-coding them into the component.

  8. Avoid common accessibility pitfalls in form styling and UX

    Ensure that form field borders and description text have sufficient color contrast against the background for low-vision users. Avoid using fixed widths on forms to prevent horizontal scrollbars on small viewports, which hinders users of screen magnification. When marking required fields, provide a clear explanation of the asterisk (*) symbol or explicitly include the word '(required)' within the label.

  9. Guidelines for Creating Accessible Captions

    When creating captions for synchronized media, follow these constraints:

    • Simplification: Captions may simplify spoken text to improve readability or reading speed; they do not need to be a verbatim transcript.
    • Information Scope: Captions must not introduce new information that is not present in the media itself.
    • Completeness: If the audio is muted, no important auditory content should be missed.

  10. Implement WCAG 1.2.9 Audio-only (Live) AAA compliance

    To meet the Level AAA requirement for live audio (real-time streaming such as live podcasts, sports events, news, auctions, or speeches), you must provide a text alternative for the information conveyed.

    Recommended Implementation:

    • Live Captions: This is the preferred method because spoken content often deviates from a pre-written script or varies in pace.
    • Transcripts: May be used if the live audio follows a strict script, but is generally less effective than live captions for real-time events.

    Compliance Constraints:

    • Providing a transcript that differs significantly from the actual live events does not meet this criterion.
    • Using captioning operators without adequate training to ensure accuracy may result in failure to meet this criterion.

  11. Implement accessible form field labels and descriptions

    Every form field must be associated with a <label> element to provide an accessible name and allow mouse users to focus the field by clicking the label. For additional instructions or descriptions, use the aria-describedby attribute to programmatically link the form field to its description text; otherwise, screen readers in 'forms' mode may ignore the description.

  12. Optimize Tab panel focus and structure

    • Panel Focus: If a tab panel contains no focusable elements (like links or buttons), add tabindex="0" to the tab panel itself so screen reader users don't miss the content.
    • Element Choice: Depending on the importance and amount of content, consider implementing tabs as buttons or anchor links instead of generic divs.
    <!-- Make the panel focusable if it contains no interactive elements -->
<div role="tabpanel" tabindex="0">...</div>