Akademy/2023/Accessibility BoF

From KDE Community Wiki
< Akademy‎ | 2023

Meeting Notes

Upstream Qt Fixes

  • for generic stuff like ignoring invisible elements and propagating action names for icon-only buttons
    • Carl has a WIP patch for the former
    • set better defaults when A11y is enabled and not manually overwritten
  • there's not fundamental objection from Qt to such changes, so we should try to do that first before doing app-level workarounds
  • a11y attached properties incur extra cost

HTML strings in a11y names

  • avoid when possible, screen readers struggle with that

Keyboard navigation

  • screen readers only see things that are focusable, not the entire AT-SPI tree
    • this also means only actions but not labels are read out
  • focus inside list items is also tricky
  • Firefox uses a different kind of key navigation when the screen reader is on, which makes a lot more things available such as links inside a text body
  • QWidget::buddy helps with this, but doesn't exist for QML
    • could be done in QML by binding the label text to a11y name or description
  • Kirigrami FormLayout and MobileForms cover some of that
  • can we automatically test for this?
    • every element in the tab order should have a name
    • can we check for complete tab order graphs?
  • text fields interrupt tab order
    • should we set a dedicated shortcut for this?
    • should tab entry be disabled so tab works focus changes?
    • shift-tab works to tab out backwards
  • row selection vs cell selection in widget list/table/tree views
    • current (focus) highlighting is hardly visible compared to selection highlighting
    • possible enable more keyboard navigation here when the screen reader is on
    • QAccessible::isActive gives us API for checking that

Tooling

  • there's fregl's "Randamizer" tool in libqaccessibilityclient, which is a very bare-bone version of accesserizer
  • the web inspectors have this built in:
    • AT-SPI tree access
    • color contrast checks
  • kwin color blindness effect: exists from Randa 2017 (?) but not integrated in Kwin upstream
  • could we built a color contrast checks?
    • do we need this for the style, or are custom colors the bigger problems?
    • should we have a more expanded color palette/color API that gives you more colors which are optimized for contrast? Android apparently has something similar

Discoverability of A11y features

  • zoom/color inversions etc listed under desktop effects
  • have all this collected in a a11y systemsettings page
  • have a11y covered in the Plasma welcome page?