Changelog 003: Bye-Bye Clutter, Hello Smarter Checks

Bye-Bye Clutter, Hello Smarter Checks

Steve: [00:00:00] And we’re live. Hey William, how’s it going? 

William: Yeah, it’s going good. How you doing today? 

Steve: I’m doing well. We had a lot of rainstorms last night and dogs barking. 

William: Yeah, we’re looking at storms tomorrow maybe, but we are in the middle of a heat wave right now. It’s super hot outside. 

Steve: Yeah. So, in Scotland, what’s super hot?

William: Well, it’s 25 Celsius at my desk and I’ve got the AC on. It’s probably 28, 29 out there. 

Steve: Okay. 

William: Which in Farenheit is, 

Steve: He’s gotta switch the whole thing over. 

William: 75 at my desk right now. So, I guess like, 85, 90, I would say. 

Steve: So, 75 inside’s pretty hot. Crank up that AC, right? 

William: Comfortable. 

Steve: Yeah. So we’re trying to stream to LinkedIn for the first [00:01:00] time, and I’m refreshing the page to see if we are, and it looks like we are maybe, but we’ll have somebody on our team trying to confirm this as well.

But, it looks like everything’s live. We’ll just give it a few minutes to, for anybody that wants to join, for everything to go out.

I’m not sure about LinkedIn. It doesn’t look like we’re live, so maybe we won’t be on LinkedIn today. And all those business professionals will miss out on our live stream.

William: No, I just, I literally just heard you say that on LinkedIn. 

Steve: Oh, you did? Okay. 

William: So. It is live. 

Steve: Okay, very cool. 

William: Looks like it’s like 20, 30 seconds live, just. 

Steve: Yeah. Yeah. We have a delay. Oh, it is live. There you go. [00:02:00] Alright. Yeah, so there’s a little bit of a delay, which you know, is good, right? Maybe we can do the live censoring if… 

William: Yeah. If someone makes a mistake, but they don’t wanna see it we can just cancel it. 

Steve: Yeah. Or, we use some naughty words on the live stream, but, well, yeah. Now we got confirmation from Paola that it’s working. So, well. She says, just checked and it doesn’t look to be live, but I just checked and it does look to be live on LinkedIn, so interesting.

I think it is delayed. 

William: Yeah. 

Steve: So, all good. So, yeah, so let’s jump into it. So, today we’re doing Accessibility Checker Changelog episode three. We’ve made it three episodes, William, and that means we’re in it for the long haul now. 

William: Yeah, every two weeks. 

Steve: Every two weeks. Yep. So, this episode we’re calling Bye-bye Clutter and [00:03:00] Hello Smart Checks.

Introduction

So, what we do in this live stream is we talk about the Equalize Digital Accessibility Checker, which is a WordPress plugin that is used to scan your websites for accessibility and to help your websites become more accessible and to stay accessible. The plugin, we have a suite of plugins at this point.

We have a free plugin which is very full-featured. None of our rules are gated. And you, so you can download that today and get a lot of value out of it. We have a pro plugin with advanced features such as full-site scanning and being able to manage issues at a global level. And we have a few add-ons.

We have audit history to track your accessibility issues over time. And, we have a multi-site add-on to be able to manage the installation, the activation, and the license keys from the multi-site network level. And, finally, [00:04:00] we have an export add-on that allows you to export your issue data and your site scan data to CSV files.

So, let’s jump into it today. We’re calling it Bye-bye Clutter, Hello Smart Checks and that’s because we’ve implemented some changes. We’re exclusively talking about the free plugin today because those are the changes that went out last week. And, we made changes to how our issues show on the front-end, especially in the case where multiple issues show up and so that they don’t overlap with each other.

And, we’ve made some improvements to accessibility rules and to adding more site health notifications inside the WordPress admin to help you be sure that the Accessibility Checker is working correctly.

More Accessibility Checker Details in Site Health

So, first off, let’s jump into we added more Accessibility Checker details in the Site Health check.[00:05:00] 

So, if you don’t know, inside the WordPress admin, they have this feature nowadays called the Site Health. And, basically what it does is it can scan your website for any number of issues, right? If it can’t access the rest API, maybe it’ll give you a notification that, hey, your web, your website’s blocking the rest API, and things like that. And, it gives us the ability to hook it and add our own things.

So, let me pull up my screen and then I will show you the Site Health.

We do have confirmation from Paola that it’s working fine. So great. We are going out on LinkedIn, and X, and YouTube. Cool.

So, when you log into your website, you’re presented in the opening dashboard page.

You can move these widgets around, but it seems to always be in the top left for me. There’s a site health widget and you can see take a look at six items on [00:06:00] the site health screen. So, it’s showing me that I have some things that should be improved, some things I should look at, right? So, I can click this Site Health link, which will jump me over to the Site Health page. You can also get to it from the the menu in the left hand, the left hand of the Admin page by going to Tools and then to Site Health.

So, we’ve added three Site Health checks and one I have listed here as critical. So, now you’ll see, and we’re tagging these with accessibility to help you identify them and to not add any confusion to other people that may be tagging accessibility things.

