Accessibility: improve Windows/NVDA screen reader support

[michaldziwisz]

Summary

This PR improves accessibility across the Flutter app, with a strong focus on Windows + NVDA. It addresses multiple screen-reader and keyboard navigation issues reported during everyday flows (e.g., adding OATH accounts, toggling options like “Require touch”/PIN protection, navigation selected-state announcements, reading of help/shortcuts content, and reliable announcement of transient feedback).

Key changes

Semantics & keyboard navigation

• Navigation selected state: only the active navigation item exposes selected semantics (unselected items no longer announce as selected). Also reduces duplicate announcements.
• Checkable/toggle controls: introduce a reusable AppToggleChip to consistently expose checked semantics, correct enabled/disabled state, and reliable activation via screen reader / keyboard.
• OATH “Require touch” (Add account): refactored to use AppToggleChip and announce state changes.
• Dialogs / overlays: broaden ESC handling to dismiss dialogs/menus/overlays more consistently.
• Keyboard shortcuts help: reworked the shortcuts dialog so items are focusable and announced coherently by screen readers.

Screen reader announcements (feedback)

• Add AccessibilityAnnouncer (Dart) that prefers a Windows-native announcement path and falls back to Flutter framework announcements where appropriate.
• Toasts: announce toast messages.
• “More info” popups: ensure the info text is actually readable (dialog fallback in a11y modes + explicit announcement).

Windows runner (native)

• Implement a yubico_authenticator/a11y method channel on Windows.
• Raise UIA Notification + LiveRegion events to make announcements more reliable with NVDA (e.g., clipboard feedback / transient status messages).

Text editing (Windows/NVDA)

• Improve character-by-character reading in editable fields by tracking caret movement and announcing the character at the insertion point (helps align arrow-key navigation and Delete behavior with what NVDA announces).

Tests

Adds regression/widget tests for:

• navigation selected-state semantics,
• list item selected-state semantics,
• AppToggleChip semantics + activation,
• OATH “Require touch” semantics + activation,
• InfoTable copy-to-clipboard semantics,
• AppTextField caret announcements,
• UTF‑8 byte counter semantics.

Validation

• flutter analyze (Windows) ✅
• flutter test (Windows) ✅
• Manual: tested on Windows with NVDA; accessibility improved significantly (controls announced correctly, toggle state conveyed, navigation selection correct, and announcements for transient feedback are more reliable).

AI disclosure / limitations

• This PR was prepared 100% with AI tools, specifically GPT‑5.2.
• I did not perform a dedicated code-quality review beyond compilation/analyzer/test passes.
• Primary validation was functional + accessibility testing on Windows with NVDA.

[dainnilsson]

First off, thank you for your work on this! Accessibility is important to us and we are making a push to improve the app in this regard, so we are very happy for the help.

Unfortunately I don't think we'll be able to merge this PR as it stands, as it changes a lot of things and it is not fully clear what code addresses what issues. In short, it will take a long time for someone to figure out what each change actually does and to make sure it is needed, and doesn't cause unintended issues (eg. problems on other platforms). For future reference, having PRs broken up into semantically distinct changes helps a lot with this, rather than a single commit.

It also seems that a lot of Widgets seems to have been replaced with others, and while that may offer improvements in accessibility, it may hurt maintainability of the code and there may be better ways of solving the same issue.

So, what can we do with this? Hopefully as we work on accessibility issues we can use this as a reference for items that need to be addressed, and the code changes as a more concrete form of that: Showing exactly the functional change that is needed.

I will leave this PR open for now as we DO want to address these issues.

[michaldziwisz]

That’s correct. I only tested accessibility on Windows, so it’s difficult to determine what impact these changes might have on the apps on other systems. And if all applications are built from a single codebase, then of course it’s important to make sure that improving one thing doesn’t break something that already works. I hope this example proves useful and at least points in the direction of what could be improved to make your application more accessible.