For this series, I’m not going to walk you through the process of writing an entire app, because that’s not what we are doing. However, I do want to use this small post to talk about how the following posts will be structured as well as highlight some tool that will make your job easier.
In the following posts, I will not waste your time by incrementally building up a component, only to reveal the final code at the end (Ain’t nobody got time for that!). Rather, I will give a brief introduction explaining why I have found a component necessary and/or helpful and then show the final code.
Note: I didn’t write these components to be feature rich, but rather to show how to present their contents with accessibility in mind. So take them and feel free to reshape them to serve your needs!
Following that, and depending on the need, I will call out things that I think are important to understand, and also show a few example uses.
Finally, all the components are available on an Ember Twiddle so you can dig around and improve at your leisure.
Be sure to check out the GitHub Repo to see both of these addons in action!
A Few Extras
At this point, I would be remiss if I didn’t call out a couple incredibly helpful addons that will save you time and frustration as you work towards building accessible Ember apps. There are:
This addon is a must if you are working on an Ember application. Because of the nature of single page applications (SPAs), when we click on a link and the content is updated, screen readers and other assistive technologies (AT) will not present that content to the user unless we tell it to.
That is where the Ember A11Y addon comes in. Once implemented, it will set the browser’s focus on the correct outlet whenever it is rendered to, prompting AT to present that information to the user.
This is an addon I have been playing with a bit lately and have found it incredibly valuable. If you write tests (Ahem… you should be), then this gem should be in your arsenal. It uses Deque Labs’ aXe-core engine to provide you with improvements you could make to your code that will make it more accessible.
You could use it in acceptance, integration, and unit tests to run a check on the presented markup, and fail the test if it finds any issues. The really nice thing about the engine is that it even provides links to short articles explaining the problems it finds, educating your teams along the way.
The first time I dropped it in an app, I wondered why I hadn’t done so before.
Alright, with all that said, I think we’re finally ready to start laying down some code. It only took three posts to get this far! We’re going to start off small, by building something simple. An icon component.