Changelog 002: From Error to Explanation: Smarter Accessibility Reporting

Steve: All right. We’re live. Let’s see. How’s it going, William? Doing all right. 

William: Going good. How are you doing today? 

Steve: Been doing pretty good. Let’s check and make sure we’re out there live, and it looks like we are out there. If anybody else is joining us, let us know in the chat. And I’m checking YouTube.

We look good. And, it looks like we are live on X as well, all good. So well welcome to the Accessibility Checker Change Log livestream episode two. In this episode, we will be going to be talking from error to explanation, smarter accessibility reporting. So this [00:01:00] last couple weeks was kind of a, we went through a couple sprints and we actually released two releases in the last couple weeks.

Right, William? 

William: Yep. Unexpected surprise release 

Steve: Yeah. So just a, it’s a free release. An extra free release. So what,

William: Fill things up for next week. 

Steve: That’s right. That’s right. So next, next week is a typical planned release. So yeah, so two for one this week. And so what we typically have been trying to do lately is we’ve been trying to run two week sprints.

Kind of, that kind of forces us from a development standpoint to l imit the scope of features that we’re trying to implement so that we can get them out to you guys using the plugin sooner. And for us to feel like we are moving at a good pace and releasing and getting that dopamine hit every time we release a new version.

So we could jump into it. This live stream is about the Accessibility [00:02:00] Checker plugin. It’s a WordPress plugin, and at this point, it is a suite of plugins. We have the Accessibility Checker free plugin, which is a very full featured accessibility scanner. We have a pro version, which extends those features out and allows you to do things like full site scanning and some tools to help you remediate issues from a global level.

And then we have a suite of add-ons for the plugin. We have the audit history add-on, which tracks your accessibility issues over time. And then we have a multi-site add-on to manage multiple subsites and licenses and activations across all of those. And we have an export add-on that allows you to export your Accessibility Checker data to CSV files.

Smarter Accessibility Reporting

Like I said, today we are looking at adding smarter accessibility reporting into the plugin. And I think that would be a great feature to start with. A little bit of background on this one was this feature [00:03:00] actually initiated from our CEO, Amber Hinds, and Amber took the steps to actually create a PR for us.

William: And that was a lot of fun. 

Steve: That was, yeah. So that may scare some dev teams and that may, it may be seem helpful to some dev teams. For us, it was actually welcomed, and it was actually beneficial to help us accelerate this feature and get it out to you. So let’s take a look.

Alright, so what do we mean when we talk about better accessibility reporting? So in the free plugin, if you’re using the Accessibility Checker and you’re looking at issues, so I’m gonna view an issue on the front end of the website. So you see the Accessibility Checker front end highlighter is open to an issue.[00:04:00] 

So where before we just had a paragraph description that would show for the issue that was highlighted, the current issue. Now, we’ve reduced that description down to something that’s very easy to read. One sentence very, something very digestable. And then we divided up under a subheading of how to fix the issue.

So not only are we telling you what’s wrong, we’re now trying to give you information on things that you can take action on. And we still have our link to the full documentation, so you can read full documentation about this issue and more code examples and things like that. But what we’re trying to do is we’re trying to bring more actionable information into the plugin for you to see at a glance. And I think that’s it for the front end highlighter.

So, if you’re running Accessibility Checker Pro, if [00:05:00] you now go to, in the WordPress admin and you go to Accessibility Checker and you go to Open Issues the Open Issues screen is now presented with a little bit different. Where before we would just tell you the, we would tell you the check, the rule, and the type, and the count. Now, we’ve added severity and we’ve added WCAG level, and the ordering. The initial ordering has changed a little bit too. So, we’re doing a multi level ordering. Now we’re ordering first by count, well first by severity, and then secondly by count.

So, on my screen you can see I have the rules listed here, and severity, you’ll see the critical goes to high, to medium to low, and you can see the counts kind of restart based on the severity. So, if I’m looking at just the critical issues the first [00:06:00] critical issue has 150 issues.

And then the last one, goes all the way down to one issue. So what we’re trying to do here is we’re trying to order these in the way that we think is most you could get the most impact and make the most improvement in your accessibility. So it’s like how critical we think the issue is, and then the number of issues that, that exist within that severity level.

And then of course, you go into high and you can see that count, restart and medium and low. And then, but what we are still doing, we still are putting all the past issues down at the bottom so that they’re not in your way. So with that we actually made these columns sortable, so that if you want to look at it differently than our default sorting, you can click on the table headers.

So if I click on count. So it’s now ordering by [00:07:00] least to most, if I click it again, of course, it, it switches from ascending to descending. And you can do this on every column. So the WCAG level. So I say I only wanted to see the most you, the AAA and AA down the A and best practice. And then severity.

You can see all your critical rules, all in one grouping. So we have, we, when we first look at this, we were going back and forth does this make sense? Because we’ve always had errors and warnings in the past, of course. But, and I think internally we were struggling a little bit with well, what does that mean to have an error and a warning and then have a severity, right?

Do you wanna speak to that at all, William? 

William: Not really. 

So this was quite confusing for me at first. 

Steve: Yeah. 

William: Like, for example, why is [00:08:00] one of the or two of these high severity issues, only warnings are errors than the others are the opposite. Like, that doesn’t immediately make sense to me on the surface.

So I had to have, as it was explained to me, warnings are things that probably require a human to check as a follow up on its discovery. And, maybe internally, I might be fighting to make one of these columns not the default visible. 

Steve: Yeah. 

William: I think I would rather only see one at a time by default. 

Steve: Yeah. So, you’re right. So, in the Accessibility Checker, a warning is actually something that requires human review to validate if what we found is actually correct. And then error is something that we with a great deal of confidence we can assume that what we have found programmatically [00:09:00] is correct.

And it doesn’t necessarily require human review. So we went back a little bit internally should we rename these, like instead of errors and warnings, it should be like like a requires a manual review or doesn’t require a manual review or like automated review, and the plugin being several years old that would be quite the jarring change throughout the plugin. And we would have to update a lot of documentation and actually it would be a pretty significant change programmatically as well. So we left it the same. But what we did was from, I had a little bit of a concern about the visual load of this page because initially errors and warnings in past were in, in a like button.

