Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Accessible Routing #433
This is probably an unpopular point of view, but I think there are other areas that should be prioritized over accessibility. Here are three examples:
Obviously one thing doesn't prohibit another, one can work on both screen reader support and localization functionality at the same time. But in a world of limited resources, I think efforts should be concentrated on other things.
Thankfully, it's not a zero sum game! Since my primary area of expertise is accessibility, this is where I can propose specific improvements to Ember.
If your area of expertise is in any of the things you suggested, please do feel free to write RFCs to address those issues- there's room here for everyone!
@sandstrom I have to wholly disagree with that statement based on one thing: every single new ember app out there right now is broken to AT. There's nothing the user can do to try and work around or fix it. I know it's not ideal, but if you need to translate something to a different language, you have the ability to. AT users are simply stuck high and dry. If they're an advanced AT user they might be able to figure out what's going on in a SPA, but probably won't bother.
I think every SPA framework / lib needs to take accessibility seriously & prioritize the work now that everyone is building SPAs. Until those framework / lib authors take it seriously, all SPAs will be broken to AT.
And, as @MelSumner said, it's not zero sum. You can get the ball rolling on first class i18n support if you'd like. Maybe learn some lessons from Angular when they took on that effort.
Lastly, this work might save everyone's companies from being sued for not being accessible.