The 5 Short Frontend tips for November

The button role isn't enough for an accessible interface

There is a practice of overriding the button's default role. It's a bad practice already because authors of the ARIA in HTML standard prohibit overriding of default roles in section 2.1.

But in addition, people think if they define role="button" this element becomes accessible. Yes, it's true for screen readers. But that's only one case!

This "button" isn't accessible for a keyboard. Users can't focus on this element using the tab key. Also, this "button" isn't accessible for interaction using the enter or space keys.

So if you want to define role="button" don't do that. Just use the button element.

don't do this

<div role="button">Go</div><!-- or --><span role="button">Go</span>

you can use it instead

<button>Go</button>

The bigger clickable area the better user-friendly interactive elements

When we design interactive elements we have to think about how users will interact with them, in particular, a clickable area.

That is important because users use different kinds of interactions. I often see designers and developers make a clickable area that is equal sizes of the element.

It's nice for users who use a mouse. But that's a big problem for other users. If users have a motor disability click on such an element is a nearly impossible task,

Sometimes I can't hit on such elements when I tap on them using a finger. Also outline around elements has not enough contrast, if I focused on them using a keyboard,

But we can solve these problems easily. Just we should design more largest clickable area that will not conflict with other elements around.

The aria-labelledby simplify navigation for users of screen readers

Any web interface has a lot of sections that help users without vision disabilities orient at the page. We just see headings and understand that is a section and also its sense.

But some users can't see. They use the special quick navigation mode known as "Regions list" in screen readers. In this mode screen readers display all regions on the page. So users can go to any by some taps.

Unfortunately, there is a problem that is section elements aren't displayed in this mode until we associate section heading with a section using the aria-labelledby attribute.

So we have to add the id to the heading and add this as a value to the aria-labelledby attribute that is defined for the section element. As a result, this section will be added to the regions list and users will know about it.

don't do this

<section>  <h2>About me</h2>  <p>Lorem ipsum, dolor sit amet consectetur...</p></section>

you can use it instead

<section aria-labelledby="about-me">  <h2 id="about-me">About me</h2>  <p>Lorem ipsum, dolor sit amet consectetur...</p></section>

Focus moving is underestimated

We don't think about what to do with focus when we design elements that appear after user actions. Or, more specifically, we just do nothing. Therefore there are 2 problems.

Firstly, we cut off the possibility of more quick interaction. For example, when we log in on Groupon we have to focus on the input field to start filling in the form.

Instead, when we go through the same case on Pinterest focus moves to the first input field automatically. So we can start filling in the form without additional actions.

Secondly, if users have vestibular disabilities login becomes an impossible task because in this case, they lost the possibility of using a keyboard. For example, when we push on the sign in button on Groupon focus doesn't move inside of the form. It's lost just.

For these reasons, we have to design our interfaces with the thought of how focus should move. In this case, our interfaces will be accessible for more users.

Improving accepting the Cookies Policy using focus

A last years there is a popular pattern when users have to accept Cookie Policy on websites. So I've wanted to research which solutions are and how they affect user experience. Let's talk about it.

The typical solution is on the Fred Perry website. Users can see text with a link on the cookies policy and an accept button. When we use this kind of solution we have to use mouse, touchpad or others devices for pushing on a link or button. So we do additional actions.

Also there is another solution on the H&M website. They set focus on the cookie policy link. The prop of this solution is users can consult with the policy if we just push the Enter key. When they want to accept the policy we push the Tab and Enter keys. We haven't to take in hand mouse or use the touchpad.

The problem of this solution is a lot of users read the policy already and don't want to read it again. They just want to accept that.

So I suggest to set focus on the accept button. In this case we quickly accept that using the Enter button. And if we need to read the policy we just will switch on the link using the shift+tab combination and then we'll go to read of policy by pushing the Enter key.

P.S.
Thank you so much, my sponsors: Ben Rinehart, Sergio Kagiema, Jesse Willard, Tanya Ten, Spiridon Konofaos.

Also I tell stories from my career on Substack. Join my free newsletter, if you're interested in my background