They looked like buttons. They weren’t buttons, but they kinda looked like it, like a little flag. And it was like a solid, red background and solid orange background. And so what we did was we removed those [00:10:00] backgrounds, we just made ’em text and we added icons and we changed the warning from an orange to a blue to not conflict from a visual standpoint with the severity levels.

So it does raise the question. How can a warning be high? How can a warning have a higher severity level than an error, right? So, that’s where it gets a little confusing, that the warning actually means that it requires human review to validate if it actually is a real issue.

So, to that, we wanted to add some explanation to severities and types and stuff inside the plugin. And so up in the help tab, in the top right hand corner of the admin, you can toggle help and you can now get a couple tabs here to for descriptions, for types, [00:11:00] understanding issue types, errors.

With accessibility issues that are almost certain barriers for users with disabilities and it goes on. And then warnings, potential accessibility issues that might be problematic depending on context. And that goes on and we provide some links over to our documentation and over to our support here as well.

And then there’s a second tab for severity. So where it talks about critical, high, medium, and low and what, and how we’re evaluating the severity levels. And we found that, or the way we’re actually doing it is we’re actually validating the severity off of what Axe-Core is doing.

And a little bit off of our own discernment internally. I was actually listening to the WP Product Talk podcast this morning, and Amber was demoing some of this stuff, as well. And talking about that, using the help tag the [00:12:00] help tab up in the top of the admin. And Zach had mentioned that nobody uses that.

And it’s funny ’cause I know William 

William: Used it once.

Steve: Yeah. When William and I were talking about implementing this and I think we were both yeah, I don’t know that we’ve ever used this help tab inside. And it’s there if you go to a post type and 

William: But it does seem like it’s a good place for this information to live, but it isn’t incredibly discoverable.

Steve: Yeah, I would agree. And I think our initial thought was that we would implement it here with the thought that if it really became an issue, we would actually maybe pull it out and, over to the right hand side, maybe make a description key of sorts. But from a plugin development standpoint, utilizing the help tab is, very easy and you can hook into it very easily and put your data there and that’s just some UI that you don’t have to create.[00:13:00] 

So I thought this was a pretty good place for it. But I would agree with you, William. I’m not a hundred percent sure how discoverable it is. 

William: Yeah, I think we’re gonna need to tell people to click that 

Steve: Yeah. 

William: With the same questions. 

Steve: Yeah, possibly. So if you are sorting these tables and you do modify ’em, we do provide you with a button to reset the default sorting.

And that just moves it back to that multi level sorting that I talked about earlier. So once you click through to an issue, so we’re, I’m clicking on ambiguous anchor text, and that brings me over to the individual issues for that rule check. So, now we’ve updated our description box here with the with the updated information on the WCAG criterion that it, it references.

And in this case it’s the 2.4.4 link purpose. It, and it is a level [00:14:00] A and the severity is critical as we saw on the previous page. And we’ve divided this up into multiple headings on why it matters. So we give a detailed description on why it matters, but a detailed but brief. And then we provide the how to fix text.

This is the same text that I showed in the front end highlighter. Okay. And we have with a link to more detailed documentation, and then we provide additional resources. So a lot of these links a lot of times there’s lots of references that we could use in the MDM docs or in WCAG docs. So we’re linked over to resources that will help you understand this issue and help you remediate this issue.

William: Yeah. So we do also have information about the affected user groups that individual issues might pertain to, which probably will also appear in this right hand side box in a not too distant future. [00:15:00] 

Steve: Yes. Yes. So that is, that has been added in the code. So that’s something that we’ve already implemented from a code standpoint, but we have not surfaced inside the plugin yet.

And so look for that in the future. So that is the how we are adding more information and helping you get to fixing the issue quicker and getting the information in front of you that you need like I said, a big shout out to Amber Hinds for opening a PR on this and scaring the dev team with the CEO opening a PR, but definitely helped bring this feature to life and helped bring it to the public I think a lot quicker than it would’ve.

William: Yes. So for, just for a bit of reference, I am a developer and a lot of this text is not in my wheelhouse. I’m not a copywriter. I couldn’t have written this even with guidance. This ideally came from Amber, and [00:16:00] I don’t think there’s anyone else in our company that would’ve been qualified to write this quite as nice.

And I’m a big fan of the how to fix messaging now, because before it was almost a bit of, flying blind. We were not actually telling you, we were saying, here’s this issue, this is what the issue is. But we weren’t explaining how that could be fixed or even why it was important to fix it.

Steve: Yeah. 

William: So all that information now is right there in front of you. You don’t need to visit the documentation links anymore. Get that info. 

Steve: Yep. Yeah, like we suggested Amber put a comment and maybe in the future the word warning will change to needs review. So yeah, that’s what we were explaining.

And, I think that’s part of making a software product like this, especially something that involves accessibility, where you’re trying to give context to how the rule was found and what the severity of it is and what the priority of [00:17:00] fixing that issue is. That adding more clarity in the future I think would be great.

So that was that feature.

Rescan Button in the Frontend Highlighter

So we’ve added, the next feature here that we wanna talk about is we added a re-scan button in the front end highlight to re-scan the current page. So let me share my screen again. So was this, did you do this one, William? 

William: We had a bit of help from the AI for this one. 

Steve: Well, we don’t need, we don’t need to out ourselves.

William: I had previously worked on this and had UI problems that didn’t resolve in the moment. 

Steve: Yeah. 

William: And AI got the help to get this over the finish line. 

Steve: Sure. So why did we add this? 

William: Well, quite a few users at this point are not visiting [00:18:00] the editor page at all anymore. There’s a lot front end page builders.

There’s a lot of people who may be looking at their issues on the front end and not wanting to visit the admin. Not, not everyone’s technical. They don’t like being in the dashboard, but a lot of people on websites and they like to look at their stats. Here, you can see your issues and if you don’t think the rules or you don’t think what it’s found is correct, you can click that button right there, that rescan button.

All of a sudden. The issues are wiped and a fresh scan of this exact page as it is right now is performed. And then you can see the results right then and then. 

Steve: Yeah. So in our previous live stream we talked about we added the ability for the front end highlighter to scan unscanned pages.

So if you go to a, if you navigate to the front end page that hasn’t actually been scanned in the back end, that the, 

