Understanding WCAG SC 1.4.2: Audio Control (A)

Section 1: Deconstructing Success Criterion 1.4.2: The Foundational Rules

Success Criterion 1.4.2 Audio Control is a fundamental component of digital accessibility, situated under Guideline 1.4, which aims to make content "Distinguishable." Its Level A conformance level signifies that it addresses a critical barrier that could prevent some users from accessing or using content at all. A thorough understanding begins with a precise, clause-by-clause analysis of its normative requirements and its special status within the WCAG framework.

1.1 The Normative Requirement: A Clause-by-Clause Analysis

The official text of WCAG SC 1.4.2 is concise but dense with meaning:

"If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level."

To apply this criterion correctly, each component of this statement must be clearly understood.

"Plays automatically"

This phrase refers to any audio that begins without being the direct result of an intentional user action. The key distinction lies in user intent. For example, if a user clicks a link or button clearly labeled "Play Video: The History of Computing," the subsequent audio playback is considered user-initiated. In contrast, audio that begins playing the moment a page finishes loading, such as background music or a narrated introduction, is "automatic." This distinction is paramount because it separates experiences the user has explicitly requested from those that are imposed upon them.

"More than 3 seconds"

This clause establishes a strict, testable temporal threshold. Audio that plays automatically but concludes entirely within three seconds is exempt from the requirement to provide a control mechanism. This allowance is for brief, non-intrusive sounds, such as a short notification chime or a quick sound effect on a splash page. However, if the audio lasts for even a fraction of a second longer than 3.0 seconds, the criterion's requirements are fully triggered. It is also critical that such short sounds do not loop; a two-second sound that loops would quickly exceed the three-second limit and thus fail the criterion if no controls are present.

"Mechanism is available to pause or stop"

This is the first of two distinct paths to conformance. It requires the presence of a user-operable control that can halt the audio playback. The term "mechanism" is defined broadly as a "process or technique for achieving a result," which can be provided directly in the content (e.g., a button) or by the user agent or assistive technology. For web content, this almost always means an explicit control provided by the author.

Crucially, the official guidance clarifies that relying on the user to mute their entire operating system's volume is not a valid mechanism. This is because many assistive technologies, most notably screen readers, use the same system volume channel. Muting the system would silence not only the unwanted background audio but also the assistive technology the user relies on for navigation, thereby creating an even greater barrier.

"Mechanism is available to control audio volume independently"

This clause provides the second, alternative path to compliance. Instead of a pause or stop button, a developer can provide a volume control that is independent of the overall system volume. This allows a user to specifically reduce the volume of the page's audio without affecting the volume of their screen reader or other applications. This control must include the ability to reduce the volume to zero, effectively muting the sound. While both pause/stop and volume control are technically compliant options, the former is a more direct and often more effective solution to the primary problem of auditory interference. A pause or stop control immediately eliminates the source of the distraction, whereas a volume control requires the user to perform a more nuanced action—such as locating and manipulating a slider—while the interfering audio continues to play.

1.2 The Principle of Non-Interference (Conformance Requirement 5)

SC 1.4.2 is one of only four Level A success criteria designated as affecting "non-interference" under Conformance Requirement 5. The other three are SC 2.1.2 (No Keyboard Trap), SC 2.3.1 (Three Flashes or Below Threshold), and SC 2.2.2 (Pause, Stop, Hide).

This special designation means that a failure of SC 1.4.2 on any content on a web page, regardless of whether that content is used to meet other success criteria, constitutes a failure for the entire page. For example, if the main content of a news article is perfectly accessible, but an embedded third-party advertisement plays uncontrollable audio for more than three seconds, the entire news article page fails to conform to WCAG.

The rationale for this stringent requirement is that the barrier created by uncontrollable audio is so profound that it can prevent a user from perceiving, operating, or understanding any other part of the page. The audio interferes with the user's ability to use the page as a whole, making it a page-level failure. This elevates the importance of SC 1.4.2 beyond a simple component-level check to a fundamental prerequisite for a page's overall accessibility.

Section 2: The Human-Centric Rationale: Why Audio Control is Essential

While the technical requirements of SC 1.4.2 are precise, its true significance lies in the human barriers it is designed to dismantle. The criterion is not an arbitrary rule but a direct response to the severe, and often insurmountable, challenges that automatically playing audio creates for a diverse range of users. Understanding these human factors is critical for developers and designers aiming for meaningful, rather than merely technical, compliance.

