Question 72552 in Reactjs Question posted in
The new location for the React Documentation can be found here.

Screenreader only reads first child component within a form but not all child components – Reactjs

I have a form like so:

<form {...props} tabIndex={0}>
    <ProgressBar />
    <FormTitle />
    props.questions.map(q => <Question {...q} />)
</form>

When the focus gets to the form element, screenreaders (e.g. VoiceOver on Mac) only seem to auto-read out the progress bar and then stop. I’m expecting that all the child components within the focused form would be auto-read out loud and then each individual input control read when tab navigating but perhaps that is an inaccurate understanding of screenreader focus.

When I tab navigate, the focus enters each input field within the form and bypasses the form title entirely. How do I get a form element-level focus to read out all child components?

Tags:

2

Answers


  1. 0

    You probably shouldn’t have a tabindex on the form in the first place. Forms aren’t generally interactive elements and you don’t need to make them interactive for screen reader user’s sake. Screen reader users have a variety of ways to navigate content on the page and do not need tab stops added to help them.

    Login or Signup to reply.
  2. 0

    The basic rule of keyboard accessibility is quite simple: all interactive elements and only interactive elements must be focusable, and elements that aren’t interactive shouldn’t be made focusable.

    Interactive means that you can have an interaction with the element, i.e. perform some action, do something with it.
    For example, button and links are interactive, as well as form fields. Something happens when you click on them or type in text when they have the focus.

    However, paragraphs aren’t interactive. The user doesn’t expect anything to happen when they are clicked on. Nor is a title such as <h1>, and nor a <form> element taken in its entirety.
    IN the case of the <form> element, you don’t interact with the form itself, but with its fields only. The fields are interactive, but not the form.

    Since the form itself isn’t interactive, it shouldn’t be focusable (you should remove your tabindex attribute).
    The screen reader doesn’t expect it either, so you shouldn’t be surprised if its behavior is totally unexpected, too. As always, garbage in, garbage out.

    More generally, you are making a quite common confusion between the situation of screen reader users vs. keyboard-only users.

    Screen reader users, who are blind, partially sighted, or have troubles reading text on the screen comfortably, have a list of various shortcuts to read through the page. Using tab is one of them, it’s very useful and important that it works correctly, but it isn’t the only navigation mean.
    There are common shortcuts to jump to the next heading to make it read from that point on, or the next form field for example; or, more simply, arrow keys allow to move a reading cursor like in a Word document, or sweeping the screen left and right allow to read elements one by one.
    Note, however, that the reading cursor in question here isn’t the same as the system focus, and this is precisely the root of many confusions and misconceptions.

    ON the other hand, keyboard-only users can only press tab to move between interactive elements. But they don’t need more navigation keys, as they can perfectly see the screen.
    They don’t need to somehow move a special reading cursor precisely onto a given element in order to read it. All they need is to focus elements that do something.
    Hence, focusing an element that does nothing is just a waste of time for them.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search