Changelog 012: More Control, Less Friction

Steve: [00:00:00] All right. We are live. William, how’s it going? 

William: It’s going okay. Good. Very good day today. Springtime has sprung. 

Steve: Springtime has sprung. Yeah. So springtime in Scotland. Doesn’t really feel like springtime over here in the Midwest of the United States. So much got cold again, but 

William: For me it just means that daffodils have started to bloom. Makes me itchy. Sneeze. 

Steve: Yeah, it hits me hard too. Those allergies will hit very hard very soon. We are just getting set up, making sure everything’s going out live to everybody. And it looks like we…

William: We are live on YouTube. 

Steve: We are live on YouTube. We got a confirmation from our very own Equalize Digital [00:01:00] and our very own Amber, who probably just switched her YouTube account from Equalize back to Amber, which I do all the time too.

Very cool. This is episode number 12, William. We’ve made it 12 episodes. 

William: Can’t believe it. 

Steve: So changelog 12. This is a where we go through and we talk about changes in the Accessibility Checker plugin.

For anybody that is not aware, the Accessibility Checker plugin is an automated accessibility scanning plugin to help your WordPress website become and stay accessible.

We have a free plugin on you can get at our website or at WordPress.org. It’s a very full featured scanning plugin where you could scan individual pages and posts. But we also provide a Pro [00:02:00] Plugin as well, where we’ll allow you to extend out and scan custom post types, run a full site scan, and a handful of lovely add-ons.

We have an Audit History Add-on to track your accessibility over time. A Multi-site Add-on to manage your Accessibility Checker license and stats at the multi-site network level. And an Export add-on that allows you to export your accessibility issues to a CSV file.

So today’s theme is more control, less friction.

This release is really about removing the little points of friction that slow people down when they’re doing accessibility auditing and remediation. Excited about this one. These releases went out last week and if I’m right, the version numbers, it’s Accessibility Checker version 1.39.0.[00:03:00] 

William: Correct. 

Steve: And in pro it’s version 1.21.0. 

William: Yep. 

Steve: Oh, I got it 

William: Right. 

Steve: Alright, very good. I didn’t have that written down in my notes. Off the top of my head. Live in Accessibility Checker Daily. Got those releases stuck in my brain. Cool.

More control where it matters. Let’s start with the first one here, William.

CSS modifier classes for New Window Warning

William: Yeah.

We have added some CSS Modifier classes to our plugin for the new window warning rule.

This has been, I think it was requested more than once. However, we, yeah we didn’t action on this until just recently. The modifier classes do two specific things. The first one is it hides the visible label and it prevents the tool tip from being displayed. Those are now options that you can apply to your window, the warning [00:04:00] classes.

The reason this was important, either of them, was important for two different reasons. The icon, first off, sometimes people just don’t like it. That’s one of the reasons. But the other main reason is that sometimes it does break layouts in certain situations. An icon appearing might break a line or something like that. So that can be quite complicated for people to just bulk apply the fix to their website and make sure everything looks just fine. So now there is modifier class to not output the icon.

The tool tip was a bit different. The main issue with the tool tip was in hover navigations. When you hover over the tool tip, you’re no longer within the navigation and some navigations act on that. When you leave the navigation, sometimes they close and it’s a bit of a pain. Ideally they should handle tool tip button. Many of the navigations do not. I actually, I do have, I haven’t shared my screen yet. I can share this screen. I have… 

Steve: Oh, I have this. 

William: Do you have that? 

Steve: Is [00:05:00] this helpful? 

William: Yeah, this is the same markup I was gonna test. So if you preview this on the front site, you can actually show. 

Steve: So should we show the classes first?

William: Sure. 

Steve: Just a little caveat here. I am running WordPress 7.0 Beta something. So I’m on a unreleased version, that’s why this code box looks a little different. In 7.0 you actually can, have a preview and you can add CSS and JavaScript. So this looks a little different than what you may be seeing on your site.

But you wanna walk through this, William? 

William: Yeah.

So in this code section, we have a bunch of divs that contain links essentially. Each link either has one of the modifier classes applied or does not. The purpose of the wrapper div is to show that you can actually apply those modifiers to a wrapper and then it would target all of the links inside of that wrapper.

So we have two modifier classes. We have [00:06:00] edac-nww-no-icon. This is a pattern we follow. edac at the beginning is Equalize Digital Accessibility Checker. This is for new window warning. And then there’s the modifier at the end, which is no-icon.

There is another modifier class, which is no-tooltip, edac-nww-no-tooltip.

And these handle both the two new behaviors that we talked about. And as I said, you can apply this to the wrapper class or you can apply it directly to the link. It functions in both cases.

So if we have a look at the front end, we have the new window warning link. This is the default behavior at the top. So it has an icon and has a tool tip when you hover over it. The next link down has no icon, but still has the tool tip. The one after that, no tool tip, but has the icon. And then these last two links both have no [00:07:00] icon and no tool tip. One of these has the classes directly applied to the link, and one has it applied to the wrapper class.