So you can group those together. But, you can see I have a critical issue, and it says “no post types selected for accessibility checking.” So, if I toggle this open, it says, “Accessibility Checker cannot scan any content because no post types have been [00:07:00] selected without configured post types, no accessibility issues will be detected.”

So, of course, in your Accessibility Checker settings, if you haven’t selected any custom post type or if you’ve deselected all your custom post types, then the Accessibility Checker is not gonna be able to do its job. So, we create, we provide a button here to jump over and enable those. But, before I do that, let’s see what else we have under accessibility.

And, so, on the Site Health check page, I have four recommended improvements, and in there our accessibility one is “content has not been checked.” So, if I toggle this one open, it says “No post have been scanned. Run a full site scan to begin checking your content for accessibility issues.”

So, we don’t have this listed as a critical issue ’cause we don’t think it’s critical. And, really, at this point, if I go to do a full site scan and I haven’t addressed the critical issue, the full site scan’s actually gonna tell me to do the same [00:08:00] thing. Enable a custom post type so that we can scan.

So, we can also look at the past test. And, if I go down, we have one here in the past test.

Currently it’s “No accessibility issues detected.” If I toggle that open, it says “Accessibility Checker has not found any issues in the scanned content.” So, on the surface, the way things are set up now, “Oh great, I don’t have any accessibility issues.” But, this is only because we haven’t scanned anything.

So, let’s go back and let’s address these issues and see how the Site Health changes based on our reconfiguration. So, if I scroll back up to the the critical issues here and I click on “Configure Post Types” and it’ll jump me over to the Settings Page and I can see, of course, I don’t have any custom post types checked.

So, I’ll check “Page,” I want to scan pages, and then I’ll hit [00:09:00] “Save Changes.”

Okay. So, now if I go back to Tools and then I go to Site Health, now that Site Health critical issue is gone and it’s no longer showing. You can, if I toggle open Passed Tests, you can see now that “Post types are configured for accessibility checking.” That it is now passing.

But, we still need to run a full site scan. If I go to the Recommended Improvements under Accessibility Content has not been checked. So, now if I toggle that open and I go to Start a Full Site Scan, okay, run Accessibility Checker there. So, I’m gonna run a scan. I only have, I chose Pages on purpose ’cause I know there’s not that many and our Full Site Scan won’t take that long to complete.

So, let’s let that run, and see how that changes our Site Health. [00:10:00] Alright.

And our full site scan is completed.

So if I jump back over to Site Health, so now under Recommended Improvements, I can see Accessibility Issues Detected. This was showing as passed because we haven’t scanned anything. The plugin, the has no knowledge of accessibility issues.

So, if I toggle that open, I can see that Accessibility Checker has detected 18 errors and 20 warnings. Since I have the Pro Plugin installed, I can actually click a button to go view those issues, it jumps me over to the Open Issues and then I can start addressing those here.

So, that’s a quick rundown, a simple rundown of the Site Health. Just trying to expose, throughout the WordPress Admin when [00:11:00] accessibility issues are there and trying to help you take action on those and trying to give you more context to what the plugin’s doing and what state it’s in.

So, those are our Site Health updates. You got any thoughts of wisdom on to add to that, William? 

William: No. I was a bit distracted trying to figure out what I’m dabbling next. 

Steve: That’s right. 

Clear Issues From the Front-End Highlighter

You gotta always, yeah, you gotta keep up on the show notes and get ready for your turn. So, the next feature that we’ve added is, we’ve added the ability to clear issues on a Post. Oh, sorry. The ability to clear issues on a Post or Page from the Front-End Highlighter.

So, if you’ve used the plugin before, I mean, it’s probably been a year or so ago, we did add a feature into the Admin, that Post Edit Page, to be able [00:12:00] to clear issues.

And, William, can you speak to a little bit why we initially added that in the Admin and because, on its face it seems like not a great idea to add a clear issues button, but can you speak to that a little bit?

William: Yes. So, we initially added this button because some users had ended up in some stuck issues in the reports on the individual page by changing their Post Type of the individual Post that was being viewed. So, at the time, our plugin didn’t differentiate or didn’t filter out based on the actual Post Type.

So, if someone changed their Post Type, they would have all issues displayed on the single page, but when they update, they wouldn’t actually be cleared out as no longer existing because the Post Type mismatch. So, that was the original intention of the cleared issues button.

It also is a very useful debugging tool to make sure that [00:13:00] when an issue is cleared or discovered that it doesn’t either reoccur or, accidentally get missed on a Rescanned.

Steve: Yeah. 

William: So, yeah, for me it’s a nice debugging tool, but it did solve a bug that no longer is an issue, but was for a while. 

Steve: Right. So we, in episode two of Accessibility Checker Changelog, we released a feature and we talked about a feature, and it was called a Cleanup Process. So, we now have a cleanup process inside the plugin that runs through and will automatically check for issues that are no longer connected to a Post Type that have become orphaned in some way. And, the clear button before, if your issues had become orphaned, you could actually hit that Clear Button, and it would un-orphan those issues and allow you to Rescan the Post.

