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.
  • ShortFuse@lemmy.world
    2·
    17 hours ago

    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.

    While with WAI ARIA you can just quickly assert that the page is compliant with a checker before pushing it to live.

    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.