And the reason it was important to target the wrapper class as well, is you might wanna put one of these modifier classes on an entire section on your website, such as your navigation or a hero block, a specific piece of content, you might wanna have this applied everywhere inside that block. So you can do that. It’s either on the link directly or on any of the pattern wrappers. 

Steve: Yeah. And I’ll note too, that we did update the documentation for our Opens in a New Window Fix. 

William: Correct. 

Steve: To include these modifier classes. If you’re a current user, you can reference that documentation for those classes. And we’re also reference those, in the post that goes out in regards to this changelog.

But to speak a little bit about what William was talking about in navigation menus, so like in navigation menus, you can with the [00:08:00] JavaScript that’s used to handle ’em, you can have the bubble up effect of events event handling. And I’m gonna preview this on our Equalize Digital website because this is actually something we ran into.

When you have the new window warning in the navigation menu, there can be a bubble effect of those JavaScript events to where when the tool tip is initiated, we’re doing the accessible thing and trying to move focus to it. And what that does, it actually triggers those other JavaScript handlers that will actually, they actually think you’ve gone off of the menu and then the menu just closes.

So if I add that utility class, not to show the tool tip here, now I can hover over this without the tool tip getting focus or out without the navigation menu thinking that I’ve actually hovered off of it because essentially I have because that tool tip actually doesn’t [00:09:00] exist exactly in the same markup.

Is that right William? 

William: That is correct. It is a globalized element. It is one tool tip that appears regardless of which link you hover, and as such, it is external to all of the markup that lives here. 

Steve: Yeah. 

William: It is not technically part of the navigation menu as far as the accessibility tree goes, and it does cause issues with mobile navs and probably other hover effect elements like maybe some sliders or anything else that requires your mouse to remain on the element might get thrown off by moving into a tool tip. And this isn’t just a problem with our tool tip. This is just a custom tool tip implementation almost always has this issue. 

Steve: Yep. And we can’t account for how every navigation menu is coded. So this is a way to kinda circumvent those issues.[00:10:00] 

And it just puts more control where it matters back in your hands to help you control the output on the front end.

Cool. 

William: Yeah. And if anyone is listening and would like user facing options to enable these globally, let us know. And that’s something we’re considering but have not yet implemented.

Steve: Yeah. Yeah. We’re also looking at too, with all of our fixes where you can have an active state of a fix, but it’s not actively applied globally. Is that what you were referencing, William? 

William: Correct.

I was thinking that we would expose options where they could disable the icon globally as opposed to having to use the modifier classes everywhere.

Steve: Sure. 

William: However, what you’re talking about is maybe a secret feature. 

Steve: Yeah. Secret. So like you can enable a fix but the fix doesn’t get applied globally to where you could actually use these utility classes to apply the fixes on an individual basis. So [00:11:00] just that puts, that takes the control piece and ramps it up to 11 and gives you full control on how a fix is applied.

William: Yeah. But by default, what we will almost always do is we will have a link with an icon and a tooltip when the fix is enabled, but we will put control of those options in users hands. In the not too distant future, both in the additive method and the subtractive. 

Steve: Perfect. So moving on putting more control back in your hands.

Hide Legacy Metabox in Block Editor

Steve: So in our last live stream we went through and we previewed our new block editor sidebar, and that kind of brought to rise a few questions about what should a user be using? Should they be using that new sidebar? Should they be using the legacy Metabox? In some cases they have to use the Metabox because they’re not on a block enabled post type or [00:12:00] post.

So we wanted to, and it, we wanted ourselves to be able to not see the Metabox if we don’t have to see the Metabox. So what we’ve done is we’ve added a new setting and this was prompted by one of our members of our Facebook group. So if you are not a member of our Facebook group, we will put a link in the show notes for this and jump over to our Facebook group and join, and you can ask us questions about the plugin and accessibility and anything in between.

We added a setting. I’ll pull up my screen again and let me go to Accessibility Checker settings.

William: In the Block Editor above. 

Steve: Yeah, so if you go to Accessibility Checker Settings and you go to System Settings at the very end, we’ve added a new setting called Block Editor Metabox and with a checkbox that says Show [00:13:00] Accessibility Checker Metabox in the Block Editor. So you can enable that or disable that and your Metabox will show or hide based on that.

But we went a little further William? 

William: Yes. So there is some default behavior here. If you already see the metabox, you have this plugin installed, we are not gonna just immediately hide it. You are going to still see the metabox and you will be able to come to the Settings page, toggle the setting, change that so that you don’t have to see the Metabox in the Block Editor if you don’t want to. If you like the Metabox, keep it, it’s not going away.

But I think most people will probably prefer the sidebar when they have the option. Existing users will retain the metabox. They have to come here, toggle the setting.

New users will have this enabled by default. So they will only see the sidebar in the Block Editor. They will continue to see the classic metabox in classic editor.

And if they wanna restore it, they have to come to the settings. [00:14:00] And… 

Steve: Yeah, this will actually be disabled. So if you’re a new user, this will actually be disabled by default. 

William: Correct. 

Steve: Yeah. So if you download the plugin and put it on a new website, the Metabox on block enabled pages will be disabled by default. But you can come here and turn it back on if that’s your preference.

