A few days ago, the Dev Community did another #DevDiscuss on Twitter to find out what a good UI/UX design means to their followers.
Someone mentioned that carrd seems to be a pretty good UI UX design for them.
I was curious. I had to check it out for accessibility. Because to me, a good design means that it is completely accessible. Otherwise, how can you talk about a good user experience if there are people who can't use the app properly?
Table of content
- Setup and Accessibility Tools
- Navigating with Keyboard
- Zooming and scaling should not be disabled
- Elements Must Have Sufficient Color Contrast
- Links Must Have Discernible Text
- Other problems
- Next Steps
1. Setup and Accessibility Tools
Let me give you information about the setup and accessibility tools I will be using.
Setup
- MacBook Air M1 to test the website
- Checking the home page of the website
Accessibility Tools
Let's run the axe DevTools extension. 50 automatic* issues were found, 1 critical and 18 serious and 9 moderate ones. We are focusing on the first two categories.
*Automatic means that vulnerabilities are found using accessibility development tools. However, even if all the listed vulnerabilities are fixed, it doesn't necessarily mean that the website is now fully accessible. Manual testing is still required, using only the keyboard and going through the website with a screen reader, to really point out and fix all the problems.
To easily find the errors on the website, you can highlight them by activating the Highlight button.
2. Navigating with Keyboard
Before I get into the details of the Axe DevTools results, I tried using only the keyboard to navigate the site. The burger menu doesn't get any focus, which made it unclear to me if I could access it using only the keyboard.
In fact, the menu is focusable and interactive, but the outline is not visible. The reason for this is simple. When I look at the source code, the a tag has its default outline value set to 0.
Another thing I noticed while tabbing through the menu in the burger menu overlay is that the focus goes beyond the overlay and does not stay in the overlay.
So if the user keeps tabbing without closing the overlay the links on the homepage are focused, but the user can't see them because the overlay is still open.
At the bottom left in the video you can see which button or link is currently focused.
How to solve
Overlays are always a bit tricky when it comes to focus. It would be best to look for an existing accessible package that never loses focus.
In general, it's not good practice to use a burger menu for desktop versions, for usability reasons, for example. If JavaScript is not enabled, the user will not be able to use the menu.
3. Zooming and scaling should not be disabled
I really like this issue because developers do this to prevent their design from breaking, which I completely understand. But people with limited vision or older people who are slowly losing their vision need the ability to zoom in order to perceive the content the same way as people without visual impairments.
Issue Description (by axe Devtools)
Ensures does not disable text scaling and zooming.
As you can see, the last part of the meta data in the head contains the attribute and value of user-scalable="0", which causes the issue.
The good thing is that some browsers don't care about this attribute. I can zoom into the website with my MacBook Air without any problems. And it seems that at 200% zoom (which is the requirement), the website still looks perfect 🥳.
When zooming into a website, responsiveness matters. They have made the website fully responsive, so there is nothing to worry about.
How to solve
Delete the user-scalable="0" attribute and the problem no longer appears.
4. Elements Must Have Sufficient Color Contrast
Almost half of the serious problems were related to color contrast.
Issue Description (by axe Devtools)
Ensures the contrast between foreground and background colors meets WCAG2 AA contrast ratio thresholds.
People with low vision may have difficulty reading the content due to the weak color contrast.
Primary color
This button, and the one at the bottom of the page, do not have sufficient color contrast (turquoise HEX color value of #33ADA9 on white HEX #FFFFFF).
axe DevTools shows that the contrast ratio is only 2.45:1, which is quite low. To meet WCAG2.1 AA, the contrast ratio needs to be at least 4.5:1. The turquoise would have to be reduced to a brightness of 33% to achieve this ratio.
Neutral color
The other problems are caused by a white tone used on links and the copyright information in the footer.
The white (#FFFFFF) itself would suffice with a contrast ratio of 7.82:1 on a gradient background, but an opacity of rgba(255, 255, 255, 0.3), and even lower for the copyright section (rgba(255, 255, 255, 0.15)), has been set which weakens the contrast immensely.
How to solve
Darken the primary color and removing the opacity will solve these problems.
5. Links Must Have Discernible Text
The other serious problems concern anchor tags around the burger menu as well as the linked website examples in the carousel.
Issue Description (by axe Devtools)
Ensures links have discernible text.
<a href="#menu">
<svg>
<use xlink:href="#icon-menu">...</use>
</svg>
<span class="label">
Menu
</span>
</a>
A label was actually added, which should fix the problem. But it is set to "display: none", which makes it inaccessible. To hide the content from the user's view, but not from the screen reader, you can hide the content as follows:
.label {
clip: rect(1px, 1px, 1px, 1px);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
width: 1px;
}
Furthermore, there is no alternative text for the images in the carousel, so the a tag cannot provide any information about where the link will lead when clicked. And that is what is misleading.
<a href="https://caycepollard-demo.carrd.co" target="_blank">
<img alt="" src="assets/images/marketing/landing/site-2.jpg">
</a>
Screen reader users can tab to the images in the carousel because they are surrounded by an a tag, so they assume that something will happen when they click on them. But screen reader users don't get any more information in the alt attribute or via an aria label about where that link will take them.
How to solve
Provide alternative text to the img tag or add aria to the a tag with the information of its destination.
6. Other problems
I have also briefly gone through the source code and would like to give an overview of possible problems, which I will not go into detail.
I want to show the mindset I have when I check the code for accessibility, what I look for, or what seems strange to me and I would definitely inspect and test more closely.
1. Landmarks
It lacks the use of the main tag, which is one of the necessary landmarks for screen reader users. The main content is divided into section and a div. I can't think of any reason to write it this way, and would be curious why this way of dividing the content was chosen.
2. Tabindex
The above mentioned section has a tabindex that is set to -1. I am curious what the reason for this is. Perhaps deleting this section would fix the keyboard problem.
7. Next Steps
I will contact the owner of the homepage and share my findings and tips, ask if changes can be made to make the web accessible to all, and of course offer my help if needed.
In order to do this, I will write something like:
Dear Team.
I am reaching out to you because I like your product but also care about the experience you provide to people with disabilities. You might not be aware, but your website has some accessibility issues that affect people with disabilities.
I am sure that your developers are able to solve these problems. If not, I'll be happy to help you solve the problems.
The following problems belong to be solved:
1.
2.
...
I really hope they implement the changes and help make the web cleaner and accessible to everyone. ☺️ I will keep you updated.
Thanks for your reading and time. I really appreciate it!
Top comments (2)
I'd add that where the textless link has
target="_blank", that should be removed.You could say it's more UX than a11y, because opening things in new tabs can be disorienting for people with perfect vision, but it's going to give one new dimension to navigating with a screen reader, and it's going to break the "back" functionality.
I've seen people recommend adding ".." to these links, but the simpler solution is to not do it in the first place unless you have a Really Good Reason.
Hi Ben, thanks for your comment.
Sure, there is so much more to say about this code. At this point, I was focusing on the particular problem axe DevTools is pointing out here.
You're absolutely right of course,
target="_blank"is not a good practice. Another option would be to use aria to let the screen reader user know that clicking on the link will open a tab in a new window.