azul
azul copied to clipboard
fschutt
Accessibility
How are accessibility concerns handled in Azul? As in if I create a GUI with it, can blind users read the UI via screen readers or other methods? Or is this something I would have to implement myself by other means?
No, there is no accessibility yet and it's not planned. While it's not impossible to support it in the future, it's a lot of work to implement, since every platform (Windows, Linux, Mac) has different APIs, so implementing accessibility takes a lot of time. Maybe in a few years - but it's a very low-priority issue.
As for whether you could implement it yourself - for many screen readers you need to dispatch events when element states change. However, since azul is completely stateless the only way to detect "change" is by diffing the DOM trees of subsequent frames. Which is a lot of work that hasn't been finished yet. So I don't think you could implement it as a user.
@rask If the software you are trying to build is very simple, you can consider using Tolk (available on crates.io). It allows you to directly communicate with the major screen readers on Windows. However, for a decent user experience, you would be better off of using Electron for instance. @fschutt I would be curious about how one can implement this feature (as I am directly concerned), hope I will be able to help when you decide to dive into it!
On Windows, there are two APIs: Microsoft Active Accessibility, and the newer way of using Microsoft UI Automation. Most of the documentation is written for .NET (what a surprise), but generally the C++ APIs are all on MSDN. There are a few good articles on MSDN:
As for screen readers, you'd need to test that it works with JAWS, ZoomText and Dragon. But I have to say, I'm not the right person to ask and you can google the rest yourself. I don't know more than you on this topic, I have never concerned myself with what screen readers need in terms of information, mostly because Azul is made for custom GUIs like image editors and gamedev tools - and there isn't much of a point in writing an image editor for a blind person.
A lot of screenreader tools seem to depend on types like "buttons", "text fields", etc. - in azul this is a bit of a problem, because these things don't exist, they are just DOM nodes all the way down. So there is no built-in "text input" component, there is just a rectangle that reacts to ontextinput events in a certain way. That might be a bit of a problem for screen readers. So yeah, if you want to implement it - you're on your own, because I don't know how to implement it either.
And for Unix based systems, you have ATK. @fschutt We currently don't have a good native Rust crossplatform GUI toolkit, but if Azul grows, it would be nice to tacle this challenge. For web based documents, we have Accessible Rich Based Internet Application, which is a standard that describes roles and attributes that can be attached to any element to give informations to assistive technologies. So, maybe a new set of components (e.g. AccessibleRole) could be attached to divs? The most difficult part being of course detecting state changes (traversing the DOM when the hashes differs is the only way I can think of right now).
I've added stub APIs (you can target them, but they don't do anything yet):
https://azul.rs/api/1.0.0-alpha1#Dom.set_accessibility_info
https://azul.rs/api/1.0.0-alpha1#st.AccessibilityInfo
Since Azul is now MPL-2.0 licensed (same as Firefox), my plan for handling a11y is simply to copy the necessary code from Firefox meanwhile translating it from C++ to Rust. I've looked into it and the hardest part is memory management (because these APIs are designed to work with inheritance, which does not exist in Rust - you have to basically hand-roll your own vtables, sigh). Internally, the Window and WindowInternal classes allow traversing the DOM tree, as most accessibility APIs expect it.
Hi @fschutt ,
I am the co-author of AccessKit which aims at being a cross-platform accessibility layer. There hasn't been any activity on the project recently, but this will resume soon. We are taking inspiration from Chromium and would be happy to help you integrate AccessKit onto Azul. We know that implementing accessibility is hard, so we are building a library that can work for everyone. It would be very nice of you if you could have a look at the project and tell us whether our accessibility model fits your needs.
Regards.
@DataTriny I know about AccessKit, however right now a11y is not my primary concern (getting the code to run on all platforms is)
This is a common misconception. Supporting screen readers does not mean you're targetting only blind individuals. Much like everything in life, there is a spectrum, and complete blindness is only a minority within visual impairments. I am legally blind, use a screen reader, but still use image editors because I can see. The screen reader helps me see low-contrast labels/text or get a quick description of what I'm looking at in terms of the general UI or an too-dark or too-bright image.
I understand the project does not have a11y in mind at the moment, but this is one of those things that is easier to work with from the beginning than trying to tack it on later on.
@jquesada2016 The project does have accessibility in mind, but it's a stub function right now:
https://azul.rs/api/1.0.0-alpha1#Dom.with_accessibility_info
https://azul.rs/api/1.0.0-alpha1#st.AccessibilityInfo
It's mostly modeled around MSAA (Microsoft Accessibility).