In web apps, you can short-circuit this “there’s no business case” nonsense a bit by building your components using the accessibility attributes as the hooks between HTML, JS & CSS. E.G. rather than adding classes for everything you want JS and CSS to act on, instead hook onto the attributes role, aria-*, hidden and so on. If you do it as habit, it takes only a little bit longer to think about or type than attaching a class name, but helps you use the browser’s built-in accessibility support “for free”. If you work this way, you don’t even need to tell management what you’re doing.

I accept that this is easier on smaller, or new projects.

100% agree. I've noticed this as well. A lot of the time, the best objective-sounding argument for something I want is "it's necessary for accessibility", even though _I_ want it for reasons which would've been ignored. And a whole lot of the settings I rely on to make my computing devices comfortable are hidden under "accessibility" menus in settings screens.

There are even cases where the strongest argument for something to have a web version in addition to an Android/iOS app is accessibility. You can make some really interesting and specialized input hardware for Windows PCs which has no chance of working on an iPad, so there are people whose disabilities makes web apps way easier to use than any Android/iOS app. And if there exists a web app, power users can use the service from their comfortable desktop setup rather than from the tiny screen on their phone.

Accessibility is the most effective argument against the "one-size-fits-all" "it works for 90% of users" thinking that's otherwise so pervasive.

> make my computing devices comfortable are hidden under "accessibility" menus in settings screens.

That IS accessibility.

Accessibility is often understood to be for people with disabilities. For example, Wikipedia's first line on the topic[1] is:

> Accessibility in the sense considered here refers to the design of products, devices, services, or environments so as to be usable by people with disabilities.

And the W3C's intro to accessibility[2] says:

> When websites and web tools are properly designed and coded, people with disabilities can use them.

I don't have any disabilities which affect my use of technology. But I do like a fast key repeat rate, I like hot dim my screen at night further than the normal brightness setting allows, and I like to enable mono audio when watching a video where one of the audio channels is broken. I don't think most people would characterize these use cases as "accessibility", but they're all hidden under the accessibility settings in various systems.

You may consider this accessibility though, I don't know. There are definitions out there which don't put emphasis on disability.

[1] https://en.wikipedia.org/wiki/Accessibility

[2] https://www.w3.org/WAI/fundamentals/accessibility-intro/

I think you're trying to counter my off-the-cuff (re)-definition of accessibility. You're pushing it into the sphere of "it's just for disabled people".

I agree that's how the word is used most often. But using it that way others disabled people. Othering allows decision-makers to ignore the out-group because "it's not economically viable to support them" or because "it's too difficult" or "we'll have to learn & refactor, which takes time away from features"... or whatever.

I consciously put forward the suggestion, somewhat masked by my flippant tone, that developers (in the sense of anyone involved in "making": CEOs, management, designers, engineers) could do a small shift in their thinking that would open up the idea of access for all. This would push back the othering of disabled people, would include them. It would allow developers to work more creatively with the idea that their fellow humans interact with with products and services in myriad ways.

Even if you want to take the tighter definition of accessibility put forward on Wikipedia, the topic can still be opened up to new perspectives. Consider the differences between the medical and social models of disability. The medical model says that disabled people have deviations from mean physiology or psychology that must be addressed symptomatically, under "medical" supervision. The social model[0] pushes the disability out to our social systems. Sure, some people have "incapacities" - challenges with movement or sensory processing etc - but the dis-able-ing is enacted by the social systems (design patterns, funding, font-sizing, stairs vs ramps, stigma, othering) that ignores the needs of anyone off the mean.

I struggle to see clearly at distance. The fact I don't know which train to board is more because the station designers built the timetabling system with a typeface that can only be read comfortably by those with mean/median vision. If they printed it larger, I could stand in the crowd and read the sign like everyone else. If they'd installed a PA system and announcements, I could use my hearing instead. (fortunately, most stations do work this way now. Hopefully you can see the systems thinking in my example).

[0] https://en.wikipedia.org/wiki/Social_model_of_disability

One of the first things I do on a new Mac is to enable three finger drag. A couple of years ago this option moved fron trackpad settings to accessibility options.

That’s when I understood that I had a disability.

I can't understand why Apple did this, it seems like such a natural interaction for the trackpad.

yea when i was using windows a few years back i got some great mileage out of autohotkey + microsoft's accessibility access. (acc.ahk is the script someone make that interfaces with it if anyone is interested)

one good example was being able to control spotify. it doesn't work with the current redesign i don't think, but i used to be able to heart a song, show the current track name and artist in a tooltip, or list all the songs in your friends tab. lots of handy stuff like that and it all worked even when the spotify window was in the background