rumored to be drawing pictures and writing code on a "personal computer".
inactive
| pronouns | she/her |
| tumblr | https://perhapskhat.tumblr.com |
| github | https://github.com/PerplexativeKhat |
rumored to be drawing pictures and writing code on a "personal computer".
inactive
| pronouns | she/her |
| tumblr | https://perhapskhat.tumblr.com |
| github | https://github.com/PerplexativeKhat |
against all odds, a good orange site comment
Accessibility is customization, and customization is accessibility. They are one and the same.
User control over interfaces is an accessibility feature. At the heart of accessible control schemes is the notion that if a user isn’t able to use a traditional control-scheme they should be able to build or hook into something else or customize something that works for them.
This is a big problem with how the Linux community thinks about accessibility. Accessibility is not a separate concern from user agency and control. Accessibility IS user agency and control over a user’s interface. It is the ability to take an interface you can’t use or that is frustrating or painful to use and to adapt it to your needs.
Accessibility is fully aligned with Linux/GNU philosophy, but we treat it like a separate issue and like it’s a chore to support, rather than being a central pillar of how we ought to be approaching software development in general.
Here, GP has RSI which means their customization is linked to a traditional physical disability. But to be clear, even if that wasn’t the case and even if this just made their life easier and they didn’t have a clear, socially accepted disability classification to point to – customization is still accessibility. Gatekeeping accessibility or asking people to prove that they’re fully “disabled” isn’t really helpful, we should still be prioritizing making it possible to build things like this. And we should still be treating it like an accessibility concern regardless of whether there’s an easily defined disability to point to.
things ive checked: