Democratizing Accessibility: WordCamp US Showcase

Amber: Thank you so much. I am Amber Hinds. If you are interested in tweeting or X ing, I don’t know if that’s a word now at us, Our handles are, I’m HeyAmberHinds, which is spelled H-I-N-D-S, and Steve is @SteveJonesDev . So if you take any pictures and you wanna do that, we very much appreciate it.

And our company is @EqualizeDigital. Just sharing this in case you cannot see the slides. If you want to access the slides or a plain text version of the content on our website, you can go to equalizedigital.com/wcus-showcase. That will give you the slides, which you can either access via a Google embed.

You can link over to them, or you can just access the content right there on the page. So I want to start by giving you a little background on why we built our Accessibility Checker plugin. We have been working together as a team since early 2017, and primarily we were doing a lot of marketing website builds.

We started working with universities and government and got into accessibility and having to build more accessible websites for those clients. And what we found was that the tools that existed out there either didn’t meet our needs or our clients needs or they were so prohibitively expensive that when we tried to introduce accessibility to smaller businesses that we were building websites for that had smaller annual marketing budgets, they were just like, no way, I can’t do that.

So really this plugin started as us trying to, quote, scratch our own itch. We needed a solution that would help us solve some of the things we weren’t seeing. So there are browser extensions like WAVE or Axe. These are really great tools. for scanning one page at a time. They don’t crawl out the entire website and find problems that might exist on some blog posts from five years ago.

They also don’t store a history. It’s you get the status right now. You can’t see how is that improved or changed. There are SaaS solutions which do crawl the whole website. These options typically charge per page, per scan, per URL. And I’m talking, we as an agency paid for one of these solutions, and we had the right to use it on two websites at a time, and we were paying over $5,000 a year.

And we have university clients that were paying for these solutions, and trying to figure out how to divide it among their hundreds of websites from different departments across campus, and they were paying upwards of $100,000 a year. And these solutions, you really can’t translate that to a small business.

We were looking for something that was more affordable, but also the other problem with the external solutions for WordPress is that they really require what we call retroactive remediation. A content author creates content, they publish it, The external scanner is set up to, let’s say, every Wednesday, go crawl the website, discover all the new URLs, scan them, generate a report.

You either have to log into that dashboard, or you have to go look for an email that comes to you that says, hey, there’s problems on this page. That then means someone has to go back and fix it. And so what we’re really looking for is something that will proactively warn people before they hit publish.

Just like an SEO plugin, gives you guidance on that. So that’s what we were thinking about. And then the other thing that we learned as we were using some of these tools is that they don’t know WordPress. And while some of them have very great rule sets, they don’t, they sometimes miss things, or on the other hand, they flag false positives, which we’ll talk a little bit more about that.

And so we really were like, we need something that has the best rule set for WordPress. And that’s what motivated us to build Accessibility Checker. What I’m gonna do now is actually jump over and do a quick demo of Accessibility Checker so you can see it yourself. On the slide URL, you can fill out a form and it will spin up an InstaWP site and you can play with this exact same demo yourself.

You can also get this if you go to equalizedigital.com/demo. It’s always fun to do live demos. So what we’re going to look at is a fake e-commerce store. It looks like a a shoe store. It’s called Basic Fit. And I’m going to scroll down the homepage to give you a feel of how this is.

So we’ve got an unbelievable speed and comfort section that’s got four WooCommerce products on it. Different tennis shoes, the images, the names of the shoes, the sizes that are available, which are Buttons, ostensibly. And we’ve got a carousel that animates and changes the shoe that is visible without a pause button.

I’ll note that’s a no. And a button to learn more about our AirPro X3 TurboCharger. You see an average looking e commerce store. And now, if I flip over to the editor, This is built in the block editor, the specific demo. Down below where the content is added, there is a meta box for Accessibility Checker.

And what we have in the main summary is a percentage of past tests. This particular site has 73 percent past tests. I can see that there are 21 errors, 8 contrast errors, 17 warnings. Zero Ignored Items, and my page has a reading level of 10th grade, and we’ve not put any sort of simplified summary for this, which would be a AAA guideline if we wanted to meet readability guidelines at the AAA level.

There is a tab for details, and if I click over to it, I can now see a list of all of the issues that have been flagged, and they’re in accordions and then I can. And I can expand them to get more information about specific ones. So I can look, for example, at four linked image with empty alternative text.

