Accessibility: support for screen readers

[tronical]

At the risk of this being a very open task, this ticket tracks the foundation of accessibility support. This is by no means everything, but it's a start.

Acceptance Criteria: It's possible to navigate the widget gallery demo using voiceover and a keyboard on at least one platform (such as macOS or Linux). This means the text of labels, etc. is read, it's possible to use the keyboard to navigate between different elements and activate them.

[Be-ing]

Please consider voice over accessibility for touch screens together with this. This is not an area I have much knowledge to offer, but I want to note that keyboards are not the only way that navigating GUIs is done with screen readers.

[Be-ing]

AccessKit could be helpful for this.

[tronical]

That looks promising, I'll keep an eye on that. Thanks for the pointer!

[jacquetc]

Hello,
AccessKit is still young but looks promising, I'm currently trying to understand it. I would not use 60fps for any desktop project because of the lack of accessibility.

Please, could you rename the title ? Something like "Accessibility: support for screen readers".

For your information, screen readers on Windows are:

• Narrator (included in Windows)
• JAWs (free trial)
• NVDA (free), easy to launch

Linux (using AT-SPI 2):

• Orca

Apple OSX & IPhone:

• VoiceOver

Android:

• TalkBack

I found a useful checklist on Flutter.

[tronical]

Done :). Thanks for the feedback and the checklist!

[Jookia]

Just to add on this, no accessibility support makes Slint a really hard sell for a GUI framework compared to something like Qt, GTK or even stock Win32. Slint is barred from running in organizations that require use of accessible software for example.

[mwcampbell]

Since someone mentioned my AccessKit project, I'll offer a quick update on it. I've got a basic Windows implementation working; the biggest limitation right now is lack of support for text editing. Also, I have a branch of Druid with AccessKit support. So now, the Slint team has something concrete to look at. I'll start working on AccessKit again in a few weeks.

[tronical]

That’s excellent. Thank you for the update (and your work on AccessKit)!

[DemiMarie]

I noticed this is listed as “low priority”. Unfortunately, in multiple nations, inaccessible UIs in commercial products are prohibited by law, which makes this a blocker. (Source: Hacker News)

[ogoffart]

@DemiMarie : Thanks for your comment.
We have actually started to work to improve our support for accessibility, and are actually working in an accessibility branch (#1193 and #1194). But not something that can be tested yet.

[DemiMarie]

@DemiMarie : Thanks for your comment. We have actually started to work to improve our support for accessibility, and are actually working in an accessibility branch (#1193 and #1194). But not something that can be tested yet.

You’re welcome! I am glad that it was helpful, and even more so that you are working on accessibility support.

[DemiMarie]

@ogoffart: I hope this is not too much to ask, but could non-accessible elements cause a compiler warning?

[Be-ing]

I like that idea a lot.

[hunger]

Warning on all non-accessible elements seems a bit of overkill: You do not want the screen reader point out random Rectangles making up a Button! You care for the Button in its entirety and the Functionality that provides.

Maybe we could warn about non-accessible exported Elements. Those are the building blocks used elsewhere.

[Be-ing]

Warning on all non-accessible elements might work okay if there's a way to explicitly opt out of the warning like clippy lints.

[DemiMarie]

Maybe we could warn about non-accessible exported Elements. Those are the building blocks used elsewhere.

That sounds like a great idea.

[mwcampbell]

Now that AccessKit integration is merged in egui, and the AccessKit Windows backend supports text editing (coming soon on macOS), maybe it's a good time to look at integrating AccessKit into slint. That is, unless you expect that desktop apps in production will use the Qt backend for the long term, though that complicates commercial licensing.

[DemiMarie]

What about a direct AT-SPI backend for Linux?

[Be-ing]

That's what AccessKit is building: AccessKit/accesskit#56

[Be-ing]

AccessKit just made the first release with Unix support: AccessKit/accesskit#198 It would be great to use it with Slint's winit backend.

[mwcampbell]

If there are any concerns about AccessKit's implementation, API, or support for different widget types that are blocking Slint's adoption of AccessKit, please let me know. Thanks.

[hunger]

@mwcampbell Thanks for the offer :-)

[tronical]

Beyond #2865 I'm going to file a few tickets under the accessibility label, so that we can track further improvements. My objective is to close this task when #2865 lands and incrementally work forwards.