So, so that feature, [00:14:00] the Automatic Cleanup does address that and help fix that issue. But, , like William said, the Clear Issues Button, I think internally we use it a lot for debug and we find it a valuable tool.

Now, there is the potential for abuse, right? Like you could clear your issues. So, if you ran a post and you got all these issues, you could just hit Clear and then leave the page and the issues are gone. The next time somebody opens that page to edit it the checker will automatically scan and find those issues again. But, there is a small potential for abuse, and I think that you just have to be mindful of that. If you clear those issues, be sure to either refresh the Edit Page or to hit the Save button so it rescans.

So, I’ll pull that up and show you. So, this was the Admin button. So, if I click this, it’ll it’ll pop up an alert and, ask me, “Do I really want to clear these issues?” And I hit Okay. And then, you can see [00:15:00] all the stats go green because there are no issues.

Issues still exist. So, let’s go ahead and resave the page. And, this just gives us some assurance that what we currently have is a hundred percent correct. Now, of course, saving the page actually does the same exact thing. It actually clears the issues and rescans.

But, let’s jump over to the front end and take a look at how this looks like in the Front-End Highlighter. So if I open the Details Tab and then I toggle Open an Issue and I hit View on Page, you can see the Front-End Highlighter pops up and now at the bottom you can see as of the last, the previous release we added a Rescan button.

And, we thought since we’ve added a Rescan button here, we should add a Clear Issues button so you can do both right from the front end.

So, [00:16:00] I have a Clear Issues button. If I go ahead and click the Clear Issues button, I get the same alert that pops up and asks me if I really want to do this in case somebody accidentally hits this button they have a way out. So, now the issues have been cleared. It gives me feedback, and so now I can hit the Rescan This Page button and it’ll say “Scanning,” and then I can see my issues again.

So, I think I showed in the last episode too, a way that I’ve used this a little bit is I actually will inspect an element in the inspector and actually modify the element on the page to test if a change will actually work before actually implementing it on the code side. And these Rescan buttons and these Clear Issue buttons help me to actually rescan that modified element on the page that actually really isn’t [00:17:00] modified, but it’s just a debugging thing for me for a developer to be able to do.

William: Yeah. So, something I have tried is on front end page builders as well, let’s the produce folder that you edit the content in line. Like, let’s say Beaver Builder for example, which is an entirely front end builder, or can be if you actually edit your content rather than saving the content, you can click that Rescan button right there and then, whereas previously with the builder like Beaver Builder, you would need to save the content and then visit the Editor Page in the backend to get an updated list of issues. That no longer will be the case.

This Rescan This Page button rescans the currently rendered version, so, prior to saving. And, currently it does also save those issues when you click that button. Which is something that I have an issue in back of my mind of making it an optional save, whether you wanna rescan and save, or whether you just wanna rescan the current content. Which I think will be [00:18:00] useful for other page builders that, as you’re building your page you might wanna check it and rather not actually save those issues. You just wanna see them.

Steve: Right. Yeah, we’ve had some talk about that in regards to the Front-End Highlighter and in regards to Full Site Scanner. We’re looking at adding features into the Full Site Scanner that actually allows you to make, to pass arguments through. When I say arguments, I mean like you can choose which Custom Post Types, which Post Status, maybe a Date Range, actually get scanned from the Full Site Scanner.

And the reason why we haven’t implemented that yet, is because we need to be mindful about how we do that because, our plugin is trying to get a holistic view of the accessibility throughout the website and if you run a Full Site Scan and you modify the query and the arguments that get passed into what Posts and Pages get scanned, it could skew the overall Accessibility [00:19:00] Reports of the page. So, we’ve had some talk maybe in regards to that, in regards to the Full Site Scan of some sort of snapshot and it’s not a hard issue, but it’s a snapshot issue that you’ve taken to be able to do some kind of debugging or, some edge case out there. So. That is the clear. 

Rescan Button

William: Actually, before we move on, there is another feature that exists or doesn’t exist because of Clear Issues one, but can be demoed if you wanna pull that back up again and just clear the issues from the page.

Steve: Yeah. 

William: Okay. So, this page now effectively has no issues. If you reload it, you see how the scanner has automatically opened and then there we go. 

Steve: Yeah. 

William: Just rescanned right away. So, if you clear the issues, next time someone opens that panel on a page, it will [00:20:00] automatically rescan. Which means that people who use exclusively Front-End Page Builders will be able to get their results.

Not, maybe not instantly, but they will be able to get them for every single page, regardless of whether they visit the editor in the backend or not. Which is becoming more and more common. People would never visit the admin for their page edits. 

Steve: Yeah and that pattern or that process that William just described is actually mirrors what, how the backend works, right?

You can clear the issues, but when if you refresh the page, it will rescan. And, so, it works the same in the backend.

And yeah, if you are using a page builder that’s dynamically updating things in real time, you can hit the Rescan at any time to see your current results and get feedback real quick.

So, that is the Rescan button. William, the next one I wanted you to [00:21:00] demo. I have it up on my screen right now, which I just noticed. Do you want me? 

William: Yeah, you could demo that. I did actually. That’s what I was faffing around. I had to find the post that exhibited this, but, I do have it up. 