If it’s a classic editor page then we will show you the Metabox regardless of the setting.

So let’s show it in action. So I’m going to leave it toggled on and I’ll go to a post. I’m zoomed in. Let me zoom out so it doesn’t look weird.

I’ll just edit the same post. So in recent versions, we have this separation now with the where the Metaboxes live. And a neat little trick that William taught me that I didn’t know was if you actually click on this bar with one click, it collapses. 

William: Found it by accident, 

Steve: And if you click it again, [00:15:00] it opens.

I was always clicking this and dragging it back and forth. 

William: I was trying to… 

Steve: Yeah. 

William: That’s how I discovered this feature. 

Steve: So this is a block enabled theme. You have our Metabox and you have our sidebar, but if I go and deselect the block editor Metabox setting, and then refresh the page, our Metabox is gone.

Of course, there’s still Yoast SEO still has theirs here, but now ours is gone and you can close that and you can just do your auditing and your remediating straight here from the sidebar with your content right next to it. And if the sidebar icon is how you initiate these, and sometimes it’s hard to find if you’re just on a regular post. We’ve actually added a little kind of helper panel. It’s a panel. 

William: It’s a panel. 

Steve: To open our panel [00:16:00] up if you’re just on the regular post edit panel. 

William: So let me test you a bit here. What if you unpin this sidebar? How do you get it back? 

Steve: You want to test me? So the ellipses, so if I go to the ellipses in the top toolbar and then I go to Accessibility Checker and I…

Wait, hold on. How do you unpin it up here? Right here? 

William: Yeah. 

Steve: So I unpin it. So I had to go to the sidebar. There’s a little star to unpin it. So you’re asking how do I get to it? I can just do this. 

William: You can do that. 

Steve: Yeah. 

William: I heard that you get it back in the toolbar. 

Steve: You pin it. 

William: You can also go through the menu into this as well.

Steve: You click the little star. So this is just a little sidebar that you know if you don’t know about sidebars in the block editor, you can actually, choose which ones you wanna see. I can get to Yoast SEO from here. I thought I could, hold on. Oh, there 

William: You have to go through the settings to turn it off. The quickest way is to click the star icon. [00:17:00] 

Steve: Oh yeah, that’s right. See, this is a UX problem. 

William: It is. 

Steve: So I can, I can get rid of Yoast, I can get rid of our Accessibility Checker. We’ve gone that extra mile to make sure it’s always here for you in case you forget or you don’t know to go to the ellipses menu.

Cool. So that’s a simple feature that had a little bit of thought to it and we’re glad to get that out in the release. And one release from the, from when we released the sidebar, the very next release had that setting, that was a request from a customer.

Alright, so continuing on with our theme of giving more control to the user. We have another issue that kind of came up through our support channels that that William worked on. You want to explain this one?

Exclude Post IDs from Full Scan (Pro)

William: This was an issue that came up many times actually. So a lot of websites have specific pages. So the first and [00:18:00] the problem at the forefront here was some sites have log out URLs and they are technically pages, but if you visit those pages, it logs you out. And due to the nature of the way we do our scan, we browse the website as a user would see it. And if you happen to hit that page in the fill site scanner, it logs you out and then you can’t continue subsequent scan pages.

So we needed a way to exclude specific pages for that reason. Some users have other problem pages that don’t scan because they’re filled with JavaScript issues or slow pages or any number of other reasons why a page might not wanna be scanned. There was no previous way to exclude them.

Now there is, there’s no user exposed feature for this yet. This is only done via a filter. You pass any post ID you wanna skip in the full site scanner, restart the scan, that post will get skipped. And when I say skipped, I mean it will not be scanned at all in the [00:19:00] full site scanner.

However, if you visit that page individually in the editor, you can still scan it.

You can also scan it from the front end highlighter. 

So this does not mean you won’t get results for the page, it just means it won’t be scanned in the full site scanner. 

Steve: Yeah. So let’s do a little show and tell. You did the tell. Let’s do the show.

William said, this is not currently an exposed setting, but we are planning to create a setting for this because we are finding it quite valuable for our own testing and for clients troubleshooting when there are scan issues with scanning certain pages.

So right now it’s a filter. We’ve documented this in our documentation, correct. William? 

William: The documentation article for this one is yet to be published, but… 

Steve: Okay. So we will be updating our documentation. 

William: Oh, no. As I stand corrected, it is published.

Steve: Perfect. 

William: You can find this in our [00:20:00] docs.

Steve: Yeah. 

William: Basically this exact example, 

Steve: Right. So it’s just a simple filter to filter in post IDs on the ones that you don’t want to be scanned. So you can see here. I’ve actually created a little utility plugin . And the only thing that exists inside this plugin is the filter itself.

So it’s just edacp_excluded_post_ids. And then we catch the excludes ID and we pass in our IDs. This can be an array of IDs. Right now I only have one ID here. 

William: So I will say this must be an array of IDs if you want it to actually exclude the post.

It cannot be a string ID. If you pass a string here, it does not break because there is error handling, but it won’t do what you think. So you do have to pass an actual array of integer [00:21:00] numbers for the post ID. 

