(When) do screen reader users use tabs?

So first of all you are confusing tabbing with focus. While a screen reader user may use arrow key navigation, they may also bring up a list of links on the page, or forms, regions, tables or (most often) headings in order to navigate to sections that interest them / get a feel for the page layout.

Tabbing is useful as there are plenty of people who cannot, struggle or prefer not to use a mouse but do not require the assistance of a screen reader i.e. Cerebral Palsy due to accuracy issues.

Hopefully that clears that bit up for you.

As for autofocusing an input on a multi-page form, that is more of a UX issue...is it good UX for all users if you auto-focus the form.

I would say yes, requiring people to click, tab or use shortcuts to get to the input if that is going to be the action that 99% of people need to take is not good UX.

Notice I say the <input> and not the heading.

What you do want to do is look into how to indicate this is a multi-page and multi-step form on the first page of the process.

You should also consider having a checkbox as the first step that says something like "this form is multi-page, would you like us to auto-focus the first question when a new page is loaded" and have it default to checked.

That way someone has the choice to stop the auto focus if they wish.

Additionally (or as an alternative if you do not want the checkbox) you may consider adding some text near to the submit button (and properly associate it with aria-labelledby and an ID) that explains that the next step loads a new page and the first input will be auto focused.

Another thing is that assuming you have titled the pages correctly (Form name or process - step 2 of 5) then a screen reader user can easily ensure they are on the correct page.

So focus the input if this is a multi page form, not the heading level 1.

Focusing headings after navigation is a trick for Single Page Applications (SPAs) so that might be where you have seen that, if you load the page content via AJAX then that is one of the recommended ways to handle navigation. You indicated next page "loads" which makes me think this is a Multi Page Application, but I thought I better add that just in case as a general tip.

Bear in mind that all of this advice is general. Depending on your form, site design, loading pattern, user base (experienced users / internal system vs general public) etc. the best practice may be different.

So long answer short - use autofocus on the input if this is a multi step form and you think it is appropriate and obvious that the input would be the next thing to fill in.

Then test it with someone who uses a screen reader and get feedback as to whether it makes sense or if it was confusing or unexpected.

You are making a confusion between screen reader user and keyboard user. One doesn't necessarily implies the other.

People having dyslexia but normal sight may use a screen reader so that they can hear a text out loud instead of trying hard to read it themselves, but since they otherwise use a mouse or a touch interface, they aren't keyboard users.

People having difficulties using their hands but with a normal sight might not be able to use a mouse or a touch interface. They don't need a screen reader, but use exclusively a keyboard or maybe another specific input device that mimique the most important keys of a keyboard (in particular, tab, arrow keys, enter and escape). A joystick in some form can be such a device.

Considering what has been said above, designing a proper keyboard navigation and optimizing it always make sense. It may not be of important use for some screen reader users, but it's very important for keyboard users, as it's maybe their only way for them to interact with the app/page.

I am a screen reader user. With others, I believe a confusion about input focus is being associated with structural and contextual concerns. To the first question regarding when to “optimize” TAB experiences. It is always important since keyboard navigation is a supporting pillar used in my toolbox as a screen reader user. In addition, any input based non-screen reader accessibility tool is likely going to use this means of access.

As a developer, a guideline I always impress on other is the fact you want the natural structure and flow of code to do most of the work for you. Secondly, the process should follow expectations of your target audience and it seems you want to follow a “wizard” style. So, let me spell out a typical expectation for a wizard style questionnaire flow when using a screen reader.

UX point: does page reload fully or dynamically change?

This matters as this has a direct impact on my current reader “cursor” and how I will navigate to find the question.

From above statements, I will assume H2 will be used consistently. Thus, I will naturally use quick navigation to go to the first H2.

Now, I will use screen reader tools to read the question (be it TTS or braille output).

Once I feel I have its meaning, I will typically use TAB to find the first input control. Buttons are not input controls and thus violates user expectations. I am looking for checkbox, radio box, text field, and/or combo box.

If check or radio boxes, then I am assuming a group and hope for grouping (sadly rarely present) and will use tactics to deal with the situation I have found. If grouped, then I am using TABs a lot to move quickly and hear the “context” of the specific box focused with input.

Finally once I have answered the question, I am looking for the next question or forward/previous mechanism. These typically show up as buttons.

Hopefully, I am demonstrating how conventions/expectation are built using basic structure rather than trying to force procedure on the user. Thirdly, sites like a11y project can be very helpful with coding.