Emberjs is awesome, but addressing accessiblity issues is challenging.
I set out to make a more accessible TodoMVC app (to allow editing and deleting using the keyboard). The first issue I ran into was correctly associating the labels with their inputs by setting the id. This turned out to be much more challenging than I expected. I initially thought I might be able to use an ‘index’ helper in the ‘each’ block, but it doesn’t exist, and I think that’s the wrong approach anyway. I was ultimately able to get close to a working solution, any feedback would be greatly appreciated.
My real concern is that ember needs to provide more support for addressing accessibility concerns. @chadhietala informed me about ic-tabs by @ryanflorence an accessible tab widget (which looks awesome). I also came across a blog entry that talks about using aria with ember. I’m glad people are thinking about it, and working on it, but I think there needs to be an entry in the Cookbook section of the emberjs guides page. It could be its own entry, or added on to existing examples. For example, in the ‘User Interface and Interaction’ section, there could be some content about using aria, or a focusable element, to make the dialog more accessible. The ‘Focusing a textfield after it’s been inserted’ example should also include a label in the docs.
I’m really big on accessibility, all our stuff has to be accessible, and by that I mean our blind front-end engineer has to sign off on commits to our component and application code.
I’m very happy you’re concerned about accessibility 
I have found that ember’s bound attributes and automatic view ids make for some pretty easy accessibility tasks.
Having a lot of accessibility+ember experience I do not think ember is either in the way or lacking anything for accessibility. In fact, quite the contrary for me, it has made it so much easier to do.
I also don’t think its ember’s job to try to teach accessibility, that would be like trying to teach ux design (because that’s all aria is about, “audible interaction design”). The concepts are simple: bind some attributes, call methods from keyboard events, manage focus; these are all things ember is already designed to do well.
As for your attempt at the TODOMVC app, I’m sure there is some missing architecture. You can’t just tack on keyboard navigation into code that didn’t expect it.
So a coworker of mine helped edit the book Accessibility Handbook and he really dislikes Ember because (according to him) single page apps really crap themselves when trying to achieve 508 compliancy.
I agree that Ember’s Cookbook should have a section on how to handle the bulk of 508 compliant issues. If nothing else, I might convert my coworker to Ember’s awesomeness 
So in the spirit of “be the change you want to see in the world” I submitted a PR for this very issue:
https://github.com/emberjs/website/pull/1632
@ryanflorence since you have experience with this I think it would be great if you kick things off.
1 Like