Icon Stacking in the Front-End Highlighter

Steve: Okay, okay. So, the next feature that we released is what we’re talking about with this episode about clutter. We’re trying to simplify the layout of things on the front end and actually make it easier for you to identify issues.

So, we fixed the icon stacking in the Front-End Highlighter when there are multiple issues on the same element.

So, you want? 

William: Yes. 

Steve: You wanna describe how that previously worked? 

William: So, in the past. So, yeah, let me open this here. So, in the past, if this, like, if this had two distinct issues, I would click this link, but I wouldn’t be able to click on the second one. The second one would be behind it, and I would have to use the Previous and Next buttons to get to it. They would be stacked on top of each other if this save element had multiple issues.[00:22:00] 

Whereas if we look at the item below, so the first one, Ambiguous Anchor Text it, it’s just called “Link.” That is correct, and it’s an Improper Use of Link. So, if we inspect this, we will see it fails because it has that as the anchor and no wrong. So, this link here has two individual issues, and now they’re nicely stacked side by side.

So, you can individually click on those issues, whereas previously they would be on top of each other. You wouldn’t be able to get to them. You would need to click the Next button. And it just so happens because I’ve cleared the issues, they’ve been discovered back to back.

But sometimes, that isn’t the case. Sometimes issues are discovered out of order. So, you know, number eight and number seven are right next to each other. But, in some pages, number seven and number 16 might be these issues. So, as you click through them, it would be [00:23:00] jarring pulling you up and down and back and forth. So, now you can just see them side by side. No longer stacked.

Steve: Right, and the reason why Williams are on the left side of the page is probably because those are probably HTML Blocks, aren’t they? 

William: They are HTML Blocks. Yeah. 

Steve: Yeah. 

William: So yeah, we can see it here as well. So, Text is Too Small and it’s underlined text.

Steve: Yeah. So, a pretty simple feature, but actually it goes a long way to organize the Front-End Highlighter icons and not make it so cluttered or confusing. I even know that like sometimes I would look at those and I’d be like, “Oh, there’s only one issue here.” And then, I’d start tapping ’em through and like, “Wait, there’s like, there’s two or three issues on.” And they’re just overlaid on top of each other and whoever, you know from a indexing z indexing, whoever gets their first, gets the, yeah, whoever gets their last actually is the one on top.

So, you trying to pull up a another one? 

William: Yeah. [00:24:00] So, this one here specifically, but it isn’t this one, but there is sometimes you have an issue or a set of issues that are, yeah, this one doesn’t have to.

But sometimes you might have a list of items and you might have, these are test posts, so these are supposed to pass and supposed to fail.

That’s not correct here because 

Steve: Yeah. 

William: This in my local, but sometimes, why these two are failing? Why is this one here not failing? And, previously that could be a stacking issue because of the wrapper. But… 

Steve: Yeah. 

William: I guess I’m not explaining that very well, but it is very useful that it is side by side now. 

Steve: Well, a common issue. Yeah, a common issue is when, you know you have multiple issues regarding one HTML Element. But, like, a lot of times where we’d see this and that, like right there, that’s a perfect example.

So, this is like an icon. It’s like this is in the page pagination, it’s like a previous [00:25:00] icon and there’s two issues and the icon is really small. So, and this actually moves them, separates ’em a little bit so that you can actually initiate both of them. Social Icons is normally where you see this a lot. Where you have like five social icons that are just, real close together, and then it’s just it looks like a mess, and the icons are all overlapping each other.

So you’re trying a third one here? Yeah. See, that’s an interesting one too, ’cause there’s…

William: Here is like the exact problem that I was just describing. Whereby this is an outer element and actually does technically overlay this inner elements first issue. 

Steve: And are those in order?

William: They are in order because I’ve just rescanned this page to show it. 

Steve: Oh, okay. Yeah. Yeah. 

William: They would’ve been discovered out of order because the theme has changed. 

Steve: Right. 

William: Yeah. So, this is actually the error [00:26:00] element that wraps all of these in all of the pagination and this one, this is what it was previously like everything. But now, you know they are stacked side by side.

I know. I’m not sure, I’m not sure on a very good use case of this ’cause it’s still broken in some situations, but I have an idea how to fix that as well. 

Steve: Yeah, because it’s evaluating the position based on the element itself and not on its children or its parent issue.

William: Yeah. Yeah. I mean previously I wouldn’t be able to access this. This is the second issue for these two warnings. 

Steve: Right. 

William: So, I can access this separately now because this one sticks out, but previously, they wouldn’t. 

Steve: So. Yeah. And so on the page I had up, you can see it as well, like these are nicely stacked right next to each other. They’re not overlapping. So, I can actually see that there are two issues here. Where before it would look like there was only one until you started paging through these. And same with this “Learn More” link [00:27:00] and, there’s another “Learn More” link down here because it’s Ambiguous and it’s an Improper Use of a Link.

So, that is another small feature that we think goes a long way to helping expose all the issues on the page and to make things more readable and decluttering the Front-End Highlighter.

Cool.

Improved: Missing Transcript Detection

So, the next feature that we have here is we improved the missing transcripts that they can better detect transcripts for videos in the content.

