Making Disabled Elements Accessible: A Developers Guide

Shawn Sandy (Ally.Cafe) ~ July 10, 2024

Introduction

Disabled elements, such as buttons and other interactive UI components, indicate that certain actions are currently unavailable. Proper implementation of these elements is essential for accessibility, ensuring that all users, including those using screen readers and other assistive technologies, can understand the state of the element and the reason for its unavailability. This article guides you through relevant Web Content Accessibility Guidelines (WCAG) 2.2, best practices, and techniques for making disabled elements accessible.

Relevant WCAG 2.2 Guidelines

WCAG 2.2 provides several guidelines pertinent to the implementation of disabled elements:

Guideline 1.3 Adaptable: Create content that can be presented in different ways without losing information or structure.
- 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.
- 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.
Guideline 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.
- 2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context.
- 2.4.6 Headings and Labels: Headings and labels describe the topic or purpose.
Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.
- 4.1.2 Name, Role, Value: For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

Why Accessibility Matters for Disabled Elements

Disabled elements need to be accessible to ensure that all users, including those using assistive technologies, can understand the element’s state and why it is not currently available. If disabled elements are not properly implemented, users might become confused or frustrated, leading to a poor user experience.

Best Practices for Accessible Disabled Elements

Clear Visual Indicators: Ensure that disabled elements are visually distinct from enabled elements using differences in color, opacity, or additional icons.
Descriptive Text and ARIA Labels: Provide clear, concise reasons for why an element is disabled using ARIA labels or additional text.
Proper HTML Markup: Use appropriate HTML attributes like disabled for form controls and aria-disabled for other interactive elements.

For screen readers to accurately convey the state of a disabled element, proper use of HTML and ARIA attributes is essential. Here’s how you can implement accessible disabled elements:

Disabled Form Controls

For form controls like input fields, checkboxes, and buttons, use the disabled attribute:

<input type="text" disabled aria-label="Input is disabled because the form is incomplete" />

Disabled Non-Form Elements

For elements like links or custom buttons, use aria-disabled:

<a href="#" aria-disabled="true" tabindex="-1">Disabled Link</a>

Code Examples

Example 1: Disabled Form Control

<form>
  <label for="username">Username:</label>
  <input type="text" id="username" name="username" required>
  
  <label for="submit-button">Submit:</label>
  <button id="submit-button" type="submit" disabled aria-disabled="true" aria-describedby="submit-reason">Submit</button>
  <p id="submit-reason" style="display:none;">The submit button is disabled because the username is required.</p>
</form>

<script>
  const usernameInput = document.getElementById('username');
  const submitButton = document.getElementById('submit-button');
  const submitReason = document.getElementById('submit-reason');

  usernameInput.addEventListener('input', function() {
    if (usernameInput.value.trim() === '') {
      submitButton.disabled = true;
      submitButton.setAttribute('aria-disabled', 'true');
      submitReason.style.display = 'block';
    } else {
      submitButton.disabled = false;
      submitButton.setAttribute('aria-disabled', 'false');
      submitReason.style.display = 'none';
    }
  });
</script>

Example 2: Disabled Link

<a href="#" aria-disabled="true" tabindex="-1">Disabled Link</a>
<p id="link-reason" style="display:none;">This link is disabled because you need to complete the previous step.</p>

<script>
  const disabledLink = document.querySelector('a[aria-disabled="true"]');
  disabledLink.addEventListener('focus', function() {
    document.getElementById('link-reason').style.display = 'block';
  });
  
  disabledLink.addEventListener('blur', function() {
    document.getElementById('link-reason').style.display = 'none';
  });
</script>

Techniques and Failures

Sufficient Techniques:

ARIA Techniques: Using aria-disabled to indicate an element’s disabled state.
Text Description: Providing additional text to explain why the element is disabled.

Common Failures:

Relying on Color Alone: Using only color to indicate an element is disabled, which can be problematic for users with color vision deficiencies.
No Explanation: Failing to provide a reason for why an element is disabled.

Conclusion

Making disabled elements accessible is critical to ensuring a positive user experience for all users, including those relying on assistive technologies. By following WCAG 2.2 guidelines and best practices, you can create more inclusive and accessible web applications.

For more information, you can refer to the following resources:

Found an error, typo, or bug please edit on github or open an issue or ticket

Edit on Github Open an issue