Steve: So let’s see what this looks like when I go to a full site scan.

So William did actually give the user feedback in the UI when they have excluded IDs.

So now when you go to Accessibility Checker full site scan, there’s a check summary and this is going to show you what’s going to be scanned. I got 644 posts to be checked. 11 pages will be checked. Archive pages will not be checked ’cause I don’t have that enabled. And now we have this new one here. It says, one specific post ID is set to be excluded from check via the excludes filter. And then it shows the IDs of the posts that are to be excluded. So we’re kinda letting you know, “Hey you’ve done this” and we did this one to, so you have assurance that it’s working. And [00:22:00] two, if you forget to remove it for some reason, if I have this post and I actually do want to scan, if I have this plugin, this custom little plugin, and I do actually wanna scan this page ’cause I’ve resolved why it wasn’t scanning this will be like, oh, I need to disable that plugin and then I can scan and it goes away.

William: I’ll also call out here that the numbers above this, that say how many posts or pages to be scanned does reflect the excluded post IDs. So if you were to remove this filter. I believe that number of pages goes up by one. 

Steve: Okay. So I’ll disable the utility plugin. 

William: It may be a post. I can’t remember what that ID is, but these numbers should go up by one.

Steve: It was a page. 

William: And that’s the same number. So I, that 

Steve: Is it?

William: I think it is. I’ll be taking a note of that. 

Steve: Activate.

Do you have to reinitiate? 

William: [00:23:00] You shouldn’t have to reinitiate the scan. That’s, I’ve not, I’ve broken that somehow in the, 

Steve: But you can definitely see that when I disable the plug in the, you can, the filter message goes away and then if I re-enable it returns.

So William will make a note to update this count the way he described it.

Anything else on excluding post IDs from the full site scan? 

William: Nothing else on this one.

Do you have a broken page to show someone though? Because we do have another feature on this page. 

Steve: I’d have to, yeah. Yeah. We will get to that. That’s under a different section, but

so we, yeah, we do have a new full site scanning feature that William is so excited to talk about that he’s trying to jump ahead. But we’re gonna hold off and we’re gonna go…

William: It makes sense to talk about it here. 

Steve: I know.

William: Let’s talk about your stuff. The UX. 

Steve: We could do it. [00:24:00] Let’s jump down so we could jump into our pro scaling and accessibility scanning.

So since we’re talking about the full site scanner let’s talk about a couple of improvements we’ve made. While I grab the little code snippet, we have to generate a 

William: Broken page. 

Steve: A failed scan.

Performance Improvements

Steve: Why don’t you explain some of the performance improvements that went into this release?

William: Yes. The full site scanner we have in this is really quite query intensive. To get some of these numbers and to generate the list of IDs we want to scan requires us effectively looking at every post and an awful lot of the post metadata for all of those posts to generate the full list.

We were gathering that information with potentially three or four, I think it was four individual separate queries each that were resulting in very similar post ID lists.

So what I did was I made one of the queries [00:25:00] slightly more intensive to gather all of that information and once all that information is gathered, then we process it in the place where the other queries were. So we don’t need to query the database more than one time other than to do additional metadata lookups if required later on as part of the scan.

But when the scan starts it really. It should be almost three times faster at generating the ID list. And for some sites, small sites, like a site of this size, the time it takes to generate the ID list is really quite small. But for a site that might have 50,000 pages and post to scan that, that can take 15 or more seconds to perform each of those queries. So now it only takes one of those times and the rest of it is processed in PHP. 

Steve: Yeah, performance improvements on things like a scanner of sorts like this definitely will net the greatest benefits at scale, right? 

William: Yes. The bigger your site, the quicker [00:26:00] that query has become for you, or the more time you have saved.

And this is also in line with the previous performance improvements we made on very large sites. It may be seven times faster due to those previous improvements, but on a small site it isn’t directly measurable how fast those queries are. However, it is significantly more efficient even if the time doesn’t add up on a small site.

Steve: Yeah. We got a request to show our pretty little faces while we do the screen share. I didn’t realize the screen share was up by itself for so long.

So we are on camera. William, do not pick your nose.

That is just a little performance improvement and we continue, are always trying to do performance improvements to the full site scanner. I can’t underestimate how advanced this full site scanner is and how complex it is and how we are continually always working to refine it, to make it work smoother, to make it work faster [00:27:00] and to make it handle any kind of edge case we run into.

’cause we run into a lot of them when we’re scanning real websites.

William: Yeah. I also think it’s real nice that we have this changelog where we can tell people about those changes because that change is entirely invisible. Users that couldn’t start their scan easily before will be able to start their scan and they’ll be able to see a benefit.

But the majority of users actually don’t have a problem starting their scan. Their sites are small to medium sized and they didn’t need this improvement, but they got it anyway.

Failed Scan Handling Improvements

Steve: Yep. Totally. Cool. So let’s move on to the next goodie and that is being able to clear out failed scans. So I’ve got a code snippet here so we can generate a failed page scan.

So while I do this, can you explain what a Failed Page scan is anyway? 