So, that’s a vague changelog entry. William, can you? 

William: Yeah. So, we have the customer reach out to us where their markup looked correct to me from the front end, from our, not the markup, but the rendered markup looked correct to me in terms of how the transcript and the video was lined up back to back.

However, when the page was [00:28:00] being scanned, we weren’t detecting the transcript existed. And the reason why is because some systems rely on a lazy load that employ actually employs two script tags for the video. So, what was actually happening is, one of them was discovering the transcript, but the second one was not discovering the transcript.

So, this role has now been updated so that it can handle when there are two iframes with videos side by side, but only one transcript that’s related to both of them.

So, I actually do have some markup which can show it when you load this into that page.

Alright, I guess I can pull it up here first.

So yeah, the issue that we were seeing is, so there’s a Figure Tag, which is where the video is contained. Here is the video, and there is a [00:29:00] transcript right here. So, this should be getting connected. The problem is that the transcript was actually connected to this iframe as opposed to this iframe. So, there was still technically one iframe that was missing the transcript. So, the rule has been updated to understand that these are technically the same thing. It isn’t the same thing here in this ’cause this is just some random generic test markup. But, yeah, this transcript belongs to whichever of these iframes is displayed.

So we can actually, if I edit this page. I can paste that. See that, and these numbers should not significantly change. Like it should not detect. Well, maybe it will. Yeah. So a video is present, but is not detected and that there is a missing transcript because it has [00:30:00] a transcript. The transcript is right here. In the H3 is the transcript.

But previously, before we made the rule change, it would detect one missing transcript because there was one transcript with two videos. So, that’s a long-winded way of saying it. Now, bare handles lazy load of YouTube videos and other providers. Specifically, this was a YouTube issue it was discovered with. 

Steve: So, this primarily revolves around lazy loading, right? 

William: Yes, lazy loading, however, I’m not talking about just lazy loading plugins. Sometimes, the browser will lazy load these. 

Steve: Yeah. 

William: Like, by default. So, it will employ a very similar parent. Perhaps not this no script duplicated parent, but like a lot of videos will automatically hate themselves for bandwidth reasons.

Right? If you might be on a slow connection, then the video [00:31:00] might not want to be instantly loaded or you are maybe scrolling through like Facebook, and Facebook doesn’t wanna show you every single video you scroll past until you interact with it. Right? Like, these are techniques that are common now and previously, the rule was not catching this, but it does now. It detects the video because there is video, but it knows the transcript is attached to both of them, right? As opposed the one. 

Steve: So, was this issue brought up internally or by a customer? 

William: So, a customer brought this issue up. We had spoken to this customer, and they explained how they were adding their transcripts.

It seemed correct to me that the mark, as I said, visually on the page, it looks correct, but the scanner still thinks slightly differently because the scanner looks at just the markup and it was being thrown off by the fact that there was two video iframes, but only one transcript. 

Steve: Yeah. Yeah. 

William: And that [00:32:00] is, technically an issue if every video you have should have a transcript, but if the videos are the same, then… 

Steve: Right.

William: One transcript is acceptable for both. Yep. 

Steve: So, yeah, we’re always trying to refine these rules. We’re always trying to make ’em smarter. We can’t always come up with every scenario ourselves. Create an, unit or just test to evaluate. A lot of times these fixes come from our own internal use on the auditing side of our company.

They utilize the plugin in the audit. So, we actually, walk the walk and we dog food our own plugin and that helps it make it a lot better.

And our customers when they reach out, so if you’re using the plugin and you’re trying to discern, “Hey, I added a transcript to this video, but the plugin still says it’s missing, like, what’s going on?” Contact our support, and we’re always very quick to fix these issues and to help improve the plugin.

And what [00:33:00] it does is it not only fixes the problem for you. All the 7,000 people that have the plugin installed, all get a net benefit from you raising that issue to us and us taking action on fixing it.

William: Yep. And whenever we have these, we do add these. This is a test suite, and we do add this test that this exact markup here should pass. And now, every time we make a change to our rules, this will be validated. “Does this pass for the rule or does it change?”

And yeah, every time we have an issue to fix the rules, we add a case for in these tests so that we can make sure that we don’t have any regressions and we make sure that the things we expect to pass and the things we expect to fail.

Steve: Yeah. Yeah. So, a more simple way of saying what William said was we add these scenarios and we validate the rules against them with every single change of the plugin. So, if any coded, [00:34:00] like if we say somebody says, ” Hey, the transcript’s not doing X, y, Z.”

Right? And we go, “Okay, well, we can fix X, Y, Z,” and we go and change another thing about the missing transcript rule and if that inadvertently breaks the missing transcript rule that we fixed previously, the one we’re talking about here, it’ll flag as an error, and actually it won’t even allow our developers to approve to get merged.

William: Yep. 

Steve: So, it’s just all in a way to make sure that we’re collecting these scenarios over time. They actually get added to our test suite. They’re actually validated with every change to the plugin just ensures that our rules continue to improve and they don’t degradate with future changes. 

