The internet plays a substantial role in most people's everyday lives, and if retailers don't have an accessible website they could be turning away thousands of potential customers.
The Centers for Disease Control and Prevention (CDC) in the United States estimates that as many as 27 per cent of adults in the United States have some form of disability. Many of these users have different requirements for accessing the information and services they need and retailers should be mindful of how they can help make those available to them.
So here’s a breakdown of some common accessibility issues and how we can address them.
Colour contrast issues arise when two or more colours on a page aren't distinct enough from each other to be noticeably different and readable. For example, light grey text on a white background.
Can you read both hellos above? Probably not – neither passes the Web Content Accessibility Guidelines (WCAG) minimum contrast ratio, although the second is easier to read than the first.
It's not just about shades of grey though – according to Colour Blind Awareness approximately 1 in 12 men (8 per cent) and 1 in 200 women are affected by Colour Vision Deficiency (CVD or Colour Blindness). That's a lot of customers you could be pushing away if you don’t optimise your website for them.
The most common type of CVD is red-green vision deficiency, where it's difficult to distinguish between some shades of red and green, but there are other types that can affect how users interact with your store.
To avoid contrast issues start by looking at your designs. If you're using Figma, you can use a plugin like the A11y - Color Contrast Checker to ensure your text is visible – it even provides sliders to help you adjust your colours until the contrast is high enough to meet the WebAIM guidelines.
Your store isn't static though – it's regularly updated as new product ranges are launched and as sales come and go. It’s therefore important to make sure contrast issues aren't introduced as the store grows and your content changes.
Regularly run some of your more popular and frequently updated pages on PageSpeed Insights, which can flag accessibility issues. To flag these issues at scale though you can look to tools such as SortSite by PowerMapper.
If you want to get a sense of how people with different vision deficiencies could be experiencing your site, Chrome DevTools has vision deficiency emulation built in, including different types of colour blindness, and blurred vision.
By using these and interacting with your site you can find issues manually. Addy Osmani talks about emulating vision deficiencies in DevTools here.
And don’t rely solely on visual representations of colour – if you have colour swatches for your products, for example, text labels with the colour name written out can be a super useful way to help customers distinguish between them.
Too much motion on your site can cause dizziness, headaches and nausea, and these symptoms can last long after your animations have finished.
Vestibular Disorders caused by damage to the inner ear can cause these symptoms and according to the Vestibular Disorders Association "as many as 35 per cent of adults aged 40 years or older in the United States – approximately 69 million Americans – have experienced some form of vestibular dysfunction".
According to The Guardian, frequent zoom slide and parallax animations in iOS 7 made some users sick and led some organisations to recommend that "people with such conditions don't upgrade their iOS devices". As a result, Apple replaced zoom effects with crossfades and made various other adjustments to aid people using their devices.
Even if a user doesn't feel dizzy after viewing transitions on a store, they could be distracting. If they're in the middle of a critical task, an animation elsewhere on the page can steal their attention, or disorient them completely.
Val Head, a principal designer at Adobe, suggests animations should be purposeful. For example, a menu that slides away as a submenu slides in helps to inform the user the menu is still there, it's just moved away to make space for the submenu.
Dennis Gaebel, an SVG animation and visual design specialist writing on The A11y Project, recommends that animations shouldn't start automatically – indicators should be used to help guide expectations when actions are performed and all animations should be able to be turned off.
In modern operating systems, users can opt-in to reduced motion, which developers can then use to implement safer animations for them. If, as an example, you have an animated element that follows the cursor as a user navigates the page, you might simply add the following code to hide it for customers who've opted for reduced motion:
Google has some more examples of prefers-reduced-motion and how this can be used here.
You shouldn’t just rely on prefers-reduced-motion though. Not all users know the setting exists - this means we can't safely assume everybody who hasn't opted into reduced motion wants lots of motion.
Many articles also suggest a brute-force approach to managing prefers-reduce-motion that looks something like this:
This code attempts to make all animations practically non-existent. As Michelle Barker notes in Smashing Magazine, "reduced motion doesn't mean no motion".
Animations can be used to help users if, for example, they submit a form with an error. By highlighting the problematic field in red and scrolling it into view it can help them identify the problem and understand where they've been moved to on the page.
You probably know that there are six levels of heading supported on the web – h1 through h6 – and these should be used to structure the content on each web page. There should only be one h1, which describes the main content on the page, and as many of the other heading types as needed.
If you imagine a table of contents in a book, the title "Table of Contents" would be a h1, and any top-level chapter headings would be h2s. Indented sub-chapters would be h3s or greater, depending on how many times they've been indented.
Blind or visually impaired users often rely on screen readers to read and navigate websites. Screen readers can list headings on a web page and allow users to skip straight to them. According to a 2021 survey by WebAIM, 67.7 per cent of screen reader users use headings to navigate pages – for those with advanced screen reader proficiency this is reportedly as high as 76 per cent.
Headings are semantic elements but they don't all have to have the same styles. For example, if semantically a heading should be a h3, but it looks more like the h5 headings used elsewhere on your site, this doesn't mean you should use a h5 instead. Just use a h3 and style it to look like a h5.
Content like the above is often implemented in code as two headings, but this is wrong. In this example "Winter Sale" is a heading, but "Your favourite brands for less" is just regular text. Your code should be marked up to reflect that, for example with a h1 for "Winter Sale" and a paragraph element for the subheading. You can also group the two inside a header if appropriate.
Designs often don't include a heading for every section of the page, but this can lead to headings being skipped. For example, on a collection page "Gold Necklaces" might be used for the h1, and then all products in the list have a h3.
We've skipped a heading level here though – h2. Even though there's no heading in the designs you can add a visually hidden h2 called "Product List", in this instance, which will help screen reader users navigate straight to the products.
This is perhaps the most difficult for developers to address directly in code. In most CMSs rich text fields allow all headings to be used – this often leads to heading levels being chosen for their style rather than their meaning. It's difficult to prevent this altogether though, so our suggestions are:
Alt text is used to describe an image on a page, typically for users who rely on screen readers to navigate the web. This is particularly important when an image is required to understand a piece of content.
For example, if an image shows a graph comparing two products alt text should be used to describe the graph to those using screen readers – especially if the graph is not explained elsewhere in the copy.
The biggest mistake with alt text is simply not to provide it. This can be extremely harmful to those relying on it. It can be difficult for large websites to ensure all images have alt text, but this doesn't make it any less important.
Another common mistake is to attempt to automate creating alt text by using a page, product or article title instead of an actual description of the image. Whilst this will ensure images always have alt text, it often leads to images having alt text that isn't descriptive of the actual image.
In the worst cases, automation can lead to images with completely inaccurate alt text – for instance, a blog post which includes images all featuring the name of the article as the alt text, rather than descriptions of the individual images.
In other cases, automation can lead to imprecise alt text. Take for example an image gallery showing different parts of a watch – whilst “gold watch" might technically describe what's in the image, it doesn't help people using screen readers understand what each image is meant to show them.
It would be more worthwhile to have "front of gold watch", "back of gold watch" and "gold watch strap" for each image. Remember that just because somebody is using a screen reader doesn't mean they can't see at all.
It's impossible to say how much detail every piece of alt text should contain – it all depends on the context and the message being conveyed.
This Gov.uk article gives a few tips for writing effective alt text, suggesting it should be specific and concise, and that you avoid repeating information in alt text if it’s already described in a caption.
Jake Archibald, a principal engineer at Shopify also wrote a great article about the importance of context in alt text. He highlights how an image can have a different meaning depending on where it’s being used, and so the alt text might change as a result.
We recommend using automated tools such as SortSite, which we mentioned earlier. These tools will look through pages on your website and flag any images without alt text.
Relying on automated tools might not solve everything though. If you've added inaccurate or non-descriptive alt text to any images these won't be flagged as issues.
Manual reviews of existing content are another good option. Existing content can be prioritised depending on your needs, for example on an ecommerce store you might start by reviewing the homepage and most popular product pages, and leave your blog posts until last.
This is a very broad-ranging topic that has many potential issues. As a general rule, you should use the appropriate HTML for your components to take advantage of built-in accessibility features in browsers. Doing this means you don't have to implement accessibility features manually, or worse – miss them out entirely from your website.
Which of these is a button? Both should be buttons but only "share" is. "Add to bag" uses a generic "div" element instead that's been styled to look like a button. Even though they look the same, using a div instead of a button here has hidden costs.
Div elements aren't focusable, which means when using the "tab" key to navigate "Add to bag" is skipped entirely. If you rely on a screen reader to understand page content, finding where to add a product to your bag is going to be a challenge.
Even though JavaScript is used to add a product to the cart on click, the browser doesn't know this div is meant to act like a button. Even if a screen reader user does find it, they aren't told it's clickable. Browsers also automatically trigger click behaviours on buttons when a user presses enter – they don't do this for divs.
The "Just Use Button" video in the Google A11ycasts series demonstrates some of these issues and explains why it's easier to use a button from the start.
Tables have played a huge role in the history of the web but nowadays some developers will go to great lengths to avoid using them. As layout systems such as Flexbox and Grid have been introduced it's become tempting to use those to create tables, rather than wrestle with the quirks that come with native HTML.
Styling elements to look like tables instead of using the right HTML makes the data difficult to navigate with screen readers. A correctly marked-up table will announce the number of rows and columns when accessed.
Users can then navigate the table with their keyboard, and the screen reader will let them know where they are in the table. The row and column headers, along with their position in the table will be announced as the user moves through it.
When written correctly, tables can also be used to display more complex data than a lot of developers realise. The Web Accessibility Initiative has a few tutorials for different table layouts here.
The "Accessible Cart Tables?" post by Adrian Roselli is also a great learning resource for complex table layouts. Roselli discusses how you can address differences between various screen readers when working with tables.
There is no silver bullet to fix accessibility issues on the web. Ensuring your site stays accessible involves a commitment from everybody involved in maintaining it – from the developers to the content managers.
There are tools out there that can flag accessibility problems, but remember, you can't rely on these tools to catch everything.
Plug-and-play widgets exist that can add accessibility features and fixes for you too, such as adding text size controls and colour adjustments. These widgets can't reliably solve every problem though – for example, alt text on images require manual oversight.
Here are a few steps you can take to make sure you stay accessible in the future:
Before any new content is published or code is changed, have accessibility reviews in place to catch and resolve any problems.
These audits can flag issues that slip through the net, which means you can fix them as soon as they get flagged.
Ultimately you're making a website accessible for your users, not for tools. Gathering feedback from your visitors, perhaps through a survey, is the best way to find out how to accommodate them.
By Association Only is the Shopify Plus agency for the world’s most design-conscious luxury brands. Get in touch to discover how our team of experts can support your brand’s Shopify ambitions.
By Association Only has won its fourth Awwwards site of the day title, this time for our work with luxury sneaker brand P448.
From made-to-order luxury bridal gowns to more affordable ready-to-wear bridesmaid dresses, we take a look at the bridal stores using Shopify to sell their pieces.
%20(1).jpg)
Last week By Association Only hosted its annual summer soiree at Coal Office in London. Read all about it here.
.jpg)