navigationtabsaccessibilityfocuswai-aria

tabindex for divs with landmark roles, right or wrong?


I have had feedback from an accessibility expert that it is irritating for screenreader users that I use tab indexes on my landmark regions. I added the tab-index so that users can use skiplinks to visit the navigation or main content. I was informed that it was frustrating for a non-interactive element to appear in the tab order of the page. I have now changed this so that skiplinks send you to the first focusable element within these regions and the regions themselves are not focusable. I have implemented this for my navigation landmark, main landmark and for some areas aren't landmarks but that include tablists, tabs etc.

However, I see many ARIA design patterns where divs with the role "region" have a tab index even when they are not interactive. For example, the tab pattern and menu pattern have regions with tab-indexes. https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation/ https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

The aria tabs pattern says

To make it easy for screen reader users to navigate from a tab to the beginning of content in the active tabpanel, it is recommended that all tabpanel elements in a tab set are focusable if there are any panels in the set that contain content where the first element in the panel is not focusable.

So does that mean that a navigation landmark should not have had a tab-index since it only contains focusable elements, but my main content landmark should have a tab-index since it may contain a header before any buttons etc? This would mean that the experience of navigating to each landmark from the skiplinks was not consistent though.


Solution

  • That’s right, they should not appear in the tab order of the page. As Inclusive Components note:

    The general rule is not to allow the focus of non-interactive elements by the user because the expectation is that focusable elements will each actually do something

    But you are right as well, that setting focus on target elements that just changed contents is a good practice. As focus always needs to be visible, and skip links potentially lead you quite far down the page, it’s helpful to have the focus in viewport.

    I think some browsers would even continue tab order from the skip link, instead of the target. At least that was the case a year ago.

    The nuance is that you need to use a negative tab index. That allows to set focus programmatically, but will not include the element in the tab order.

    <section id="jumphere" tabindex="-1" aria-labelledby="jumphere-title">
      <h2 id="jumphere-title">…
    

    For patterns such as tabs, it’s best practice that the panel immediately follows the tabs. This way, no focus control is necessary. It’s often done any way, and there seems to be different opinions on whether the panel should be focusable with keyboard or not. The APG Tabs are, Inclusive components’ tabs and UK.GOV’s are not.

    Skip links might be different to these patterns, in that their targets are very far from each other and from the skip link. When tabbing through a page, the skip link is quickly forgotten.

    What actual users think can only be determined by usability testing with actual keyboard and screen reader users.