Focus Management
Deliberately controlling where keyboard focus sits after an interface change, which is what makes a dynamic application usable without a mouse.
In a document, focus follows the source order and the browser handles it. In an application that replaces regions without a page load, nothing handles it, and the default behaviour is wrong in ways a mouse user never sees.
The cases that must be designed rather than left to chance: opening a dialog should move focus into it and trap it there, so tabbing cannot reach the page behind; closing it should return focus to the element that opened it, or the user is returned to the top of the document. A client-side route change should move focus to the new content and announce it, since otherwise a screen reader user hears nothing and the keyboard remains where the old page was. Content revealed by an action should receive focus or be announced. Removing the focused element must move focus somewhere deliberate rather than to the body.
None of this is expensive if designed in, and all of it is difficult to retrofit because it is distributed across every interaction. It is also invisible to automated checking — a tool can detect a missing label, not a focus order that makes no sense — which is why it needs keyboard-only testing as a routine practice rather than an audit finding.