William: Yeah. And that previously was a problem because we had no automated testing first. All of these rules, back in the days when all these rules were powered by PHP, so you could make changes to one of those rules and not understand that it affects a different rule. [00:35:00] And, sometimes a positive way, sometimes a negative way, but without the automated testing, we didn’t know.

At this point, I think we have 95% of all of our rules tested to almost 100% coverage. 

Steve: Yeah. 

William: And soon it will be all of our rules. We’ll have 100% test coverage. 

Steve: Yep. Cool. It’s just the way that we ensure that we’re creating the best quality rules and the most accurate rules we can.

So, that’s our rundown on new features inside the Accessibility Checker free plugin. You can find it at equalizedigital.com, or you can find it on WordPress.org. You can find it in your WordPress dashboard and search for Accessibility Checker. Install it, give these new features a try, and do that all completely free.

What’s Coming Next

Upcoming Features. So, we’ve been teasing a few things in the last couple episodes and we’ve been teasing adding the ability to scan archive [00:36:00] pages and we’ve been teasing a little bit about an issues API that we’ve had in the works. And, I think since we have a little bit of time here, I think what it might be good is to do our first ever Equalize Digital Accessibility Checker sneak peek.

We need an animation screen. We have some confetti. 

William: Some confetti. 

Steve: There you go. So, on the Archive Page Scanning, how’s that coming along, William? 

William: Yeah, so it’s pretty far along.

There’s a couple of edge cases, a couple of quirks still to work through, but by at large it is working. It can scan all your Taxonomies, all of your Custom Post Type Archives and it shows you the results in the various reports.

The Summary will reflect how many issues those pages have.

You will also be able to use the Front-end Highlighter to preview those issues directly on the [00:37:00] page. And, you can globally ignore issues. You can individually ignore issues. You can do almost everything you can do with normal page issues, with archive issues, with exception of being able to, edit the content. You can’t edit the contents of an Archive Page in the same way. So there are some adjustments there to be made.

If you wanna pull up my screen, I can actually quickly demo this.

So, this is my test site. I have 66 posts on this page. But, if you look in the sidebar, there is a whole load of custom taxonomies added.

There’s also this, oh, it’s this one here, this Custom Post Type, which has an Archive Page. So previously, none of this content would be able to be scanned. But, if we now go to the Fill Site Scanner and click this one, you will see 66 Posts and 10 Pages. If I click this one, it’s actually gonna [00:38:00] scan 87 items because 10 of those things are post terms from these taxonomies.

And, while this is doing its scan, I can actually show you a little bit what this looks like, in the backend. So, these are the terms. So there’s 10 technology term as a topic, as part of this taxonomy. So, if I click Edit on this, it has 8 issues, 6 warnings. And yeah, these are the errors that are present on this page.

So, an Empty Heading Tag. I can click this button here, I can actually review this. There we go. That’s the Empty Heading Tag on a Taxonomy Page. Normally, you would not be able to scan this page, you wouldn’t get issues for it, but here are all the issues. This is [00:39:00] an actual taxonomy template. 

Steve: Very cool. So, for those that don’t know, I think the Accessibility Checker is getting ready to turn five years old, I think.

Yeah. Right. And yes, which is amazing. And I will say this, that when we released the Accessibility Checker in 2020, that the archive scanning was probably issue number one. It was probably the first thing that was open was we need to add the ability to scan Custom Post Type.

William: It was actually quite difficult with the way that the plugin is set up to do its associations or not just the way the plugin’s set up, but the way WordPress is rigged up to where post ID equals the object. And archives are collections of, post IDs are listed of post IDs, but they’re not pages of themselves. They’re not posts in terms of how WordPress considers a chunk of content. [00:40:00] It’s a dynamic page. 

Steve: Yeah. 

William: It doesn’t exist in and of itself in the same way that other pages are posted, so it’s actually quite difficult to keep track of it. Yeah, it proved quite difficult. 

Steve: Well, let me ask you this, was coming to a solution the difficult part or the implementation the difficult part? 

William: Coming to the solution was quite difficult. Actually, coming up with the right idea to be able to track these and, I don’t know how much we want to talk about the actual solution.

Steve: No, we can talk about that. 

William: Until we release it, but yeah, the, the long and short is that a Custom Post Type is created, which currently is called virtual pages. 

Steve: Yeah. 

William: And we store these items here and, I have this up here. So, it’s actually using smart sampling. So, right now what it does is it takes the one finds, looks at all your terms, and it finds any a given taxonomy. The one that has the most posts, the one that has the least posts, and it will actually do the least post check twice because it’s trying to find one [00:41:00] that has zero and one has only one single post. So, we’ll try and find, it will always find at least the minimum and maximum on a page, but it is trying to find three terms from every taxonomy so that it covers the most use cases of each of those templates.

Steve: Right. But we have the ability to, so we’ve added a setting where you can toggle on 

William: Yes. 

Steve: And.

William: Toggle this one right here. On every taxonomy term, every Post Type will be checked. 

Steve: Yeah. So, if you want to ensure that you’re, if you’re trying to be a hundred percent compliant, that you’re catching all of your term pages.

