Accessibility Improvement: Add Focus and Alternative Text for Labels and Widgets

[dorzao]

What is the problem or limitation you are having?

Currently, the Toga framework has some limitations in terms of accessibility. Labels are not focusable via the keyboard, which makes navigation difficult for users who rely on this functionality. Additionally, there is no support for adding alternative/descriptive text to widgets, which prevents screen readers from providing adequate descriptions. There is also no way to customize the accessible text for widgets, limiting the ability to make the interface more descriptive and intuitive.

Describe the solution you'd like

1- Focus for Labels: The ideal solution would be to allow labels to be focusable by setting an attribute like focusable: True. This would enable labels to be included in the window's tab order, improving navigation for keyboard users.

2- Alternative Text for Widgets: Adding an alternative/descriptive text attribute (similar to the 'alt' attribute in HTML) for all widgets would allow screen readers to provide more informative descriptions, such as for images.

3- Customizable Accessible Text: Implementing the ability to customize the accessible text for widgets. Accessible text is what identifies the widget to the user, such as "button" for a button, "text field" for a text input, or "label" for a label. While this functionality is also important, I consider that items 1 and 2 are more critical for improving the overall accessibility of the framework.

Describe alternatives you've considered

look up

Additional context

I am a programmer with limited experience and highly value accessibility to make applications more inclusive. The ability to make labels focusable and provide alternative text for widgets are significant improvements that could benefit many users. Customizing accessible text is an additional aspect that, while useful, is less critical compared to the other improvements. I believe these changes would not only enhance the framework's usability but also help address a wider range of user needs.

If this suggestion is not in the right place, please guide me on where I should submit it. I am willing to help in any way I can to contribute to the development of Toga.

Thank you for your attention and for the excellent work on Toga.

Best regards, @dorzao

[freakboy3742]

Thanks for the suggestion. As I've indicated on other tickets, Toga definitely wants to provide first-class support for accessibility; it's mostly a question of having sufficient knowledge about what constitutes best practice.

Regarding your specific suggestions: Focus on labels is an interesting one, because on macOS at least, that's not how accessibility appears to work. Focus is only granted to widgets that can accept input; VoiceOver then relies on widgets to provide the context equivalent to what is displayed by text labels.

As for (3) - I'm not completely certain configurable accessibility text is necessarily needed. A button is a button is a button; while there might be a need to customise the exact description about the purpose of an input, the type of input isn't something that should need to be customised on a per-widget basis. Ideally, Toga will "do the right thing out of the box", or, at least, a reasonable first approximation of the right thing with minimal additional input.

Customisable alt text (point 2) is definitely needed though; however, even then, it may be possible to get useful alt text without requiring a separate string definition. An example of this would be what is proposed by #2233 - if you've got a label that is associated with a text input, then you shouldn't need additional accessibility text - all the text you need is there (to first approximation, anyway - it might be possible to improve the text specifically for the purpose of screenreaders). Again, this is a case where toga should "do the right thing" by default, but provide options for customised specifics.

[dorzao]

Thank you for the response! I agree that suggestion 3 regarding the type of field would only be a nice-to-have. However, regarding item 1, while it's true that on macOS the behavior is different, on Linux, for example with Orca, users cannot reach the label using the Tab key or arrow keys. If it were a static label, there could be alternatives like generating an audio output of the text that should be there, or using a workaround with a focusable widget like a text field that plays the audio when focused. But what about a dynamic label that changes depending on user actions?

Regarding item 2, associating a label with an image might face the same issue as item 1: how to associate something that isn't focusable with something that lacks a description? For example, if there is an image of a bird in the window, and I create a class that always places a label with a description next to the image, since the label isn’t focusable, accessing the image through Tab navigation would still remain inaccessible, you see?

So that's my concern. I thought this would be the right place to suggest these improvements. If it’s not, and if you have a link to the appropriate place to submit this, please send it to me.

Thank you once again, and I look forward to your reply.

[freakboy3742]

Thank you for the response! I agree that suggestion 3 regarding the type of field would only be a nice-to-have. However, regarding item 1, while it's true that on macOS the behavior is different, on Linux, for example with Orca, users cannot reach the label using the Tab key or arrow keys. If it were a static label, there could be alternatives like generating an audio output of the text that should be there, or using a workaround with a focusable widget like a text field that plays the audio when focused. But what about a dynamic label that changes depending on user actions?

I don't know anything about how Orca operates, so I can't comment on the specifics. That's something where we need someone who has expertise with Orca to advise on what the right solution would be on GTK.

What I'm flagging is that adding focus to labels would be alien on macOS, so any solution in this space isn't as simple as "add focus to labels".

It's also worth noting that GTK, by default, doesn't allow focus on labels either. If Orca adds focus to labels, then it is stepping at least partially outside the bounds of GTK's default behavior. That is something we need to accomodate; but again, it's more nuanced than "add focus to labels."

Regarding item 2, associating a label with an image might face the same issue as item 1: how to associate something that isn't focusable with something that lacks a description? For example, if there is an image of a bird in the window, and I create a class that always places a label with a description next to the image, since the label isn’t focusable, accessing the image through Tab navigation would still remain inaccessible, you see?

Sure, that makes sense; and I agree that's what an alt-text style tag would be for. But again - on macOS at least, that doesn't require that the label be focusable.

So that's my concern. I thought this would be the right place to suggest these improvements. If it’s not, and if you have a link to the appropriate place to submit this, please send it to me.

As I've said here, and on the other ticket - this is the right place to raise the issue; now that you've raised it, we need to discuss the details to work out what the shape of the eventual solution looks like.