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.

Conclusion

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 info@barrierbreak.com. Also, if you want to know how our accessibility experts test your website and make it accessible, get in touch with our team at sales@barrierbreak.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.

The post Busting Myths: Separating Fact from Fiction in Accessible Interactive Elements appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Interactions on the Web are getting more engaging and dynamic these days. In this modern web era, UI designers are coming up with rich interactions for users where information is available to them without requiring the page getting reloaded. Gone are the days where users clicked on a link or button and web page had to be reloaded to show the updated content. Now users click on a link  or button and additional content is available for users then and there!

WAI ARIA comes to the rescue!

WAI ARIA provides  a wide range of roles, states and properties which can be utilized to make the rich web interactions available for persons with disabilities. Assistive technology is used by persons with disabilities and to make the information related to dynamic and rich interactions understandable, it is required to convey the information semantically.

Semantics is used to convey information related to a user interface element’s role, states and properties that a user can understand. For example, if a <div> element is used to structure a button then it needs a role of “button” for a user to understand that it is a button that can be clicked. Next it needs a label (property) to understand what is the purpose of the button. If clicking on the button expands or collapses the content then it needs a state to convey this information.

In this post, we will be talking about one of the ARIA state aria-expanded!

aria-expanded is a WAI-ARIA state which is used to show the expandable and collapsible content. It is used to indicate that the element for which it is specified or another element that it controls is expandable or collapsible. As per the ARIA specification, aria-expanded has the following values:

• true: indicates that the element is expanded
• False: indicates that the element is collapsed
• undefined (default): indicates that the element is neither expanded or collapsed

Some of the roles for which aria-expanded state can be specified include button, Link, combobox etc.

Tip: All the leading browsers and screen reader combinations include support for aria-expanded!

Good code example of aria-expanded

On the BarrierBreak website, we have a navigation menu available in responsive mode. The menu is structured using a button and users can expand the menu to view the list of our services. Below code demonstrates how aria-expanded can be used to convey the menu button’s state for screen reader users:

<button id=”opennav” class=”navbar-toggler pull-xs-right mobile-menu col-style-1 active” type=”button” data-toggle=”collapse” data-target=”#mainNavbarCollapse” aria-expanded=”true” aria-label=”Site Navigation Menu”>

<i class=”vertical-align” aria-hidden=”true”></i>

</button>

Bad Code example of aria-expanded

If a page contains a link which opens in a new window, aria-expanded is specified for the link, which is not required. As aria-expanded defines the state of an element and in the case of links opening a new window the state of the link is not required to be conveyed to users. Below is a code example depicting incorrect use of aria-expanded:

<a href=”https://www.barrierbreak.com/accessibility-barrierbreak/” target=”_blank” aria-expanded=”false”>About Us</a>

Adding aria-expanded to the code is not rocket science! Yes, that’s correct but it needs to be implemented correctly. Check it by inspecting the code and most importantly get it tested by persons with disabilities using assistive technology to ensure that is done right!

Want to know more about our accessibility testing or our accessibility subject matter expert services? get in touch with us at sales@barrierbreak.com or Book an appointment with our account management team and we will be happy to help you!

The post aria-expanded: the Good and the Bad appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Modal dialogs have always been common, but it seems in the last few years, their popularity has increased. From sign-up forms, to dialogs asking you to subscribe to your newsletters, or even simply error notifications, many of these patterns are implemented using modal dialogs.

A large portion of these modal dialogs are inaccessible, which means a major component of the web is out of reach to people (these can be keyboard-only users, or screenreader users, or a combination of both). Fortunately, there are ways to make modal dialogs accessible. We just need to keep in mind a few basic principles.

It’s all about focus

If your modal dialog can be 100% operated using a keyboard, then chances are you are on the right track. A common error with many implementations of modal dialogs is that they don’t keep in mind keyboard focus and assume everyone has a mouse to click on elements.

As a user, I should be able to:

• Have the initial focus inside the modal dialog as soon as the dialog is opened. It shouldn’t be anywhere on the main page.
• Close the modal using my keyboard.
• Tab through various focusable elements (like form input, buttons etc) using just my keyboard.
• Stay within the modal. Keyboard focus should not leak to anywhere in the background (the main page) as long as the modal window is present. Keyboard focus should be trapped inside the modal window as long as its present.

Ideally, when the dialog is closed, the focus should go back to the element that spawned the dialog.

Dimming the background

In the cases of modal dialogs, its a good idea to dim the background with something like a translucent grey color just to emphasise the fact that the background is not in focus. When the background is greyed out, and the modal window is not, it gives an extra indication that the user is supposed to pay attention to the modal dialog.

This won’t matter much to screenreader users, but to sighted users, its a helpful practice.

ARIA and Hiding things properly

Just because an element isn’t visible doesn’t mean its hidden. If not implemented properly, it can still be seen using a screen reader.

It’s important to use aria-hidden=“true” in cases where we want to hide an element from the screen reader.

1. When no modal dialog: The main page has aria-hidden=“false”. Modal dialog has aria-hidden=“true”.
2. When modal dialog is in play: The main page has aria-hidden=“true”. Modal dialog is aria-hidden=“false”.
3. When modal is closed: Go back to step 1.

We should also add additional semantics to divs and buttons to let the screenreader know what an element is supposed to be doing. For example dialog has the correct aria role attribute (role=“dialog”). If you have a close button, have a aria-label attached to it which describes it’s intent. For example, <button aria-label=“exit dialog”>X</button>. This is especially true if you’re using an non-text component (which also doesn’t have an alt attribute) in your button which is essential to understanding functionality. A common example of this are icon fonts.

Also, try using aria-labelledby to describe the title of the dialog, and aria-describedby to assign a description of the dialog.

HTML5 and Polyfills

The modal dialog is such a common pattern that we have an element in HTML5 for it called the <dialog> element. What makes this element great is that it takes a lot of the HTML and JS things we code for, and has it baked into the element itself. For example, it has DOM APIs to show and hide the modal, so we don’t have it code them ourselves. It has a ::backdrop CSS pseudo class to style the backdrop a certain way.

Keep in mind that not all browsers have support for the dialog element yet. So using a polyfill such as the this one from the Google Chrome team is essential.

Existing solutions and further reading

If you’re looking for a library for existing implementation to learn from, then do take a look at a11y-dialog which is fork of the Incredible Accessible Modal Window. I prefer the former over the latter because its not dependant on jQuery and has a JS API, a DOM API and event handling.

If you’re a fan of Web Components, then take a look at <paper-dialog> from the Polymer team.

That’s all you need to know for making great accessible modal windows.

The post Accessible modal dialogs: A tricky minefield appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.