This episode is a recording of a January 2024 WordPress Accessibility Meetup where Amber Hinds, CEO of Equalize Digital, shared her case study on building an accessible drop-shipping WooCommerce website, including the process for building, testing, and remediating in WooCommerce and specific plugin findings. If you want to watch a video recording from the meetup, you may do so on the Equalize Digital website: Building a Low-Code Accessible WooCommerce Website: Amber Hinds.
WordPress Accessibility Meetups take place via Zoom webinars twice a month, and anyone can attend. Learn more about WordPress Accessibility Meetup and see upcoming events.
Listen
Mentioned in This Episode
- Equalize Digital Shop
- The WebAIM Million
- Accessibility Statement
- Content Management Systems and Site Builders
Summarized Session Information
WooCommerce has a significant presence in the online marketplace. Data from BuiltWith indicates that WooCommerce powers 6.1 million live websites, making up 21% of all WordPress sites and 9% of all internet sites. This highlights its vast reach in e-commerce but doesn’t mean much without accessibility. People with disabilities hold an annual disposable income of $1.9 trillion and have a strong economic power. There are also the legal implications of web accessibility, as noted by a report from UsableNet, which pointed out that a majority of the lawsuits under the Americans with Disabilities Act in the United States in 2023 targeted e-commerce websites.
In examining the accessibility of WooCommerce, Amber analyzed websites featured in the WooCommerce showcase. She assessed ten sites using the WAVE browser extension and manual testing to check for focus outlines, skip links, and functional navigation. The assessment revealed varying levels of accessibility. Common issues across these sites included missing alternative text for images and inadequate focus indicators. This analysis revealed a disappointing lack of exemplary accessibility in the showcased examples, mirroring a wider issue in web accessibility.
In this session, Amber tackled the question of whether it’s feasible to build an accessible WooCommerce website without extensive coding. The experiment involved creating a basic e-commerce store using the Twenty Twenty-Four WordPress theme to test WooCommerce’s out-of-the-box accessibility. While some positive aspects, like the built-in mini-cart and template editing, were noted, she concluded that WooCommerce does not inherently support fully accessible website creation without additional coding.
Through extensive testing, Amber categorized issues into CSS-related, easy template adjustments, and developer-level fixes. CSS issues included improving focus indicators and color contrast. Template adjustments were made for skip links and heading levels. The most significant were developer-level issues requiring technical expertise, leading to the opening of 45 GitHub issues with WooCommerce.
Amber addressed critical issues by creating an accessibility statement for the store, detailing the problems, and linking to the GitHub issues. Amber highlighted the importance of addressing potential blockers like mini-cart focus issues and sticky elements, especially for revenue-generating stores where waiting for WooCommerce to implement fixes might not be viable.
Amber discussed challenges with using Printful, a service for her WooCommerce store. Issues included improperly formatted product descriptions and a size guide that violated several accessibility guidelines. She temporarily resolved some of these issues, like the size guide, using CSS to hide problematic elements. The session also touched upon the use of AI-generated alternative text for images and its challenges.
Finally, Amber warned against certain types of plugins that could introduce accessibility issues in WooCommerce websites. This included page builders, search and filter plugins, search suggestion plugins, floating carts, plugins modifying the checkout page, PDF invoice generators, and carousel, tab, or accordion plugins. She emphasized the importance of carefully vetting these plugins for accessibility.
Session Outline
- Background information
- How easy is it to build an accessible WooCommerce website?
- Issue types
- Critical issues & prioritization
- Using Printful
- AI-generated alt-text
- Plugins likely to add problems
Background information
The data provided by BuiltWith reveals that WooCommerce is a dominant force in the online marketplace, powering 6.1 million live websites. This accounts for 21% of all WordPress websites and 9% of all websites on the internet. This information underlines WooCommerce’s extensive reach and influence in the e-commerce sector.
In addition, a report from the International Finance Corporation (IFC) highlighted the substantial annual disposable income of $1.9 trillion among people with disabilities, emphasizing the vastness of this market, which exceeds the population of countries like China.
Furthermore, there are also the legal aspects of website accessibility. A report from UsableNet showed that in 2023, a staggering 82% of all lawsuits under the Americans with Disabilities Act in the United States targeted e-commerce websites.
Lastly, we have the impending enforcement of the European Accessibility Act in June 2025, signaling a crucial timeline for businesses and web developers in Europe. This act necessitates compliance with accessibility standards, thereby stressing the need for immediate action to make websites accessible, especially as the deadline draws nearer.
WooCommerce showcase accessibility
Let’s discuss the practicality of building an accessible WooCommerce website. To evaluate this, Amber examined the websites featured in the WooCommerce showcase. Amber selected the first few websites that appeared in the WooCommerce gallery, assuming these to be the most visible and influential examples of what can be achieved with WooCommerce.
Amber conducted a basic accessibility assessment of these ten websites using the WAVE browser extension. This tool helped identify various accessibility issues, such as errors, contrast errors, and alerts. Additionally, Amber performed a manual check to assess whether these sites had visible focus outlines, skip links, and functional navigation menus, especially through keyboard navigation.
| Website | Errors | Contrast Errors | Alerts | Visible Focus, skip links, and functional nav |
| allblackshop.com | 32 | 53 | 219 | yes |
| orangeamps.com | 5 | 13 | 36 | no |
| weber.co.za | 13 | 14 | 72 | no |
| stroopwafels.com | 7 | 97 | 77 | no |
| offermanwoodshop.com | 3 | 0 | 8 | no |
| dvosuspension.com | 8 | 17 | 23 | no |
| augustapparel.com | 33 | 23 | 47 | yes-ish |
| stylegirlfriend.com | 20 | 5 | 24 | no |
| shop.bjork.com | 4 | 1 | 6 | yes |
| heggerty.org | 77 | 2 | 99 | no |
The results revealed a diverse range of online shops with varying levels of accessibility. For instance, the best-performing site in terms of WAVE analysis was OffermanWoodshop.com, which had minimal errors but lacked functional dropdown menus accessible via keyboard. Another notable example was the website of singer Bjork, which had better accessibility features but was marred by issues like unlabeled form fields.
However, not all accessibility issues carry the same weight. For example, the All Black Shop website had numerous errors primarily due to missing alternative text for linked images, a common issue in product galleries.
The overarching takeaway from the assessment is a somewhat disappointing realization: even among the showcased examples of WooCommerce websites, none demonstrated exemplary accessibility. This observation raises concerns about the ease of creating accessible sites with WooCommerce.
Amber connects this finding to a broader issue in web accessibility, referencing the WebAIM Million report. This report indicates that over 90% of websites have easily detectable accessibility problems, aligning with her observation that the lack of accessible WooCommerce examples is both disappointing and unsurprising.
How easy is it to build an accessible WooCommerce website?
To find a concrete answer, Amber decided to take on the challenge herself by building an e-commerce store using WooCommerce.
Sometimes, the WooCommerce sections were more accessible due to inherent features of WooCommerce, whereas the broader website accessibility could be compromised by the chosen theme.
To conduct the experiment, Amber primarily used the Twenty Twenty-Four WordPress theme to establish a baseline for accessibility using a core WordPress theme. This choice also allowed her to experiment with full-site editing features.
The result of her endeavor was a basic but fully functional e-commerce store, which can be accessed at shop.equalizedigital.com. Amber used minimal additional plugins to keep the focus on the core capabilities of WooCommerce and the chosen theme.
The Good
One of the highlights was the built-in mini-cart feature in core WooCommerce. The mini-cart functionally slides out and displays items in the cart, along with options to view the cart or proceed to checkout.
The full-site editing aspect of WooCommerce makes it easy to edit templates for various pages like the shop page, product single page, cart, and checkout page. While it was straightforward for a typically abled person, full-site editing might present challenges for screen reader users. Specifically, there would be some difficulties in editing navigation menus and footers, but overall, it was manageable to modify WooCommerce templates without needing extensive coding.
In the assessment, Amber observed that considerable effort had been made to enhance accessibility. Very few ambiguous links and unlabeled fields indicated a conscious effort towards accessibility. Notably, the use of ARIA roles, such as “role equals button” on links, suggested that WooCommerce had revisited and improved elements for better accessibility.
Moreover, there were some accessibility issues that could be addressed through workarounds available in full-site editing.
Out of the box WooCommerce accessibility
Is it feasible to build a low-code, accessible WooCommerce website straight out of the box? No. WooCommerce, as it currently stands, does not inherently support the creation of a fully accessible website without the need for code modifications.
However, the current state of WooCommerce does not necessarily define its future potential or limitations. The lack of out-of-the-box accessibility does not mean that building an accessible website with WooCommerce is impossible, but it would likely require the assistance of a developer.
While WooCommerce has limitations in its current form regarding accessibility, there is still potential for improvement and the ability to create accessible websites, albeit with additional technical intervention.
Issue types
Amber elaborated on the specific types of issues she encountered while building and testing an accessible WooCommerce website. Her approach to testing was comprehensive, involving the Accessibility Checker WordPress plugin, keyboard testing, and testing with screen readers like Voiceover and NVDA. The issues identified fell into three main categories.
- CSS: These were relatively minor issues related to styling elements for adequate color contrast and other similar concerns. Although they might seem small, addressing these issues is crucial for meeting accessibility standards, particularly for users with visual impairments.
- Easy Template Adjustments: Amber found certain issues that, while potentially having a major impact on accessibility, could be resolved without delving into code. These adjustments could be made directly within the website editor and did not require developer-level intervention.
- Developer-Level Fixes: The majority of the problems encountered fell into this category. These issues require more technical expertise to fix and should ideally be addressed at the WooCommerce core level. These fixes are better off being implemented by WooCommerce itself to avoid individual websites having to maintain “technical debt” – the ongoing effort to keep custom solutions updated alongside WooCommerce updates.
During the testing, Amber reported opening 45 GitHub issues for WooCommerce, indicating the extent and complexity of these problems.
CSS fixes
Focus indicators: In some instances, especially in the WooCommerce loops (like product blocks or shop archive pages), the default focus outlines were not visible enough. To rectify this, Amber modified the focus outline for WooCommerce product images and links. This involved ensuring that focus indicators were visible and correctly sized around the elements.
Color contrast issues: These included modifying the opacity of the “view cart” banner, adjusting the color of labels on the checkout page, and enhancing the error color to pass the AAA level of compliance.
Color used for interaction indicators: To accommodate users with color blindness, Amber made changes to elements that relied solely on color to indicate interaction, such as links and hover states. She added or modified text underlining to these elements to provide a visual indication of change in addition to color changes.
Email footer text: The default color of this text was too light, failing to meet color contrast standards. To fix this, Amber used in-line CSS styling within the email templates to ensure the text color was appropriately contrasted against the background.
Editor fixes
Skip links issue: There was a lack of skip links on the shop archive and product single pages, even though they were present on the homepage. This issue was traced back to the WooCommerce template, where the main content was contained within a div element instead of a main tag. The Twenty Twenty-Four theme required a main tag to implement skip links. Changing the HTML element from div to main in the WooCommerce template was a simple but crucial fix for improving navigation for keyboard and screen reader users.
Heading level consistency: Another issue was inconsistent heading levels, particularly on the cart and checkout pages, where H1 tags were missing. There were discrepancies in sample content, like the refunds page, which skipped from H1 to H3 headings.
Checkout page adjustments: On the checkout page, Amber added a message indicating that all fields were required unless marked as ‘optional.’ This change addressed the lack of visible required indicators, which could be confusing for users. Additionally, she enabled a setting in WooCommerce to redirect users to the cart page after adding a product, as the default behavior did not adequately notify screen reader users about the addition of items to the cart.
Focus order on the checkout page: A significant fix involved adjusting the focus order on the checkout page. Amber rearranged the order of the columns in the template so that the focus order on desktop matched the logical flow of the page. This change ensured that users navigating with a keyboard or screen reader would encounter elements in an intuitive sequence, particularly important for accessing discount options like coupon fields.
Issues reported to WooCommerce
These cover the issues encountered with WooCommerce that couldn’t be resolved through simple CSS or editor fixes. Out of the 45 issues identified, 31 required more complex solutions beyond no-code or low-code fixes. Amber grouped these issues by page type and made them accessible through the shop’s accessibility statement and GitHub links.
- Mini-cart accessibility: While generally accessible, the mini-cart had a few issues. It didn’t return keyboard focus to the triggering button upon closure, and until JavaScript loaded, it lacked an accessible name. There was also a problem for low-vision users at high zoom levels, where sticky footer elements obscured the mini-cart.
- ARIA labels for price ranges: Amber suggested enhancing screen reader accessibility by adding ARIA labels to price ranges, which would provide clearer context than just reading out numbers.
- Product sorting accessibility: On the main shop page, the product sorting functionality didn’t announce changes to screen readers, impacting the user experience for visually impaired users.
- Product gallery issues: The product gallery posed challenges, especially for screen reader users, due to its placement before product details. Amber added a screen-reader-only link to bypass the gallery but acknowledged that further improvements were needed.
- Ambiguous links and focus issues: These were found particularly on product tags and variation selection.
- Issues on the cart and checkout pages: Amber identified problems like the coupon button being coded as a link without appropriate handlers and focus management issues after address changes. The “Buy with Google Pay” button lacked a focus outline, and the “return to cart” link was missing for zoomed-in users.
- My account page challenges: On the “My Account” pages, Amber found unlabeled navigation, skipped heading levels, and ambiguous links. Additionally, page titles and H1 tags didn’t change to reflect the content of different account pages, creating potential confusion.
WooCommerce needs to address these issues to ensure a fully accessible experience for all users. This detailed report reflects the complexity of web accessibility and the importance of continual improvement and responsiveness by platform developers.
Critical issues and prioritization
Amber discussed how she addressed the various accessibility issues she found in WooCommerce. She created an accessibility statement for the store, openly acknowledging the work in progress and linking to the GitHub issues for transparency and to allow others to follow the progress of these issues.
This approach was influenced by the fact that the store wasn’t primarily focused on revenue generation, and hence, she could afford to wait for WooCommerce to fix these issues. However, she emphasized that this approach might not be suitable for revenue-generating stores, where accessibility issues could be critical blockers. In such cases, relying solely on WooCommerce for fixes may not be the best strategy.
From the list of issues she identified, Amber highlighted a few that she considered as potential blockers, especially for primary business websites using WooCommerce:
- Mini-cart losing keyboard focus: This issue could significantly impact user experience, as users would be ‘dumped out’ of the cart and lose their place upon closing it.
- Sticky elements in mini-cart for low-vision users: The presence of sticky elements that block content when zoomed in could be a major impediment for low-vision users. This might be fixable with CSS.
- Issues with the ‘Clear’ button on product pages: Ensuring the clear button works correctly is crucial, as it impacts the user’s ability to modify their product selections effectively.
- Spacebar handlers on the cart and checkout pages: The issue with links turned into buttons without spacebar handlers needed addressing to ensure keyboard navigability.
- Announcing status messages by forms: Ensuring that all status messages, particularly those related to errors or confirmations, are announced to users is vital for an accessible user experience.
Those running WooCommerce stores should check for these issues and consider patching them independently while waiting for WooCommerce to implement fixes. This approach underscores the importance of proactive management in addressing accessibility concerns, particularly in cases where such issues could directly impact business operations and customer experience.
Using Printful
Printful is the service she used for this WooCommerce store.
Faux lists in product descriptions: When importing products from Printful, the descriptions included what appeared to be bullet points but were actually mid-dots within paragraph tags. These faux lists were not true HTML lists and required correction for proper accessibility.
Printful size guide accessibility: When using a screen reader, the size guide pop-up failed to announce its opening, did not shift focus into the pop-up, and did not allow keyboard navigation within it. The tabs and close buttons in the pop-up were not keyboard-focusable, and the close button lacked an image description and an ARIA label, making it invisible to screen reader users.
Issues with table accessibility: The size guide also included a table with size, length, and width information, but it was poorly structured for accessibility. The table headers were not correctly marked, making it difficult for screen readers to interpret the table correctly.
Lack of keyboard accessibility: Elements like tabs for switching between inches and centimeters were not keyboard-focusable, being just text in a list controlled by JavaScript. This lack of keyboard accessibility was a major concern.
Inability to close pop-ups easily: The pop-up could not be closed using the ‘escape’ key or by clicking outside of it. The only way to close it was through the unlabeled close button.
Due to these extensive issues, it’s best to hide the size guide completely using CSS as a temporary solution.
It’s important to thoroughly evaluate third-party services and plugins for accessibility compliance, especially when they are integrated into an online store or website.
AI-generated alt text
AI-generated alt text
| Image |  |  |  |  |
| AltText.ai | An image of a square with a mountain on it. | A set of Accessibility Pins with a green cactus on them. | The measurements of a white hoodie. | Make the Make WordPress Accessible Youth T-Shirt with WordPress design. |
| Me | A set of Accessibility Pins with 5 different patterns; described in product description. | A hoodie with lines indicating how to measure length (from the shoulder near the neckline to the hem), width (across the chest at the armpits), and sleeve (from middle back of neck to wrist). | Gray t-shirt showing a drawing of a block editor toolbar from the WordPress Editor set to an H1 above stacked text: Make WordPress Accessible. The text covers the entire chest area of the shirt. |
Plugins likely to add problems
Amber focused on identifying certain types of plugins that are likely to introduce accessibility problems in WooCommerce websites. These insights are based on the experiences and observations while building and auditing WooCommerce sites.
- Page builders: Be cautious using page builders. Many showcased websites built with various page builders often include elements that are not accessible.
- Search and filter plugins: Search and filter plugins, particularly those adding filters to the sides of pages, frequently have accessibility issues.
- Search suggestion plugins: These plugins, which show product suggestions with images as users type in a search box, often lack keyboard accessibility and are not accessible to screen reader users.
- Floating carts: While the WooCommerce mini-cart performed relatively well, Amber warned against other floating cart plugins that may appear on the side or bottom of the page. These often fail to manage focus correctly and do not announce when they are opened, similar to the issues observed in the Printful size guide pop-up.
- Plugins modifying the checkout page: Be cautious with plugins that alter the checkout process, such as those converting it into a step-by-step process. The default WooCommerce checkout page works well with minor adjustments, and altering it significantly could introduce accessibility barriers.
- PDF invoice generators: Amber has not encountered any PDF invoice generator plugins that create accessible PDFs. These are important for customer communication and should be accessible. If the invoices are emailed to customers, ensuring their accessibility is crucial.
- Carousel, tab, or accordion Plugins: Many of these plugins are often not functional for users who cannot use a mouse.
Wrapping it all up
Amber Hinds shed light on the complexities of creating accessible WooCommerce websites. She emphasized WooCommerce’s significant online presence and the importance of accessibility, particularly given the substantial disposable income of people with disabilities and the legal implications surrounding web accessibility. Her analysis revealed inherent challenges in WooCommerce, highlighting that creating fully accessible websites often requires additional coding.
Amber shared her hands-on experience, categorizing the encountered accessibility issues into CSS fixes, template adjustments, and developer-level challenges. This demonstrated the multifaceted nature of web accessibility and the need for continuous effort in addressing these issues. She emphasized proactive measures, such as creating an accessibility statement and prioritizing critical issues like focus management in mini-carts, especially crucial for e-commerce businesses.
Furthermore, Amber discussed the complexities introduced by third-party services like Printful and cautioned against certain types of plugins known to add accessibility problems. Her session provided valuable insights into the necessity of thorough evaluation and adaptation to ensure inclusivity in digital commerce, highlighting the ongoing effort required to make e-commerce accessible to everyone.
Transcript
>> CHRIS HINDS: Welcome to episode 55 of the Accessibility Craft Podcast, where we explore the art of creating accessible websites while trying out interesting craft beverages. This podcast is brought to you by the team at Equalize Digital, a WordPress accessibility company and the proud creators of the Accessibility Checker plugin.
This episode is a recording of a January 2024 WordPress Accessibility Meetup where Amber Hinds, CEO of Equalize Digital, shared her case study on building an accessible drop-shipping WooCommerce website, including the process for building, testing, and remediating in WooCommerce and specific plugin findings. WordPress Accessibility Meetups take place via Zoom webinars twice a month, and anyone can attend.
For show notes, a full transcript, and additional information about meetups, go to AccessibilityCraft.com/055.
>> AMBER HINDS: So I wanted to present a case study today that’s about building a low-code accessible WooCommerce website, and we will circle back to the title of this, and whether or not that was possible in just a little bit.
So some background info that I think is interesting and relevant. There’s a website called BuiltWith that scans code out on the internet, and lists tools and how widely used they are for various software on websites.
According to BuiltWith data, they currently know of 6.1 million live websites that are built with WooCommerce. 21% of all WordPress websites include WooCommerce software, according to W3 Text, and 9% of all websites on the internet have WooCommerce, so it is a huge platform that is very widely used.
I’m assuming that most people in the chat are familiar with WooCommerce, and have probably even played around with it on a client’s site or on their own site.
So why does accessibility in WooCommerce matter? Some things to think about is the IFC recently reported that, worldwide, people with disabilities have an annual disposable income of $1.9 trillion. They said that it’s actually a larger market, as far as number of people, than the entire country of China, so it is a very large market that can be reached.
If you are worried about legal compliance, UsableNet is a company that does reports on accessibility lawsuits twice a year they, and at the end of 2023, they reported that for the year of 2023, 82% of all of the lawsuits under the Americans with Disabilities Act in the United States were against E-commerce websites.
Then of course something else to keep in mind is, if you or your clients are in Europe, enforcement begins for the European Accessibility Act in June 2025, so we are nearing the point where there will be a year or less to get websites ready to comply with that.
So when we’re thinking about WooCommerce accessibility and how possible it is to build an accessible WooCommerce website, one of the first things that came to mind for me is, I should just go look in the WooCommerce showcase and see how accessible the websites that are being featured by WooCommerce in their showcase are. Are these good examples?
I have on the screen right now a table that lists 10 URLs. I’m not 100% certain if that gallery randomly orders. These were basically from the logos at the top on WooCommerce’s gallery, and then the first few in the gallery itself when I loaded the page. I didn’t really dig around. I was just, like, “What comes up first?” Because these are probably the websites that if they come up first and the order is consistent for everyone, that the most people see as examples of what you can do with WooCommerce.
So I did a quick assessment of these 10 sites. I used the WAVE browser extension on them to see if they had errors, contrast errors, or alerts, and the number, and I have that listed here for each one, and I’ll go through them, so just in case you can’t see the slides, you don’t have to worry about that, and then I did just a quick manual assessment, which was essentially on the home page. I tabbed around and I assessed, did it have a visible focus outline? Did it have skip links? And did it have a functional navigation menu where I could get to the dropdown?
So these shops are a wide variety, some of the ones that are on here is the All Black Shop, which is to buy merchandise for a soccer or a football team, depending upon where you are in the world, what you might call that.
Bjork, the singer’s website, some different E-commerce websites for really big businesses, so Weber Grills, their New Zealand website was here. The Stroopwafel website, where you can order Stroopwafel cookies is here, and a lot of stuff.
The best one that I found as far as WAVE goes, was called “OffermanWoodshop.com.” It had three errors, zero contrast errors, and eight alerts, and at first I thought, “OK, maybe this will be the best website.” But then it didn’t have functional dropdown menus. It did have skip links, and it did have focus, but I could not access the dropdown menus and the navigation via a keyboard alone.
It’s really hard on these, because, you know, an interesting thing, one of the other ones that looks like it might be sort of good is Bjork, the singer’s website, which has four errors, one contrast error, six alerts, and yes, it had visible focus, skip links, and functional map. It had all of those things. But the four errors are all unlabeled form fields.
So not all issues are the same, some of the other ones that had larger numbers, like the All Black Shop, that one for the soccer/football team, the 32 errors were almost all linked images missing alternative text, and it’s because they aren’t adding alternative text for their products, and when you have a product, gallery or grid, it links the images, too, not just the title of the product, and if you don’t have alt text, then depending on how it’s built, it doesn’t always provide anything, so there can be a lot of problems.
I’ll share links to the slides, and at the end, if we want to dive into any of these, we can. But what I wanted to point out here is, at first glance, I couldn’t find any great examples of WooCommerce websites that work really well, and that doesn’t bode very well for how easy it is to do this and make something with WooCommerce accessible, if there’s not a lot of examples. But at the same time, I’m not surprised by this.
If you’re familiar with the WebAIM Million, which WebAIM, the organization behind the WAVE browser extension, puts out every year a report, over 90% of websites have easily-detectable accessibility problems, so while this is disappointing, it’s also not surprising to me.
Then I said, OK, what if I want to assess how accessible the WooCommerce website was, or how possible is it to build a WooCommerce website? Basically, I decided the best way I’m going to figure this out is by building one myself.
I think there’s a question that DK asked about when I went through and I did that assessment with WAVE, and I was tabbing through a little bit manually to see how things work, if I was just doing the homepage, or maybe the WooCommerce portions of the site were better than the homepage? And I think that’s a great question.
I did look at some of them on their shop archives. I didn’t go to any of their single products, and then I didn’t do things like “add them to cart.” So it is possible that some of them might be better in the WooCommerce portion, because the theme can add a lot of problems and can control a lot of things beyond WooCommerce.
I saw websites where there were focus indicators in the WooCommerce sections because WooCommerce was adding them, but there were no focus indicators anywhere else because the theme had outline “colon none set.”
So what I decided was the best way to assess this is that I was going to build a basic E-commerce store. I was going to use the Twenty Twenty-Four theme and patterns that already came with the Twenty Twenty-Four theme for two reasons. One, I’m not a designer. I did not want to have to spend time designing this thing. But also, from a standpoint of trying to figure out what a baseline of accessibility in WooCommerce is, I think it’s most ideal to do that either using a core WordPress theme, or potentially to do it with, their storefront theme, if you want to assess how well they’re doing accessibility in storefront.
Although, for me, this was also a little bit of an ability to play around with full site editing. Basically what I did was I built a store using Twenty Twenty-Four WooCommerce, and I tried to add very minimal additional plugins. That shop is a fully functional E-commerce store. You can go to it at “Shop.EqualizeDigital.com.” We’re going to look at it and talk about some of the things on it throughout this talk. But it does fully function, and you can buy stuff if you want to.
Now I want to talk about what worked really well and was good about some of this, and then we’ll dive into challenges and other things that I found.
It’s been a while since we built an E-commerce shop. We don’t do a lot of WooCommerce anymore. We used to do more. Now we do auditing on WooCommerce websites, but we don’t actually build them.
So one thing I thought was super neat was that there is now a mini-cart, and I will show you what I am talking about, so I have flipped over to the store on our website, and you can see in the header there’s “Equalize Digital Shop.” There’s a navigation menu, “all products,” “FAQ contacts,” “my account.” And on the right-hand side there is a cart icon. It currently says $1.18, somethings in my cart. If I click on this, then it slides out – this is what they call the mini-cart – from the right side and it shows me what’s in my cart. I have the ability to click a link style. There’s a button to go view my cart page or go to checkout, and it has some other information here.
So I was pleasantly surprised to find that this existed in core WooCommerce. Before, I always thought you had to have a plugin for this, so I thought that was awesome.
I will say, this is a little bit on the full-site editing side. Outside of the nav menus, which I could probably go on the whole night talking about editing the nav menus in full site editing, but editing the templates for WooCommerce.., so they had many templates for the shop page, the product single, the cart, the checkout page. It was relatively straightforward for me as a typically abled person.
Full site editing can be really challenging to use with a screen reader, so I am not saying that it is easy or even straightforward for everyone. The nav menus, I spent, like, two hours trying to figure out how to build my nav menus, which sounds ridiculous when you listen to me say I had three items in my nav menu at the top. But that and the footer, there are definitely some challenges there. But to some degree, I did OK with editing the WooCommerce templates in a way that didn’t require me to pull them into the theme and write PHP code.
In my assessment of it, I found very few ambiguous links. I didn’t find very many unlabeled fields. It was clear to me that some accessibility work had been put in. I saw areas where “role equals button” had been added to a link, so obviously they circled back and they reevaluated, and they realized that things needed to be buttons instead of links, and so they were working on remediating it with ARIA.
There were also some workarounds for some of the problems that they found that were possible in full site editing, which may or may not be on WooCommerce for making that possible. It might be more just WordPress core, but there are some things that were good.
I’m going to give you the TLDR, which stands for “Too long, didn’t read.” If you want to leave right now, the short answer of, is it possible to build a low-code accessible WooCommerce website? The answer is, no, it’s not. Out of the box, WooCommerce is not fully accessible, and as of today, it is not possible to build a fully-accessible WooCommerce website without making code fixes.
I hope you’ll stick around, because I’m going to tell you what those problems are and what code fixes are needed. But I was disappointed, because I will say I have always had an interest in trying to make it easier for non-technical people to build accessible websites, and I’ve wanted to prove that it’s possible, so I was a little bit frustrated and disappointed that I ran into as many problems with WooCommerce as I ran into.
That said, just because this is the situation right now, it does not mean that it will always be the situation or the case, and it doesn’t mean that you can’t build an accessible website with WooCommerce. It just means you probably need a developer to help you do it.
There were three different types of issues that I encountered when I built the website. What I did was, I built it out, I did testing with our Accessibility Checker plugin, I did keyboard testing, and then I tested it with both Voiceover and NVDA. The three kinds of things I encountered during my testing were CSS things, pretty small style tweaks that needed to be made to a few elements for color contrast or some other things that I’ll talk about in just a minute.
Other things that were easily fixable in the editor, which I’m calling easy template adjustments, even though some of them actually had a really major impact if I had not corrected them, but I was able to correct them without code.
The third one is where the vast majority of their problems fell, which is what I’m calling dev-level fixes, so these are things that ideally should be patched by WooCommerce, because we want them rolled out by everyone. We don’t want to have to maintain the technical debt of our JavaScript loading on the front and correcting WooCommerce. Or us building a template that might get out of date when WooCommerce releases a template update. That said, if WooCommerce were not to fix them, they could be remediated by a developer with either JavaScript or hooks and filters. During the course of my testing of this website, I opened 45 GitHub issues for WooCommerce.
>> STEVE JONES: This episode of Accessibility Craft is sponsored by Equalize Digital Accessibility Checker, the WordPress plugin that helps you find accessibility problems before you hit publish.
A WordPress native tool, Accessibility Checker provides reports directly on the post edit screen. Reports are comprehensive enough for an accessibility professional or developer, but easy enough for a content creator to understand.
Accessibility Checker is an ideal tool to audit existing WordPress websites find, accessibility problems during new builds, or monitor accessibility and remind content creators of accessibility best practices on an ongoing basis. Scans run on your server, so there are no per page fees or external API connections. GDPR and privacy compliant, real time accessibility scanning.
Scan unlimited posts and pages with Accessibility Checker free. Upgrade to a paid version of Accessibility Checker to scan custom post types and password protected sites, view site wide open issue reports and more.
Download Accessibility Checker free today at equalizedigital.com/accessibility-checker. Use coupon code accessibilitycraft to save 10% on any paid plan.
>> AMBER: So let’s start with the CSS fixes, sort of easy things. I put a public gist on GitHub, which we can look at here quickly and talk about some of the CSS fixes that I made. I just put these in the customizer, not the way a real developer would do it. But again, I was going for low-code.
So there were a couple of instances where I needed to fix focus indicators, some of which were 2024. I actually opened a GitHub issue for 2024 because they were using one pixel dotted, and it’s very hard to see, and I don’t think that it’s large enough, so I corrected that.
The main thing in WooCommerce, where I fixed the focus outline, and that’s this first section of code, is in the WooCommerce loops, which is what I’m going to call these, so that’s either if you’re having a block that is displaying some number of products, or you are on the main shop archive page, and there is an image followed by the title of the product, followed by the price, and sometimes a button.
The initial way that this got focus was it could go to the image and it could go to the link, and if we see this on the product page, then we can see that also.
Let me see if I can go tab to that.
So here I’m on the product page, and right now, there is a focus indicator on the image for the pint glass. Then I hit tab again and it goes to the title. WooCommerce by default does not have a focus outline on these images, and the link that is behind is behind the image. The container doesn’t fit to the image, so just adding it doesn’t work.
So the first fix I did was applying that to the WooCommerce product image, so I’ve got a class for .Wc-block-components-product-image-a:focus, so I’m saying it needs it, and then I ended up having to, on that block, the link, put a display block on it so that the A tag would go up and you could actually see it around the image, so that was the only instance I found where WooCommerce was failing to add a focus outline. Otherwise, it generally did.
A thing that I’m not in love with right now that I have to figure out how to resolve for is that WooCommerce defines a color for focus, so you’ll notice here when I tab to the title, it’s purple. When I go to the image, it’s black, and the reason for that is WooCommerce is setting it as purple. When I define focus outlines, I don’t like to set a color because some browsers, if you don’t set a color, will do a double-color outline so that it’ll be light and dark and it’s easier to see, and so I prefer to allow the browsers to do it.
I have to figure out how I can unset WooCommerce’s because I don’t love that I get black, purple, black, purple in different spots. Otherwise, I might just have to go through and manually set colors to override and force them to all be the same.
Next, I encountered three different color contrast issues in WooCommerce that I fixed with CSS. One was on the “view cart.” I guess I don’t have a link to that issue. When you first add a product to your cart from a product single, it’ll pop up a banner that’s usually green if you don’t style it, and then it has a link, “view cart.” And that had an opacity that was too low and it failed color contrast, so I made the opacity much closer to one on that.
The labels on all of the fields on the checkout page… We’ll just go to the checkout page for a minute. The default for all of these labels: first name, last name, address, email address, everything that there might be is a very light gray that fails color contrast, which I fixed, and then in some places, the error, color red, it didn’t even pass AA. In some places, it passed AA but not AAA, so I just universally made the error color everywhere past AAA and be a darker red, so that was the color contrast fixes.
The other thing that I did with CSS was, there were two places where they were using color alone, and that was on that banner I said, the “view cart” link, which was underlined, and then when you hovered over it, it just changed the opacity, so it very subtly changed the color, but there was no other indication of the hover state being enacted, and then vice versa.
On the checkout page, the “return to cart” link, which I’ll show you, its down here at the bottom, this only had a color or opacity change. It currently has no underline, and on hover now, it has an underline.
So there were a few places where I noticed that they were only using color, and I either added or removed text decoration in order to ensure that we had a visual change in addition to a color change, for people who are color blind.
So those were sort of the basic changes that I made to CSS on the front-end, and then there’s one other change that I have to make that’s not on the front-end. But what I’ll show you is that in the email that is sent out to users or customers after they make a purchase, there’s footer text, and the default color of the text, even if you put it on a total white background, it’s such a light gray that it fails color contrast, so in that specific scenario, what I ended up doing was inlining.
It is kind of frustrating because it’s the one they don’t have a setting for, so that field accepts HTML, and you can type whatever you want in there, so I actually put a span tag around all my text, and set the color in that way there so that I can make sure that the emails that WooCommerce send also pass color contrast.
I’m not going to open my slides a bunch because I think it’s more useful for us to see different tabs.
The next area was editor fixes, so things that needed to be fixed, some of which were pretty major, so when we talk about testing the homepage versus testing the shop and the product single, one thing that this caught me on that I almost missed initially and then I accidentally saw it on the product single, which made me go back and recheck the shop archive, was there were no skip links, and I had tested it on the homepage and they were there, so then I dug into 2024 and I was trying to figure out why I didn’t have skip links on my shop archive and my product single, and what came out of it is that WooCommerce has a template, and basically, when you go in… I’m showing you an image right now from the full site editor where I’m editing the template for the product catalog, which is the same thing as the shop archive. But the template in WooCommerce is called product catalog.
There is a group container, and on that group container that everything is in, the breadcrumbs, the title, the notices the different products, things like that, under “advanced settings,” there is a dropdown where you can set the HTML element, and the person at WooCommerce who created this template, which then every WooCommerce website uses, just left it as the default, which is a div. When, in fact, what it needed to be done is toggled and set to main, because the 2024 theme only adds skip links if a main tag is present on the page, and in fact, it is actually incorrect to not have a main tag, because you should have all of your content contained in semantic landmarks.
This is incredibly easy fix, right? I went in there and I toggle the dropdown. It doesn’t require a developer. But if you don’t know about this, it can cause major issues for accessibility on your site, so obviously, it’s something that we need WooCommerce to go fix so that everybody who spins up and uses this template don’t encounter that.
Likewise, there were some minor things around heading level, so on the sample content, on the refunds page, they go from the H1 to the H3. On the cart and the checkout page, I don’t really know why, but the checkout here, the title of the page was an H2, so they were both missing H1s.
I didn’t actually open a GitHub issue for them because it already said when I opened it, it was edited, and so I was, like, [inaudible]. I wasn’t sure. It’s something I need to experiment with and see if that’s an issue I need to flag for WooCommerce or not.
The other thing that I did on the checkout page in my template was, I added a message above my checkout fields that says, “All fields are required unless marked with ‘optional’.” And the reason why is, it threw me off at first that there is no visible required indicator on this page. I expect field labels to either have an asterisk at a minimum, or literally say “required.” When in fact, it’s sort of the opposite here, because the assumption is pretty much everything is required, and so I felt like it’s more clear, and maybe we need to provide users with an explanation that everything is required unless marked with “optional,” because it’s the reverse of what people expected, so I added that to my template.
The other thing that I did was I turned on the setting in WooCommerce under “add-to-cart behavior,” “redirect to the cart page after successful addition.” I did not originally have that turned on my WooCommerce settings. But the reason why I turned it on is because the default behavior in WooCommerce on a product single, if you don’t have that, is that it adds a banner message above the product title and the product image gallery that just says something, like, one or two or however many, and the product name have been added to your cart, and there’s that “view cart” link that I mentioned failed color contrast that I fixed. But this banner is not announced to screen reader users, and in fact, default behavior is the page reloads, and so it dumps screen-reader users up at the top of the page when the page reloads.
I’m, like, “How do they know if it successfully functioned, if it doesn’t tell a screen-reader user that something was added to the cart?” My workaround for this was, turn on that setting, and now they just go to the cart and their thing is in the cart.
Again , it’s an easy fix that you may or may not love. Your clients may or may not love that, but at the same time, you can toggle that box and then it’s guaranteed that everyone will know, yes, this guy added to the cart, and they aren’t going to have to sit there and try and figure out if it works or not.
The other thing was the focus order on the checkout page. On this checkout page, the design that you’re seeing right now is the default design, but I have fixed my focus order, and on the left, we have all of the fields: contact information, shipping address, shipping options and rates, billing address, if you needed that, credit card information, going all the way down to placing-an-order button. That’s a left column that’s about three-quarters wide.
The other column to the right has our order summary, which is actually an accordion that can expand and collapse, and it can show products. I only have one product in my cart, but if you had multiple products in the cart, then it would show multiple products. The ability to add a coupon is also over here, and then there is a summary of subtotal shipping, and what the total will be.
The way this is set up is that, on mobile, I’ll just make my screen more narrow to go over to mobile. Or if I am a low-vision user and I am zoomed in to 250% or more, it stacks the order summary and the coupon fields and everything above the checkout fields, which is logical. I think that totally makes sense and that’s correct.
The default way that this is, though, is that the focus order does not match in default WooCommerce, so what would happen is if you load this.., and by default, it’s collapsed when I was loading it in my testing. In order for me to get to the order summary to expand it, or to get to this button and add a coupon so that I can add a coupon to my order, I have to tab first through everything down below, so it’s pretty major because somebody could get all the way through, get to place an order, assume they’re done, and never know that they could add a coupon, because they’d actually have to tab to that coupon and it would jump them all the way back up to the top, which is not logical, so it’s a focus order failure, and that is definitely something that has been raised in complaints when people who are blind did not have same access to discounts as people who are sighted.
So what I did that was pretty easy is I just reverse ordered these columns in the template for the page, and then on my gist, which is the very last thing I have here, I used a flex-direction row-reverse on the container: wc-blocks-components-sidebar-layout. I did add a custom class, order-corrected to the container above that because I want to make sure I wasn’t flex-directing anything else weird.
So I’m only targeting the specific one, but that allowed the actual order on my checkout page to be corrected so that I get things in the visual order on the page. But when we encounter it at the view where it’s side by side, it looks the same way that they had styled it originally.
Also, honestly, in this order, it does make sense, if we’re tabbing, to go to the order summary and be able to expand that. Go to “add a coupon” before we get to the contact information.
So again, this is something that was relatively easy for me to do. It took one line of CSS. It was just dragging to (two?) column, switching the order of the columns in the template, but it actually solves a major accessibility problem.
Where that brings us next is all of those other issues that I could not fix, so of the 45 issues that I identified and reported to them, 31 of them did not have what I could find as either no-code or low-code fix. You can find them on the GitHub link that is linked earlier in the slides, or I have them grouped by page in our accessibility statement on the shop, so if you go to the accessibility statement for the shop, I have these grouped by basically the kind of page that they’re on.
So I’ll talk a little bit about some of these. I don’t think we have enough time to go into all of them. But all of them are linked over to the GitHub issues that I created for WooCommerce.
So I have global. These are things related to the mini-cart, probably the biggest thing on that, and I’ll say, the mini-cart, not only was I pleased that it existed, but it was generally quite accessible. When you open it, it announces that it’s open, it shifts keyboard focus in, it has a focus lock, it does everything that I expect a pop-up modal to do, except it doesn’t return the keyboard focus to the button that triggers it when it’s closed.
There was a pre-existing issue that I was able to replicate, which is that until JavaScript loans, it doesn’t have an accessible name. It relies on JavaScript to add that accessible name to the button that opens and closes it. I do think that’s worth noting. I feel like there’s a lot of accessibility fixes that don’t exist if JavaScript doesn’t exist, right? Like, you wouldn’t be able to change your expanded from true to false, or things like that. But that said, it should have an accessible name even if someone isn’t loading JavaScript.
The only other issue that I noted on it was if you zoom in a lot, so about 300%, 400%, like a very low-vision user, there’s sticky elements in the footer that actually blocks your ability to see what is in that mini-cart, so my preference would be that there should be no sticky elements. But otherwise, I feel like it’s quite accessible, and it’s more accessible than some of the alternatives that I have seen.
The other global thing that I added, I called it enhancement more than a bug, but I would love to see ARIA labels added to price ranges, so what happens in a screen reader that just reads, for example, “$25, $29,” which doesn’t have a lot of meaning? So I think that could be improved if it had an ARIA label that’s something like, “Price range: $25 through $29.” Sighted people have a hyphen, but the hyphen isn’t read out by a screen reader.
On the main shop page, the only major issue that I found was that the product-sorting message wasn’t provided for screen readers when you use that dropdown to sort.
On individual product pages, the vast majority of the problems were around the product gallery, as you can imagine. There’s actually an open issue, which I don’t have listed here, but someone flagged, that I’m intending to go respond to. They said they had a blind person test, and the blind person found it really challenging that… Let’s go look at our product.
The default design in WooCommerce is that the product image in a gallery, which could have very many… I’m on a product that only has two images, but it could have a lot [inaudible] before the H1 and all of the details, and they had mentioned that the person who was testing their website found it challenging to get to the pricing and the variations, and be able to add to cart.
So actually, what I did to help sort of resolve this is I actually added a hidden screen-reader-only link above the product gallery that has, “Detect, bypass gallery and go to product details.” And if you click it, it jumps you over to the column that has the H1 and the price, and the “add to cart,” and all of that sort of stuff to allow people to quickly bypass the gallery.
I think there’s other things that needs to be done to improve the gallery, and I opened several issues for them, but I think there’s definitely more that could be done on it beyond what I’ve reported here.
Minor but somewhat important issue. The product tags down here, so description, additional information, reviews don’t have aria-selected so they don’t tell you, if you are a screen-reader user, which one is active.
Another thing that is probably one of the bigger issues from a functionality standpoint is… See, now I’ve gotten to the point where I have too many tabs. Let me go back. Oh that’s not where I meant to go. I’m going to open up product that has variations. We’ll look at our “Make WordPress Accessible” T-shirt.
When you choose variations, there is a clear button, although it’s coded like a link, so this needs to be fixed, and what that does is it would clear out what you have already selected in the form as far as color and size and any other variations. But the other sort of major issue here is that it doesn’t announce anything to screen-reader users when you do clear it, so they don’t know, and it doesn’t move focus. Your focus actually stays on the “clear” link, which is actually on the page. It’s just visually hidden, but it’s there, so there are some issues related to that. If they don’t find a variation, there’s a visible error message that comes out, but they don’t hear it, so some things on there.
On the cart page, the coupon button was a link that has a role button added, but they haven’t added spacebar handlers, same thing with the “change address” button on the cart page. After changing your address, if you’re trying to get shipping rates, keyboard focus wasn’t managed appropriately.
On the checkout page, the “buy with Google Pay” button – which only shows up if you’re in a Chrome browser, which I’m not using right now, so I can’t show it to you – doesn’t have a focus outline.
I put a note on there for them. I don’t know if they can fix it because it loads in an iframe, and so it might be a stripe thing, and maybe stripe needs to fix that. But I’m assuming WooCommerce has way more pull with stripe than I do, [chuckles] so I opened a WooCommerce issue.
Then the “return to cart” link on the checkout page is missing for zoomed-in users, so that link we saw down at the bottom where I was talking about it didn’t have an underline on hover and I added it, they made the choice to remove it from mobile.
When you remove things from mobile, it removes them for low-vision users who are zoomed in too, and that’s not correct, so they need to figure out a different way to handle that.
Then there were a host of issues on the “my account” pages, which I can just show you real quick what I’m talking about so everyone can visualize that. I’ll open yet another tab just to keep myself confused.
So there’s a nav menu here, which says “dashboard, orders, addresses, payment methods, account details, and logout.” So these are sort of the account pages. It’s in a nav tag, but it’s unlabeled. Pretty much every single one of these subpages has heading levels that it skips, so it has the H1, and then it goes to H3s, so they’re skipping heading levels a lot.
There are a few ambiguous links here, so for example, billing address, this ad link, or if you already have one, it says “edit.” And it doesn’t say which address, and there’s two of them. It doesn’t say which one.
On the “view order” screen, there’s also some issues there with some ambiguous links and those sorts of things. Things that I don’t feel like would be hard for them to fix, but would make a big difference.
The other thing that I think is probably the more major difference for usability on these pages is, you’ll notice I’m on the address page now. If I go to the orders page, the thing that is important to note, the page reloads, the URL changes, but the H1 on all of these still says “my account,” and the page title, which we can see if we can get there, it all just says “my account.” So it doesn’t ever change to adequately reflect the content on the page, which I think could be very confusing and problematic for people.
There were a couple of issues around error and success message handling on these forms on these pages, and the login page, so kind of a very long list, but those are things that I encountered that I was, like, “I don’t know how to fix these in a no-code way.” And I would have to pull in one of my developers to fix them, but what I’m really hoping is WooCommerce will fix them for everyone.
The way I handled this, as you probably noticed, was I created an accessibility statement. I said, “Hey, this is a work in progress. Here are all the issues that we found.” And I linked over to them on GitHub so people could follow the progress.
I think this works for me because I don’t actually know if anyone’s going to buy any products from me, and I’m not trying to get people to buy products from me, and it’s not my main business, right? But if you have a revenue-generating store, and you encounter problems like this in a plugin, some of which could be considered blockers, then waiting for a fix from a plugin developer might not be the best option, and that’s something that you need to assess, so just because I did it in that way on this particular store.
So if this were me and I had a WooCommerce website, and this was my primary business website, the things that I would probably look at patching – either by perhaps having my developer volunteer time for WooCommerce when submitting a patch to WooCommerce, or if not, patching them in our theme in some way – are the things that I consider to be potential blockers, so from that list that we just talked about, the biggest potential issues I see are the mini-cart losing keyboard focus. I think almost everyone’s going to use that cart, and it’s going to be incredibly frustrating to get dumped out of it and not be where you were when you close it.
Sticky elements in the mini-cart, we looked at that when you’re zoomed in, so low-vision, there shouldn’t be anything sticky, and now when I might be able to fix with CSS, I just didn’t have time to really dig into finding it, and then issues related to the “clear” button on the product single, you really want to make sure that works well. This adding the spacebar handlers on the cart and the checkout page for those buttons, well, they were links that had been turned into buttons and were missing spacebar handlers, and then ensuring that all the status messages were announced by forms, so any of the times that they weren’t announced, those are probably things I would be assessing right now.
So if you have a WooCommerce store, I would check for these things, and if so, you might want to patch them in your own store while we wait for WooCommerce to make fixes.
I built my shop using Printful, and I want to take a moment to talk a little bit about some issues with Printful and show you something, so first thing to be aware of is, when you import products from Printful, it imports what looks like a list, but it’s actually what I call a faux list into your product descriptions, so it has what looks like bullet points, but it’s actually, within a paragraph tag, there’s a mid-dot, so a round circle that appears to be a bullet and breaks, so they’re not actually real lists, and that’s something that I had to go through and fix.
The other thing that was so bad that I ended up just hiding it from the page, which we’ll go look at, is the Printful size guide, so it pretty much violates everything that could possibly be violated in this one element.
Let me find it real quick. I just hid it with CSS. Oh, wait, I wonder if I need to go. All right, look, I’m going to comment out my CSS that is hiding it for a second so that we can see it. See I did try to fix a reflow thing, but I have a comment out because it didn’t work right now so. Let me comment this out.
So now I have my size guide from Printful back, which I’m going to hide as soon as this call is over because of how bad it is. I’m going to turn on a screen reader.
All right, so what this size guide does is it opens a pop-up so people can learn more about the sizes and choose which one is right for them, so I’m going to navigate to it. I’ll be pausing Voiceover, and I’ll point out some of the things that it does wrong.
As far as models and pop-ups, if you have them on your website, you can take a lot away from this to go and test and make sure that yours don’t do that.
[screen reader voice]
All right, so first thing is I got to size guide. It’s a link. Links go somewhere. They go to another section on the page. They go to a different page. When a modal is opened, it should be a button that triggers an action, so I want to hear that it’s a button, and it should be a real button, so I should be able to trigger it with a space bar or a “return” key. It should also tell me it has a popup, so you’d want to have aria-haspopup=dialogue, so I know that it has that kind of popup. I’m just going to open it now.
Nobody heard anything. It opened, it did not focus, it didn’t shift the focus into it, and it didn’t tell me that it opened, so for someone who cannot see that it opened, they don’t know that it opened.
I’m going to see if I can make my way into it.
[screen reader voice]
I’m hitting tab behind it and you’ll notice that it’s reading things out behind the page.
[screen reader voice]
All right, so I’ve gone through the entire page and I can’t get in here at all, which seems odd to me because what I see as I use my mouse is I have tabs. These should be focusable. I also have a “close” button, which should be focusable, which would mean that I should be able to at least get to these items if going all the way to the bottom page. Usually pop-ups are in the footer, and I’ve gone beyond it, so I’m going to turn Voiceover off, and we can explore why I cannot get to these things.
So my “close” button, that is a button, so I find that a little odd. I’m not really sure. It kind of makes me want to say, “Where is this?” This might actually not be in the footer.
Let me see if I can keep [inaudible]. See, now I’m on it. Where was I? Oh, yes, I’m on the FAQ. That’s the footer. All right, now I’m on it, so I got to that button. However, that button… Actually, we’ll turn the Voiceover back on.
[screen reader voice]
So voiceover told me to get missing image descriptions button, so as we can see in the Inspector, this button has an X in it that is an image with no alternate text, and there’s no ARIA label, so no one would know that this is a “closed” button.
Now, from here, can I tab?
[screen reader voice]
So I can’t tab to these visual tabs, and the reason why is because they are a list and just with text. There’s no button or a link in them. It’d be better if there’s button, but you can make accessible tabs with links, so these are not keyboard-focusable at all.
The other thing I noticed, there’s also tabs down here that’ll allow me to toggle inches and centimeters. Also, not keyboard-focusable. Built the same way with the list, but nothing in it besides text. They’re probably using JavaScript to control the function.
Then to make matters worse, we have a table that has size, length, width. It is using the T-head tag, but the elements inside there are just in TD tags. They’re not set as headings, so I saw all this and I said, “Wow, that’s a lot of work to fix that.” And also, I can’t close it with the “escape” key. I cannot close it by clicking on the overlay behind it, but luckily it does close with buttons. Can only close it with that unlabeled button. Can’t use the “escape” key or click anywhere else on the website to make it close.
So my solution on this, as you all saw, was I couldn’t figure out how to turn it off in settings, so I just went into my CSS and I added a “display none” on it, which screen readers will respect that. It means if not focusable, it’s not there. At some point, I do want to try and figure that out.
So if you use Printful, beware. I would not use that on your site if you were worried about accessibility.
I have maybe 150 images on this website, and I thought, what better time than now to test out some AI-generated alt text? So I used a free trial and got 25 images worth of alt text from “AltText.ai.” The reason why I used that one was because it said that it looks at the product title, and if you have meta descriptions and stuff from Yoast, it will look at that too, so I thought, it will give me more accuracy.
What I’m showing right now are four different images and what “AltText.ai” said about them, and what I said about them, so the first one is the filler image that WooCommerce has, which I do not give alt text to you because if you’ve not provided a real image on your product, the filler image is decorative, so I don’t think it needs it, but, of course, “AltText.ai” is not that smart so “AltText.ai” said, “An image of a square with a mountain on it.” It says it’s an illustrated mountain.
For our pins accessibility, “AltText.ai” said, “A set of accessibility pins with a green cactus on them.”
I said, “A set of accessibility pins with five different patterns described in product description,” because I did not want my alt text to be so wordy as to explain how all five of these are.
By the way, if you are not looking at these pins, they do not have a cactus. That is an alligator. But I guess they have a much larger image that they were served, so they saw it as a cactus, but it is actually our alley mascot.
Then there’s an image that is a white hoodie, and it has three different red-dotted lines labeled A, B, and, C. This goes with the measurement and size guide from Printful. “AltText.ai” just said, “The measurements of a white hoodie.” And what I said was, “A hoodie with lines indicating how to measure length from the shoulder near the neckline to the hem. Width, across the chest at the armpits, and sleeve, from middle back of neck to wrist.
Their thing is technically right, “the measurements of a white hoodie,” sort of. But what’s important about this image is actually telling people how to measure things, if they’re trying to measure themselves or measure some other piece of clothing they have to decide what size to buy, and so just saying the measurements doesn’t communicate the important information about how or where to do measurements.
Then the final image is a gray make-WordPress-accessible T-shirt, and this one got a little weird. I thought for sure that it would do OK because it has the product title, but also I thought it could read text on images, but it did not do a super-great job of reading text on images, so “AltText.ai” for this T-shirt said, “The Make-WordPress-accessible youth T-shirt with WordPress design,” which makes no sense, and I said, “Gray T-shirt showing a drawing of a block editor toolbar from the WordPress editor, set to an H1, above the stack, text, ‘make WordPress accessible’. The text covers the entire chest area of the shirt.”
So again, thinking what people need to know if they’re trying to decide if they want to buy this product or if it looks like something that they want.
My takeaway is still the same. I don’t think that alttext generators can really give you good things, so I wouldn’t recommend doing it.
Now, if you are building WooCommerce websites, the other plugins that I would look at that are likely to add problems would be, first, any page builders.
A lot of those websites in the showcase were built were different page builders. Anytime you do that, there are definitely going to be elements that are not going to be accessible, so I’ll be careful about that.
Search and filter plugins, and we could look at some of these if we want to. I’m going to wait till Q&A before pulling some of them up, but I have a few that we could look at. But the ones where they add filters on the sides. We’re in the middle of auditing two different WooCommerce websites right now, and both of them had filtering plugins that had problems, so that is something to beware of.
Search suggestion plugins, so this is like you have a search box, and type it in, and then it shows, like, “Here’s products,” with pictures of them and all that stuff. Almost every single one that I’ve tested.
A couple of months ago, I tested, like, six different ones, and none of them were keyboard-accessible or accessible for people on screen readers as far as being able to access the suggestion results.
Any sort of floating carts, so that mini-cart that we saw, there were a couple of issues I mentioned, but in general, it did really well. But I’ve seen other ones where they add a floating cart icon on the side or down by the footer, maybe in the bottom-right corner, sometimes those are impossible to reach. They typically don’t manage focus well, even when they’re open. You see things like we just saw on that pop-up for the size guide, where it opens, but no one’s told that it’s opened, and it doesn’t shift focus in, so I’d be really aware of that if you’re using those.
Anything that modifies the checkout page. The things I found on the checkout page for WooCommerce were really minor. There were two things, and they were both pretty minor. It works well once you fix the focus order, so I would be careful about plugins. I’ve seen some where it turns them into steps, and then it only shows you your addresses here, and then you hit “next,” and then it shows you the billing or whatever that might be, so I’d be really careful about those.
PDF invoice generators. I have never seen a single one of these that creates accessible PDFs, so if you are generating the PDF invoice so that you can print it and put it in someone’s packing materials, it’s probably not that big of a deal. If you are emailing the PDF invoice to your customers, then it should be accessible, and these kind of plugins, typically, you wouldn’t want to use them. It would be better to manually create the PDFs yourself.
Then, of course, carousel tab or accordion plugins. We just saw an example of tabs that were completely non-functional if you couldn’t use a mouse. That happens a lot with different carousel tab and accordion plugins, so I’d be very wary of those.
What’s next for our shop? Obviously, I want to try and resolve issues with the Printful size guide, or come up with an alternative. I think having a size guide is really helpful to people, but that one is just so bad that, to me, it didn’t make sense to keep it on the site, and I’d rather no one have access to size information than have something that leaves some people out.
I was hoping, before this, to be able to test some of the different swatch selectors on the product single so that you can choose the color of your shirt with a square that shows the color or a circle, right? A button. Radio button, probably, is my assumption of how that should be coded. I haven’t had a chance to do that. I’m planning to do that. I’ll probably tweet about it if I find one that works.
I want to change the size attributes from a single letter to the full word, so on products, when you do size, it just has, like, L, M, S, XL, XS, that sort of stuff, and I think that it sounds better on a screen reader if it actually has the words written out.
I’m not sure how that works with Printful since I imported products from there, so again, it’s something I have to figure out, but I think that’s an enhancement that will improve things for everyone.
Then, exploring alternative options for the product gallery, particularly on products where there’s a lot of images. I haven’t had a chance to look at some of those plugins, but I feel like there’s a lot probably there that could be improved. I also haven’t tested the reviews’ functionality yet.
On the fun side, maybe more T-shirts, and I would love if anyone has any ideas, and maybe we can make some more T-shirts, so that’s what I’ve got.
I’m happy to answer questions. As I mentioned, I have a bunch of, like, the filter things pulled up that I could show you some different examples, because I was looking at some of those before.
Do you want to come back on, Paola? And maybe we can talk, if anyone does have any questions about WooCommerce accessibility, what’s possible, current status?
>> PAOLA: Yes. OK, I’m back on.
Thank you, Amber, for that very insightful presentation.
We did have a few questions come in. I’m going to start with this one from DK. It says: “Do you have any stats on the accessibility of non-WooCommerce sites? For example, Squarespace, Wix, how do they compare to WooCommerce accessibility?”
>> AMBER: I do not. The one thing I am wondering potentially is if WebAIM does.
Hold on, I’m going to try and search this. I’m in a different tab for a second, and if I find it, I’ll pull it over.
I feel like they have something where they say “accessibility by CMS.” And I think I have this linked in a presentation I did for AccessU. They have Shopify included in that. Give me one second and I’ll try and pull that up. But off the top of my head, I don’t know anything else other than that.
I don’t know if anyone else does. Feel free to throw anything in the chat.
We can go to the next question while I pull this up.
>> PAOLA: Yes. The other questions that came in were related to the sample pages you showed in that table at the beginning of the talk. I don’t know if you would prefer to go into your findings on those websites.
For example, one of the questions said that: “You mentioned you checked their homepages for errors. But how did the WooCommerce portions of the sites do?”
>> AMBER: Yes, so maybe what we can do is take a look at the ones that had functional navs and focus states and that kind of stuff, and I’m happy to pull some of them up.
So this is the All Blacks Shop. This one, when I tested this one, I did look at the main shop page in addition, so I’ll just pull up WAVE real quick, so we have a missing form label, 30 broken aria references, which is interesting. It probably means something didn’t load.
I can’t get WAVE even to show me what it’s saying. Oh, wait, there it is, so it’s on the, like, “select options” button, which is coming from WooCommerce.
Let’s see what that is. Oops. Oops. Let’s see, aria-describedby. It’s interesting. I don’t know why WAVE was calling that a broken aria. reference. Unless it’s somewhere else in here and it just looked like it was on the element.
So this page when I tested it, there was actually a lot of products on the homepage. It has carousels, which is a little bit odd. I’m smoothing my mouse left and right, and it moves them, so that was that one.
The Bjork website, I saw someone asked about that, [crosstalk ] was missing. Or empty form labels, I’m pretty sure, is what I remember, and the homepage is super basic on here. It has an image and some categories, and, like, no products or anything like we saw on the other website.
What was this? Yes, so the search form doesn’t have a label, and there’s two instances of the search form, and there’s one hidden form that also is a field that doesn’t have a label, but we can’t currently see it, and there’s a linked image missing alternative text, which is probably this super-funky image. Oh, it is this funky image in the middle. I don’t even know how to describe it. It looks like it’s computer-generated mushroom flower thing. I don’t even know.
>> PAOLA: Yes, it’s a hard one. [chuckles]
>> AMBER: This was one, though, where it had focus dates. It had skip links. It had mostly functional things. I mean, the nav is pretty basic. But, yes, it’s still had a few issues around search.
If you’re thinking about searching products… Let’s see. I’ll just search for one of these. Oh, see here, this is a great example. Let me turn. This one has a search suggest on it.
[screen reader voice]
All right, so I’m going to go out of this field and go back in. This field has search suggestions, and so it’s sort of interesting to see what I’d be able to get to the suggested products. Remember when I was talking about this is one area where plugins frequently don’t do a great idea.
[screen reader voice]
All right, so I’m just going to search for one I can see.
[screen reader voice]
What it’s done is it’s given me three products, and then also some suggestions for how I can filter, like, search inbox, search in merchandise, search in Bjork, which I’m guessing are maybe categories? But it didn’t tell me that. I can visually see them, but I didn’t hear that there are any suggestions available. I’m going to try either tab or arrow keys to see if I can get down to those, so this is a tab key.
[screen reader voice]
OK, so the tab key did function. It got me there. It’s reading out the text. Let’s see what “add to cart” says.
[screen reader voice]
So that’s good because it wasn’t just “add to cart.” It actually included the name of a product, so whatever plugin they’re using for this, we can inspect it. Let’s see if we can see.
The biggest thing on this was it’s not maybe totally unusable. But it probably needs an aria-live added to it so that it would announce… I don’t love that this isn’t a table. The search results, I think an unordered list would be better. But it could say, you know, “Three products found,” or something like that, and then tell people, and move them into it. But I’m trying to see if I can tell if it has any identifying stuff. It just says, “widget_product_search.” So I can’t obviously tell what plugin this is.
So this is one that is maybe usable, but needs a little bit of remediation.
>> PAOLA: Right, and going back to the previous question, Bet [phonetic] had a couple of comments, so I’m just going to read them out.
“Shopify has a number of issues similar to what Amber outlined.” And then Bet also mentioned: “For all of these, you’ll find that plugins and add-ons multiply, often by quite a bit the numbers of issues. Usually the types of things that Amber listed: product filtering, and sorting, etc.”
Moving on to our next question from Tedros: “Any recommendations on accessible plugins for a small business multi-vendor E-commerce site?”
>> AMBER: A multi-vendor? So that would allow them to submit their products on the front-end, would be my assumption. Kind of like an Etsy or an eBay or something.
>> PAOLA: Yes, that’s what I’m [crosstalk ] here.
>> AMBER: I am not the best on that front. I don’t know. Bet does a lot with WooCommerce, so Bet, if you know anything.
I did find what I was looking for. Unfortunately, I don’t know anything about those specific plugins, so I can’t make a recommendation.
So what I pulled over is a presentation I gave for AccessU, and it’s from the WebAIM Million in 2023, and they do have a section where they talk about accessibility errors by builder, and what the difference is, and which were better or worse, so from an average number of errors and being better.
It doesn’t look like Shopify is on here, which is unfortunate. Squarespace is on here, which I do know has an E-commerce.
Let me copy the link, and I can put that in the chat if anyone wants to reference it.
What actually makes this hard is that sometimes it says that it’s better.
I had this whole moment of just, like, Divvy is on here, and if you look at it comparatively, Divvy is 48% better than the average website. But if you’ve ever been in Divvy, you definitively know that’s not true, and that’s why it’s really important.
When I was doing my assessment, I wasn’t just looking at number of WAVE errors. I also checked to see if there’s a focus state. I tabbed around to see if the navigation work. That kind of stuff can’t be figured out without a human, so you have to take these kinds of things with a grain of salt.
Unfortunately, Shopify is not in here, which is odd because Shopify has a pretty large market share for E-commerce, but maybe WebAIM just isn’t looking at it.
>> PAOLA: Yes, and Bet mentioned: “Multi-vendor is a plugin feature that would have to be specifically tested.” So that’s there.
We do have a couple of questions. I know we’re almost out of time.
Dennis asked: “How can accessibility be maintained during updates to WooCommerce and its plugins?”
>> AMBER: Yes. I think the best way to handle that is, ideally, you want to test. I think the larger your WooCommerce store is and the more revenue you have going on it, you probably don’t want to be just running updates on your production site anyway, so you’d want to run them on a staging server and test things.
I would always recommend reading update messages, so developers of plugins list out what they changed in the update, and especially for WooCommerce, I would reference that. Just to make sure that if they mention, “Oh, we changed something in the cart,” then when you update it, I would go check the cart, and test all the way through the process, too, so that was like I mentioned.
Initially, I almost missed that the skip links were not working on the main shop page and the product page, because I only tested it on the homepage and I was just going through quickly, so really, I think, being thorough on your important parts, so test your product, test your shop page, test your cart, test your checkout every time, and maybe that means you batch your updates, so you’re not running updates every time, like, instantly when they’re available. Maybe you say, “We do them every Tuesday” or “We do them every other Tuesday” or whatever that looks like for your organization.
>> PAOLA: Yes, and then one last question that came in. I’ve kind of got the answer to this, but I wanted to get that in: “How about accessiBe and UserWay?”
>> AMBER: Yes, so overlay products are not great. They can’t find what a human can find, just like a testing tool can’t find what a human can find. They can fix some things, I will give them that. But they also make some really weird choices. Like we looked at the AI alt text generated and how it just didn’t quite do what it needed to do.
The European Accessibility Act, actually, if you are in Europe, specifically states that overlays are not acceptable, and increasingly, in the United States, there is no guarantee that having an overlay will keep someone from getting sued, and when they do get sued, part of the settlement is always that they will remove the overlay and fix their website the right way.
So I would save your $49 a month, and instead, focus on what you can do. Identify those critical areas and work on those, and just fix that first.
>> PAOLA: Yes. Thank you Amber.
I think that’s it, so we’re going to wrap everything up.
Thank you so much, Amber, for your amazing presentation, and thank you, everyone, for attending meetup today.
We’re just going to wait a few seconds to let the transcript finish.
Amber, do you have any last thoughts that you want to share?
>> AMBER: Yes. Thank you, everybody, for putting up with my coughing fits and all my weirdness today. [chuckles]
If you have any questions, the best place to get me is probably on Twitter. I’m at “@HeyAmberHinds.”
We will see you back here for meetup on February 1st, right?
>> PAOLA: Correct, yes.
>> AMBER: All right. Bye, everybody.
>> CHRIS: Thanks for listening to Accessibility Craft. If you enjoyed this episode, please subscribe in your podcast app to get notified when future episodes release. You can find Accessibility Craft on Apple podcasts, Google podcasts, Spotify, and more. And if building accessibility awareness is important to you, please consider rating Accessibility Craft five stars on Apple podcasts. Accessibility Craft is produced by Equalize Digital and hosted by Amber Hinds, Chris Hinds, and Steve Jones. Steve Jones composed our theme music. Learn how we helped make 1000s of WordPress websites more accessible at equalizedigital.com.