Accessibility of accesskit
#577
SmakoszJan
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
First of all, I would like to thank you for this project. It's the single best way to make Rust applications accessible with many integrations across many projects. This is meant as a constructive critique of the status quo and a proposal, not a complaint.
Unfortunately,
accesskit
has a wide range of issues. The documentation is very lacking and any questions regarding the source of knowledge for it don't give straightforward answers, instead pointing to how it's largely similar to aria but diverging where necessary, discussing how this is a fresh start and a chance for a new API, often times also pointing out how the API is still very unstable. The README features a promise of multiple target platforms and, more importantly an overview and an introduction into the world of accessibility for first-time developers. The latter is still painfully missing and potentially a big obstacle on the road to fully understand and utilise the features this crate provides. This expands to the contribution guide. Reporting an issue is pretty straightforward, but PRs are where things go south. The guide only suggests two things: making language bindings and making platform adapters. Language bindings require the knowledge of at least two languages and how to bridge them. This isn't an incredibly common knowledge and for the more experienced folk, for whom it is common knowledge, it's a huge time investment that can potentially all go to waste because of the afforementioned API instability. Platform adapter development is the same, but much worse. It requires knowledge of how to actually adapt the API to a platform, avoiding all the little quirks, extensive knowledge about testing (which, as a matter of fact, is also barely-if-at-all explained in the guide) and plenty of time and patience for unexpected API changes. And for last, but far from least, there isn't really much of a communications channel. It might just be me, but GitHub doesn't really strike me as a good discussion platform. For a project with so little activity (personnel wise) I believe setting up and maintaining a Discord shouldn't be too consuming, I've done it myself once - it wasn't bad. This would allow for some more open discussion and generally easier management, I think. I'd love to reach out to the people behind this project and discuss a thing or two.So what about it? Here are my thoughts:
First and foremost, push for stability. The sooner it's there, the better. It's not like it's the end of the world, it's not like it's somehow incredibly restrictive. If it ever proves necessary, there are plenty of major version past 1, no one is forcing anybody to stick to one major release. I believe this is the most important obstacle to note, as it stalls plenty of issues, including documentation, language bindings, adapter development, examples, and widespread adoption.
Once (and before) the API is stabilised, push for documentation for each property, method, and variant out there. Create a guide. Start small, expand later. It may be a good idea to only start working on the guide after 1.0.
Update the contribution guide. Invite people to write examples, to test it in the wild, to write documentation, to contribute to the guide, once it exists. Provide a guide to language binding writing, and to adapter writing. Open a communications channel, like
Discord
. Make it easy to reach out to you, to ask both development-related and usage-related questions, including questions about accessibility.Don't fear innovation, but utilize existing resources. I imagine this one's pretty clear, but I think it's worth putting here. Consider reaching out to people with experience. Maybe to someone related to
aria
, perhaps to some screen reader devs, maybe some one else who can provably say a thing or two about accessibility. Get an external opinion.Now, I know the above is easier said than done. It's a lot for two people, it's a lot for three people, it's a lot for ten people. But it has to be done. I'm working on a project that intends to go in-depth about accessibility. This project is crucial for the success of this. This, among other reasons, is why I'd be happy to hop into the development of this and help out wherever I can. The issues listed above require somewhat extensive discussion and a more detailed roadmap. It's a vague suggestion, not a concrete proposal, I'm well aware of that. I'd be happy to get in touch.
As a matter of fact, here you go: https://discord.gg/JxxWkznWUq
Beta Was this translation helpful? Give feedback.
All reactions