Accessibility of FormData.label
Currently there is an issue with the accessibility of FormData.label. While these are clearly visible to sighted users, they are not read out by screen readers (tested with Orca) as the user tabs through the forms. (It can be read out using Orca's read line functionality at least sometimes, but this is rather fiddly and inconvenient, and I've found some where this does not seem to work, or at least not all of the time). The only thing that's read out is the default Accessible.name for the controls, which ranges from "often not very helpful" to "almost completely useless", and the control type/Accessible.role (left out in the list below).
- for textfields, nothing is read out unless there is a placeholder, or the existing text is selected
- for spinboxes and sliders, nothing is read out (except the value in the spinbox/slider)
- for checkboxes, only the label following the checkbox is read out. This is sometimes enough, but checkboxes using FormData.label very often are sentences that have crucial parts missing, or have the meaning fully in the label and only "Enabled" after the box.
- for radiobuttons, essentially the same as for comboboxes
- for comboboxes, the content of the selected entry is used as the name, which is often not informative enough and also completely superfluous, as for comboboxes the selected item is read out anyway, so the user hears the same text twice.
- for buttons, the button label is read out which is probably ok in most circumstances, but using buttons with FormData.label does not seem very common so this is based on a very limited sample
Of course, this is easily fixed by setting the Accessible.name of the control to something appropriate (i.e. the text for FormData.label, plus maybe some other stuff depending on the specific control like checkbox text). The problem is that this does not seem transparent to developers: In a semi-random sampling of a couple dozen users of FormData.label
on lxr, I've found exactly one project that sets Accessible.name or Accessible.description appropriately, namely DrKonqi.
Not even the Accessibility kcm gets this right; if a user tabs through the Keyboard Filters sub-page for example, all they'll hear is "Enable checkbox not checked" "Enable checkbox not checked", and they'll have to guess that the first one is "Slow keys" and the second one is "Bounce keys". If they enable the first one and press tab, they'll be presented with "text" (no indication that it's the delay spinbox), and a bunch of "when any key is pressed checkbox not checked" options, with no indication that this is about "Ring system bell".
This does not seem to be a satisfactory state of affairs. I can see two ways to solve this:
-
Make it very explicit to developers that this needs to be set (in the Kirigami tutorial, API documentation, etc). Go though all the users on lxr and explicitly set Accessible.name. Maybe write a tool that checks this automatically. Pros: Very flexible; no changes on the Kirigami side required; all code changes are simple even for inexperienced contributors (I'll volunteer to at least do some of them). Cons: Developers have to remember to do this; it's a lot of boilerplate code everywhere; hard to enforce for third-party users.
-
Have Kirigami do the right thing and automatically set the Accessible.name. Pros: Big a11y improvement throughout KDE and third-party users with a single effort; developers don't have to remember it. Cons: Requires changes in Kirigami; how to best do this is not quite clear to me and most ways seem to have their own problems.
Here's a very rough proof-of-concept that shows a first approximation of the correct behavior isn't too hard: cwo/kirigami@2a5051e4
Some issues with this:
- it should special-case some controls (e.g. checkboxes should have both the FormData.label and the text as part of the Accessible.name
- it's a bit awkward to do a11y-specialcasing in layouts, but this is where all the FormData.label stuff happens; not sure if there's a better place
- I'm a bit unsure how to handle cases where the FormData.label isn't attached to a control directly, but to e.g. a layout. It probably makes sense to always apply the change to the buddy? I didn't fully think this through yet
- the big one: Kirigami does it's thing when the item is fully created. This means that if the item sets Accessible.name directly, it will have already done so by the time Kirigami sees it, and Kirigami changing the Accessible.name will overwrite these changes. Most cases of this can probably be handled by always prepending the FormData.label to Accessible.name instead of using it as a replacement (which should be fine for most controls, but for comboboxes will keep the unecessarily doubled text) but will not work if the item does something very custom. I have no idea how to solve this. I'm not sure if it's possible to somehow do something from the Kirigami side immediately when FormData is set. Qt has a function wasNameExplicitlySet in qquickaccessibleattached_p.h but this doesn't seem to be exported and is from what I can tell not part of the official API. I have no idea what to do here (only thing I can think of with my extremely limited understanding of how all the layers interact is a separate flag in FormData to tell Kirigami not to overwrite Accessible.name, but this seems a bit clumsy)
So this is where I'm at. I think resolving this in a consistent way is very important for improving the accessibility of Kirigami applications and Plasma, but I'm very usure how to proceed and am near the border of my current technical understanding, so I thought I'd raise this as an issue before looking into this more.