When I started in the industry, progressive enhancement as a concept was the theme du jour. As SPAs have gained prominence, I’ve sadly watched the drive to impr

When I started in the industry, progressive enhancement as a concept was the theme du jour. As SPAs have gained prominence, I’ve sadly watched the drive to improve them and sometimes pushback against them morph this concept as it’s taught to newcomers into “No JS” or “low JS” as a side effect. It lacks nuance. For example, your menus should work without JS but that doesn’t mean they should work as well as or exactly the same way as they do with JS disabled. There are many features and patterns that a11y/screenreader users (which I recognize I’m somewhat lumping in with the “I disable JS for X reason(s) crowd here) appreciate that are still impossible without JS. I’ve surprised people on a couple occasions by showing them how much JS is actually used to create many of the WAI-ARIA menu proof of concepts[0], for example. I think the “a11y is easy” crowd, well intentioned as it may be, is also partially to blame for this. I’ve read articles with titles like “How to do X with CSS only” that gloss over many UX downsides to the chosen approach. The sad reality is that a11y users represent another audience with a different set of formed expectations one needs to cater to, and fulfilling those expectations is not free more often than some would care to admit, especially when you consider how complex the differences in approaches between screen readers can be. This isn’t an excuse to not help those users, but I have wondered before if we would be doing better if we were more scathing in our commentary on vendor standards as it relates to this. Who knows? Perhaps I’m naive. [0] https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/ https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/me...