Why is UI accessibility so important? What are the most common accessibility issues and how to detect them? In this article, I will provide you with answers to those questions. What’s more, I’ll show you how the Storefront UI library helps to take care of all those accessibility-related errors. Let’s go!
What is UI accessibility?
“The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability. [...] Accessibility is essential for developers and organizations that want to create high quality websites and web tools, and not exclude people from using their products and services.”
This is the definition of accessibility made by W3C. World Wide Web Consortium is the main international standards organization for the World Wide Web.
Why is UI accessibility so important?
Accessible website means that its content and each of its functionalities are available for everyone, including users with disabilities.
Let’s imagine you’re on a page that hasn't fully loaded. Or the layout on this page isn't adjusted to your screen dimensions and you can see only half of its content. Or there are buttons that don't work in a way that you assume and instead of submitting a form they clear it out. Would you like to visit this website again? I doubt it.
And what if this is a government website? Or any other that allows access to important information? Is it okay to exclude millions of people from using a website or app just because they have some kind of disability? No, it’s not.
The same applies to your eCommerce store. You should make your website accessible to anyone who wants to become your customer. If you don’t pay attention to the limitations of your potential clients, they simply won’t be able to become paying customers.
What are the most common accessibility UI issues?
A website can look perfect at the first glance. But trust me, there can be plenty of inconveniences that you don't even think of if you live without disabilities. What are those hidden problems?
According to WCAG (Web Content Accessibility Guidelines) report the most common are accessibility problems are:
- Low contrast text
- Missing alternative text
- Missing input labels
- Empty links
- Missing document language
- Empty buttons
Source: https://webaim.org/projects/million/#wcag
As you can see, these problems aren’t sophisticated and don't require special knowledge to be solved. It’s quite easy to find a solution for them - and yet they are still very common.
Beside low contrast text (this one might depend on the company's branding colors and this is why the decision process may take a bit longer) – the other issues are easy to find and fix. Those are all small changes that can bring lots of advantages to the users and to your business.
How Storefront UI helps with UI accessibility?
Looking at the WebAIM report, you can check how our UI library helps with most common accessibility issues:
- Low contrast text
If you wonder if the selected colors and their contrast is correct, you can easily check it on the WebAIM website. Just fill in your foreground and background colors to see what their contrast ratio is.
You will find out how your colors look with regular text. What’s more, you will find out, if they meet WCAG criteria.
You can set chosen colors quite easily – just follow this tutorial .
- Missing alternative text for images
SfImage component checks if there is an alt text for img tag passed by alt prop. If there’s no alt text, it will mark down an image with a red dashed line.
SfImage without alt text SfImage with alt text
- Missing form input labels
SfInput has a special prop called label, so it’s easy to add any text as input label in one component.
- Empty links
There is a prop link in SfLink, so it’s easy to remember about it and pass the desired link to a tag.
An example of use SfLink component.
- Empty buttons
There are special attributes - aria labels - that can be added to our components. You just need to add aria-label and pass the desired value. You can see such an example in our SfHeader buttons.
How to find accessibility UI issues and what is the role of semantic HTML?
Let’s stop for a while with buttons and one crucial part of accessibility, which is semantic HTML. This part is often forgotten.
Some may think that there is no difference if a text will be put in div or heading. Well, it may make a huge difference for many users and I don’t mean a difference in styling.
Especially if you build a library with components that can be put inside each other, you need to think about all possible ways of how those components will be used. Before we see such examples though, there’s one more question to answer. How to find accessibility UI issues?
There is a special package @nuxtjs/html-validator. If you have a project in Nuxt, you can add it there. For Vue projects there is a “html-validate” package. Also, there is a directory called “nuxt” in our repository. You can find it in “packages/nuxt”. It is mainly dedicated for testing purposes but it has as well the HTML validator package added. It is possible to configure the package according to your needs. It points out not only accessibility errors but also good practices.
And what about your live projects? There are lots of tools and websites (free and paid) that can check if there are any accessibility errors. Everyone can find something according to their needs. One of such websites is https://rocketvalidator.com/. For those who use Storybook, there is a special add-on called “storybook-addon-a11y”. It tests components and shows if there are any problems with their UI accessibility.
Fixing UI accessibility issues in practice
Now we know how to check accessibility issues so let’s go back to code examples.
To create a regular button with an icon you can use two of our components SfButton and SfIcon. Code will look like this:
Looks good. But if we’ll check HTML in dev tools, we can see that div is inside the button. Why is it there? Because SfIcon used to have a wrapper that was a div.
Let’s see what HTML spec says about possible content in button element:
“Content model:"
And regarding it, phrasing content is:
“Phrasing content is the text of the document, as well as elements that mark up that text at the intra-paragraph level. Runs of
- a
- abbr
- area (if it is a descendant of a map element)
- audio
- b
- bdi
- bdo
- br
- button
- canvas
- cite
- code
- data
- datalist
- del
- dfn
- em
- embed
- i
- iframe
- img
- input
- ins
- kbd
- label
- link (if it is allowed in the body)
- map
- mark
- MathML math
- meta (if the itemprop attribute is present)
- meter
- noscript
- object
- output
- picture
- progress
- q
- ruby
- s
- samp
- script
- select
- slot
- small
- span
- strong
- sub
- sup
- SVG svg
- template
- textarea
- time
- u
- var
- video
- wbr
- autonomous custom elements
- text”
It’s a long list but as you can see, there’s no div at all. As the team responsible for Storefront UI, we've struggled for a while about all possible ways of combining components. We had to have in mind that separated components, as well as combined components, should create semantic HTML.
And what about the mentioned differences between text in heading and div?
Heading tags are often used for SEO purposes. Also, they are used because of their styles - there’s no need to add additional font size or font weight. But they also have another very important role - they communicate the organization of the content on the page.
Web browsers, plug-ins, and assistive technologies can use them to provide in-page navigation. Thanks to proper use of headings, assistive technologies can detect different sections and their subsections and move to them quickly. There is no need to go through a wall of text that isn’t in our interest.
If there’re no headings on a page and main topics are in divs without any additional styling, then the navigation on such pages will be very limited. Even for people without disabilities it’s easier and much faster to search a page when there is an order and main topics are somehow highlighted.
The future of UI accessibility in Storefront UI
Looking at what has been done and what we plan for the future, this is only the beginning of our adventure to better understand and improve accessibility in Storefront UI.
We aim to be a library that not only allows developers to reduce development time but also cares about UI accessibility. Even if someone doesn’t know much about it, with our help good practices will be applied along with components.
If you would like to learn more about accessibility or about any other topic related to Storefront UI , go to our GitHub and become our contributor. We are waiting for you!
.png)
