Accessibility Fixes: Search Modal Input Rework

by Alex Johnson 47 views

Introduction

In this article, we'll delve into the details of the proposed rework for the search modal input on the SocialGouv's code-du-travail-numerique platform. The primary focus is on enhancing accessibility to ensure a better user experience for everyone, including individuals using screen readers and other assistive technologies. We'll explore the issues identified, the steps to reproduce them, and the expected outcomes after implementing the suggested improvements. These improvements not only aim to fix current accessibility shortcomings but also align the platform with best practices for inclusive design.

Problem Statement

The current implementation of the search modal input has several accessibility issues that need to be addressed. These issues include missing aria attributes, improper labeling, focus management problems, and insufficient contrast for focus states. Addressing these concerns is vital to ensure that all users, regardless of their abilities, can effectively use the search functionality.

Key Accessibility Issues

  1. Incorrect aria Attributes: The role="combobox" and aria-expanded attributes are placed on the parent div instead of the input element itself.
  2. Unlinked Label: The visible label, "Que souhaitez vous savoir" (What do you want to know), is not properly linked to the input field.
  3. Unlinked Helper Text: The helper texts, such as "par exemple : Comment sont comptés les congés pendant les arrêts maladies ?" (for example: How are leaves counted during sick leave?) and "Tapez 3 caractères ou plus pour lancer une recherche" (Type 3 or more characters to start a search), are not associated with the input field.
  4. Focus Management: After validating a search result by pressing Enter, the focus shifts to the first displayed link, skipping the displayed title. This can disorient users, especially those relying on keyboard navigation.
  5. Insufficient Focus Contrast: The focus state on the dropdown list options lacks sufficient contrast, making it difficult for users with low vision to identify the currently focused element.
  6. Screen Reader Issue: The message within the <div role="status" aria-live="polite"> is not read by screen readers upon its appearance.

Steps to Reproduce

To reproduce these accessibility issues, follow these steps:

  1. Navigate to https://code-du-travail-numerique-linked-new-search-page-4cp392js.ovh.fabrique.social.gouv.fr/?pk_ab_test=search_v2.
  2. Open the search modal.
  3. Inspect the search field and its label.
  4. Enter a search term (e.g., "congés") and press Enter. Observe where the focus shifts.
  5. Enter a non-existent search term (e.g., "fhejefhjkzehfzeklhfzj") and press Enter. Again, note where the focus moves.
  6. Type the first three letters of a search term and use the keyboard to navigate through the suggestion options.

By following these steps, developers and testers can directly observe the identified accessibility issues and verify the effectiveness of the proposed solutions.

Expected Results

The following improvements are expected to resolve the accessibility issues:

  1. aria Attributes on Input: Add role="combobox" and aria-expanded="[true/false]" attributes to the input element. The value of aria-expanded should dynamically update to true when the suggestion list is displayed and false when it is hidden. Also, include aria-describedby="XX", where "XX" is the id of the <p> element containing the helper messages.
  2. Label Association: Wrap the <h1> and <p> elements within a <label for="modal-search-autocomplete"> element. Ensure that the for attribute matches the id of the input. Add an id to this label and update the aria-labelledby attribute on the listbox accordingly.
  3. Remove Redundant Attributes: Remove the role="combobox", aria-expanded="false", aria-haspopup="listbox", and aria-labelledby="modal-search-autocomplete-label" attributes from the parent div.
  4. SR-Only Label: Decide whether to keep or remove the sr-only (screen reader only) label "rechercher" (search). If retained, it should be placed before the <h1> within the label.
  5. Focus Management: When the user presses Enter in the input field or selects an option, the focus should move to the "Cela pourrait vous intéresser" (You might be interested in) title. If the message "Précisez votre saisie, aucun résultat disponible." (Refine your input, no results available) appears, the focus should remain on the input field.
  6. Focus Contrast: Ensure that the focus state on the list options has sufficient contrast (a ratio of 3:1 with the background and 4.5:1 with the text). If necessary, add another visual modification, such as bolding the text, to improve visibility.
  7. Screen Reader Announcements: The message within the <div role="status" aria-live="polite"> should be properly announced by screen readers. To achieve this, ensure the div is present and empty, and the message is injected into it. Additionally, using aria-live="polite" aria-atomic="true" is recommended for better support, or simply using role="status" alone.