William: We’re covering the box, Steve. We’re gonna [00:19:00] have to go in the admin and move it to the left. 

Steve: Oh yeah. Hold on. The, you talking about on the live stream?

There we go. Sorry about that.

William: Oh, you still have a shared in button? I got it. 

Steve: There we go. 

William: Yeah. 

Steve: Thanks. Thanks for calling that out. But yeah, so in a previous version, we added the ability if a post had not been scanned, that the front end highlighter, if it was initiated, it would automatically scan that and show you results.

As a secondary feature to that, we’ve added this re-scan button, which you can now see that now that William instructed me to move it into the viewable area. We have this re-scan button, and you hit re-scan and it says scanning, and then it refreshes with the issues. So the issues didn’t change in this respect because I didn’t do anything, but if I was to enable a fix. So you can enable fixes from the in front end. You can actually [00:20:00] re-scan the page here in a future release. What we’re do is we’re actually just do it for you whenever you enable a fix.

One thing that I found interesting when I was going through was that like if you’re like a developer playing around let me, I can actually like, so say this issue that says ARIA-hidden I can go in here. Is that what it was? ARIA-hidden? 

William: Yep. 

Steve: Yeah. Yeah. So if I actually wanted to just, this is not correct for me to move this, but this is just for illustration purposes, but I could re-scan the page and it’s scanning and it refreshes and that.

Now that issue is gone. So like I can play around in the front end, which is a little dangerous because that’s now saved in the database, but, so it’s not entirely correct now, but I can

William: I do have plans to make this be able to scan without saving. Yeah. So the [00:21:00] users that are experimenting can verify their fixes right here.

And that’s gonna be particularly useful for people that use the front end page builders. 

Steve: Right? 

William: What is what you get. They’re gonna wanna run temporary scans. 

Steve: Right, right. Totally. So I found it useful to play around with modifying the elements inside the Chrome inspector and the re-scan it.

Okay, that’s how I fix it now we go to the code and we fix it. We fix it there. So that’s just a small feature, trying to add a little bit of more usability to the front end highlighter. We actually, I’m gonna tease a feature right now since we’re talking about it, but we have a PR up pull request up for being able to clear the issues out on the front end as well which you can actually currently do in the back end.

So we’re gonna surface that to the front end highlighter. So that is our re-scan button. [00:22:00] 

Automatic Cleanup of Orphaned Issues

William: Well, that actually leads us into an interesting thing. So the reason that the cleared issues button exists is because some people ended up with orphaned issues that were not attached to posts entirely, and we needed that button to clear them.

That is also the next feature on the list that we released on Tuesday. Yeah, we’ve released this week actually. 

Steve: Yep. So yeah. 

William: Now if there is posts in the database that are dangling, no post attached to them anymore, maybe the post was deleted with command lane, some plugin delete the post and didn’t fire the appropriate hooks.

We don’t keep that in the database anymore. We actually will now have a background process that runs once a day. I will start slowly making sure that the database gets cleaned up once a day, up to 50 issues at a time to make sure that it doesn’t hit performance of your website. But yeah, if you have issues that are dangling with nothing attached to them or the post types are mismatched or [00:23:00] whatever has happened, has caused that data to be recorded but no longer connected, they will just be removed and it’ll keep your databases nice and clean.

Steve: So will this work for, this’ll work for people that have been building up orphaned issues over time? 

William: Over forever. And there, there is, there are various reasons why issues do not get fired. So we do have actions bound to the trash post, to the delete post, and we should be cleaning up our own issues as opposed to move between statuses.

But sometimes plugins skip post, they skip all the actions, they skip the post delete or the trash step. There’s no way for us to track every single situation. It also used to be problematic for us to scan our database every day and find these issues. But now it’s just a simple SQL query.

It’s quick, it does 50 in a batch, and it will just continue to do that every [00:24:00] day. And this opens up the opportunity for other cleanup routines to make sure that we can keep all of, all of these websites that we’re installed on, make sure that we’re not slowing them down by increasing our database size unnecessarily.

We are only gonna store the things we need to do to offer what we say we do on our plugin. Right. We don’t wanna be storing additional data. We don’t wanna be leaving things dangling after we’re gone. 

Steve: Yeah. So that it can happen too. Like when I think the, where we, it highlighted itself for us was when post types actually, or when somebody actually switches.

A post from one post type to a to another. And you’d think that wouldn’t happen very often, but it happens more than you would realize. And there’s also a second use case too where if Accessibility Checker plugin gets turned off for a time and then posts are deleted while the plugin is turned off, and then when it’s turned back on, it’ll still retain that data [00:25:00] in our, in the Accessibility Checker database.

And this just provides, a way to clean that up. And I think we can demo this. You, I can demo it. Is that all right William? 

William: Yeah. 

You can run a demo. I didn’t prep for this. I could maybe while you’re doing that prep for this I did also add a command, a WP-CLI command. So if someone discovers that they have quite a lot of orphan issues, they can actually use the command line and, clear out as many issues as they want 

Steve: Yeah. 

William: Without having to wait for the ones that they check to run.

Steve: Cool. Well, I’ll demo that. So let’s take a look. So the first use case here, I think what we’ll do is we’re looking at switching the custom post type. What I’m looking at now is I’m actually looking at the my SQL database. I’m looking at the Accessibility Checker table, and I’m looking at the results inside that table.

And you can see that I got 1,493 rows. So 1,493 rows. [00:26:00] If I go into pages here and I select 

William: Actually, I think I may want to stop you at this point. I’m not sure. This does clean up the post type thing and maybe you demo the other one and I’ll check that. 

Steve: Well, let’s demo it and let’s see. But let’s see.

Yeah, 

William: we do, doesn’t it? We’ll, I’ll look in the next. 

Steve: I am pretty sure it does because I tested it. Well. Let’s see. 

William: You tested that, but I didn’t write tests. 

Steve: Oh, you didn’t write tests? Yeah, so hold on. 

William: That confuses me.

Steve: What I’m gonna do is I’m gonna do a bulk action and I’m gonna change the posts post.

William: Oh, you don’t have post types? 

Steve: I don’t have other post types. But look here’s what we can do. If I turn on a plugin like Elementor, which should give us additional custom post types