William: So there are usually three different scenarios where the page might fail to scan. The first [00:28:00] one is the page just fails to load, times out there’s some issue with that. The other issue might be there’s a lot of JavaScript errors on the page. It breaks our scanner because of one of those errors, we can’t scan the page. The third issue is there’s potentially a redirect or something in the way of our scanner actually being run. So there is a few reasons why a page might fail to scan. The most common reason is the page doesn’t load quick enough, but there is a filter to increase that time if anyone needs it. But that is the most common reason for a scan fail is a page timeout. Because we have to load the entire page to see it the way a user would see it. 

Steve: And a page timeout in the sense that you’re speaking is not like a server timeout. This is our own imposed timeout, right? 

William: Correct.

So we will only wait 15 seconds. If the page hasn’t fully loaded in that 15 seconds, we will move on. And that is to just prevent the scan being [00:29:00] infinitely blocked on a page that might never hit his load event. And for anyone who’s a developer, the load event is a specific event in the page loading order in a browser. And that is what we trigger our scan on the load event, which is effectively when the entire page is fully rendered, as much of the things have happened on the page that would happen for a normal user. And then we scan it so that we see what users are gonna see. 

Steve: Right? So we take those failures and I put those in quotes and we collect them and we hold them, and then we expose ’em to you at the end of your scan. Or the scan will refresh on the interval, so they may pop up before the end of the scan.

And we expose those to you so you can troubleshoot why that page failed. A lot of times in my own experience, if I visit that page and just let it scan inside the editor at an individual level, it scans and then the failure goes away.

Was that a new feature? That it goes away?

William: That is a new feature. [00:30:00] Previously the list would be static and saved until you start fresh scan. Now, if you successfully scan the page, either through the front end highlighter or by visiting in the editor, once it’s successfully scans, it will be removed from the failed list. 

Steve: Yeah. Cool.

So I have a little code snippet that William wrote here.

This will actually just hit the end point here and trigger a failure. 

William: You have to run this while in the middle of the scan. 

Steve: Oh, it has to be running. Okay. Yes. Okay. Hold on. Let me run. Accessibility. Okay. So we are running a scan.

And I’ve got quite a few posts.

William: This is gonna take a while, but you don’t need to wait till the scan completes. You can fail this post now and reload this page. 

Steve: Okay, cool. So I will trigger the script. 

William: Oh, what happened? I can’t read that. 

Steve: 403 [00:31:00] Forbidden. 

William: Is the URL correct there?

I can’t read it. You’ll need to read it out. 

Steve: It should be correct. wp-json/accessibility-checker/post-scan-results. 

William: Yeah, that is correct. Is this post ID, a real post ID? 

Steve: It was at one point. Let’s go find us a post ID. Hold on. 12, 900. 

William: Oh, the fact that’s not a real post ID is the reason why the counts didn’t update.

Steve: Oh, let’s test that. That’s a good catch. So I’m gonna, okay, there we go. I got the failure. It returned back a success in the console log. So now I’m gonna refresh. So now I have a failure on an actual existing post ID. So these are sandbox sites, local sites that we use for testing. And William and I bang on these things really hard and we delete post and we [00:32:00] create posts. That’s why that post ID didn’t exist. So now I’m using an actual post ID. So I have a scan failure and you can open this up. And this has been here for a long time, but we have updated this now. 

William: Yeah. So there is three things new here. First off, you can see there’s an action button. Clear on the individual item.

There’s also a Clear All button. After the entire list the clear all button will wipe all of these failures in one go.

The individual action will clear just one post as you go.

I did also add a template column here. A customer told me that this would be quite useful for them to know whether a specific template was causing their failures or not.

There is now the template column that can be referenced. And in my experience, it is actually quite common that someone has a slow template causing a lot of these timeouts. So this helps them identify that now. And if you [00:33:00] wanna pick any one of these clear buttons and just click them, it will go away.

And if you refresh the page, the accordion won’t show again. It is resolved and you can’t see it ’cause there’s zoom in, but there was an admin notification that appears and it gets read out by the screen reader.

Steve: Yeah. Let me grab that snippet again because I want to show that post ID was 12 900. All right, so now I have the failure again. So one cool feature. Like I said, a lot of times when a page fails in the full site scan it could be that the scanners running too fast and for running too fast for your server resources. And we do have a setting where you can slow that down to prevent these.

And but what I found is if you just go to the page, it’ll scan it. So if I open up this post id, it automatically scans [00:34:00] and then if I refresh that now clears out that issue, whereas before it, it persisted. So I can in real time fix some of my failures while the scan’s running.

William: That list does stay present once the scan completes, so you can work through that list after the scan as well. 

Steve: Right. 

William: And it is almost always going to scan when you visit the page in the editor. 

Steve: Yep. So let me stop the scan real quick and we’re gonna jump all the way back and we’re gonna go back to the excluding IDs for just a moment, to check and see if the count is actually function functioning correctly, when in actual post ID is used. So we got 644 posts and 11 pages. If I open this plugin and I update this post ID to 12 900, which [00:35:00] is in a real post id, I go back to full site scan and I refresh, oh, gotta go to plugins and enable this plugin.

