Stability, Ordering, and Issue Clarity ![rw-book-cover](https://img.youtube.com/vi/2hwdgKtM6C0/maxresdefault.jpg) Steve: All right. We're live. How's it going? William: Yeah, it's going pretty good. No complaints. Steve: No complaints. Well, that's good. William: I've got lots of complaints, but I'm coming here. Steve: Yeah. So it looks like uh, it looks like we're going out live just fine. Um. Lemme check X and make sure we're doing, we're going out there. Okay? Yeah. So second live stream of 2026. We are just plowing through 2026 already. William: Only one 12th of the way. Steve: Only one 12th. But boy, it went fast, didn't it? William: Yep, it did for sure. Steve: It did. So we have been busy working on new features for Accessibility Checker and yep. Looks like we're going out live on X. So, Cool. So, Welcome. Anybody joining now or after the fact? Uh, We do pre, we do uh, save these recordings for later so you can enjoy 'em in your, in your own time, in your own leisure. Um. This is the Accessibility Craft change log livestream uh, where we go over the latest features in the Accessibility Checker WordPress plugin, which is an automated accessibility scanning plugin to help your website become and stay accessible. We have a full suite of plugins. We have a free plugin uh, that is full featured for scanning uh, individual posts. We have a pro plugin where you can do site level scans and get more advanced uh, auditing and remediation features. And then we have a few add-ons that go along with our pro plugin. We have a audit history to track accessibility issues over time. A multi-site plugin to help uh, you uh, manage your accessibility licenses and stats and activations at the network site level of a WordPress multi-site, and we have an export add-on that allows you to export your issues to CSV, so you can import them into any uh, system you desire. So. Today we're talking about stability, ordering, and issue clarity. So it's not a huge release, but it's an important release. So we're continually, we're always trying to refine things and make things better and to um, be able to detect issues with greater accuracy and in this case, being able to surface uh, identical issues where we have historically had uh, a little bit of trouble surfacing those accurately. So the the plugin updates are in our free plugin and our pro plugin. Free uh, plugin release is version 1.37.0, and the pro release version is 1.2.0. Alright, so welcome William. William. William: Hey. Steve: Doing good? William: Yeah, doing good to there. Steve: All right. So. Let's dive in and start going through these, and William will help me describe some of the things that we've done and uh, some of these improvements. So first off, we're gonna start with issue identity, knowing when two things are the same. So historically, like I mentioned um, if you had two identical issues on the same page, Accessibility Checker would a lot of times think that they were the same and would only surface it once. And what we've and, and this is because of the way that Acce Accessibility Checker has historically worked and how it uniquely, or how it was identifying issues. And basically it was evaluating based on the, the code object that it detected as the issue on the page. And do you wanna describe why that's problematic, William? William: Yeah. So if. Pre, previously, the entire HTML fragment was the unique identifier for an individual issue, and that, you know, in some instances might be true. You might only have one skip link on a page. That's fine. You might only have one homepage logo on a page. That's also fine. But what you're likely to also have is a lot of paragraphs and. Say, for example, there's two empty paragraph tags. They will look exactly the same as far as our system processing previously would work. So only the first discovered item would be flagable. The subsequent items would be considered as the same if the, the system wouldn't know that it was the second item, and in most cases. That's fine. In some cases it's not, as I said in, in the case of empty paragraphs, but what if you also had the same broken link on a page? It would only be flagged once, and that has some cascading issues. So if you fix the link, the issue wouldn't go away. You would think you fixed it because you would see the first instance of that issue. You would be able to click the The view on page button. It would take you to it. You would fix it. The issue wouldn't go away. It would actually just highlight another issue on subsequent scans. So it would look like you're, it would effectively look like you're not doing anything. And hence the, the problem, it wasn't an issue for a long time or wasn't realized to be an issue for a long time, but it, it turns out there are some, some pretty nasty edge cases that. Yep. Make things maybe not necessarily true. Steve: Yeah, and I think where it pops up a lot of times is like in the WordPress block editor, like it's very easy to generate empty paragraph tags just by, you know, hitting a return in the wrong place and not putting any, any You know, text. And so like you could end up with empty paragraph tags and like William said, if you had like three empty paragraph tags, the plugin would say, Hey, you have an empty paragraph tag. And you would fix it and then it would say, Hey, you have an empty paragraph tags, and then you would fix the next one. Until they were resolved. William: So because that issue was so prevalent, there was some affordances added that made paragraphs technically unique. So there would be, if you had three empty paragraphs, it would be stored as three unique items. However, then they wouldn't properly be grouped in the pro plugins open issues tab, the fast track tab, because they weren't the same markup object. Because we treated the markup object as the only unique aspect when that just. Ended up just not being true. Steve: Yeah. So to that um, this has been quite some time in the making. Uh, uh, we, We started storing additional uh, selector information in the database. I, I wanna say like eight or nine months ago. William: It is been quite a while. I think most people will already have selector data stored. Steve: Yeah. So we've quietly been collecting this data in, in the database, in, in your database. We haven't been collecting it. It's in your database, on your website and William: Your website, your data, your markup. Steve: Yeah. Yeah. So when we scan a rule, we get, uh. Uh, certain artifacts that come from that scan. And of course the code object is one. And we have historically been using that as the source of truth for what's unique. And you have a selector uh, you have an ancestor. And you have an X path. And so those three uh, metrics have been, or those three artifacts of the scan have, have been added and several releases ago. So that when we did switch to this, we didn't, we didn't have to uh, you know, run an update process or um, but that being said, if for some reason somebody hasn't scanned in like nine months. We do have an update process in, in that case to actually put in a unique identifier into that selector field so that the functionality we've added will work even if you haven't re-scanned in nine months. So in making the making every like, empty paragraph, unique. So now we've switched to the selector as the unique identifier. And, And how does that make it unique, William? Why is that any different than the code object? William: Yeah, so if you wanna pull up my screen, I actually have a, an actual database from one of my test sets up that shows how this is unique. So right here we have previously how we would store paragraph tags and this markup fragment here. Signifies a less than tag, and some of these require signified greater than tags. But this is an empty P tag, and if you see this inside the curly brackets, there is a P nth-child five. So this is the fifth P tag on post ID 2616. So this is a unique selector. However, this was. Not how we originally were storing the selectors. If I scroll up to the, the top of this, you can see here this does not contain the end child value in the object. However, we have a selector over on this side and if we see your sixth, seventh, eighth child, ninth, 10th child. So these all appear on the same page and these are the unique selectors for this object. And this is quite a simple selector, the six paragraph tag on the page and we are. Fairly certain that this is a unique selector. However, sometimes the selector isn't as simple as this one. For example, this item here, which is a YouTube embedded iframe, so this selector is much longer. It has four different levels. Of, Of selector only way the iframe is them that we are targeting. But it's inside an embed wrapper from Core, which has an identifier with an embedded YouTube block, and it's inside from a plugin from called Newsletter Glue. So all of these combined together to make this unique and the reason that the selector is so long is because there probably is other iFrames on this page. That means that iFrame on its own, it's not sufficient. Um, But if we look at the item above this, this is WP dash image dash 5 7 0. This is unique on the page. This is a unique selector, and as such can be short. And with these selectors, it is far easier to identify the actual item on the page. So if we look at this, which is Rule 21 in the database, this image. Scroll back to what the object looks like. It is significantly larger. Steve: Mm-hmm. William: Some, most of the market fragments will be much larger than the the selectors now, so we will be more effective in what we have to deliver to the page to find aims. Steve: And, And more efficient to some degree in some of our queries as well. William: Correct. I think I've done some initial measurements, nothing entirely scientific, but searching by this selector is probably 15 times faster than searching by this item. Um, It is roughly the same when you're searching for a paragraph because it's a small markup fragment, but the larger the markup fragment is, the more time we're gonna save on our queries. So yeah, ultimately, we're gonna save several seconds every time we don't run a scan. Steve: Mm-hmm. William: Most likely. Steve: Yeah, so switch switching to using this selector uh, is, is a better long-term uh, solution for the plugin. And uh, it, you know, it brings a certain level of stability and consistency and issue tracking, whereas the selector is kind of, it's a kind of a known pattern on how that's generated, whereas a piece of uh, relying on market alone. Can, Can, is, can really, it could be anything. And we're not in complete control of the markup. Yeah. That's detected William: well. But if we were searching by this markup um, we, we previously did write the code that would find this markup on the page and handle the highlighting. And it was a, a rather complicated solution to, to find this and also not very performant on the front end. Whereas this selector right here can be passed into native JavaScript functions. Steve: Yep. Yep. Without any fancy parsing. Yep. William: Document dot querySelector is the the function, and this is native JavaScript. Almost everyone will have. Probably use this if they have ever written JavaScript before, and you can find this exact element with this one lane. Nothing else required. And we have, because we have made sure that this is stored as a unique selector, we know this is only gonna return one object. It's never gonna return more than one. Steve: Mm-hmm. Yeah, so I mean, the reason why this matters for accessibility is, is that we can surface and report on the overall state of the accessibility more accurately. So we're not, we're no longer grouping, like say five empty paragraphs. Together and counting it as one. We will actually now count that as five individual issues, giving you more, more of an accurate uh, assessment and accurate stats on where the accessibility of your page sits. And, William: And not to call out something that was negative about the way we were doing it previously. However, we have had at least one customer support query come in where someone was fixing an issue and getting slightly frustrated that the issue was never going away. And the reason why is because there was several of this, the same markup on the page, and they were fixing one, and the next one was the one identified. And it, it was frustrating for them. So now we are removing that as a potential issue that someone might run into. Steve: Right, right. So reducing noise and William: Correct. Steve: So it's repeated noise to, and it's putting a lot on the remediators hands to, to say they're, that they identify an issue, they fix it, and then, then it's, they're presenting with the exact issue. It's not the exact issue, but it'll actually, William: then it looks like the same issue in the back end. Unless they're using the front end entirely. They might not know that it's a different instance. Steve: Yeah, cool. So William: No longer an issue. Steve: No longer an issue. So all of your duplicate uh, uh, identical markup will now be uniquely identified by Accessibility Checker. So that was kind of the first step in improving that. And then we've taken that and we've done the second step, which is improving the front end highlighter. Uh, In regards to, uh. You know, uh, surfacing unique issues and the stability around having these selectors and the ancestor and, and XPath and improving how um, issues are identified and highlighted on the uh, front end highlighter. So I'll pull us back up, William. Um, So we added stability, selectors and DOM ordering. So before in the front end highlighter you would, when you would pull up an issue and you, we have a next and a previous button, so you can just, you know, quickly toggle through the issues on the page. It would actually go in the order in which those issues were identified and stored in the database. And um, we wanted to give a more uh, seamless and fluid experience to. Going through the, the front end of your website and, and fixing accessibility issues. So we've decided to order from the top of the DOM down. So your first issue in the dom will be the first one that's highlighted, and then so on down the page. And this helps just bring, bring a, a. Less jumpy experience to tabbing through those. 'cause if issues were identified in the top of the page and then in the bottom of the page it would lit, literally jump down to the bottom of the page and then jump back to the top of the page. So it's, it's just a way of making it more of a seamless experience and, um. in do. In doing that, we switched it to using the selector to identify these, these issues and so the targets actually end up more accurately in the right place. Um, William: at At, like I said earlier on, it is at least 15 times faster at discovering these issues on the front end, which might not matter so much for someone who has a fairly high end PC. But for someone that might have a PC that is running background tasks or doing other things it, it is actually noticeable. I didn't realize how noticeable it was until we ran the, the CPU role simulation yesterday. Steve: Mm-hmm. William: And it, it is quite a lot faster to find by selector. Steve: Yeah. Because, I mean, uh, a, a code object. Like William said, could be, I mean, it could be a thousand characters. Like, I mean, We've done a really good job of, of reducing that down to the, to the smallest uh, HTML character we can to identify the issue. But it could be a pretty big piece of code. And when you take that and then you try to parse it and generate a selector from it uh, there can be some inconsistencies. And we actually did work on, so the, the front end highlighter that. We would actually take that code object and we, we would pull out and generate a JavaScript selector from it. And what, what we've done is we've taken, and that had been refined over, over several years and it was very accurate, but this is actually more accurate than that. And not only. Using the selector isn't more accurate. It's, It's, like William said, it's way more performant to only pull, like in some of those cases it's five characters and you have a U unique identifier, whereas, you know, the code object could be quite a few, you know, like it could be a hundred characters easily. And um, and. And so the, so we had that we would build a selector before. And what we've done is we still have that functionality. And from a programmatic standpoint, what we've done is we've built a layered uh, kind of try and uh, switch case, kind of like, uh, it, it first tries to use the unique selector to find the issue on the page. And if it actually fails to do that, which. In most cases, I don't think it will. William: I have not found a fail case in the last like two weeks, right? It always finds a selector now. Steve: If that fails, then it, it would, it'll go down to the ancestor and it'll try to find it with the unique ancestor. And in the rare case that both of those actually fail to identify the issue, it will go to our, our, our legacy code object selector to try to find it. So we're doing everything we can to make the, the selection of these issues on the front end of your page as. Accurate as possible, and we can't promise a hundred percent accuracy, but I would say that it is very close to that now at finding issues on the page. William: Yeah. Well, one of the, the benefits of the selector backed discovery is an issue I've previously run into is code on the front end of a website changing what the HTML looks like. Sometimes injects data attributes for image lazy loading or you know, pre prefetch. But a lot of things are added sometimes on the page after it renders. And if you're searching for a specific issue and the markup has changed, then sometimes you're not gonna be able to find that item. Steve: Yeah. Sorry William, it looks like I dropped off. Um, William: That's fine. I was yammering away. Steve: There. There we go. And it's, we're back and cool. Looks like we switched positions, but I like you on the left. It's better. It's good. Oh, I think I can move it, but I'm afraid too. Yeah, so we, we must have an, we must have an internet uh, problem there, but yeah. Cool. William: I think we're moving on to the what, the changes to the highlighter position. Steve: Yeah. So, William: Which also we got more, significantly more accurate um, in terms of visually where it gets placed and also the order in which items are presented. Steve: Yeah. So in a previous release, William, you had worked on a feature to try to spread out, uh. targets like it, like one highlight targets so that they don't William: Yes. If there's one object, one, one markup object that had two issues, they would stack on top of each other. You wouldn't be able to individually click them with a mouse. Steve: Mm-hmm. William: And you would need to use the highlighter to. The previous and next button to find them. And before we made the recent change, they may not be in the correct order. They, They may actually be very different. They may not be side by side than the previous and next. Um, Now they are, which is, you know, a good improvement. But I did previously make an affordance that would add five plus pixels off to the side, which would allow them to be clickable as well. Um, As a side effect of that, introduce some bugs. Steve: Yeah. Yeah. William: And position and accounting. Steve: Yeah. Which, and with the adding in the unique uh, issues and reordering the DOM, the targets in the in DOM order kind of highlighted a, a little bit of a bug with that. So this is a bug that was generated with some of our, our changes, unreleased changes. And so William took kind of a fine tooth comb through that positioning and uh, reworked how the targets are po are initially positioned and how they're repainted when the page scrolls to kind of make that just a, a. A more accurate and a, a better uh, visual experience and to work with these new features that we, we introduced. So that brings us to um, some more frontend, highlighter changes we made. So disable style improvement. So we got a little bit of feedback that our disable styles does uh, some funny things every now and then and, um. the disable styles is a bit of a complex thing. I mean, In theory it's simple, so I, if you're looking on the front end highlighter and you're going through issues, you may come across an issue where the front end highlighter says it's not visible on the page, and there there can be many reasons for that. And the number one reason is typically. It's something that's hidden on the desktop view, so like a mobile menu and, and there's an accessibility issue inside of that, and it, and it says, Hey, we know this issue's not visible on the page. You can toggle off the styles and it, and if you toggle off the styles, then you can see the target and you can see the element in which uh, has the accessibility issue. So you can toggle that. It removes all the styles from the page. You basically get like a old school looking like HTML page. And um, it, you know, if you're. From the early days of the internet, like William and I, you you were used to those HTML pages. William: I kinda like it. Steve: I do too. It's a little nostalgic, but uh, William: I don't wanna jump in here though and, and say that earlier you mentioned that it was quite complicated to do this disable styles. It, It isn't actually complicated to disable them at all. You just remove them completely. Steve: But William: Re-enabling them is surprisingly complex. Steve: Yeah. Yeah. So this was most notably on websites that used like page builders or websites that had a lot of snippets or websites that had custom code added in the places throughout the page rather than, you know, like, uh, your styles and your being collected into a unified stylesheet that's enqueued in the header, which is, which is a much easier place to like pluck out and, and put back. Um, So when you were, and. And the reason why is 'cause if you have like inline styles or you have a style tag somewhere in the middle of the page um, and you have other styles that are loaded in the header and you got, maybe you could even have styles loaded in the footer who, who knows? And, And so you, you're, you're fighting a, an a cascading stylesheet, inheritance game here. So every style that's inserted has the ability to modify or uh, or inherit styles that are added further up in the page, William: Or specifically to override them if the specific LEE is exactly the same. Steve: Right? Right. So, William: So the order in which the styles are presented. Is quite important. Steve: Is important, quite important. And it's really highlighted on websites like that. And um, so we kind of reworked it a, a bit um, to where we are, you know, we're going through and we're, we're removing the styles and maybe even setting flags to where they should be. And then we're, when the the styles are re-enabled we're, we're inserting them back to where they belong. Or where they, Or where they started. I'm not sure if that's where they belong, but William: back Back to where they were. Steve: Yeah, back to where they were in the order in which they were there. And programmatically, when you're doing this, you're doing it from top down and then when you go to put 'em back, you're kind of need to reverse the order so you don't mess up that in inheritance. So, um. Like William said, simple on its face, but like complex in practice. William: Yeah, and it's not just complex because you have stylesheets to contend with. You also have inline styles and you also have inline style tags as well. And they are treated quite differently. um, Particularly in generally in the cascade, inline styles on a specific element are gonna have the highest specificality, the highest priority. All the time. And if you don't restore them back to the existing object, then that is gonna be pretty problematic because they will instantly lose all of their specificality which you know, is a thing we did see on some test sets when we were refactoring this as we've seen images that had inline sizing suddenly grow. When you reenable the styles um, quite often we see an extra space at the end of pages because margin collapse wasn't present. Steve: Yeah, so we consider this quite the improvement. Um, And, um. we, you know, we we're always trying to improve the, the product. We're always trying to take the feedback we get about the features and the plugin and, and make it better. And um, we consider this uh, quite the improvement. Um, So in regards to like, we did some like CPU throttling testing of the plugin and we were messing with these styles. We noticed that the styles would reload anytime you tried to close the uh, Accessibility Checker front end highlighter panel and in, in most ca in some cases, it only needs to actually reload those when you have styles disabled so that your page restores the normal. If your styles are not disabled, it doesn't need to do that. So, William: And it was just whenever you closed it, doing it by default, and as you said, we were doing CPU throttling and realized that low power devices. Well, we, well, I already knew this, but page CSS painting on the page is quite a expensive process in terms of CPU cycles, and most of us don't notice it day to day because, or you know, we have high power computers or whatever. But if you're on a mobile device, for example, and you have to close that box you, you're probably gonna notice a flicker because it's gonna take time to repaint every single style that was on that page. And if we don't need to do it, we just shouldn't. And you know, that is now how it works. We don't, We don't do it if we don't need to. Steve: Yeah. And likely the, in most cases we don't need to do it. Yes. So William: Exactly. We were absolutely doing it in most cases when we didn't require it, which is wasteful. Steve: Yep. William: That we don't waste those CPU cycles. Steve: So we are passing the CPU savings onto you. The Accessibility Checker users. William: Yep. Save yourself like 2 cents of electricity per month. Steve: Two per, yeah. Per lifetime. William: Yeah. It's worth it. Save the planet a little bit at a time. Steve: That's right. That's right. Um, And plus, you know, it, it, it hedges against, if that reenable styles really does have a slight issue on. On any, on a certain website, it, it hedges against not modifying the page. Like, Don't mess with the page if you don't have to. William: Correct. Steve: And uh, cool. So that was a nice little added bonus into uh, adding improvements to the disabled styles. So finally, let's move on to uh, sorting in fast track improvements. So, Along with, uh. generating unique id uh, unique objects. Um, We had to make a few updates to our um, uh, I'm skipping ahead to the fast track one here, William, but the, we had to make some updates to the fast track improvements uh, or to the fast track page so that the numbers uh, ca make more sense. When it was initially coded. It was coded under the assumption that. There, there wouldn't be William: one instance per page. Yeah, Steve: there'd be one instance of every object per page. Whereas now that that assumption is incorrect, there could be five instances, there could be 99 instances of the same code. Object on the page. Um, Do you have this up? Do you wanna show this? William: Yes. I have this up on a demo site, so um, um, maybe I should. 'cause this code object might be unreadable, right? Steve: Yeah, Yeah. Um, William: Yeah, so this is our fast track page and as we, this specific issue here is an empty paragraph. And I keep using this as a way of testing things because this is the smallest markup chunk that I can write that creates an issue. Um, But as we can see, this is on five effective pages. One failing check, which the check is. Paragraph tag, but when we open the issues panel, it says there's 15 instances of this check. Previously, this would only be able to detect one instance per page, so this number would be five for instances and five affected pages. And the title of this column was actually affected PA pages previously. However, now that there can be more than one detected markup fragment, that's the same on a page. This has been renamed to be instances and there's 15 instances of paragraph across five pages. So now this label here used to be pages, and now it is affected pages. It contains the view pages link. I click on this, it opens up a panel which has 1, 2, 3, 4. Five pages and that matches the, the affected pages here. So if we click on any one of these view on page links, it will take us to the page and highlight the first empty paragraph instance. So let's see if I click on this one, and here we go. We have a bunch of empty paragraphs, and this is the first instance of it on this page. Steve: Yeah, so previously with previous Logic, this would've showed 15 pages, which would've been a bit redundant. William: Correct. And it would've been five. So there's probably, this page here probably has five on it. This probably has one. There would be this link with the P five times if there was five instances on this page, which, you know, you don't need all of those links and, and it would read out quite nastily to screen readers as I discovered. So, Steve: Yeah. Yeah. So it just, it'd be duplicate links over and over again and add a bit of confusion. So we've kind of rolled those all up and um, tried to make this uh, logically make a little bit more sense when we're dealing with uh, duplicated uh, identical issues. Issues. Cool. So since you have your screen up, do you want to jump over to the open issue sorting? So in a previous release, we released uh, this more advanced uh, sorting when it comes to open issues. We sort by severity and then, and then by count, by count. And um, we made the ability to, to sort these columns. So if you want to see what these look like, order differently, you can, and, uh. we have since refined this a bit. Do you wanna speak to that way? William: Um, Yes. So I think the refinements we've made is by default, there is now an indicator. You can see this is by default, sorted by severity. And severity is a two tier sort, as you were just saying. Steve: Mm-hmm. William: Um, Previously there wasn't good visual indicators, so no, there is. Change these. Um, You can also just go back to the, the default sort. Mm-hmm. Yep. So that's the default Steve: actually. You, You're sorting, yeah. You're sorting by by severity. If you wanna go back to the default, we have a reset to default sorting. Because the default sorting is, is a bit custom. Right? It's, It's two tiered. Yes. William: Yes it is. So I didn't, I actually didn't notice the count was not sorted properly on severity. You only sort. Steve: So if you sort by severity individually by clicking on the, the top of the table, you can, you can support uh, you can sort just by severity without regards to the count. And, And vice versa. If you want to just see what is, what issues have the highest count, you can just click on count and get the lowest or the highest uh, count of issues to start working on. The reason we sort this uh, default sorting, I. Is we're trying to highlight to you what's the most critical issue and, and which one has the most. So like, if you're trying to, you know, improve your accessibility uh, coverage or your numbers you, you go, you click on this top one, which in this case is missing form label, and you fix these four issues and you've, you've fixed the most severe and the highest number of, of issues. It's kind of like a, what's my biggest bang for my buck? Right? Where can I most devote my time? William: But if that's, it's mostly for the critical issues though, is what's the, the most high any issue that you can solve if you are looking for most bang for your buck as far as raw numbers go, you probably are gonna want to use the, the fast track, Steve: right? ' William: cause I could fix this link here, which would be 13 pages solved, Steve: right? And you just have to fix it in one place. William: Yes, exactly. Steve: Yeah. Yeah. Well, yeah, yeah. In that instance, one place. William: Yeah. Steve: So, Yep. So those are the improvements in the latest releases. Um, We try to put out releases every two weeks and we try to move fast here and, and have a really iterative uh, development release workflow so that we can fix these things and we can get these out to you, the user as quick as possible. Um, So we are working on new things as well. Um, We can't really tease too much of it, but we are currently in, in a uh, a workflow uh, work cycle of doing some UI improvements to help um, bring Accessibility Checker more in line with, uh. some modern WordPress layouts. And uh, as you know, Williams pulled up here, our uh, current meta box. So a little tease is that we are um, we're kind of bringing this meta box kind of. Into the WordPress editor in a more, Hey don't, don't be highlighting stuff. Like Don't click on that. I William: can't click on it. It's broken. Steve: Oh, okay. I haven't, I haven't William: made the work yet. Steve: So, William's teasing here he's, he's uh, looking at the WordPress editor sidebar, and there, there appears to be something in regards to Accessibility Checker in that sidebar that I will not speak of. Here, but uh, I just wanna let uh, our users know that um, we're doing a lot of UI and UX enhancements to try to improve the experience and the layout of our meta box. And we are gonna really excited to get this out to you here in uh, in an upcoming release. Hopefully not too, too far from now. So. Well, that's our episode. Kind of a short one this time. Um, But uh, some important features, you know, having unique, being able to identify, uh. items uniquely is huge. And being able to improve the selector and the accuracy of the front end highlighter, we think is pretty huge. And uh, being able to restore those styles without issues is, seems minor, but it's, it's important. So we're always continually improving the Accessibility Checker. And we do these live streams twice a month. Um, We do it on the. First and the William: second And the fourth. Steve: Second and fourth. That's right. Second and fourth. I'm off because of January. Because like January 1st was like on a Thursday and that would've been Yeah, but William: I, I think technically it's the second and the last. Steve: Yeah. The second and the, but some William: months might have five. Steve: Yeah. Yeah. So we should be on a normal, uh. schedule for February. So, uh, Look for this live stream here in a couple weeks and we look forward to joining you and, and thanks for being with us today. See you William: see., Stability, Ordering, and Issue Clarity, YouTube, 01kjb9zk9f1n28mtksqzydxms8.