2.1 The Primary Barrier: Screen Reader Interference

The principal motivation behind SC 1.4.2 is to prevent interference with screen reading software, the essential assistive technology used by people who are blind or have low vision. A screen reader conveys the content and structure of a web page through synthesized speech or a refreshable braille display. Its users navigate by listening to this output.

When a web page loads and immediately begins playing audio—be it background music, a video soundtrack, or a narration—it creates a competing auditory stream. This directly masks the screen reader's speech, a disorienting experience described by users as "absolute chaos". The user is caught in a debilitating accessibility trap: the very tool they use to navigate is rendered useless by the sound, preventing them from hearing the announcements that would lead them to the control needed to stop that sound. They are effectively locked out of the page, unable to navigate, understand content, or perform any actions.

This problem is critically exacerbated by the fact that most software-based screen readers share the same audio channel as the browser. A user cannot simply turn down the "background" sound using their system volume controls without also silencing their screen reader. This is why the criterion's requirement for a control independent of the system volume is non-negotiable.

2.2 Cognitive and Sensory Impact

The negative impact of autoplaying audio extends far beyond screen reader users. It poses a significant barrier for individuals with a range of cognitive and neurological conditions.

For users with cognitive disabilities such as Attention-Deficit/Hyperactivity Disorder (ADHD) or other learning disabilities, unexpected audio can be intensely distracting, making it difficult or impossible to focus on and comprehend the page's primary content. Research has shown that a single distraction can derail concentration for over 20 minutes, effectively destroying the user's ability to complete their intended task.

For individuals with sensory sensitivities, including those on the autism spectrum or with Post-Traumatic Stress Disorder (PTSD), a sudden, unexpected blast of sound can be jarring, overwhelming, and trigger sensory overload or anxiety, making the web experience uncomfortable or even distressing.

The scientific literature on the cognitive effects of background audio adds a layer of important nuance. While some studies have explored potential memory benefits from background music, the results are highly inconsistent and depend heavily on factors like the music's tempo and arousal level, the complexity of the cognitive task, and, most importantly, individual preference and mood regulation. Some research indicates improved performance in certain tasks, while other studies show that background music can be detrimental, especially when cognitive resources are limited. This scientific ambiguity reinforces the core principle of SC 1.4.2: because the effect of audio is so personal and context-dependent, the control to play it must reside with the user. The user is the only one who can know their current cognitive state, environment, and whether the audio will be a help or a hindrance.

2.3 Broader Usability and Inclusivity

The case against autoplaying audio is so strong that it transcends specific disability accommodations and becomes a principle of universal design. Adhering to SC 1.4.2 improves the experience for nearly every user in a variety of situations.

• Users who are hard of hearing: These individuals may have their system volume set high to hear their screen reader or other notifications. Unsolicited audio can be painfully loud, and competing sounds can make it impossible to distinguish speech or other important audio cues.
• Users in shared or quiet environments: A vast number of users browse the web in offices, libraries, on public transportation, or at home where others are sleeping. Unexpected audio is socially disruptive, unprofessional, and can be deeply embarrassing.
• Users with limited bandwidth or data plans: Autoplaying media consumes data without the user's explicit consent, which can be costly for those on metered connections.
• General User Experience: The overwhelming consensus among usability experts and users alike is that autoplaying audio is an intrusive, unwelcome, and annoying design pattern. It violates the user's sense of control and can cause them to abandon a site in frustration.

Ultimately, the accessibility requirements outlined in SC 1.4.2 align perfectly with best practices for user experience design. By giving users control over audio, developers are not just complying with a standard; they are creating a more respectful, predictable, and usable experience for everyone. This makes the case for compliance not only a legal and ethical imperative but also a sound business decision that fosters user trust and satisfaction.

Section 3: Technical Pathways to Conformance

Achieving conformance with SC 1.4.2 involves a clear set of technical strategies. The Web Content Accessibility Guidelines (WCAG) provide several "Sufficient Techniques," which are recognized methods for meeting the criterion's requirements. These techniques are not of equal value from a user experience perspective; there is a clear hierarchy of preference that developers should follow to create the most accessible and user-friendly products.