And now I have 643, so we’re down one. So I excluded it and the count actually went down. 

William: I was worried there for a second. 

Steve: Yeah, no, you did good. 

William: Works as intended. Maybe as an additional verification layer, I should verify that these IDs do exist prior to 

Steve: showing 

William: them. Yeah. 

Steve: Cool. So that’s the full site scanner all the lovely improvements.

New fix: Empty Search Handling

Steve: And next we’ve added a new fix. So if you’re not aware already, Accessibility Checker comes with a whole list of fixes that you can use to programmatically fix accessibility issues on your website [00:36:00] with one click, or, two or three. It depends, but, you can see all of our fixes here on this page.

I’ll zoom in a little bit. So we’ve got several fixes to do to cover a lot of areas, but we’ve added a new one. And this one is the empty search handling: force WordPress to show a search results page when a search is submitted with an empty query. So the way that this works out of the box, and this is actually a quite interesting one, and this is a fix that’s also in Joe Dolson’s WP Accessibility Plugin.

And, we pulled this over ’cause I think there was actually a client need for this. The clients that was already using our plugin, but wanted to actually use this as well. And so we pulled it over, made some modifications. We submitted the modifications back to Joe’s plugins so that both plugins now have parity of [00:37:00] sorts and are improved.

So let me take a look at a search page. So if I go to search, if you don’t know, you can just throw a query parameter and search for something. Tests. I write tests in this website a million times, so I’ll get a bunch of posts. And when I actually pass through a value on that query parameter, I get the post that I should get. But what happens by default in WordPress is that if you pass in an empty value, you get search results for, and it says not, it’s just blank. And then I think it returns… 

William: All the post it returns effectively, everything. The reason this number’s different to the number in the backend is because it actually is literally searching for no space characters.

So if there’s like an empty return space in a post or whatever, but this is an interesting generally unseen accessibility issue for people with any kind of [00:38:00] cognitive disabilities.

Where this doesn’t really make any sense. Yeah. And this really doesn’t make a lot of sense for me either, but for someone who might not fully get what’s going on here, this could be incredibly confusing.

Steve: Yeah.

For somebody that can’t see what’s going on. Yeah. 

William: Yeah. 

Steve: ‘Cause essentially you’re passing nothing, but you’re getting a bunch of results. And so it’s like, why? Now we can force an error on empty search results by toggling this setting and hitting save. So now when I go back to the site and I search for an empty string I don’t get any posts and we get a message, “Sorry, but nothing matches your search terms. Please try again with some different keywords.” So we’re forcing an error and on this theme, there’s a search box for you to search a different keyword. So this just cleans it up a little bit. It gives context to, to what’s going on. If nothing is sent over, then nothing [00:39:00] should be shown. 

William: I also think this is one of these fixes that has no negative.

That this should just be how Core behaves. 

Steve: Yeah. 

William: WordPress Core. I also think everyone can just enable this and if they have a search box on their website, they might help some users for free that this is a free fix. Nothing. It’s also in the free plugin, but this is an easy win. 

Steve: Yep, totally. So that is our new fix.

We’re always thinking about and prototyping new fixes that we have coming down the line and we’re doing everything we can to not just surface accessibility issues in your website, but also be there to help you fix those right away and to make your website accessibility and to make those issue counts go down.

Admin UI & Terminology Alignment

Steve: Cool. So the next thing is, if you were in our last live stream or watched our last live [00:40:00] stream after the fact we did a big UI update on the sidebar, which we spoke about a minute ago. So we have a new sidebar, but that new sidebar comes with a new UI. We updated our Metabox, which I think I have disabled right now.

I, let me turn it back on. Go to settings, show Metabox.

So we have our new sidebar, which our sidebar kind of pushed us to think about the UI and the user experience and what it should look like and a little bit how it can dovetail into WordPress a little more seamlessly. And to just modernize the look of Accessibility Checker, because Accessibility Checker is five years old, and when you’re five years old, it’s time to start thinking about how you look and update, updating your appearance, so 

William: I must have missed that one when I turned five. 

Steve: [00:41:00] That’s right. So we changed with the sidebar and then we mirrored that over to the Metabox inside the free plugin. And what we’ve done in this update is we’ve taken that a step further and started translating the terminology and the UI elements into the rest of the pro plugin.

So let’s take a look at that. The first place where you’re notice it is on if you’re running Accessibility Checker pro. Actually this is in free too, but there’s more UI here to look at. If you’re in pro, you get some more stats. So we’ve updated our dashboard widget. With just some of the new colors.

We actually adhered, we decided to inherit the the user’s color palette settings and in WordPress 7.0, it’s this bright blue. But you can change it if it doesn’t meet color contrast, it’s on you as a user because you can change this to [00:42:00] something that does have contrast. 

William: I actually got a screenshot from a customer on support who had the red theme on.

It was interesting to see the full site scan with the red. 

Steve: Yeah. Yeah. I’ll demo that just for fun here in a minute, but, so we updated this with some colors and just some layout changes just to, and we brought in our iconography and we brought in our new terminology. We don’t think, we don’t call things errors anymore.

