This is part of a series on writing accessible Ember apps. Feel free to start at the beginning to get caught up. Want to see these components in action? Then be sure to check out the Ember Twiddle or the GitHub Repo! Got questions? Hit me up on Twitter.
Forms are huge buckets of vulnerability when it comes to writing accessible applications and websites. There are so many things that can go wrong with them that we must be sure to test them thoroughly.
One of the areas that we can get in trouble while using Ember is around the form inputs themselves. Specifically around tying inputs to their labels. This is because without labels, assistive technology will not be able to inform users what a particular field is for.
In HTML this can be done one of two ways. First, by explicitly referencing the input’s
id on the label’s
for attribute, or by wrapping the input with the label itself:
Because Ember provides the
textarea helpers, and since these produce their own unique IDs (Unless we pass in our own), it can be tricky to tie an input’s label to itself without using the implicit method (Method two above).
But sometimes you don’t want to rely on this approach. So we’re going to create a component that will do the lifting for us, and even yell at us when we use it wrong. That way, when other developers try using our component, our code will ensure it is used correctly.
Before we can write our component, we will need to make a small update to the
Ember.TextSupport class, so that we can add the
aria-describedby attribute to our inputs. It’s super simple and looks like this:
Nothing magical going on here, but a small change necessary to get the output we need. Onward!
This one is a bit more complex than our previous component so take a few moments to process it. As far as ARIA labels are concerned, we’ll only be using the
aria-describedby, but the rest will be simply using Ember to create the markup we need. Here is the final code:
For example uses of this component, check out the Ember Twiddle for this series. But you should also take a moment to review a few notes about the code:
Notice that the component will either reference a passed in ID or use the guid for the component’s instance as the prefix for the input and description IDs. This ensures that the IDs are both unique and understandable when looking through the DOM.
We also have the ability to hide both the label and description from the screen if we don’t need to show those on the screen. By doing this, we can keep a nice layout while still providing assistive technology with the information they need.
Labels are Required
Look at the computed property for the label. What this code does is verify that a label has been provided to the component. If it doesn’t find one, it notifies the user via an informative
Here are a few example uses of the component to see what it will output.
This will generate a standard input with label:
And will be rendered as:
This use will generate a standard input with a hidden description:
And will be rendered as:
While there is so much that we can do to ensure that our forms are accessible, this component provides a solid baseline for getting us started with accessible forms. It also shows us some advanced tricks in Ember that will do some of the heavy lifting for us.
Next, lets take a step back and create an alert box that will automatically present it’s updates to a user.