Respecting the No-JS Choice: Making Your Site Work for Everyone
Gracefully degrading my site for no JavaScript, including the CSS-based .no-js approach, testing with Lynx, and creating an informative experience for all users.
n my most recent posts, I've been [tinkering](https://brennan.day/extending-the-post-graph-plugin-adding-clickable-links-and-tooltips/) and [getting into the weeds](https://brennan.day/from-65-to-83-attempts-at-performance-optimization/) of programming my site.
A lot of developers, I feel, are programming for a rather homogeneous end-user: they are viewing the site on the latest mobile or desktop device with the latest operating system, and on the latest supported browser (which most likely has Chrome underneath the hood).
There are luckily some wins we still keep up with, like responsive design due to the wide array of different screen sizes (there was a point in time where app developers only needed to have their app in one screen size on iOS, because there was only one iPhone screen resolution). But otherwise, it is a monolithic responsibility given to the end user: you need to buy recent devices, you need to run a certain up-to-date OS, and you have to use a web browser that most likely doesn't respect your privacy.
This is a lot to ask for, if not outright hostile to the end-user.
With this in mind, I've been thinking about accessibility and optionality. Not just screen readers or keyboard navigation (those kind of things should be default baked-in), but accessibility respecting user choice and how they choose to interact with the Internet.
With that, I decided to go through the process of better making my site properly degrade for users without JavaScript.
## Why Bother with No-JS?
If we're being honest, most web developers demand JavaScript be used by the end-user. Sites are built with extensive (read: [bloated](https://dev.to/williamnogueira/the-problem-of-bloat-in-web-development-do-we-really-need-front-end-frameworks-14ma)) frameworks like React or Vue, fetching data dynamically and adding all sorts of complex interactivity where JavaScript is absolutely required.
But what about users who choose to [disable JavaScript](https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement)? There are many reasons for this decision:
* Privacy-conscious users who block all scripts by default * People on slow connections or who are using older technology where JavaScript lags the experience or might not even be an option * Certain users of assistive technology * Terminal browser users * People simply trying to conserve battery on mobile
Like with all accessibility principles, the end result is a better experience for *all* users, not just those who the accessibility is built for. Disabling JavaScript is a choice, and as web builders, we need to respect that choice.
## What Was Breaking?
In my process of adding various easter eggs and extending functionality, I have ended up with several JavaScript-dependent features on my site:
Did you enjoy this article?
Recommend it — Standard Reader surfaces well-loved writing to more readers across the network.