037: WooCommerce and Accessibility with Bet Hannon and Meg Miller

By /

This episode is a recording of a September 2023 WordPress Accessibility Meetup where the team from AccessiCart, an agency that specializes in accessibility and eCommerce, looked at the accessibility of the base WooCommerce plugin and some of its popular add-ons. If you want to watch a video recording from the meetup, you may do so on the Equalize Digital website: WooCommerce and Accessibility: Bet Hannon and Meg Miller.

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

Transcript

>> CHRIS HINDS: Welcome to episode 037 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 September 2023 WordPress Accessibility Meetup where the team from AccessiCart, an agency that specializes in accessibility and eCommerce, looked at the accessibility of the base WooCommerce plugin and some of its popular add-ons. 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/037.

And now, on to the show.

I am very excited to introduce our speakers. I’m going to add some spotlights to them to pop them up here for everyone. So you all should be able to see Bet Hannon and Meg Miller. 

Beth Hannon is the CEO of AccessiCart. She is also one of the lead organizers of WordPress Accessibility Day, and does a lot with accessibility in the community. So you may have seen her around, whether on social media or in various groups providing a lot of great expertise. 

Meg Miller, of course, has spoken for us before and has given a great presentation on alt text that I have gotten so much positive feedback. So I’m really excited to have you, Meg, come and share your expertise on WooCommerce, because we’ve never had a WooCommerce talk before. So we’re very excited. 

I am going to stop sharing my screen and I will let you all take over. For everyone who’s watching, if you can try to use the Q&A section, I will be watching that for questions. It’s a little bit easier for me than if you put them in the chat. I will watch the chat too, but they will get answered faster with Q&A. 

Do you want us to wait until the end, Bet and Meg? 

>> BET HANNON: Yes. If you could, that would be great. 

>> AMBER: OK. So we will hold questions until the end, and then I’ll pop in and we will ask them. 

>> BET: All right. Yes, we work together. This is kind of the first time that either of us have done a talk kind of in tandem with another person somewhere. That took a little extra coordination. So thanks, Amber. 

As we’re starting out today, I know that we have some folks with us who are fairly new to accessibility. Maybe they have a WooCommerce shop, and they’re thinking about accessibility, but they’re new to our community and some of the things about accessibility. So I want to start with just a fairly short moment about why you would want to make your website accessible. And a lot of people come to accessibility concerns because they’re worried about getting sued or fined. And, indeed, in the first half of this year already, 84% of the ADA lawsuits around web accessibility in the U.S. are E-commerce sites. So E-commerce is a place where there’s often a lot of accessibility issues. 

There’s also some new legislation coming into enforcement in the EU in June 2025, the European Accessibility Act, and it has some limited things. But basically, if you have a site that has EU customers, you’ll want to start checking on that, because like GDPR, it’s not where your business is based; it’s where your customers live. So thinking about accessibility and compliance with law is a huge deal for people. But there are a lot of other good reasons to begin thinking about accessibility for E-commerce shops.

Globally, about 20% to 25% of all adults have some disability, and a lot of those disabilities are more invisible. We want to make sure that all of those folks that have disabilities are able to use the web. There’s an equality piece here. But beyond that, people with disabilities, if they can’t make a purchase on your website, you are leaving money on the table. 

A study in the UK estimates that £6.9 billion are being lost annually by inaccessible websites to their competitors that are accessible. So in addition to making your site accessible, we’ll almost always improve your SEO, and always improve the user experience for all the visitors on your site. So lots of great reasons that you might want to make your site accessible. 

This talk, just for a fair warning, will not be an introduction to accessibility. We will be giving some overviews, some strategies, some technical information about testing, and some or even a lot of what we’re going to cover will be mostly helpful for developers. But if you’re not a developer, please do hang in, because I do think you’re going to have a lot of value in this talk, even if that’s just a list of things you now need to be aware of and take up with the folks who help you with your site. 

If you’re new to accessibility, here are some great resources to get you started. Amber mentioned some of them in the intro. The very first one in this list is this Meetup’s past presentations. You can find a ton of great presentations. They’re recordings to the past web presentations on a variety of topics. They’ll help you learn a lot of what you need to know. And that Facebook group, like Amber mentioned, is a great place for asking questions. And then finally on this list is the Ally Collective. And it’s an online resource where you can take self-paced learning courses. There are some other places too, but there are a lot of places around where you might want to start learning about accessibility. 

As we talk about various accessibility issues today, it’s important to acknowledge that while all accessibility issues are important to address, they’re not all equal in severity. Some accessibility issues are walls. That is, they prevent some people with disabilities from moving on to use the site at all. This would be a critical failure. And clearly, there’s a high demand for getting those issues addressed. 

Some issues are hurdles. They’re difficult. They create friction points. Some people with disabilities will have to go to great lengths to find a workaround, if they stick around on your site at all. Hurdles would be considered severe or moderate issues. 

Other issues are more curbs. They represent a smaller point of stumble or friction. They make the site more annoying to use. That’s not a great user experience. Curbs are considered minor issues. So walls, hurdles, and curbs. 

In this presentation, we want to organize talking about various potential accessibility issues in E-commerce by thinking loosely about the buyers’ journey. Before the potential customer even arrives at the site, there are some important things for the site owner to know accessibility in WooCommerce core and themes. But accessibility is more than just about things in core and themes. We’re going to talk about content accessibility. And then what’s a WooCommerce site without some plugins? We’ll talk about things to think about and to be aware of when you’re choosing plugins or having custom coding done, which will help you know what to test for, especially as we think about E-commerce functionalities that we would find on a WooCommerce site. 

We did some auditing on a lot of different plugins, and we did originally think about just giving a list of good and bad plugins for accessibility. But we ended up feeling like it’s a lot more valuable if we just try to help everyone be aware of those specific accessibility issues that are commonly found in E-commerce, and specifically WooCommerce sites. So Meg is going to start us off with Woo and Themes. 

>> MEG MILLER: OK. A few curbs. WooCommerce has done a good job progressing its front-end accessibility standards. WooCommerce tends to take accessibility concerns seriously, as evident in both their repo forums and GitHub communities. They regularly prioritize critical accessibility issues and take time for quality assurance. There are a couple curbs here and there. I’m not saying they’re 100% accessible, but most users should be able to successfully browse and purchase items successfully using WooCore alone. Most accessibility issues on Woo sites are a result of a theme, a plugin, or poor content practices. And we’re going to go ahead and get started with themes. 

Shopping for a theme can be both nerve-wracking and exhilarating when trying to find one that reflects the vibe of your shop, but there are things to look out for to ensure it’s functional in addition to simply looking nice. And bear warning, there is a difference between a theme being accessibility-ready, as you would see a tag for in the repo, and actually being accessible. Well, there are definitely themes out there that are true blue accessibility themes by developers who understand the needs of users beyond aesthetics. This isn’t always the case. At best, being accessibility-ready means the heavy lifting is in place, but there are still optimizations that need to be made to make it accessible. 

This often means adjusting colors or increasing font sizes or those details. But other times, accessibility-ready is just tacked onto a theme to encourage download when it doesn’t even have base-level accessibility optimizations, and we’ve certainly seen those before. Checking the accessibility of a WooCommerce theme isn’t much different than checking the accessibility of any other site. But if it comes with additional features, special attention will want to be paid here. 

Since we already stated this won’t be an intro to accessibility, we’re only going to quickly review universal theme accessibility concerns. Font and interface colors should have adequate contrast to their backgrounds, which will vary depending on the size of the object. Typography itself is important for legibility. Avoid themes that force you into a cursive, handwritten, or decorative font. These are notoriously difficult to read, especially for those who may have a cognitive disability. Also, keep in mind, cursive hasn’t been a required third-grade curriculum in the US since 2010, meaning anyone born after 2002 may be at a disadvantage, and that’s 21 and younger, for those of you who aren’t keeping track. 