3.1 The Gold Standard: User-Initiated Playback (G171)

The most robust, user-centric, and highly recommended technique for conformance is to avoid autoplay entirely. Technique G171: Playing sounds only on user request ensures that audio begins only when a user performs an explicit action, such as clicking a "Play" button.

This approach is superior because it solves the accessibility problem at its root. It completely eliminates the risk of auditory masking for screen reader users and prevents the "race" to find a control mechanism before the page becomes unusable. The user is in full control from the outset, having already focused on the media element and expressed a clear intent to engage with it.

Technically, this is the simplest method to implement. It requires the developer to simply omit the autoplay attribute from the HTML <audio> or <video> element.

<audio controls src="podcast-episode.mp3">
  <p>Your browser does not support the audio element.</p>
</audio>

3.2 Implementing Compliant Controls

When autoplay is a firm project requirement, the criterion mandates the provision of a control mechanism. There are two primary ways to implement this: using the browser's native controls or building custom controls with JavaScript.

HTML5 Native Controls

The simplest way to provide a mechanism is to use the controls boolean attribute on the <audio> or <video> element.

<audio autoplay controls src="background-music.mp3">
  <p>Your browser does not support the audio element.</p>
</audio>

When the controls attribute is present, the browser renders its default user interface, which typically includes a play/pause button, a volume control, and a seek bar. This satisfies the letter of SC 1.4.2. However, this approach has significant accessibility and usability limitations:

1. Keyboard Accessibility: Native media controls are notoriously inconsistent in their keyboard support across different browsers. In many cases, a user cannot use the Tab key to move focus to the individual buttons (play, mute, etc.) within the player, making them inoperable for keyboard-only users.
2. Styling and Discoverability: Native controls cannot be styled with CSS. They may not align with the website's design, and their default appearance may have poor color contrast or be too small to be easily discoverable and operable by users with low vision or motor impairments.

Accessible Custom Controls with JavaScript

For a more robust and accessible solution, developers should create their own controls using standard HTML elements and JavaScript's HTML Media Element API. This approach provides full control over functionality, appearance, and accessibility.

HTML Structure: The foundation is a set of semantic <button> elements. Buttons are natively focusable and can be activated with both Enter and Spacebar, ensuring keyboard accessibility from the start.

<audio id="audio-player" src="background-music.mp3" autoplay></audio>

<div class="custom-controls">
  <button id="play-pause-btn" type="button" aria-label="Pause Audio">Pause</button>
  <button id="stop-btn" type="button" aria-label="Stop Audio">Stop</button>
</div>

JavaScript Logic: The HTML Media Element API provides methods like play(), pause(), and properties like currentTime to control the media playback.

// JavaScript for custom audio player controls  
const audioPlayer = document.getElementById('audio-player');  
const playPauseBtn = document.getElementById('play-pause-btn');  
const stopBtn = document.getElementById('stop-btn');

playPauseBtn.addEventListener('click', () => {  
  if (audioPlayer.paused) {  
    audioPlayer.play();  
    playPauseBtn.textContent = 'Pause';  
    playPauseBtn.setAttribute('aria-label', 'Pause Audio');  
  } else {  
    audioPlayer.pause();  
    playPauseBtn.textContent = 'Play';  
    playPauseBtn.setAttribute('aria-label', 'Play Audio');  
  }  
});

stopBtn.addEventListener('click', () => {  
  audioPlayer.pause();  
  audioPlayer.currentTime = 0;
  playPauseBtn.textContent = 'Play';
  playPauseBtn.setAttribute('aria-label', 'Play Audio');
});

Accessibility Enhancements: This custom approach allows for crucial accessibility improvements. In the example above, the button's text content and aria-label are dynamically updated to reflect its current state (e.g., changing from "Pause" to "Play"). This provides clear feedback to all users, including those relying on screen readers, about the function of the control at any given moment. If icons were used instead of text, the aria-label would be essential for screen reader users.

3.3 The Three-Second Exception (G60)

Technique G60: Playing a sound that turns off automatically within three seconds provides a narrow exception for very short, non-looping audio clips. This is suitable for brief auditory feedback, such as a confirmation sound after a form submission, but is generally inappropriate for any substantive content or music. Even if brief, developers should consider that any unexpected sound can be startling or disruptive, and this technique should be used with caution.

