Demystifying Screen Readers: Accessible Forms & Best Practices

This is the third installment in our series on accessible web forms. If you missed the previous post, check out "Managing User Focus with :focus-visible." This article explores screen reader navigation within forms and outlines best practices for accessible form design.

Editor’s Note: This post has been updated to reflect current best practices and includes additional code examples. Your feedback is welcome!

Understanding Screen Readers

Screen readers are assistive technologies (AT) that translate digital text into audio or Braille. They are essential tools for visually impaired users. This guide uses Mac VO (VoiceOver) as an example, a built-in screen reader for Apple devices. The specific methods for activating and using VO may vary slightly depending on your device.

Activating VoiceOver on macOS

On newer MacBook Pros, activate VO by holding down the command key and quickly pressing the Touch ID three times. Older MacBook Pros (with a Touch Bar) use the shortcut cmd fn f5. For traditional keyboards, use the equivalent shortcut or enable VO through Accessibility settings. Upon activation, VO provides an introductory message.

You can navigate using a combination of tab, control, option, shift, and arrow keys, or utilize the VoiceOver Rotor for more direct navigation.

Modifier Keys in VoiceOver

The default VoiceOver modifier keys are control option, but this can be customized to caps lock or a combination of both.

Using the VoiceOver Rotor

Activate the Rotor using your modifier keys "U" (e.g., caps lock U). Use the left and right arrow keys to navigate through the different options.

Navigating by Heading Level

Navigate by heading level using your modifier keys cmd H. Use modifier keys shift cmd H to move back up the document structure.

Accessibility Best Practices for Web Forms

Web forms are fundamental to web interaction. Here are some best practices for creating accessible forms:

1. Explicit vs. Implicit Labels: While implicit labeling (using the for attribute to link labels and inputs) is acceptable, explicit labeling (<label>...</label>) is generally preferred for clarity.

<label for="name">Name:</label> <input type="text" id="name">

2. Required Fields: Use the required attribute for mandatory fields. Always provide a visual cue (e.g., an asterisk) to indicate required fields for all users.

<label for="email">Email (required):<span style="color:red">*</span></label> <input type="email" id="email" required>

3. Use Native HTML Buttons: Always use <button></button> elements for form submission; avoid using divs styled as buttons.

Demo and Resources

For a code example, visit the VoiceOver Demo GitHub repo. A live demo using VoiceOver is available at Navigating a Web Form with VoiceOver.

Screen Reader Software Options

• NVDA: A free and open-source screen reader for Windows.
• JAWS: A popular commercial screen reader for Windows.
• Narrator: A built-in screen reader for Windows 11.
• Orca: A screen reader for GNOME-based Linux distributions.
• TalkBack: The built-in screen reader for Android.

Browser and Screen Reader Compatibility

For information on browser support for HTML elements and ARIA attributes, consult caniuse.com and the Accessibility Support documentation for ARIA. Remember that screen reader compatibility depends on browser support. DigitalA11Y's article, "Screen Readers and Browsers! Which is the Best Combination for Accessibility Testing?" offers helpful insights.

Acknowledgements

Thanks to Adrian Roselli, Karl Groves, Todd Libby, Scott O’Hara, Kev Bonnett, and others for their contributions.

Further Reading

• Apple VoiceOver Support
• WAI-ARIA Authoring Practices
• WAI-ARIA in HTML
• Google TalkBack Support
• Understanding Screen Reader Interaction Modes
• Required Attribute Requirements

The above is the detailed content of Demystifying Screen Readers: Accessible Forms & Best Practices. For more information, please follow other related articles on the PHP Chinese website!