Themes should be able to zoom up to 200% without loss of content or functionality, and this is an official WCAG guideline, part of the success criterion. Skip link presence should be tested for and their functionality should be confirmed, especially if you’re using a menu plugin or any sort of page builder. It’s not uncommon for these to break the skip link IDs that they depend on to work. 

Clear user interface components and interactions. This means focus indication for keyboard users, clear hover effects that don’t rely only on color, and obvious field-focus indications. Sites should have a clear and logical reading order. This includes the tabbing order, which should be in the same order a user would visually read a site. And lastly, my favorite new enhancement of WCAG 2.2 is making clickable target size a double A requirement.

Clickable targets like buttons and social icons should be a minimum of 24 pixels by 24 pixels. This ensures those with motor disabilities have enough room to successfully interact with these items. Personally, I prefer to keep them a little bit bigger at about 40 by 40, but that’s just because I have chubby fingers and poor hand-eye coordination. 

So what makes a WooCommerce theme, in potential, special? So there are themes that have been optimized for WooCommerce, meaning a developer installed Woo on their dev environment and was sure to implement the theme styles to it. But then there are themes that were designed for WooCommerce, sometimes implementing special modals, features, or post types to optimize a shop. These features should be paid special attention. 

For example, a popular theme implements related product models on each side of the screen on single product pages. Other themes entirely overhaul the product catalogs or add specially designed sliders or carousels. These features are potentially the biggest differences between a standard theme and a WooCommerce theme. 

While I could do an entire presentation on why sliders should be avoided, we simply don’t have the time to go into details on every single possible feature an E-commerce theme could possibly provide. And it’s entirely possible to provide these custom features and still be totally accessible, but it all comes down to double checking. Regardless of what feature enticed you into a particular theme, it’s necessary to do your due diligence and ensure you’re not sacrificing function for form. So pay close attention to how the theme stands out from others, and start testing those features. 

If you’re not on the technical end of things, you’ll probably need to download some browser extensions or use third-party tools. For a quick view of text information, I like the browser extension, Fontanello. With Fontanello, you simply right-click on the text, navigate down to the Fontanello menu item, and an informative dropdown is available to you. As depicted in the screenshot on this slide, The dropdown will tell you a few things. One is the font size. While there’s not an official minimums font standard, it’s generally agreed upon that 16 pixels is a good minimum, especially for a standard body size. So if you have fonts on your theme that are less than that, you may want to consider bumping that up a bit. 

Additionally, Fontanello, in particular, shows you the contrast between the foreground text and the background color, as well as its accessible contrast pass or fail status. You can also check the color manually by copying the hex code from this dropdown. And from this particular dropdown, all you have to do is click on the hex code; you don’t have to write it down, and pasting it into a tool like WebAims Contrast Checker. 

I love the extension, Accessibility Insights, if only for their tab-stop feature, which will visually show the order as you tab down a page. This is great for really getting a good idea of reading order. It also has an accessible names feature, which is great for discovering elements that aren’t labeled properly, or could be masquerading as UI components; something that looks like a button, but isn’t one on a programmatic level. And we will go into depth about that a little bit later. This is a great tool for non-technical folks. At the very least, it will provide you with a list of things you’re going to want to have your developer check out. 

Lastly, I cannot say this enough, do not shy away from trying out a screen reader yourself. Well, you could download one. I use NVDA. Windows, Apple, iOS, and Android all come with built-in screen readers. Turn that bad boy on and take it for a spin. You don’t need to become a professional screen-reader user to get comfortable turning one on for the purpose of testing. After all, there are plenty of users who require assistive technology who are still at a novice level, and those people should be kept in mind also. 

Being comfortable with a screen reader and personally knowing what your site sounds like to someone who may not be able to visually see it already puts you miles ahead of your competitors. Google your OS and how to turn on the screen reader, and also how to turn it off. I encourage you to look up how to turn it off before you look up how to turn it on. Then just turn it on and listen. 

>> 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.

>> MEG: While there are many things that could create curbs, hurdles, or walls for a user, these are a few jumping-off points to consider when shopping for a theme. Be extra cautious if you’re interested in a theme that relies on a framework. A framework is an expanded dependency infrastructure placed on top of WordPress. Common examples of a framework are Genesis, iThemes, and underscores. Using a frame on top of your WordPress site can be extremely beneficial and add a ton of extra features. And a lot of them are actively optimizing themselves with accessibility in mind. However, developers who build themes meant for these frameworks are not always keeping those practices in mind, and can critically impede some of these enhancements by simply being unaware of their existence or necessity. Avoid page builders if you can; I’m very vocal about this. 

While the WordPress block editor has some back-end editor accessibility issues, for the front-end experience, laying page builders on top of it is redundant, and just creates more potential points of weakness and conflicts. This is unnecessary, considering you can pretty much do everything you’d need to within the native WordPress editor, especially considering the plethora of accessibility enhanced block library plugins available in the repo. 

Page builder themes and page builder frameworks tend to introduce many performance and accessibility issues. I’m not saying they’re inaccessible by nature, but they’re going to give you an extra unnecessary layer of required testing and troubleshooting when things go wrong. 

As Bet mentioned earlier, don’t be afraid to reach out to communities about themes and recommendations. Accessibility communities love talking about accessibility, and most give the milk away for free, because our goal is to ultimately make the web a more inclusive place. 

Selecting a theme should be about measuring twice and cutting once. And taking a few extra steps into consideration, even if a theme is advertised as accessibility-ready, can save you and your users a lot of grief down the line. Anyone familiar with accessibility knows there’s no such thing as, “One size fits all.” So if a theme is trying to tell you it’s the 100% accessibility cure-all, take extra cautions to ensure you’re not buying snake oil.

Back to bet, who’s going to talk to you about content accessibility. 

>> BET: So accessibility barriers are not just in the theme. I think that sometimes, a misconception that folks have is that it’s all about the developer-focused things in the theme. It’s important to remember website content accessibility basics must also be included in products. Anytime a product is edited, it can potentially create new accessibility issues. 

Again, if all of this is new to you, it’ll be covered in much greater depth in the resources we mentioned at the beginning of the talk, but here’s just a few reminders. Products should use nested heading tags as part of overall semantic HTML. The one and only one h1 on the product should be the product title, which should clearly describe the product. And everything after that should be properly nested semantic H tags. And using those H tags is really important, because it helps screen-reader users and assistive-technology users find their way, navigate their way through the product page. 

Every image should have alt text. In addition to basic good alt text practices, like not keyword stuffing, product images require special care for alt text, because you may want to include features that may be visible in the image, but not necessarily listed in the content. This needs to get balanced out, however, with not making the alt text to verbose, too long, and too detailed, especially if it’s trying to repeat content that’s in the features list of the text. So we have several posts on the AccessiCart blog about this topic. And last year, Meg gave, I think this is the presentation that Amber referenced at the beginning, an entire presentation for this meetup just on product image alt text. That has some helpful exercises, some experiments you can do to level up your product text alt skills. 

You want to make sure that you’re using good descriptive link text. People who are depending on screen readers… And by the way, that’s not just visually impaired people. Sometimes people with cognitive disabilities also depend on screen readers. Those users often skip through the content and have the screen reader read out loud just some of the H tags and the link text. And if you think about it, that’s what those of us who are sighted are doing as well. We’re skimming through the content. And so it’s really important that all of the text that you turn into a link could stand on its own outside the context of the rest of the text around it. So if someone were to simply read out loud the text of your link, they would know where they’re going to go and what that link was going to do. So you wouldn’t want to have “Click here, click here, click here” be the thing that the screen reader reads out. 

All videos need to have captions or transcripts. There are some great tools out there that will let you do this automatically and even for free. But if you’re using auto-captioning on those videos as you’re uploading them, you absolutely have to check them for accuracy, especially if those videos are using any specialized or technical language. Having captions or transcripts that clearly have not been proofread may convey to your user that you don’t really care about their experience on the site. And incorrect captions can negatively impact your SEO as well. 

