discord: 0xfffe
elephant: https://hachyderm.io/@pastels
24.24.2.287


Lunaphied
@Lunaphied

We talk a lot about accessibility and disability. But what we don't often hear discussed is the concept of "technological disability". That is, disability primarily due to limited technology. So let's talk about it a bit.


delan
@delan

on the one hand, is wonderful. with things like evergreen browsers, living standards, experimental feature flags, and polyfills, the modern web evolves at an exciting pace that far exceeds any other platform.

and the old web was unquestionably worse. the waterfall approach of “standards then reality and not the other way around” made early web standards slow and out of touch. this resulted in messy browser wars, and encouraged authors to turn to proprietary and inaccessible platforms like flash. traditional release cycles meant waiting years to try new features, plus years for those features to actually reach users.

that said,

building everything for the bleeding edge has its costs.

it disables people, as @irides explains, and it contributes to forcing everyone else onto an unsustainable treadmill of new hardware to keep up, which in turn feeds our destructive sandwich of resource extraction on one end, electronics waste on the other, and obscene energy consumption everywhere in between.

it also limits browser diversity, because if more or less every popular website requires an evergreen browser that supports everything, it becomes hard to make an independent and relevant browser without a megacorporation’s time and money. that’s why opera is chromium now, that’s why edge is chromium now, that’s why everything but like firefox and safari and epiphany are chromium now.

and yeah, i know i’m preaching to the choir a bit by saying this on cohost. in reality, there are a bunch of systemic reasons why this probably won’t change any time soon. planet-scale websites by for-profit developers will always treat a million users as disposable if it lowers development costs enough for their other billion users.

polyfills,

in theory, allow us to have our cake (developer experience) and eat it too (backwards compatibility). for example, nowadays it’s common to use the latest javascript features and just compile it down to ES5 (2009) or even compile it exactly down to what’s supported by an arbitrary percentage of the market.

but they’re not magic. you can polyfill features, but you can’t exactly polyfill computing power or bandwidth, not to mention the resultant code is often slower than if the feature were available natively. just because you can emulate the cutting edge, doesn’t mean doing so will result in anything remotely usable.

what now?

the point of this is not to say we should all go back to centering shit vertically with negative margins, var that = this, cranking out a gif for every rounded corner on the page, and web apps that rely entirely on being spoonfed gobs of html by some server every time you click on something.

the solutions are progressive enhancement, graceful degradation, and most importantly, giving a shit about people unlike ourselves. and if we respect the web’s fundamental behaviours rather than trying to bleach them into a clean white canvas in order to inevitably recreate it all in javascript, we can do more for more people with less.

the web is not meant to be a pristine medium to convey a pixel-perfect reflection of our programmer-artistic vision. it’s meant to keep us on our toes and violate our assumptions, that’s what makes it so versatile. it’s meant to be messy, that’s what makes it fun.

you can’t expect that old kindle to do everything the web can do today, but sometimes you just wanna message a friend or go down a wikipedia rabbit hole or look at some cute cat pictures, and you should be able to do that no matter what kinda device you have.


cr1901
@cr1901

But we are saying that only supporting an encrypted version of a read-only website is perhaps not ideal.

and you should be able to [message a friend and look at cat pictures] that no matter what kinda device you have.

Does this include an IBM 5150 :P? With the caveat that I would not log into a bank account using a 5150, TLS/SSL is the main reason I can't browse much of the Internet on old devices; the world assumes multiplies are cheap in terms of time and space. There are embedded crypto stacks, which solve part of the problem if you have a supported compiler. But you still need a certificate store and to keep that certificate store updated. That costs space and isn't exactly ergonomic for end users. In addition, AIUI TLS 1.3 got rid of the (unintended) ability to stream the handshake; the entire certificate chain from the server has to be stored in RAM. Not great for deeply (< 4kB RAM?) embedded devices. If existing stacks can't help me for IBM 5150, I really don't want to implement crypto, a type of software that famously touts itself as "something most people shouldn't write" because of its edge cases.1