3.4 Providing Discoverable Mechanisms (G170)

If audio must autoplay for longer than three seconds, technique G170: Providing a control near the beginning of the Web page that turns off sounds that play automatically is critical. This guidance directly addresses the screen reader user's dilemma. By placing the control at or near the top of the document's source order, it becomes one of the first interactive elements a user encounters when navigating from the top of the page. This allows them to quickly find and activate the control to silence the audio before it becomes an insurmountable barrier to further navigation. A common implementation is a simple link at the top of the page labeled "Turn off sound" or "Silent mode".

In summary, while several paths to technical conformance exist, they form a clear hierarchy of user-friendliness. The best practice is to avoid autoplay altogether (G171). If autoplay is unavoidable, a discoverable and fully accessible custom control should be provided (G170). The three-second exception (G60) should be reserved for minimal, non-essential sound effects only.

Section 4: Documented Failures and Anti-Patterns

Understanding how to conform to SC 1.4.2 is as important as understanding how to fail it. The WCAG provides documented "Common Failures" which describe specific anti-patterns that violate the success criterion. For SC 1.4.2, two failures are particularly relevant: a general failure condition and a more specific failure related to modern HTML5. Recognizing these anti-patterns is essential for developers and auditors.

4.1 F23: The General Failure

F23: Failure of 1.4.2 due to playing a sound longer than 3 seconds where there is no mechanism to turn it off is the broadest and most fundamental failure of this criterion. It applies to any technology that can produce audio on a web page, including older technologies like Flash or Silverlight, as well as modern HTML5.

This failure occurs when two conditions are met simultaneously:

1. Audio begins playing automatically upon page load.
2. The audio continues for more than three seconds, and there is no user-operable mechanism provided on the page to pause, stop, or independently control its volume.

Classic examples of this failure include:

• A website that plays continuous background music with no on-screen controls.
• A corporate homepage with a narrated introductory video that starts automatically and cannot be stopped or paused by the user.

The existence of this general, technology-agnostic failure underscores the long-standing nature of this accessibility principle. The problem of unexpected audio predates modern web standards, and F23 serves as a catch-all for any implementation that violates the core requirement of user control.

4.2 F93: The HTML5 Autoplay Failure

As the web has evolved, so have the specific ways in which accessibility barriers are created. F93: Failure of Success Criterion 1.4.2 for absence of a way to pause or stop an HTML5 media element that autoplays is a more modern and specific failure that directly addresses the features of the HTML5 specification.

This failure occurs when an HTML5 <audio> or <video> element is implemented with the autoplay attribute but without a corresponding control mechanism. The presence of F93 in addition to the more general F23 reflects the standardization of the autoplay attribute in HTML5, which made this particular anti-pattern a common and predictable source of accessibility issues.

A typical implementation that triggers this failure looks like this:

<video src="advertisement.mp4" autoplay loop></video>

In this example, the autoplay attribute instructs the browser to begin playback as soon as possible. Because the loop attribute is also present, the media will play indefinitely, far exceeding the three-second threshold. Crucially, there is no controls attribute to enable the browser's native player interface, nor are there any custom JavaScript-powered buttons to give the user control. This code creates a direct and clear violation of SC 1.4.2.

It is important to distinguish this from a common and acceptable use case for background videos. The following code does not fail SC 1.4.2:

<video src="decorative-background.mp4" autoplay loop muted></video>

In this case, the muted attribute is present. This instructs the browser to play the video without any sound. Since no audio is playing automatically, SC 1.4.2 is not triggered and therefore not failed. This pattern is widely used for decorative background videos and is considered an accessible practice as long as the video does not convey essential information visually without a text alternative.

The specificity of F93 serves as a reminder that as web technologies evolve, accessibility standards must also adapt to provide clear guidance on the proper use of new features and to guard against their potential for misuse.

Section 5: A Comprehensive Testing Methodology

Verifying conformance with SC 1.4.2 requires a hybrid approach that combines the efficiency of automated tools with the nuance of manual, human-led evaluation. Automated tools can flag potential issues, but only manual testing can confirm the true user experience and ensure that control mechanisms are not only present but also genuinely usable.

5.1 The Role of Automated Testing

Automated accessibility scanning engines, such as axe-core (which powers tools like Deque's axe DevTools, Google Lighthouse, and Microsoft's Accessibility Insights), play a valuable role in the initial phase of testing.

