And while that is a perfectly valid stance to have on this, you'll more than likely shoot yourself in the foot if you don't.
- Wayland didn't think it was important to immediately include this, and now we have the majority of linux distributions having serious issues with screenreaders and other assistive tech. Fedora's shipped with this broken for almsot a decade. Calamares didn't think it'd be important to fix and has been broken for about as long.
- Particularly now, with devs grabbing a component library on top of React with a generous helping of CSS frameworks and third-party NPM-based extra bits that are all tangled together, and what have you, if you don't vet this stuff beforehand you'll have to retrofit half your UI to fix things after the fact. That, right there, is why accessibility seems so hard to implement.
Fixing a native HTML select for accessibility is easy; it already is. Fixing some componentized overengineered monstrosity that figured they'd get to it later and as a result doesn't speak with screen readers, doesn't work on phones, doesn't work when zoomed in, doesn't respond to speech recognition software, goes absolutely nuts when the user scrolls, and doesn't let you use it properly with a keyboard... yeah that is harder :)
I think it makes sense to learn about it early and do a11y as much by design as possible. I think a universal design approach will help anyone. Many power users will appreciate good keyboard only navigation as a side effect. With a bit of a11y knowledge you might be able to catch a lot of low hanging fruits. Wouldn't do it with public procurement and overdone rigout in mind. Just spinning up a screen reader on an app can actually be a fun experience.
