The checks in Failure technique F85 for Focus Order need to be tweaked

[mbgower]

The checks in https://www.w3.org/TR/WCAG20-TECHS/F85.html fail to account for the situation where the trigger has been removed.

As well, the test is quite prescriptive (go backwards).

These came out during discussion on #3214 in the prior survey and meeting. There are some other scenarios which should be considered in this failure technique to avoid unintentionally failing techniques which are acceptable in certain circumstances

[detlevhfischer]

@mbgower It would help to have a typical example where the trigger opens a modal and is no longer present afterwards. Would that be, for example, a dialog used to confirm the deletion of the very trigger that called it up (say, date a filter category, or some teaser tile)? Or are there better / more common examples?
I was wondering what the best practice would be even if the Failure test might not prescribe a location to set the focus to. My gut feeling tells me the element immediately before the (now deleted) trigger - and failing that, the start of the page.

Feedback would help if I take a stab at rewriting F85.

[mbgower]

@detlevhfischer Here's what I wrote in that survey

In a situation where a button exists in a table row to delete that table row, when the user activates it, the focus cannot be put back on the target. At IBM we provided guidance to put the focus on the prior UIC in the focus order. This has seemed to work well in such a situation. It matches the guidance on focus order in the dialog, but contradicts the order "forward" in the change. I'd like to see it made a bit less prescriptive.

Hope that helps!
My gut tells me just failing to prior tabstop is the best fallback in many situations. Almost always going to be preferable than top of page.