Navigating the Browser Blind
Simple steps that make Card components work for everyone.
If you typically use a mouse and keyboard, it may be hard to imagine how difficult it is to use only your keyboard when navigating a website.
Users who are blind or low vision users navigate and make selections on a website with only their keyboards, along with text-to-speech, tools such as Apple’s VoiceOver or Freedom Scientific’s JAWS (Job Access With Speech) that read the contents of the website out loud.
The two work well in conjunction, but without proper web design and web development implementation, the text-to-voice application can confuse users more or leave them struggling to do basic tasks like clicking a link.
Let’s look at a real world example
Many highly-trafficked sites, including IBM.com, use Card components to present options and convey information about each selection to help the user navigate. There are many variations of Card components, but the Carbon for IBM.com team typically classifies a Card as a component that contains a link with text and possibly additional media.
Although this seems like a simple component, when implemented incorrectly, the Card can cause confusion for visually-impaired users.
The Carbon for IBM.com team makes our best concerted effort to achieve accessibility requirements on our components as we strive towards creating a Universal Design. Because there are a wide variety of users visiting IBM.com on a daily basis, our QA team remains vigilant regarding any accessibility failures.
Some of the screen-reader accessibility issues we have addressed recently regarding the Card component include items being overly verbose, beginning and ending boundaries not being conveyed, and not being able to use arrow keys to read more detailed information.
Accessibility done wrong
An example of how a visually-impaired user might read a Card component that has not been implemented correctly can be seen below. A GIF is shown with the output from Apple’s VoiceOver when the user tabs to the Card component. Then there is a codepen example with how the HTML and CSS were implemented to create the Card component and give a live interaction for users to test with there text-to-speech tools.
When a user uses their text-to-speech application then tabs to the Card component, it will read the entire card including the image’s alternative text, heading, and call to action. This is too much information for a visually-impaired user when they are trying to navigate the screen quickly. Arrow keys won’t help either. Like tabbing, if a user navigates with their arrow keys, they cannot read the different elements (image, heading, CTA) one at a time.
This happens because the anchor link <a> is wrapped around the entire Card component, which can be seen in the above codepen example. In the W3C Editor’s draft link section it explains that links will get their name from the contents.
With these types of Card components, a designer might give information to the developer that the focus state should wrap around the entire card. The easiest way for a developer to accomplish this would be wrapping the entire card with the <a> tag. This would give the correct effects to visual users, but doesn’t work for everyone.
Accessibility done right
In order to keep to design specs, but also have an accessibility friendly Card component, the anchor link should be used only around the text that will give the information guiding the user to their next location. The example below shows an implementation. First, a GIF is shown with the output from Apple’s VoiceOver when the user tabs to the Card component. Then there is a codepen example with how the HTML and CSS were implemented to create the Card component and give a live interaction for users to test with there text-to-speech tools.
In this case, the user is able to tab to quickly understand that they will be linked to another site. They also have the option to also use arrow keys to gather more information by navigating to the heading and alternative image text. In the above codepen example, the <a> wraps just around the call-to-action text. Additional styles have been added so that the focus state still wraps the entire card to match design specs and visual users will see no difference from the prior example.
This simple change to the card component can magnify the experience for accessibility users and continue to give non-accessibility users the same great experience.
Continuing accessible content
The Carbon for IBM.com team is committed to creating components that are usable by everyone, and will continue to be vigilant about the best approaches for accessibility. This would not be possible without the dedication of IBM’s Accessibility team in creating an equal access environment.