so I’ll select five of them or so, edit, bulk, edit, [00:27:00] post type. I’m gonna change it to template, which is just the Elementor custom post type. It’s weird to actually switch a post to that post type, but this is just for demo. Okay, so you can see I’ve moved those. So there was roughly like four or five posts that were moved to a different post type.

So I’ve got 1493 rows. So there’s two ways to to, so this will actually automatically run every 24 hours. It’ll do this cleanup, but you can initiate it in a couple different ways. And William already talked about one way, which was using the WP-CLI. So our plugin actually has a handful of WP-CLI scripts.

We’ve wrote a CLI script for this. And the other way to do it is actually to use something like, the Crunchroll plugin to actually initiate the the CR job and off cycle. So let’s try to run the [00:28:00] WP-CLI. I’m here in my terminal in Mac and then, and the WP-CLI script is WP space accessibility dash checker space cleanup, dash orphaned dash issues.

So let’s run this and see if we get some results.

There we go. Found five orphaned post IDs. And then it tells me the ones that it’s deleting. So it says deleting issue for post ID 8 5 8 9. And then of course it goes down and shows me the same for the five issues. And then I get a success message that says orphaned issues cleaned up, complete five post processed.

So

William: I’m glad that worked. 

Steve: Yeah so we had William sweating a little bit on that one. 

William: I need to write PHP tests for that thing. That’s what made me question it because I wrote them specifically for if the ID doesn’t exist, but I don’t remember writing them for. If the type changed. 

Steve: Right, right.

So [00:29:00] this feature and so this feature was a little bit of a tag team. So between, we can say it, the AI kind of initially helped us write something and the way a lot of times it goes with AI is you get an initial recommendation on how to do something and then you look at it and you go, no, this isn’t right.

And then I think William took a pass on it. 

William: To be fair, I think the AI did an okay job of this. I just added the command line because this is how I would personally want to clear these issues out. 

Steve: Yeah. 

William: So this, I’m sure other people are similar to me. And yeah. Just some code cleanup.

The AI that we tested with this did not like tabs, so it did not write way to clean code. 

Steve: Yeah. So William did a pass on it and cleaned it up and added some use cases there. And then I did a review and I found that it was only deleting posts that didn’t exist anymore. And I [00:30:00] wanted it to actually delete posts that don’t exist and when the post type had actually changed on an issue.

William: Oh, so you changed this after I had the yeah. 

Steve: So that’s exactly which, why 

William: I didn’t write the tests. 

Steve: Yeah, that’s why I’m bringing it up. That’s exactly why William freaked out a little bit when I started to do this because he didn’t necessarily do that piece, but then it went over to him for review.

So we’ve been moving fast and doing lots of features so we can forget I call it developer amnesia. You have to flush the brain to put more stuff in. 

William: Soon as you finish one thing, you need to move to the next. 

Steve: Yeah. So if I go back and I look at my SQL database here, I said we had 1493 rows.

If I refresh, I now have 1478, so that’s less the five that we’ve deleted. So a second example of this is just when posts are deleted and we do run. We do run a cleanup when a post is deleted with the plugin active, but if the plugin is not active, or [00:31:00] for some reason the hook that we use that to, to remove issues out of our database, when that’s deleted, fails for whatever reason, like maybe there’s a plugin conflict on your website and something further up in the stack fails and it never gets to our cleanup process then that would actually generate an orphaned issue if the post in fact did delete.

So the way I can demo this is if I go to WordPress and I go to plugins or the WordPress admin and then I go to the plugins and I’m gonna deactivate Accessibility Checker Pro and I’m gonna deactivate Accessibility Checker. So now if I go to the post page and I select a handful of posts. I don’t know how many this is, but it’s like roughly 10. And I just move those to the trash. Just for, I’m gonna dump the trash just to make [00:32:00] sure. So I’ve deleted 11 posts. So now if I go back to the Accessibility Checker and I reactivate the plugin and this will actually clean up just with the free plugin.

You don’t have to have pro installed, but I’ll, I’m gonna turn pro back on. And now if I run that CLI command again, it’ll delete them just like it did before. But since we’re here in the admin, I wanna show you the other way to manually trigger this. And it’s just using a plugin called the WP-Control.

If I go Cron Events. So if I go to tools, Cron Events, and I just search EDAC, which is Equalize Digital Accessibility Checker, it’s our prefix. You can see that there’s a Cron job here called EDAC cleanup orphaned issues, and you can just hit run now.

Now, where this will be different than the CLI script is you won’t get visual [00:33:00] feedback that it actually did it like you do in the terminal, but it should run nonetheless.

So if I hit run now, so that’s gonna go ahead and run that scheduled event. It doesn’t affect the one that runs every day and it’s gonna go through and delete those issues. So how do I know if it actually deleted the orphan issues? Well, since I’m not using WP-CLI, I have to rely on the my SQL database.

If I jump back over to my SQL database admin here, and I refresh. We should see this number drop by 11. So currently it’s 1,478. If I refresh, it’s now 1450. So actually I was wrong about, I was wrong about the 11. We delete 

William: Some of them have more issues than that. 

Steve: Yeah. We deleted 11 posts, but there are multiple issues within the post and it looks like it actually deleted what, roughly 25 issues throughout those 11 posts.[00:34:00] 

So that is our cleanup process, and this is something that we’ve talked about for a long time. Something that we’ve had in the roadmap to implement, and I am happy that we finally got that implemented. 

William: Yeah, that’s nice that this exists. Now, I will call it the, in the WP-CLI command, you can actually increase the batch size.

So if you have, you’ve turned our plugin off a year. And just recently reactivated that you might have 10,000 issues that are orphaned. You might have a lot of them. You can actually increase the batch size on the command line flag version of this. So if you wanted to delete all of them in one go, you could do that.

And if you have a concern about performance, you actually have added a sleep timer. So you can actually add like a delay between each deletion. So you could delete, 10,000 posts with 0.2 seconds between each one. Or, two seconds, five seconds. You can change that to wherever you want. [00:35:00] 

Steve: Cool.

William: Yeah. With Cron job, no such, choices, right? It will do 50 at a time. And if you’re in a situation where you have a very old site and you’ve just recently reactivated the plugin, after one year or two years, you probably wanna use the command line option. 

Post Status Filter for Full Site Scans