These tools are highly effective at parsing the DOM and identifying high-risk code patterns. For SC 1.4.2, their primary function is to detect <audio> and <video> elements that have the autoplay attribute but lack the muted attribute. The no-autoplay-audio rule in axe-core, for example, is specifically designed to flag this condition. This provides an immediate, actionable signal to developers and auditors that a component requires further investigation.

However, the limitations of automation must be clearly understood. An automated tool can confirm the presence of a controls attribute, but it cannot verify:

• Whether a custom JavaScript-based control is fully keyboard accessible.
• Whether the control is placed in a logical and easily discoverable location in the DOM.
• Whether the audio actually stops playing for more than three seconds in practice.
• Whether the control provides an adequate accessible name for screen reader users.

Data from comprehensive audits shows that automated testing, while powerful, can only identify a portion of all accessibility issues. Therefore, its results should be treated as a starting point for a more thorough manual review, not as a final verdict on conformance.

5.2 Essential Manual Verification: A Step-by-Step Checklist

A robust manual testing process is non-negotiable for validating SC 1.4.2. This process must go beyond simple visual checks and simulate the experiences of users with different disabilities, particularly those who rely on keyboard-only navigation and screen readers. The following checklist provides a structured approach for manual auditors.

1. Discovery and Initial Observation:

• Load the web page in a clean browser profile to ensure no prior settings (like site-specific muting) interfere with the test.
• Listen carefully as the page loads. Does any audio begin playing without any interaction from you? If no audio plays automatically, SC 1.4.2 does not apply, and the test for this criterion passes.

2. Duration Check:

• If audio does start automatically, use a stopwatch or a timer.
• Time the duration of the audio playback. Does it stop completely on its own at or before the 3.0-second mark?
• Verify that the audio does not loop. If it stops within three seconds and does not loop, it conforms via technique G60.

3. Control Identification and Functionality:

• If the audio continues for more than three seconds, visually inspect the page for any apparent controls (e.g., a media player interface, a "Mute" button, a "Stop Music" link).
• Interact with the identified control using a mouse. Does it work as expected? Does the audio pause, stop, or does the volume control function correctly and allow muting?

4. Keyboard Accessibility Audit:

• Return the page to its initial state (e.g., by reloading).
• Put your mouse aside. Navigate the page from the very top using only the keyboard.
  • Use Tab to move forward to the next focusable element.
  • Use Shift+Tab to move backward.
• As you tab through the page, observe the following:
  • Discoverability: Can you reach the audio control via the Tab key? Is it located early in the tab order, ideally before the main page content, so it can be accessed quickly?
  • Focus Visibility: When the control receives focus, is there a highly visible focus indicator (e.g., an outline)? The focus must be clearly visible at all times.
  • Operability: Once the control is focused, can you activate it using Enter or Spacebar? Does activating it successfully pause, stop, or mute the audio?
  • No Keyboard Traps: After interacting with the control, can you tab away from it to continue navigating the rest of the page?

5. Screen Reader Experience Simulation:

• This is the most critical step, as it directly tests the primary intent of the criterion.
• Activate a screen reader (such as NVDA on Windows or VoiceOver on macOS) before loading the page.
• Load the page and listen to the combined output of the autoplaying audio and the screen reader's speech.
• Attempt to perform the following tasks:
  • Intelligibility: Is the screen reader's speech comprehensible over the background audio, or is it completely masked?
  • Navigation and Identification: Use standard screen reader navigation commands (e.g., tabbing between focusable elements, using arrow keys to read content) to find the audio control. Does the screen reader announce the control's name and role clearly (e.g., "Pause, button")?
  • Operation: Can you activate the control using the screen reader's interaction commands? Does this successfully silence the audio, allowing you to hear the screen reader clearly again?

A failure at any stage of this manual process, particularly in the keyboard and screen reader tests, indicates a failure to conform to SC 1.4.2. This sense-based testing approach, which requires the auditor to actually listen to the user experience, is the only way to verify that the spirit, and not just the letter, of the guideline has been met.

Section 6: Contextualizing SC 1.4.2 in the Accessibility Landscape

Success Criterion 1.4.2 does not exist in a vacuum. To apply it effectively, one must understand its relationship to other WCAG criteria and its place within the evolving ecosystem of web browsers and user agent policies. Two key areas of context are its distinction from the visually-focused SC 2.2.2 and its interaction with modern browser autoplay-blocking features.

