Development Ideas from the Accessible eStore, part 1: Structuring your template

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.

Defining page template structure is a collaborative effort

It is a common misconception that developers are responsible for web accessibility. Actually, developers must collaborate with experience designers to make experiences accessible. Experience designers provide specifications to developers. These specifications should outline how the experience works with a mouse and keyboard. They should also describe what the screen reader should announce. Developers need experience designers to provide structural recommendations for page templates.

Creating something new vs. inheriting a project

As developers, sometimes we get the amazing opportunity to build an experience from scratch. In that case, we have the opportunity to build it right. More often, we are staffed to an ongoing project. In that case, there are still many things we can do to improve the accessibility of that experience. I’ll talk about both scenarios in this article.

Structure your template in an accessible way

Must do: Use semantics to describe your content

Developers should start by using HTML5 semantic elements to properly describe their content. When a developer uses HTML5 semantic elements, the semantic meaning of their content can be communicated to assistive devices like screen readers. Please use these semantic elements if you have the opportunity to create a codebase from scratch.

Here are a few examples of HTML5 semantic elements:

• <header> — To group content at the top of a page.
• <nav> — To identify page navigation. Use in conjunction with an aria-label. For the global navigation menu, I recommend aria-label=”Primary”. The screen reader will say something like, “Navigation, primary.”
• <main> — To identify the main content of a page.
• <section> — To thematically group content types.
• <article> — To identify independently distributable or reusable content.
• <aside> — To identify information that is a sidebar to your main content. (Confirm with a user experience designer before using this).
• <p> — To identify paragraphs.
• <ul> — To identify lists.
• <table> — To identify tabular data. Make sure to use in conjunction with a <caption> element.
• <a> — To identify links (interactive elements that will navigate a user away from the current page).
• <button> — To identify buttons (interactive elements that perform an action within the current page).
• <footer> — To group footer content on a page, like author details, legal information, and/or links to related information. Also use a <nav> element around navigational links, with an aria-label to describe the navigation type. For the footer navigation, I recommend aria-label=”secondary”. The screen reader will say, “Navigation, secondary”.

All these elements help a non-sighted user form a mental picture of the content on the page. Assistive technology announces an element’s type to inform non-sighted users. In this way, they can understand what an element does. Read more about all of the HTML5 semantic elements at freecodecamp.org.

Aside: It’s worth it to actually dig in and understand what each semantic element is for, to avoid making incorrect assumptions. For example, many developers think that all addresses should be marked up using the <address> tag. This is actually completely wrong. The address tag is meant to define the contact information for the author or owner of a document or an article (a single address). It is not meant to be used on pages that list multiple addresses, like store locator pages. If you don’t believe me, look it up. When mistakes like this are made, it often causes screen readers to announce erroneous and confusing information.

Or, use ARIA roles to give semantic meaning to generic <div> elements

The Web Accessibility Initiative — Accessible Rich Internet Applications (WAI-ARIA) is a technical specification published by the World Wide Web Consortium (W3C) that defines ways to increase the accessibility of web content, especially dynamic content and custom widgets.

Developers inheriting someone else’s code base that uses generic <div> elements instead of HTML5 semantic elements can make that codebase more accessible by assigning ARIA roles to the <div> elements using ARIA attributes. When a developer applies ARIA roles to generic <div> elements, this also communicates the semantic meaning of their content to assistive devices like screen readers.

A common mistake that developers make is to use an HTML5 semantic element and also give it a ARIA role. Don’t do this. Just use one method or the other.

The following table showing HTML5 semantic elements and their ARIA role equivalents is from dequeuniversity.com:

HTML 5 elements and corresponding ARIA roles:

• HTML5 <header> → ARIA role="banner"
• HTML5 <nav> → ARIA role="navigation"
• HTML5 <main> → ARIA role="main"
• HTML5 <footer> → ARIA role="contentinfo"
• HTML5 <aside> → ARIA role="complementary"
• HTML5 <section> → ARIA role="region"
• HTML5 <article> → ARIA role="article"
• HTML5 none → ARIA role="search"
• HTML5 <form> → ARIA role="form"

Use landmarks to identify page sections

Landmark roles (or “landmarks”) programmatically identify sections of a page. Landmarks are attributes you can add to elements in your page to define areas like navigation, search utilities, main content areas, and other regions for assistive devices. They help users form a mental picture of a page.

In the previous section we discussed using the HTML5 <nav> element, or a <div role=”navigation”> and how they are equivalent. Either one of these will identify an area of navigation to assistive technology. The screenshot below shows the VoiceOver screen reader’s rotor menu, displaying a list of landmarks for the page on the Accessible eStore. For the Accessible eStore, we used HTML5 semantic elements to define landmarks.

The VoiceOver rotor menu shows a list of landmarks for the Accessible eStore’s product listing page.

How do landmarks work with the screen reader?

I want to interrupt this article to let you know how landmarks work with the VoiceOver screen reader. Don’t worry — they work in a similar way for other screen readers. A VoiceOver user can use a key combination to open what is called the “rotor” menu. This menu allows the user to cycle through different lists of content pulled from their current webpage (among other things). The screenshot provided shows a list of landmarks in the rotor menu. Once the menu is open, the user can employ their left and right arrow keys to cycle through types of content lists, like headings, links, etc. When they find the list they want, in this case, landmarks, they can use their up and down arrow keys to navigate that list. They will hear the landmarks, and when they get to one that sounds interesting, like “Primary navigation,” they can hit their enter key to navigate directly to that section.

Check out the list of landmarks for the Accessible eStore:

• Banner
• Primary navigation
• Secondary navigation
• Breadcrumb navigation
• Filters region

The first landmark is the banner. The header element (or banner role) is meant to identify the general content usually placed at the beginning of the web page. This typically includes a logo, company name, search icon, etc.

Three navigation sections follow the banner content. We gave each navigation menu a name using an aria-label. E.g.

<nav aria-label=”primary”> or <div role=”navigation” aria-label=”primary”>

We provided a name for each navigation section to provide context for a user. When they cycle through the options in the landmarks menu, because we added labels, a user will hear: “Primary navigation, secondary navigation, breadcrumb navigation.” If we did not label our nav elements, the user would have simply heard, “Navigation, navigation, navigation.”

Aside: There’s no question that landmarks should be labeled to provide context. It’s harder to tell if the names we chose are effective. Did we do a good job naming our menus to be meaningful to the user? Our global navigation menu is called “Primary navigation”. This houses the main sections of our store. We have a second menu related to secondary activities, like accessing your account, or your cart after you have already browsed through the site. We called this the “secondary navigation”. Finally, we have the breadcrumb navigation at the top of the page.

Does a regular user know what a breadcrumb menu is? Do the terms “primary” and “secondary” make sense in this context? Maybe. This is all part of doing user research. We hope to get feedback on our usage of these terms and come up with some better alternatives or conventions. In the meantime, developers should ask a user experience designer to provide the best name.

Landmark tips for developers:

• Use semantic HTML5 elements if you can, and landmark roles if you must.
• Ask an experience designer which parts of the page should be landmarks, and what the landmarks should be called.

Our final landmark role was to define the filters region on the product listing page. We did this because we wanted to give a keyboard and screen reader user an easy way to quickly navigate to the filters area. We thought this would be an area that a user might want to randomly return to as they were exploring the product grid. Is this a useful feature? Is there some other part of the page that deserves to be marked up to make it easily accessible in this direct way? 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.