As an accessibility expert, I have always come across a question – be it from my team or the clients. How can I make this interactive element accessible? Most of time my answer is simple, use native HTML elements over ARIA wherever you can; even one of the 5 rules of ARIA states this! But what about custom interactive elements? Can’t we use that as well? Wouldn’t that get the job done? (wondering) What about the look and feel wouldn’t it look plain? So, many questions, right? Oh god, one more question 🙂
Most of the time everyone wants fancy products, but they forget while making them fancy they are not considering accessibility. Accessibility is not just for people with disabilities, it will always benefit every user!
With so many questions, there also comes the “misconceptions” about the accessibility for the interactive elements. In this blog we will try to bust such myths or the so-called misconception by separating the facts from fiction! So, fasten your seat belt (don’t worry I am not taking you for a ride!) and let’s bust them together!
Myth 1: Making interactive elements accessible is time-consuming and expensive
Fact: Most accessibility fixes are relatively simple and inexpensive to implement if you stick to basics i.e., using native HTML elements over custom interactive elements. Moreover, integrating it into the design process itself takes care of lot of foreseeable accessibility issues that occurs during the development phase. But if you keep on waiting for the magic to happen on its own – then you will definitely be late to the party for fixing – which will take a lot of planning to tackle the issues that will occur
Myth 2: The accessible interactive elements are visually boring
Fact: It’s not hidden that everyone want some fancy intuitive websites that are visually appealing! But the beauty about accessibility is you don’t have to compromise on the visual look and feel. You just have to ensure that keeping accessibility in mind you are choosing the right color, the right font size and keeping it user friendly as well. Accessible design can not only be visually appealing but it can actually enhance the user experience for all users, not just those with disabilities. You can use our friend “CSS” to achieve the look and feel that you desire even on the native HTML elements!
Myth 3: Assistive technologies will take care of accessibility of interactive elements, developers need not worry about it
Fact: It’s like saying all the vehicles will drive themselves, driver need not have to worry! Lol 😊
Note: Yes, I know that’s possible in some vehicles now! But you get the point, right? 😉
While assistive technologies can help people with disabilities to access the content, they DO NOT guarantee accessibility. Whatever the assistive technology picks it picks up from the underlying code behind the elements. It’s not like Aladdin’s magical lamp, that you rub it and things come true! Developers, Designers and Content Writers need to make sure the content is designed, written and coded keeping accessibility in mind.
For example, a button needs to be identified with a role of button because the screen reader can’t dream of it to be a button! So, if you code a button as <button>Hit me</button>, the assistive technology like screen reader will identify it as “Hit me, button.”
If you design a button that has very poor contrast, someone with low vision or color blindness won’t be able to perceive the button clearly.
Similarly, if you are designing an accordion which show/hide the content, wherein though visually the content is available but you forget to remove aria-hidden attribute when content is visible or forget to change the value to “false”, then you are asking for trouble! A screen reader will not be able to access that content if aria-hidden is still present with a value of “true”.
Myth 4: Scripted interactive elements can be accessed by all
Fact: Imaging if I tie your hands at the back and ask to pick up a glass that is on the top shelf – will you be able to? No, right? You will require help here!
Then why assume everyone will use a mouse to interact with an element? When a scripted element is present on the website that’s functional only using a mouse – it’s a BLOCKER for people with motor disability who might just use a keyboard/switch devices to interact with the website. Even in certain situational disability like when your mouse dies and the only way to hit that button to book your last available seats of your favourite Marvel/DC movie is with a keyboard – but meh! You cannot reach it or activate it! The tickets are now sold out ☹ Wouldn’t this be frustrating? It’s the same with scripted elements. So, next time If you code an interactive element, ensure that it’s reachable and actionable using different input devices.
Myth 5: Providing tabindex=”0” will magically make the custom interactive element actionable!
Fact: This is one of my favorites. I have seen so many developers slapping a tabindex=”0” on the neutral containers like <span> or <div> to create the custom interactive elements and forget to provide the necessary scripting. Reality check – tabindex attribute will only make the element focusable! You will have to provide the required event handlers along with the key listeners to make the element functional. Remember basics 😊 More importantly, people love tabindex=”0” so much that they go in and give it to non-interactive elements too assuming that screen readers use Tab to read content.
Myth 6: Sometimes we forget, beyond screen reader users’ other disability exists!
Fact: I have made the interactive element accessible for screen reader users. This I get to hear a lot! A custom interactive element will be used which will be only actionable using a screen reader. It won’t be reachable with a keyboard. If someone invites you to a party, but then forgets that you are even at the party. Hurts, right? We need to understand that beyond screen reader users, other disabilities exist – if you have made the interactive element accessible for screen reader users it doesn’t means that automatically it will be accessible for other people with disabilities. Someone who is using just a keyboard/switch device – how will they reach to the element and perform action? The interactive elements MUST be designed keeping inclusion in mind.
Myth 7: Role is not mandatory for interactive elements!
Fact: What’s the purpose of an interactive element? To perform an action – correct? If my interactive element is coded as <div tabindex=”0”>Activate Me!</div> to which all the required scripts are provided that makes it actionable using different input devices; my job’s done right? Answer is – you guessed it right, NO! How will a person using a screen reader understand the element is in fact actionable? Should they keep on guessing and activating the elements to understand if they are interactive? Sounds wrong right? Then define role! Role is an important piece of information that helps screen reader users understand the nature of element – like button, links, radio button, checkbox and so on.
Myth 8: Use of native HTML elements limits functionality
Fact: In simple words to say – this is another misconception. Functionalities like accordion, menus, draggable/droppable objects and so on can be perfectly created using native HTML elements. It’s the scripts that has to be handled accurately such that the accordion can expand/collapse content; menu button can open and close the sub menu and so on. Remember native HTML elements provide out of the box accessibility! So, it’s a win-win for everyone 😊
Myth 9: If there’s design constraint to provide a visual text, then use aria-label
Fact: This is another of my favorites. If there’s no space to provide a visual text – provide aria-label to specify the accessible name. So easy, right? Wrong, providing aria-label means you have to hard code the accessible names! Remember? then developers complain about accessibility is a time-consuming process? Most of the sites use template logic wherein the structure will be set and based on the requirement additions/subtraction happens. But if you can utilize the visual text that is already available then why not? If it’s a form field, then a developer can definitely use title attribute to provide the accessible name. Remember, aria-label again is only available for a screen reader user – remember Myth number 6 we explored earlier? So, there is alternative like using aria-labelledby to provide an accessible name using the visual text that is already available.
And that’s a wrap, folks! I hope you enjoyed busting the above myths! By addressing these myths, Developers, Designers and Content Writers also understands the importance of accessible interactive elements and the benefits they bring to all users.
We’ve tried to bust some myths, separated facts from fiction, and hopefully gained some valuable insights on accessible interactive elements. I don’t remember where, but I read this somewhere which stuck with me – “Remember, the only thing that should be exclusive about your website is its content, not its accessibility”.
It’s important to remember that accessibility is not just a checkbox that needs to be ticked off, but a fundamental aspect of creating an inclusive digital space.
So, let’s keep on breaking down the barriers and making digital space more inclusive! Stay curious and keep busting those myths! Do share any additional myths that comes to your mind in the comment section below.
If you have any further questions or would like more information on accessibility reach out to us at firstname.lastname@example.org. Also, if you want to know how our accessibility experts test your website and make it accessible, get in touch with our team at email@example.com.
This article by Fahad Lambate is a part of our BB Geek series where BarrierBreak team members share their expertise on accessibility and inclusion, drawing from their extensive experience in the field.