Looking to make your site more accessible? Or maybe you want to make it easier to traverse your site overall using browsers and other interfaces? Using ARIA, you can do both. Let’s take a look at what ARIA is and how it can benefit an eCommerce site. We’ll also go through some examples step by step.
What Is ARIA?
WAI-ARIA stands for the Web Accessibility Initiative–Accessible Rich Internet Applications. This initiative takes the form of a set of guidelines and attributes that are maintained by the W3C. Using these attributes, we can create relations between our site elements that can’t be expressed through HTML alone. The most important for our use here is that we can define element relations outside of the parent-child relationship, and more clearly connect UI elements for our users.
At this point, it might be a good idea to check out our original primer on ARIA to brush up on some of its foundations.
.png)
HTMLSite Accessibility: Getting Started With ARIA
Adding ARIA to eCommerce
Previously, we talked about how to apply ARIA to a general website that resembled a common small business homepage. This time, we’re going to take a closer look at how ARIA can improve the user experience for large eCommerce sites.
We’re going to focus on four key areas of eCommerce that pose unique situations: product pages, category pages (or product aggregate pages), multi-level navigation, and faceted navigation. We’ll be using these two wireframes to guide us through the process:
Preparing for ARIA
In the case of most websites, adding ARIA is a fairly straightforward process. You define the pieces of your site, break them down into landmarks and elements, and add in the necessary code.
We’re going to follow a similar process with our eCommerce site, but we now have a new layer of intricacy. With the complexity that comes with eCommerce sites, ARIA can become a rabbit hole in many cases. While it is important to improve the accessibility of your site as much as possible, we unfortunately will often run into business constraints. Because of this, we’ll want to do a little more planning upfront, prioritizing each of our ARIA additions.
By doing this prioritization, we can ensure that the most important aspects of our site are improved first, making the user experience as good as we can in the time available.
Let’s kick it off by taking a look at some product pages.
ARIA for Product Pages
A staple page for any eCommerce site, these pages typically show a product, its available variations, and a way to add the item to a cart. Each of these interactive elements should be considered separately.
For our product page, let’s break it into pieces like this: our core product information, interactive elements that affect the product, our add to cart button, and an expanded content section.
If we needed to prioritize the implementation on this page, we would want to group it like so:
- Core product info, interactive elements, add to cart button
- Expanded product content
The main factor at play here is something we talked about in a previous article: ARIA helps to define an element’s intent. In the case of the expanded content, most of the HTML elements that are being used have elements with semantic meaning and intent that match. This means that while it is useful to put additional ARIA information if we can, it is likely less important than completing the other three areas.
Core Product Information
Let’s start off by adding ARIA to our core product information. This is pretty straightforward due to the simplicity of the elements being used here. The code looks like this:
A Nice Bag
Bag Size:
100x150mm
For starters, we’ll add a role to the main div, and a relationship between the image and the product title heading.
A Nice Bag
...
Interactive Product Elements
This is where product pages can get a little tricky. Products on an eCommerce site can have quite a few different types of variations present. Beyond just the types available, the number of them that can be utilized simultaneously adds another layer of complexity. In our example, we have three elements that come into play: size, color, and quantity.
Let’s take a look at how you can mark that up. Here’s the code for the ARIA-enhanced selection and checkbox elements:
Add to Cart Button
The cart button is similar to a standard button, but we’re going to go out of our way to label it more clearly than other buttons:
Expanded Product Content
Finally, the expanded content area is treated just like a typical content area. Depending on your product pages, however, it might be a good idea to separate your main content landmarks from your supplementary content landmarks. The tabs add an extra layer to the code here as well. Here’s how we’d do it in our example:
- Product Info
More product info...
Adding ARIA to Category Pages
While product pages can be considered an alternative form of content page in most respects, a site’s category pages, also called Product Listing Pages (PLPs), are a whole different beast. They are operating as a large navigation structure, allowing users to sort through hundreds or even thousands of products.
This makes them increasingly complex, becoming even more so as additional layers of content and filters are added (we’ll talk about faceted navigation and filters in the next section). Let’s look at the two mains areas of our PLP outside of the filters: the product blocks and the pagination.
Here’s our starting code frame:
Product Listing Page
...A Nice Bag
1 2 3 ... Last
Handling Pagination
Pagination is the name given to the small links at the bottom of our product listings here. Typically, they’re represented by numbers or arrows, but they can come in various other forms. On the HTML side of things, pagination links look just like regular links. We’ll say that ours is controlling the product listings without redirecting to another page.
To make it known that it’s controlling a content area in this way, we have to declare it as a controller, define what it is controlling, and then mark that content area as live. Here’s what that looks like in our case:
...
When we create our live area here, we utilize the "polite" setting that ARIA makes available. If your changes are pertinent and need to be addressed by the user quickly, or you need to prioritize among several live areas, you can use the value "assertive" as well.
Marking Up Repetitive Elements
A unique challenge that comes up with product landing pages is the intensive navigation complexity within the product listings themselves. From a visual perspective, it can be easy enough to group the information, using visual cues to determine what information applies to which product.
Doing so with ARIA has a few more layers than the previous applications we’ve covered. Marking a “buy now” button a standard button can create confusion when there are 20 of these buttons on a page. To solve this, we’ll need to create clear connections between each product and its related elements.
Here’s how we’ll do that:
...A Nice Bag
While this does help a bit with clarifying relations for the user, it’s still not the best implementation. A better way would be to dynamically generate an aria-label by concatenating the product-title element with an additional phrase such as “add to cart”.
Using ARIA With Faceted Navigation
Faceted navigation refers to the filters and options that are commonly shown on eCommerce sites, letting you narrow down your search results. These come in many flavors—from sizes to color and beyond. For our example, we’re going to make two assumptions:
-
Our faceted navigation updates the products live on the page. This isn’t always the case, as sometimes eCommerce sites might generate a new page when a filter is applied, but we’ll be working as if the site updates content live.
-
Our faceted navigation allows for the selection of multiple filters. Not every eCommerce site does this, and there are definitely cases where it shouldn’t be allowed. However, this creates an extra layer of complexity outside of the scope of this article.
Setting Up Your Controls
The HTML behind our filters is similar to that of pagination, appearing in the code as basic links. For our uses, though, the intent of the filters is to alter information that is currently on the page. Because of this, we’ll want to mark the entire container around the filters, making it clear that this is a controller for another area on the page:
Defining Live Areas
Like pagination, these updates are happening live on the page. Because of this, we’ll want to mark the main content on our page as being “live”. Note that we did this previously in the pagination section, but we’ll be repeating the step here for consistency.
The code should look like this:
...A Nice Bag
Testing Your Implementations
Our implementations are now all in place, so let’s put them through some tests. My favorite tools for doing so include Google’s Accessibility Developer Tools or IBM’s Dynamic Assistant Plugin, but depending on your project’s scale, you might need to create your own testing script.
If you need a tool that operates outside of Chrome, or just don’t prefer the two mentioned above, W3C has a list of other accessibility tools that are available.
Making eCommerce More Accessible
With these new additions to your ARIA toolset, you should now be able to appropriately mark up almost any eCommerce site. To ensure the best user experience with an eCommerce site, remember to keep your navigation as simple as possible, and express intent clearly.
Have further questions on this topic? Did I miss something important? Tell me in the comments below!
Powered by WPeMatico