6.1 Comparison with Related Criteria: SC 1.4.2 vs. SC 2.2.2

A common point of confusion for developers and testers is the distinction between SC 1.4.2 (Audio Control) and SC 2.2.2 (Pause, Stop, Hide). Both are Level A criteria, both fall under the "Non-Interference" conformance requirement, and both deal with content that starts automatically. However, their scopes, thresholds, and primary intents are entirely different. Misunderstanding these differences can lead to incorrect implementation—for example, mistakenly applying the five-second rule from SC 2.2.2 to an audio element.

The following table provides a clear, side-by-side comparison to disambiguate these two critical criteria.

This table clarifies that SC 1.4.2 is exclusively for auditory content, while SC 2.2.2 is for visual content. They address different sensory modalities and have distinct time limits and required controls.

6.2 The Influence of Modern Browser Autoplay Policies

In recent years, major web browsers like Google Chrome, Mozilla Firefox, and Apple Safari have implemented their own increasingly strict policies to block or limit the automatic playback of media with sound. These policies are a direct response to the widespread user frustration with intrusive autoplaying content.

For example, Chrome's autoplay policy is based on a Media Engagement Index (MEI). This score tracks a user's history of media interaction on a given site. Autoplay with sound is generally blocked unless the user has demonstrated a pattern of playing media on that site, or if they have installed the site as a Progressive Web App (PWA). Muted autoplay is almost always allowed.

While these browser-level interventions are a positive step for user experience, it is a critical error for developers to rely on them as a substitute for WCAG conformance. The responsibility to meet SC 1.4.2 rests with the content author, not the user agent. There are several reasons for this:

1. Inconsistency: Browser policies are not standardized. They differ between browsers and can change at any time with a new software update.
2. User Overrides: Users can often change browser settings or grant permissions that allow autoplay on specific sites, in which case the browser's protection is removed.
3. Author Intent: The presence of the autoplay attribute in the HTML code is a clear expression of the author's intent to play audio automatically. WCAG evaluates the content as authored. If the author's code requests autoplay, it must also provide the required control mechanism, regardless of whether a particular browser chooses to honor that request in a given context.

The relationship between WCAG and browser policies can be seen as a "belt and suspenders" model of user protection. WCAG conformance is the "belt"—the fundamental, non-negotiable standard that ensures the content itself is accessible. Browser policies are the "suspenders"—an additional, helpful layer of protection provided by the user agent. A robust and responsible implementation accounts for both, ensuring that the web content is accessible by design, not by chance based on a user's browser choice.

Conclusion

WCAG Success Criterion 1.4.2 Audio Control stands as a pillar of accessible web design, embodying the core principle that users must have ultimate control over their experience. Its requirements, though technically straightforward, are rooted in a deep understanding of the profound barriers that unsolicited audio can create. For screen reader users, uncontrolled audio is not a mere annoyance but a complete blocker to access, rendering a page unusable. For individuals with cognitive and sensory disabilities, it is a significant source of distraction and distress.

This analysis has demonstrated that conformance is not a matter of choosing one of several equal options, but of following a clear hierarchy of best practices. The gold standard is to cede control to the user from the outset by making all audio playback user-initiated (G171). When autoplay is an absolute requirement, the provision of a discoverable, fully keyboard-accessible, and programmatically clear control mechanism is non-negotiable (G170).

Furthermore, robust conformance demands a rigorous, hybrid testing methodology. While automated tools provide an essential first pass by flagging risky code patterns like the autoplay attribute, they are insufficient on their own. Only through meticulous manual testing—navigating with a keyboard and, most critically, simulating the experience with a screen reader—can an organization truly verify that its implementation is not just technically compliant but functionally accessible.

Finally, while modern browser policies that block autoplay are a welcome advancement for overall user experience, they are a supplement to, not a substitute for, an author's responsibility under WCAG. The standard judges the content itself, ensuring a baseline of accessibility that is independent of the shifting landscape of user agent features. By embracing the human-centric rationale behind SC 1.4.2 and implementing its requirements thoughtfully, developers and designers do more than meet a line item on a checklist; they create a more respectful, predictable, and inclusive digital world for everyone.