When I expand this, I can see the impacted code. The specific image that it is, um, and I have a couple of different actions and options. How this sounds to a screen reader user, there’s actually a lot of hidden headings here. We reference the ID, and so a screen reader user doesn’t actually get the same layout, but they’re able to use the headings that are associated with the IDs of the issues, and then it connects things like view on page.

There’s actually Additional information, so it doesn’t say view on page for each one of these, it says view, issue ID, blah, blah, blah on page, so it has more meaning for a screen reader user. And Steve will talk a little bit more about what we’ve done to make our own plugin accessible. But basically, so you can go through, you can see what all of the issues are.

Then we could just look at this one, for example, Ambiguous Anchor Text, there’s Learn More, there’s an arrow, let’s say I didn’t actually know where this was on my page, if I click View on Page, then it’s going to open on the front end, and it will jump me down to that section, it puts a dashed pink box around it with an error button, tells me this is the ambiguous anchor text.

Anchor text and where it is, which might help me. A lot of our content creators like this front end view. You can actually jump through the page. So I’ve gone forward. I’m seeing there’s something with ARIA hidden on it. There’s something here that probably fails color contrast as well. So we can move through all of the different issues on the front as well.

Here’s the shoes missing the alternative text, which is linked. So it’s also an empty link. So that’s another view. And then let’s say I go and fix this. So I’m going to change my learn more, and it’s not just going to say learn more, and now I’m going to have to, we’re just going to put about the shoes.

And to save our page, so it scans the page on any sort of save action. Save draft, publish or update. Used to say update. We’ve got a WordPress thing now. It just says save on that button, but it used to read update. So notice any sort of save post triggers it to re scan. I’m actually now at 75 percent past test because I only had one problem now, so I’m 100 percent past on ambiguous anchor links.

And if I go over to the details, you’ll see that Error is no longer present. In our free plugin, this is pretty much how you engage with the plugin. On a post by post basis, you can work and edit there. We don’t limit the rules. We don’t limit the scans. None of those things. In our pro plugin, we have the ability to run a full site scan.

For example, if I was going to run a full accessibility check, it is telling me it would check 13 posts, 13 pages, 8 products, 4 press releases, which is a different. I will note, if you’re interested in seeing how it works with Classic Editor, the Press Releases post type is a Classic Editor post type, so you can see how it works in there if you go play around with the demo.

And then you also get some high level counts as well. So on our main welcome screen, I can see how many errors there are for the entire site. It happens to be 139 unique errors, 68 unique color contrast errors, 60 warnings, 59 percent overall. And then we have this really handy view called Open Issues, which allows us to then drill down on those specific issues.

So I could see things like If I wanted to look at incorrect heading order, I can go over, there’s 59 incorrect heading orders, there’s a section here that says, explains what this means, links over to documentation, then I can find each page, so for example, on the About page, there’s an H4, that probably shouldn’t be an H4, I can jump over to that we also have an Ignore feature, Which is both on this and on the free plugin in the post.

If you go in and you test something and you confirm, Hey, no, actually this was right. I’ve confirmed it’s accessible. You can then save that and it will remove it from the reports. And then as an add on, we have our audit history add on, which is part of our small business and above. And this allows people to track the history.

So at the top, we have an accessible graph. It visually looks like a graph. It sounds like a table to a screen reader user. That gives us total issues versus past tests over time and tracks that on a daily basis. You can actually choose whatever date range, last 3 months, last 6 months, last 12 months this year, or set custom date ranges.

And this will control both the graph and the progress chart below which has those counts and numbers and shows you what your change has been. This website got worse as we built it, and then got a little better when I fixed some things before I came up here to show you it. Ideally, you don’t want to see a bunch of this getting worse, right?

We want to see the other direction, but. So that is a high level overview of what the plugin looks like. I do encourage you to go to equalizedigital. com slash demo and spin up the demo on InstaWP and play with that and experience it more. Just highlighting as a quick recap, the free versus pro, what exists there?

Excuse me. So again, on free we have all accessibility checks. A big thing for us is we really wanted to make it affordable and usable.

Any website at all can make their website accessible to everyone. So you can do post and pages, unlimited scanning. You have that front end view. You have the in post view, and there’s no limitation on the rules. And then where our division on pro is that we do introduce custom post types only in pro the full site scanning, full site reports.

