More Control, Less Friction ![rw-book-cover](https://img.youtube.com/vi/LTtkq_SH2eA/maxresdefault.jpg) All right, we are live. William, how's it going? Uh, >> it's going okay. Very itchy today. Springtime has sprung. >> Springtime has sprung. Yeah. So, springtime in Scotland. Um, not doesn't really feel like springtime over here in the Midwest of the United States so much. got kind of cold again. But >> I mean for me it just means that daffodil have started to bloom. Makes me itchy. Sneeze. >> Yeah, it hits me hard too. Those allergies will hit very hard very soon. Well, um we are just getting set up, making sure everything's going out live to everybody. And it looks like we have a >> live on YouTube. >> We are live on YouTube. We got a confirmation from our very own Equaliz Digital and our very own Amber who probably just switched her YouTube account from Equaliz back to Amber, which I do all the time, too. Uh, very cool. So, uh, this is episode number 12. William, we've made it 12 episodes. >> Can't believe it. >> So, change log 12. Uh, this is a live stream where we go through and we talk about uh changes in the accessibility checker plug-in. 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. So, uh we have a free plugin on uh you can get at our website or at wordpress.org. It's a very fullfeatured scanning plugin where you could scan individual pages and posts, but we also provide a pro plugin as well where will allow you to extend out and uh scan custom post types, run a full site scanned, and a handful of lovely add-ons. We have an audit history add-on to track your accessibility over time, a multi-sight add-on to manage your accessibility checker license and stats at the multi-sight network level, and an export add-on that allows you to export your uh 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 uh when they're doing accessibility auditing and remediation. So excited about this one. Uh these releases went out uh last week and if I'm right, the version numbers it's accessibility checker version 1.39.0. Correct. >> And in Pro, it's version 1.21.0. >> Yep. >> Oh, I got it. >> Right. >> All right. Very good. I didn't have that written down in my notes off the top of my head. Living accessibility checker daily. Got those releases stuck in my brain. Uh, cool. So, more control where it matters. Let's start with the first one here, William. Yeah. So, we have added some CSS modifier classes to our plug-in for the new window warning row. This has been I think it was requested more than once. Um, however, we yeah, we didn't action on this until just recently. Um, the 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 your window warning classes. Um, the reason this was important, it hiding 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. Um, but the other main reason is that sometimes it does break layouts in certain certain situations. An icon in a pun 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 the icon. Um the tool tip was a bit different. Um the main issue with the tool tip was in hover navigations. um when you hover over the tool tip, you're no longer within the navigation and some navigations act on that when when you leave the navigation. Sometimes they close and it's a bit of a pain. Um ideally they should handle the tool tip, but many of the navigations do not. Um I actually I do have I haven't shared my screen yet. I can share this screen. I have >> Oh, I have this. >> Do you have up? >> Is this helpful? Yeah, this is the same markup I was going to test. So if you preview this on the front site, you can actually show. >> So should we show the the classes first? So >> sure, just just a little caveat here. I am running WordPress uh 70.0 beta something. Um so I'm I'm on a unreleased version. That's why this code box looks a little different. In 7.0 you you actually can, you know, uh 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 want to walk through this, William? >> Yeah. So, in this um code section, we have a bunch of divs that contain links essentially. Um each link either has one of the modifier classes applied or does not. Um, 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. Um, so we have two modifier classes. We have edac-Nw icon. Um, and the yeah this is a pattern we follow. So eac at the beginning is equalized digital accessibility checker. This is for new window warning. And then there's the modifier at the end which is no dash icon. That there is another modifier class which is no-ash tool tip. EDAC- NWW-n tool tip. And these, you know, these handle both the two new behaviors that we talked about. Um, 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 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. Um the next link down has no icon but still has the tool tip. Um the one after that, no tool tip but has the icon. And then these last two links both have no 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 want to 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 want to have this applied everywhere inside that block. So you can do that. It's either on the link directly or on any of the pendant wrappers. >> Yeah. And I I'll note too that we did update the documentation for our opens in a new window uh fix. >> Correct. >> To include these modifier classes. If you're a current user, you can uh reference that documentation for those classes. And we're also reference those in the in the in the post that goes out in regards to this change log. But to speak a little bit about like what William was talking about in navigation menus. So like in navigation menus you can kind of with the JavaScript that's used to handle them you can have that bubble up effect of events event handling. And I'm going to preview this on our equalized digital website because this is actually something we ran into. um when when it uh when when you have the new window warning in a navigation menu, there can be a bubble of effect of those uh JavaScript events to where when the tool tip is initiated, we're doing the accessible thing and kind of trying to move focus to it. Um, and what that does, it actually triggers those other uh JavaScript uh 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 um util the 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 um because that tool tip actually doesn't exist uh exactly in the same markup. it, you know, it's a right >> that is correct. It is a globalized element. It is one tool tip that appears regardless of which link you hover and as such is external to all of the markup that lives here. >> Yeah. So, 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 pip implementation almost always has this issue. >> Yep. And you know we can't account for how every navigation menu is coded. So this is a way to kind of circumvent those issues and uh and it just puts more control where it matters back in your hands to help you control uh the output on the front end. Um cool. >> Yeah. And if anyone is listening and would like userfacing options to enable these globally, let us know. And that's something we're considering but have not yet implemented. >> Yeah. Yeah. We're also Yeah. So we're also looking at too with all of our fixes um where you can have a you can have an active state of a fix but it's not actively applied globally. Is that what you were referencing, William? Correct. >> But 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. >> Sure. >> True. >> However, what you're talking about is maybe a secret feature. >> Yeah. Secret. So like you can enable a fix but 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 just that puts that takes kind of the control piece and you know ramps it up to 11 and gives you full control on how a fix is applied. >> Yeah. But by default what we will almost always do is we will have a link with an icon and a tool tip when the fix is enabled. But we will put control of those options in users hands. >> Yep. in the not too distant future both in the the additive method and the subtractive. >> Perfect. So, moving on um putting more control back in your hands. So, in our last live stream, we went through and we previewed our new uh 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 metab box? Um, in some cases they have to use the metab box because they're not on a block enabled uh post type or post. Um, so we we wanted to and if we wanted ourselves to be able to not see the metab box if we don't have to see the metab box. And so what we've done is we've added a new setting. And this was prompted by one of our uh members of our Facebook group. So if you uh are not a member of our Facebook group, we will put a link in the show notes for this and u jump over to our Facebook group and join and you can ask us questions about the plugin and accessibility and anything in between. Um so uh we added a setting. Uh I'll pull up my screen again. And let me go to accessibility checker settings um >> accessible not locator. >> Yes. 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 or block editor metab box and with a checkbox that says show accessibility checker metab box in the block editor. So, you can enable that or disable that and and your metab box will show or hide based on that. But we went a little further, right, William? >> Yes. So, there is some default behavior here. Um, if you already see the metab box, you have this plug-in installed, we are not going to just immediately head it. Um, you are going to still see the metab box and you will be able to come to the settings page, toggle this in, change that so that you don't have to see the metab box in the block header if you don't want to. If you like the metbox, keep it. It's not going away. But I think most people will probably prefer the sidebar when they have the option. Um, so existing users will retain the metbox. They have to come here, toggle this in. Um, new users will have this enabled by default. So they will only see the sidebar in the block header. They will continue to see the classic metbox in classic header. Um, and if they want to restore it, they have to come to the sense and >> yeah, this will actually be disabled. Like so if you're a new user, this will actually be disabled by default. >> Correct. >> Yeah. So if you're if you download the plugin and put it on a new website, the metab box on block enabled pages will be disabled by default. But you can come here and turn it back on if that's your preference. Um if it's a classic editor page, um then then we will show you the metab box regardless of this 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. Um, I'll just edit the same post. So, in recent versions, you know, we have this separation now with the uh where the metab boxes live. Um, 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. >> I found it by accident. >> And if you click it again, it opens. I was I was always clicking this and dragging it back and forth. >> I I was trying to >> Yeah, >> that's how I discovered this feature. >> So, this is a block enabled theme. Um, you have our metab box and you have our sidebar. But if I go and deselect the uh block editor metabox setting and then refresh the page, our metab box is gone. Of course, there's still, you know, Yost SEO still has theirs here, but now it now ours is gone. And you can close that and you can just uh do your auditing and your remediating straight here from the sidebar with your content right next to it. Um and if if you know 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 um panel. Is this a is it? It's a panel. It's a panel. >> Um, to open our panel up if you're just on the regular post edit edit panel. >> So, let me test you a bit here. What if you unpin this sidebar? How do you get it back? >> Uh, uh, 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 I turn Wait, hold on. How do you unpin it? Up here. Right here. There. 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?" Well, I can I can just do this. >> You can do that. >> Yeah. >> How do you get it back in the toolbar? >> Uh, you pin it. >> You can You can also go through the menu and do this as well. Just for those that don't know, >> you click the little star. Uh, so this is just a little sidebar that, you know, if you don't know about sidebars in the block editor, you can actually, you know, choose which ones you want to see. Like I can get rid of Yost SEO from here. I thought I could. Hold on. >> You have to go through the settings to turn it off. The quickest way is to click the star icon. >> Oh yeah, that's right. See, this is a UX problem. >> It is. >> So I can, you know, I can get rid of Yos. I can get rid of our accessibility checker, but we, you know, we've kind of gone that extra mile to make sure it's always here for you in case you forget or, you know, you don't know to go to the ellipsies menu. So cool. Um, so that's kind of a simple feature that had a little bit of thought to it and, um, 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 a customer. All right. 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 um that William worked on. You want to explain this? >> This was an issue that came up many times actually. So a lot of websites have specific pages. So the first and the problem at the forefront here was some sites have log 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 h happen to hit that page in the full 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 want to 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 um a filter. You pass any post ID you want to skip in the full set scanner, restart the scan, that post will get skipped. Um and when I say skipped, I mean it will not be scanned at all in the full set 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 high layer. 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. Yeah. So let's let's do a little show and tell. Well, you did the tell. Let's do the show. So um like 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 uh troubleshooting uh when there are uh scan uh issues with scanning certain pages. So right now it's a filter. Um we have doc we've documented this in our documentation correctly. >> The documentation article for this one is yet to be published but >> okay so we will be updating our documentation. >> Oh no as Dan corrected it is published. So >> perfect. >> You can find this in our docs. >> Yeah >> with basically this exact example. >> Right. So, it's just a a simple filter to filter in uh post ids on the ones that you you don't want to be scanned. So, you can see here I'm I've actually created a little utility plugin of and um the only thing that exists inside this plugin is the filter itself. So it's just edact p for pro underscoreexclude\_post ids and then uh we catch we uh catch the excludes ID and we pass in our ids. This can be an array of ids. Uh right now I only have one ID here. >> So I will say this must be an array of ids if you want it to actually exclude a post. It cannot be a string ID. Um, 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 actual an array of integer numbers for the post ID. >> Right. So, let's see what this looks like when I go to um a a fullsight scan. So, William did uh actually give the user feedback in the UI when they have excluded IDs. Um, so now when you go to uh accessibility checker fullsight scan, there's a a check summary and this is going to show you, you know, what's going to be scanned. You know, I got 644 posts to be checked. 11 pages will be checked. archive pages will not be checked because I don't have that enabled. And now we have this new uh 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 kind of letting you know, hey, you've you've done this. And we did this uh one to so you have assurance that it's it's it's working. And two, if you forget to remove it for some reason, like if I if I have this uh this post and you know I actually do want to scan if I have this plugin, this custom little plugin and I do actually want to scan this page because I've resolved why it wasn't scanning. Um you know, this will be like, oh, I need to disable that plugin and then I can I can scan and it goes away. Um, I will also call out here that the numbers above this that say how many posts or pages to be scanned does reflect the excluded post post ids. So if you were to remove this filler, I believe that number of pages goes up by one. >> Okay. So I'll disable the utility plugin. >> It may be a post. I can't remember what that ID is, but these numbers should go up by one. >> It was a page >> and that is the same number. So I >> is it? >> I think it is. Let me take a note of that. >> Activate. >> Do you have to reinitiate? >> You shouldn't have to reinitiate the scan. That's >> that that's I've not I've broken that somehow in >> you can definitely see that. Um when I disable the plugin the you can the filter message goes away. And then if I reenable it, it it it returns. So So William will make a note to update this count uh the way he described it. >> Anything else on uh excluding post IDs from the full site scan? >> Um nothing else on this one. Do you have a broken page to show someone though? >> Because we do have a feature on this page. I'd have to Yeah. Yeah. We will get to that. That's under a different section. But so we Yeah, we do have um a new a new fullsight scanning feature that William is so excited to talk about that he's trying to jump ahead. But we're going to hold off and we're going to go make >> sense to talk about it here. >> I know. Um, >> let's talk about your stuff, the UX. >> Well, we could do it. Let's let's jump down. So, we could jump into our pro uh scaling and accessibility scanning. So, since we're talking about the full site scanner, uh let's let's talk about a couple of improvements we've made. Um while while I grab the little code snippet we have to generate a uh >> broken page >> a failed scan why don't you explain some of the performance improvements that went into this release? >> Yes. So the full site scanner we have in this is really quite quy 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. um 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 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 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. >> Yeah. I mean performance improvements on things like uh you know a scanner of sorts like this definitely will net the greatest benefits at scale, right? >> Yes. that the bigger your site, the quicker that quidy 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 might be seven times faster due to those previous improvements. But on a small site, it 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 second. Yeah. Yeah. Um, 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. And >> sneeze. >> So, we are on camera. William, do not pick your nose. Um so um that is just a little performance improvement and we continue are always trying to do performance improvements to the fullsight scanner. I I think it it it I can't underestimate how advanced this full-sight 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, and to make it handle any kind of edge case we run into because we run into a lot of them when we're scanning real websites, right? >> Yeah. I also think it's real nice that we have this change log where we can tell people about those changes because that change is entirely invisible. Users would just I users that couldn't start their scan easily before we'll 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 mediumsized and they didn't need this improvement, but they got it anyway. >> Yep. Totally cool. So, let's move on to the next goodie and uh that is um 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 page failed page scan is? Anyway, >> so there are usually three different scenarios where a page might fail to scan. The first one is the page just fails to load. Times out. There's some issue with that. Um, the other issue might be there's a lot of JavaScript headers on the page. It breaks our scanner because of one of those errors. We can't scan the page. Um the third issue is um you know there's potentially 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 that. The most common reason is the page doesn't load quick enough. But there is a fware 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. >> And and a page timeout in in the sense that you're speaking is not uh like a server timeout. This is our own imposed timeout. Right. >> 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 infinitely blocked on a page that might never hit its load event. And for anyone who's a developer, they'll 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 going to see. >> Right? So we take those failures and I put those in quotes um and we collect them and we hold them and then we expose them to you at at the end of your scan. Um or the scan will refresh on an interval so they may pop up before the end of the scan. Um, and we expose those to you so you can you can troubleshoot uh 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 will it scans and then the the failure goes away. Was that a new feature that it goes away? >> That is a new feature. Previously, the list would be static and saved until you start a fresh scan. Now, if you successfully scan the page, either through the front end highlighter or by visiting in the editor, once it successfully scans, it will be removed from the fails list. >> Yeah. Cool. So, I have a little code snippet that William wrote here. This will actually just hit the uh the uh the endpoint here and trigger a fail. >> You have to run this whale in the middle of the scan. >> Oh, it has to be running. Okay. Okay. Hold on. Let me run accessibility. Okay. So, so we are running a scan and I've got quite a few post. So, uh >> this is going to take a while, but you don't need to wait till the scan completes. You can fail this post now and reload this page. >> Okay, cool. So I will trigger the script. >> Oh, what happened? I can't read that. >> It for 40 or three for forbidden. >> Um, is the URL correct there? I I can't read it. You'll need to read it out. >> It should be correct. uh wp-json/acessibility-checker- version one- slash post-scan- results. >> Yeah, that is correct. Is this post ID a real post ID? >> Uh it was at one point. Let's go find this a post ID. Hold on. 12900. >> Oh, the fact that that's not a real post ID is the reason why the counts didn't update. Oh, well, let's test that. That's a good catch. So, I'm going to Okay, there we go. I got the failure. It returned back a success in the console log. So, now I'm going to refresh. So, now I have a failure on an actual existing post ID. So, these are 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 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. You can open this up. And this has been here for a long time, but we have updated this now. So >> 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. Um the clear all button will wipe all of these failures in one go. The individual action will clear just one post as you go. Um we 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. So there's 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 want to pick any one of these clear buttons and just click them, it will go away. Issue gone. And if you refresh the page, the accordion won't show again. It is resolved. And you can't see it cuz you're zoomed in, but there was an admin notification that appears and it gets read out by the screen reader. >> Yeah. Let me uh let me grab that snippet again because I want to show that post that post ID was 12900. Um all right. So now I have the failure again. So, one cool feature, like I said, a lot of times when the page fails in the fullsight scan, it it could be that your the scanner is running too fast and for for it's running too fast for your server resources. And we do have a setting where you can slow that down to prevent these. And um but what I found is if you just go to the p page, it'll scan it. So if I if I open up this post ID, it automatically scans and then then if I refresh that now clears out that issue whereas before it it persisted. >> So so I can kind of in real time fix some of my failures while the scan's running. Um >> um that list does stay present once the scan completes. So you can work through that list after the scan as well. >> Right. >> And it is almost always going to scan when you visit the page in the editor. >> Yep. So let me stop this scan real quick. And we're going to jump all the way back and we're going to go back to the uh excluding ids for just a moment to um to check and see if the the count is actually function functioning correctly when an 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 12900, which is an a real post ID, I go back to fullsight scan. And I refresh. Oh, got to 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 went down. >> I was worried there for a second. >> Yeah. No, you did good. >> Works as intended. Maybe as an additional verification layer, I should verify that these IDs do exist prior to showing them. >> Cool. So that's the fullsight scanner. Uh all the lovely improvements. And uh next we've added a new fix. So if you're not aware already, accessibility checker comes with a a whole uh list of fixes that you can use to uh programmatically fix accessibility issues on your website uh with with one click or you know two or three. It depends. But um so uh you can see all of our fixes here on this page. I'll zoom in a little bit. Um, so we've got several fixes to do uh 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 uh query. So, the way that this works out of the box, and this is actually quite a quite interesting one, and this is this is a fix that's also in Joe Dawson's uh WP accessibility plugin, and um you know, we we pulled this over uh because I think there was actually a client need for this um the clients that was already using our plug-in, but wanted to actually use this as well. And um so we pulled it over, made some modifications, we submitted the modifications back to Joe's plugin so that both plugins now are have parody of sorts and are improved. So let me take a look at a search page. So if I go to search, so if you don't know, you can just throw, you know, in a query parameter and search for for something, you know, like you know, tests. I write test in this website a million times. I'll get a bunch of posts. So, and when I actually pass through a value on that query parameter, I get the posts that I I should get. But what happens by default in WordPress is that if you pass in an empty value uh you know you get search results for and it says not you know it's just blank and then uh I think it returns >> it returns effectively everything. The reason this number is different to the number in the back end 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 this is an interesting generally unseen accessibility issue for people with any kind of um cognitive disabilities >> where this doesn't really make any sense. >> And, you know, 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. >> Yeah. For somebody that can't see what's going on. Yeah. Yeah. >> Um because essentially you're passing nothing but you're getting a bunch of results. And so it's like why? So um now we can force uh force an error on empty search results by toggling this uh 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 post 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 a search box for you to search a different keyword. So, this just cleans it up a little bit. It gives context to to to what's going on. Like, if nothing is sent over, then nothing should be shown. I I also think this is one of these fixes that has no it has no negative that this should just be how core behaves core. >> Um I actually 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 but I mean it's also in the free plugin but this is an easy win. >> Yep. Totally. So, that is our new fix. We're always uh thinking about and pro prototyping new fixes that we have coming down the line. And we're doing everything we can to not just surf service surface accessibility issues in your website, but also be there to to help you fix those right away and to make your website accessibility and to make those issue counts go down. Um, cool. So, the next thing is if you were in our last live stream or watched our last live stream after the fact, uh we did kind of a big UI update on the the sidebar, which we spoke about a minute ago. Um so, we have a new sidebar, but that new sidebar comes with a new UI. We updated our metab box, which I think I have disabled right now. 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 could dovetail into WordPress a little more seamlessly and to kind of just modernize the look of accessibility checker because accessibility checker is is five years old and when you're five years old, it's time to start thinking about how you look and update update updating your your appearance. So >> I must have missed that one when I turned five. >> That's right. Uh so so we we changed it to sidebar and then we kind of mirrored that over to the metab box inside the free plugin. And what we've done in this update is we've taken that a step further and started translating the termin ter terminology and the UI um elements into the rest of the the pro plugin. Um so let's take a look at that. The the first place where you notice it is on if you're running uh accessibility checker pro. Um, actually this is in free too, but uh 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. U we actually adhere, we decided to inherit the uh the users color palette settings. Um, and in WordPress 7.0, it's this this bright blue. Um, but you can change it if it doesn't meet color contrast. It's kind of on you as a user because you can change this to something that does have contrast. >> I actually got a screenshot from a customer on support who had the red theme on. It was interesting to see the full sight scan >> with the red. >> Yeah. Yeah. I'll I'll demo that just for fun here in a minute. But um 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. You know, we don't think we don't call things errors anymore. We call them problems. We don't call them warnings anymore. We call uh issues that need need review. And um and we we've just kind of cleaned up the UI a bit here. um and and using core buttons instead of our own buttons and adding, you know, uh opens some new window indicators um throughout this. So, this is just kind of a a design cleanup and uh um just to bring it in alignment with the free plugin. The next place is the welcome screen. So, the welcome screen, we uh kind of brought over the same thing. We removed the the heavy background colors and brought in our iconography and our terminology and and kind of the the same color into the the welcome page. Uh, I I don't think there's anything major on here other than just a design change and some, you know, some button changes, a few layout, just kind of padding things to clean this up a little bit on the welcome page. And then you'll notice as you go through uh open issues, you'll see uh uh we've brought in the new icons on the the initial open issues page that shows all of the issues on the website. Um 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, um, this kind of remains the same. If you go into an issue, uh, we've kind of just brought that over as well, the same kind of iconography and terminology and updated those throughout the interface and tried not to be obtrusive or modify this too much with this first pass. So um in the sidebar it doesn't 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 them if you have confirmed they are in fact not issues. And then global ignores is now global dismissals. And uh so just updating all of that kind of terminology throughout the the plugin. If I go to the fullsight scanner, which we've been looking at already for quite some time on this uh live stream, but there a lot changed here, but it doesn't look like a lot changed here because we were using um kind of our really own out of the box buttons and things like that. And we we have removed stripped out those custom button styles in favor of just adopting what what what core what's in core the core button styles. And uh this will be more apparent too once WordPress uh 70 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 a scan, you know, 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 you know, of course, if you got a lot of pages, it doesn't look like it the bar is loading very fast, but I wanted to give the impression that it's doing something because it is doing something like if you know if I inspect the page and I go to the network tab, you can you can see that our scan scanner is doing something. Um, you can I mean you can tell it's very active. It's pulling up a page. It's scanning it, sending the results back. It's clo it's closing that and redoing that over and over again. Um, so we I wanted to add these stripes in um what they call them candy stripes I think. >> I think so. And uh I wanted to give a little bit of movement to show kind of hey even though the bar only goes uh you know horizontally every scan every page scan completion uh that also to give some movement in between those those movements that hey it's doing something and it kind of just looks kind of fun. But to what William was saying about um the the the color palette. So I don't know you want me to go to to like a really ugly one. >> Any of these is quite different. The one I seen was this one. The red one. Sun. >> Sunshine. So now if you need in the editor if you need to have a certain level of color contrast I would probably stick with the default. But um so I've switched the the theme. If I refresh the page then our our scanner adopts you know whatever you've chosen as as your uh profile color the everything changes. And we're just doing what we can to make the the plug-in kind of fit in with with the core a little more. And you can see it here. You can see it on the >> uh dashboard. Like it brings in in the the theme colors. So I >> I think I might be in the minority of users here, but I actually like my plugins to look like WordPress. Um, a lot of plugins try and look quite different and if it's quite obtuse to me when I'm browsing the dashboard that things look all kinds of different ways depending on what page you're on. So, I I really like this change. Everything in our plug-in should look like WordPress because it is inside WordPress. That's something I believe. Not every plug-in believes it, but now we do. >> Yeah. Yeah. So, I prefer the default theme and the default theme is changing um with WordPress 7.0. So, it looks a little bit different. Um is the current one fresh? Is that what the current one is? >> Yes, the Well, it's called default I think in 6.9. Um it's been renamed to fresh in >> and 7.0. >> There's a new default. Yeah. >> Yeah. So if I go back to the the default then here there we go. So that is some of the UI stuff that we have gone through and cleaned up. In doing that uh you know anytime you go into software and you start messing with things you start finding other things. We updated um you know these labels here are translatable now. Like you find things that weren't translated and and you fix the accessibility on them and you fix the translat make them translatable. And we found several areas throughout the plug-in um and that that we did uh translation improvements on. And you know, we have our plug-in translated into 32 languages, something like that. >> I think it's 35 now. >> Oh, is it up to 35? And um we're con, you know, continually making improvements to uh make sure everything is uh as translatable as possible. So, and uh we made we did some accessibility fixes as far as UI in the settings panel. We did find um a couple orphaned labels and we went through and uh 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 plug-in and fixing them. Um so I think that's kind of the UI uh improvements that we've done. Uh I think we have one last thing to talk about, William. It's kind of our smarter detection >> and updates to our missing transcript. >> Yeah. So the 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 a transcript or any link that might be to a transcript to tell you this there's a video on this page. It doesn't have a transcript. It is a AAA requirement to provide transcripts for video. It is it double A no it is a AAA requirement. Um so it is a needs warning in our plug-in um or needs review so that it 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. um 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 the specific format of Beaver Builder video inputs. Um it could be I think it was four levels away in terms of DOM depth which our check just was considering too far and as such we actually increased the limit. So it will 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 as we recently found is actually really quite close visually in certain builders. Beaver Builder was where we discovered this at first but I did also figure out that this is a problem in certain element 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 BeaverBuilder may have ran into this and we didn't know because we we'd never tested that specific format of connecting the video with the transcript. >> Yeah. So it's pesky page builders, right? Yeah, we get a bit better every time. So reports an issue, we fix it. >> Actually just this morning fixed an issue with cadence >> in the a pro fix for the adding file type and size. Um cadence also has a similar issue where the link is too far away from the content if it's an overlay link. So >> that'll also be fixed in the next release hopefully. >> Yeah. So that's, you know, 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 a whole world of uh page builders and themes and things like that that we don't always have at our disposal. >> And a lot of these page builders change so frequently that >> you know this this issue with the ad fail or this BeaverBuilder issue might not have existed a year ago. And it does now and it should be resolved forever hopefully. Fingers crossed. But >> yeah, >> wait and see if Before change how they output their video. I am hopeful they change it so that you can have your transcripts closer in the DOM. >> Yeah, we will see. >> Cool. Well, I mean, that's just, you know, that's how we're that I think all these things sum up how we're uh 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 um the procanning functionality and performance improvements that we've made in these releases. And it just kind of 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. Well, we're a few minutes over, but we can go as long as we want. Do we want to tease what's next? >> Um, do you have anything ready to tease? >> I I don't want to show it, but do we want to talk about it? >> Yeah. Well, yeah, we can. I mean, I don't know what one you're talking about because we have quite a number of things. >> That's right. We got a lot of things in the so we are uh we have teased this before and you know I want to bring it up again because it's you know it's kind of the the thing that we're working on pushing through but our email 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 uh u generating email reports because we now uh will have a connection between accessibility checker and the e the my.equalized website. If you're not familiar with what my.agalizeddigital.com is, it's our dashboard for any of our customers that have uh either downloaded a free accessibility checker plug plugin um or one of our premium plugins, bought a course, um affiliates. So, we have a dashboard. So, our email reports were are going to let you uh attach your free or your paid plugin. If you're have a paid plugin, it's already attached to the dashboard. Um but we now will let free customers attach and to the dashboard and then it will get uh it will get audit summaries and then it will process those and send them to you and right into your inbox and show you uh any improvement or regression in your accessibility uh from week to week. I'm looking forward to getting this feature out. >> I don't want to say done. I think there's still some work some improvements there, but I would love to get this actually released. And this is a really big change. The the ability for free plug-in users to connect to my do get, you know, get the email reports is 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. You know, we're not just building these things for the people that pay us. We're building them for everyone. That's that's the point. Accessibility is for all users. >> Man, couldn't have said better myself, William. >> I think I'm going to need to write that one down. >> That's right. Write it down. That's a tweetable moment right there. Yeah, >> we still call them tweets. That's a postable moment right there. >> So, no, perfectly. Very well said. And I think that sums it all up. And I think with that, we're going to call this a uh we're going to call this into our live stream. We thank anybody that watches uh here live with us or anybody watching later to go check out accessibility checker free. Uh if you like it already uh or if you like it after using it, please give us a fivestar review on WordPress.org. We appreciate it and uh we appreciate your support and we look forward to uh bringing new features to you in the next live stream. See you. Back., More Control, Less Friction, YouTube, 01kmv7x3ayw1xy1c5qhkkc9718.