Make it possible to pair Label with components like TextInput

[RastislavKish]

What is the problem or limitation you are having?

Right now, screenreaders can use TextInput fine as a widget, however, they can't determine its purpose for the user. Example, a TextInput can have a label "User name" above itself, but when tabbing through, the screenreader will announce just "text entry", instead of "User name text entry", hiding the purpose of the component from the user.

Describe the solution you'd like

There should be a way to pair Labels with other widgets like TextInput or MultilineTextInput, so the screenreader could say "User name text entry". For example, with Gtk Label this can be achieved using the mnemonic widget property.

Describe alternatives you've considered

There is currently no way to achieve this to my knowledge. Using a placeholder can provide some information, but that's not its intended use-case and will disappear as soon as the user types in anything.

Additional context

To see this problem in action, you can run the Celsius - Fahrenheit tutorial app, turn on a screenreader (Alt+Super+S for Orca on linux, Ctrl+Win+Enter for Narrator on Windows) and try to use the app from keyboard. The textboxes are announced fine on Linux from my testing (should be similar on win), however the only way you can tell which is for Celsius and which for Fahrenheit is the read-only state of the result.

[freakboy3742]

Thanks for the suggestion. We definitely want to do anything we can to improve accessibility, and this seems like something that should be relatively straightforward to address - the detail is all there (as in - the label exists) - we just need to tie the label to the widget somehow.

I don't know if you're in a position to make a specific API proposal - or, even better, provide a prototype implementation that is backed by an implementation on at least one platform - but any suggestions would be welcome - especially since you seem to be familiar with screenreader tech. We'd be happy to provide feedback on a design, or guidance on how to contribute if you're unsure how to get started.

[freakboy3742]

I've done a quick survey of accessibility APIs:

• macOS has an extensive set of accessibility controls, allowing you to go as afar as specifying an accessibility hierarchy independent of your layout hierarchy. However, it looks like you can get a long way by specifying an accessibilityTitle, accessibilityRoleDescription, accessibilityHelp, and a couple of other properties.

• Winforms allows you to explicitly provide accessibility hints in a number of forms, including the name, description and role of the widget.

• GTK allows you to specify that a label widget serves as a mnemonic widget for another widget. There is also a much richer set of APIs in the form of ATK; but, of course, this being GTK... those APIs have been deprecated and replaced with a whole new system in GTK4

• Unsurprisingly, iOS has a similar approach and set of attributes to macOS

• Android allows widgets to specify contentDescription, hint, and labelFor properties, as well as some additional control over whether an element should be voiced at all

• The Web has WCAG

The general approach seems to be a set of properties that provide:

1. A short label or name of the widget
2. A "role" for the widget - this often has a default value describing the fact that something is a "button", but is configurable for cases like overriding an image element to present as a "button" or "chart" for accessibility reasons.
3. A longer "hint" that can provide additional context. This is aligned with the sort of help text you might provide on a tooltip for sighted users.
4. In some cases, directly associating a label with a widget.

---

My naïve first-pass at an API is to provide 2 properties on widgets where accessibility hints are needed:

1. label - the short form description.
2. help - a longer piece of hint text.

label would accept a string, or a literal label widget. If label widget is provided, then it would also apply any "label for" hints that can be programmatically applied.

There's a handful of widgets where providing an accessibility label wouldn't make any sense - generally, widgets that have a text attribute (e.g., Label itself, Button, Switch). These are "self describing", so there's no need for an external label. At the very least there's a meaningful default label, so an explicit label would be an override.

help would be a string; if a platform provides a native way to surface UX hints (like tooltips), the help string would be used there.

---

To be clear - this is a very much un-informed first pass at a "quick and dirty" accessibility API. I will be the first person to admit that I'm not even close to being an expert in this field; I may be missing all sorts of subtlety and nuance. If anyone has a better proposal, I'd love to hear that suggestion.

[dorzao]

I’m also encountering some issues related to accessibility. Each label should have a 'focusable' attribute in the sense that, when pressing tab, the tab order should include the label (this should be a boolean, as not all labels need to be focusable). Another detail is an alternative text feature similar to the 'alt' attribute in HTML. When displaying images on the screen, we don’t have the option to add a description. There should be something like an 'alt_text' attribute for all focusable widgets if we want to add descriptions to accommodate screen readers/accessibility. If I am suggesting this in the wrong place, please guide me on where I should submit this suggestion. Thank you.

[freakboy3742]

@dorzao The ticket tracker is definitely the right place to suggest such an idea; the specific idea you're suggesting possibly warrants being a separate ticket, as it is about labels generally rather than labels specifically tied to text inputs.

As a more general topic - we aspire to have good accessibility support out of the box; but this is an area where we know that we often drop the ball through a combination of lack of experience about what constitutes best practice, and the huge variation in how individual platforms handle accessibility. If this is an area where you have expertise or interest, we welcome your input and contributions.

It's also worth noting that while raising issues identifying specific problems is very helpful (the more detail, the better), an open ticket will remain an open ticket until someone contributes a fix - so, it's even more helpful if a bug report is then followed by a pull request addressing the issue. We're happy to work with anyone who wants to contribute - especially if it's in an area where we lack experience - so if you need any pointers on where to starting looking for a fix, we're happy to help. We also don't expect someone to contribute a fix for every widget on every platform in one pull request - an incremental improvement (one platform, or even one widget on one platform) is plenty, as long as the code makes sense in the broader architectural sense.