Ignore Logging, so being able to track when your users ignore things who’s ignoring things, so you can maybe go back and be like, Hey, you shouldn’t have ignored that. And Audit History and some other things that Steve will talk about. And I’m going to hand over to him to talk more about how we took this idea and turned it into an MVP.

Steve: All right. Thanks, Amber. So I want to take a little bit of a dive into the code, into the technical side of the plugin and a little bit of the history of where it started. And how we got to where we are. So we first came up with the idea, of course, sparked from client needs and from our own internal needs.

So we took that concept and we put together a proof of concept. So 2019, 2020 COVID hit, agency world got hit pretty hard too, as well. So we took that time to build a product. The bulk of the work was done during the lockdown. And it. It gave us an escape from just sitting there wondering when work was going to come back to being proactive and building something that was going to be beneficial for the whole web.

We evaluated existing tools to see what was out there. We identified the gaps in the market to see what we could do that would make our plugin unique and not just unique, but unique to WordPress. So we initially built a prototype. We, We started scraping HTML, so we’re trying to make something that traditionally runs as a Sass and in an isolated environment where you can control all the variables.

We now need to bring this into WordPress where we can’t control very many variables at all. We started with scraping the HTML and displaying the results in the admin screen as Amber just showed you. We refined the rules collaboratively for accuracy and creating the rules, not just as general accessibility rules, but as rules that were specific to WordPress.

So it wasn’t enough to just come up with these rules and write the code and just show you guys a bunch of errors and warnings on your page, right? We needed to come along with you and educate as well. So comprehensive documentation was paramount to releasing a product that would work. And you noticed in the screens that Amber showed, there was a little icon.

Anytime you are looking at a rule where you can click on it and you can get a brief description of the issue at hand. Or you can click through and we’ll tell you why it’s that way and what you can do to fix it. So it was definitely paramount to have an educational component to that too.

So we launched with a freemium model but our free plugin is very full featured in our effort to democratize accessibility, we wanted to be able to give a free tool to the WordPress community that without any costs, you could scan our whole rule set. So free and pro same rule set, no blockers there.

So the MVP launched at the end of 2020. And since the launch, we continue to redefine that rule set over and over. It’s not done. It’s never done. We get feedback from you users and we get feedback from us internally using it ourselves. And we are constantly refining those rules. So some technical considerations.

So to get a little bit more into the nerdy side, which is where I love to be, There’s a lot to consider when you’re running something like this inside of WordPress, right? You have to be very mindful. We don’t know what type of hosting company this website’s running on. It could be running on enterprise hosting on WordPress VIP, or it could be running on some 2 bargain basement hosting.

And we want the plugin to be able to work in both cases. So we had to take a lot of considerations into caching efficient queries. To optimizing databases using, utilizing indexes determining what kind of common queries we make with those databases. It requires specific PHP extensions.

Not every host has the same extensions enabled when you roll up a website. So we were getting support questions from time to time that we can’t scrape the HTML off the page because a certain extension is not enabled. So we’ve had to do a lot of documentation around that, especially on the support side and unconventional SSL configurations.

Believe it or not not all SSL seems to be created equal on every host. So there’s a lot that we have to do to mitigate that and provide filters to test certain things for every environment. So JavaScript execution, which I’ll get into in a little bit more technically later is unique inside of our plugin.

Because again, we’re trying to do something a bit unique, a bit unorthodox when it comes to development inside of WordPress. But there’s a lot of things that we have to consider where we’re actually injecting the JavaScript app into an isolated environment, running our scan, passing the information back through the REST API.

So there’s a lot of cross origin consider, considerations to look out for browser memory just having the page open, running a scan can build up a lot of browser memory. So we have to do a lot to mitigate timeouts. And then and to make for an optimal performance. So if the memory builds up we either have to kill the query or we have to refresh the page to keep the scan going.

So we chose to go with the custom data database for this plugin opposed to using custom post types to store this data and at scale, that was a very good move because we have seen clients use this and we have seen a million records, over a million records in a database, in our database table for the plugin.

So being able to index certain queries is definitely paramount for scalability. So some of the notable packages that we’ve used in the plugin is we used the WooCommerce Action Scheduler. We needed a way to reliably run a scan on a website, not pushing it to an API, running it safely over here and then pushing the information back.

Running it inside of WordPress and a cron jobs, as a lot of developers know, are not always reliable and depending on the host, sometimes cron is disabled or there’s a cron alternative. So we decided to go with the WooCommerce Action Scheduler and this allows us to orderly push through page scans in an orderly fashion and validate whether or not they passed or they didn’t pass and then move on.

