WCAG criterion 4.1.2 – Name, Role, Value (Level A) part 2

Last time, we discussed the difference between links and buttons and button states. Based on your suggestions in the comments, we’ll now look at a visual comparison between a link and a button. How can their appearance impact digital accessibility?

The most important rule when designing and implementing elements is consistency across the website.

We shouldn’t implement a button on one page that looks completely different on another page (in terms of shape, colour, graphics), while serving the same function or purpose. It’s crucial to distinguish links from buttons visually.

This usually looks like this:

🔗 Link:

• Usually underlined (or highlighted in some other way, like bold or color – but remember about proper contrast).
• It’s typically text but can also appear as a graphic.
• The link’s color often changes after it’s clicked or is highlighted in a different color if we’ve visited the page before (commonly, this is purple by default).

🔘 Button:

• Often takes the form of a clickable object, usually rectangular, with text or an icon inside.
• Its appearance depends on the designer’s creativity: it could have shading, a border, and can be highlighted with various colors (watch out for contrast 😉), with colors often symbolizing different actions (e.g., green for “confirm,” red for “cancel”).

Do you often come across links that look like buttons and vice versa?

Back to buttons. It hasn’t been explicitly stated, and while it seems obvious, it might not always be!

Remember, every button should have its own label. If a user cannot immediately tell what function a button serves, there should be some assistance provided. Why is a button label so important?

It’s crucial for every interface element to be clear and unambiguous. For users of assistive technologies, like screen readers, a missing button label means missing information about its function.

Instead of learning that a button closes a window, submits a form, or opens a menu, the user might only hear “button,” which is unclear and ineffective.

So, what can we do?

Aria-label attribute: In many cases, using the aria-label attribute is a better solution than relying on the title attribute. It directly informs assistive technologies (e.g., screen readers) about the button’s function. Aria-label can be used when the button has no visible text, such as for icons like “close” (an X), “add” (a plus), or other symbols. Example:

<button aria-label=”Close”>✖</button>

Problems with the title attribute

Although the title attribute might seem like a good way to provide extra information about a button, it doesn’t always work correctly. Some issues include:

• Incompatibility with screen readers: In some cases, screen readers ignore the title attribute or read it incorrectly. PowerMapper’s tests provide more details.
• Lack of visual cue: Information from the title attribute only appears when hovering with a mouse, meaning that keyboard users and those on touchscreens might never see it.

An alternative to the title attribute could be properly implemented tooltips that work for all users (keyboard, touchscreen, screen readers, and mouse).

Wow, criterion 4.1.2 really is a deep topic. How many more posts will we need? 🤔 Time will tell.

Have a great weekend!