And the reason why we would do sampling in this regards is to… Typically your taxonomy template page is going to be the same for every tag, right? Or whatever the taxonomy is. Right? 

William: And on a lot of sites, you might have more tags or categories than you have actual posts. So, you might have 500 categories, but only [00:42:00] 150 posts.

So, we don’t wanna scan, all of those additional pages when the results are gonna be the same. 

Steve: Yeah, and it’ll just fill up the database, and it’ll create a lot of noise for you. But, we wanted to be able to give you the ability to thoroughly scan everything if you so choose, but we’re just not doing it by default out of the box.

William: Yeah. So, I actually think I can probably demo that. So, both of these are Tag Type. If I look at the seven and seven, seven and seven, right? ,So the page has the issues. It doesn’t matter which tag it is, they’re the same. They’re the same set of issues across both of those terms. So, if you were scanning every one of your tags and you had a thousand tags, this isn’t useful to know that a thousand pages have these exact issues. But, maybe it is, but I don’t think it really is to wanna fix them. 

But, you can come in [00:43:00] here, you can check this box, save it, and if we visit the Full Site Scanner, you’ll see that this number’s actually higher now. It’s gonna scan a hundred pages, which it will scan every single term I have in all of those taxonomies.

So, if you take a look at this page now. Yeah. 24 rather than the 11, I think that was previously here. 

Steve: Yeah. So, if I could jump back a little bit when we talked about coming up with a solution for this. So, the reason why this feature hasn’t been implemented for a long time is because it was highly complex because the pattern in which Archive Pages are generated is much different than the pattern in which a Post or a Page is generated in WordPress.

So, a Post or a Page really isn’t generated. It actually exists, and it’s something in a database that we can grab and, we can loop over. An Archive Page is not something that necessarily exists. It’s more something that is generated [00:44:00] on the fly.

Then this is really the difficult part in application development, or product development, plugin development, whatever you wanna call it. Is when you’ve baked in kind of a pattern of how your plugin works, and then you have something that doesn’t fit into that pattern. You have to then start thinking, “How do I achieve this without breaking all the backwards compatibility?” So backwards compatibility of the plugin or actually having, what we were facing was probably a massive refactor of the way that we scan the whole website to be able to…

William: So, for me, primarily my concern was data storage. 

Steve: Yeah. 

William: How we were gonna store a new shape or a new pattern of data?

So, what I’m pulling up right now. This is how our data is sort. This is our General Custom Table and an Issue ID is always attached to Post ID, who has a Type and… 

Steve: Yeah.

William: A Site ID.

Right? So these three pieces of [00:45:00] information exist for all of our issues, but none of this information. But, aside from the Site ID, but neither of these three exist for a Taxonomy. They don’t have an ID, nor do they have a Post Type. 

Steve: Yeah. Several weeks ago or a couple months ago, I was sitting at a kid’s swim meet, on my phone. And, I don’t know if anybody has kids in swim. You know that there’s a lot of downtime between the times when your kid swims.

So, I was running through lots of scenarios on how we could achieve this and I really went through very difficult paths to get there. Even going as far as putting together some sort of elastic search where there are scans that run in the background that generate these Pages and or these records.

And then through that research, William and I’s back and forth, we came to the determination that, “Hey, WordPress provides the shape we need. Why don’t we just detect these [00:46:00] Pages and put them into a Custom Post Type?” And then we then have access to Post IDs, we have access to post meta. We have a place to show the results on the Individual Archive level rather than making you use the Open Issues Table to remediate these. It actually made things quite simple and solved a lot of things.

Now, if you’re using a Virtual Custom Post Type you have to be mindful too that, any Archive Page is going to create a record inside of the Post Table.

And since we’ve now released, our Cleanup Process, we can now hook into that. And we’re doing some work to generalize that Cleanup process. But, we can actually hook in and ensure that these Virtual Posts don’t become stale. If things change on the website, like, if somebody deletes a Taxonomy term, right?

We can,

William: Yes. 

Steve: Yeah, we can hook in and we can clean that up. Right, William? 

William: Well, we can, and that will, would be very complicated without the [00:47:00] cleanup action. But, now, we have this Cleanup Action. This can be set scheduled if someone deletes, if you just easily delete the United States, then all of this information, should be cleared almost immediately.

Well, once a day. But, we could feasibly clean up individual texts as they get deleted, but if you batch delete something, or maybe you unregister this topic’s Taxonomy. 

Steve: Yeah. 

William: We don’t, we can’t individually delete them. We don’t know you’ve unregistered them, but the cleanup routine can run, and we’ll get rid of those two.

Steve: Right. So, we’re doing everything we’re doing our best to make sure that, since we’re gonna utilize the Post Table of Sorts to help us generate these Pages. By default, we’re not gonna do everything. Although you can choose to do, you can choose to scan every single archive, and we’re gonna run Cleanup Routines to make sure we’re being mindful of what’s being added into the database.

So the way where you saw that, William, we have that [00:48:00] virtual so this is still a Beta. It’s still in works. That’s gonna be, that’s gonna be folded under the Accessibility Checker 

William: Yes. 

Steve: Page, and you’ll be able to access it under that same dropdown. 