For our HTML scraping, we the plugin was built five years ago and we started with this PHP simple DOM, simple HTML DOM parser package. And we started with the Dave Child text statistics package. So one is used to scrape HTML and the other is used to evaluate the reading grade level. Now, both of these products at that time were actively in development, but they have since become inactive.

We have taken those under our own umbrella, forked them, and we are now maintaining those for security with the plan to deprecate those here in the near future. And finally, which I’ll touch on a little bit more here in a minute, is the Deque Axe Core library API for scanning for accessibility.

So finally, the technical, last technical consideration here is accessibility standards. It wasn’t enough for us to just build a plugin that can scan for accessibility, but our plugin needs to be accessible itself because. We have users of all types of abilities and user testers that we hire out with all types of abilities, and we want them to be able to use, utilize our plugin as well.

Accessibility in a plugin is a must to be accessible itself. We tested it with VoiceOver, NVDA, and JAWS. And we tested it with many blind users.

Creating the best ruleset for WordPress. Our initial rules were PHP. As I explained, we scrape the page and then we evaluate it. The pros in that is that it’s fast. It’s extremely fast. And it can, we can do it in the background. We don’t need you to be logged in. We don’t need the page to be open for you to run a scan.

The cons are accuracy. So five years ago CSS didn’t really utilize variables that widely, or it was just coming into, to use. And so we were actually parsing CSS and we were parsing HTML to be able to evaluate them for accessibility. With the with CSS variables coming in the instantiation between variables became, the algorithm became very large and that’s when We realized that we need a solution to this.

We need something that’s more accurate. We need a rendered page to evaluate. So the major technical challenge here is how do we keep the scanning on the server with zero costs to free users while having the most accurate results? So our solution was to create an isolated environment when the page is open, inject our scanning.

JavaScript application into that environment, run all of our scans and pass the results back through the API for storing and for presentation to the end user. So unlike a SaaS where you connect to an API and it pushes your, scrapes your page, and it does it all in this perfect environment and brings the information back, we had to do this inside of WordPress.

And this is a bit of an unorthodox methodology in doing a scan on a page like this, but it does ensure that we have accurate results, that your color contrasts come back and they’re not false positives. So at the same time, we decided to utilize the Axe Core library. We’re going to bring Axe Core in and couple it with our current rulesets.

Axe Core promises 57 percent of WCAG issues can be identified through a programmatic API. So we didn’t just take axe-core at its word and install it, turn everything on and flood the end user with all kinds of accessibility issues and say look, we found 75 accessibility issues just because we can. No, we extended it.

We brought it, we’re bringing it in one rule at a time. And of course we start with the ones that are, that need CSS or in JavaScript evaluation the most. So we extended Axe Core rules to mitigate false positives. Even in our own testing of Axe Core, we identified this doesn’t really seem to be working.

100 percent accurate to what we think it should be as accessibility professionals. Axe Core does provide a great way to extend their rule set. So we would take a rule and we would write an extension to one. We would also combine the Axe Core rules. We want to create the information we want to present the information to the end user with as little noise as possible.

We don’t want to scare the end user away. Say, Oh, I’ve got. 250 errors on this page. I don’t know what to do, right? We want to try to present it to you in a way that you feel like you can take action on it. So we would take multiple axe core rules and we would combine those into one of our rules.

So examples of rule improvements that are only for WordPress. So we don’t flag ARIA hidden warnings on the core spacer block. Possible headings and quotes, anything in the admin bar. And utility plugins, such as Query Monitor. So there’s certain utility plugins that will print out UI on the front end of the website.

We don’t want to scan Query Monitor’s output of all the issues on the page or non issues on the page and store those. Cause that just adds confusion. And a logged out user is not going to see that. Now, if you’re creating some sort of SaaS or you have users that are logged in and you are using plugins that do put stuff on the front end page, that maybe that’s a consideration that you look at.

Or even if the admin bar is enabled for logged in users. You want to make sure that whatever’s being put through that admin bar is accessible. So we run specific checks on the content instead of the entire page, such as our readability scan. To reduce confusion there, we don’t want to scan your header and footer and then evaluate it for a readability score.

We just want what’s going through the body there and then missing sub, missing subheadings, um, and rules look for specific WordPress plugins in contrast to SAS that is, is a generic rule set. So we’ve taken lots of effort to make sure that. These rules are catered towards WordPress. So we’re looking for specific slider plugins.

