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?
Just seems absurd.
EDIT: Also, how is this different from any other cross-platform API like POSIX, sockets, TCP, etc?
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?
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
[1]: https://youtu.be/hxf-fIubkMs?si=Cya66U7KQBpvLU-R
[2]: https://www.accessibility.works/blog/alternate-separate-acce...
Because they don’t want to release software that targets a lowest common denominator. If you don’t care about this stuff, just use Electron or some other library that lets you move fast and make mediocre software that feels foreign on every OS.
Each operating system is different in lots of different ways and if you want to make the best app on each platform, you embrace that. For example, many apps have some number of settings. On Windows you will probably put those in a Preferences or Settings dialog in the app. On iOS, some of those belong in the settings panel. Great apps aren’t going to pave over these differences.
Same goes for accessibility APIs. There’s all kinds of assistive devices (both hardware and software) already in widespread use. They have different expectations on every platform. Follow the conventions laid out by each platform maker and your software should just work. It’s the same as handling keyboard and mouse support. Each OS has different APIs.
Does that mean people who write cross-platform libraries have to do more work? Well yes it does, but then creating an abstraction over each platform is what they set out to do in the first place. It’s an important part of the job.
POSIX is a good example of a lowest common denominator that is "good enough" for many kinds of programs, but not consumer software applications with GUIs. That common denominator is the kind of cross-platform GUI toolkit/framework that we're talking about. a11y is a feature of that, not of something like POSIX. And no OS vendor is going to try and create such a standard, or if one is created they won't try and follow it - because anything that makes applications better on other platforms makes their platform worth less.
AccessKit is a really laudable effort to decouple the a11y API from the UI. It would be great if many GUI toolkits adopted it, but it does affect their design in non trivial ways.
Summed up: what you're asking is "why don't Apple and Microsoft make it easier for developers to make software developed on Apple platforms better on Microsoft or vice versa" and the answer should be self evident. These APIs exist to create value for the platform, not for other platforms. Standards don't exist for portability, they exist to create lock-in and entrench existing players.
No, what I'm asking is why the responsibility is always put on GUI toolkit developers. If a good cross platform a11y API is possible, the moral obligation is on the OS vendors to create it and support it. If it's not possible, then why do we treat GUI toolkit devs not only as if it is, but it's somehow their job to re-implement it for every GUI library?
The obligation is in the developers making cross platform layers, like GUI toolkits. There's no obligation for MS and Apple to agree on an API, but there is an obligation for the software claiming to target both to support both APIs. That's the very nature of making something cross platform!
“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.
* 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.