After the advent of JavaScript frameworks and libraries, making web interfaces is way easier, so now it's common for frontend engineers to underestimate HTML and claim they know it well. However, after spending some time working on accessibility improvements, I've realized how ignorant many of us are about the markup language.

While much is said about semantic tags and their use, practical testing often reveals that we use them without even knowing what the tag means to the browser or screen readers.

Elements that don't behave

Frontend engineers are typically used to developing interfaces assuming that every user can navigate using a mouse. This works well when using native tags like <button>, but when we need other interface elements to behave similarly, it's undeniable that we fail to assign specific functions to these elements. For example, if I need an element in my interface to be accessible like a button, theoretically, this element should be accessible via the keyboard. And you might think that simply adding a role and tabindex to this element is sufficient, of course.

However, in practical testing, the browser identifies this element as a button, but we often forget to add keyboard events to these elements, rendering them inaccessible, even if they are now focusable.

If you have no idea what I'm talking about here, you should urgently start testing your interface with the help of a screen reader, it's the only way to know how the browser is interpreting the interface you're developing.

Messing everything up with aria

When we need to provide additional information to elements, we use the aria properties. I will spare you from saying how many absurdities I've seen in code related to that.

Adding aria properties to elements doesn't change the application's visual appearance, but under the hood, you're leaving some users completely lost, not to mention the variety of incorrect possibilities for adding an ARIA property. Again, the only way to know what you're telling your non-mouse user is by using assistive technologies.

Being careless with old techniques

I won't delve into the topic of forms because it's quite embarrassing to see form fields without an associated label in 2024. Users who rely on assistive technology simply don't know what to do or what information to enter in the field. And this is basic.

Does this happen? Yes, and very often! And why? Because visually, your label is there (of course, you probably can see it). But try opening your screen reader and navigating to a text field without an associated label, it's frustrating for the user and embarrassing for you.

What now?

The point I'm trying to make is that many of the problems I've been facing are basic things and basic resources that should be used from simple, overlooked HTML.

If you're a frontend engineer and care even minimally about what you're delivering in your day-to-day work, I suggest getting to know and using more of these resources, understanding better the construction of the interface elements you're designing, talking to your design team to help them arrive at an accessible solution, put yourself in the shoes of others, and try using what you're creating the way they interact with it.

If you are a web experience designer and you're about to deliver that wonderful prototype, but your colleague on the other end implemented it poorly, I have bad news for you. It is essential and should be part of your job to test the interface, check accessibility, and be aware of the aspects mentioned.

I'll leave some links where I spend my time to get the information to design interfaces accessibly, and if you, like me, are reading this and find yourself completely lost, wondering where to start, leave your message, and I'll be happy to make you feel embarrassed about what you've built in the past.

Web Accessibility Initiative
Huge documentation about HTML elements
Pattern's documentation for interactive UI elements