We’re looking for specific maintenance mode plugins. So maintenance mode plugins can have a tendency to block our scanning. So we’ll write a module to be able to bypass that maintenance mode so that our scan will still run.

Amber: So we built it and we launched it and it was going great. We had some of our clients using it as well as some other agencies and some small businesses. And then in, towards the end of 2022, JJ Toothman from Lone Rock Point reached out to us. They were the lead developers on the new NASA.Gov website.

And he says to me, Accessibility Checker was one of the major differentiators behind NASA selecting WordPress over other CMS platforms that they evaluated. Yes! Very cool, right? They’re like, NASA’s using WordPress? You can’t tell anyone. It’s a secret. This isn’t public. And that they are going to use your plugin.

And I’m like, this is great! I’m the marketing person, right? This is so awesome. Our plugin is going somewhere. And I go to Steve and I’m like, Hey, this is awesome. And it was really exciting, but it did require some growth. So let’s talk a little bit about if you have a plugin, what does it mean to go enterprise?

Steve: To say that I didn’t have my Houston we have a problem moment would be a lie. But no, this was definitely a little bit of a wake up call. It was great to be selected by NASA for this and it was a huge opportunity. And I wouldn’t pass it up for anything, but at the same time, it did highlight that, okay, this is a great MVP, but now it’s time to go enterprise.

Now it’s time to take Accessibility Checker to the next level. So what did we do to get there? We made our plugin WordPress VIP compliant. The WP VIP team was great to work with. I got on the phone with the engineers there. We worked together to say, Hey, what can we do to make sure that this plugin can run and it can run at scale?

And and they were great partners in the NASA project. We leveled up our development workflow. So no longer is it enough to just willy nilly create features and let’s do it live and let’s go. But we had to really come up with a mature development workflow. So we refactored most of the plugin, the object oriented programming principles.

We fully adopted the WordPress coding standards. No longer, yeah we’re look at the coding standards. If we can’t, no, it can’t even make it into the code base anymore unless it passes and we implemented PHP unit security and integrated testing into our workflow. We removed insecure packages and libraries to strengthen security.

WordPress developers, just be careful what you bring under your umbrella because you’re then responsible for it. And anybody that looks at it, evaluates it for use such as NASA, or Automattic or investors are going to question packages that you utilize in that. We, we optimized the database and queries to hand over 1 million records and handle them efficiently, which was a very big achievement for us.

Refactored scan, scanning algorithms for up to seven times faster scans. So our full site scan, like I said, it utilizes the rendered page, it, which is actually a little slower than scraping HTML. Our initial launch of that, we took that and was a proof of concept. It works. It’s a little unorthodox, but it works.

It’s working for users. They’re finding they’re not getting false positives anymore. But then we went through a refactor earlier this year to make that scan seven times faster. We introduced front end reports for non technical content editors, which Amber demoed here a little bit ago. And we added WP-CLI for command line management and automation.

And created an add on called the Audit History add on, which Amber also demonstrated. Just a few minutes ago. And I think with that, I’m going to hand it back to Amber.

Amber: So after all that hard work, we were really excited in 2023. We were a Gaady award winner. The Global Accessibility Awareness Day Foundation gave out three Gaady awards.

One was to the agency that built the new W3C website. One was to Procter Gamble and one was to us. So that was cool. We received that in recognition of elevating accessibility to a first class citizen. Today we have 4,000 plus active installs and 5 out of 5 stars on WordPress.org. No idea where in that 4,000 plus, so you know, maybe you guys all go install it and we get 5,000 plus this week, hey?

But it’s, I feel like there’s been a lot of hard work and things that we’ve We’ve been really proud to accomplish, and what are we doing next? We are, based on some user requests, making fixing problems easier. We are going to have some global fixes that can be turned on in your settings.

But we are also working on, in that front end highlighter and in the back, being able to have buttons that’s hey, fix this for me, and you can. Hit it for the ones where it were possible, and we can do it the right way and actually be accurate. Being able to do that to especially help the, even the free users that are, DIYers that maybe don’t have any technical knowledge at all.

We are also working towards having a dashboard that for enterprise or agencies who want to be able to view the accessibility status of multiple websites all in one place. So you’ll be able to log in, connect API keys for any of the websites that you manage, and then see all of those reports there. Another big thing that’s coming relatively soon in the plugin is issues specific to user roles.

