2025 Year in Review - CourtneyR.dev's 2nd Brain

2025 Year in Review 🔗 **Source:** [2025 Year in Review](https://www.youtube.com/watch?v=M7p4GFbugP0) > [!note]+ Document Notes > tags: [accessibility, wordpress, year-in-review] > author: Accessibility Checker > source: YouTube > reference: https://www.youtube.com/watch?v=M7p4GFbugP0 > date created: 2024-12-27 11:30 > > # 🏷️ Title: Accessibility Checker 2025 Year in Review - Major Releases, Features, and Technical Improvements >  ## 🧰 Action Inbox - [H1] Download MultiSite plugin for agency license holders — manage 20+ sites efficiently #multisite - [H2] Try Archive WP for outdated content compliance — maintain accessibility while archiving #archive - [H3] Update to latest version for internationalization support — now available in 30+ languages #i18n ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Accessibility Checker Plugin](https://accessibilitychecker.com) - [European Accessibility Act](https://ec.europa.eu/social/main.jsp?catId=1202) ## 📝 Summary - Accessibility Checker released two new plugins in 2024: MultiSite management and Archive WP - Implemented full internationalization with 30+ language translations - Migrated from hybrid PHP/JavaScript scanning to full JavaScript rendering for enhanced accuracy - Added archive page scanning capabilities, performance optimizations, and WP-CLI integration - Demonstrated significant growth in non-English speaking markets, particularly Germany and Asia ## 📖 Main Content The Accessibility Checker team completed their most ambitious year yet, launching two standalone plugins while significantly expanding their core accessibility scanning capabilities. The MultiSite plugin addresses enterprise needs by centralizing license management across WordPress networks, while Archive WP helps organizations maintain accessibility compliance for outdated content through automated archiving with proper disclaimers and redirects. A major technical milestone was the complete internationalization of their plugin suite, making accessibility tools available in over 30 languages. This initiative required overcoming complex challenges with JavaScript string extraction and minified code translation, but resulted in measurable adoption increases in non-English markets. The team also completed a fundamental architectural shift from static PHP analysis to full JavaScript page rendering, dramatically improving scan accuracy at the cost of increased resource usage. This change enables detection of dynamically generated accessibility issues that static analysis cannot identify. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/M7p4GFbugP0?t=0) — Welcome and Overview - Key idea: Final livestream of 2024 reviewing major accomplishments - Evidence: "Last one of the year. We made it." #### ⏱️ [03:30](https://youtu.be/M7p4GFbugP0?t=210) — MultiSite Plugin Release - Key idea: First major plugin release enables centralized license management - Evidence: "Allows users to basically have full control over how their licenses get applied across a multi network" #### ⏱️ [08:15](https://youtu.be/M7p4GFbugP0?t=495) — Settings Synchronization Feature - Key idea: Copy settings from master site to all subsites with one click - Evidence: "Why would you configure 50 different sites when you can just come here, configure one, and then clone your settings across all of them?" #### ⏱️ [12:45](https://youtu.be/M7p4GFbugP0?t=765) — Archive WP Plugin Introduction - Key idea: Standalone plugin for managing archived content while maintaining compliance - Evidence: "Plugin to help you manage outdated content while maintaining accessibility compliance" #### ⏱️ [18:20](https://youtu.be/M7p4GFbugP0?t=1100) — AI-Assisted Development - Key idea: Archive WP was first major plugin built using AI workflow - Evidence: "Archive WP was probably the first big plugin that we tried to implement that to its fullest" #### ⏱️ [25:10](https://youtu.be/M7p4GFbugP0?t=1510) — Internationalization Implementation - Key idea: Full translation support added across all plugins in 30+ languages - Evidence: "We fully tackled internationalization of our plugins this year" #### ⏱️ [28:45](https://youtu.be/M7p4GFbugP0?t=1725) — Translation Impact on Adoption - Key idea: Significant increase in installs from Germany and Asian countries - Evidence: "Germany being probably the top country that we've seen the most adoption from after implementing this internationalization" #### ⏱️ [32:15](https://youtu.be/M7p4GFbugP0?t=1935) — JavaScript Translation Challenges - Key idea: Minified JavaScript required special handling for translation strings - Evidence: "When that code has been minified or uglified, it's really quite difficult to discover where those strings are" #### ⏱️ [38:30](https://youtu.be/M7p4GFbugP0?t=2310) — Archive Page Scanning - Key idea: Five-year requested feature finally implemented using virtual post IDs - Evidence: "Steve had the idea of why can't we just virtually create these IDs" #### ⏱️ [42:20](https://youtu.be/M7p4GFbugP0?t=2540) — Performance Optimizations - Key idea: Query optimizations provide 5-20x speed improvements for large sites - Evidence: "For large sites, you're looking at five, six, 7, 10, 20 times faster sites for very very large sites" #### ⏱️ [45:15](https://youtu.be/M7p4GFbugP0?t=2715) — WP-CLI Integration - Key idea: Command-line tools enable hosting partner integrations - Evidence: "Programmatic way of getting the individual scan stats for a single page" #### ⏱️ [52:30](https://youtu.be/M7p4GFbugP0?t=3150) — Rule Improvements and Severity - Key idea: Enhanced rule descriptions and intelligent severity sorting - Evidence: "Improved rule descriptions and metadata to provide better context on accessibility issues" #### ⏱️ [58:45](https://youtu.be/M7p4GFbugP0?t=3525) — JavaScript Migration Rationale - Key idea: Full JavaScript rendering provides dramatically more accurate results than static analysis - Evidence: "It is literally the difference between making an educated guess and actually being able to see what the thing is going to look like" #### ⏱️ [62:15](https://youtu.be/M7p4GFbugP0?t=3735) — Custom Rule Development - Key idea: Most rules are custom extensions beyond standard Axe Core implementation - Evidence: "We only actually take directly verbatim from Axe core, a handful, maybe five or six of those rules" ## 📚 References - [Accessibility Checker MultiSite Plugin](https://accessibilitychecker.com/multisite) - [Archive WP Plugin](https://accessibilitychecker.com/archive-wp) - [Axe Core Accessibility Engine](https://github.com/dequelabs/axe-core) - [WP-CLI Documentation](https://wp-cli.org/) ## 🗣️ Paraphrase - Released two major plugins this year: MultiSite for enterprise license management and Archive WP for compliant content archiving with automated workflows and accessibility disclaimers - Completed full internationalization supporting 30+ languages, overcoming technical challenges with JavaScript minification and seeing significant adoption growth in non-English markets - Migrated from static PHP analysis to full JavaScript page rendering, dramatically improving accuracy while requiring more resources but enabling detection of dynamic accessibility issues ## 📰 Newsletter **Accessibility Checker Wraps 2024 with Major Plugin Releases and International Expansion** The Accessibility Checker team completed an ambitious 2024 with two new plugin releases and significant technical improvements. The MultiSite plugin streamlines license management across WordPress networks, while Archive WP helps maintain compliance when archiving outdated content. A major milestone was full internationalization support in 30+ languages, driving notable growth in German and Asian markets. The team also migrated to JavaScript-based scanning for dramatically improved accuracy. Key practical benefits include archive page scanning (a 5-year requested feature), performance improvements up to 20x faster for large sites, and WP-CLI integration for hosting partners. Resources: [Accessibility Checker](https://accessibilitychecker.com), [WP-CLI](https://wp-cli.org/), [WCAG Guidelines](https://www.w3.org/WAI/WCAG21/quickref/) ## ✅ Action Items #### WordPress - Core: Integrate accessibility scanning into core development workflows - Plugins: Review accessibility compliance for plugin directory submissions - Community: Promote accessibility checker adoption at WordCamps and meetups - Training: Develop accessibility curriculum incorporating automated scanning tools - Documentation: Update accessibility handbook with latest scanning techniques #### DevRel - Developer advocacy: Present accessibility automation talks at conferences - Education: Create workshops on JavaScript-based accessibility scanning - Developer experience: Improve API documentation for WP-CLI commands - Community management: Moderate accessibility discussions and feedback #### OSPO - Security Management: Review accessibility scanning tool vulnerabilities - Software Inventory: Include accessibility tools in SBOM strategy - Developer Support: Provide training on accessibility compliance automation - Community Engagement: Fund accessibility tool development ## 🧪 Hypotheses - JavaScript-based scanning will become the industry standard over static analysis due to accuracy improvements - International accessibility regulations will drive increased adoption of automated scanning tools - AI-assisted development can accelerate feature delivery while maintaining code quality - Centralized license management becomes critical as organizations scale accessibility compliance efforts ## 📊 Methodology - Compare install growth rates pre/post internationalization by geographic region - Measure scan accuracy improvements between PHP static analysis and JavaScript rendering - Track development velocity metrics for AI-assisted versus traditional coding approaches - Analyze performance improvements across different site sizes and configurations ## ❓ Questions - How will emerging AI coding tools change accessibility scanner development workflows? - What scanning capabilities should be prioritized as WordPress moves toward full-site editing? - How can automated accessibility tools better integrate with content creation workflows? ## 🔮 Future Research - FSE template scanning implementation strategies - Direct URL scanning versus WordPress post-based architecture - AI-powered rule creation and customization capabilities - Real-time accessibility monitoring during content editing ## 💡 Implications - Practice: JavaScript-based scanning requires more server resources but provides enterprise-level accuracy - Policy: International accessibility laws create market demand for multilingual scanning tools - Security: WP-CLI integration enables secure programmatic license management for hosting providers - Education: AI-assisted development requires new code review and quality assurance processes - Funding: Accessibility tool development increasingly viable as compliance requirements expand globally ## 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: Plugin interface screenshots, workflow diagrams - Improve: Architecture diagrams for JavaScript scanning pipeline, internationalization process flowcharts #### 🔊 Aural learners - Present: Live stream format with developer discussion - Improve: Audio-only podcast version, technical deep-dive recordings #### 🗣️ Verbal learners - Present: Clear explanations of technical concepts, development analogies - Improve: Glossary of accessibility scanning terminology #### 🧩 Kinesthetic learners - Present: Live plugin demonstrations, hands-on feature testing - Improve: Step-by-step setup guides, interactive scanning tutorials #### 🧠 Logical learners - Present: Technical decision rationale, performance metrics - Improve: Decision trees for scanning method selection, ROI calculators #### 🧑‍🤝‍🧑 Social learners - Present: Live Q&A format, community feedback integration - Improve: User story sharing, case study discussions #### 🧘‍♀️ Solitary learners - Present: Detailed technical documentation, self-paced exploration - Improve: Individual assessment tools, reflection prompts #### 🌿 Naturalistic learners - Present: Real-world accessibility impact examples - Improve: Ecosystem thinking about accessibility tool adoption ## 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, logical content flow - Improve: More descriptive alt text for technical diagrams #### Keyboard navigation - Present: Standard video player controls - Improve: Timestamped navigation shortcuts #### Contrast and readability - Present: High contrast video player interface - Improve: Transcript formatting for better readability #### Media and captions - Present: Full video content with detailed transcript - Improve: Professional captioning, audio descriptions for visual elements #### Standards reference - Meets WCAG 2.1 AA for video content with comprehensive transcript ## 🌍 DEIB Assessment #### Cultural breadth - Present: Discussion of international market expansion, multiple language support - Improve: More diverse geographic examples, non-Western accessibility perspectives #### Inclusive language - Present: Technical jargon appropriately defined - Improve: Plain language summaries for non-technical audiences #### Neurodiversity support - Present: Clear section breaks, logical information flow - Improve: Visual summaries, reduced cognitive load formatting #### Representation - Present: Focus on making tools accessible to global audiences - Improve: Highlight diverse accessibility needs and use cases ## ✅ Logical Validity #### Strong reasoning - Deductive strength: JavaScript scanning accuracy claims supported by technical evidence - Inductive strength: Market expansion patterns based on internationalization data - Causal reasoning: Clear connection between feature releases and user adoption - Analogical strength: Appropriate comparisons to enterprise accessibility tools #### Fallacies - Post hoc reasoning: Attribution of growth to internationalization without controlling for other factors - Appeal to popularity: Using install numbers as primary quality indicator #### Tone of voice - Overall tone: Professional and technical with appropriate enthusiasm for achievements ## 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacks on critics or competitors - Reverse victim/offender: No victim/offender reversals identified - Emotional cues: Positive, achievement-focused presentation without defensive rhetoric ## 🎯 Conclusion Accessibility Checker's 2024 achievements demonstrate the maturation of WordPress accessibility tooling from basic compliance checking to enterprise-grade auditing capabilities. The successful internationalization effort and technical migration to JavaScript-based scanning position the platform for continued growth as global accessibility regulations expand. The integration of AI development workflows and hosting partner APIs suggests the accessibility scanning market is evolving toward more automated, integrated solutions that reduce the technical barrier for organizations pursuing compliance. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] MultiSite plugin centralizes accessibility management across networks > [!quote] [2025 Year in Review](https://youtu.be/M7p4GFbugP0) by [[Accessibility Checker]] via [[YouTube]]. Published 2024-12-27. Accessed 2024-12-27. > "Allows users to basically have full control over how their licenses get applied across a multi network." Critical for agencies managing multiple WordPress installations with accessibility requirements. [view highlight](https://youtu.be/M7p4GFbugP0?t=210#H1) #xref #accessibility #multisite ID:rw_multisite_management ### [H2] JavaScript scanning provides dramatically better accuracy than static analysis > [!quote] [2025 Year in Review](https://youtu.be/M7p4GFbugP0) > "It is literally the difference between making an educated guess and actually being able to see what the thing is going to look like." Fundamental shift in automated accessibility scanning methodology toward live page rendering. [view highlight](https://youtu.be/M7p4GFbugP0?t=3525#H2) #xref #scanning #javascript ID:rw_js_scanning_accuracy --- ## Full Transcript [00:05] All right, we are live. [00:10] Hey, [00:10] >> how's it going, William? [00:12] >> Yeah, going good. [00:16] >> Last one of the year. [00:17] >> Last one of the year. We made it. All [00:19] right. [00:21] Looks like we are live on YouTube. [00:27] uh [00:29] check out X and see if we're live there [00:31] as well. [00:37] And it looks like we are live. All [00:40] right, I'm going to I'm going to repost [00:42] this. [00:48] We're live. Today we are talking about [00:52] the year in review. We made it, William. [00:54] It's December. How do you feel? [00:57] >> Tired. [00:58] >> Tired. [01:00] >> It's been a long year. [01:02] >> Long year of long year of feature [01:04] updates on the accessibility checker. [01:07] >> Yeah. Feature updates and you know, a [01:10] bunch of other things. [01:11] >> Yeah. [01:12] >> Nonaccessibility checker things. [01:14] >> Non life raising children. [01:18] >> Yeah. Just pretend that doesn't happen. [01:20] That's probably the hardest part of [01:21] everyone's life. [01:23] >> Yeah. Yeah. Cool. Well, it looks like [01:26] everything's going out. [01:30] So, yeah. So, welcome to the live [01:32] stream. If anybody's joining or watching [01:34] after the fact, uh we appreciate it. Um [01:38] we are going to take a little bit of a [01:40] uh look back. You know, it's kind of [01:42] like those old sitcoms, right? Where [01:44] they would have that episode that was [01:46] like the flashback episode, [01:47] >> the filler episode, [01:48] >> the [01:51] what I mean. [01:54] Yeah, the filler episode. Don't call us [01:56] out. It's not a filler episode. This [01:58] episode is going to be packed with all [02:00] kinds of helpful information about [02:03] accessibility checker and what we did [02:06] this year and and kind of uh the the uh [02:09] struggles, [02:10] a little bit of the uh how the sausage [02:12] is made for the year. Um but yeah, so [02:16] this is going to be our flashback [02:18] episode, our [02:20] our greatest hits of the year. So, [02:24] well, we're glad that you're you're [02:25] joining. If if you're not aware, we we [02:28] have this uh live stream every couple [02:32] weeks and we talk about new features and [02:36] uh thing upcoming features and changes [02:38] to the accessibility checker. And this [02:41] is intended to be a little bit of a [02:43] technical uh deep dive, but also a [02:45] little bit of an informative uh live [02:48] stream for users of accessibility [02:50] checker or potential users of [02:52] accessibility checker. [02:54] Accessibility checker is a WordPress [02:56] plug-in that is an automated [02:58] accessibility uh scanner to help you [03:02] identify uh accessibility issues on your [03:06] website and fix those accessibility [03:08] issues. [03:11] So, [03:13] what do you think, William? We jump [03:15] right into the year and review. So, I [03:18] >> Yeah, [03:19] >> I thought we would start with kind of [03:21] the the big hitters, right? Like some of [03:24] the major things we did this year. So, [03:26] it wasn't just [03:28] um [03:30] it wasn't just fixing bugs, squashing [03:33] bugs, and creating new features and [03:35] accessibility checker. actually released [03:37] two new plugins this year. Uh do you [03:41] want to talk about the first one? [03:43] >> Yeah, so the first plugin we released [03:45] this year was the multi-sight plugin. It [03:48] allows users to basically have full [03:51] control over how their licenses get [03:53] applied across a multi network. Um some [03:57] users might have you know five site [04:00] license but a network that contains [04:02] seven sites. they get to prioritize [04:04] which site get those license and you [04:07] know when I say five sites that might [04:09] not be [04:10] that may not be so troublesome to visit [04:12] each site individually and apply your [04:15] license but when we're talking about [04:16] license sizes that reach you know 50 [04:19] licenses [04:21] people are not going to want to manually [04:22] go to all of those sites. So primary [04:25] reason for this plugin is management of [04:28] the licenses. Um as a side benefit all [04:32] the things that are required to rig up [04:34] to manage licenses also allows you to [04:37] see all of the errors and warnings [04:38] across the entire network as well. So in [04:42] addition to managing your licenses, you [04:43] can also see the current stats of all of [04:46] these sites in the network. Um you don't [04:49] need to have the license activated on [04:51] all of these sites to get stats. [04:53] Obviously, we have the free plugin that [04:55] runs completely without a license and [04:57] has full scan, all the same rules, all [05:00] bu. [05:01] So, all of the site stats will be [05:04] available to see in this plug-in in [05:07] addition to managing the license. Um, [05:10] and while you're managing the license, [05:11] you're also if you have if you have the [05:14] professional single site license, you [05:16] get the plugin, the pro plugin, but on [05:19] higher tiers, you get access to some of [05:21] these add-ons. And we, you know, again, [05:24] all the things that were required to be [05:25] rigged up to manage the licenses meant [05:28] that we could also manage all of these [05:30] add-ons all from this one single page. [05:38] >> Yeah. And uh that is a great [05:42] explanation. [05:43] Also settings. Did you mention settings [05:45] about [05:46] >> I did not mention settings. So why would [05:48] you configure 50 different sites when [05:50] you can just come here, configure one, [05:52] and then clone your settings across all [05:53] of them? [05:54] >> Yeah. Yeah. [05:55] >> So this is probably [05:57] I haven't actually used this feature [05:58] myself. I think this probably saved a [06:00] few people many many hours of time. [06:03] >> Yeah. Yeah. Yeah. So you can basically [06:06] you can choose a uh a network default [06:09] site any site on your WordPress [06:11] multi-ite as the default. [06:14] We have a a drop down to choose which [06:17] site and then you can select the other [06:21] sites and then you can choose copy [06:23] settings from the default site and you [06:25] apply that. It's actually going to set [06:28] take all the settings take the settings [06:30] from that one master site and and copy [06:33] it to all the the other subsites. [06:37] So yeah, so this is a very uh uh very [06:41] awesome plugin for people managing large [06:46] networks for agencies and this is an [06:49] add-on plugin to that uh to the agency [06:54] customer level plan for accessibility [06:57] checker. [06:59] >> So users with what 20 licenses [07:03] >> Yeah. Yeah. Yeah. Yeah. So [07:05] >> you're not going to want to visit 20 [07:07] individual sites in a network, [07:09] >> right? And a little bit of a teaser for [07:12] like things to come. We we have had some [07:14] internal talks about bringing some of [07:17] this uh being able to export and import [07:20] settings uh to the uh accessibility [07:23] checker pro plugin um for people that [07:26] are setting up large networks of sites [07:30] that are not inside of a multi-sight [07:31] install. So trying to bring that feature [07:34] to our our our premium pro plugin as [07:38] well. Cool. So that's multicide. [07:41] Anything else on that? [07:43] >> Um I don't think so. I think this covers [07:45] all the features. It doesn't have a lot [07:47] of features of its own. It just takes [07:49] advantage of features of, you know, all [07:52] of the individual network sites. [07:54] >> Yeah. Yeah. Totally. [07:57] And we released this plugin early in the [07:59] year. We actually started it uh I think [08:03] late last year and then of course we [08:05] went through development and by the time [08:07] we got everything ready to launch it was [08:09] it was the new year. I think we launched [08:10] this in January. [08:12] >> Wow. That long ago. [08:14] >> Yeah. So any any of our current agency [08:18] uh license holders uh if you haven't [08:21] tried it and you're running a [08:22] multi-sight uh give it a try. Um, so the [08:27] next big feature, so we mentioned this [08:29] in our last live stream. So we'll kind [08:32] of just touch on it here and not go too [08:34] deep, but the uh the next plugin we [08:38] released is actually not an an [08:40] accessibility checker add-on. Sure, it's [08:42] complimentary to accessibility checker [08:44] because it's kind of accessibility [08:46] adjacent. Um, is the archive WP plugin. [08:50] This is a premium only standalone plugin [08:54] that doesn't require accessibility [08:56] checker. Um, and it is a a plugin to [09:00] help you manage outdated content while [09:02] maintaining accessibility accessibility [09:05] compliance. [09:06] Um, so has a lot of features in it like [09:10] where you can you can take your post and [09:12] migrate them to a a custom post type [09:15] called archived content and um it'll [09:19] store all the metadata all it'll migrate [09:21] the terms to a a new taxonomy so that [09:24] you can have frontend views to filter [09:26] those. It'll automatically assign uh 301 [09:29] redirects. Um, you can act you can [09:32] revert these changes as well. If you [09:34] migrate a post and you realize that, oh, [09:38] I shouldn't have done that. You can [09:39] actually restore that to its original [09:41] location. And by location, I mean its [09:43] original custom post type and its [09:45] taxonomies will be restored to their [09:48] original location as long as those [09:50] taxonomies uh still exist. Um, but not [09:55] only is it utilitarian in that in that [09:57] way that it gives you this tool to [09:59] migrate between these custom post types, [10:02] it also comes with a full set of blocks [10:05] and patterns to help you help you create [10:08] the front-end page. So, we have three [10:10] blocks in there uh uh for for the uh [10:14] there's a disclaimer. So, this is for [10:16] accessibility compliance labeling your [10:18] content as archived content. Um, and [10:23] just a little side note on that and the [10:25] reason why you would want to archive [10:27] content from an accessibility standpoint [10:29] is uh a lot of a lot of u a lot of laws [10:34] and regulations around accessibility [10:36] will allow for an exclusion of archived [10:38] content. So if you label content as [10:42] archived and you don't update it after [10:44] that fact um that it can be considered [10:48] archived content and and it may be [10:50] excluded from certain accessibility [10:53] requirements. [10:54] Um so we've got these blocks. So we got [10:56] a disclaimer block uh in there. We've [11:00] got a uh a filters block which holds all [11:03] the the filters. So you can filter by [11:05] the custom post type. You can filter by [11:07] the original custom post type. You can [11:09] filter by the uh migrated terms and uh [11:13] you can filter by a search keyword [11:16] search and and then there's a third [11:18] block uh which is actually the loop [11:20] output which is a dynamic it's it's [11:23] dynamic you know um dynamically loaded [11:26] content that loads uh your loop and it [11:29] loads it real fast and it refreshes [11:31] without a page refresh and um and then [11:34] we've taken those blocks and we've given [11:36] you a couple patterns as well so that [11:39] you can apply this directly to a page [11:41] with just one click of a button. You've [11:43] got this pattern for like a left align [11:45] layout or a right align layout and or a [11:49] actually we remove the right align [11:51] layout. Sorry, the left align layout and [11:53] the center align layout um because it [11:57] really doesn't make sense to put filters [11:59] on the right hand side and it causes [12:02] some weird you know flow issues for [12:05] >> index. Yeah. [12:07] Yeah, totally. And uh so the the archive [12:11] WP plugin is is a fullfeatured plugin to [12:15] help you manage archived content. And we [12:17] worked really hard on this in October. [12:21] Uh William and I were uh just are [12:24] getting carpal tunnel from all the [12:27] typing or all the prompting. [12:31] >> I think you did an awful lot of [12:32] prompting on this one. By the day I came [12:35] in, I had to clean up some of that [12:37] prompt work. [12:38] >> Well, you know, that's an interesting [12:39] take, right? So, we've [12:42] uh kind of the history of accessibility [12:44] checker is that, you know, accessibility [12:45] checker is getting ready to turn five [12:47] years old. So, next year, accessibility [12:50] checker will go to kindergarten. [12:52] Um, we've raised [12:56] um and and five years ago, you know, AI [13:00] was not part of our development [13:01] workflows. Not at all. I mean it it [13:04] didn't exist. Open AAI may have just [13:06] been a a comp a recently founded company [13:10] at that time. Um, so you know, we used [13:14] to write every line of code by hand and [13:16] uh nowadays we've got a lot of AI [13:19] implemented in our workflows and I think [13:21] the archive WP was probably the first [13:24] big plug-in that we uh tried to [13:28] implement that to to its fullest with [13:31] without going down the the road of vibe [13:35] coding which you're not going to you're [13:37] never going to get uh to [13:39] >> I don't see people making viable [13:41] products. No. [13:42] >> Yeah. With five coin. Maybe maybe next [13:44] year. [13:45] >> Yeah. Yeah. Yeah. [13:47] >> So, we call it what do we call it? We [13:49] call it pain prompting. Is that what we [13:50] call it? [13:53] >> I think it was a bit painful sometimes. [13:55] Although, to be fair, the AI [13:58] >> built a lot of things that might have [14:00] been quite complicated for a human. [14:02] >> Yeah. [14:03] >> In this in this plug-in and it did [14:05] require cleanup. I don't think the AI is [14:07] quite at the point where it writes fully [14:09] production ready code. someone is still [14:12] going to have to follow behind. you [14:14] know, where it's it's kind of [14:16] interesting like with the archive WP [14:19] plugin how uh [14:22] the the AI would lead to discovery in [14:26] some sense where you would you would you [14:28] would kind of ask you use the ask [14:30] feature to ask questions about [14:32] you know should this you know should [14:34] this should this redirect or like you [14:37] know like uh or it would come up with [14:39] kind of it would kind of come up with [14:40] ideas and you're like you know what that [14:41] might be a interesting feature to add to [14:44] the plugin. So in some sense it's it's [14:47] good for discovery of features when [14:49] you're kind of massaging a plugin like [14:50] archive WP into its final state because [14:54] that was one thing that kind of I found [14:57] interesting about archive WP was the [14:59] initial idea of it and and a little bit [15:01] of background on that is that this was [15:03] actually a a plug-in that we created for [15:06] a customer for one of our remediation [15:08] customers that needed uh something [15:12] similar and and and and we had the idea, [15:16] well, other clients are going to need [15:18] this. We have more clients that need [15:20] this and why don't we make it so that [15:22] it's something that can be utilized [15:24] across um many websites. And as any [15:27] developer knows, making something for [15:29] one website [15:31] and making something for all websites is [15:33] quite the feat. [15:35] >> It's quite a lot of additional work to [15:36] make it work across websites. [15:40] So the the original U version like used [15:43] like short codes to output stuff and was [15:46] very opinionated on its design and [15:50] layout whereas archive WP is very [15:52] nonopinionated on the design and layout. [15:55] Now we've [15:56] >> I will I will step in actually here and [15:58] say that while the original [16:00] implementation of this on the client [16:02] website was based on short codes and we [16:05] have built this plug-in based on blocks, [16:07] short codes are still available and they [16:09] are fully equivalent to the blocks. So [16:11] if you have a website that does not use [16:12] the block editor or a custom postite [16:15] that is not yet block enabled, you are [16:18] still able to use these blocks wherever [16:20] you choose just by implementing the [16:22] short code. Um, secretly you might [16:25] discover there's some additional [16:26] features of those short codes that [16:28] weren't exposed to the blocks. Someone [16:30] wants to do some digging in. [16:32] >> Yeah. Yeah. So the there's a lot of um [16:36] attributes under the hood and that's [16:38] what William's trying to say. [16:40] >> Yeah. And um and we archive WP does have [16:44] a a a onboarding wizard that will [16:47] actually help you build this page. It'll [16:49] create the page if you haven't created [16:50] it or it'll let you choose an existing [16:52] page and it'll actually implement the uh [16:55] the block patterns or the short codes [16:57] with a tiny bit of HTML markup to kind [17:01] of get some layout into a uh classic [17:04] editor page. Um, so what we've tried to [17:08] do with ArchiveWP is we've tried to make [17:11] this process as easy and seamless for [17:14] the enduser to to one get the plug-in [17:17] installed to get a page created and to [17:19] archive their content. Literally within [17:21] a few clicks, you can have all your [17:23] content archived into its own custom [17:26] post type isolated from all the other [17:29] custom post types with disclaimers for [17:31] accessibility compliance. [17:33] And uh it took a lot of work to get uh [17:37] from that initial piece that we made for [17:38] the client to a fully functional uh [17:42] premium plugin. [17:44] So looks like uh we have Daniel on the [17:48] live stream. [17:50] >> Oh, hi Daniel. [17:52] >> And Daniel says, "Thank you for all the [17:54] improvements this year." Well, [17:58] our pleasure, Daniel. Oh, [18:00] >> so so I was on a call with Daniel a [18:02] couple of weeks ago debugging the thing. [18:04] So it's nice to see people [18:06] >> Oh, awesome. [18:06] >> People coming in. [18:07] >> Cool. [18:09] >> Any more problems, just reach out. [18:11] >> Yeah, we're here to help. Daniel, thanks [18:14] for joining us and uh look forward to a [18:17] lot more next year. We are in the [18:19] planning phases of uh features and new [18:22] things for accessibility checker for [18:24] next year. [18:27] Cool. So those are the major releases. [18:30] So two new plugins this year. Um [18:34] but we didn't neglect our existing [18:36] plugins and we have done a lot on that [18:40] side. So this next uh feature I don't [18:44] know if feature is the right word but [18:46] this next uh area that we implemented [18:50] throughout all the plugins it was was [18:53] kind of huge. And if I'm being a little [18:55] honest, uh, William and I were a little [18:58] apprehensive to, uh, undertake this, uh, [19:01] because we knew it was going to be quite [19:04] the undertaking. So, [19:06] >> this was a lot more effort than expected [19:09] and also exposed some [19:12] interesting things for me about the way [19:14] WordPress handles this under the hood. [19:17] >> This is my first deep dive into this in [19:20] a very long time. [19:23] >> Yeah. Yeah. So, do you want to say what [19:25] it is, William? [19:26] >> Yeah. So, we fully we we tackled [19:29] internationalization [19:31] of our plugins this year. So, we have [19:33] made them fully translatable [19:37] as far as we could. If you find anything [19:40] that's missing translation functions, [19:41] let us know. But we're quite confident [19:43] we've caught everything at this point. [19:47] And we translated the plugins, our [19:50] entire suite into [19:53] 30 [19:54] plus languages, at least 32, but some [19:57] plugins have a couple more. [20:00] >> Yeah. [20:01] So So what does that mean? Why why why [20:05] would we do this? [20:06] >> Well, accessibility of content is not [20:09] necessarily just about how the content [20:12] behaves in the browser. Sometimes it's [20:15] inaccessible for someone because they [20:17] don't speak English and that you know is [20:20] a problem for well more than half of the [20:22] world does not speak English and now our [20:25] plug-in is available to a lot more [20:27] people who will now be able to take [20:29] advantage of these features and the user [20:32] the users of our plug-in our plug-in [20:35] becomes more accessible due to the [20:36] translations and the users of those [20:38] people's websites become more accessible [20:41] due to the fixes that we provide or help [20:43] these site owners do. So, it it's it's [20:46] partly about reaching more people, but [20:48] it also is just it's just the right [20:51] thing to do [20:52] >> actually. [20:54] >> Yeah. I mean, basically um uh [20:57] translations and internationalization is [20:59] is accessibility like and it's and it [21:03] really is. it it actually is taking the [21:05] accessibility checker and then making it [21:07] available for more more people and and [21:11] in doing so, right? Um and it goes to [21:14] show sometimes your own like uh [21:16] apprehensions or I mean dare I even say [21:19] our own biases when when you kind of say [21:23] well we don't need to do that right or [21:24] like that'll take so much time it's not [21:26] worth the time or something and you [21:28] don't think it's really going to have a [21:30] benefit. Um to our surprise, we think it [21:33] has had quite the benefit in our install [21:36] counts from from different countries. Um [21:40] Germany being probably the the top [21:42] country that we've seen uh the most [21:46] adoption from after implementing this [21:49] internationalization. Now, there's some, [21:52] you know, that coincides with a lot of [21:54] uh, you know, the European Accessibility [21:56] Act coming into place and and Europe [21:58] having pro or not Europe, uh, Germany [22:01] having [22:03] probably some of the more stricter uh, [22:05] requirements. I [22:06] >> I think they're definitely a first to [22:08] implement type country where they lead [22:10] the way in a lot of these things. Um, in [22:13] addition to Germany though, I have [22:14] noticed an awful lot more Asian users [22:17] coming in and you know identified by the [22:20] fact that I can't read their names [22:23] sometimes. [22:24] >> Yeah. [22:24] >> Um, coming in in Korean, Japanese, [22:28] um, so lot more people in languages that [22:30] I would not have expected. I mean, these [22:33] are countries that might not have the [22:35] same regulations in the way that um, [22:38] Germany does. [22:40] >> Yeah. Yeah, but these these are still [22:41] using our plugin and maybe they would [22:44] have if we hadn't translated it or maybe [22:46] they wouldn't like we we'll never know [22:48] because we now offer these translations. [22:51] >> Yeah. Yeah. [22:53] Yeah. I think it was great. And I think [22:55] it it it's a little bit of a us [22:57] practicing what we preach and um and we [23:01] implemented this just before our team [23:03] went to [23:05] uh work camp Europe and uh so that we [23:07] could have we could take we at us as an [23:10] American company flying over to Europe [23:13] um saying hey you know we're here to [23:15] support you as the accessibility uh the [23:18] European accessibility act comes into [23:20] place. It was it was kind of on us to [23:23] kind of practice what we preach a little [23:24] bit. If we're going to support these [23:26] these European countries and and and [23:29] other countries, Asian countries [23:30] throughout the world, that we should [23:33] make this plug-in readable to everybody. [23:36] And um [23:39] and and I think it was probably one of [23:41] the best things we did this year. And um [23:44] >> it it definitely has it was worth the [23:47] time. [23:48] >> Yeah. Yeah, [23:48] >> can't say that about every feature that [23:50] we try. You know, you hindsight is [23:53] great. In hindsight, we were mistaken to [23:56] put this off for so long. [23:58] >> Yeah, I think so. So, from a technical [24:02] perspective, [24:03] I mean, how do you how do you translate [24:06] a plugin to that many languages? like [24:08] well before we say how we get into [24:11] translating it for so many languages [24:12] let's just maybe talk a bit about how [24:14] translations in WordPress works because [24:16] this is the first time I have undertaken [24:18] a large [24:21] translation project in WordPress since [24:24] the since the more common [24:27] I want to say commonization I don't [24:29] think that's a word but it's the closest [24:31] that I can get to um strings inside [24:35] JavaScript files is [24:39] far more common now than it would have [24:41] been just five or six years ago. And PHP [24:44] we have well understood translation [24:47] functions. You know we use the double [24:49] underscore type functions and you know [24:53] it does static analysis using get text. [24:56] So it finds the translations it converts [24:59] it into a pot file. Translators can take [25:01] the pot file they can generate [25:03] individuals for their each language. So [25:07] it is static analysis. However, when you [25:10] have JavaScript in your plug-in, quite [25:12] often you use minification or [25:15] uglification of the JavaScript code [25:18] because we always want to deliver the [25:20] smallest packages possible to the [25:22] client. And when that code has been [25:24] minified or uglified, it's really quite [25:27] difficult to discover where those [25:28] strings are inside of the content. And [25:31] this was a challenge I didn't foresee [25:33] being a problem, but it ended up [25:35] actually being a huge issue for me is [25:37] how to find these strings inside [25:41] minified JavaScript files because we can [25:43] find them quite easily in our source [25:45] code because it's nice broken into [25:48] lines. All of the all of the tokens [25:50] still exist there, but in the minified [25:53] files, we had to do some configuration [25:55] hurdles to get it to keep those [25:58] translation files there. And once you [26:00] have those translation files, they [26:02] actually don't get built in the same way [26:03] and delivered as PHP translations do. [26:07] There's actually JSON files that you [26:09] also need to deliver to the client side [26:11] whenever there's a translation [26:12] available. So yeah, translations are a [26:15] lot more complicated than they used to [26:18] be if you have to support JavaScript, [26:20] which in this day most of us have to [26:23] support JavaScript translations. [26:25] >> Yeah. Yeah. Yeah. [26:27] So uh yeah. So we had some technical [26:29] hurdles to get over. We actually had to [26:33] kind of set our mindset a little bit [26:35] around it too where it was like our [26:38] plugins are are our strings are mostly [26:40] all translated. there might be some like [26:43] low lowhanging strings that were kind of [26:46] missed over the years and it was kind of [26:49] like in our heads we're like well we [26:50] just need to we need to get the [26:53] mechanism in there to translate these [26:56] and and these translations are a little [26:59] bit AI assisted and um we need to have [27:03] the workflows built into our pipeline so [27:06] that these translations happen with [27:08] every release and then once we have that [27:12] then we can kind of go back and and [27:14] clean up code where there are some [27:16] strings that may not be translated uh [27:19] correctly. Uh so in our heads it wasn't [27:21] like oh we've got to go through five [27:23] plugins fix all the strings and no it [27:26] was like let's put the mechanism in [27:28] place things are translated all the [27:30] strings like 90% of the strings are [27:33] ready to go let's just put the mechanism [27:35] in place and get the the translation [27:38] files for those and then we'll go [27:40] through Turns out that once we had put [27:42] the mechanisms in place, it became much [27:44] easier to discover where we had missed [27:46] the string somewhere because we could, [27:48] you know, I'm pretty sure I could [27:50] confidently navigate and read our [27:53] plug-in in French at this point because [27:55] French was the language that I chose [27:56] when I was debugging things. But if [27:59] you're reading, you know, the settings [28:01] in French and suddenly you see an [28:02] English word, [28:04] >> you know, that's missing a translation [28:05] function. And that really did help us to [28:07] get I I want to say almost all of them [28:10] but at very least we have covered 98% of [28:13] all of the strings in our plugin. [28:16] >> Yeah. Yeah. Totally [28:19] cool. So let's move on to um [28:23] accessibility checker pro. So what did [28:26] we do this year in accessibility check [28:27] checker pro? So we we expanded the [28:31] scanning capabilities. Uh we added the [28:34] ability to scan post type archives and [28:36] taxonomy terms which we've spoken about [28:38] on a previous change log liveream. Uh do [28:42] you want to speak to that at all [28:44] William? [28:45] >> Yeah so that was a a fiveyear desirable [28:49] feature that took a very long time to [28:52] implement. That feature predated me even [28:54] working on any of this code. I didn't [28:56] know that was a feature that was [28:57] desirable. [28:58] >> Mhm. [28:59] >> Um at first, but it turns out quite [29:01] desirable. Um Steve actually came up [29:04] with the the way we could solve this [29:06] under the hood is effectively building [29:09] our entire plugin is set up around the [29:11] the ethos of post IDs and archive pages [29:15] do not have post IDs which was the real [29:17] complication here and Steve had the idea [29:20] of why can't we just virtually create [29:22] these IDs and as such we do we just [29:26] virtually create a post for every single [29:29] one of the archive terms that want to be [29:30] scanned and we and store our data on the [29:34] virtual post, allowing us to scan every [29:37] single archive page you have on your [29:39] site, which includes custom post type [29:42] archives, as well as all your taxonomy [29:44] archives like categories, tags, or any [29:48] custom taxonomies that you create that [29:50] have archives visible. So yeah, all of [29:54] those pages are now scannable and you [29:56] can get results in exactly the same way [29:58] that you would get results for typical [30:00] posts. They're reflected in your overall [30:03] site report. And if you know if you have [30:06] the exporter plugin, you can export all [30:09] those results as well and filter them to [30:11] the individual archive that needs fixed. [30:15] Um I will say that I discovered that you [30:17] usually don't need to scan every single [30:19] archive. So, we do have some form of [30:22] like smart sampling built in because if [30:25] you have one category archive, it's [30:28] probably the same as all the other [30:29] category archives in terms of its [30:31] construction. So, you theoretically only [30:33] need to scan one. Um, but what we do [30:37] have is we scan one that is [30:41] representative of a maximum number of [30:43] posts. So, it will show pageionation and [30:45] the minimum number of posts. So ideally [30:46] it won't have pageionation and you know [30:49] so we cover at least two at least three [30:53] taxonomies [30:54] >> or each three pages per taxonomy type. [30:58] >> Yeah. [30:58] >> In in the smart sampling mode. You can [31:00] of course turn on full sample and you [31:03] can just scan every single page which is [31:06] probably what a lot of customers might [31:08] end up doing but [31:10] >> right [31:10] >> that can take a very long time if you [31:13] have thousands of terms [31:15] >> and and and lots of custom post types. [31:19] >> Yeah. Yeah. So this was just this like [31:22] William said five years ago this was [31:24] probably like this is probably feature [31:26] number one that was on our list and uh [31:29] and it just got kept getting pushed [31:31] because of the complications around it [31:33] like William said about you know archive [31:35] pages are dynam dynamically generated [31:39] pages you know on they're generated on [31:41] the fly basically and and there's no [31:44] there's no post ID there if there's no [31:47] post ID there's no post meta [31:50] And the accessibility checker requires [31:52] post meta quite a bit. And so us coming [31:56] up with a u us putting our engineering [31:59] heads together and coming up with a a [32:01] unique way to slot that into the plugin [32:03] without a complete refactor of the whole [32:05] plugin was a huge win for us and a huge [32:08] win for uh our users. uh so now that [32:12] they can they can get more coverage in [32:14] their scans and have uh more assurance [32:17] that uh their website is uh being [32:20] scanned for accessibility compliance. So [32:22] along with with that William you want to [32:24] talk about the next one [32:26] >> performance wins. [32:28] >> Well before that there's there's a [32:30] bullet point [32:31] >> oh [32:31] >> above that. [32:33] >> Yeah. Yeah. So you you have a post page [32:36] and a front page on in most WordPress [32:39] websites and [32:41] previously we weren't always scanning [32:43] them depending on what the configuration [32:45] is. So now we actually go out our way to [32:48] make sure that we do scan your blog [32:49] page. Um and also your you know front [32:53] page if you know your front page is [32:55] almost always going to have an ID [32:57] >> but your blog post [32:59] may not if you have not assigned a [33:01] static page to it and if you had not [33:03] assigned a static page to it we [33:05] previously might have missed it but now [33:07] that isn't the case. We will actually [33:08] try and scan that page all the time now. [33:12] >> Yeah. due to the fact that we could it's [33:14] technically an archive for the posts and [33:16] is now discoverable and virtually [33:19] exists. [33:21] >> Yeah. So um just like another it's not [33:23] an archive page but kind you know but it [33:26] is kind of a [33:27] >> an archive page internally. [33:28] >> Yeah. But we can't capture it as an [33:30] archive page the same way. So we've gone [33:34] the extra step to kind of consider that [33:36] as well. Now there is some other [33:37] considerations beyond archive pages and [33:40] ma main post and blog post page and [33:45] there are other things that we're [33:46] looking to add in such as uh [33:49] uh author pages and was there anything [33:52] else besides that? [33:53] >> Um so I did previously look into for my [33:56] own use um element templates. M [34:01] >> so you know not only can we scan actual [34:05] things that are considered as pages we [34:07] can probably quite soon start scanning [34:10] things that are considered as partials [34:12] such as element templates page templates [34:15] for Gutenberg [34:17] >> um you know [34:19] any number of individual components that [34:23] page builders implement that are [34:25] available through some form of URL URL [34:28] rewrite fees feasibly we can create a [34:30] virtual post ID for and scan in a live [34:33] page type of way. So no immediate plans [34:37] on what we will scan next but floodgates [34:40] are ready to open on that one. There's [34:43] lots of options of what we could scan. [34:46] >> Yeah, totally cool. So like you said [34:50] performance um so this year we [34:53] >> Amber did actually just comment in FSE [34:55] templates. [34:56] >> Yeah. Yeah. Exactly. Yeah. Yeah. Yeah. [34:58] Totally. [34:59] >> Soon PM. [35:02] >> Yeah. Yeah. So, fullsight editing [35:05] templates. Yeah. Exactly. That's uh um [35:09] those are little pieces that we could [35:11] probably push through the same mechanism [35:13] that we did the uh the archive page. And [35:17] uh now there is a whole there's a bigger [35:20] picture here too, right? like we c we [35:22] can keep kind of chasing the [35:25] the WordPress rewrite template part [35:28] thing or we could switch how [35:31] accessibility checker works and actually [35:33] start pulling from direct URLs based off [35:36] of sitemap or some kind of scraping of [35:39] the website. So [35:41] um yeah totally. Um [35:47] so performance um this was kind of a big [35:50] one but I feel like this was kind of a [35:52] feature that was uh implemented kind of [35:54] under the radar. It it was so this was [35:57] actually performance of the full set [35:59] scanner was looked at partly due to [36:04] >> I don't want to say a great many but a [36:05] larger than other issues type of support [36:09] request that comes in is to do with the [36:11] full set scanner particularly how fast [36:13] it is as we all know it isn't actually [36:16] very fast in a lot of cases. Um, so as [36:20] part of some of those complaints from [36:22] users, we re we looked at how the [36:24] queries work, how we gather the posts [36:27] and you know, first off, we actually [36:29] made it immediately faster by dropping [36:32] one half of our scanner. [36:34] I mean, we dropped the faster half. We [36:37] had the two-part scanner, we dropped the [36:38] faster half, so we're only left with the [36:40] slower part, but that does speed up the [36:43] scanner generally. But in addition to [36:46] that, there was query optimizations and [36:48] some caching added that actually does [36:50] for it won't benefit the majority of [36:52] sites, but for large sites, you you're [36:55] looking at five, six, 7, 10, 20 times [36:59] faster sites for very very large sites. [37:02] Like if you have a site that has 100,000 [37:05] posts on it, the full site scanner will [37:09] be dramatically faster for you after we [37:12] made those query optimizations. And [37:13] there are definitely more of them to [37:16] come. [37:16] >> Yeah. Yeah. Um we'll talk about this [37:19] here in a little bit too on why we [37:21] dropped that first half of the scanner. [37:23] When Williams says we dropped the first [37:24] half of the scanner, what we're talking [37:26] about is there it used to have two [37:28] passes. There was a [37:30] >> a a you know it was behind the hood [37:33] under the hood. It was a PHP scan and [37:35] then it was a JavaScript scan because we [37:37] had some rules that were written in PHP [37:41] and all we had to do was parse HTML for [37:44] that and then we had some rules that [37:45] were written in JavaScript which [37:47] actually would pull up the actual [37:50] website page and scan it from the front [37:52] end with the full render. [37:53] >> Well, actually at first all of the roles [37:56] were in PHP aside from color contrast. [38:00] So [38:00] >> we would run the JavaScript scan only [38:02] for color contrast at first, which [38:04] unfortunately is the slower half of the [38:07] scan. [38:08] >> Yeah. Yeah. [38:10] >> But more accurate half. [38:11] >> Yes. Dramatically more accurate. [38:14] >> So [38:15] >> I mean that's why we we could not do [38:17] color contrast in the PHP scan the first [38:20] half. [38:22] >> Right. Right. And and actually even [38:24] going further back when you know we [38:26] talked about accessibility checker. It's [38:27] getting ready to turn 5 years old. [38:30] um that the scan was all initially PHP [38:34] and even our color contrast was PHP but [38:36] out of the necessity to make it more [38:38] accurate we started switching that to [38:41] JavaScript over time and like I said [38:43] here in a little bit we'll talk a little [38:44] bit more about that switch to JavaScript [38:47] but uh aside from that um William has [38:52] done a lot to implement uh to make the [38:55] plug-in much more WP CLI compliant and [38:59] or I don't know if compliance is the [39:01] right word but uh ready we've been [39:03] working on a lot of our own commands and [39:05] >> yeah so selfishly because I had actually [39:08] created some commands for my own [39:11] development purposes that later on was [39:14] answered or mentioned by [39:18] um Chris had mentioned that a client had [39:20] asked for some of these WPCLA commands [39:22] and I was able to say like oh yeah I've [39:25] been using that already That's [39:28] >> that's mines. I had to do a bit of clean [39:29] up to make it production ready, but now [39:32] we have shipped a handful of WP CLA [39:35] commands and we have added a couple more [39:38] over time. Um, primarily [39:41] maybe the most useful one for an average [39:43] user would be a programmatic way of [39:46] getting the individual [39:48] scan stats for a single page if you had [39:51] such a need or you know the full site of [39:55] scan stats as also if you had such a [39:57] need. And I can imagine a a few people [40:00] might programmatically want to grab them [40:02] rather than having to log into a whole [40:04] bunch of individual sites and check [40:06] their numbers, right? [40:08] Yeah. And things like uh license key [40:10] activation, deactivation, [40:12] um adding the license key, things like [40:15] that. Um and a lot of that was done in [40:17] prep with some uh some of the [40:18] partnerships that we've uh uh put [40:23] together this year with some of our [40:24] hosting partners. Um so that they can be [40:27] able to run CLI commands in their [40:29] pipelines to be able to uh activate and [40:32] deactivate and add license keys to the [40:34] to the plugin. Uh, one of our more [40:37] recent uh, partnerships is with [40:39] Cloudways and uh, some of these uh, [40:41] requests came from them as well to be [40:43] able to do these things. Yeah. Well, [40:46] technically a hosted partnership now can [40:49] retrieve a key from a customer and then [40:52] make everything from that point onwards [40:54] entirely seamless in their platform. [40:56] They could, you know, activate the [40:59] plugin, install, activate, and trigger [41:02] scans across some of the pages [41:04] >> like all entirely programmatically [41:07] before a user even has to make it [41:10] anything other than the purchase to get [41:13] their key, [41:14] >> right? [41:14] >> And and actually they could just install [41:16] free as well. So some of these platforms [41:19] can now seamlessly get that up and [41:21] running, [41:22] >> right? So we're doing more to expand [41:25] accessibility checker uh for hosting [41:27] companies as well so that we can make it [41:29] available to their client base and make [41:32] uh integrating uh it into uh those [41:36] hosting plans uh more seamlessly. So [41:39] hosting companies reach out to us. We'll [41:41] get you an integration and we're we'll [41:44] get up and working. So uh man, we're [41:47] running long on time and we got a lot to [41:48] get through. So, we're going to we're [41:50] going to I'm going to rapid fire some [41:51] more things here. So, on accessibility [41:54] checker pro workflow. So, uh we I'm [41:57] going to run through some of these real [41:58] quick. We added filtering by uh post [42:01] status. So, whether it's a draft or [42:03] published, etc. [42:04] >> And this was a highly requested feature. [42:06] People don't want to scan their drafts [42:08] because they don't see any. They might [42:10] have 10,000 drafts. [42:12] >> Yeah. [42:12] >> They're never going to be published. [42:14] >> Yep. Totally. Uh so, you can filter [42:17] those out. You can actually see the post [42:19] status inside the uh open issues uh [42:22] table in accessibility checker pro. Now [42:26] um we added landmark uh selectors to the [42:30] issues table as well. We're talking [42:31] about this. We added landmarks and free [42:34] as well. We'll talk about that allowing [42:36] users to pinpoint the specific location [42:38] of landmarks. Um so we've just surfaced [42:41] that inside of the open issues in the [42:43] pro plugin. We improved rule [42:46] descriptions and metadata to uh provide [42:49] better context on accessibility issues. [42:51] This was a huge undertaking that uh [42:54] Amber took to rewrite some of these [42:57] descriptions and how to how to fix it. [43:00] Um, we've added uh severity uh to issues [43:04] and we've added some kind of intelligent [43:07] severity sorting to our issues in the UI [43:11] to help you surface not only the is not [43:14] only the issues with the because it used [43:16] to sort by [43:18] errors and warnings and then a secondary [43:20] search on the the issue count. So now it [43:24] it it is extended to sort by um severity [43:29] and then issue count. So what we're [43:31] trying to do inside the plugin is always [43:33] expose to you what you can action on and [43:36] get the the most results from. [43:44] So um [43:47] what else? Let's see. [43:50] And then like I said the severity. So [43:51] that's a lot of the the kind of a lot of [43:54] the big features that we've added to [43:55] Pro. Of course, we are always squashing [43:57] bugs and fixing other things in that [44:00] regard. But let's move on to [44:02] accessibility checker free. We call it [44:05] core sometimes, but the the plugin that [44:08] you can get from wordpress.org. [44:12] And uh [44:14] you want to run through this first one, [44:16] will you? [44:16] >> Yeah. So we added um rescan and clean [44:20] issues buttons and these are just nice [44:23] to have userf facing features. These are [44:25] things that we do programmatically quite [44:27] often by going into the database [44:29] cleaning issues. You know no longer do [44:32] we have to do that as developers but [44:34] being able to clear issues sometimes [44:36] fixes edge case bugs if someone changes [44:39] post types or does unusual things. [44:42] Disable the plugin for a while turn it [44:45] back on. So clean issues just resets the [44:48] post and then you can just click to [44:49] rescan and you can immediately get fresh [44:52] results. [44:53] >> Yeah. [44:53] >> And you can also use that like if you [44:55] have you know don't haven't thoroughly [44:58] tested this with a lot of different [45:00] builders but if you use a front-end page [45:02] builder you now have a rescan button on [45:05] the front end that you can then scan as [45:07] you change your content. It works with [45:08] some builders. I haven't tested all of [45:10] them. [45:11] >> Yeah. [45:11] >> If you have a builder that it doesn't [45:12] work on, let us know. Yep. Yeah. Um we [45:17] know that it works really well with [45:19] Elementor. Um we are [45:22] >> Beaver Builder works with most for the [45:25] most part, [45:25] >> right? And we we currently are uh [45:28] working with Etch to get accessibility [45:30] checker working fully with the Etch uh [45:33] website builder and uh we're looking [45:37] forward to uh implementing that. And if [45:39] anybody any other builders have [45:41] problems, feel free to reach out to us [45:42] and we're we'll get those fixed. [45:46] Um, and [45:48] >> as another nice UI feature, we no longer [45:50] overlap icons on the front end. So if [45:53] you're using the front end highlighter [45:54] and an issue has two different warnings [45:57] or one warning, one error assigned to [45:59] it. Those icons will no longer overlap [46:01] each other. They will be stacked neatly [46:02] side by side. So you can click on each [46:05] one individually and see the relevant [46:08] information about that specific issue. [46:11] >> Yeah. Where before if you had multiples [46:13] stacked right on top of each other, you [46:14] had to use the arrows, the next and [46:16] previous areas to get to them. So [46:18] >> and sometimes those issues might not be [46:20] next to each other in the order stack. [46:23] So you would jump up and down on the [46:25] page. [46:26] >> No. [46:28] Cool. So uh new smarter rules. We are [46:31] always trying to refine our rules to [46:34] make them better. Uh Amber's always [46:37] opening tickets for us to with new ideas [46:39] on how to make the rules uh smarter and [46:42] more intelligent and help with uh her [46:45] own uh audits of things. Uh this first [46:49] one. [46:50] >> Yeah. So it's a shame that Daniel isn't [46:51] still here. He did say he had to drop [46:53] off, but this was what the call I had [46:54] with Daniel a few weeks ago was about an [46:56] another improvement we made to the video [46:58] transcript detection. So if videos were [47:02] not not or the transcripts were not [47:03] directly adjacent in terms of the markup [47:06] there might have been cases where it was [47:07] missed and that was the case on Daniel's [47:10] website. So that is now fixed and the [47:13] detection of video transcript should be [47:15] far more reliable for everyone based on [47:19] that change and it was already quite [47:21] reliable. There was just some edge cases [47:23] that meant it might not work [47:26] >> right. [47:28] And uh landmarks, we've talked about [47:29] this a little bit in on when we're [47:31] talking about pro, but we have added uh [47:34] landmark uh location feature to show [47:36] exactly where landmarks are in the DOM. [47:39] So that's in the front-end highlighter. [47:41] It actually will list you what the uh [47:43] landmark location is in the uh in in the [47:47] details tab in on a post or in the uh [47:50] open issues from the pro plugin. and you [47:53] can click on that and it'll open it up [47:55] in the front end highlighter and [47:56] highlight that landmark location. So, [47:58] just doing more to try to show you where [48:00] issues are and we actually have plans to [48:03] expand that to be able to start [48:05] segregating out issues based on which uh [48:09] which user role should be seeing which [48:12] which issues. So, basically um an editor [48:16] probably doesn't need to see issues in [48:18] the header and footer. Those are global [48:20] issues. Well, they may want to seen them [48:21] still, but they probably can't fix them [48:23] or not in a position to fix them. So [48:25] maybe you might want to show them only [48:27] actionable issues, in which case an [48:29] editor might only see issues that are [48:31] directly inside the content area or the [48:34] main tag. [48:35] >> Yeah. [48:36] So cool. [48:40] Then uh so links we improved checks for [48:44] anchor exists uh missing title attribute [48:47] and new window warnings. [48:49] Was this one you worked on, William? [48:52] >> So, I think I've touched most of these [48:54] rule tweaks over the year. I cannot [48:57] remember [48:59] which ones exactly. Um, however, a lot [49:02] of these were improved from something [49:04] we're going to talk about in a minute, [49:05] the the JS conversion. So, a lot of [49:07] these rules got dramatic improved [49:10] >> accuracy due to some switchovers, [49:13] including the next one that's in this [49:14] list here, the underlying text as well. [49:16] And I will also put Amber a bit on the [49:19] spot here and call out that there might [49:21] also be a naked links roending [49:25] some documentation work. [49:26] >> Yeah, that's my favorite one. Naked [49:28] links. [49:32] >> That that's actually quite a common [49:33] problem that [49:34] >> right [49:35] >> we should be flagging and detecting. [49:37] >> What what is a what is a naked link? [49:39] It's when you just copy and paste a link [49:41] directly from your address bar and it [49:43] might contain all those letters and [49:45] numbers that they use for tracking or it [49:47] might be nested 16 levels deep. And for [49:49] a screen reader, every one of those [49:51] characters is going to be read out and [49:53] that just is a horrible experience for [49:56] someone who might not be visually [49:58] impaired. [50:00] >> Yeah. Yeah, we are. So, we have [50:02] implemented the naked links rule and and [50:05] this is a little bit how the the [50:07] workflow works, right? So, uh, you know, [50:11] a recommendation for a a rule gets added [50:14] to either, you know, our ideas board or [50:18] as an issue in GitHub and and then [50:22] sometimes William or I are have a minute [50:24] and we're we're like, ah, we'll pick [50:26] this one up and then we, oh, that was [50:28] easier. [50:28] >> It never takes just a minute, but there [50:30] >> Well, this one was more complex than [50:32] that, right? But um and then we get it [50:34] and then you know we assign it to Amber [50:36] and we wait for documentation and once [50:38] we get documentation then it we release [50:40] it out to the world for you guys because [50:42] releasing a rule without documentation [50:45] on what does this mean and how do I fix [50:48] it and what are the implications of this [50:50] um is is not a a great uh user [50:54] experience. So, um, but not only that, I [50:58] mean, like when you get the idea for [51:00] like we try to compare like we we use [51:03] Axe core in our plug-in, but an [51:05] extremely [51:07] um extended version of it. We hook into [51:10] it. We change it. We group rules [51:11] together. We we don't use some of their [51:13] rules. We use some of our completely own [51:16] custom rules. And in this case, uh, [51:19] William, the the recommendations that [51:22] came from Amber about what is a naked [51:24] link, um, was was was far more, uh, [51:28] verbose than like what say axe core does [51:31] to detect those, right? [51:34] And, uh, [51:39] >> you good? [51:40] >> I think my internet is being a bit off. [51:42] >> Oh, okay. Okay. [51:44] >> Oh, it is a bit off. Okay. So, William [51:47] is now frozen. So, I will talk. [51:50] >> There's something. [51:51] >> Yeah. [51:52] >> Yeah. [51:53] >> You You talk. Give me one second. [51:55] >> All right. Um, so while William goes and [51:57] kicks his kids off of the internet, um, [52:01] I'll talk about naked links. That's what [52:03] he's doing. The uh Yeah. So anyway, uh [52:08] you know, whether it has a protocol on [52:09] it or doesn't have a protocol on it, [52:12] making those decisions on what actually [52:14] constitutes a naked link, I think what [52:16] we've come up with goes pretty far um to [52:20] making it a very usable rule that [52:23] doesn't create a ton of noise uh for the [52:26] for the end user. So that's a little bit [52:29] of a sneak peek on a rule to come. But [52:33] to that, William, since we're kind of [52:35] talking about rules and JavaScript and [52:38] axe, can you talk a little bit about why [52:40] we decided to [52:42] finally jump and just migrate everything [52:45] over to JavaScript scanning? [52:48] Oh, I can't hear you. [52:50] >> Let me know if you can hear me. [52:53] >> Oh, maybe. Is that [52:56] >> you're [52:56] >> No. [52:57] >> Yeah, there you go. Uh, I think you're [52:59] good. Try to talk. [53:02] Yeah, I think I'm back. I just disabled [53:04] Netflix. [53:08] Oh no, [53:10] he's frozen again. So [53:15] >> yeah, you're still cutting out a little [53:16] bit there, bud. [53:27] >> There we go. You're back. [53:29] I'm back for one second, but I'm [53:32] probably going to disconnect again in a [53:33] second. I'm going to [53:35] >> Yeah. Yeah. [53:35] >> Going to have to shut down some stuff on [53:37] their end. [53:40] >> You on the router cutting them out? [53:43] >> Yeah. And I'm not cutting out the right [53:44] things apparently. [53:46] >> That's right. [53:48] So, I mean, we we used to scan in PHP. [53:52] We kind of migrated to a hybrid approach [53:55] and then this year we went full in. We [53:58] did a major sprint to get these all [54:00] converted over to what we call [54:01] JavaScript rules. And what we mean by [54:04] that is these are this is uh scanning [54:07] code and logic that can be run on the [54:10] actual rendered page. So we can pull up [54:14] a page, we can insert our scanner into [54:16] it, we can scan the page and get uh [54:19] vastly more accurate results than we [54:22] ever could with just straight up PHP [54:24] parsing. [54:26] And uh [54:27] >> yeah, well the the perfect example [54:28] probably is the the color contrast. [54:31] >> Yeah, [54:32] >> is the the first one that was [54:33] transitioned because there's you have to [54:37] read all of the JavaScript, all of the [54:39] CSS, and all of the HTML to try and [54:42] determine what color an object might be [54:45] inside the DOM. And that might actually [54:47] be influenced by external JavaScript [54:49] that runs that you'll never really be [54:51] able to know in a PHP scan. So unless [54:55] you render the page, you won't know the [54:57] actual color and you may also not [55:00] understand what the background color [55:01] would be to do an actual comparison. So [55:04] once you render the page, you know all [55:06] of those things with, you know, a [55:08] guaranteed [55:10] like for certain that there's no [55:13] question in what color is on top of what [55:16] color if you actually render the page. [55:18] And there's a lot of other rules like [55:20] the underlying text row we briefly [55:23] mentioned earlier on. So there's a bunch [55:25] of different ways you can underline your [55:27] text. You can literally just use text [55:29] decoration, a style row, but you can [55:32] also use um border bottom on a row and [55:37] we cannot detect that in PHP with static [55:40] analysis. We cannot determine what a [55:41] thing looks like. However, with [55:43] JavaScript, we can see that and it is [55:45] literally the difference between making [55:48] an educated guess and actually being [55:50] able to see what the thing is going to [55:51] look like to a user in the browser. [55:56] >> There's a huge difference between static [55:59] scan and a live page scan. The the [56:02] downside of the live page scan is that [56:04] it takes up more resources and it's a [56:06] bit slower because of the nature of how [56:09] you have to render the page, but it is [56:12] millions of times more accurate. [56:14] >> Yeah. And you need to you need to leave [56:16] the page open and let it run because we [56:19] need to use your browser to determine [56:21] these things. Whereas when we were doing [56:24] uh the PHP the static analysis we didn't [56:27] need that um u because we actually were [56:30] not rendering the page and and so it [56:33] does require a little bit more resources [56:37] and a little bit more complexity to do [56:40] what it does. But this is actually the [56:44] the def you know what makes [56:46] accessibility checker different than [56:48] almost any other scanner. And um and [56:52] this is what actually brings like [56:54] enterprise SAS [56:56] accessibility scanning that cost a [56:58] fortune. This is what actually we're [57:01] doing to take that and bottle it into a [57:04] WordPress plugin and bring it to [57:07] uh the vast a vast majority of users [57:09] that don't have the resources or don't [57:12] want to pay for those super expensive [57:15] accessibility enterprise accessibility [57:17] tools. Well, a lot of those super [57:18] expensive tools are just running X core [57:21] right out of the box. They're not doing [57:23] any customization or any tweaking. And [57:26] you know, I was quite surprised that [57:28] with our bucket of, you know, however [57:31] many rules we have, we only actually [57:33] take directly verbatim from Xcore, a [57:37] handful, maybe five or six of those [57:39] rules. And the rest of these custom [57:41] rules are extensions of Xcore rules or [57:44] some of them are very WordPress specific [57:47] rules. [57:48] >> So we're not just going to give you [57:50] generic answers the way some of these [57:52] like online scan tools are going to [57:55] >> going to manage. We're literally going [57:56] to [57:58] interpret the results of the scan and [58:00] provide only the valuable items as as [58:04] far as we deem. You know, we might [58:07] not have be pulling out all of the [58:09] valuable items as of yet from Xcore, but [58:12] over time we will be adding more of more [58:14] rules, more custom rules, and more [58:17] things that can be scanned against those [58:19] rules. [58:21] >> Yeah. Because we're not we're not just [58:22] looking to build like a, you know, a [58:24] base level compliance [58:27] uh scanner. We're actually looking to [58:29] build a [58:31] a fullfeatured auditing tool to help you [58:34] audit a website. And we expose we expose [58:38] what we call warnings, which are [58:40] actually things that we're prompting you [58:41] as an auditor or just a web developer or [58:45] uh or a website creator, a content [58:47] creator. We're actually prompting you to [58:49] say, "Hey, we can't programmatically [58:52] tell you with with certainty that this [58:54] is an issue, but we think it is and we [58:58] want you to look at it." So, we're doing [59:00] a lot to help come alongside you and and [59:03] to assist in that audit of these [59:05] websites to make them as accessible as [59:07] possible. So along with that conversion [59:10] William um we we we found the need to [59:15] really make sure that our if we're [59:17] writing and extending so much of axe [59:19] core we need to ensure that what we're [59:22] doing is right and that we don't have [59:24] any regressions when we change other [59:26] rules. [59:27] >> Yes. So before I say how we did this let [59:30] me tell you how we used to do this. We [59:32] had the WordPress website. It had the [59:35] bunch of content on that website. And we [59:37] would update the plug-in on that [59:38] website. We would visit the pl the [59:40] website, scan the page, and we would see [59:43] what it finds, what it doesn't, and we [59:44] had lists of things that we expect [59:46] should pass and things that shouldn't. [59:48] And that was all live content on a live [59:50] website that we had access to. And that [59:53] was how we previously were testing this. [59:56] Um, now we have almost every single row [59:59] or every role that we transitioned in [60:01] the most recent batch. I think it's [60:03] probably 90 95% of all the rules that we [60:06] run in our scanner now have fully [60:08] automated JS tests. And this was an [60:11] excellent use of AI we discovered [60:13] because we had the content for most of [60:16] these roles elsewhere. And we were able [60:18] to tell the AI here's the content we [60:20] have generate these tests that automate [60:24] verification that these things pass or [60:26] these things fail. And every time we [60:29] make a change to a rule, these tests get [60:31] run and it tells us whether we have [60:32] broken a rule or improved the rule. And [60:35] if someone comes to us with an issue [60:37] that these rules do not detect, we just [60:39] add it to these unit tests and we can [60:43] change our role or change our tests till [60:46] we get it to pass or fail. And not like [60:50] like we legitimately want to fix exactly [60:52] what's reported. So we take the markup [60:54] snippet directly from these problematic [60:56] websites and verify them against our [60:59] actual row. And the way Jest works is it [61:01] literally spins up and tests against [61:03] this exact markup. So we have a pretty [61:07] high degree of certainty that if we fix [61:09] it in our tests is fixed on someone's [61:11] website. [61:13] >> Yeah. And this is you know this is a [61:15] living and growing test suite like [61:18] William said and we're continually [61:20] adding to it and we don't remove these. [61:22] It just builds up. I mean, we've got [61:23] thousands of code snippets that get [61:25] tested when these rules run. And we can [61:29] even we can even do like um uh we even [61:32] do like testdriven development uh in in [61:35] respects to that where if say Amber says [61:38] we should do this rule, right? We should [61:41] do this check. We should check for this [61:43] certain thing and this is what I think [61:45] uh would be a failure or this is what I [61:47] think would be a pass. we can actually [61:49] take those [61:51] put them into the the test first before [61:54] we even write the the check or the the [61:56] rule and um we can actually take that [62:00] and then use AI to prompt it to say hey [62:02] can you try to make a rule and a and a [62:04] check to to go along with this. So it's [62:07] kind of [62:08] >> it's sometimes hit and miss. I actually [62:10] do think the AI works better the other [62:12] direction where we write some of the [62:14] code. We start off with basic unit tests [62:16] and then we ask it to look at the code [62:19] we've written and extend the unit test [62:21] to make sure that things we change don't [62:23] break something or you know to highlight [62:26] things. The the AI has actually been [62:28] surprisingly good at identifying gaps [62:31] >> in the tests that we have. So we might [62:33] have a series of 10 tests and we can [62:36] prompt the AI and the AI might come back [62:38] and say here's 15 edge cases that you [62:40] didn't consider. [62:41] >> Yeah. And then we just instantly put [62:43] them in and we run the tests and sure [62:45] enough some of them might pass, some of [62:47] them might fail. Some of them might be [62:49] incorrect and we need to continue [62:52] tweaking the rule to make sure that the [62:54] answers we get in the end from the tests [62:56] are exactly what we expect. [62:59] >> Yeah. And as far as regressions like we [63:02] have some rules that actually will share [63:05] like uh helper a helper uh code across [63:09] multiple rules and if you modify that or [63:12] you modify a certain rule you can [63:13] actually you have a lot of uh checks and [63:16] balances there to ensure there's no [63:18] regression that [63:18] >> like for example if we modify how we [63:20] handle area hidden [63:22] >> in terms of visible content if we modify [63:25] the helper that we use for that that [63:27] could break a whole bunch of things [63:29] because that is actually a base [63:30] requirement for a lot of [63:33] screen reader backed rules. If if it's [63:35] already hidden, the screen reader won't [63:37] ever see it. And that might be a [63:38] problem. We might actually want to flag [63:40] that it's hidden and tell you you need [63:41] to unhide this. Or if it is hidden and [63:44] it's problematic content, maybe we don't [63:46] need to tell you that that's an issue [63:48] because the screen reader can't see it. [63:51] So, it is important that that works. [63:53] >> Yeah. [63:54] >> We need to make sure that that our [63:56] helper does not get broken. Yep. [64:00] So, I mean that's a rundown on what we [64:03] are doing on our end to ensure accuracy [64:06] to make sure that your your issues are [64:08] actual issues, not false positives and [64:10] that we are continuing to build build a [64:13] huge library of tests to ensure that [64:15] with every update that uh that all of [64:19] our rules continue to work and that we [64:21] don't create any downstream problems. [64:24] So, we are running short of time. I [64:26] think it's time for another lightning [64:27] round to finish up. [64:29] >> Well, you you go lightning around and [64:31] I'll maybe enable I'll turn Netflix back [64:34] on. [64:36] >> Yeah. So, we did some dashboard tools in [64:38] the plugin. We integrated accessibility [64:40] checker into the site health. We're all [64:42] adding some more information in into [64:44] there to not only help you see that [64:48] there. So now in the site health it'll [64:50] actually flag if you have u [64:53] accessibility issues on your website. Um [64:56] and u it flags you know the different [64:59] warnings that come with the site health. [65:01] Um so we're trying to expose [65:03] accessibility checker there. When you [65:04] run site health you can see if there's [65:06] accessibility issues that need to be [65:08] addressed on your website. We added an [65:11] admin toolbar with quick links. Now, [65:13] this is the most easy easy thing, but [65:16] it's one of William and and my favorite [65:20] things is is now having just a toolbar [65:22] with links in it that we can quickly [65:24] jump to our settings page, [65:26] >> go straight to the settings page, no [65:28] longer having to double click [65:30] >> or the fixes page specifically. [65:31] >> Yeah, the fixes page. So, we're just [65:33] trying to make things uh more more [65:35] accessible and uh easier to navigate to. [65:40] So, we have some add-ons. We did some [65:42] work on add-ons as well this year. We [65:44] have our export add-on. Our export [65:47] add-on now includes a wikag levels and [65:50] the severity level in the export. We are [65:54] actually looking at adding some more [65:56] features to the export to be able to [65:58] export uh issues at the post level. Um [66:03] that is an upcoming feature that we're [66:06] looking at uh for the ex exporter [66:09] plugin. And then in our audit history [66:12] plugin, uh, we added a filter to [66:15] customize which user capabilities are [66:17] allowed to view the audit history page. [66:20] So, yep. And this one also came from a [66:23] customer request. So, you know, any [66:26] anyone who has any issues or any [66:29] desirable features they have, send them [66:31] our way because we almost always try to [66:33] implement the things that you request [66:35] because [66:37] we can only come up with so many great [66:38] ideas on our own. [66:40] >> Yeah. [66:40] >> You always come up with some more. [66:43] >> Yeah. So, [66:45] so those are some of the top things and [66:47] like I said, a whole litany of bugs that [66:49] have been squashed throughout the years, [66:51] but we do not have time to go through [66:53] each one of those, but just uh these are [66:55] all the things that we're doing to [66:56] improve the accessibility checker to [66:58] make it easier for you to use and to [67:00] make it more accurate and and to help [67:03] you make your website as accessible as [67:06] possible. So, [67:08] what are we doing next? It's [67:12] >> well next it's Christmas time [67:14] >> so we're we're taking a break [67:16] >> but then yes [67:17] >> but then after the break we are doing [67:20] email reports [67:21] >> right [67:22] >> and not just email reports these reports [67:25] will also provide access to some new [67:28] information that you have to jump [67:30] through some loops to find such as [67:33] identifying the top five pages on your [67:36] your website with issues. So yeah, these [67:39] reports will be available to [67:42] everyone I want to say, not just page [67:45] users. [67:47] >> So yeah, more to come on that. [67:50] >> Yeah. So this is actually a feature [67:52] that's in the works right now. Um it's [67:54] it's not even part of the 2026 roadmap, [67:58] but it's a part of this year's roadmap. [67:59] But as you said, the year is winding [68:01] down and uh equalized digital. We like [68:04] to uh treat ourselves and our team to a [68:07] nice week off at the end of the year [68:09] just as a little thank you for all the [68:11] hard work and to have [68:13] >> forcing me to spend time with my family. [68:15] >> Forcing you to spend time with your your [68:17] family and um [68:21] uh so yeah. So, basically what it is, [68:23] it's going to be the the free plugin. [68:25] You're going to be able to connect it [68:27] with your my dot uh equalize, we call it [68:30] my dot. So, it's your dashboard on [68:32] my.equalized.com. [68:35] Um, you will be able to connect your [68:37] free plugin with the dashboard. If you [68:40] don't have an account, if you got the [68:41] plugin from WordPress.org, you can [68:43] create an account on uh my.equalized.com [68:48] and make that connection. And once [68:50] that's connected, we will get your uh [68:53] your summary report at certain intervals [68:57] and we will send you emails about the [69:00] accessibility uh status of your website. [69:03] A little report on and like William [69:05] said, some new features in that report [69:07] that aren't currently in the plug-in [69:09] where we're identifying the top pages [69:11] that need to be addressed. Uh so that [69:13] you can get that right into your inbox. [69:16] You can see what pages have problems, [69:17] what you know and you can action on [69:19] those right away. And there is uh a lot [69:23] that goes along with that as well. We we [69:26] have thoughts and ideas and these are [69:28] just ideas about um you know we can [69:31] expose that that those reports inside of [69:34] your my.ealizeddigital.com [69:34] vehicledigital.com dashboard and we can [69:38] start to do some a little more [69:40] historical we can expand the the audit [69:43] history plugin that we have we can start [69:46] doing that at at an even bigger level [69:49] and uh exposing some of that [69:51] >> I also want to mention that you know [69:54] audit history is currently only [69:55] available on higher tier licenses and [69:58] with the addition of the email reports [70:00] that is actually going to introduce at [70:02] least a currently versus fast access to [70:07] history of issues for free users as [70:10] well. So this is not just a [70:12] >> all the fanciness is not going to be [70:14] only for paid users. Free users will [70:16] absolutely get a lot of benefit from [70:19] this feature being available as well. [70:21] >> Right. Yep. And what it also does is it [70:24] allows you to collect uh the the [70:27] accessibility status of multiple [70:30] websites into one dashboard on [70:33] y.ealized.com [70:36] >> potentially just one email as well [70:38] monthly. [70:39] >> Yep. So a lot in the works there. We at [70:44] in December uh equalized digital goes [70:46] into kind of planning mode a little bit [70:48] and uh we start to plan out what we're [70:50] going to work on for the next year and [70:53] we are currently in the throws of that [70:55] this week and uh we're doing a lot to [70:58] plan new features for the next year and [71:02] uh I'm super excited to share what those [71:04] are with you all uh late in future live [71:07] streams um once we all get uh a unified [71:11] decision on what those are and uh we [71:14] start [71:14] >> I'll let slip of one that maybe might [71:16] not make the road map but I'm absolutely [71:18] going to do here which is some more [71:20] advanced rules. [71:22] >> You might want to look at whether your [71:24] tabs are correct as opposed to just do [71:27] tabs exist on the page or they [71:29] >> they're correctly [71:31] >> component level accessibility [71:35] >> might be a set of rules in the future or [71:37] there might be some other experimental [71:40] rules. Well, we don't want to give these [71:42] ideas all away. Our competitors are [71:43] watching. [71:46] They're gonna maybe they're going to [71:47] steal all of our ideas. No, no, it's [71:49] it's fine. But no, um, we're always [71:52] thinking about these things. Like [71:53] William said, component level scanning. [71:55] We can identify a component. Why don't [71:57] we just scan the whole component to make [71:58] sure it's complaining? Tabs are hard. [72:01] They're hard to make accessible. So why [72:03] don't [72:03] >> hard to make accessible from a [72:04] development standpoint, but actually [72:06] quite easy to recognize when they're [72:08] wrong from a programmatic standpoint. So [72:12] >> yeah, [72:12] >> let's do that. [72:14] >> Cool. [72:15] Well, do you have any uh closing [72:17] thoughts for 2025, William? [72:20] >> It's been a busy year. Done a lot more [72:23] than we had time to go through here. um [72:26] made a lot of development improvements [72:28] in the plug-in consistently which you [72:30] know is reaping the benefits of how [72:32] quick we can get these features out now [72:34] and you know hopefully next year is a [72:36] year full of features now that we've [72:38] done a lot of that cleanup. [72:40] >> Yeah. Yeah. So my kind of 2025 recap is [72:45] that yes, busy is is is a word I would [72:49] cap the year off with a whirlwind year [72:52] of busyiness and uh but you know that [72:56] just shows what Equalized Digital is [72:57] doing to to and what we're putting into [73:00] this product to make it useful for the [73:02] you for our users and and our commitment [73:05] to pushing accessibility forward uh from [73:08] you know from a technical perspective of [73:11] identifying and fixing issues and and [73:14] continuing on with that and and what [73:16] other areas can we help in this audit [73:19] and reme remediation of accessibility. [73:22] And I just want to end by saying, you [73:25] know, any listeners or or customers of [73:27] or users of accessibility checker, thank [73:29] you. Thank you for trying out the [73:31] plugin. If you haven't used it, please [73:34] grab it. It's free. It's extremely [73:36] fullfeatured free plugin. None of our [73:39] rules are gated behind a payw wall. All [73:42] of our rules, [73:42] >> you get all of the scan capability for [73:44] every post, the same as everyone else. [73:48] >> Um, so I just want to say thank you uh [73:51] anybody that's tried out the plugin and [73:53] all the people that we interact with uh [73:56] uh feel free to reach out to us. We're [73:57] all happy to give advice. We're happy to [74:00] look into bugs. And uh just uh want to [74:03] wish everybody a a happy new year and uh [74:07] we look forward to getting back to it [74:09] next year. [74:10] >> I think we will see you on [74:13] is it the 7th of January? [74:15] >> Yeah. [74:18] >> Um the 8th maybe the week after we're [74:21] back. [74:22] >> Yep. Next live stream will be probably [74:24] around the first week of the year. So [74:26] look for us then. Thanks for joining us [74:28] and