Sometimes people are in the habit of creating what visually might appear to be a list, but really isn’t a list in the HTML. Like, you might do that with tabs or with hyphens. And this is a big problem, because then the code doesn’t tell the screen-reader user that the content is in a lister table, making that content potentially difficult to understand. So you always want to use actual bulleted or numbered lists, actual columns, actual tables that are a part of your webpage so that screen-reader users will have the proper context for understanding that content. 

Finally, I don’t have a slide for this, but use plain language, especially when you’re using calls for action. Being cute and making a button that says, or what appears to be a button say, “Let’s do this,” can be confusing versus a much more direct “Buy now.” 

So once you’ve made sure that your theme and your products are accessible, it’s time to turn to plugins and custom code. 

>> MEG: We may not have a slide for it, but I could probably do an entire presentation on cute language, and how often it’s seen, and how annoying it is. 

So as we indicated earlier, the good news is that WooCommerce, out of the box, is fairly accessible. Most major accessibility issues for WooCommerce come from plugins or custom coding. And that means when we are focused on front-end accessibility, any plugin or custom coding that affects the front-end output needs to be evaluated. This would include things like making changes to the product search, the add-to-cart functionality, making changes to the checkout process, and much more. 

Here’s a tip. Plugins and custom coding that work within the CoreWoo functionalities and components are much more likely to be accessible than plugins and custom coding that work around Core WooCommerce to do their own thing. Or what I like to call going rogue. We aren’t saying that it’s impossible to be accessible plugins or code or creating new functionalities and components; just that if a developer isn’t using best-practice code, there’s a good chance it won’t be.

Almost all WooCommerce stores need some add-ons or plugins. However, they can also make a store entirely unusable for some users. A lot of plugins can come with the same issues we discussed regarding themes. They can introduce poor color contrast, or lack of keyboard access, or focus indication. You can test them using the same methods. However, we’ll be talking a lot about code here, as a lot of plugin accessibility issues stem from bad development practices. Unfortunately, a lot of these issues can be difficult to diagnose, if you aren’t sure what you’re looking for or aren’t familiar with a browser inspector. 

So some people may need the assistance of a developer to avoid misdiagnosing issues. I encourage users to pay attention to both the support and review forums of plugins they’re considering. It’s not uncommon for folks to report accessibility issues there. If a plugin author responds to a user, you can also get a read on their commitment. And unfortunately, it’s still not uncommon for some plugin authors to disclose accessibility simply isn’t a priority for them. 

While we’ll touch on some testing methods here, the primary goal of this section is education, and making you aware of some of the accessibility issues lurking in the repo and practices being utilized by popular plugins that could be on your store right now. As I mentioned, we will be going through quite a bit of code talk here. But even if you’re not on the technical end of things, this should give you some good ideas of the kinds of questions you should be asking your developer. 

On this slide, we have some code here. In the left column, we have an A tag wrapped with link text that says, “Take me somewhere.” And in the right column, we have a button, and the text for that is, “Activate something.” 

Let me define some of what I mean by worst practices in development. Many things in web development can be done multiple ways. However, there are a few elements that have specific programmatic purposes, and should be used for specific things. Best practice coding means a developer is using an element as it was designed to be used. Well, bad or worse practice means a developer is usually misusing an element that already has a specific purpose, or forcing one element to act like a different one, which is often redundant, because as we said, there is probably an existing element that fills that need. 

As a quick example, we’ll use links and buttons. And when I say that, I mean A tags and button tags, not how they look visually. They could look identical, visually, on the front-end. It’s not uncommon for some developers to use these interchangeably, and this is bad practice. “A” tags are intended to take you somewhere, like another page off the site, or somewhere else on the same page. However, a button tag is meant to activate something, like a modal. These semantics are very important when it comes to accessibility. 

When elements aren’t used correctly, assistive technology doesn’t relay their information properly, and it can keep some people from accessing certain aspects of a site altogether. Worse practice coding standards are like using a baseball bat to hammer in a nail when there is an actual hammer within reach. This distinction is important, because best-practice code will almost always be accessible, and bad or worse practice code will almost always cause accessibility curbs, hurdles, or walls; and in most cases, negatively impact your SEO. 

Let’s consider some real-life examples. Gift card plugins, they’re very popular, and for good reason. Who doesn’t love a good gift card? What’s important when picking out a gift card? And I’d imagine the amount of the card is the top priority. WooCommerce uses input components for their products, things like selectors, radio buttons, and checkboxes. This method is very efficient when accessibility is kept in mind and everything is labeled correctly. 

For example, if the amount selection is using an input group with a semantic label titled, “Select the amount,” with amount options like $25, $50, and $75, using radio buttons, a low-vision screen-reader user should be able to successfully navigate and select from these options via keyboard, and have context for this field. This is a great method. You can even style these radio buttons to look like buttons. 

However, without keeping accessibility in mind, what if we put, “Select the amount” in paragraph tags, and use semantic buttons for the amounts instead? This can be a problem. For one, the buttons aren’t tied to the fake paragraph label at a programmatic level. This means they will show up out of context on an element list. A screen-reader user would hear the amounts, but not the label. While you could assume a user purchasing a gift card would conclude they’re selecting an amount for the gift card, the fact that these are buttons misinforms the user as to their functionality. 

As we mentioned, buttons are used to trigger something, so a screen-reader user wouldn’t have a clear idea of what selecting this option would do. Additionally, even if a developer programs a button group to only allow one option, the way a radio button group works, this information isn’t conveyed to a screen-reader user. So they aren’t being told that selecting one option will unselect another. When a user can’t visually see what is occurring on the screen, this could prove to be a confusing and counterintuitive experience. And we’ll discuss the importance of semantic labels a little bit later. 

So what else is important when selecting a gift card? What about the face? What it looks like? Let’s say a gift card has three face options. “Happy birthday,” “Congratulations,” and “Happy holidays.” All very different. And ideally, you’d get to pick which one you could use, right? But this is another field that could be accessible using input fields such as a radio button group with images, with proper alt text. But again, ignoring accessibility, what if we wrap the image options in div tags and use JavaScript to make them act like radio buttons? While this reinvention of the wheel may not be a problem for mouse users, this method makes selecting a card face impossible for any keyboard user, especially without the right attributes. Divs are not user-interface objects, which means they can’t be tabbed to, and do not show up as intractable in a screen-reader element list. They are entirely unselectable by a keyboard user, sighted or not. 

These are examples of bad-practice coding that can go unnoticed simply because they appear to work for an able-bodied user. Just like people, it’s how the inside was developed that counts. And unfortunately, these practices are actively being used by a few Gift card plugins available in the WordPress repo right now. A large variety of WooCommerce plugins involve adding, removing, or modifying user components. 

As implied, user interface or UI components are elements intended for user interaction. They are defined by four major categories: input controls, navigational components, information components, and containers. We will go into some specifics later on, but we’re going to touch on the broad spectrum, and how it applies to WooCommerce plugins. 

UI components must be usable. They are the backbone of any website. And unfortunately, plugins often create UI components that are either inaccessible by keyboard, wreak havoc on an otherwise clean interface, break Core WooCommerce components that were otherwise fine, or just generally create a poor user experience. 

For example, one of the issues I see relatively often are plugins that alter the display of product variations. By default, WooCommerce uses a dropdown selector for product variations, but it’s not uncommon for shop owners to want something a little snazier, such as thumbnails or color swatches. There are some plugins that can accomplish this excessively by using input controls. There’s plenty of them, just like Woo does. However, others, as we previously discussed, go rogue and use the div tags, which are not UI components, and JavaScript, to make them act like selectable options. Just like with our Gift cards example, this means keyboard users can’t select any variables. Whatever the default settings are will be the only variation of a product they would be able to buy without the use of a mouse. 

