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.
Summary
- This will not violate logical focus order even if you do nothing.
- If the browser back button does the same then you are fine to leave it as is.
- If the browser back button performs differently to your application back button then try and fix that first.
- 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.
- Make sure the heading does not have a visual focus indicator but your button does
- 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!).