Last monday, I visited Wehkamp. They boosted the pagespeed of their productpages after taking part in a Google Speed Race and ending up second.
As a result, I tested their productpage on sitespeed and accessibility. Beside some sitespeed findings, we also discussed accessibility of a productpage.
You might ask why accessibility is important when you're not a governmental organization. Some reasons why you might want to address accessibility:
- it has overlap with mobile web design and usability;
- semantically build websites are better for SEO;
- you are minimizing legal risks when digital accessibility laws are effective;
- your webshop will reach more people (such as visually impaired or users with motor disability, like Parkinson disease).
Let's dive into the accessibility lessons we can learn from a productpage like the one of Wehkamp.
Visible focus
Often the outline of buttons is being hidden on purpose, due to esthetic choices. However, an outline provides clarity to users, to users using a keyboard for example. Using a keyboard isn't always done voluntary.
Many users are physically unable to use a mouse, and need to navigate through the page using only the keyboard.
Mary Gillen
Within Wehkamp's productpages, it isn't always clear where the focus is when navigating through a page using a keyboard. For example, the button for picking a productsize or adding the product to your cart doesn't get clear focus. However, these are the most important buttons for conversion.
Solution: adding a CSS outline or alternative visual confirmation on focussed elements.
Keyboard trap inside the slideshow
Using the tab-key to navigate, also causes issues when reaching the image player. This image slideshow, which allows users to scroll through product images, is trapping the keyboard when it is reached using the tab-key. It only does so, when not navigating fast enough.
The reason is an endless configuration within the slideshow, which allow users to keep sliding through the images, without the need to hit the left-key to go back to the first image. The endless loop is being created on the fly as a user is navigating, but prevents a user from stepping out of the slideshow.
Solution: allowing users to navigate through the slideshow's images using left and right key only. When the tab-key is being pressed, the user should step out of the slideshow.
Closing menu's and dialogs
When opening dialogs or menu's, for example for showing available sizes, enlarging a product photo or dropdown menu, it is common to close them using the escape-key. This way, it is easy to close an action and proceed with navigating.
In the case of Wehkamp, some dialogs can't be closed this way. The user has to navigate to exactly the same button, which allowed them opening the dialog in the first place. This will slow down keyboard users just a little bit (if outline of focussed element has been addressed in the correct way). Users using a screenreader, have to wait for each element to be spoken out loud, to be sure they reached the same button which was responsible for opening the dialog in the first place, to eventually trigger it again to close it.
Starting all over again
For other dialogs and dropdown menu's, the focus is brought back on the very first element within the document, instead of the element where the user started opening a dialog or menu. This is not only confusing for users using a keyboard, but even more confusing and frustrating for users using other assistive technology.
Solution: using JavaScript, fetch and save the interacted element. Adding an event-listener to the escape-key on dialogs and dropdowns, the focus can be brought back to the saved element.
Site search on mobile
When the search bar receives focus on mobile, it is blocking the whole screen with a white background layer. In the meanwhile the user is able to keep navigating through the website while the search-screen isn't being closed, not allowing users to see what they are doing.
Zooming or scaling text
Sometimes for the same reason as omitting an outline on focussed elements, zooming a webpage on smartphones is being disabled. However, for usability as well as accessibility, allowing zooming is a best practice and even obligated when you have to abide to WCAG 2.1.
Solution: configure user-scalable to yes when setting the viewport metatag.
Skipping content
Wehkamp has introduced a skip-navigation button for screenreader users. This button will only become visible when it is receiving focus. This is quite common behaviour.
A productpage often has listings for related product or earlier visited products. As these listing can become quite long, you can help visitors using assistive technology by adding skip-links here too.
Solution: Before entering long listings, a button can be added to skip past the listing.
Need to address accessibility or want to discuss the accessibility of your webshop?