So when I did that demo for you, you saw that everything on the whole page, header, footer, all of those problems. That’s great for an administrator, but if someone is an author, they probably don’t need to be told about an issue in the header or the footer because they can’t control any of those things.

We’re working on having user role based capabilities so you can then only show issues to the user roles that you want to show them to. Email notifications is another thing that we have in the works. Being able to set it up so that perhaps if a website does get worse. You get an email alert those sorts of things.

And then, a big thing that I’m really excited about as part of this with the dashboard and being able to connect in, is we are going to have the ability for people to opt in to industry benchmarking, which will then have a public page on our website where anyone can go see anonymized data. and see what the accessibility status of websites using Accessibility Checker is, and perhaps see correlations between themes and plugins, which I think will be very interesting.

So again, I am Amber Hinds. I’m the CEO of Equalize Digital.

Steve: And I’m Steve Jones. I’m the CTO of Equalize Digital.

Amber: And you can find us at on X or LinkedIn, if you just search our names on LinkedIn, you’ll find us, and we’re happy to take maybe one or two questions, and we got

Moderator: So we, yes, let’s give them a hand.

We’ve got time for a few questions. If you are inspired, and you want to give a talk, or you have something to say, that is great. This is not the time. Please keep your questions concise, and we’ll be able to get to a number of them. So I’ll walk around and hand the mic. Let’s start. Back here.

Audience Member: Could you repost the URL of the interactive demo?

I missed that the first time.

Steve: Equalize digital.com/demo.

Audience Member 2: Hey, first of all, thanks for doing this a lot. I have about 120 clients sites, none of which use Gutenberg. How usable is this for crusty old websites?

Steve: Sure. , it’s page builder agnostic. It scan, it scans the front end of the rendered page. So it really takes no consideration into whether it’s.

Gutenberg, or Divi, or Elementor.

Amber: In our demo, if you go to the press releases post type, you’ll see what it looks like in Classic Editor. But if you are using a page builder like Elementor or Beaver Builder or something like that front end highlighter actually loads in your Elementor editor.

And you can go through the issues in the Elementor editor using front end highlighting. It’s not really front end, but yes.

Michelle Frechette: So the first time I turned it on one of my websites, I was incredibly overwhelmed with how bad the website was performing. What’s your advice to somebody who turns it on and feels that overwhelm?

Because it can feel daunting at first, but there’s got to be a way to pull up your bootstraps and go forward, but what’s your best advice?

Amber: So I will say I, I think it’s actually easier if you do have the pro and you have the open issues view because you could choose an issue and fix that, but that said, you could still go into every post and page and look for the one issue.

So I would choose things that we know cause major issues. So for example, empty links. Or, Linked Images Missing Alternative Text. That’s an easy fix. Most of us know how to write Does everyone know how to write alternative text on your images? Raise your hand if you know how to do that. Yeah, so if you have linked images with no alternative text, you could go fix that.

It’s super easy, and it makes a huge difference for users. So I would pick something, Read the documentation. Also, I run the official WordPress Accessibility Meetup, which is on Zoom, twice a month. And you can learn a ton.

Steve: I would tag that with, the plugin is always trying to float the most important issues to the top.

If you’re using the Pro plugin, we got a tab called FastTrack, and it actually will collate duplicate issues together. And it counts those and then reorders the output with the most count at the top. That way, it’s almost like the most bang for your buck, right? So you fix this one issue, you’re going to fix 99 issues throughout your whole website.

Audience Member: There’s lots of accessibility website checkers and law firms are chasing down websites left and right. One of my clients is in a lawsuit now. Every time we fix anything, they’ll send back a, another website that it didn’t pass. So how does accessibility checker, how can it be used to combat that problem?

And how could we go back to our client and say, there isn’t anything else. There’s nothing else we can fix. So you’ll have to get another web design company or. Tell the law firm to shove it, or, can this help in any way?

Amber: Accessibility Checker does have overlap with many of the same rules that law firms use, like WAVE.

They use the WAVE tool, and we have overlap in those same rules. But what I will say is, you can never solely rely on automated testing, and you’ll note when you look at our reports, there’s a little asterisk. We never say 100 percent accessible, it says pass test, and there’s an asterisk that says, You can’t just use automated testing, you need manual testing as well for real accessibility.