I see the same issue a lot with some coupon plugins. A lot of coupon plugins use the same method of non-UI components and JavaScript that allow users to get a discount when shopping. Well, at least mouse users. Keyboard users aren’t allowed to get 20% off a pair of khakis, apparently. Do you see why bad practice coding can be a problem? And in this particular case, maybe even a legal issues? Using the Accessibility Insights browser extension I mentioned earlier, by enabling accessible names, it will highlight elements on the screen and how they’re programmatically identified, meaning how a screen reader sees them. And if an element is missing a name, it doesn’t take a developer to know. It’s a good indication that inaccessible shenanigans are afoot. 

Any UI component implemented by a plugin should be checked, maybe double-checked, for bad practice code. As an asterisk, it is possible to make these more accessible with the use of attributes and extra layers of code, but that’s not what’s happening here. That’s not what I’m referring to. And there are so many elements in existence to accomplish these tasks natively, but there aren’t many good reasons to force non-UI components like a div to be something it’s not, especially at the expense of user experience. 

So just like my meme on screen here says, stop trying to make div plus JavaScript happen. Whether it’s a share on social-media button, quick views, variable alterations, coupons, or whatever awesome feature you want to add to your website, it’s crucial to ensure these are usable by everyone. 

Other popular additions to WooCommerce stores are filtering and sorting plugins. Especially if you have a large inventory and a huge variety of products, adding optimized filtering and sorting plugins can greatly enhance a user’s experience, make it easier to find the products they’re looking for more quickly. However, a lot of these plugins use methods that don’t always make the experience enjoyable for users of assistive technology. 

For example, you’ve probably been on a website before with a filter that refreshes the results on the same page. If it isn’t announced to a screen reader user that the results update automatically, they may not be aware something is happening. This can be extremely aggravating, and forces them to bounce around to find out if their action did anything at all on a page. 

By the way, I do want to take a moment to clear up a common misconception about users of assistive technology, and this helpless, lost, and confused trope. Well, yes, inaccessible websites can be an extremely confusing experience. When we use the word “confusing,” people less familiar with accessibility often associate this description with a scared child lost in a department store, which is an inaccurate stigma by how we think of people with disabilities on a broad scale. The feeling it invokes is something we can all relate to, and that’s being extremely frustrated by a shopping experience. When a store has counterintuitive organization, making it difficult to find what you’re looking for without assistance, it’s the equivalent of not labeling aisles, realizing an item was stocked in a place you would never look for it. Or not being able to access an aisle at all because an inconsiderate employee left a trolley or a pallet in front of it. These are all common aggravating occurrences I imagine most of us have had to deal with, and that users of assistive technology have to deal with, digitally, every day due to common inaccessible practices. 

You’ll definitely want to make sure your sorting and refreshes are keyboard accessible. You should be able to test most of these using a tab, enter, and arrow keys. Make sure keyboards have access to the same dropdowns and filter options mouse users do. If you’re using an advanced search plugin that automatically provides search results, make sure you test that those are keyboard accessible. I highly encourage you to activate your operating system screen reader while tabbing through these options. For an enlightening experience, try running some tests with your eyes closed. 

For example, if you have an advanced search plugin installed that automatically populates with recommended products, turn on your screen reader, click on the search box, and close your eyes, and start typing a product you know is in your store. Is the screen reader telling you what’s happening? Do you think someone who was blind or low vision would be aware of the automatically populating products? 

You can do a similar experiment with automatically updating filters. Highlight a filter-selection box and use your arrow keys slowly, enough time in between for items to refresh on the page, and [inaudible] what is happening on the page. Even if you’re not adept at using a screen reader or keyboard navigation, these little experiments can give you enough information to know whether or not someone who requires assistive technology would have a good user experience with these features. As long as someone could ultimately use these functions, these would be hurdles or even curves. But one of the goals of accessibility is to allow everyone to have the same experience and access to the same features on a site. So ideally, these features would be easily usable with little frustration to users who may have a disability, as they would be for an able-bodied mouse user. You want to ensure the experience is as universal and predictable as possible. 

We’ve got some more code on this page. We have two examples for a good-practice labeling, semantic labeling. And that is a label tied to an input via for an ID, with the proper attributes. The label itself is good for accessibility. And another one using a label-wrap method, where the label tags wrap around the input. “No’s” are just a label with no attributes connecting it to the input. And the other “no” option is no semantic label at all, but using p tags around the label, which is labeled bad for accessibility: fake label.

We’ve touched on semantic labels a few times. Let’s go into why that is so important. If a label isn’t programmatically associated with a field, it significantly limits the ability of visually impaired screen-reader users to successfully fill out a form with confidence. To a screen-reader user, an input field without a semantic label is a blank box. This requires them to jump around to locate nearby information. And this leaves room for error, especially for more complex forms. 

Input fields without label are the equivalent of being handed a bunch of spices and ingredients without their own labels, and then being expected to use them correctly, keeping your fingers crossed you do not mix up the salt and sugar. If you’re adding any sort of field manager plugin, make sure you check on their output. If the plugin developers have followed those standards, then these fields should be very accessible. However, there are a couple things that can make them inaccessible. 

Soren labels should be visible at all times. So if a developer has opted to hide them visually, maybe replacing them with a placeholder content inside the input box that is going to go away once the field is filled out, they could cause issues for those with cognitive disabilities once the placeholders disappear. And if they use a display-none method, this could make forms unusable for screen-reader users. This is also something you should keep an eye on when selecting a theme, as a theme developer, could hard-code hidden form fields. To reiterate, you’ll want to make sure the form fields are real labels that are programmatically associated with the field it’s labeling. 

An easy method to ensure a form’s labels are correctly connected to a field, simply click on the label; it’s associated fields should become active automatically. If you click on a form field label and it does not become active, this is pretty good indication of fake labels that could make it impossible for a screen-reader user to fill out the form in question efficiently, if at all. 

Here is that testing practice, just so you know what to look for. As you can see, I’m clicking on the label here and the field becomes highlighted. There’s a visual focus indicator. But when I click on the inaccessible field, nothing happens. It still has the capability of focus, but clicking on that field does nothing at all. 

From here, we’re going to discuss some more general site elements. These elements are used so broadly and have so many possibilities of utilization, it’s difficult to actually provide a specific list for every single one. So we’re going to touch on them and give you an idea of what to look out for. If you add a plugin that creates any sort of table, like a wish list, cart overhaul, size chart, so on, there are a few things you’ll want to keep an eye on. As you can see on the screenshot on the slide, we’re going to be looking at how the Core WooCart table functions to give you a baseline example. There is usually an X button to remove an item from the cart. And if you turn on Accessibility Insights, you’ll see that this X button is labeled “Remove item.” And you’ll want to tab to that button and press “enter” to make sure it still functions as intended. If there are additional links on a table or modals, you’ll want to check those, interact with them, and just generally make sure everything functions as it’s supposed to be, like increasing the quantities using the up and down arrow keys.

Secondly, you’ll want to make sure a non-core table has semantic table headings. Without headings, a screen-reader user won’t hear what the column’s information pertains to. If you’re uncomfortable in the Inspecto, you can download an accessibility browser extension like Wave. While automatic checkers can’t detect everything that could be inaccessible on a site, they can be great for semantic detection, and they’ll at least tell you if your table is missing a header. 

Modals and pop-ups are extremely common on E-commerce websites to assist in efficient shopping and padding your newsletter recipient list. However, they are among the most common hurdles we see. The testing for both modals and pop-ups are pretty much the same. Ensure its content is accessible via keyboard and tap-through, ensuring you can interact with everything. Most importantly, you’ll want to make sure it’s dismissible. Ideally, a “close” button is visible and not a heading, which is a common practice in pop-ups. Even better is when it can be dismissed using the “escape” key on a keyboard. 