William: Yeah. And you know what, teasing not the next feature, but a potential feature afterwards is that maybe you can just add Custom Pages, Custom Aims that you might want to scan.

Steve: Yeah. Yeah.

William: Not just Archives. 

Steve: Well, so that’s a real sneak peek.

William: May not be next week. 

Steve: Yeah. 

William: It probably won’t be next week, but there may be some. 

Steve: Well, yeah. Well, what we needed is, we needed a mechanism in which to do not your typical Post or Page. Right. And, so now we have a mechanism to do Archive Pages.

Well, I think in that process we’ve learned that, “Hey, we could probably open this up to be able to scan other things as well.” Like, and this…

William: Some like false Post Types or some sites have dynamic content, right? Like, knowledge base, for example, may not actually have an individual [00:49:00] Post for every item. And that knowledge base, it may be programmatically generating. 

Steve: Yeah. And well even Archive…

William: Other things.

Steve: Yeah. Even Admin Pages. So 

William: Yes. 

Steve: So, you can maybe Add New, and you could put in a URL to an Admin Page and then and possibly be able to get scan results on a WordPress Admin Page. Which actually has been an internal request because we audit WordPress plugins and a lot of WordPress plugins have Dashboard Pages that we need to audit as well and it would be nice to be able to alleviate some of that manual auditing with some automated auditing from the Accessibility Checker.

William: For us, as it would be nice to automatically scan all of our own pages. 

Steve: Yeah. 

William: To identify that our Posts are the same. 

Steve: Exactly. Yeah. And I think it opens up the door a little bit to be able to scan Full Site, editing template, or what do they call it? Parts [00:50:00] or, and maybe even patterns, maybe a way to run an Accessibility Check just on a pattern alone, a pattern of blocks or an Individual block at the block level, we could run scans. So this kind of opens the door to a lot of possibilities and we’re excited to get that out.

We are slated to release that possibly next week. 

William: Think next week, because it’s the end. 

Steve: So, be on the look for that feature and a full in-depth demo of that on our next live stream. So, we do have a couple other things coming that we’ve mentioned, such as email reports and issues API. I think we’re at about time. We’re gonna hold on demoing the. Oh, well. 

William: Well, we do have to hold on it ’cause I don’t have the authorization. So, but here we have a fully documented issues API. We get issues. You can create new issues. Yeah. Single issue. [00:51:00] Update an issue. Delete an issue. You can check whether you have access or I can demo this one. 

Steve: Because you don’t have access.

William: I don’t have access. I would go 401 unauthorized. One second. Maybe, I can be authorized if I can maybe fake it. 

Steve: Yeah. Yeah. So we’re working on the issues API, and this has actually been in the works all year. And we were working on a separate product that we developed this for and we thought that this would be very useful inside the plugin.

So, we thought this would be interesting release. So, you’re getting an extra special sneak peek into the upcoming issues API. 

William: Yeah, so if I click this one here’s the issues. I could update these, I could change them, paginate them however you want. So, let’s see, 69416 is that issue ID. Check on [00:52:00] down here to this. Delete one, try it out. Put that ID in. 204, which means it has successfully deleted. If I click this button again, a 404 because the issue’s not found. And if I rerun this up here, this should go away. So, 69416. Yep, it’s gone. 69415 is the next issue.

So, can ask for separate pages. And given this, should be recognizable for anyone who’s developed APIs before.

Right. So he gives you the coral example, the request URL, and these are live responses from this actual testing.

So, these are the issues, 10 of them at time, or as many as you want. 

Steve: So what’s a 

William: 500? 

Steve: So what’s a use case for having an API in the plugin? Why are we working on this?

William: Yeah, for us this is, potentially useful for us to [00:53:00] be able to build more modular interfaces. For example, the Full Site Scanned already takes advantage of the rest API and however, it does not delete issues if it doesn’t discover that maybe it could. Or maybe it can create its issues now with this Post Request, right?

So, this is going to potentially be useful for us. However, this also means that anyone can build themselves an application. So, you might use some site management software that runs offsite like MainWP. You will be able to use an integration or build your own integration now where you can get these issues right in MainWP, like you might only care about the count.

Well this is an endpoint. You can run this, you can see how many issues are on this site and on my test site, 1,630 issues exist. Right? You might wanna display that or you might wanna display how many of specific types there are. You can figure that out from [00:54:00] these basic checks and if you’ve, fix an issue, you can just delete it, right?

Like in the offsite system, if it’s like inside the iframe or something, then you might wanna do that. Or you might wanna, sneak peek to potential, another future feature you might wanna manually create issues. 

Steve: There you go. Yep. So that is the sneak peek of the issues. 

William: Sneak peek of all the things for the rest of the year.

Steve: That’s right. So, alright, well I think we’re at time. It’s been fun running through this with you, William. Like I said, grab the Accessibility Checker plugin at equalizedigital.com or on the WordPress plugin repository.

And if you already have the plugin, please update to the latest version to get the the latest features.

So well, we have these live streams every two weeks, and we would love for you to join [00:55:00] in and ask questions next time. So, please join us and we’ll talk to you then. See you’all later. Okay. Bye.