James Scholes

@jscholes@dragonscave.space · Joined ⁨Nov⁩ ⁨2022⁩

Digital #Accessibility Engineer/Analyst, #ScreenReader user, and occasional #software developer. #a11y

Bluesky
@jscholes.bsky.social
Profile photo alt
A closely cropped headshot of a White man with light skin and a neutral (probably far too serious) expression on his round face. His short dark hair is parted in the middle and slightly longer on top. He is wearing a dark t-shirt and his large eyes look p
Pronouns
He/Him/His

Another appliance search blighted by the existence of touch screens and the fundamentally exclusionary practice of cramming them into everything regardless of suitability.

Want the best feature set? It's on the unusable model. Need accessibility? You'll need to sacrifice useful features, some of which would make the device more friendly to disabled people.

I'm struggling to come up with fresh ways of articulating how mentally draining this is.

To occasionally want to spend a bit of your hard earned money on something nice, only to repeatedly be shown that nice is synonymous with "we didn't think about disabled people." to see exclusion worming its way into cheaper and cheaper appliances, relegating disabled customers to an increasingly basic category of products that might eventually disappear.

But what's the use in articulating it at all? The only people reading this here already know it because they live it every day.

But at least I get to go to work and help make something I find morally deplorable more accessible in a bit! Happy Thursday.

Replying to @⁨jscholes@dragonscave.space⁩

@matt I believe this is one of the reasons why "SaaS in a box" services (like Cloudflare or Netlify) that give you hosting, API endpoints, a database, somewhere to put files, automated deployment, and so on all in one place have proven so popular.

It's not because people like Cloudflare. It's because people hate decisional fatigue and the acquisition of knowledge when it feels like it has a poor return on investment.

In some circles, the response to this shift has overwhelmingly been admonishment for encouraging vendor lock-in—even though superbly abstracted code was supposed to avoid that in the first place and everybody's writing that, right?—along with an unconvincing insistence that learning to administer a Fedora server is really really worth it. @nick

Replying to @⁨jscholes@dragonscave.space⁩

@matt I should also acknowledge that this tendency applies beyond syntax.

People (myself included) agonise over whether or not to use a relational database, and then which one to use, and then how to abstract it away so they can agonise about it again in the future...

... And then put 100 records in it. Who cares! You could've used a text file at that point.

@nick

Replying to @⁨matt@toot.cafe⁩

@matt Programming is a syntactically wanky field.

Do we need 17 templating languages for generating HTML that only differ on the names of the function to uppercase a string and whether you type `{%` or `<%`?

No. We need the research into those 17 syntax styles to determine which is clearly better (by whatever metrics), and to then abandon the rest.

But we don't do that. We all go around learning Twig, and Jinja2, and Liquid, and whatever the heck because one engine is written in Rust so it's faster. And one is only supported by Shopify. And one was already chosen for this project and changing the templating language when fixing a typo is rude and disproportionate.

In short, I think programmers do an absolutely terrible job of separating their academic interests from practical reality. And that's fine; the two are intertwined within many industries and hobbies.

But we shouldn't be surprised when outsiders find all of this completely bananas and invest in the tool that appears to abstract it all away.

@nick

Replying to @⁨matt@toot.cafe⁩

@matt I'm particularly interested in this question, and the related psychological effects, in relation to those who legitimately cannot read or write code for themselves.

I have a hunch that such people have a view of software development velocity and practice that we would find skewed, and that they would likewise struggle to accept just how slow and involved the process really is when an LLM isn't in the mix.