this post was submitted on 05 May 2025
102 points (95.5% liked)

Programming

20020 readers
121 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] ozr@programming.dev 9 points 2 days ago* (last edited 2 days ago) (3 children)

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.

[–] ShortFuse@lemmy.world 2 points 19 hours ago* (last edited 19 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.

[–] masterspace@lemmy.ca 5 points 2 days ago* (last edited 2 days ago) (2 children)

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.

[–] andioop@programming.dev 6 points 2 days ago* (last edited 2 days ago)

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.

[–] Vincent@feddit.nl 1 points 2 days ago

Heh, just deleted my reply - thanks for covering all that, you're exactly right :)