Accessibility of Search Feature and Images
I’ve recently studied more about accessibility problems, so why not have a look at a real project somewhere on the internet and see what it can offer when it comes to accessibility. I’ve found a new e-shop platform and chose their search feature and images as a subject for my brief testing session.
When we talk about accessibility, it can be translated into building systems that are inclusive. That is that different people can use them. We can talk about people who have problems with their vision, or simply about someone who prefers to use only a keyboard (IT people, including me, can say a few things about this :)).
I good website to learn more about accessibility (a11y for short) is webaim.org. The whole a11y field can be roughly divided into the following topics:
- content and structure of the system
- keyboard usage
- image content and text alternatives
- colours and contrast ratios
- media accessibility — documents, videos, audios
I’ll mostly focus on keyboard usage and images in this post.
I’ve chosen sporttown.cz as a system I’ll have a look at. It’s only a random e-shop I’ve found, I have never seriously tested it, nor do I have any affiliation with the company.
To narrow down my test session, I’ve chosen their search feature for my testing:
I might look up at other areas later on.
My initial model after a tiny recon session is that the search feature works like this:
When I type something into the search box, I can go to a listing page, directly to a product detail page, or to a category page.
Now I’ll get back to a11y and start with a keyboard. Webaim.org mentions: “Ensure that all content can be accessed with the keyboard alone.” (webaim.org/techniques/keyboard/)
When I take my hand off a mouse, refresh a page, the first observation I made is that I can’t see what element has focus. So, right after getting to the page, I’m a bit confused and lost. But I press Tab key in order to find where the focus is. What happens is I can see a focus indicator on the Sign In link:
But I wanted to search for a product, not sign in. Hm. It seems like the seach box was skipped. I also tried presing Shift + Tab to move the focus back, but the search input box never got focused. That seems like the first big issue in accessibility because anyone who uses only a keyboard won’t be able to search at all.
However, after some further exploration later on, I found that I can in fact reach the search input box. It’s just I have to first press Tab a few times and then go back with Shift + Tab a few times, the path can look like this:
So technically I can reach the search input field, but this is not intuitive at all, it feels like this feature works by a happy coincidence, not by design.
After looking into the DOM, I can see that the Sign In (and Cart) link preceeds the search input, but on a real page, it’s the other way around. That’s why I can reach the search input by tabbing (even without using Shift + Tab), but I have to tab three times, which is not natural for people who are used to reading from left to right.
The solution should then be quite easy — swap the order of the elements in the HTML so they follow the natural order from left to right and top to bottom.
If you are confused after this text, I’m with you :) This is clearly something that was not given much thought when building the e-shop.
Let’s then use a mouse for focusing the search box. I’ll type in “obuv” (shoes in Czech), which will open an autocomplete:
There you can see I can either go to a concrete product detail page, to a category, or I can click the button at the bottom and go to all result (listing) page.
Webaim.org mentions that with autocompletes like this one, I should be able to use only a keyboard. Arrows up and down for navigation between items and Enter for selection.
In fact when I press arrow down key, nothing happens. The focus is still inside the seach input field, not on the first item in the list. When I press arrow up key, the cursor moves in front of the first letter in the search box, not on any of the items in the list. When I press Enter, I land at a listing page as if I clicked the orange button at the bottom of the autocomplete.
Again, using only a keyboard for the autocomplete is severely limited to only one action. People who can use a mouse can perform three actions here.
Another problem might be with the form control HTML. The search input field is implemented like so:
<input autocomplete="off" class="FormControl js-autocomplete-control" name="search" type="text" placeholder="Zadejte, co hledáte...">The form control has not associated label, nor does it have a title attribute, not any ARIA properties. There’s at least a placeholder attribute, but that might be confusing to some screen readers.
Since my first test session was focused on the seach feature and using a keyboard, I can more or less finish it here. It seems only a keyboard will make the search feature unusable, therefore severely limiting accessibility for some people.
Let’s now have a look at pictures and alternative texts. You can read two articles on Webaim.org (webaim.org/techniques/images/ and webaim.org/techniques/alttext/) on this topic. I’ll try to simplify what they say in a couple of points:
- contentful images should have an alternative text so people who use screen readers can consume such a content
- decorative images should have a null alternative text (
alt="") - the alternative text should consider the picture’s content and function
These points are key, although there are further topics such as icons, interactive maps, etc. but I’ll leave all that aside for now.
Let’s first have a look at the logo of the site. In HTML, it looks like this:
<img src="/common/img/logo.svg" alt="" width="208" height="40" loading="lazy">That is a null alt text. Such an alt text will not be read by screen readers. This is probably not the most important thing since screen readers will read the page name from <title>, but it might be sometimes useful to hear the company’s name from the logo’s alt text because such a logo is usually clickable at some pages and can take you back to homepage (this happen on this e-shop as well).
Just a quick intermission here: Can you see another problem with the main picture?
Yes, it’s lazy loaded. But it’s the LCP element. A good practice says LCP elements should not be lazy loaded since that can prolong the same metric.
Let’s see more pictures, for example at a product detail page:
Again a null alt text. And there’s no surrounding text that could be picked up instead. This is not ideal because screen readers will have nothing to go by here. The picture is also a link, and when I have a look into the accessibility tree, it says ignored:
That’s not ideal at all. This is the main product picture, therefore it comunicates some content that users will likely be interested in. Clicking the picture also takes me to a gallery. Yet it’s all ignored in the accessibility tree because there’s a null alt text.
Using Overrides in Chromium, I can try changing the alt text to something meaningful:
That helps and the picture and link will make it into the accessibility tree. Screen readers will now announce it.
This alt issue is a bit strange from another perspective as well. When I search the DOM for other alt texts, I can see, for example, this node:
<img src="/data/cache/thumb_50-50-12/categories/1567/1636295215/lplu108808_1.jpg" alt="OBLEČENÍ" loading="lazy">That’s a picture in a menu that’s hidden now. It’s not like they forgot all alternative texts, only some are missing.
Up until now, I have done everything using only Chromium DevTools. This is a good approach when you also want to learn about how a11y testing could be done, but once you know what and how to look for, you can start using some tools that automate some parts of this a11y testing.
One Chrome extension that could be used is WAVE. When activated, it will perform an analysis of the current page:
You can immediately see that it marked the main picture because an alt text is missing.
Another tool I’ve been using here is Accessibility Insights for Web. You have seen this one in action when I visualised how the tabbing path works in one of the pictures above.
There are likely many other tools I don’t even know about. It’s not that important for me to know them all, if I need some tool, I’ll iterate towards it as I keep testing.
That’s it for now :) Obviously I can keep testing for a11y problems, but I’ve limited myself for the search feature and some pictures, so I’ll wrap it up now.
One takeaway could be that a11y is not automatic. Even if a site looks nice, it doesn’t mean it’s inclusive and everyone can use it. There are many different GUIs based on who is sitting in front of the system — if it’s a person who has no vision, your beautiful GUI is useless.
Being aware of such problems can mean a big difference, especially when we know early on in the development, so there’s still time for designers and developers to take action.