To circle this back to @irides and @delan's point, there are much more important devices that my silly 5150 that have trouble accessing the Internet, because all the human bandwidth is dedicated to the bleeding edge and "only devices < X years old matter". I.e. deprecating insecure crypto standards without an upgrade path for older device because the few crypto stacks out there won't make sure the stacks build for your compiler and device combination.

Even ignoring my desire to put old shit on the internet, I don't think "only devices < X years old matter" is morally right. But probably that interferes with someone's bottom line, and who wants to spend money and resources on making sure the web is implementable2 when Billion-Dollar-Corp number 5 needs a shiny new feature?

  1. And this would be in addition to the real risk of finding out halfway through the implementation that it's physically impossible to do enough math with a 4.77MHz clock to properly negotiate with a secure server on the other end. It's high time risk, low reward, with a moderate potential to be very depressed by the results LOL.

  2. I don't believe it's possible to implement a web browser from scratch. I.e. collectively, the teams working on web browsers today could not (as opposed to would not) reimplement a web browser. All that knowledge is buried in several decades of web browser code, and many people who would know how to dig it out to say "here's how to do X", have moved on. And new standards change too fast for teams to keep up with them, let alone still have bandwidth to apply new standards while they're busy building a new browser engine. I hope Ladybird proves me wrong.


You must log in to comment.

in reply to @Lunaphied's post:

This reminds me of a post I read a while back, "The unreasonable effectiveness of simple HTML." (I think it was originally shared here on Cohost, but I'm not sure by who.)

The author describes how someone was using a PSP to access UK.gov — I was already aware of the UK.gov efforts in general accessibility, but that led me down a fun research tangent into their philosophy and guidelines on progressive enhancement:

I agree it's definitely an issue that people should pay more attention to, especially for essential services. I don't really know how I feel about calling it "technological disability," though. As a disabled person who is working in accessibility somewhat... It doesn't feel quite right? Maybe it's a common term that I'm not familiar with, but I'm uncomfortable with it for some reason. I'm not sure I have an alternative, but I thought I'd mention it.

Huh, that's an interesting post. We appreciate your bringing it to our attention, it has a similar perspective.

We appreciate your feedback on the term and we're sorry it made you uncomfortable. Our thoughts as a disabled person here are mostly that we think disability comes in many forms and that as society changes, lack of access to technology itself becomes a type of disability.

Unfortunately, in the process of writing this, that point was squeezed out a bit more than we meant it to be, as we lacked concrete examples beyond limited personal experience. So the focus ended up on background establishment and a few tie-ins to how this is related to more traditional accessibility topics.

We hope that gives a bit of perspective to why we chose the term

Back in 2017 a coworker and I noticed that we both used an iPhone 3G. Browsing was near impossible, and I had access to very few apps. We were both disabled, and our poverty was a result of our disability and societal attitudes towards supporting disabled people (ie. as little as possible). I do feel like disability and exclusion often go hand in hand, but they aren't always the same thing.

We'd just like to share, as a matter of a fun example. Our smartphone died over a year ago, so we've been stuck with an iPhone 4. Most websites simply refuse to load, as a matter of expired certificates. The ones that do load, are barely functional, get stuck, crash the browser or don't display well. Surprisingly, Youtube works phenomenally well all things considered, and we don't get ads! Zero ads, no midrolls, no beginning or end ads.

We can't access any new apps either, so effectively we are left with a phone / alarm clock / youtube / single video game machine.

This is what I was talking about in my reply-share when I said it takes a lot of tech skill to keep older tech viable. :P

If you want to get more websites loading, you will need to find and install the updated ISRG Root X1 certificate. Most websites still won't work due to missing features in your outdated Safari but you can at least attempt to load them.

If you want to be able to install old versions of more apps (a handful still work without doing this by sheer luck), you will need to jailbreak and install the Checkmate Store! tweak. (Important detail if anyone actually tries this: DO NOT update everything in Cydia all at once right after jailbreaking very old iOS devices! You'll run out of RAM halfway through and brick the device. Update packages one or two at a time.)