Ory Kratos recovery flow ↔ Screen reader compatibility: What adjustments ensure keyboard navigation consistency across identity providers?

The adjustment lives in one rendering layer, not per provider

Cross-provider consistency is not achieved by tuning anything per identity provider. In stock Kratos (version assumption: v1.x self-service flows — verify against your pinned release), every recovery flow is rendered through a single template or a single ui.nodes payload; the provider or recovery method only changes which nodes appear in that payload. The work is therefore to make your one rendering layer provider-agnostic: render nodes in payload order with native HTML, wire ARIA from node metadata generically, and verify each provider-initiated path. You cannot guarantee Tab order by hardcoding fields — you get it from render order plus per-flow checks.

One premise to check first: unmodified Kratos recovery is identifier-based (email plus a code or link); provider chaining such as OIDC happens in login and registration. If provider buttons appear on your recovery page, they come from customized nodes or templates — and injected nodes are exactly where Tab-order regressions originate. Exact node composition varies by version and configuration, so treat this paragraph as marked for review.

Confirmed behavior vs. assumptions

Well-established web behavior, independent of Kratos version:

• Tab order follows DOM order; any positive tabindex breaks it. Use none at all.
• Native input, button, and a href elements are keyboard-operable without script.
• Every field needs a programmatic label; error text needs a stable id referenced via aria-describedby.

Kratos-specific points, stated as assumptions to verify: hidden fields (csrf_token, flow id) arrive as nodes in the payload; Kratos enforces no accessibility itself; overridden templates are not migrated for you on upgrade, so node changes can silently alter order.

Scoped adjustments

1. Render ui.nodes in delivered order, hidden fields included, where the payload places them. Never maintain a hardcoded field list; a new provider or method will shift nodes and change Tab order silently.
2. Map metadata to semantics generically: node label text to <label for>, messages to aria-describedby, autocomplete="email" on the identifier field, and autocomplete="one-time-code" if you use code-based recovery.
3. Set aria-labelledby on the form pointing at a visible heading, and keep a persistent error container with role="alert". On full page loads, live regions are not reliably announced, so also move focus to the first invalid field or an error summary after a failed submit.
4. Order actions semantically: primary submit first in the DOM, secondary links ("Back to login", support) after, grouped in <nav aria-label="Recovery">, with unique accessible names.
5. Choose focus after redirects deliberately — focus the heading via tabindex="-1" or the first field — and test with password managers, which disagree about autofocus after redirects.

Verification per provider path

Start a recovery flow through each configured method, then Tab from page load and confirm the order: identifier field, submit, secondary links. Run axe-core against each rendered flow URL and do one manual pass with NVDA or VoiceOver, since automated tools miss announcement timing. A scoped check:

npx @axe-core/cli "http://localhost:4433/self-service/recovery?flow=<id>"

Adjust host, port, and flow id to your deployment.

One detail that changes the recommendation

Are you overriding the server-rendered templates, or building a SPA on the recovery JSON API? The ARIA wiring above is identical, but the focus strategy is not: a server template relies on page-load behavior, while a SPA owns focus management after every re-render and must move focus and re-announce errors itself. Confirm which rendering mode you run before implementing the focus steps.