Steve: Yeah, totally. Cool. So our next feature is the ability to filter post statuses that are scanned in the full site scanner.

William: Yeah. So this has been a very long-term requested feature by many people, and we have always been slightly resistant to building this because, you wanna know about your issues before you publish the post. You don’t only wanna know them in published posts, but, well, I think that’s what people want to know.

It turns out customers think differently. Sometimes the customers actually do wanna just scan the published posts and now using a simple filter, they can do that with the fill set [00:36:00] scanner. So they can choose what post statuses are scannable in the fill set scanner, I’ll call it, if you visit a single post.

It will still scan the issues, even if it’s a draft. But, so the filter only affects the filter scanner, and that is on purpose. Yeah. I want you to get your results if you’re editing a post. 

Steve: Yeah. The single issue will be a separate filter.

Yeah. So it is interesting building software like this and getting lots of feedback from clients that come in through support or just, feature requests. And this one actually probably was the one that would come up the most. And I think it’s, people have different use cases for how they handle posts, right.

We, I think we had a client that was, they basically had, what we would call the, the old post or just outdated posts that they just set ’em all to draft and so that they can, it’s like posts that [00:37:00] they’re probably planning to set as archived and in an accessibility way archived.

And that way they don’t have to like worry about the compliance on those issues. But and they were setting ’em all the draft and then they would go to the full site scanner and the full site scanner is gonna scan everything. And if they have a large number, five, 10,000 post, it could take a long time to scan.

So I think what users are asking for in a full site scan are ways to. Get a full site scan, get a picture of kind of what the overall issues are like throughout the website, but maybe filter ’em by, post status, maybe filter ’em even by post type, which you can do, but you have to select the post type in the settings.

William: I preschool that actually way I was looking at the status. I think we will implement a filter for the type as well in the, not do this in future. 

Steve: Yeah. And possibly date. And so this is, 

William: it’s a lot more complicated. 

Steve: Yeah. This is laying the groundwork for us to [00:38:00] be able to add custom filters to the full site scanner.

So you can choose what type of full site scan you want to run. So are you prepped to demo this, William? 

William: I can be in two minutes. Maybe two minutes. 

Steve: I gotta talk for two. That’s a long time in livestream time. 

William: Let’s see. 

Steve: So basically what we’ve done is we’ve gone through and you can just add a, add a custom filter to your functionality plugin or to your theme inside your functions.PHP file to actually filter these out.

And the reason why we start with a filter, and then a lot of times when we create features like this, we will, from a development standpoint, we’ll create the filter first. That way we can run tests and do all of our testing to make sure it works. And then from there we’ll build a UI on top of the filter.

And what that does is, like for say we have these handful of clients that have been requesting this, we can actually get this over to them. We can give them [00:39:00] a pre-release of the plugin and we can tell ’em, here’s the filter to use and they can test it and provide us with feedback on it if it’s working or if there’s any bugs or things like that.

So I don’t think that was two minutes, William, but let’s pull you. 

William: I think I’m ready. Yeah. 

Steve: There we go. 

William: So here’s my scan of my test site. I have 75 pages in total. 10 or so ish are drafts or other statuses. So this is the filler. It’s actually really quite simple. This is the filler name. It gets past the current statuses and you return an array of, statuses that you want.

In this case, I’m gonna only want published pages. So if I come back here, you say, I didn’t need to refresh the page because this is constantly doing a poll in the background, and now there’s 64 pages to be scanned. So I’ll click this one, run the scan, it’s gonna scan all 64 of those pages. [00:40:00] 

Steve: How many did you have before you added the filter?

William: 75. 

Steve: 75. 

William: So I have 11 draft posts or pages. 

Steve: So if you stop that, if you stop that scan. And then you go to the filter and actually change the filter to draft.

And then, 

William: So I’m gonna need to reload the page for this one. This one does not update the numbers, but yeah, there we go. Nine into, 

Steve: Yeah. So now he’s, 

William: So this is gonna scan draft, but it’s gonna fail on my local. Say every one of these isn’t gonna be scannable. 

Steve: Yeah. 

William: Apparently number four is very simple.

Steve: Yeah. But so very easy to filter those out. Oh, I liked that. How that scanner went backwards. What was that William? 

William: It is too fast for its own good. 

Steve: Yeah. 

William: When it’s the number’s low. 

Steve: Yeah. And the progress bar so we have JavaScript polling on the page to like. [00:41:00] Increase the progress bar.

William: So what happened there was I actually scanned two pages in the team that it pulled because my pull rate is set five seconds. 

Steve: Oh, I see. Very cool. So yeah.

William: That’s updated. And if I change the spec or if I just comment, so again, after a few seconds this stuff, it’ll go back up.

Maybe not, but Yeah. Versus seven effect or yeah. Oh yeah. That won’t complete, obviously this is the amount that it just scanned.

Steve: Yeah. You have to hit run a new scan. There you go. Yeah. Yeah. So very cool. Something that we, a feature that we, yeah, a feature we were a little nervous about was actually not nearly as hard to implement as we thought.

William: Well, we got it implemented with just this, but the amount of changes that were needed were not small. 

Steve: Yeah. Yeah. So this is out in the current version that went out on this Tuesday. [00:42:00] And you give it a try and we will be sending this over to some of our clients that have requested this and asking for more testing and look forward to us surfacing this in the UI here in the near, near future.

Alright, so last, on the last stream we talked about landmarks. We added landmark locations to the plugin. And since Williams’s already there we’ve added this to the open issues tab as well. You now have a column in the table for landmarks and you can click on a landmark and it will open it in the front end and highlight it for you.

And this has been implemented in previous versions in, on the individual page. So there we go. Very good.

All right. So the next feature, which I and we, this was one [00:43:00] that was sitting out just in a, I don’t know, on a shaping board or something that just never got implemented, was to add the license key to the plugin the plugin admin page. Why would we want to do this, and why would we spend time doing this?

William, do you wanna pull that up? 

William: I could, but please don’t comment on update plugin . 

Steve: This is a local environment, right? 

William: Yes. 

Steve: Yeah. Yeah. 

William: So here, my license is currently activated. If I click this link, it’s going to deactivate it, but I don’t have my license key to hand, so I can’t click the link.

