Naming things is still a common and enduring challenge in accessibility

(Loaded 67 times)

Naming is one of the most difficult and enduring challenges in software engineering, and it is obvious that it’s also a giant problem in accessibility. How can you help?

I understand that naming classes, properties, methods and so on can be challenging when it comes to programming. But, as long as the code works it’s perhaps not a real problem and more a developer experience issue (or business issue by adding costs to development time).

But when it comes to digital accessibility – naming things is crucial. Naming interactive elements like buttons and links and not naming them shows that multiple roles have failed to understand and implement accessibility.

Design, development and content all bear the responsibility here. Not naming interactive elements – or naming them incorrectly – is a very common and very enduring issue that I find in all over the web and in practically all native mobile applications that I analyze.

It’s also a very quick indication of the overall state of accessibility, sometimes all I need to do is to check if the hamburger menu icon has it’s name to know about the overall situation…

Even if we use semantic elements (or components that communicate their role and state), it is not enough. We need to provide proper names to them. Otherwise we risk the experience for some users (screen reader and voice control at least) to be like the following:

  • Link
  • Link
  • Link,
  • Button,
  • Button,
  • Link,
  • Link,
  • Edit blank,
  • Button

Ask yourself – how confusing would a remote control for a new device be, if I had to guess and try what the buttons on it actually do?

A reflection about interfaces with buttons that have no names.

What needs to be done to solve this?

We need the awareness – they why – why is it so important to name things in the first place. And then we need to know how to name them, technically – in the code. And then we also need to know where we can change the names (or translate them).

So – it’s a team effort design can annotate the names, development can implement them and allow content editors to populate/change/translate them. So the team has to be aware of the why and the how. As simple as that.

Now, this is just the basics. There are also other parts of websites and native mobile applications that require naming, for example when we have multiple nav and form sections (sometimes we need to name them), but the most important task with naming is to name all the interactive elements. It’s essential for end users that rely on assistive technologies.

So, awareness, knowledge and then also the process, to systematically name things.

And sometimes, if not often, it’s perhaps best to just use text and have the icon as a decorative visual “hook” instead of relying on our assumptions that “everybody” will understand what we thought with “that” icon. And yes, you are allowed to make this a feature toggle somewhere (perhaps in the profile or settings), so that regular users can decide for themselves if your icons are enough or not.

But please always provide a name for all interactive elements.

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me:

Leave a Reply

Your email address will not be published. Required fields are marked *