|
|
|
|
|
by zelphirkalt
2 days ago
|
|
Since we are talking about _typical_ React sites, accessibility is immediately out of the window, when it only renders a white page. Even if it renders a proper page and even if one allows its JS to run, accessibility is usually still not even an afterthought, because the typical React page breaks back and forth buttons and standard browser functionality. The typical React app also will use some "components" thingy, instead of standard HTML form elements, and in the process makeing a complete mess of the DOM, so accessibility is also out there. The number of things this paradigm breaks, only to then have to fix them again, but this time by implementing them in JS partially correctly is just too high, for the average web dev to manage on the short time budget they get assigned in their day to day scrum managed job, where new feature requests and KPIs are more important than actual usability of their pages, and few people even properly test on multiple browsers, let alone screen readers and the noscript situation. It is just too tempting for them to use some component "someone else already made" "do not reinvent the wheel" etc., while constantly being discouraged to spend more time on making things actually work well. |
|
That's not the case for 99.9% of users.
> if one allows its JS to run
JS is enabled by default in every major browser. It's the _standard_, _typical_ way to browse the web.
> The typical React app also will use some "components" thingy, instead of standard HTML form elements
Components only exist in JS, not in the DOM. In DOM, they show up as regular HTML input elements.
> It is just too tempting for them to use some component "someone else already made"
HTML is also something "someone else already made".