And we have a whole documentation article that explains how to do manual testing. And that’s something we talk about a lot at meetups. I would say you do need to do manual testing as well for a legal standpoint. But that said, having 100 percent passed in your, if you can have those reports, you can screenshot them or in audit history, you can export CSVs that show the history of it’s been at 100 percent for this amount of time, in combination with perhaps having either an accessibility professional audit it, or having users test it, and doing like a recorded user testing session, that’s probably going to be the best thing to help with liability. And the other thing I would advise your clients on is have a solid accessibility statement and process.

What do they do when they get a complaint? Do they just ignore it? Or do they say, Oh yes, we’ll get that fixed. And they reach out to you and say, Hey, can you fix this in the next 24 hours? And then it gets fixed. That is much more likely to create happiness with that user of their website than to result in a lawsuit.

Not legal advice.

Audience Member 4: For the

clients that Say they’ve, it came from you from other companies and they had the helper widgets, AKA overlays on the sites, but they’re like, we do want to have everything remediated, but we still like that widget on there. Is there a way to do it like without an overlay or something like that?

Because we still believe that these widgets help people to make the font bigger and fix contrast and all that. How do you wrangle those?

A couple of ways. We just had one that we’re remediating right now. It’s actually someone who’s been sued twice, and they had Userway on their website. I’ll call them out.

The first thing I did was We looked at what, we put the site on stage and we turned off UserWay. We did a manual audit and an Accessibility Checker scan and got all of the issues Accessibility Checker was identifying and everything that we could identify in a manual issue. Then we went to the live site and we just did it on like the homepage.

And we looked at all of the issues and did any of them get resolved. Literally none of them were resolved by UserWay. And then we also toggled the font size bigger. And look, now all the fonts overlap each other, and it doesn’t actually function well. So we just showed them all this, and we’re like, Why would you keep this on your website?

It’s literally doing nothing for you, and you’re paying Some dollars per month. So they were instantly like, Oh yeah, this makes no sense. And we’ve already been sued twice. So we’re going to take it off. So I think trying to have proof and comparisons and show them, this is literally the problem and here’s where you can see it’s not fixing it.

The other thing that I would say is that if they’re really like, Hey, we really want a contrast toggle, like a contrast toggle itself or adding dark light mode, that is not bad. And many users like those. You don’t necessarily have to have a accessibility plugin to do that. It could be coded into the theme, or there are just contrast mode plugins on WordPress that are free.

So I would think more about doing that, like having those specific tools separately than trying to use an accessibility overlay to provide that feature. And then you just really gotta test it. Because I’ve seen those contrast toggles that are generic miss things. Like it doesn’t change the placeholder text on inputs.

And now your placeholder text fails color contrast. So you need to check and make sure that it’s actually doing everything that it says it’s going to do.

Moderator: Nice. We’ve got time for just one more short question. Any other questions? I’ll come back up to the front here.

Taco Verdonschot: A little bit of a hypothetical question, but if you had unlimited resources in development tomorrow, what’s the next thing you’d build for the plugin?

Steve: Thanks for putting me on the spot, Taco. Man, we have a product strategy board in our in Basecamp, and I’d be happy to show it to you and I would implement almost all those things.

But no we, some of the things we’ve talked about just oh man. Everything, we have so many ideas, like the enterprise piece, being able to send out reports, email reports, having a dashboard where enterprise clients can manage all of their accessibility reports in one place. We would do a lot.

We’d probably build another API that scrapes, like the other guys, but keep this tool as well. We do a lot. Amber, do you have any? I’m going to put Amber on the spot since Taco put me on the spot.

Amber: Oh, the thing that I didn’t mention that we keep talking about that we probably need is a better multi site add on because currently, so our licensing requires you to activate it on every sub site to function.

So that’s a good point. A license is a sub site, not a whole network of sites. And that’s annoying for people that have multi sites with 500 sites. So we’ve talked about needing to have a multi site add on that allows you in the network admin to be like, this is what I want to do. I want to be able to toggle on these rules and maybe not these rules.

And these are the post types I want to check on a site by site basis. Really more on that big site management.

Moderator: Very nice. Let’s give it up for Amber and Steve.

If these embedded slides do not work for your assistive technology, you may view the presentation slides on Google or access a text version lower on this page.

Why We Built It

“Scratching our own itch.”

