To make this process intuitive, the active element must display a highly visible focus indicator, such as a thick, high-contrast outline. The system must also allow users to cancel the operation at any time by pressing the Escape key, which returns the label to its original position. ## Implementing ARIA Live Regions for Screen Readers Visual changes on the screen are not automatically communicated to screen reader users. When a user grabs, moves, or drops a label, the application must announce these actions dynamically using ARIA (Accessible Rich Internet Applications) live regions. An `aria-live` region set to "polite" or "assertive" should be used to broadcast status updates. Useful announcements include:
* **Selection:** "Label 'Earth' grabbed. Use arrow keys to navigate to a destination target." * **Movement:** "Target 'Third planet from the sun' focused." * **Completion:** "Label 'Earth' placed on 'Third planet from the sun'." * **Cancellation:** "Drag cancelled. 'Earth' returned to starting list." Additionally, draggable items and drop zones should use appropriate ARIA attributes, such as `aria-describedby`, to provide instructions on how to interact with the elements using a keyboard. ## The Button-Based Matching Alternative While keyboard-simulated drag-and-drop is possible, it is often complex to implement and prone to usability issues. A highly effective and simpler alternative is to provide a button-based or dropdown-based matching interface.
Instead of dragging: * Each label can feature a menu button or a dropdown select element next to it. * When activated, the menu lists all available drop zones. * The user selects the destination from the list, and the item is automatically moved to that location. This approach utilizes standard HTML form controls, which are natively accessible and work reliably across all browsers, screen readers, and mobile devices without requiring custom keyboard event listeners. ## Visual Contrast and Clear Instructions
Accessibility also includes supporting users with low vision or cognitive disabilities. * **Contrast:** Ensure that labels, drop zones, and text descriptions meet WCAG contrast ratios of at least 4.5:1 for normal text and 3:1 for graphical boundaries. * **No Color-Only Cues:** Do not rely solely on color changes (such as turning a border green for correct or red for incorrect) to convey success or failure. Use text labels, icons, or patterns to indicate status. * **Clear Instructions:** Provide explicit instructions at the beginning of the task explaining how to complete the labeling exercise using both a mouse and a keyboard. ## Testing and Verifying Accessibility To ensure the labeling task is fully accessible, developers should perform manual testing using only a keyboard and a screen reader.
* **Keyboard-Only Test:** Unplug the mouse and attempt to complete the entire labeling task using the Tab, Space, Enter, Arrow, and Escape keys. Ensure that the focus never gets trapped in a loop. * **Screen Reader Test:** Turn on a screen reader (such as NVDA on Windows, VoiceOver on macOS, or TalkBack on Android) and verify that all instructions, selected states, and drop actions are clearly announced. * **Zoom and Responsive Test:** Zoom the browser to 200% and check if the labels and drop zones remain readable and usable without overlapping.