The other important part of this is, the presence of a pop-up or a modal should be announced to a screen reader using the correct attributes. Otherwise, they may not be aware of its existence at all. A developer can help confirm attributes, but the best way is to test this using an actual screen reader and ensure those attributes are being used correctly. Or, alternatively, they aren’t being interfered with by another site feature. Ideally, the screen reader will announce its presence or the presence of a dialogue box, and have a label programmatically associated with it, explaining its purpose, like newsletter sign-up or a product quick view. The best way to test this would be to download the screen reader and ensure its presence is announced. 

To give you an idea of what to look out for, common uses of a pop-up, as referenced, are used for newsletter signups, and occur automatically when a user has been on the site or a page for a certain amount of time. If you plan on using one of these plugins, test it thoroughly. Modals are essentially user-trigger pop-ups. 

The most common example of a modal is a quick view often seen on product listings that pop up with more detailed information without actually redirecting a user to another page. Modals can be the result of many plugins, from cart enhancement, coupons, login themes, and there are many different ways to develop them. So you want to make sure any modal implemented by a plugin on your site is accessible. 

I find a lot of keyboard issues lie within cart modals. It’s not uncommon to have a cart button, which instead of taking you to another page, opens a quick view modal. These can be extremely problematic if not done correctly. I’ve seen some that don’t allow keyboard access into them at all. Especially if this is the only way to get to a physical cart or checkout page, keyboard accessibility is a must. If your keyboard testing reveals any sort of struggles or hurdles, you may want to consider another option. 

So what makes a properly-built plugin? There’s no one right answer. But as we’ve discussed, there are certainly quite a few wrong ones. To reiterate, if you’re adding onto an existing functionality, it’s wise to follow core coding practices, especially if they tend to use best-practice coding standards, as WooCommerce itself tends to follow. The add-on should function indistinguishably from the core, so it integrates seamlessly. And best-practice code is a must. There’s no reason to be forcing elements into a job they didn’t apply for, especially when they already have jobs to begin with. 

I know this has been a lot, and I’m sure there will be some questions in a bit, but for now, Bet has one more resource to share. 

>> BET: Thanks, Meg. As we’re wrapping up, we just want to make sure that folks know that for US business owners, there’s a tax credit available for making your website more accessible. The business has to be US-based, and has to have either under 30 employees or under a million dollars in gross revenue. But things like the entire cost of a website project when accessibility is included, or any remediations, or testing, or auditing that are done can be included. It’s a credit on a 50% up to $10,000, so up to $5,000 of credit. And that business has to pay that upfront, and then they can get their taxes reduced the next year. And this is a tax credit that can be claimed repeatedly. So it can be a great resource in terms of helping folks make their sites more accessible overall. 

Meg has covered a lot in this presentation, and we both know that you might feel overwhelmed, and you might not know where to start, and that’s normal. It happens to all of us. Just start. Start small. You’ll develop better habits and better practices for being more accessible over time. And after a while, all of this will become second nature. Progress over perfection is a saying within the accessibility community, and that’s our advice to you. Just start. Start making small progress, small steps, and stop worrying about being perfect. Just start.

Thanks for listening. 

We do have the time to stay on if there are questions. 

>> AMBER: There are some. So thank you so much. That was a fabulous presentation. I’m not going to give them quite in the order they came in, but let’s see. I think I’m going to start with maybe an easy one, but we’ll see. 

Dennis is asking: “How do you balance the need for descriptive alt text with the fact that product images are often used as links to the product? That would necessitate simply the name of the product.”

So like on an archive page, maybe the alt text needs to be different from on the product page. And I’m wondering if you have any thoughts about that.

>> BET: Go Meg. 

>> MEG: In WordPress, there are multiple ways to implement alt text. You can set a global alt text for an image from say the media library, but you can override that locally. So if you’re using it for images, you’ll want to have that global set. But then when you’re actually implementing the product images into the gallery or the single product images, you want to make sure to balance the description text with the alt text, and this can actually help you provide better information for all of your users, by describing universal information that everybody will want in the actual product description, which a lot of people aren’t doing because they depend on everything being visual; like even metal buttons versus plastic buttons on a shirt, you know. 

So it’ll help you balance the difference of doing that universal description in your actual product description, while actually providing descriptions in the alt text of things that you will depend on people to be aware of visually, and describe that in a manner to people who may not be visually aware of the product. If there are pocket on the shirt, you know, stuff like that goes unnoticed. It’s never mentioned in the description that there’s a breast pocket on a shirt. It’s not in the alt text. Somebody out there is not going to be aware that this pocket exists if they can’t see it themselves. And that’s the kind of stuff you want to balance. I know I went a little bit off topic in that. 

>> AMBER: No, I think that’s a good point. One of the things that I would push back a little bit on this question is, it sort of presupposes that the name of the product should be the alt text when it’s linked? And I don’t actually think I agree on that. Because if I think about when I go clothing shopping, half the time the clothes are, like, named… Let’s say we’re looking at dresses; they’re named, like, “The Sally dress,” “The Mary dress,” or something like that, right? But if I’m on an archive page as a sighted person, I can see, “Oh, this one is a long dress. This one is a short dress. This one is green, this one is blue.” And then I could choose to go to that single, to go add it to cart or read more about it. 

However, if I was on a screen reader and all I heard was, “Link, Sally dress, Link Mary dress,” how would I know that one was blue and short, and one was green and long, and then I even wanted to go to the product page? So I think even on an archive page, you don’t actually want to use the name of the product. You want to describe it. Would you agree? 

>> MEG: That’s a fantastic point, especially if you have those kinds of the Sally dress, stuff like that. I think you would be safer if your titles were more innocuous. Like, you know, “This is my generic green army dress with a collar called…” Like the way Amazon labels their products, where they shove them in every [inaudible]. That’s an example of when the title alt text could be adequate in a catalog. But no, what Amber’s saying is absolutely great. And these conversations are good ones to be happening, by putting yourself in the position of a screen reader user, thinking what is going to be the most helpful. 

For example, if we’re talking about clothes, that is a great example. If we’re talking about tools, which are going to probably be titled what you’re looking for, that may be an example of differences in alt text where you say, you know, “This is my three wrench set” in the alt text for the title, but then go into more details in the single product page. It’s just going to depend on what kind of shop you’re running, and what you yourself may be looking for, and how you want to convey that to another person. And that’s going to make the decision for you on what alt text you use in what places, if that makes sense.

>> AMBER: Yes, that totally does make sense. So this is definitely a curve ball question, but Jason asked, “How are accessibility experts and brands looking towards technologies like voice and conversational AI to help them optimize the user experience for all users?” 

Have you all looked into this or have you heard much about what E-commerce is doing on this front? 

>> MEG: Do you know that the NVIDIA A1000 is going for like $40,000? I have a whole thing on this. I’m not going to get into it. I can’t. I think it’s all fascinating. I’m coming in and out of it. I’m not the most well-versed on the accessibility-specific enhancements that people are creating. I am wary about anything that is automatic, because as any of us know, automatic checkers and AI fail. However, it’s getting smarter. 

Me, I welcome our AI overlords. I cannot wait for this future. But I encourage anybody to have a conversation with ChatGPT specifically about accessibility and talking through things. I think that… 

>> BET: This is already trying to, like, change the AI stuff around accessibility by having conversations with chat bots. 

>> MEG: It’s such a broad topic, that’s the thing. It’s such a broad topic. We can talk about small local things like ChatGPT, but there are big, huge things going on. That’s a broad topic, and I’m not well versed enough on all of it, but there are some really fascinating things going on there. And I would actually… 

>> BET: Somebody really tripped your geekometer on all of this. 

[crosstalk ] 

