4 ms·
How well integrated with the underlying platform is it? For example, on Windows do you take advantage of accessibility APIs for things like screen readers?
by criddell 2y ago
How well integrated with the underlying platform is it? For example, on Windows do you take advantage of accessibility APIs for things like screen readers?
- apitman 2y agoI don't think open source GUI toolkit developers should be expected to handle accessibility until OS vendors spend some of their billions of dollars to develop a reasonable cross-platform API.
- duped 2y agoWhy should OS vendors spend money devaluing their product? It's up to the cross platform software developers to make abstractions that work across platforms, not on platform developers to make things that work on other platforms. Just seems absurd.
- apitman 2y agoSee response to sibling. Why is this the responsibility of GUI toolkit developers and not app developers? EDIT: Also, how is this different from any other cross-platform API like POSIX, sockets, TCP, etc?
- duped 2y agoApp developers won't do it if the toolkit doesn't support it and make it extremely easy to use. It's also not that different, because platforms often offer richer/better APIs than POSIX and application frameworks use those with POSIX as a fallback for lower tier targets.
- apitman 2y agoI agree they won't do it, but why does that mean GUI toolkit devs carry the responsibility, when they also aren't provided with a good API?
- criddell 2y agoAll of the modern operating systems have good accessibility APIs. You ask why developers should take advantage of them? Because it’s the right thing to do and it’s usually not particularly onerous and accessibility accommodations usually make the software better for everyone. Would you also question why builders have to make bathrooms wheelchair accessible in public buildings? It costs more and can be uglier and restricts the potential designs. Why shouldn’t the wheelchair builders have to make fancier wheelchairs that can navigate the spaces you want to build, right?
- apitman 2y agoWhy should devs have to implement a separate API for 4+ different OSes? There should be one single API. The closest we have is AccessKit[0]. It's an awesome project, but this work should be funded by Google/Microsoft/Apple. I'm not arguing GUI toolkit devs shouldn't implement accessibility support. It's a laudable thing to do. I'm pushing back against the meme that the responsibility lies primarily with them. > Because it’s the right thing to do and it’s usually not particularly onerous Have you implemented cross-platform accessibility support for a GUI toolkit? > Accessibility accommodations usually make the software better for everyone. Accessibility support bloats software. The most trivial example is websites. If you add full accessibility support to a website, it will be bigger, and therefore objectively worse for any user not taking advantage of the accessibility features. The extra bytes also add up over trillions of requests to have an environmental impact. I think we should be exploring alternative approaches like hand-tuned accessibility-focused apps. > Would you also question why builders have to make bathrooms wheelchair accessible in public buildings? It costs more and can be uglier and restricts the potential designs. Strawman. Bathrooms exist in a physical space. Only one implementation can occupy that space, and disabled people have little choice but to interact with the implementations near them. Software distributed over the internet has no such constraints, and different products can compete on accessibility features. Also, ramps are beneficial to almost everyone at various times. Most people will never use a screen reader. > Why shouldn’t the wheelchair builders have to make fancier wheelchairs that can navigate the spaces you want to build, right? Physical accessibility laws were created before modern electric wheelchairs. It might indeed make more sense to regulate (or subsidize) this at the wheelchair level. Do you think most wheelchair users would prefer ramps everywhere, or a wheelchair capable of going up stairs[1]? As mentioned[2] by your sibling, accessibility advocates and ADA regulations push for "Full & Equal Enjoyment". That doesn't sound like being forced to use ramps to me. [0]: https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit [1]: https://youtu.be/hxf-fIubkMs?si=Cya66U7KQBpvLU-R https://youtu.be/hxf-fIubkMs?si=Cya66U7KQBpvLU-R [2]: https://www.accessibility.works/blog/alternate-separate-accessible-websites-fail-ada/ https://www.accessibility.works/blog/alternate-separate-acce...
- deergomoo 2y agoIf you are creating tooling for people to create GUIs, it should always be possible to make those GUIs accessible. I’m not saying this one doesn’t—I don’t know if it does—but in the general case it absolutely should. Not everyone is going to bother, but not even giving people the ability would be deeply irresponsible.
- apitman 2y agoWhy is this the responsibility of GUI toolkit developers and not app developers? There's nothing stopping app developers from making a separate version for their app designed specifically for accessibility. This results in a better UX for the users and the toolkit developers.
- Someone 2y agohttps://www.accessibility.works/blog/alternate-separate-accessible-websites-fail-ada/ https://www.accessibility.works/blog/alternate-separate-acce...: “Why Alternate “Accessible” Website Versions Fail ADA And May Increase Legal Risk. […] 1. DOJ: All public accommodation’s websites must comply. […] 2. ADA = "Full & Equal Enjoyment" […] 3. Is a "Separate But Equal" approach discriminatory?” I’m not a lawyer, but I don’t think one can draw another conclusion from that than that having a separate app designed for accessibility is a big no-no. Also, as a developer, you choose a GUI toolkit to make your life easier. Having good accessibility support then is a point in favor of a toolkit, just as, say, having lots of good-looking controls is one. Possibly even more so, as implementing accessibility support is a huge undertaking. You need to be able to enable high-contrast mode, to set keyboard shortcuts, to use larger fonts, tone down animations, have an on-screen keyboard, etc.
- apitman 2y ago* Your reference is talking about websites. The web is much easier to implement accessibility for than native OSes. * It's talking about intentionally low quality, minimal-effort ADA compliance. Do you believe most blind people (simple example, there are many types of disabilities) would prefer a version of a tool that has basic (but decent) screen reader support built into a GUI toolkit, to a hand-tuned app built specifically to address their needs? * Trying to legislate something as subjective as "Full & Equal Enjoyment" is one of the most absurd things I've ever heard. I didn't realize the ADA regulations were that bad. By that definition, anyone with a disability can claim anything about a website that they don't like is preventing them from experiencing "Full & Equal Enjoyment". * Them comparing websites using cheap ADA solutions to the civil rights movement is chef's kiss > Also, as a developer, you choose a GUI toolkit to make your life easier. Having good accessibility support then is a point in favor of a toolkit, just as, say, having lots of good-looking controls is one. I fully agree here. Accessibility is important and it's smart for toolkits to compete on such features. That's not what I'm pushing back against. I'm pushing back against the idea that responsibility for accessibility lies predominantly on GUI toolkit developers. There is nothing wrong with making a GUI toolkit that doesn't support accessibility. Accessibility support can be implemented/improved at multiple layers of the stack, but HN loves bringing this up because it's a meme with high virtue signalling value.
- pjmlp 2y agoThose developers have the option to make use of said OS APIs.
- criddell 2y agoAre you speaking for the Brisk project?
- apitman 2y agoDo you have some reason to think I am?
- danlcaza 2y agoAccessibility features are planned and will be included in one of the upcoming major releases.