[sapling-ginger]

No, they literally have to. The accessibility tool landscape is a wild place, since there are so many different human disability types, and people need different assistance in different ways, so there is no one tool that can help everyone end-to-end. Some people can see, but their hands can't type, so they use a custom input method. Some people can't see, but they can type, so they just need to be able to hear the page but otherwise can interact with the page with their normal keyboard. Some people have issues both seeing, hearing, and typing, so they have their own custom setup.

The browser's focus has to be taken as the gospel truth, because that is the only thing that all these different assistance tools can agree on. There is no standard otherwise. If you want to be a smartass and develop a speech-to-text tool that does it's own focus management separate from the browser's, well now people who need custom input solution can't use your tool, because what they are typing into (browser's focus) is different from what your tool is focusing on.

[andrewflnr]

No one is inputting directly to window.document, so in the scenario in the article you need to move the browser focus separately anyway. You'll notice I specifically said "where to read from", which is a distinctly different question from where input goes. Yes, you'll want to bring them together pretty often, but that's still better than dumping the user at the document root anytime a developer does something normal and predictable like disabling a button.