A11Y Validation in EmberJS component Part I
Sometimes, when I’m creating a reusable component, I tend to use conditionals to check if the user is passing all arguments required, if not, I provide a default one, like the following example.
There is nothing wrong by doing that, but what about if I don’t want to use a label on this component call, like a slider where I’m using another markup as a label? Well I might end up breaking some of my accessibility tests, in order to fix this problem I need to refactor my component to make it not just more reusable but A11Y compliant every time we use it in our codebase.
From this code we can see that label is rendered only if it’s passed as an attribute, but then, how are we going to make sure this is A11Y compliant?
In my-component.js is where we are going to do our validation.
Couple of things are happening here,
- Checking if a label is passed, if not, an ariaLabel should be passed.
- In the case that none of the previous attributes are not passed we’ll have an error in our console about it telling us which attribute is missing altogether with component name.
Nice one, isn’t it? We have a clear and concise error preventing us to make mistakes from A11Y perspective.
Another important action happening here is the fact that we are adding an aria-label attribute when the user wouldn’t want to use a label on top of our slider component, this will make sure we are still A11Y compliant.
The right way to use this component would be
Small refactors like this one not only helps us a lot with our day to day A11Y implementations but allow us to think more about how we can extend rendering options in our components.