We call them problems. We don’t call ’em warnings anymore. We call issues that need review and and we’ve just cleaned up the UI a bit here and using core buttons instead of our own buttons. And adding, opens a new window indicators throughout this. So this is just a design cleanup and just to bring it in alignment with the free plugin.

The next place is the welcome screen. So the welcome screen, we brought over the same thing. We removed the heavy background [00:43:00] colors and brought in our iconography and our terminology and the same color into the welcome page. I don’t think there’s anything major on here other than just a design change.

And some, some button changes, a few layout, just padding things to clean this up a little bit on the welcome page. And then you’ll notice as you go through open issues, you’ll see, we’ve brought in the new icons on the initial open issues page that shows all of the issues on the website.

And we brought in the terminology. We’ve updated the severity label here to match the modified severity label we used in the sidebar. But other than that this kind of remains the same. If you go into an issue, we’ve just brought that over as well, the same kind of iconography and terminology, and updated those throughout the interface and tried not to be [00:44:00] obtrusive or modify this too much with this first pass.

In the sidebar, you can see dismissed issues here, it doesn’t say ignored anymore. We have gone away from using the word ignore and in favor of dismiss because we don’t want you to ignore accessibility issues. You can dismiss ’em if you have confirmed they are in fact not issues. And then global ignores is now global dismissals.

And so just updating all of that kind of terminology throughout the plugin.

If I go to the full site scanner, which we’ve been looking at already for quite some time on this live stream, but there a lot changed here, but it doesn’t look like a lot changed here because we were using, our really own out of the box buttons and things like that. And we have removed, stripped out those custom button styles in favor of just adopting what core, what’s in core, the [00:45:00] core button styles. And this will be more apparent too, once WordPress 7.0 comes out here in a couple weeks.

So I’ve got a blue button here now, which is just your core button. When I start to scan, we’ve updated these buttons and kind of something I’ve been wanting to do for a while that I haven’t is our scanner will run. And of course if you’ve got a lot of pages, it doesn’t look like it. The bar’s loading very fast. But I wanted to give the impression that it’s doing something because it is doing something.

If, if I inspect the page and I go to the network tab, you can see that our scanner’s doing something, you can, you can tell it’s very active. It’s pulling up a page, it’s scanning, it’s sending the results back. It’s closing that and redoing that over and over again.

So we, I wanted to add these stripes in what they call ’em candy stripes, I think. 

William: I think so. 

Steve: And I wanted to give a little bit of movement to [00:46:00] show hey, even though the bar only goes horizontally every scan, every page scan completion that also to give some movement in between those movements that, hey, it’s doing something and it just looks fun.

But to what William was saying about the color palette, so I don’t you want me to go to, to a really ugly one? 

William: Any of these is quite different. The one I seen was this one, the red one.

Steve: Sunshine. In the editor, if you need to have a certain level of color contrast, I would probably stick with the default.

But so I’ve switched the theme. If I refresh the page, then our scanner adopts, whatever you’ve chosen as your profile color, the everything changes and we’re just doing what we can to make the plugin fit in with the core a little more. And you can see it here, you can see it on the dashboard, like it brings [00:47:00] in the theme colors.

So 

William: I think I might be in the minority of users here, but I actually like my plugins to look like WordPress. A lot of plugins try and look quite different, and if it’s quite obtuse to me when I’m frozen. Dashboards that things look all kinds of different ways depending on what page you’re on. So I really like this change.

Everything in our plugin should look like WordPress because it is inside WordPress. That’s something I believe. Not every plugin believes it, but now we do. Yeah. 

Steve: Yeah. So I prefer the default theme. And the default theme is changing with WordPress 7.0. So it looks a little bit different.

Is the current one fresh?

Is that what the current one is? 

William: Yes, they it’s called default, I think in 6.9. It’s been renamed to Fresh in 

Steve: and 

William: 7.0. 

Steve: There’s a new [00:48:00] default. Yeah. Yeah. So if I go back to the default then here we go.

More Translatable Strings (AJAX)

Steve: That is some of the UI stuff that we have gone through and cleaned up. In doing that anytime you go into software and you start messing with things, you start finding other things.

We updated these labels here are translatable now. Like you find things that weren’t translated and you fix the accessibility on ’em and you fix the translated, make them translatable. And we found several areas throughout the plugin that we did translation improvements on, and we have our plugin translated into 32 languages, something like that.

William: I think it’s 35 now. 

Steve: Oh, is it Up to 35. And we’re continually making improvements to make sure everything is as translatable as possible.

Settings: Orphaned Labels & Help Link Fixes

Steve: And we made, we did some accessibility fixes as far as UI in [00:49:00] the Settings Panel. We did find a couple orphaned labels and we went through and fixed those and attached those to the proper setting so that they read out properly for screen readers.

And this is just us practicing what we preach, finding accessibility issues in our own plugin and fixing them. So I think that’s the UI improvements that we’ve done.

Missing Transcript Detection (Enhanced)

Steve: I think we have one last thing to talk about, William. It’s our smarter detection 

William: Yeah. 

Steve: And updates to our missing transcript.

