2025 Year in Review  All right, we are live. Hey, >> how's it going, William? >> Yeah, going good. >> Last one of the year. >> Last one of the year. We made it. All right. Looks like we are live on YouTube. uh check out X and see if we're live there as well. And it looks like we are live. All right, I'm going to I'm going to repost this. We're live. Today we are talking about the year in review. We made it, William. It's December. How do you feel? >> Tired. >> Tired. >> It's been a long year. >> Long year of long year of feature updates on the accessibility checker. >> Yeah. Feature updates and you know, a bunch of other things. >> Yeah. >> Nonaccessibility checker things. >> Non life raising children. >> Yeah. Just pretend that doesn't happen. That's probably the hardest part of everyone's life. >> Yeah. Yeah. Cool. Well, it looks like everything's going out. So, yeah. So, welcome to the live stream. If anybody's joining or watching after the fact, uh we appreciate it. Um we are going to take a little bit of a uh look back. You know, it's kind of like those old sitcoms, right? Where they would have that episode that was like the flashback episode, >> the filler episode, >> the what I mean. Yeah, the filler episode. Don't call us out. It's not a filler episode. This episode is going to be packed with all kinds of helpful information about accessibility checker and what we did this year and and kind of uh the the uh struggles, a little bit of the uh how the sausage is made for the year. Um but yeah, so this is going to be our flashback episode, our our greatest hits of the year. So, well, we're glad that you're you're joining. If if you're not aware, we we have this uh live stream every couple weeks and we talk about new features and uh thing upcoming features and changes to the accessibility checker. And this is intended to be a little bit of a technical uh deep dive, but also a little bit of an informative uh live stream for users of accessibility checker or potential users of accessibility checker. Accessibility checker is a WordPress plug-in that is an automated accessibility uh scanner to help you identify uh accessibility issues on your website and fix those accessibility issues. So, what do you think, William? We jump right into the year and review. So, I >> Yeah, >> I thought we would start with kind of the the big hitters, right? Like some of the major things we did this year. So, it wasn't just um it wasn't just fixing bugs, squashing bugs, and creating new features and accessibility checker. actually released two new plugins this year. Uh do you want to talk about the first one? >> Yeah, so the first plugin we released this year was the multi-sight plugin. It allows users to basically have full control over how their licenses get applied across a multi network. Um some users might have you know five site license but a network that contains seven sites. they get to prioritize which site get those license and you know when I say five sites that might not be that may not be so troublesome to visit each site individually and apply your license but when we're talking about license sizes that reach you know 50 licenses people are not going to want to manually go to all of those sites. So primary reason for this plugin is management of the licenses. Um as a side benefit all the things that are required to rig up to manage licenses also allows you to see all of the errors and warnings across the entire network as well. So in addition to managing your licenses, you can also see the current stats of all of these sites in the network. Um you don't need to have the license activated on all of these sites to get stats. Obviously, we have the free plugin that runs completely without a license and has full scan, all the same rules, all bu. So, all of the site stats will be available to see in this plug-in in addition to managing the license. Um, and while you're managing the license, you're also if you have if you have the professional single site license, you get the plugin, the pro plugin, but on higher tiers, you get access to some of these add-ons. And we, you know, again, all the things that were required to be rigged up to manage the licenses meant that we could also manage all of these add-ons all from this one single page. >> Yeah. And uh that is a great explanation. Also settings. Did you mention settings about >> I did not mention settings. So why would you configure 50 different sites when you can just come here, configure one, and then clone your settings across all of them? >> Yeah. Yeah. >> So this is probably I haven't actually used this feature myself. I think this probably saved a few people many many hours of time. >> Yeah. Yeah. Yeah. So you can basically you can choose a uh a network default site any site on your WordPress multi-ite as the default. We have a a drop down to choose which site and then you can select the other sites and then you can choose copy settings from the default site and you apply that. It's actually going to set take all the settings take the settings from that one master site and and copy it to all the the other subsites. So yeah, so this is a very uh uh very awesome plugin for people managing large networks for agencies and this is an add-on plugin to that uh to the agency customer level plan for accessibility checker. >> So users with what 20 licenses >> Yeah. Yeah. Yeah. Yeah. So >> you're not going to want to visit 20 individual sites in a network, >> right? And a little bit of a teaser for like things to come. We we have had some internal talks about bringing some of this uh being able to export and import settings uh to the uh accessibility checker pro plugin um for people that are setting up large networks of sites that are not inside of a multi-sight install. So trying to bring that feature to our our our premium pro plugin as well. Cool. So that's multicide. Anything else on that? >> Um I don't think so. I think this covers all the features. It doesn't have a lot of features of its own. It just takes advantage of features of, you know, all of the individual network sites. >> Yeah. Yeah. Totally. And we released this plugin early in the year. We actually started it uh I think late last year and then of course we went through development and by the time we got everything ready to launch it was it was the new year. I think we launched this in January. >> Wow. That long ago. >> Yeah. So any any of our current agency uh license holders uh if you haven't tried it and you're running a multi-sight uh give it a try. Um, so the next big feature, so we mentioned this in our last live stream. So we'll kind of just touch on it here and not go too deep, but the uh the next plugin we released is actually not an an accessibility checker add-on. Sure, it's complimentary to accessibility checker because it's kind of accessibility adjacent. Um, is the archive WP plugin. This is a premium only standalone plugin that doesn't require accessibility checker. Um, and it is a a plugin to help you manage outdated content while maintaining accessibility accessibility compliance. Um, so has a lot of features in it like where you can you can take your post and migrate them to a a custom post type called archived content and um it'll store all the metadata all it'll migrate the terms to a a new taxonomy so that you can have frontend views to filter those. It'll automatically assign uh 301 redirects. Um, you can act you can revert these changes as well. If you migrate a post and you realize that, oh, I shouldn't have done that. You can actually restore that to its original location. And by location, I mean its original custom post type and its taxonomies will be restored to their original location as long as those taxonomies uh still exist. Um, but not only is it utilitarian in that in that way that it gives you this tool to migrate between these custom post types, it also comes with a full set of blocks and patterns to help you help you create the front-end page. So, we have three blocks in there uh uh for for the uh there's a disclaimer. So, this is for accessibility compliance labeling your content as archived content. Um, and just a little side note on that and the reason why you would want to archive content from an accessibility standpoint is uh a lot of a lot of u a lot of laws and regulations around accessibility will allow for an exclusion of archived content. So if you label content as archived and you don't update it after that fact um that it can be considered archived content and and it may be excluded from certain accessibility requirements. Um so we've got these blocks. So we got a disclaimer block uh in there. We've got a uh a filters block which holds all the the filters. So you can filter by the custom post type. You can filter by the original custom post type. You can filter by the uh migrated terms and uh you can filter by a search keyword search and and then there's a third block uh which is actually the loop output which is a dynamic it's it's dynamic you know um dynamically loaded content that loads uh your loop and it loads it real fast and it refreshes without a page refresh and um and then we've taken those blocks and we've given you a couple patterns as well so that you can apply this directly to a page with just one click of a button. You've got this pattern for like a left align layout or a right align layout and or a actually we remove the right align layout. Sorry, the left align layout and the center align layout um because it really doesn't make sense to put filters on the right hand side and it causes some weird you know flow issues for >> index. Yeah. Yeah, totally. And uh so the the archive WP plugin is is a fullfeatured plugin to help you manage archived content. And we worked really hard on this in October. Uh William and I were uh just are getting carpal tunnel from all the typing or all the prompting. >> I think you did an awful lot of prompting on this one. By the day I came in, I had to clean up some of that prompt work. >> Well, you know, that's an interesting take, right? So, we've uh kind of the history of accessibility checker is that, you know, accessibility checker is getting ready to turn five years old. So, next year, accessibility checker will go to kindergarten. Um, we've raised um and and five years ago, you know, AI was not part of our development workflows. Not at all. I mean it it didn't exist. Open AAI may have just been a a comp a recently founded company at that time. Um, so you know, we used to write every line of code by hand and uh nowadays we've got a lot of AI implemented in our workflows and I think the archive WP was probably the first big plug-in that we uh tried to implement that to to its fullest with without going down the the road of vibe coding which you're not going to you're never going to get uh to >> I don't see people making viable products. No. >> Yeah. With five coin. Maybe maybe next year. >> Yeah. Yeah. Yeah. >> So, we call it what do we call it? We call it pain prompting. Is that what we call it? >> I think it was a bit painful sometimes. Although, to be fair, the AI >> built a lot of things that might have been quite complicated for a human. >> Yeah. >> In this in this plug-in and it did require cleanup. I don't think the AI is quite at the point where it writes fully production ready code. someone is still going to have to follow behind. you know, where it's it's kind of interesting like with the archive WP plugin how uh the the AI would lead to discovery in some sense where you would you would you would kind of ask you use the ask feature to ask questions about you know should this you know should this should this redirect or like you know like uh or it would come up with kind of it would kind of come up with ideas and you're like you know what that might be a interesting feature to add to the plugin. So in some sense it's it's good for discovery of features when you're kind of massaging a plugin like archive WP into its final state because that was one thing that kind of I found interesting about archive WP was the initial idea of it and and a little bit of background on that is that this was actually a a plug-in that we created for a customer for one of our remediation customers that needed uh something similar and and and and we had the idea, well, other clients are going to need this. We have more clients that need this and why don't we make it so that it's something that can be utilized across um many websites. And as any developer knows, making something for one website and making something for all websites is quite the feat. >> It's quite a lot of additional work to make it work across websites. So the the original U version like used like short codes to output stuff and was very opinionated on its design and layout whereas archive WP is very nonopinionated on the design and layout. Now we've >> I will I will step in actually here and say that while the original implementation of this on the client website was based on short codes and we have built this plug-in based on blocks, short codes are still available and they are fully equivalent to the blocks. So if you have a website that does not use the block editor or a custom postite that is not yet block enabled, you are still able to use these blocks wherever you choose just by implementing the short code. Um, secretly you might discover there's some additional features of those short codes that weren't exposed to the blocks. Someone wants to do some digging in. >> Yeah. Yeah. So the there's a lot of um attributes under the hood and that's what William's trying to say. >> Yeah. And um and we archive WP does have a a a onboarding wizard that will actually help you build this page. It'll create the page if you haven't created it or it'll let you choose an existing page and it'll actually implement the uh the block patterns or the short codes with a tiny bit of HTML markup to kind of get some layout into a uh classic editor page. Um, so what we've tried to do with ArchiveWP is we've tried to make this process as easy and seamless for the enduser to to one get the plug-in installed to get a page created and to archive their content. Literally within a few clicks, you can have all your content archived into its own custom post type isolated from all the other custom post types with disclaimers for accessibility compliance. And uh it took a lot of work to get uh from that initial piece that we made for the client to a fully functional uh premium plugin. So looks like uh we have Daniel on the live stream. >> Oh, hi Daniel. >> And Daniel says, "Thank you for all the improvements this year." Well, our pleasure, Daniel. Oh, >> so so I was on a call with Daniel a couple of weeks ago debugging the thing. So it's nice to see people >> Oh, awesome. >> People coming in. >> Cool. >> Any more problems, just reach out. >> Yeah, we're here to help. Daniel, thanks for joining us and uh look forward to a lot more next year. We are in the planning phases of uh features and new things for accessibility checker for next year. Cool. So those are the major releases. So two new plugins this year. Um but we didn't neglect our existing plugins and we have done a lot on that side. So this next uh feature I don't know if feature is the right word but this next uh area that we implemented throughout all the plugins it was was kind of huge. And if I'm being a little honest, uh, William and I were a little apprehensive to, uh, undertake this, uh, because we knew it was going to be quite the undertaking. So, >> this was a lot more effort than expected and also exposed some interesting things for me about the way WordPress handles this under the hood. >> This is my first deep dive into this in a very long time. >> Yeah. Yeah. So, do you want to say what it is, William? >> Yeah. So, we fully we we tackled internationalization of our plugins this year. So, we have made them fully translatable as far as we could. If you find anything that's missing translation functions, let us know. But we're quite confident we've caught everything at this point. And we translated the plugins, our entire suite into 30 plus languages, at least 32, but some plugins have a couple more. >> Yeah. So So what does that mean? Why why why would we do this? >> Well, accessibility of content is not necessarily just about how the content behaves in the browser. Sometimes it's inaccessible for someone because they don't speak English and that you know is a problem for well more than half of the world does not speak English and now our plug-in is available to a lot more people who will now be able to take advantage of these features and the user the users of our plug-in our plug-in becomes more accessible due to the translations and the users of those people's websites become more accessible due to the fixes that we provide or help these site owners do. So, it it's it's partly about reaching more people, but it also is just it's just the right thing to do >> actually. >> Yeah. I mean, basically um uh translations and internationalization is is accessibility like and it's and it really is. it it actually is taking the accessibility checker and then making it available for more more people and and in doing so, right? Um and it goes to show sometimes your own like uh apprehensions or I mean dare I even say our own biases when when you kind of say well we don't need to do that right or like that'll take so much time it's not worth the time or something and you don't think it's really going to have a benefit. Um to our surprise, we think it has had quite the benefit in our install counts from from different countries. Um Germany being probably the the top country that we've seen uh the most adoption from after implementing this internationalization. Now, there's some, you know, that coincides with a lot of uh, you know, the European Accessibility Act coming into place and and Europe having pro or not Europe, uh, Germany having probably some of the more stricter uh, requirements. I >> I think they're definitely a first to implement type country where they lead the way in a lot of these things. Um, in addition to Germany though, I have noticed an awful lot more Asian users coming in and you know identified by the fact that I can't read their names sometimes. >> Yeah. >> Um, coming in in Korean, Japanese, um, so lot more people in languages that I would not have expected. I mean, these are countries that might not have the same regulations in the way that um, Germany does. >> Yeah. Yeah, but these these are still using our plugin and maybe they would have if we hadn't translated it or maybe they wouldn't like we we'll never know because we now offer these translations. >> Yeah. Yeah. Yeah. I think it was great. And I think it it it's a little bit of a us practicing what we preach and um and we implemented this just before our team went to uh work camp Europe and uh so that we could have we could take we at us as an American company flying over to Europe um saying hey you know we're here to support you as the accessibility uh the European accessibility act comes into place. It was it was kind of on us to kind of practice what we preach a little bit. If we're going to support these these European countries and and and other countries, Asian countries throughout the world, that we should make this plug-in readable to everybody. And um and and I think it was probably one of the best things we did this year. And um >> it it definitely has it was worth the time. >> Yeah. Yeah, >> can't say that about every feature that we try. You know, you hindsight is great. In hindsight, we were mistaken to put this off for so long. >> Yeah, I think so. So, from a technical perspective, I mean, how do you how do you translate a plugin to that many languages? like well before we say how we get into translating it for so many languages let's just maybe talk a bit about how translations in WordPress works because this is the first time I have undertaken a large translation project in WordPress since the since the more common I want to say commonization I don't think that's a word but it's the closest that I can get to um strings inside JavaScript files is far more common now than it would have been just five or six years ago. And PHP we have well understood translation functions. You know we use the double underscore type functions and you know it does static analysis using get text. So it finds the translations it converts it into a pot file. Translators can take the pot file they can generate individuals for their each language. So it is static analysis. However, when you have JavaScript in your plug-in, quite often you use minification or uglification of the JavaScript code because we always want to deliver the smallest packages possible to the client. And when that code has been minified or uglified, it's really quite difficult to discover where those strings are inside of the content. And this was a challenge I didn't foresee being a problem, but it ended up actually being a huge issue for me is how to find these strings inside minified JavaScript files because we can find them quite easily in our source code because it's nice broken into lines. All of the all of the tokens still exist there, but in the minified files, we had to do some configuration hurdles to get it to keep those translation files there. And once you have those translation files, they actually don't get built in the same way and delivered as PHP translations do. There's actually JSON files that you also need to deliver to the client side whenever there's a translation available. So yeah, translations are a lot more complicated than they used to be if you have to support JavaScript, which in this day most of us have to support JavaScript translations. >> Yeah. Yeah. Yeah. So uh yeah. So we had some technical hurdles to get over. We actually had to kind of set our mindset a little bit around it too where it was like our plugins are are our strings are mostly all translated. there might be some like low lowhanging strings that were kind of missed over the years and it was kind of like in our heads we're like well we just need to we need to get the mechanism in there to translate these and and these translations are a little bit AI assisted and um we need to have the workflows built into our pipeline so that these translations happen with every release and then once we have that then we can kind of go back and and clean up code where there are some strings that may not be translated uh correctly. Uh so in our heads it wasn't like oh we've got to go through five plugins fix all the strings and no it was like let's put the mechanism in place things are translated all the strings like 90% of the strings are ready to go let's just put the mechanism in place and get the the translation files for those and then we'll go through Turns out that once we had put the mechanisms in place, it became much easier to discover where we had missed the string somewhere because we could, you know, I'm pretty sure I could confidently navigate and read our plug-in in French at this point because French was the language that I chose when I was debugging things. But if you're reading, you know, the settings in French and suddenly you see an English word, >> you know, that's missing a translation function. And that really did help us to get I I want to say almost all of them but at very least we have covered 98% of all of the strings in our plugin. >> Yeah. Yeah. Totally cool. So let's move on to um accessibility checker pro. So what did we do this year in accessibility check checker pro? So we we expanded the scanning capabilities. Uh we added the ability to scan post type archives and taxonomy terms which we've spoken about on a previous change log liveream. Uh do you want to speak to that at all William? >> Yeah so that was a a fiveyear desirable feature that took a very long time to implement. That feature predated me even working on any of this code. I didn't know that was a feature that was desirable. >> Mhm. >> Um at first, but it turns out quite desirable. Um Steve actually came up with the the way we could solve this under the hood is effectively building our entire plugin is set up around the the ethos of post IDs and archive pages do not have post IDs which was the real complication here and Steve had the idea of why can't we just virtually create these IDs and as such we do we just virtually create a post for every single one of the archive terms that want to be scanned and we and store our data on the virtual post, allowing us to scan every single archive page you have on your site, which includes custom post type archives, as well as all your taxonomy archives like categories, tags, or any custom taxonomies that you create that have archives visible. So yeah, all of those pages are now scannable and you can get results in exactly the same way that you would get results for typical posts. They're reflected in your overall site report. And if you know if you have the exporter plugin, you can export all those results as well and filter them to the individual archive that needs fixed. Um I will say that I discovered that you usually don't need to scan every single archive. So, we do have some form of like smart sampling built in because if you have one category archive, it's probably the same as all the other category archives in terms of its construction. So, you theoretically only need to scan one. Um, but what we do have is we scan one that is representative of a maximum number of posts. So, it will show pageionation and the minimum number of posts. So ideally it won't have pageionation and you know so we cover at least two at least three taxonomies >> or each three pages per taxonomy type. >> Yeah. >> In in the smart sampling mode. You can of course turn on full sample and you can just scan every single page which is probably what a lot of customers might end up doing but >> right >> that can take a very long time if you have thousands of terms >> and and and lots of custom post types. >> Yeah. Yeah. So this was just this like William said five years ago this was probably like this is probably feature number one that was on our list and uh and it just got kept getting pushed because of the complications around it like William said about you know archive pages are dynam dynamically generated pages you know on they're generated on the fly basically and and there's no there's no post ID there if there's no post ID there's no post meta And the accessibility checker requires post meta quite a bit. And so us coming up with a u us putting our engineering heads together and coming up with a a unique way to slot that into the plugin without a complete refactor of the whole plugin was a huge win for us and a huge win for uh our users. uh so now that they can they can get more coverage in their scans and have uh more assurance that uh their website is uh being scanned for accessibility compliance. So along with with that William you want to talk about the next one >> performance wins. >> Well before that there's there's a bullet point >> oh >> above that. >> Yeah. Yeah. So you you have a post page and a front page on in most WordPress websites and previously we weren't always scanning them depending on what the configuration is. So now we actually go out our way to make sure that we do scan your blog page. Um and also your you know front page if you know your front page is almost always going to have an ID >> but your blog post may not if you have not assigned a static page to it and if you had not assigned a static page to it we previously might have missed it but now that isn't the case. We will actually try and scan that page all the time now. >> Yeah. due to the fact that we could it's technically an archive for the posts and is now discoverable and virtually exists. >> Yeah. So um just like another it's not an archive page but kind you know but it is kind of a >> an archive page internally. >> Yeah. But we can't capture it as an archive page the same way. So we've gone the extra step to kind of consider that as well. Now there is some other considerations beyond archive pages and ma main post and blog post page and there are other things that we're looking to add in such as uh uh author pages and was there anything else besides that? >> Um so I did previously look into for my own use um element templates. M >> so you know not only can we scan actual things that are considered as pages we can probably quite soon start scanning things that are considered as partials such as element templates page templates for Gutenberg >> um you know any number of individual components that page builders implement that are available through some form of URL URL rewrite fees feasibly we can create a virtual post ID for and scan in a live page type of way. So no immediate plans on what we will scan next but floodgates are ready to open on that one. There's lots of options of what we could scan. >> Yeah, totally cool. So like you said performance um so this year we >> Amber did actually just comment in FSE templates. >> Yeah. Yeah. Exactly. Yeah. Yeah. Yeah. Totally. >> Soon PM. >> Yeah. Yeah. So, fullsight editing templates. Yeah. Exactly. That's uh um those are little pieces that we could probably push through the same mechanism that we did the uh the archive page. And uh now there is a whole there's a bigger picture here too, right? like we c we can keep kind of chasing the the WordPress rewrite template part thing or we could switch how accessibility checker works and actually start pulling from direct URLs based off of sitemap or some kind of scraping of the website. So um yeah totally. Um so performance um this was kind of a big one but I feel like this was kind of a feature that was uh implemented kind of under the radar. It it was so this was actually performance of the full set scanner was looked at partly due to >> I don't want to say a great many but a larger than other issues type of support request that comes in is to do with the full set scanner particularly how fast it is as we all know it isn't actually very fast in a lot of cases. Um, so as part of some of those complaints from users, we re we looked at how the queries work, how we gather the posts and you know, first off, we actually made it immediately faster by dropping one half of our scanner. I mean, we dropped the faster half. We had the two-part scanner, we dropped the faster half, so we're only left with the slower part, but that does speed up the scanner generally. But in addition to that, there was query optimizations and some caching added that actually does for it won't benefit the majority of sites, but for large sites, you you're looking at five, six, 7, 10, 20 times faster sites for very very large sites. Like if you have a site that has 100,000 posts on it, the full site scanner will be dramatically faster for you after we made those query optimizations. And there are definitely more of them to come. >> Yeah. Yeah. Um we'll talk about this here in a little bit too on why we dropped that first half of the scanner. When Williams says we dropped the first half of the scanner, what we're talking about is there it used to have two passes. There was a >> a a you know it was behind the hood under the hood. It was a PHP scan and then it was a JavaScript scan because we had some rules that were written in PHP and all we had to do was parse HTML for that and then we had some rules that were written in JavaScript which actually would pull up the actual website page and scan it from the front end with the full render. >> Well, actually at first all of the roles were in PHP aside from color contrast. So >> we would run the JavaScript scan only for color contrast at first, which unfortunately is the slower half of the scan. >> Yeah. Yeah. >> But more accurate half. >> Yes. Dramatically more accurate. >> So >> I mean that's why we we could not do color contrast in the PHP scan the first half. >> Right. Right. And and actually even going further back when you know we talked about accessibility checker. It's getting ready to turn 5 years old. um that the scan was all initially PHP and even our color contrast was PHP but out of the necessity to make it more accurate we started switching that to JavaScript over time and like I said here in a little bit we'll talk a little bit more about that switch to JavaScript but uh aside from that um William has done a lot to implement uh to make the plug-in much more WP CLI compliant and or I don't know if compliance is the right word but uh ready we've been working on a lot of our own commands and >> yeah so selfishly because I had actually created some commands for my own development purposes that later on was answered or mentioned by um Chris had mentioned that a client had asked for some of these WPCLA commands and I was able to say like oh yeah I've been using that already That's >> that's mines. I had to do a bit of clean up to make it production ready, but now we have shipped a handful of WP CLA commands and we have added a couple more over time. Um, primarily maybe the most useful one for an average user would be a programmatic way of getting the individual scan stats for a single page if you had such a need or you know the full site of scan stats as also if you had such a need. And I can imagine a a few people might programmatically want to grab them rather than having to log into a whole bunch of individual sites and check their numbers, right? Yeah. And things like uh license key activation, deactivation, um adding the license key, things like that. Um and a lot of that was done in prep with some uh some of the partnerships that we've uh uh put together this year with some of our hosting partners. Um so that they can be able to run CLI commands in their pipelines to be able to uh activate and deactivate and add license keys to the to the plugin. Uh, one of our more recent uh, partnerships is with Cloudways and uh, some of these uh, requests came from them as well to be able to do these things. Yeah. Well, technically a hosted partnership now can retrieve a key from a customer and then make everything from that point onwards entirely seamless in their platform. They could, you know, activate the plugin, install, activate, and trigger scans across some of the pages >> like all entirely programmatically before a user even has to make it anything other than the purchase to get their key, >> right? >> And and actually they could just install free as well. So some of these platforms can now seamlessly get that up and running, >> right? So we're doing more to expand accessibility checker uh for hosting companies as well so that we can make it available to their client base and make uh integrating uh it into uh those hosting plans uh more seamlessly. So hosting companies reach out to us. We'll get you an integration and we're we'll get up and working. So uh man, we're running long on time and we got a lot to get through. So, we're going to we're going to I'm going to rapid fire some more things here. So, on accessibility checker pro workflow. So, uh we I'm going to run through some of these real quick. We added filtering by uh post status. So, whether it's a draft or published, etc. >> And this was a highly requested feature. People don't want to scan their drafts because they don't see any. They might have 10,000 drafts. >> Yeah. >> They're never going to be published. >> Yep. Totally. Uh so, you can filter those out. You can actually see the post status inside the uh open issues uh table in accessibility checker pro. Now um we added landmark uh selectors to the issues table as well. We're talking about this. We added landmarks and free as well. We'll talk about that allowing users to pinpoint the specific location of landmarks. Um so we've just surfaced that inside of the open issues in the pro plugin. We improved rule descriptions and metadata to uh provide better context on accessibility issues. This was a huge undertaking that uh Amber took to rewrite some of these descriptions and how to how to fix it. Um, we've added uh severity uh to issues and we've added some kind of intelligent severity sorting to our issues in the UI to help you surface not only the is not only the issues with the because it used to sort by errors and warnings and then a secondary search on the the issue count. So now it it it is extended to sort by um severity and then issue count. So what we're trying to do inside the plugin is always expose to you what you can action on and get the the most results from. So um what else? Let's see. And then like I said the severity. So that's a lot of the the kind of a lot of the big features that we've added to Pro. Of course, we are always squashing bugs and fixing other things in that regard. But let's move on to accessibility checker free. We call it core sometimes, but the the plugin that you can get from wordpress.org. And uh you want to run through this first one, will you? >> Yeah. So we added um rescan and clean issues buttons and these are just nice to have userf facing features. These are things that we do programmatically quite often by going into the database cleaning issues. You know no longer do we have to do that as developers but being able to clear issues sometimes fixes edge case bugs if someone changes post types or does unusual things. Disable the plugin for a while turn it back on. So clean issues just resets the post and then you can just click to rescan and you can immediately get fresh results. >> Yeah. >> And you can also use that like if you have you know don't haven't thoroughly tested this with a lot of different builders but if you use a front-end page builder you now have a rescan button on the front end that you can then scan as you change your content. It works with some builders. I haven't tested all of them. >> Yeah. >> If you have a builder that it doesn't work on, let us know. Yep. Yeah. Um we know that it works really well with Elementor. Um we are >> Beaver Builder works with most for the most part, >> right? And we we currently are uh working with Etch to get accessibility checker working fully with the Etch uh website builder and uh we're looking forward to uh implementing that. And if anybody any other builders have problems, feel free to reach out to us and we're we'll get those fixed. Um, and >> as another nice UI feature, we no longer overlap icons on the front end. So if you're using the front end highlighter and an issue has two different warnings or one warning, one error assigned to it. Those icons will no longer overlap each other. They will be stacked neatly side by side. So you can click on each one individually and see the relevant information about that specific issue. >> Yeah. Where before if you had multiples stacked right on top of each other, you had to use the arrows, the next and previous areas to get to them. So >> and sometimes those issues might not be next to each other in the order stack. So you would jump up and down on the page. >> No. Cool. So uh new smarter rules. We are always trying to refine our rules to make them better. Uh Amber's always opening tickets for us to with new ideas on how to make the rules uh smarter and more intelligent and help with uh her own uh audits of things. Uh this first one. >> Yeah. So it's a shame that Daniel isn't still here. He did say he had to drop off, but this was what the call I had with Daniel a few weeks ago was about an another improvement we made to the video transcript detection. So if videos were not not or the transcripts were not directly adjacent in terms of the markup there might have been cases where it was missed and that was the case on Daniel's website. So that is now fixed and the detection of video transcript should be far more reliable for everyone based on that change and it was already quite reliable. There was just some edge cases that meant it might not work >> right. And uh landmarks, we've talked about this a little bit in on when we're talking about pro, but we have added uh landmark uh location feature to show exactly where landmarks are in the DOM. So that's in the front-end highlighter. It actually will list you what the uh landmark location is in the uh in in the details tab in on a post or in the uh open issues from the pro plugin. and you can click on that and it'll open it up in the front end highlighter and highlight that landmark location. So, just doing more to try to show you where issues are and we actually have plans to expand that to be able to start segregating out issues based on which uh which user role should be seeing which which issues. So, basically um an editor probably doesn't need to see issues in the header and footer. Those are global issues. Well, they may want to seen them still, but they probably can't fix them or not in a position to fix them. So maybe you might want to show them only actionable issues, in which case an editor might only see issues that are directly inside the content area or the main tag. >> Yeah. So cool. Then uh so links we improved checks for anchor exists uh missing title attribute and new window warnings. Was this one you worked on, William? >> So, I think I've touched most of these rule tweaks over the year. I cannot remember which ones exactly. Um, however, a lot of these were improved from something we're going to talk about in a minute, the the JS conversion. So, a lot of these rules got dramatic improved >> accuracy due to some switchovers, including the next one that's in this list here, the underlying text as well. And I will also put Amber a bit on the spot here and call out that there might also be a naked links roending some documentation work. >> Yeah, that's my favorite one. Naked links. >> That that's actually quite a common problem that >> right >> we should be flagging and detecting. >> What what is a what is a naked link? It's when you just copy and paste a link directly from your address bar and it might contain all those letters and numbers that they use for tracking or it might be nested 16 levels deep. And for a screen reader, every one of those characters is going to be read out and that just is a horrible experience for someone who might not be visually impaired. >> Yeah. Yeah, we are. So, we have implemented the naked links rule and and this is a little bit how the the workflow works, right? So, uh, you know, a recommendation for a a rule gets added to either, you know, our ideas board or as an issue in GitHub and and then sometimes William or I are have a minute and we're we're like, ah, we'll pick this one up and then we, oh, that was easier. >> It never takes just a minute, but there >> Well, this one was more complex than that, right? But um and then we get it and then you know we assign it to Amber and we wait for documentation and once we get documentation then it we release it out to the world for you guys because releasing a rule without documentation on what does this mean and how do I fix it and what are the implications of this um is is not a a great uh user experience. So, um, but not only that, I mean, like when you get the idea for like we try to compare like we we use Axe core in our plug-in, but an extremely um extended version of it. We hook into it. We change it. We group rules together. We we don't use some of their rules. We use some of our completely own custom rules. And in this case, uh, William, the the recommendations that came from Amber about what is a naked link, um, was was was far more, uh, verbose than like what say axe core does to detect those, right? And, uh, >> you good? >> I think my internet is being a bit off. >> Oh, okay. Okay. >> Oh, it is a bit off. Okay. So, William is now frozen. So, I will talk. >> There's something. >> Yeah. >> Yeah. >> You You talk. Give me one second. >> All right. Um, so while William goes and kicks his kids off of the internet, um, I'll talk about naked links. That's what he's doing. The uh Yeah. So anyway, uh you know, whether it has a protocol on it or doesn't have a protocol on it, making those decisions on what actually constitutes a naked link, I think what we've come up with goes pretty far um to making it a very usable rule that doesn't create a ton of noise uh for the for the end user. So that's a little bit of a sneak peek on a rule to come. But to that, William, since we're kind of talking about rules and JavaScript and axe, can you talk a little bit about why we decided to finally jump and just migrate everything over to JavaScript scanning? Oh, I can't hear you. >> Let me know if you can hear me. >> Oh, maybe. Is that >> you're >> No. >> Yeah, there you go. Uh, I think you're good. Try to talk. Yeah, I think I'm back. I just disabled Netflix. Oh no, he's frozen again. So >> yeah, you're still cutting out a little bit there, bud. >> There we go. You're back. I'm back for one second, but I'm probably going to disconnect again in a second. I'm going to >> Yeah. Yeah. >> Going to have to shut down some stuff on their end. >> You on the router cutting them out? >> Yeah. And I'm not cutting out the right things apparently. >> That's right. So, I mean, we we used to scan in PHP. We kind of migrated to a hybrid approach and then this year we went full in. We did a major sprint to get these all converted over to what we call JavaScript rules. And what we mean by that is these are this is uh scanning code and logic that can be run on the actual rendered page. So we can pull up a page, we can insert our scanner into it, we can scan the page and get uh vastly more accurate results than we ever could with just straight up PHP parsing. And uh >> yeah, well the the perfect example probably is the the color contrast. >> Yeah, >> is the the first one that was transitioned because there's you have to read all of the JavaScript, all of the CSS, and all of the HTML to try and determine what color an object might be inside the DOM. And that might actually be influenced by external JavaScript that runs that you'll never really be able to know in a PHP scan. So unless you render the page, you won't know the actual color and you may also not understand what the background color would be to do an actual comparison. So once you render the page, you know all of those things with, you know, a guaranteed like for certain that there's no question in what color is on top of what color if you actually render the page. And there's a lot of other rules like the underlying text row we briefly mentioned earlier on. So there's a bunch of different ways you can underline your text. You can literally just use text decoration, a style row, but you can also use um border bottom on a row and we cannot detect that in PHP with static analysis. We cannot determine what a thing looks like. However, with JavaScript, we can see that and it is literally the difference between making an educated guess and actually being able to see what the thing is going to look like to a user in the browser. >> There's a huge difference between static scan and a live page scan. The the downside of the live page scan is that it takes up more resources and it's a bit slower because of the nature of how you have to render the page, but it is millions of times more accurate. >> Yeah. And you need to you need to leave the page open and let it run because we need to use your browser to determine these things. Whereas when we were doing uh the PHP the static analysis we didn't need that um u because we actually were not rendering the page and and so it does require a little bit more resources and a little bit more complexity to do what it does. But this is actually the the def you know what makes accessibility checker different than almost any other scanner. And um and this is what actually brings like enterprise SAS accessibility scanning that cost a fortune. This is what actually we're doing to take that and bottle it into a WordPress plugin and bring it to uh the vast a vast majority of users that don't have the resources or don't want to pay for those super expensive accessibility enterprise accessibility tools. Well, a lot of those super expensive tools are just running X core right out of the box. They're not doing any customization or any tweaking. And you know, I was quite surprised that with our bucket of, you know, however many rules we have, we only actually take directly verbatim from Xcore, a handful, maybe five or six of those rules. And the rest of these custom rules are extensions of Xcore rules or some of them are very WordPress specific rules. >> So we're not just going to give you generic answers the way some of these like online scan tools are going to >> going to manage. We're literally going to interpret the results of the scan and provide only the valuable items as as far as we deem. You know, we might not have be pulling out all of the valuable items as of yet from Xcore, but over time we will be adding more of more rules, more custom rules, and more things that can be scanned against those rules. >> Yeah. Because we're not we're not just looking to build like a, you know, a base level compliance uh scanner. We're actually looking to build a a fullfeatured auditing tool to help you audit a website. And we expose we expose what we call warnings, which are actually things that we're prompting you as an auditor or just a web developer or uh or a website creator, a content creator. We're actually prompting you to say, "Hey, we can't programmatically tell you with with certainty that this is an issue, but we think it is and we want you to look at it." So, we're doing a lot to help come alongside you and and to assist in that audit of these websites to make them as accessible as possible. So along with that conversion William um we we we found the need to really make sure that our if we're writing and extending so much of axe core we need to ensure that what we're doing is right and that we don't have any regressions when we change other rules. >> Yes. So before I say how we did this let me tell you how we used to do this. We had the WordPress website. It had the bunch of content on that website. And we would update the plug-in on that website. We would visit the pl the website, scan the page, and we would see what it finds, what it doesn't, and we had lists of things that we expect should pass and things that shouldn't. And that was all live content on a live website that we had access to. And that was how we previously were testing this. Um, now we have almost every single row or every role that we transitioned in the most recent batch. I think it's probably 90 95% of all the rules that we run in our scanner now have fully automated JS tests. And this was an excellent use of AI we discovered because we had the content for most of these roles elsewhere. And we were able to tell the AI here's the content we have generate these tests that automate verification that these things pass or these things fail. And every time we make a change to a rule, these tests get run and it tells us whether we have broken a rule or improved the rule. And if someone comes to us with an issue that these rules do not detect, we just add it to these unit tests and we can change our role or change our tests till we get it to pass or fail. And not like like we legitimately want to fix exactly what's reported. So we take the markup snippet directly from these problematic websites and verify them against our actual row. And the way Jest works is it literally spins up and tests against this exact markup. So we have a pretty high degree of certainty that if we fix it in our tests is fixed on someone's website. >> Yeah. And this is you know this is a living and growing test suite like William said and we're continually adding to it and we don't remove these. It just builds up. I mean, we've got thousands of code snippets that get tested when these rules run. And we can even we can even do like um uh we even do like testdriven development uh in in respects to that where if say Amber says we should do this rule, right? We should do this check. We should check for this certain thing and this is what I think uh would be a failure or this is what I think would be a pass. we can actually take those put them into the the test first before we even write the the check or the the rule and um we can actually take that and then use AI to prompt it to say hey can you try to make a rule and a and a check to to go along with this. So it's kind of >> it's sometimes hit and miss. I actually do think the AI works better the other direction where we write some of the code. We start off with basic unit tests and then we ask it to look at the code we've written and extend the unit test to make sure that things we change don't break something or you know to highlight things. The the AI has actually been surprisingly good at identifying gaps >> in the tests that we have. So we might have a series of 10 tests and we can prompt the AI and the AI might come back and say here's 15 edge cases that you didn't consider. >> Yeah. And then we just instantly put them in and we run the tests and sure enough some of them might pass, some of them might fail. Some of them might be incorrect and we need to continue tweaking the rule to make sure that the answers we get in the end from the tests are exactly what we expect. >> Yeah. And as far as regressions like we have some rules that actually will share like uh helper a helper uh code across multiple rules and if you modify that or you modify a certain rule you can actually you have a lot of uh checks and balances there to ensure there's no regression that >> like for example if we modify how we handle area hidden >> in terms of visible content if we modify the helper that we use for that that could break a whole bunch of things because that is actually a base requirement for a lot of screen reader backed rules. If if it's already hidden, the screen reader won't ever see it. And that might be a problem. We might actually want to flag that it's hidden and tell you you need to unhide this. Or if it is hidden and it's problematic content, maybe we don't need to tell you that that's an issue because the screen reader can't see it. So, it is important that that works. >> Yeah. >> We need to make sure that that our helper does not get broken. Yep. So, I mean that's a rundown on what we are doing on our end to ensure accuracy to make sure that your your issues are actual issues, not false positives and that we are continuing to build build a huge library of tests to ensure that with every update that uh that all of our rules continue to work and that we don't create any downstream problems. So, we are running short of time. I think it's time for another lightning round to finish up. >> Well, you you go lightning around and I'll maybe enable I'll turn Netflix back on. >> Yeah. So, we did some dashboard tools in the plugin. We integrated accessibility checker into the site health. We're all adding some more information in into there to not only help you see that there. So now in the site health it'll actually flag if you have u accessibility issues on your website. Um and u it flags you know the different warnings that come with the site health. Um so we're trying to expose accessibility checker there. When you run site health you can see if there's accessibility issues that need to be addressed on your website. We added an admin toolbar with quick links. Now, this is the most easy easy thing, but it's one of William and and my favorite things is is now having just a toolbar with links in it that we can quickly jump to our settings page, >> go straight to the settings page, no longer having to double click >> or the fixes page specifically. >> Yeah, the fixes page. So, we're just trying to make things uh more more accessible and uh easier to navigate to. So, we have some add-ons. We did some work on add-ons as well this year. We have our export add-on. Our export add-on now includes a wikag levels and the severity level in the export. We are actually looking at adding some more features to the export to be able to export uh issues at the post level. Um that is an upcoming feature that we're looking at uh for the ex exporter plugin. And then in our audit history plugin, uh, we added a filter to customize which user capabilities are allowed to view the audit history page. So, yep. And this one also came from a customer request. So, you know, any anyone who has any issues or any desirable features they have, send them our way because we almost always try to implement the things that you request because we can only come up with so many great ideas on our own. >> Yeah. >> You always come up with some more. >> Yeah. So, so those are some of the top things and like I said, a whole litany of bugs that have been squashed throughout the years, but we do not have time to go through each one of those, but just uh these are all the things that we're doing to improve the accessibility checker to make it easier for you to use and to make it more accurate and and to help you make your website as accessible as possible. So, what are we doing next? It's >> well next it's Christmas time >> so we're we're taking a break >> but then yes >> but then after the break we are doing email reports >> right >> and not just email reports these reports will also provide access to some new information that you have to jump through some loops to find such as identifying the top five pages on your your website with issues. So yeah, these reports will be available to everyone I want to say, not just page users. >> So yeah, more to come on that. >> Yeah. So this is actually a feature that's in the works right now. Um it's it's not even part of the 2026 roadmap, but it's a part of this year's roadmap. But as you said, the year is winding down and uh equalized digital. We like to uh treat ourselves and our team to a nice week off at the end of the year just as a little thank you for all the hard work and to have >> forcing me to spend time with my family. >> Forcing you to spend time with your your family and um uh so yeah. So, basically what it is, it's going to be the the free plugin. You're going to be able to connect it with your my dot uh equalize, we call it my dot. So, it's your dashboard on my.equalized.com. Um, you will be able to connect your free plugin with the dashboard. If you don't have an account, if you got the plugin from WordPress.org, you can create an account on uh my.equalized.com and make that connection. And once that's connected, we will get your uh your summary report at certain intervals and we will send you emails about the accessibility uh status of your website. A little report on and like William said, some new features in that report that aren't currently in the plug-in where we're identifying the top pages that need to be addressed. Uh so that you can get that right into your inbox. You can see what pages have problems, what you know and you can action on those right away. And there is uh a lot that goes along with that as well. We we have thoughts and ideas and these are just ideas about um you know we can expose that that those reports inside of your my.ealizeddigital.com vehicledigital.com dashboard and we can start to do some a little more historical we can expand the the audit history plugin that we have we can start doing that at at an even bigger level and uh exposing some of that >> I also want to mention that you know audit history is currently only available on higher tier licenses and with the addition of the email reports that is actually going to introduce at least a currently versus fast access to history of issues for free users as well. So this is not just a >> all the fanciness is not going to be only for paid users. Free users will absolutely get a lot of benefit from this feature being available as well. >> Right. Yep. And what it also does is it allows you to collect uh the the accessibility status of multiple websites into one dashboard on y.ealized.com >> potentially just one email as well monthly. >> Yep. So a lot in the works there. We at in December uh equalized digital goes into kind of planning mode a little bit and uh we start to plan out what we're going to work on for the next year and we are currently in the throws of that this week and uh we're doing a lot to plan new features for the next year and uh I'm super excited to share what those are with you all uh late in future live streams um once we all get uh a unified decision on what those are and uh we start >> I'll let slip of one that maybe might not make the road map but I'm absolutely going to do here which is some more advanced rules. >> You might want to look at whether your tabs are correct as opposed to just do tabs exist on the page or they >> they're correctly >> component level accessibility >> might be a set of rules in the future or there might be some other experimental rules. Well, we don't want to give these ideas all away. Our competitors are watching. They're gonna maybe they're going to steal all of our ideas. No, no, it's it's fine. But no, um, we're always thinking about these things. Like William said, component level scanning. We can identify a component. Why don't we just scan the whole component to make sure it's complaining? Tabs are hard. They're hard to make accessible. So why don't >> hard to make accessible from a development standpoint, but actually quite easy to recognize when they're wrong from a programmatic standpoint. So >> yeah, >> let's do that. >> Cool. Well, do you have any uh closing thoughts for 2025, William? >> It's been a busy year. Done a lot more than we had time to go through here. um made a lot of development improvements in the plug-in consistently which you know is reaping the benefits of how quick we can get these features out now and you know hopefully next year is a year full of features now that we've done a lot of that cleanup. >> Yeah. Yeah. So my kind of 2025 recap is that yes, busy is is is a word I would cap the year off with a whirlwind year of busyiness and uh but you know that just shows what Equalized Digital is doing to to and what we're putting into this product to make it useful for the you for our users and and our commitment to pushing accessibility forward uh from you know from a technical perspective of identifying and fixing issues and and continuing on with that and and what other areas can we help in this audit and reme remediation of accessibility. And I just want to end by saying, you know, any listeners or or customers of or users of accessibility checker, thank you. Thank you for trying out the plugin. If you haven't used it, please grab it. It's free. It's extremely fullfeatured free plugin. None of our rules are gated behind a payw wall. All of our rules, >> you get all of the scan capability for every post, the same as everyone else. >> Um, so I just want to say thank you uh anybody that's tried out the plugin and all the people that we interact with uh uh feel free to reach out to us. We're all happy to give advice. We're happy to look into bugs. And uh just uh want to wish everybody a a happy new year and uh we look forward to getting back to it next year. >> I think we will see you on is it the 7th of January? >> Yeah. >> Um the 8th maybe the week after we're back. >> Yep. Next live stream will be probably around the first week of the year. So look for us then. Thanks for joining us and, 2025 Year in Review, YouTube, 01kc9bt3kz1vk5rg9mt3t6mnq5.