• Needed a solution to issues with existing tools:
• Generic rule sets don’t know WordPress – they can result in more false positives and have lower accuracy.
• Browser extensions can only test one page at a time and don’t store a history.
• SaaS options charge per page and per scan – tens of thousands of dollars per year.
• Scanning tools external to WordPress require retroactive remediation and don’t proactively warn content creators before they hit publish.

Try Accessibility Checker

Spin up a full demo of Accessibility Checker to try out all the features for yourself.

Free vs Pro

Free on dot org:

• All accessibility checks.
• Unlimited scanning of posts and pages.
• In-post and front-end reports.

Pro features:

• Scan custom post types.
• Full site scanning and full-site reports.
• Ignore log and governance features.
• Audit history add-on (small business and above).

From Idea to MVP

• Developed during the COVID-19 lockdown.
• Evaluated existing tools and plugins; identified gaps in WordPress accessibility solutions.
• Built a prototype ruleset that scraped HTML and displayed evaluation results in the WordPress admin.
• Refined rules collaboratively for accuracy and WordPress-specific checks.
• Created comprehensive documentation for user education, onboarding, and correct rule application.
• Launched with a freemium model: a full-featured free version and a Pro version with advanced features.
• MVP launched at the end of 2020.
• Continuous refinement of rules to improve accuracy and coverage.

Technical Considerations

• Server Performance and Configuration
  • Caching and efficient queries
  • Optimized database indexing
  • Require specific PHP extensions
  • Unconventional SSL and WordPress configurations
• JavaScript Execution
  • Runs in an isolated environment with the scan app injected.
  • Requires management of cross-origin restrictions.
  • Involves handling browser memory usage.
  • Mitigates timeout issues for optimal performance.
• Custom Database Table Management
  • Improves performance with optimized indexing.
  • Ensures faster queries and better scalability.
• Notable Packages
  • WooCommerce Action Scheduler
  • PHP Simple HTML DOM Parser (Fork)
  • DaveChild / Text-Statistics (Fork)
  • Deque Axe-core
• Accessibility Standards
  • An accessibility plugin must itself be accessible!
  • Tested with VoiceOver, NVDA, and Jaws.
  • Tested by multiple blind users.

Creating the Best Rule Set for WordPress

• Initial rules were all PHP-based.
  • Pro: scans could run in the background using Action Scheduler.
  • Con: Lacks accuracy with CSS variables or JS modifications.
• Major technical challenge:
  • How to keep scanning on the server with zero cost for free users while having the most accurate results?
  • Solution: Inject our JavaScript scanner app into a fully rendered, isolated environment to scan and return detected issues.
• Curated and modified axe-core rule set optimized for WordPress users.
  • Axe-core promises you can find on average 57% of WCAG issues.
  • Extended Axe-core rules to mitigate false positives.
  • Combined Axe-core rules in single rules to minimize user confusion and reduce noise.

Examples of Rule Improvements for WP

• Don’t flag:
  • aria-hidden warnings on core spacer blocks.
  • Possible heading in block quotes.
  • Anything in the admin bar.
  • Utility plugins: Query Monitor
• Run specific checks on the_content instead of the entire page.
  • Readability
  • Missing subheadings
• Rules look for specific WordPress plugins (in contrast to SaaS that only has generic rules).

Going Enterprise

“Accessibility Checker was one of the major differentiators behind NASA selecting WordPress over other CMS platforms they evaluated.”

JJ Toothman, Lone Rock Point
Dev team lead new NASA.gov website

• WordPress VIP Compliant.
• Level Up Development Workflow
  • Refactored using Object-Oriented Programming (OOP) principles.
  • Fully adopted WordPress Coding Standards (WPCS).
  • Implemented PHPUnit, Security and integrated testing.
• Removed insecure packages and libraries to strengthen security.
• Optimized database and queries to handle over 1 million records.
• Refactored scanning algorithms for up to 7 times faster scans.
• Introduced front-end reports for non-technical content editors.
• Added WP-CLI for command-line management and automation.
• Created Audit History Add-on

2023 Gaady Award Winner

Received a 2023 Gaady award “In recognition of elevating accessibility to a first class citizen” from the Global Accessibility Awareness Day Foundation.

Has 4,000+ active installs, 5 out of 5 stars rating on WordPress.org.

What’s Next

• Industry benchmarking and open data reporting.
• Making fixing problems easier:
• Global fixes you can turn on in your settings.
• Ability to fix/ignore problems in reports.
• Dashboard to be able to view multiple websites’ reports in one place.
• Issues specific to user roles.
• Email notifications.