Current version of HTML (5.2) offers 111 different elements (or 113 if we count in svg and math, opens in new window), some of them pretty simple and some of them “full blown” components or widgets or whatever you prefer.
There is a golden rule of accessibility – to use native HTML element before re-creating it by yourself (better known as the First Rule of ARIA, opens in new window), but sometimes we just can’t use native HTML elements. Sometimes it’s the inability to style them as we want to (or are ordered to), and sometimes those native HTML element aren’t really accessible (yes, unfortunately some of them are still not accessible).
So there is a very high probability that we need to create some interactive component “from scratch”, and in this post I will try to set up a common framework that will give us better chances to make such custom widgets as accessible as possible.
Acceptance criteria for accessible custom interactive components
Acceptance criteria is quite a wide subject but let’s focus on the accessibility in this post. What must we consider to make our custom interactive components accessible. The answer is maybe quite obvious – we have to consider the whole Web Content Accessibility Guidelines (WCAG) that helps us with their baseline accessibility and then we also have to make sure to test such components with people with disabilities. Even better – invite people with disabilities from the start, where we define the functionalities and what the components need to do.
Unfortunately it’s not always possible to cooperate with people with disabilities on every step of creation, especially in smaller organizations and I like to be realistic about it. I really hope we will come that far, as a society and on organizational level, to really include people with disabilities and their lived experiences in all phases, from design to development, but it will take time to get there. I hope that WCAG version 3 will make the progress faster, but current reality is that it’s unfortunately not a common practice. So to try our best we have to rely on WCAG, community and accessibility veterans for now.
I like the concept of checklists, so here you go – a list that can be a checklist and will hopefully help with making your custom components (more) accessible.
- Keyboard friendly – visible focus with proper contrast, all functions that can be done with mouse and touch must be possible with keyboard as well.
- Semantic markup, when needed using ARIA, to have proper role, name, states and properties that are reflecting the reality.
- Good enough contrasts and visible affordances like instructions and labels and feedback/error messaging (that is also announced properly to screen-readers), don’t rely on color alone, use also graphical symbols with good contrast and when needed alternative texts.
- Support zoom, high contrast and when using animations respect the user’s preferences like reduced motion or have a setting to disable animations totally.
Please do audit the components internally and externally, test them with different assistive technologies and when your team is confident try to also test with people with different disabilities. And pay them fair for their time!
Hope this post will help you at least a bit. If it does, please reach out and if it doesn’t please let me know if I can improve something.