>> AMBER: I saw a talk. I want to say it was at AccessU, like two or three years ago. It was during COVID I think, because it was all virtual. It was, like, when I watched. So it might be on a Knowbility website or a Knowbility YouTube channel, if anyone wants to check that out. And nobility is K-N-O-W-B-I-L-I-T-Y. He was talking about, like, voice search and voice command, and how that can help from an accessibility standpoint, and he was advising that brands should go out and get your… I don’t remember what the actual term is… 

>> BET: Oh, “And claim your…” Yes… 

>> AMBER: … The, like, sound of your brain, typically? So that when somebody’s, like, “I want to get something from this company, the voice recognition, like Siri or any of those other ones, would know what your company was. It’s like your audio handle. There’s probably an actual term for this. 

>> BET: And the person who does that stuff, and he’s really early on in all of this in the WordPress community is, Chip Edwards [phonetic]. So if people are interested in looking at that, find Chip Edwards. He’s been talking about that at WordCamps since at least 2020, if not before. 

>> AMBER: Yes. I think there’s a whole nother thing, which is, you know, it’s hard not wanting to necessarily feed the corporate machine, but to some degree, perhaps having some of your products, if you’re an E-commerce business on Amazon, might be helpful from an accessibility standpoint. Maybe you don’t only sell on Amazon, like, you still have your website. But if somebody has an Alexa, it might be easier for them to say, “Hey, Alexa, order me three of these.” I don’t know. I don’t know if you all have thoughts on that. 

>> BET: Sometimes there are restrictions about the way you do that. Sometimes you can’t do both. 

>> MEG: I think that AI is coming a long way in all of its facets, from these giant broad things to local small tools. It’s coming a long way, but at the end of the day, at least right now… Maybe this will be different in five or 10 years, maybe next year, but we can’t take the human element out of it right now, especially during this demo process, which is, we’re in AI Future Alpha right now. It is fascinating and awesome and can do some amazing things, especially for people who can’t wrap their head around this. And as it fills in the gap, it could potentially make everything much more accessible. We’re not there right now, and we cannot take the human aspect out of it. It’s just a broader scale of what a lot of us talk about; the cautions with automatic testing, where it can be so great, it can help point you in the right direction, but it can’t detect everything. And people who don’t know what they’re looking at don’t know what they’re looking at, and that can make an issue worse. I think that we’re right there still with AI, but there’s a future there. 

>> BET: Do you think that there is a future at some point where the AI will be able to compensate enough for bad accessibility on a website, that it won’t have to be fixed at the website level? 

>> AMBER: So you mean like an overlay? 

>> BET: No, not like that, but that the AI would be able to help the person navigate through whatever they needed to do on the website, even if it wasn’t coded well. 

>> MEG: I think there’s a possibility for that personally, but that [crosstalk ] 

>> BET: I think it’s a long way off. 

>> MEG: Yes, exactly. That would be such a long way off. And I think that there are still people who don’t want to sacrifice form for function. That is just a fact. Do you know how many times… And I use this line because some… This specific line bothers me so much. And when I was a fledgling accessibility professional, I didn’t have the guts to stand up about this. But people who say accessibility doesn’t fit into their elegant design, I’d have a lot to say to them face to face if they said the same thing to me right now. But there is a potential accessibility fill for AI in cases like that of people who don’t want to sacrifice form for function. [mumbles] I haven’t had enough coffee today. It’s just there are going to be places where AI can fill the gaps of people who are either still ignorant, or refuse, or are well aware accessibility is a necessity, but still refuse to because they don’t want to sacrifice their elegance. And I think that there will be a time when AI is intelligent enough and human enough that… I know that scares… My partner is a Luddite, so it terrifies him when I talk about this stuff. But I think there is a time when AI is human enough to actually fill in some of those needs. I do think it’s a long way off. But at the end of the day, we’re also still going to have a lot of people behind websites, and people can be just awful.

>> BET: This will appeal to you. Somebody in the chat said, “Lipstick on a pig.” 

>> AMBER: Yes. Well, I think if we’re going to have more AI on that front, I would like to see… Not that websites have to implement AI, which is what the overlays do, right? 

>> MEG: Yes. 

>> AMBER: But it would be neat to see if screen readers actually used AI to better incorporate. So for example, if a screen reader could start to recognize if there’s a div with the word “previous” in it, “I bet this is a button.” Right? Because why else would you have a div with “previous” or “next” in it, you know? And, like, maybe being able to get smarter about the junkie code that it sees in the screen reader itself, rather than every website trying to have to implement AI to fix their junkie codes. 

>> BET: That’s what I was trying to ask earlier, right? Is there a way for the screen readers or even just OSs to get better at reading out things? 

>> AMBER: [crosstalk ] says Freedom Scientific is experimenting with that right now.

>> MEG: OK. So this is going to be a little bit of a journey. We’re going to go back to ChatGPT. Too many people use it to create code for them. That’s bad, because chat ChatGPT can be a great assets for coding, but not if you don’t know what you’re already doing. So anybody who’s trying to create their own functions probably shouldn’t use it that way. However, what you can do with it… And it’s just going to get better from here… What you can do with it is if something is… OK, so a big joke in the coding community is, the missing semicolon. The infamous missing semicolon, where is it? It’s breaking everything. Where is it? 

You can do things like grab a huge snippet of CSS, learn on ChatGPT and say, “Validate this” or “Find the missing semicolon,” and it will do that for you. You can do that with small snippets of jQuery; verify, validate, and it can point stuff out to you. You can also ask it to enhance it for better coding practices and stuff like that. Again, do this with caution, because it’s still learning, and if you don’t already know what you’re doing, you could make it worse. But I imagine things like that could come… And it will also provide you with the fixed version of it. So I imagine there is possibility with with AI and screen readers to actually automatically scan that page for poor practice code and almost fix it as it relays it back to the assistive-technology user. That is already actively working. And once it gets integrated seamlessly into software, and things are efficient, because this could be extremely heavy on hardware, I think that is entirely a possibility. That takes a lot [crosstalk ]. 

>> BET: Then the motivation for really making it originally accessible as opposed to just letting that screen reader take care of it is the performance for it. 

>> AMBER: Yes, because it would have a negative performance impact, I’m sure, just like any JavaScript overlay does. 

OK, so I think this is an interesting sort of transition. Jason said that he’s built a plugin that adds voice and speech recognition to WordPress and WooCommerce websites. So sort of like trying to do some of this stuff. Jason’s done some work to make it keyboard accessible, but he doesn’t know how to make it screen-reader accessible. Do you have any tips for this? 

>> MEG: Well, that’s a little bit of a loaded question without seeing the functionality of it. 

>> AMBER: Right. 

>> MEG: For example, how’s the activation? Screen readers will listen to stuff, like, if a button is played, you know, you’re playing a video and you can listen to it, and can stay relatively silent during that time. So I’m not sure what to suggest to you without seeing all of it, but if you want to make it screen-reader accessible, you need to make the controls accessible. Best practice is keeping the user in control. Nothing automatically occurring without the users’ consent.

So if you have these controls, making the plugin voice activated for this website, then you want to make sure those controls can be activated by a keyboard, for one, the buttons to activate it have the correct text that tells the screen reader what is going to happen. I’m very hesitant to give you detailed advice on this just simply without seeing how things are working. And [crosstalk ]

>> BET: How does something that’s doing something with voice then play or interact with the screen reader? Amber, do you have any idea how? 

>> AMBER: I think the best way is, you need to make sure you test it with NVIDIA and JAWS, because those are the two most commonly used on a computer, and then also voiceover. But if you only have a Mac computer and you only test with voiceover, you’re not going to get what the most common user experience is. So you definitely either need to set up Boot Camp or Parallels or something like that, or get a PC so that you can test with NVIDIA.

Also, I saw recently, BrowserStack added something, so you can also test with screen readers in BrowserStack. I haven’t played with it yet. Have you? 

