I am working with an SPA with Angular and the designs indicates that there is a back button and it is before the Page level heading usually the H1. For SPA, it is a general practice that we place the initial focus on load on the H1 heading, since only the main page contents reload.

From an Accessibility perspective, I feel that placing the Back button before the heading violates 2.4.3 - Focus Order as there is an interactive element that may be missed after initial focus in the page. Do you think it is an Accessibility violation if there is a back button placed before the heading in the DOM order. Thoughts?

Back button placement

1 Answer 1


I think you meant SC 2.4.3 as SC 2.4.7 is whether there is a visible focus indicator (just to avoid confusion).

Would this fail SC 2.4.3?

This would not be a violation of SC 2.4.3 as the order is still logical in terms of page flow (if you went back to navigation and tabbed into the page I am assuming it would be the first item that is focused).

This criterion is to make sure that you don't Tab from the back button to the footer (as an extreme example) causing confusion for keyboard users.

Providing a good user experience for Screen Reader users

"Is the back button actually needed?" Is the first question you need to ask yourself.

i.e. if I go back in the browser I assume it performs exactly the same action as going back using your button?

If the answer to this is yes then there is nothing you need to do, the button is a nice extra but not essential and less likely to be used by screen reader users anyway. It will get discovered at some point during navigation.

For non screen reader users who use the keyboard they will see the back button and realise they can Shift + Tab to the button if they want anyway.

If the answer is no, the browser back button performs differently to your back button then we need to make it more easily accessible. (In reality I would say you need to fix whatever is interfering with your navigation as they should both match!)

It might surprise you but the advice would be to make the back button focusable immediately after the heading. This makes it easy to discover / access for screen reader users.

You see this still conforms to the logical part of logical focus order, it is logical that the first action on the page after reading the heading would be the back button.

As the items are closely related visually (and assuming that you have a decent focus indicator and there is no focus ring on the heading when the page loads) there is a very low likelihood that someone navigating using the visual focus indicator will get disorientated on the page when they press Tab.

However make sure that the DOM order reflects the focus order.

<h1>Test Page Heading</h1>
<button><- Back</button>

and use CSS to change the order visually.

Final point here - your visual hierarchy is just as important, the back button placement is logical so don't change the visual design to try and fix this, you will likely end up with a less optimal solution.


  1. This will not violate logical focus order even if you do nothing.
  2. If the browser back button does the same then you are fine to leave it as is.
  3. If the browser back button performs differently to your application back button then try and fix that first.
  4. If for some reason your back button needs to perform differently then the back button should be focusable after the heading even though it appears visually before.
  5. Make sure the heading does not have a visual focus indicator but your button does
  6. Swap the DOM order and change the visual order using CSS.

Above all realise that they are the WCAGuidelines - they are there to help you make the best accessibility decisions you can, but your time would be better spent thinking about how people interact with your page and testing with different input methods and assistive technology than trying to follow something to the letter (as a lot of the time the guidance is not perfectly clear anyway!).

  • 1
    Thank you so much for your detailed summary. I think it makes perfect sense. I lean towards whatever you mentioned. Not everyone agrees the same way when you work in a team, since Accessibility is a nebulous beast with everyone having their own interpretation. I wanted to get a second eye and gives me confidence that I am recommending an accessible solution. NOTE: I updated my question to reflect the correct success criteria. Thank you so much for pointing out. Nov 25, 2020 at 21:08
  • 1
    glad it was helpful for you, good luck with the project! Nov 25, 2020 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.