Earlier this week, I wrote about how I’m building a UI library for people who love HTML. I also published a YouTube video about it.
I got a lot of excited responses and comments about it, but also a noteworthy handful asking something along the lines of this…
People should not be prioritizing no-JS users. No one turns off JavaScript.
Today, I wanted to talk about why that’s wrong, and why you should care about the no-JS experience.
Note there’s a group of users that larger than the group of users without JS (for whatever reason): users of assistive technology. And they don’t even have a choice.
While I’m all for considering the needs of every user… If you get to the point where you’re worrying about no-JS users, I hope you’ve already considered the needs of people with disabilities, whether temporary or permanent.
Edit: oh right, wanted to add: just making a site work without JS doesn’t automatically make it accessible to people with special needs.
No-JS pages that fully comply with WAI ARIA are much better for users of assistive technology than any single page web app can ever hope to be. All the myriad states that an interactive JS page can enter are absolutely never ever properly tested for disabled users, and even after full expensive testing, just a little change in the JS can ruin it all again. While with WAI ARIA you can just quickly assert that the page is compliant with a checker before pushing it to live.
Definitely not. NoJS is not better for accessibility. It’s worse.
You need to set the ARIA states over JS. Believe me, I’ve written an entire component library with this in mind. I thought that NoJS would be better, having a HTML and CSS core and adding on JS after. Then for my second rewrite, I made it JS first and it’s all around better for accessibility. Without JS you’d be leaning into a slew of hacks that just make accessibility suffer. It’s neat to make those NoJS components, but you have to hijack checkbox or radio buttons in ways not intended to work.
The needs of those with disabilities far outweigh the needs of those who want a no script environment.
Also no. You cannot check accessibility with HTML tags alone. Full stop. You need to check the ARIA tags manually. You need to ensure states are updated. You need to add custom JS to handle key events to ensure your components work as suggested by the ARIA Practices page. Relying on native components is not enough. They get you somewhere there, but you’ll also run into incomplete native components that don’t work as expected (eg: Safari and touch events don’t work the same as Chrome and Firefox).
The sad thing is that accessibility testing is still rather poor. Chrome has the best way to automate testing against the accessibility tree, but it’s still hit or miss at times. It’s worse with Firefox and Safari. You need to doubly confirm with manual testing to ensure the ARIA states are reported correctly. Even with attributes set correctly there’s no guarantee it’ll be handled properly by browsers.
I have a list of bugs still not fixed by browsers but at least have written my workarounds for them and they are required JS to work as expected and have proper accessibility.
Good news is that we were able to stop the Playwright devs from adopting this poor approach of relying on HTML only for ARIA testing and now can take accessibility tree snapshots based on realtime JS values.
This is both factually incorrect, and ignores the original point.
First of all, no you cannot just run an automatic WAI ARIA checker. That will highlight some surface level basic structural issues but in no way is adequate testing for a pleasant accessible UX.
Secondly, modern frameworks like React and Angular have the same ARIA validation utilities. It does not matter whether components are loaded in dynamically by the framework as long as they’re defined in the codebase where linters and code analyzers can run.
Thirdly, you’re ignoring the actual point that is being made. You know as well as I do, that virtually nowhere actually puts serious effort and usability testing into websites making sure their websites are accessible, and that directly impacts the lives of millions of people who are cut off from the world of technology because of a disability.
Until you’re making all of your websites and apps accessible by second nature (i.e. until at a bare minimum you have your Web Accessibility Specialist certification), then focusing your time and efforts on catering to a niche ideological no JS crowd is quite frankly somewhat cruel and self serving.
If you want to learn the stuff necessary for that certification, here’s a document, the WAS Body of Knowledge listing what you need to know and maybe where you can learn that. Less detailed version in the WAS Exam Content Outline.
Heh, just deleted my reply - thanks for covering all that, you’re exactly right :)
deleted by creator
Doesn’t avoiding JS typically structure a website in such a way that the browsers built-in assistive services can cover it easier?
Not necessarily, unfortunately. (Though I guess technically it’s easier to throw up barriers using JS, but it’s not an inherent quality, and leaving it out doesn’t automatically make it good.)
I’m curious what parts would be challenging to use with a screen reader? If a site just has basic links and no JS, I can’t really think of anything unless the tab layout is somehow completely shuffled due CSS.
A comprehensive answer is out of scope and probably best given by a true accessibility specialist, but for example, if you only use
<div>tags for everything, a lot of the screen reader’s affordances for navigating are unusable. Images that carry information but not in their alt text are another simple example.And then there are parts where JS could actively help. For example, if you have a tabbed interface, but clicking a tab results in a full page refresh, the screen reader loses all context.
Also keep in mind that there’s more to assistive technology than just screen readers, e.g. sufficient colour contrast and keyboard navigability are important to many people. Too many websites still get those basics wrong.
Thanks for responding. I’m not really a web dev, so I haven’t thought about it much.
The tab layout and
<div>examples were definitely not things I was thinking about. I guess that’s a good incentive to use tags like<section>and<article>instead of divs with CSS classes.I’m actually a bit color blind myself, so I appreciate sites being high contrast and not relying on color alone for indicators. A surprising number of sites completely break when trying to zoom in and make text bigger too, which is often due to bad floating layouts. Especially if it’s resized with JS…
They overlap. Js is a shit technology for the blind.
Dynamic sites that move / hide / unhide components as you do things are unhelpful and confusing. A screen reader will tell you what’s under the cursor right now. If that changes, you don’t get notified that you’re now pointing at something else.
Static sites are better for accessibility too.
They can overlap, yes. Static sites are definitely not automatically better for accessibility.