Steve: Here. Here, let me show my screen. 

William: Yeah, but I actually can show quickly. So now with the quick fix, the quick links here. 

Steve: Yeah. 

William: Can actually just get to it here. 

Steve: Yeah. 

William: Real fast. 

Steve: So what we’re trying to do is we’re trying to we’re trying to surface these little things and make the plugin just that much easier to use.[00:44:00] 

And when you activate a plugin or when you installed the Accessibility Checker Pro, say you just purchased it and you installed it and now you need to add the key and you can just add it right there. I’ll run you through that real quick. So if I deactivate my license, so I’m on the plugins admin page in the WordPress admin.

You can see Accessibility Checker Pro and then below it, it says License your Key and then an activation button. It says Enter your license info and press return to activate it. I’m going to not show you what my license key is. So I’ve turned off the screen while I add my license key and I hit Activate and I’ll show you the screen now.

And it says your license for Accessibility Checker Pro is active and then you could deactivate it again. So we’re just taking steps to make it just that much easier and that much quicker for you [00:45:00] to do the things you need to do to make the plugin work.

What’s the next feature? The last two features we have here are they’re not bug fixes, but enhancements we’ve done to some, a couple of the rules to make ’em a little smarter. And this is something that we’re constantly doing at Equalize Digital is we have audits and remediations going on, and we have plugin development going on, and those two parts of the business help feed each other, right?

As auditors are going through and auditing things, they’re, it’s they’re, it’s great user testing for the plugin and it surfaces issues that. the development team doesn’t always come across. So it’s it’s in software development it’s called dog fooding. And so we actually use the Accessibility Checker day to day.

In our, the services that we provide to people when we run audits and remediations accessibility Checker is at the core of [00:46:00] those. And when you use your product, you can get a lot of feedback on what’s wrong, and you can come across a lot of websites that are not always in your test suite, right?

You can run into all kinds of scenarios, different themes and page builders and things like that. So a lot of times we have a constant loop of feature of issues that are being raised inside the plugin and then rules that need to be made smarter.

And here are a couple of them.

Do you wanna speak about that, William? 

Enhancement: ARIA-Hidden Rule

William: Yeah. Some of the rules we have look at, directly at the markup that is discovered by the scanner and determine whether it is valid or, it passes or it fails. But, some of the rules look at other things. So for example, the rule for the, and the ARIA-hidden check.

So ARIA-hidden is, there’s a bunch of valid use cases to use ARIA-hidden. For [00:47:00] example, decorative images. So we will still flag a decorative image that includes ARIA-hidden, unless we can discover sibling d escriptor text. So you know, for example, a social media icon might include screen reader text. That is a valid use of, ARIA-hidden, right? You’re hiding the image, but providing the screen reader text and, other valid use cases might be an SVG that contains some description text that isn’t gonna be visually seen, but it will be announced by the screen reader. And that’s also a valid use of hidden other elements nearby.

So discovering ARIA-hidden, previously we would really just flag all instances and almost all scanners, other scanners flag every instance that they discover of ARIA-hidden. But there is legitimate uses and if we can determine legitimate uses by the sibling elements, we actually won’t flag it as an issue [00:48:00] because, why give you that noise?

Right? We’ve been able to determine it’s valid. 

Steve: Yep. 

William: And yeah, for me, an interesting thing about this rule specifically is that this looks at other things on the pages. Almost all other scanners look only at the instance they have discovered, but we’re discovering the instance invalidating, whether or not it’s allowable based on our decisions there.

There’s no hard and fast rules. We have encountered valid use cases and now we’ve codified them. 

Steve: Right? So this is actually a warning. We talked about this at the beginning of this livestream and a warning requires human evaluation. But I think as we refine our rule sets and we go through when we find use cases like this where we can even make a warning or something that requires manual review smarter to not surface so much noise to the user that makes the plugin more usable and more beneficial [00:49:00] and it saves them time in their remediation.

On the screen here, what we’re looking at is I’ve got two pieces of code and I, and what I’ll do sometimes when we test is we just jump ’em, dump ’em into a code block inside the block editor so that we can run tests and see if they’re an issue.

Down in the details tab, I do have a couple ARIA-hidden issues, but they are different. They’re actually I can show you. They’re these arrows down here. These are not the code that I put in these code blocks. And so this what 

William: This is this 2024?

Steve: I think this is 24. So what we’re, so what we’re doing is there’s a button, there’s an SVG, and then there’s text accompanying it, right?

So in this first code block here the accompanying text is menu. So we could flag that as ARIA-hidden, right? And say, Hey, this is already hidden, go look at it and see if it’s legit. Right? But what we’ve done is [00:50:00] we’ve made the rule smarter in saying, Hey we went and checked the siblings that exist within this parent element and we found inner text and we can determine that this is a valid use case of ARIA-hidden and we no longer flag this as an issue for you to review. So that’s just the steps that we’re always taking to try to make these rules more intelligent and to try to save you time in your remediations.

Anything else on that one, William? 

William: No, nothing on this one. But the next issue is kinda similar in sense as well, whereby is an analysis of the entire page.

Enhancement: Redundant Alt Check

So the other issue that we enhanced this time was the image out redundant check. Formerly if it discovered repeated alt texts on a page, it would flag them as redundant because why would you include the same alt text? But we [00:51:00] realize there is legitimate use cases for repeat alt texts. For example, if you have the same image in two places, it should have the same alt text. That is correct.

From an accessibility standpoint, you want the same image to contain the same alt text or not just the same image, but the same image that links to the same place. If the image has the same purpose, the alt text should be the same. And formally we were flagging it as an error, but we’ve, updated our rule now.

And it will, every time it encounters an image, when it’s doing the redundant alt check, it will look at all the other images on the page as well. So we now have the capability with, a recently improved scanner that we always have access to the full context of the page. So no longer are we looking at just the discovered snippet in the violation or potential violation, we’re also looking at what we can compare that violation against the rest of the page context.

And as [00:52:00] such, get a much clearer picture of what is going on the page and whether something is valid or not. Because something we’re always trying to do is we wanna reduce noise as much as possible. We’re gonna throw all these issues in your face. If some of them are invalid, that’s on us.

