> Domino's had to deal with an ADA suit a few years ago because their app dispensed with standard elements with default behaviors, like <button>s, in favor of unlabeled <div>s that had effectively no compatibility with screen readers.
Use of JavaScript has approximately zero correlation with website accessibility. If anything, sticking with a mainstream framework makes you more likely to meet accessibility requirements, not less.
> Bloated codebase full of external dependencies, that only works well on fast internet connections? Well, look at all the overdependence on third-party libs, or even or even hand-rolled behaviors in JavaScript taking up dev time, for implementations of things that browsers support natively now.
If your concern is dev time then third-party libs are a great thing, and trusting the library generally means less test burden than trying to figure out what each browser supports at the moment and whether that fits with your support matrix. If your concern is performance, you have to actually measure it - often JavaScript performs better than the native browser implementation of a feature.
> Messy codebase that needs a CSS class for every element, or even style declarations within the CSS classes themselves? You can do less of that if you use semantic elements and modern language features -- because then you can write unique selectors without having to explicitly name everything.
CSS selectors are far more messy than using a CSS class for every element. CSS is a tarpit where everything almost but not quite works, minimising your interaction with it is the only way to stay sane and keep your codebase maintainable.
Use of JavaScript has approximately zero correlation with website accessibility. If anything, sticking with a mainstream framework makes you more likely to meet accessibility requirements, not less.
> Bloated codebase full of external dependencies, that only works well on fast internet connections? Well, look at all the overdependence on third-party libs, or even or even hand-rolled behaviors in JavaScript taking up dev time, for implementations of things that browsers support natively now.
If your concern is dev time then third-party libs are a great thing, and trusting the library generally means less test burden than trying to figure out what each browser supports at the moment and whether that fits with your support matrix. If your concern is performance, you have to actually measure it - often JavaScript performs better than the native browser implementation of a feature.
> Messy codebase that needs a CSS class for every element, or even style declarations within the CSS classes themselves? You can do less of that if you use semantic elements and modern language features -- because then you can write unique selectors without having to explicitly name everything.
CSS selectors are far more messy than using a CSS class for every element. CSS is a tarpit where everything almost but not quite works, minimising your interaction with it is the only way to stay sane and keep your codebase maintainable.