>> BET: A little. A little. I’ve played with it a little. It’s a plugin, right? The other thing this person could do is he could get in the growing queue of people for you and Alex to do a testing live. Got to suck it up and be, like, brave and… Yes. 

>> AMBER: The biggest things that come to mind for me with a voice control is; one, how are people even aware that the website can do that? So potentially, you need like ARIA Live Regions or some sort of alerts to notify someone that it’s a possibility, if they can’t see or, you know, if there’s a banner message that shows it. Like you were talking about pop-ups, Meg, but they’re not announced to a screen reader. Then those people might not know. 

The other thing is I would test it with Dragon Speech. And I would probably find a user who uses Dragon Speech, which is a technology that helps them to do voice control, so someone who is maybe paraplegic or uses voice all the time. And I would make sure that your program doesn’t conflict with that. 

>> BET: Well, again, my question is, what’s being read out loud by the accessibility tool? And then what’s happening with voice on the site? 

>> MEG: It also comes down to predictability. You want to make sure that anybody interacting with it, able-bodied, having a disability of any severity or on the range, you want to make sure that they know what’s going to happen. So when you create a predictable environment, a lot of things start coming into play from there. I cannot stress enough: Stop assuming. Everybody when it comes to web development needs to stop assuming, “They’ll get it. They’ll understand.” “Oh, you can do this.” “They’ll figure it out.” “You know, people are smart. They’ll figure it out.” That’s not the discussion here. It’s making a predictable experience, and making sure users know what’s going to happen when you click A. You know, you click A, what is B? And they need to know what B is going to be. When you start considering those aspects of it, a lot of things start a domino effect when it comes to code.

OK, I made sure I did this. Is this OK? And it starts leading you down a path that optimizes your code, and creates a better experience for people. And you start seeking the answers to the questions on your own. So I would definitely start with that mindset, because I think you might be surprised with how many realizations come of it by just doing your best to drop assumptions and making it the most predictable experience you possibly can. 

>> BET: Well, the other piece of this is, we’re still in early days of this, right? And so I think it’s going to have to be that it develops a little bit. But then people who depend on screen readers will have to tell us, do they want the screen reader to read things? Or do they want this voice activated thing to read things to them? They will need to tell us what is going to be the better experience for them. 

>> AMBER: It looks like Jason posted a link in the chat. If anyone feels like checking it out, post meetup, it’s, “speak to the number two web dot com.” So there’s a demo on there. So it might be interesting. And, Jason, you can also post in the Facebook group.

>> BET: Awesome. We’ve kind of gotten away from WooCommerce. 

>> AMBER: Yes, yes, a little off. I don’t know if this was a follow-up question based on something you said. I’m going to be totally honest, I don’t understand it, but maybe you do, so I’m going to ask it. Jean [phonetic] asked: “Would you please discuss the custom short code issue for accessibility?”

Do you know what that’s referencing? 

>> MEG: Oh, it’s because I have a list of hot potential custom features. I apologize for not being clear. What I was trying to provide there is an example list of common features that come with custom WooCommerce sites. And I apologize if I’m concluding the wrong thing or making an assumption. 

Short codes aren’t natively inaccessible, especially because they describe something on the front-end. But if a developer says, “Here are these custom short codes that are great,” and then they have all the codes that makes it function. If that code is not accessible in implementing these custom short codes, output and accessible content, that’s where it becomes a problem. It’s not inherently inaccessible as long as the code that it’s outputting is accessible. So it’s more of examples of features to make you think about what’s running on your theme. Like, “Oh, my theme came with these custom shopping short codes.” That’s where you start to check. 

Like I said earlier, a lot of these general themes, it’s standard testing. But when they come with something special, something unique outside the box, that’s where you start with your testing. And that’s often a short code, a slider, a carousel, or custom menus. 

Check your menus, people. They are literally how people get around your shop. And if they aren’t accessible, people just get [crosstalk ]… And don’t get me started on a hamburger desktop menu. I just don’t think we’re there yet, but I think I have another webinar about that. 

>> BET: Meg has opinions. 

>> MEG: I do. 

>> AMBER: Opinions are good. Opinions are good. 

>> MEG: The implication was just to start with the custom feature that your WooCommerce theme comes with that makes it special. Because there’s a possibility that if it has accessibility issues, they’re going to lie in those custom features that… Developers are so wonderful and they have so many great ideas and they get excited, and they’re, like, “This is going to be great. This is going to make the experience so great. People who own shops are going to love it.” And if those features are too outside the box, or… Well, there’s no such thing as too outside the box, but if the coding is [calmly] too outside the box, and uses bad practice, then these features become your most critical downfall. So start with those features, because the developer was probably really excited about them, and may or may not have used best practice. 

>> AMBER: So I’m going to put you both on the spot a little bit here, because you mentioned that you originally thought you might just show up with, “Here’s a list of good plugins, and here’s a list of bad plugins.” 

>> BET: No. We decided we wouldn’t go there. 

>> AMBER: I have thoughts on this, but I’m curious. With what you’ve seen in WooCommerce, do you think the vast majority of them are actually just all on the bad list? [laughs] 

>> BET: Oh, I thought you were going to ask us about specific ones. And we just agreed to… 

>> AMBER: OK. No, you can give us… If there is one that is really good, like, shout it out. Like, that’s awesome. I love to shout out plugins that are doing a good job. Because in our experience with doing audits, I feel like almost all of them are not good, or need at least some amount of remediation. Some are, like, “Throw it away.” [crosstalk ]. 

>> BET: Before Meg replies on this, let me just sort of offer a suggestion about how we can be better advocates. One is, as advocates, we can be pushing WooCommerce to do a better job about whether things are labeled accessibility, or accessible or not. And that WooCommerce ought to be, if they’re selling the plugin on their site, making sure that plugin at least has the option to fairly easily do output that is accessible. So there are ways that we can push at that a little bit on the Woo site too. 

>> MEG: So I want to add a disclaimer here: we are not referring to back-end editor functionality. That’s a whole other can of worms, and I know a lot of us have opinions about it. So we are disengaging with that part of the conversation altogether. 

Here’s another opinion that I have. 

>> BET: [chuckles] Oh, no 

>> MEG: For whiskey drinkers out there, Jack Daniels is swill. That, maybe once upon a time was good, but now they depend on their brand to get away with anything, to get away with this garbage. I think a lot of WooCommerce plugins do the same thing, where they got in there early in the game, and people only download them because they are recommended by word of mouth, or by the downloads amount on a repo. And… 

>> BET: Or they’re sponsorships of things.

>> MEG: And then they stop putting in the effort, because they think people are going to just download it anyway. So I think especially the big, popular plugins have a lot of issues on the front-end. And it’s more terrifying when you know how inaccessible they are, and you see 200,000-plus downloads, and you know they’re out there, like predator. I think the big names need to be held the most accountable, because if they are getting passed around, word of mouth, they need to be the… 

I’m not kidding, you guys. That coupon plugin, if you are only offering a coupon to people who use a mouse, and excluding any sort of discounts to somebody who’s coming to the site by alternative methods, that’s a discrimination issue. That is an active discrimination issue. And when people aren’t making sure that their plugins are usable, and then passing them off to other people, this is dangerous and awful. 

>> BET: Maybe this is a question for another time, but is a good strategy, in terms of being good advocates, to… I mean, we’ve had issues. I saw recently, Amber, you posted fairly publicly on a plugin not a newcomers plugin, but a different plugin, an accessibility issue in their support forum. 

>> AMBER: And then I tweeted about it, because that’s how I get people to respond fast. 

>> BET: And she tweeted about it… Exactly. We had an issue with that same plugin that we repeatedly sent them the fixes for 18 months before and got crickets. So do we think that’s a good strategy? I mean, I don’t want to shame people into doing stuff, but some of these people… I mean… [laughs] 