So we’re doing our best to make sure that we’re not throwing invalid things at you, right? We’re only throwing genuine issues whenever we can determine them. So in almost every release we have an enhancement like this where we already did something, but we’ve improved it.

Steve: Right? And again, I will reiterate that’s just in an effort to save remediation time.

And the reason why making the plugin intelligent and saving time in that respect is because we actually use it in our audits and remediations and if we can save our internal team time, it’s a huge benefit to us. It’s a huge benefit to the client, and it is a huge benefit [00:53:00] to implement this in the plugin and get that out to all of you users as well.

I brought the code up. I’m looking at the diff, the code diff in GitHub on this. Just to show how simple it was before when we were running this test, this check, and then the complexity that was added to go out and search the full context of the page.

So before we, it was bare, it was real simple. We’re just checking to see if the alts are similar. And now, we’ve got, we’ve added all these conditionals to run through and check different nodes and stuff. So I thought this was interesting. And when we develop things like this too, like we talked about developer amnesia, which I think William and I both suffer from severely.

It’s just a cognitive overload. You can only put so much in these brains. But we actually, from a development standpoint, we like to utilize comments to, in a respectful and concise way, [00:54:00] but in a way to help our future selves out. So we will, as you can see on the screen, we’ve thoroughly documented this in four lines of comment code, and that will be highly beneficial for us or anybody else on our team, or if somebody does a PR on the public repo.

And I think while I have this up, maybe I’ll just note a little bit on, on how we’ve come to a place with the development of the Accessibility Checker that we can actually take these, issues that are raised from our internal team and turn those into fixes that we have assurance actually work and that are testable.

And when we did our big refactor of all the rules into JavaScript, William actually implemented Gist tests in our test suite. And so now when the issue’s raised and say Amber opens an issue that she found and she gives us, this is the code snippet that’s giving a false positive and this is what the code snippet should be. [00:55:00] From a development standpoint, that’s amazing because we can just take that code snippet and we can create these tests off of it and then we can actually just prompt AI to say, Hey, give it context of the rule. Give it context of the test, show it which test you add, and say, now update the rule based on these ., Updates it. Then we can actually run the Gist test and confirm that it actually worked.

William: So sometimes I do it. Most of the time I do it the opposite way. So what I normally do is I feed the AI, the problematic fragment, and I ask it to create these test cases. 

So again, 

Steve: That’s interesting.

William: To create these test cases. So I can manually write some, or I can have the AI generate edge cases or whatever.

And once it’s written, the test cases, normally I’ll try and take the first pass at fixing it manually. And if I can’t fix it, then I’ll ask the AI to take a pass at it. And normally these enhancements, but not just these enhancements, but a lot of the development work we do now is aided by AI [00:56:00] to help speed things up.

Steve: Yeah, totally. And I think having a test suite like this for, especially for rules that you’re always trying to evaluate some of our test suites for a rule may be like 10 lines to actually run the evaluation, and then we have 200 lines of tests. And that’s because we’re gonna run this on all these scenarios and we can just keep adding tests to it.

And it is interesting that your approach to this, and my approach to this are actually flip flopped. I’ll actually write the test first and then tell AI, Hey, here’s the test. And yeah, 

William: I like to write the rule. I like to feel like I’m doing the importance, so 

Steve: Yeah. Yeah. That’s cool.

But 

William: I can’t show why we’re talking about the test though. I actually fixed the thing that came in a client request or a customer request. It came in a while ago, but they were having issues with transcripts so I can actually show live. How we use these tests to validate the fixes. If you pull up my screen.

Yeah, the, customer [00:57:00] a while ago had an issue they were unable to detect. So they have a link, an external link that goes to their transcripts. So the way our missing transcript pro works is it finds the video and then it tries to make sure there’s a transcript within a reasonable amount of content afterwards.

So this is, this is a scaled back version, but this is very close to what the client’s markup looks like. And I’ve pasted this right into the test. And the issue was the test formerly would discover this first diaphragm and then trip up on this second diaphragm in the unscript tag, and thus never reach down here to discover that our transcript exists and it would flag this.

And this was caused by an optimization plugin. So it loads a fake iframe first and then swaps it with the no script iframe afterwards. [00:58:00] Oh, so this is laser loaded iframes. 

Steve: Laser load. Yeah. Yeah. 

William: And this was causing a problem. So I’ve came here and the first thing I did was I simplified this markup and I came, added it to this test file.

And I do have 

Steve: Yeah. 

William: Changes, but if I run so I can run all these tests, I, yeah. Now every one of these tests pass, this is the one I’ve just added, and here are the changes. If I just quickly copy and paste that entire file, roll it back to before any changes were made and rerun these tests, this one fails.

And this is how we’re able to validate that these changes we’re making actually will [00:59:00] pass for the tests that we’ve grade. And these tests are generated from actual markup on, customer’s websites, but just generally people’s websites. 

Steve: Right. And we’ve even spoof CSS and JavaScript inside of those tests sometimes too.

William: We can, I don’t think there’s any in this. 

Steve: Oh, okay. 

William: Test. But yeah we can spoof CSS JavaScript and when we say spoof, we actually are replying it. This literally renders a page. 

Steve: Yeah. 

William: With these pieces of markup. 

Steve: And it’s beneficial too. Not to go on too much of a tangent on doing test driven development, but this actually comes in handy too a lot of times where it’s like sometimes, an issue is raised internally that should this rule be flagging for this, this markup and we don’t always know.

And then we can plug it in there and run it and go, okay, well it doesn’t flag it or it does flag it. [01:00:00] And we can actually keep adding to the test suite without actually modifying the code when we come across other scenarios that are very specific, just what William highlighted from the customer.

William: Yeah. So this was, I’ve scaled this back and I’ve, anonymized the whatnot. But this is the markup. 

Steve: Yeah. 

William: Direct from their website. This is the exact pattern I had and as you saw before, these changes. It would fail. 

Steve: Yeah. 

William: Now, it will pass. 

Steve: And if you modify the, if we modify a rule check and if we modify it and we re rerun these tests and we actually violate a scenario that we put in there, like with the change, it’ll actually be a red flag.

Hey you can’t do that. Yeah. 

William: Yeah. And we have this workflow that will run. This is a GitHub action. Anytime any of the rules or the checks are changed, this will run the test in CI. And if you’ve made the change that breaks them… 

