Development Ideas from the Accessible eStore, part 2: Providing users with shortcuts to content
Accessible eStore recap
The Accessible eStore is an interactive prototype of an accessible e-commerce storefront. It launched on Global Accessibility Awareness Day, May 16, 2019. Follow this link to read more about the eStore launch.
We created the store because the web needs more examples of accessible experiences. In this article, I will share some development features meant to help keyboard and screen reader users navigate the eStore. Open the store in a separate window and try out the features as you read this article.
If you haven’t already, please read part one of this series first!
The difference between keyboard and mouse pointer navigation
A mouse pointer user can click anywhere on the page whenever they want. But when you navigate using your keyboard, you can’t arrive at content mid-way down the page without tabbing through every single node on the page. Unless someone builds in shortcuts. This article talks about all of the shortcuts we created for keyboard users in the Accessible eStore.
Skip navigation links
One of the easiest to implement and most effective shortcuts for keyboard users are skip navigation links. If you don’t know what I’m talking about, try this out on the Accessible eStore: Tab into the page content from the address bar. A link you never saw before will appear on focus, offering you the ability to skip directly to the content.
The link is a simple anchor link to a destination on the same page. It links from the top of the page to a location where the content starts. The link label is usually something like, “Skip navigation” or “Skip to main content.”
Problem #1: Ensuring that skip links work with the keyboard
It’s common to see anchor links coded with an href that points at an anchor further down the page with a “name” attribute as shown in the screenshot. Please keep reading, this is the wrong way to do it.
This works fine for mouse users. When you click on the skip link, the page content will scroll until the target anchor (in this case, with the name=“content”) is at the top of the page, or at least in screen view. However, using the name attribute will not work in a satisfactory way for a keyboard user.
For the keyboard user, when a “name” attribute is used, they can hit enter on that skip link, and the page content will scroll up into view just as it does for the mouse user. But when they hit their tab key to move to the next interactive element in the content section, their keyboard focus will go back to the next element — beside the original skip link! The page will scroll back to the original position, and in this case, their keyboard focus will land on the first item in the global navigation menu, which is exactly what they did not want. They wanted to skip the navigation.
To capture a keyboard user’s keyboard focus, you need to use an id attribute instead of a name attribute. When we use the id attribute instead, this can work correctly for a keyboard user. Make sure to test all of your work with your keyboard and you can easily catch little issues like this one.
Problem #2: Where do we land?
On what should the user’s keyboard focus land when they skip over the navigation menu? Some people put the focus on the first heading on the page. This is kind of weird, since headings are not interactive and aren’t really supposed to get keyboard focus in this way. On the Accessible eStore, we decided to give users a way to go quickly back to the navigation menu, in case the user changed their mind. We had them land on a “Skip to main navigation” link. The code looks kind of like this:
Aside: Just in case you think multiple skip buttons look ugly, we coded them so that they would only appear on keyboard focus, so only a sighted keyboard user will see them. We don’t think the keyboard user will think these helpful shortcuts are ugly. Here’s how it looks on the eStore:
Problem #3: Seriously, but where do we land?
One of the classic problems of front end web development is where to place the destination for this link. The problem is, how do you know where (in which component) the content will always start?
Generally when we design websites, we create page templates. But usually the page templates need to be flexible, so that any component could be used at the top of the page. Many times, developers get stuck trying to figure out where to put their target anchor, trying to guess which component will always be at the top of the page, or to create a component to serve that purpose (to be the start of the content).
I recommend keeping both the skip to content and return to navigation links in the same component — the global navigation component. Simply wrap them around the global navigation menu, and they will always automatically show up and work on every page, with no dependencies on that page’s eventual content or component type.
Accessible eStore headings
Headings are another way that we can help keyboard users navigate. In this case, keyboard users who employ a screen reader or other assistive technology (AT). A screen reader can tell a user a list of headings on the page and the heading levels. This list acts like a table of contents for that page. The user can navigate the list with their arrow keys and hear each heading and level announced by the screen reader. If the heading sounds interesting, they can hit enter and navigate directly to that section of the page. This is another great shortcut we can provide when we mark up a page properly.
The Accessible eStore uses headings to describe each section of content. Every page has a descriptive primary heading (an H1).
Any text that looks like a heading visually must also be marked up with a heading tag. Heading levels should be provided by the experience designer or content strategist. Many times people rely upon developers to implement a heading structure. Sometimes a developer does a great job at this, and other times they do not. Why take a chance? Have the heading structure defined by an experience designer and approved by the client. Heading structure also impacts Search Engine Optimization (SEO) and should not be taken lightly.
Heading tips for developers:
- If you receive a design or wireframe that does not indicate the heading level, ask an experience designer what the heading level should be.
- Remember to separate style from structure in your CSS. Content authors should be able to change the heading level within a given component while keeping the style of the heading the same. Remember that a component can appear anywhere on a page and content hierarchies can change. Write your styles so that the component could have an H1 or an H3 without changing the heading style of the component.
- When you get to build an experience from scratch, focus on creating a flexible heading structure that is not tied to heading style. Work with the back end team to make sure that all component heading levels are configurable in the content management system. You’ll save yourself tons of time later if you do this right!
- If you inherit a codebase with improper headings, try to get heading fixes into the backlog and fix them incrementally. Start with the lower heading levels. Get a level 1 heading on every page. Try to get the H1 and H2 headings in order. Clean up the arrangement of the higher heading levels into a hierarchy last. Work with the Search Engine Optimization team to get these changes onto the backlog, because they will care deeply about them, too.
Other shortcuts
On the Accessible eStore, we provided keyboard shortcuts between our filters and our product grid on the product listing page. We also provided a shortcut on the product details page to allow users to easily move between the product details and the product images. Try navigating the filters menu with your keyboard and they will appear. We tried to anticipate elements that sighted keyboard users would want to move between. Remember that sighted keyboard users don’t necessarily use a screen reader, so will not necessarily have access to the screen reader menus that allow them to navigate between headings or landmarks (discussed in part 1 of this series).
Is there an optimal number of shortcuts? Did we provide too many? Let us know!
Thanks for reading, and please check out the Accessible eStore and let us know what you think of our page structure and how it could be improved.