>> AMBER: Yes, I think social media can be really helpful on that front. I will say on the coupon pop-ups, if you need to do pop-ups on your website, don’t pick a WooCommerce specific one. Pop-up Maker does a really good job with their accessibility. It’s not a WooCommerce-specific plugin, but you can use it on your WooCommerce site. Is it 100% perfect? No, but it is really, really close. We use it without qualms on websites all the time. 

>> BET: So back to the question, Meg, do you have, like, one WooCommerce plugin that you thought was good? 

>> MEG: I did quite a bit of testing. OK, so when you’re doing an audit, you are experiencing a life environment of a variety of plugins stacked on top of each other, doing different things. As Amber I’m sure could verify, loads and loads of accessibility issues on WooCommerce are being caused by these plugins. And you get a good idea, because if you look at the code, you start recognizing the classes that are often associated. So you get an idea of what’s going on here. 

When I was specifically testing these, what I wanted to do was actually get an idea. So I had WooCommerce installed, and no other plugins except for the one I’m… I have my dev environment with WooCommerce and like 80 plugins deactivated on it. Probably not that many; probably like 30, I don’t know, a lot of them. I would say the safest ones… And this is not a grand association, because once I say this, there’s going to be one out there that tricks somebody, but most of the field manager plugins have done a good job on front-end accessibility. 

I mentioned seamless integration into this. And when I say that, I mean, personally, if you were creating an add-on for an existing functionality, that add-on should seem like it’s practically a part of Core, and by making those fields act the same as the WooCommerce does by making sure those fields are tied and creating that experience. I would say that a lot of the big field manager plugins are relatively safe for front-end accessibility. 

I don’t like to endorse specific plugins, honestly. Maybe it’s that feeling of, once you make a claim, it’s good. 

>> BET: We had an experience of kind of endorsing a plugin because we really liked their accessibility, and then the next iteration came out and they totally undid a lot of their accessibility. 

>> MEG: See, that’s the thing. Once we tell you it’s good, they’re going to blow it up. You know? 

>> AMBER: I want to say something like you were saying about being, like, it extends. So Yikes has a plugin that allows you to create custom tabs, and it just hooks into what WooCommerce does, and it doesn’t do anything different. And so that’s an example. I don’t remember what that plugin is called, but if you search like, “Yikes custom WooCommerce tabs” or something like that, it’ll come up. It’s a free plugin. And that’s one that I haven’t noticed it ever causing any accessibility problems. And it does some very useful thing that a lot of WooCommerce sites might want; custom tabs in their section. And because it relies on what WooCommerce is doing, it adopts that. 

I also saw in the chat that Angela said, like, shipping tax, basic functionality plugins in her experience are usually OK. She says any plugin that does “fancy stuff” that changes the display of the archives or product pages, cart, checkout, is what she tends to be more wary of. 

>> BET: OK. So here’s the thing. It is, the more you want it, the less effort they have to put into it. That is the key thinking about… If it’s “boring” functionality, like managing plugins or just little tiny features and unlike, “We heard these have been effectively created.” It’s a weird dynamic, but the more you want something, the less effort they have to put into it. It’s no different than lowering the quality of a pair of jeans that’s flying off the shelves. 

So if it’s something sparkly, or they’re promising you… Be suspicious of people, especially people who tell you “they’re 100%” of anything. I referenced this in one of my slides: there is accessibility snake oil out there. And people make promises they simply can’t hold up to, especially since there’s a lot of fear mongering going on. 

Also, when accessibility started getting more publicized, suddenly everybody was an accessibility specialist, and I cannot tell you how many [inaudible] an automatic review using Axe or Lighthouse. And then they sent the results, and some of those were even false positives. False positives are a thing, and you don’t know that without manual testing. 

I’m getting off track. 

>> AMBER: So we only have just a couple of minutes with our captioner and then we got to wrap up, but I think that where you’re going with this is maybe a decent, like, final question. 

Rohe [phonetic] was wondering if we could talk about how much accessibility testing can be automated versus manual. And I’ll say, too, on what you’re saying about the not 100%. Like in our plugin, we have this whole little warning, like, “Just because it says 100% pass test…” We never say “accessible.” We had this whole discussion, we were, like, “We’re not going to say that it’s [inaudible] accessible. And we’ve had people who were talking and be, like, “Why isn’t it 100% accessible?” And I’m, like, “Because it’s not?” [chuckles] Right? But I don’t know if we want to continue on where you’re going, and just in like maybe two minutes, talk about that balance between manual and accessible, and how like testing… So if people are trying to test their WooCommerce site, where is that balance? And what can they trust automated? And what needs to be manual? 

>> MEG: OK, so a lot of stuff. The fact is if you’re involving yourself with accessibility, you or either somebody you trust needs to know what they’re doing. Automatic scanners have the capability of false positives, and they don’t know some stuff. 

I will give you an example. If text is on a background image or a gradient, most automatic scanners can’t detect that, and you don’t get any of that information. Automatic scanners, I would say, and this is also unfortunate, are the best for markup. They can detect this kind of stuff: “It’s missing an attribute.” “It’s misusing an attribute.” But again, these also have the possibility of being a false positive. 

Whenever we do audits, we do depend on an automatic scanner, and we check those results manually, that is jumping off point, for everything else that still needs to be done as a human. 

Here’s an idea, as you start getting more familiar with that stuff. If you have a question about a result, run it through ChatGPT, unless you’re a part of a community in which you can also talk to people in the community. But again, take everything with a grain of salt. And if you get involved with an accessibility agency, make chat credentials, caveat, and tour. There are people out there preying on people who want accessibility. 

Getting back to the automatic scanners, you can do a lot with it. They are a fantastic resource. My favorite is Axe, but there’s also Wave, which we’ll visually show you. Sometimes Wave, as a browser extension, can be a little bit overwhelming for people. And I encourage, if you’re using a shop, to use the browser extension, because if you’re using the Wave browser tool, you can’t test for things like add to cart. Carts will always be empty because of the way it functions. But if you download the browser tool, the browser extension, you can actually run it in an active environment, where you’re adding things to the shop and doing all that stuff. 

Automatic tools will just tell you information, but it won’t always tell you clearly what it means, or what you’re supposed to do with it, especially if there is a false positive, which are out there, or if it is unconcludable information, like text on an image, or a gradient that they just can’t manage. 

>> BET: The automatic tools are great. And sometimes you’ll get a thing and it’ll have like, you know, 50 issues or whatever, and that’s not going to help you… The other thing you need to start thinking about is the functionality and the prioritization of what you’re working on. 

If a person who is not able to see the screen can’t get through your checkout process because they can’t figure out your form, that’s the place to start, right? Or if they can’t navigate your menu, because it’s not keyboard navigable, right? You’ve got to start in those big places where there are the walls, as opposed to curbs and hurdles, right? So start with your walls and move, ever improving. But start with those roadblocks. 

>> MEG: It’s also great for detecting alt text. That’s a great go-to, because it’s all about that quick view. That’s great. So if you have a giant page with a million images on it, instead of checking every single one individually, you run the scanner and it points out and highlights which ones are missing alt text, and you know what you need to address. So it’s an assistant, but it’s not a boss. And so utilizing it can be a great tool, but it can’t be 100% dependent on. It can’t replace human testing, and it’s going to provide you with information that needs somebody who knows what they’re doing to look at.

>> BET: It needs context.

>> MEG: Yes.

>> AMBER: Well, thank you. This has been a phenomenal presentation. And I love the discussion afterwards. It’s always really fun to hear from both of you. So thank you so much. And thanks to everyone who stuck around. We’ll have a recording and notes with all of the links available in about a week or two. 

Don’t forget to register for WordPress Accessibility Day, if you have not. It is free, and it’s coming up at the end of this month. 24 hours of really phenomenal talks from a great audience of speakers, or group of speakers from around the world. 

So thanks, everyone. 

>> 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.