Appropriately Set the Focus on Each Page Load of a Web Application

Share this video with your friends

Keyboard/screen reader navigation relies on focus proceeding in a logical and linear order and not getting lost such that the user does not know where they are or how to get back to the desired point in a web page.

References

https://www.w3.org/TR/wai-aria-1.1/#managingfocus
https://developers.google.com/web/fundamentals/accessibility/focus/
https://reactjs.org/docs/accessibility.html#programmatically-managing-focus
https://reactjs.org/docs/accessibility.html#programmatically-managing-focus
https://reactjs.org/docs/refs-and-the-dom.html
https://reactjs.org/docs/hooks-reference.html#useref
- https://medium.com/@teh_builder/ref-objects-inside-useeffect-hooks-eb7c15198780
https://www.gatsbyjs.org/blog/2019-07-11-user-testing-accessible-client-routing/

JP Erasmus

~ 4 years ago

Would it make sense to set the tabIndex for the h1 to -1 instead of 0? As far as I understand, the header would then not be tabbable via the keyword for non-voice-over users, but it would still be focusable via JavaScript so you can control the focus?

Erin Doyle(instructor)

~ 4 years ago

Great question JP! I put together a little CodePen demonstrating what you suggest. tabIndex is definitely required in order for JavaScript to be able to call focus on a non-interactive element like an h1 or div but what you suggest is correct, if you set the tabIndex to -1 it is not able to be focused by keyboard but is still able to be focused by JavaScript. I can't say off the top of my head if there is anything else to consider that would be missed by taking this approach. I can't think of any right off though so I think it's worth giving it a shot and testing it out using the various technologies and tools just to be sure.

JP Erasmus

~ 4 years ago

Hi Erin, thanks for taking the time to create a CodePen to play with this. I'll do some experimenting on my end as well.