5 accessibility mistakes you might not think about

At GRRR we aim to create accessible and inclusive websites: it's important to us that anyone can visit and use them. Learning about accessibility is something we continue to do each day. We've written posts about accessibility before, but in this article, I want to take a closer look at some accessibility issues that you might not be as familiar with.

1. Forgetting about speech recognition

When thinking of accessibility, a lot of people think about screen readers. But did you know some people use speech recognition tools to navigate the web?

Speech recognition can be used for dictating text, or navigating to and activating links, buttons, and other controls.

In order for this to work well, labels and identifiers for controls need to match their visual presentation, in the source code. In that way, it is clear which speech command should activate what control.

We recently bumped into this issue where we prefixed button labels with “More information on…”. The button, on the other hand, would just show “plastic”. The prefix was not a part of the visual label but was hidden with CSS. This was done to give more context to screen reader users.

<a href="/en/plastic" class="button">
    <span class="screenreader-only">More information on</span>
    Plastic
</a>

The button’s accessible name is “More information on Plastic”, while the visible label only shows “Plastic”.

Now the accessible name no longer matches with the visual label of the link. As a result, visitors using voice control are not able to activate these links, because they will actually pronounce: “Click on button ‘Plastic’”, which is not a valid button label in the DOM. We can fix this by removing the hidden text, or make the hidden text visible:

<a href="/en/plastic" class="button">Plastic</a>

<a href="/en/plastic" class="button">More information on plastic</a>

Takeaway: Always make sure that a link’s accessible name includes its visual label, preferably at the beginning of the label.

2. Letting hidden items be focusable

Hidden items are very common in web pages. You usually run into them when facing accordions with collapsed sections or navigation overlays. A problem occurs when these hidden sections contain links or other focusable elements, such as buttons, form controls, etc.

When visitors use their keyboard to navigate through a page, the focus is also placed on links or buttons that are not visible. For instance, taking the accordion example into consideration: the links are visually hidden behind the collapsed accordion items.

Elements like these, that are not visible, should not be in focus order. Keyboard users who can see the screen will not know where the focus is placed. Annoying, isn’t it? Prevent this issue by ensuring that hidden links or buttons can only receive focus when they are visible.

You can achieve this by adding a negative tabindex to all focusable elements when the parent is hidden:

<div data-is-hidden="true">
    <p>
        Sed a libero. Vestibulum turpis sem, aliquet eget.
        <a href="/en/plastic" tabindex="-1">plastic</a> convallis.
    </p>
    <button type="button" tabindex="-1">Pulvinar</button>
</div>

3. Not configuring embedded iframes

A lot of websites use embeds. Think about those nice Youtube or Vimeo videos. When embedding third-party functionality, there are some things to be mindful of:

When you’re embedding content through an iframe, always be sure to provide a title for that iframe. When an iframe has a title, screen reader users can request a list of frames and learn what the iframe is about. Without a meaningful name, a screen reader user may just only hear “frame”, the name of the file or the path of the iframe.

<iframe title="Guidelines explanation" src="youtube-video.html"></iframe>

It does not stop here though, video players usually have controls/buttons. Usually these controls have (accessible) names. Offer these elements in the main language of the page, (in our case usually Dutch or English), or indicate a language switch for the buttons. The former is preferred, as it makes the buttons easier to operate for visitors using voice-guided navigation. If we take Youtube as an example, you might notice that it defaults to the language setting of your browser. To make sure it matches the language of the document you can set the hl query parameter:

https://www.youtube.com/embed/XXXXXXXX?hl=NL

Another thing to consider is key operations: some video players, such as Vimeo, use single-character key operation. For example, you can press f for full screen. This functionality can get in the way of people who depend on speech software as they rely on those short commands to operate their computers with speech software. Make sure that this command is disabled or can be disabled. With Vimeo, you can achieve this by changing the 1 behind the parameter keyboard to false. Or with YouTube, set disablekb to 1.

<iframe
    src="https://www.youtube.com/embed/HMU4fNHwT4A?disablekb=1"
    title="Working at GRRR"
></iframe>

<iframe
    src="https://player.vimeo.com/video/728822014?keyboard=false"
    title="Working at GRRR"
></iframe>

4. Using native form validation

Forms can use native HTML5 field validation. However, these error messages are not equally well-supported by all browsers and assistive technologies. The message is sometimes short or incomplete. Additionally, the text size cannot be adjusted. And when zooming in, the text size remains the same. These messages also disappear rather quickly. So, some people may not be able to read the text.

Moreover, by default, the error message does not provide any suggestions as to how visitors can resolve the error. Luckily, you can create custom error messages. But unfortunately, that doesn’t solve the previously mentioned issues. Therefore, add your error messages to the form to solve this problem.

Further reading: A Guide To Accessible Form Validation

5. Wrapping a lot of content in one link

A common pattern we often see is cards or modules that contain a link that acts as a wrapper of content. This <a> element can contain an image, headline, and additional text, which means the entire link consists of these elements.

<a href="/flower-seeds">
    <img src="/flowers.jpg" alt="Field of red and white flowers " />
    <h2>What are the best flower seeds to sow in spring?</h2>
    <p>Spring is the best time to sow warm-season annual flowers.</p>
</a>

This makes the link text cluttered and difficult to understand for visitors who use a screen reader. Alternatively, you can place the <a> element at a location that makes more sense, in this example within the heading of the card:

<article>
    <img src="/flowers.jpg" alt="Field of red and white flowers " />
    <h2>
        <a href="/flower-seeds"
            >What are the best flower seeds to sow in spring?</a
        >
    </h2>
    <p>Spring is the best time to sow warm-season annual flowers.</p>
</article>

Now you can use CSS to make the entire card clickable again:

@mixin expand-clickable-area {
    position: relative;
    &::after {
        content: "";
        position: absolute;
        top: 0;
        left: 0;
        width: 100%;
        height: 100%;
    }
}

h2 {
    @include expand-clickable-area;
}

Normally you would apply hover styling to the <a> element. That won’t yield the same results when you take this approach. To achieve the same effect, you could add this styling to the <article> instead. You can add really intrincate hover effects, and very clear focus styles. Just keep in mind that hover and focus styles should be accessible as well (think about color contrast, readability etc).

Conclusion

We hope this article has given you some insight into some of the lesser-known aspects of accessibility. Make sure to check out other articles in our accessibility category for more information on this topic.