Akademy/2025/Accessibility improvements in Qt
Documentation & guidance
It is really hard to know how to implement accessibility correctly. There were many voices asking for more documentation, guidelines, tutorials and tools to help us implement best practices for different kinds of impairment. We need to consider visual, cognitive and physical impairment.
We need to understand best practices for keyboard navigation, screen reader functionality in general and contextual information in elements and layouts. When to set roles, when are these needed?
We should have patterns that work well for end users and that the screen readers can understand in a good way. Christopher has started drafting this.
The most important scenarios to prioritize
In general widgets work quite OK, but QtQuick controls need more work. We need sensible defaults for basic implementations. Some controls do not have implementations yet and some are missing parts - i,e. spinbox, scrollbar.
Navigation needs better support. Currently scrollwidget cannot scroll with key navigation, button menus are not announced in qml since popup menus are windows and not items.
We need better convenience for handling tab order. For instance in Listviews with delegates where the delegates have buttons you have to tab through everything. This does not work very well on the tooling side as it’s hard to get focus back from a button and go a level up. You need to remove focus from all children. You should be able to move through all high level elements, enter into and escape from them again as you continue. There are a variety of problematic situations here. Entering into a textEdit where tabbing should work for text makes it hard to get out again. Using the escape key you might accidentally close the entire dialog. Control tab is expected to switch tabs in a browser so we cannot use this. F6 (on Windows) might be an option for leaving the textEdit (tbc)
In the listview example you might want to tab through the headers in the view to understand the columns, and then skip the rest of the rows.
Would be nice if there was a way to make keys know if they are in RTL or LTR mode since forward and backwards modes are not necessarily left and right keys. This is problematic also on remote controls, game consoles etc.
How would the screen reader know what the alt key + mnemonic means? They are not read out as screen readers typically do not know what to do with these.
What can we do in scenarios where the implementation makes technical sense, but little logical sense. One example is the StackWiew being announced as a layered pane, zero items. It is technically correct, but it does not align with what Orca does and the info itself is redundant/not interesting.
Testing
How can we improve testing of a11y? Can we improve testing to find out if the UI breaks when translating to other languages? Can we know if components are ordered correctly when switching between RTL and LTR modes? Can we output warnings if icon-only buttons do not have any explanatory text? How can we test the focus chain? I.e. where is my focus, what is the next item in the focus chain? Can GammaRay be helpful here?
Open questions:
- How can we make windows accessible in QML?
- How are keyboard shortcuts supposed to be announced?
- How can we handle the need for a simplified language alternative? Can regional modifiers be a solution?
- What can we do on the tooling side?
- How can we improve the documentation?
Communication, cooperation and ideas
- Recommendation to view Get Lamp documentary by Jason Scott (text only presentation of worlds)
- Perhaps a service for evaluating how well a11y is done within an app
- Jira for bugs
- Discussions - find Benedikte (@beneholm) on matrix