William: Yeah. So the Missing Transcript check we have loosely the way it works is it searches around about a video to try and find any reference to transcript or any link that might be to a transcript to tell you there’s a video on this page. It doesn’t have a transcript. It is a requirement to provide transcripts for video.

It is a AA… no, it is a AAA [00:50:00] requirement. So it is a needs warning in our plugin or “Needs Review” so users look to check for it. And previously we have made a lot of enhancements to that rule over time about how it detects the transcripts. But something that interesting came in recently is we look for nearby words to say that there’s a transcript and nearby is relative. It could be visually very close, but in the content of the page, the HTML markup actually be relatively quite far away. And that is what we discovered with a specific format of Beaver Builder video inputs. It could be, I think it was four levels away in terms of dom depth, which earth check just was considered too far. And as such, we actually increased the limit. So we’ll now look five levels of Dom depth away to try and find the transcript, which is really quite far in terms of the dom, but [00:51:00] as we recently found this actually really quite close visually in certain builders.

Beaver Builder was where we discovered this at first, but they’d also figure out that this is a problem in certain Elementor permutations of videos as well.

So now the missing transcript video will search further to try and discover the transcript before it determines it’s just too far away. And that does fix a specific support issue for one customer. But I presume anyone who used Beaver Builder may have ran into this and we didn’t know, right? Because we’d never tested that specific format of connecting the video with the transcript.

Steve: Yeah. So it’s pesky page builders, right? 

William: Yeah. We get a bit better every time. Yeah. Some reports an issue. We fix it actually just this morning fixed an issue with Kadence and the a pro fix for the adding file type and size. Kadence [00:52:00] also has a similar issue where the link is too far away from the content if it’s an overlay link, so 

Yeah. That’ll also be fixed in the next release, hopefully. 

Steve: Yeah. So that’s, we’re always trying to improve the rules and it, and our users give us, giving us feedback, helps us have context and helps us test a whole world of page builders and themes and things like that, that we don’t always have at our disposal.

William: And a lot of these page builders change so frequently. Yeah. That, this issue with the file or this Beaver Builder issue might not have existed a year ago, and it does now and it should be resolved forever, hopefully. Fingers crossed. But 

Steve: yeah, 

William: wait and see if Beaver Builder change how they output their video.

I am hopeful they change it so that you can have your transcripts closer in the dom. We will see. 

Steve: Cool. That’s just, that’s how we’re [00:53:00] that, I think all these things sum up how we’re trying to give you more control where it matters. And we’re giving you the UI fixes and visual improvements, these smarter detection, which we just talked about, and the pro scanning functionality and performance improvements that we’ve made and these releases.

And it just it’s just us trying to improve our software to make it as usable and helpful to our users as possible. We have a few minutes left. We’re a few minutes over, but we can go as long as we want.

What’s Next

Steve: Do we wanna tease what’s next? 

William: Do you have anything ready to tease. 

Steve: I don’t wanna show it, but do we want to talk about it?

William: Yeah, we, yeah, we can. I don’t know what one you’re talking about. ’cause we have quite a number of things in pipeline. 

Steve: That’s right. We got a lot of things in the, so we are we have teased this before and, I’m, I wanna bring it up again because it’s, it’s the thing that we’re working on pushing through.

But our Email [00:54:00] Reports will be launching very soon, hopefully next release, or maybe the one after, depending on how we do this. There’s some complexities around generating email reports because we now we will have a connection between Accessibility Checker and the my.EqualizeDigital website. If you’re not familiar with what my.EqualizeDigital.com is, it’s our dashboard for any of our customers that have either downloaded a free Accessibility Checker plugin or one of our premium plugins bought a course, affiliates, so we have a dashboard, so our email reports were, are gonna let you attach your free or your paid plugin if you’re, you have a paid plugin, it’s already attached to the dashboard. But we now we’ll let free customers attach and to the dashboard and then it will get, it will get audit summaries and then it will [00:55:00] process those and send them to you and right into your inbox and show you any improvement or regression in your accessibility from week to week.

William: I am looking forward to getting this feature at out. Yes. I don’t wanna say done. I think there’s still some more, some improvements there, but I would love to get this actually released. And this is a really big change. The ability for free plugin users to connect to my dot, get the email reports is a big, it’s a really big change.

Previously only paid customers would have any functionality inside of the dashboard. Free customers will too. That’s a huge leap forward. We’re not just building these things for the people that pay us. We’re building them for everyone. That’s the point. Accessibility is for all users. 

Steve: Man.

Couldn’t have said better myself, William. I think 

William: I’m gonna need to write that one down. [00:56:00] 

Steve: That’s right. Write it down. That’s a tweetable moment right there. Yeah, but we still call ’em tweets. That’s a postable moment right there. Yeah. No, perfectly very well said. And I think that sums it all up. And I think with that, we’re gonna call this an end our live stream.

We thank anybody that watches here live with us or anybody watching later to go check out Accessibility Checker Free. If you like it already or if you like it after using it, please give us a five star review on WordPress.org. We appreciate it and we appreciate your support and we look forward to bringing new features to you in the next live stream.

See ya. 

William: Bye.