A quick history
In the past, accessibility was rarely talked about – it wasn’t something companies cared much about, and it certainly wasn’t a topic for most designers. Around 14 years ago, I was involved in a project where we were asked to take the website’s accessibility into account. I, of course, did all the front-end work with that in mind, and honestly, I thought I had done a good job (I tested it in Chrome, used some tools to check, etc.).
One day, shortly before delivering the project, the client sent a blind person to our office so that, with me observing, this person could try to use the website.
After watching this person – unable to see what I had built and relying solely on hearing and the keyboard – I realised the site was far from ideal. I had to go back and fix a lot of things. It was a real eye-opener to witness the hard experience of someone who didn’t care about if the site was pretty, but simply needed access to the actual content.
After the session, I spent a few minutes talking with the person to try to better understand the challenges of using the internet for people who face more difficulties than I do. At the time, what he shared with me was quite revealing about the state of the internet when it came to accessibility.
Seeing how difficult it was for that person to use a site that for me was a super easy and “normal” task, really stuck with me – and it’s something I remember every time I develop a front-end.
Accessibility is agnostic of technology or language
Technology should never be an excuse to leave accessibility behind, and likewise, regardless of the target audience, accessibility should always be one of the top priorities.
Whether it’s an internal company app for submitting holiday requests or an online store application for selling products, we must always keep in mind that there may be people facing difficulties that we wouldn’t even think of.
Something as simple as colour blindness can be enough to prevent someone from distinguishing a submit button from a delete button. The idea of someone with poor eyesight needing to zoom in on their screen might mean they can no longer see all the information they need to do their job – and end up taking three or four times longer to complete a task.
I know that the rules and best practices around accessibility were designed to be technology-agnostic. But the problem is that technology, at its core, wasn’t originally built with accessibility in mind – and we’ve gone generations ignoring that fact. Today, we’re still dealing with the consequences of that oversight and delay.
That’s why I say – and truly believe – that technology should never be a barrier to thinking about accessibility. Because the moment we let it be, we’re automatically making people’s experiences harder, or even excluding them from being able to use a website or application at all.
How can we ensure accessibility?
Ensuring accessibility is about much more than just having images with alt text, inputs with labels, or headings on the page. Accessibility means that if there’s a hidden element on the page, a screen reader should still be able to access it, understand its context, and allow the user to perceive and interact with its content.
This is often one of the biggest challenges, especially because we use programming languages like React or Angular, where content that isn’t currently visible on the page simply doesn’t exist in the DOM – making it much harder for screen readers to do their job.
However, as mentioned above, this doesn’t mean it’s impossible to ensure everything works well and that users can navigate the page as smoothly as possible.
Using this example, let’s now explore ways to ensure accessibility.
Create a trigger element
When creating the trigger to display our overlay element, we must ensure that:
- The trigger provides information that it has an associated overlay: If we use the attribute “aria-haspopup”, the screen reader will indicate the type of element that will be shown to the user. This attribute can be used for other elements like menus using the value “menu”. For our scenario we will use value “dialog”.
- The trigger is associated with the overlay element: By using the “aria-controls” attribute with the ID of the overlay element, we create an explicit association between the trigger and the overlay.
Element information
If we have elements like “overlay” types, such as modals, dropdowns, or popups, we must provide all the information for the screen reader to understand and inform the user about “what the element is and what it is for.” There are three ways to do this:
– Indicate the element’s “role”: The role attribute helps the screen reader understand the context of the element and provide that context to the user. There are several commonly used roles:
- “dialog”: When we want to represent an area with content that is separated from the rest of the page, such as a confirmation popup for an action;
- “alertdialog”: Used when we want to display messages to the user that interrupt or provide feedback about an action performed. For example, an alert that some fields in a form are missing or that an error occurred in the system;
- “combobox”: Useful in situations where we have a custom dropdown and apply this role to the element with the list of options to be selected by the user;
- “complementary”: Used in situations where we have an element that is an overlay on the page, but the content complements the information on the screen. For example, a sidebar with filters that are applied to a table on the page. Equivalent to the HTML <aside>tag;
- “Navigation”: Role used when we have an area on the page with navigation links. Equivalent to the HTML <nav> tag;
- Add a label: By defining the “aria-label” attribute, we can assign a title to the element, which is useful to help the screen reader provide quick context to the user, especially when the element doesn’t have a visible title (for example, a tooltip with a small help text). Alternatively, we can use aria-labelledby when the element has a visible title but we want to use the text from another element to assign a title to our element. The recommendation is to use “aria-labelledby” whenever possible to ensure content consistency.
- Add a description: By adding “aria-describedby” to an element, we provide more context on what the user needs to do;
Let user interact with the overlay
At this point, we have the trigger and the overlay, the next step is to set the focus in the overlay. We can use some JavaScript to do that by using the focus() function when the user clicks on the button.
In languages where the element is not hidden in the DOM, you may have the need of using the attribute “tabindex=-1” that will allow an element to be focusable using JS but not using the TAB key of the keyboard.
It’s important to understand that if you have defined “aria-hidden=true”, the screen reader will ignore the element but you can still place focus on it breaking the accessibility rules.
Allow an easy way out
One of the best practices says that the user should be able to exit the modal using the keyboard. For that, again, we can use some simple JavaScript and close the modal.
Tip: don’t forget to remove the event when the overlay is closed and more importantly, return the focus to the trigger element, this way the user can easily continue the navigation that he interrupted momentarily to open the overlay.
Some extra tips
Has said in the beginning, you may be using some language like React that simply don’t put the HTML in the DOM if it’s not needed but, if you are using other languages that don’t use this approach, like PHP, you may have the need of adding some extra attributes to help the screen readers. As I mentioned earlier, certain programming languages, such as React, dynamically manage the DOM. They efficiently render only the necessary HTML elements, optimizing performance. However, this approach can potentially create challenges for screen reader accessibility.
In contrast, server-side languages like PHP generate the complete HTML structure upfront, regardless of whether all elements are immediately visible or interactive. While this ensures that all content is technically present within the DOM, it doesn’t inherently guarantee that the content is structured in a way that is easily interpretable by assistive technologies.
Therefore, when working with languages that don’t dynamically manage the DOM, it’s crucial to take extra care to ensure that all content is accessible to screen readers. This may involve adding ARIA attributes to provide additional context and semantic information about the elements on the page. These attributes can help screen readers identify the roles, states, and relationships of various elements, even if they are not immediately visible or interactive.
–Attribute “aria-hidden”: when TRUE, this attribute will indicate to the screen reader that the element is hidden and therefore it doesn’t need to be read. This way, when you open the overlay, you need to toggle this attribute to FALSE (so the screen reader can read it) and then back to TRUE when the overlay is closed.
– Attribute “aria-live”: if you have in your application, some sort of element that may change without interaction of the user, like an alert or notification, you need to use this attribute. Basically it will “tell” the screen reader that something changed and how the screen reader should react to it:
- By using the value “assertive”: the screen reader will immediately interrupt current reading and warn the user that something happened. Can be useful when an important notification needs to be delivered to the user;
- By using the value “off”: the “off” value indicates the screen reader that it should not interrupt the user, unless user focus on that element;
- By using the value “polite”: the screen reader will wait for the current speaking and then warn the user with the message;
How to test your screens
There are lots of handy tools to help you test accessibility. Some are browser extensions, others are apps, and they can spot things like missing alt text, bad color contrast, or buttons that don’t work with a keyboard. They’re super cool and useful for catching not just common issues but also more complex situations and help you make sure your site or app works for everyone.
Tools:
- Google Chrome extension that allows to evaluate a screen and gives feedback on some best practices, color eros and others;
- Plugin for Chrome that adds an extra Tab to the Developer Tools and helps you identify points of improvement in your screen
- A website that produces a report based on the WCAG 2.1 rules. The nice thing here is that you can paste out the HTML code of your screen, an URL or an HTML file (useful if you need to test some pages that required a login);
These are mostly the ones that I use regularly and they are free. Certainly you may know about other cool tools to use.
Conclusion
At the end of the day, accessibility is about making sure everyone can use and enjoy what you build. It’s not just for checklists or legal reasons, it’s about real people trying to do real things on your site or app.
We don’t have to be experts to start making a difference. Just being aware, asking questions, using the right tools, and thinking a bit more inclusively already goes a long way.
Since I had that experience I shared at the beginning, I’ve become much more attentive and it’s become a lot easier for me to put myself in others’ shoes. I realized that it’s very easy to create bad user experiences, but it’s so much more rewarding to create good ones.
