Files
keepassgo/docs/accessibility.md
T
2026-03-30 07:58:27 -07:00

2.2 KiB

Accessibility Review

KeePassGO currently targets keyboard-first desktop use on Linux and Windows.

What is intentionally supported

  • Keyboard focus is explicit for:
    • vault search
    • breadcrumb navigation
    • entry list selection
    • detail/editor fields
  • Focus styling is visible and distinct from the unfocused field treatment.
  • Common keyboard workflows are covered in-repo by tests for:
    • tab navigation
    • list navigation
    • search focus
    • new-entry focus transitions
  • Controls that participate in keyboard navigation have intent-revealing accessibility labels through accessibilityLabel in ui_accessibility.go.

Current screen-reader boundary

  • Gio does not currently give KeePassGO a full native accessibility tree comparable to mature desktop UI toolkits.
  • KeePassGO therefore treats screen-reader support as:
    • label-conscious where the toolkit exposes focusable controls
    • limited where platform assistive APIs are not surfaced by Gio in the same way as native toolkit widgets
  • In practice, this means keyboard and focus behavior are first-class and tested, while spoken output quality still depends on Gio/platform limitations outside this repo.

Current review result

  • Linux:
    • keyboard/focus behavior is intentionally supported
    • visible focus states and control naming are present in code
    • full Orca-style semantic verification is not something this repo can assert automatically today
  • Windows:
    • the same keyboard/focus behavior and explicit labels are present in-app
    • full UI Automation parity cannot be claimed from inside this codebase without broader Gio support

What KeePassGO should continue doing

  • Keep every major workflow operable without a pointer device.
  • Add explicit labels for any new focusable control.
  • Preserve visible focus treatment for new form fields, buttons, and dialogs.
  • Prefer dialogs and panels that keep keyboard focus predictable.

What remains toolkit-limited

  • Rich screen-reader semantics beyond the control labeling and focus management done in this repository.
  • Native assistive-technology parity with toolkits that expose a fuller accessibility object model.