Detailed Improvements Explained

To fully understand the impact of these changes, let's break down each improvement:

1. aria Attributes on Input

By placing the role="combobox" and aria-expanded attributes directly on the input element, we are explicitly defining the role of the input as a combobox. A combobox is a combination of a text input and a dropdown list, allowing users to either type in a value or select from a list of suggestions. The aria-expanded attribute indicates whether the list of suggestions is currently visible. Setting this attribute dynamically ensures that screen reader users are informed about the state of the combobox.

The aria-describedby attribute is used to associate the input field with descriptive text, such as instructions or error messages. By setting aria-describedby="XX", where "XX" is the id of the <p> element containing the helper messages, we are providing additional context to screen reader users. This helps them understand the purpose of the input field and any requirements for using it correctly. For instance, the message "Type 3 or more characters to start a search" can be directly associated with the input, providing clear guidance to the user.

2. Label Association

Properly associating a label with an input field is crucial for accessibility. The label provides a clear description of the input's purpose. By wrapping the <h1> and <p> elements within a <label for="modal-search-autocomplete"> element, we are visually and programmatically linking the label to the input. The for attribute of the label must match the id of the input. Additionally, adding an id to the label and updating the aria-labelledby attribute on the listbox ensures that the label is correctly announced by screen readers when the listbox is focused.

3. Remove Redundant Attributes

Redundant or misplaced aria attributes can cause confusion for screen reader users. By removing the role="combobox", aria-expanded="false", aria-haspopup="listbox", and aria-labelledby="modal-search-autocomplete-label" attributes from the parent div, we are ensuring that the aria attributes are correctly placed on the input element, where they are most effective.

4. SR-Only Label

The sr-only (screen reader only) label provides additional context to screen reader users without visually cluttering the interface. The decision to keep or remove the "rechercher" (search) label depends on whether it provides additional value to screen reader users. If retained, it should be placed before the <h1> within the label to ensure it is announced first.

5. Focus Management

Proper focus management is essential for keyboard navigation. When a user presses Enter in the input field or selects an option, the focus should move to the "Cela pourrait vous intéresser" (You might be interested in) title. This provides a clear indication that the search has been processed and that new content is available. If the message "Précisez votre saisie, aucun résultat disponible." (Refine your input, no results available) appears, the focus should remain on the input field, allowing the user to immediately refine their search.

6. Focus Contrast

The focus state on the list options must have sufficient contrast to be easily visible to users with low vision. The Web Content Accessibility Guidelines (WCAG) require a contrast ratio of 3:1 between the focus indicator and the background, and 4.5:1 between the text and the background. If the current focus state does not meet these requirements, additional visual modifications, such as bolding the text, should be added to improve visibility.

7. Screen Reader Announcements

For screen readers to announce the message within the <div role="status" aria-live="polite">, the div must be present and empty, and the message must be injected into it dynamically. This ensures that the screen reader detects the change in content and announces the message to the user. Additionally, using aria-live="polite" aria-atomic="true" is recommended for better support, as it ensures that the entire message is announced, even if it is updated multiple times in quick succession. Alternatively, using only role="status" is also a valid option.

Conclusion

By implementing these accessibility improvements, the search modal input on the code-du-travail-numerique platform will become more inclusive and usable for all users. Proper aria attributes, label associations, focus management, and sufficient contrast are essential for creating a seamless and accessible user experience. Regularly testing with screen readers and other assistive technologies is crucial to ensure that the platform remains accessible and meets the needs of all users.

For more information on web accessibility best practices, visit the Web Accessibility Initiative (WAI) website.