I didn’t mean to imply that reader mode doesn’t rely on HTML or CSS.

What I meant is that as web developers we tend to think of serving up a webpage the way a restaurant does it: the customer orders their meal, the waiter takes the order to the kitchen, the chef makes the meal, and the waiter brings the prepared meal to the customer who eats it as prepared. However, technologies like Safari’s reader mode show there’s a different way: the customer orders their meal, but the waiter brings back all the raw ingredients and the customer prepares the meal themselves at the table.

We think of ourselves as chefs, preparing all the HTML/CSS goodness and then serving it up hot to the client. But users are starting to prepare it themselves now. It’s less about the HTML/CSS that we send them and more about the HTML/CSS that they brought with them. It’s increasingly just the text, media, files, etc. that users are after. And (hypothetically) there’s no reason it needs to be HTML/CSS that they’re using for markup or presentation since it’s just “data” being sent over the wire.

A “website” could simply be something resembling a JSON document that the browser parses to meet the user’s needs.

All of this is just my convoluted way of saying that (A) the HTML/CSS we write is not as central to users’ experiences as they used to be (and this trend will likely accelerate in the future), and (B) that JavaScript is powering this transition and enabling huge strides in accessibility that wouldn’t otherwise be possible, and in ways that don’t rely on the charity of web developers with the wisdom or the willingness to write accessible code.