Steve: Yep. 

William: You’ll be blocked from merging. 

Steve: Yep. So if you’re [01:01:00] out there and you submit a PR to us, this runs in our continuous integration, and we’ll run on any PR that you try to submit to our repo.

William: Yeah. But it will block you from merging, but it actually is also helpful. 

Steve: Right. Yeah. 

William: You know that if you’re making changes, and I will encourage people that if they have markup that is problematic. Open a PR and add it to the test file, and the test will obviously fail, but then we can take that PR and we can figure out why this fails and then we can fix that problem.

So yeah, if you ever feel like you’ve found something that should pass or fail and it doesn’t just come to our repo and literally add 

Steve: Yep, 

William: this markup fragment. 

Steve: Cool. So that little improvement, it has not been released yet, right? William? 

William: This has not, this has been worked on literally just before this call, this live stream.

So this will be out in the next release, hopefully. 

What’s Coming Next

Steve: Well, that leads us to teasing new updates. Yeah. So that’ll be a small fix out [01:02:00] in the next one. And so what’s upcoming for the Accessibility Checker after this? In the last live stream, we talked about scanning our archive pages and we may be on track to get that out in the next, or the the one after that.

William: I think the next release depended on code review. 

Steve: Yeah. Yeah. 

Which is next Tuesday. So William’s got a lot of work to do before that, but that is he’s right. That’s a feature that needs some heavy testing to ensure that it’s implemented correctly. So that’s look for that coming soon. Email reports is a feature that we have gone through the scoping phase on, and at least from a technical standpoint.

There’s, of course when you’re starting to create email reports, there’s gonna be a design piece to that too, but, what we’re looking at doing is we’re looking at setting up the plugin to allow you to connect to my.equalizedigital.com, which is [01:03:00] our dashboard where you can manage your plugin licenses and any courses that you’ve purchased from us, and it can all be managed there.

But what we’re looking at doing is making a way for the plugin, even the free plugin, to connect to my.equalizedigital .com to be able to pull in your issue counts and to be able to start sending you email reports on the status of your accessibility on your website.

Anything to add to that, William?

William: I think this is gonna be incredibly useful for anyone who runs agencies where they maybe don’t wanna log into every single website under their accounts and check them every week or every month, whatever their frequency is. And now they’re gonna actually be able to configure themselves to receive like a weekly email, a monthly email, whatever the frequency they want is.

And now they will be able to just look in their email inbox. I’m sure we all spend too much time in [01:04:00] our email inboxes. 

Steve: Yeah. 

William: But it’s still quicker getting into the email than it is to log into each site individually and keep an eye on it. And it will also help flag, if there’s a specific site that’s had an update maybe, and a plugin that has suddenly increased those numbers, you’ll be able to compare them to your previous email and then figure out, what the cause of that is.

And I have seen this on a lot of sites, is that a plugin update has changed something that is now causing a violation. And you’re gonna wanna get on top of that quickly, usually by contacting the developer of the plugin. And letting them know, because, everyone tries to be accessible, but mistakes happen.

Steve: Yeah, totally. And so I think what we’re trying to do with the Accessibility Checker is we’re trying to make it smarter and we’re trying to make it more user friendly with services outside of Accessibility Checker to get it to your email box. And this final feature that we wanna tease is a way to open up the Accessibility Checker to a lot of different [01:05:00] services.

And this is with an issues API and this is something that, that we started earlier this year that William has been working on. And do you wanna speak? 

William: I’ve been working on this back and forth, so we were building an external integration of our own, and as such required an API to access the data, a fully robust API.

We don’t wanna just vaguely grab the data. We want the API to be fully secured, fully authenticated, and also capable of getting all the data that you may imagine. So we have an initial API and a PR that, hopefully will be merged in something in the next maybe two or three releases. And it has ways of getting all the issues, getting individual issues, creating individual issues, deleting individual issues, and reading summary stats all over API calls programmatically as needed.

And this opens up lots of options like main [01:06:00] WP host can pull this information into their dashboards.

Anyone can, you can build your own integration. Maybe you want a custom report database to, you might manage 500 websites. You can build your own database, you can build your own dashboards, you can build your own reports with API. And as a developer, I like using the API if I ever delete issues.

Some of the features we’ve released, like the clear issues button, started as an API endpoint because as a developer I was make using, making use of that and no point in keeping that feature to myself.

So that was released as the button and yeah, in future the full, a full featured issues API will be available for all your stats, all of the issues, both creation, reading, and deletion. 

Steve: Yeah. Cool. So we’re very excited about the issues API and we’re very excited about all the different integrations that we will be [01:07:00] able to implement and that you will be able to implement.

William: So yeah, if anyone has any ideas of things they might want to spec out or ideas they might wanna build themselves, feel free to send them our way. Again, you can open up issues on our GitHub. You can just message us on social. Whatever. Just let us know what you plan on build, because maybe we can gear what we release towards what you need.

Steve: Yep. Well, I think that has been quite the long episode and a lot of stuff to cover and we’re excited about the features that we’ve been working on. We’re excited to get them in your hands. And like William said, feel free to give us any feedback you have. I would encourage you if you haven’t updated to the latest versions go ahead and update them.

The versions that we’ve been referencing in this episode of the Accessibility Checker free plugin is version 1.28 and 1.29. 

William: 1.29. 

Steve: So we’ve had two releases there. And then in Pro, [01:08:00] we’re looking at version 1.14 and 1.15. Something else? Got anything? 

William: I will encourage people to update the latest version and there does include some under the hood database optimizations in there for index.

And so you’re gonna wanna get that free potential performance, but especially if you’re on a shared database host or a shared hosting, you’re gonna benefit. You’re not gonna save seconds per request, but you’re gonna save seconds over a few sessions. 

Steve: Sure. Yeah. So check the, yep, check the full change log for all the fixes that were released.

We don’t necessarily talk about every little bug fix here, but reference the full change log for that. And I think that’s it. We will have another stream in two weeks. These streams are run at 2:00 PM Eastern every other week. Look for us to release the next episode two weeks [01:09:00] from today.

So I think that’s it. Thanks for joining us. William, thanks for jumping in and going through all the technical stuff with us, and we will see you all in two weeks. 

William: See you.