Stability, Ordering, and Issue Clarity - CourtneyR.dev's 2nd Brain

Stability, Ordering, and Issue Clarity ![rw-book-cover](https://img.youtube.com/vi/2hwdgKtM6C0/maxresdefault.jpg) 🔗 **Source:** [Stability, Ordering, and Issue Clarity](https://www.youtube.com/watch?v=2hwdgKtM6C0) > [!note]+ Document Notes > tags: [wordpress, accessibility, automated-testing, web-development, plugin-development] > author: Equalize Digital > source: YouTube > reference: https://www.youtube.com/watch?v=2hwdgKtM6C0 > date created: 2025-01-26 20:45 > > # 🏷️ Title: Stability, Ordering, and Issue Clarity - Accessibility Checker Plugin Updates >  ## 🧰 Action Inbox - [H1] Update accessibility scanning workflow to leverage unique selector-based identification — reduces false positives #wordpress #accessibility - [H2] Test new DOM ordering functionality on sites with multiple identical issues — improves remediation workflow #automated-testing - [H3] Review fasttrack improvements for better issue prioritization — maximizes accessibility improvement efficiency #web-development ## 🧭 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://equalizedigital.com/accessibility-checker/) - [WordPress Block Editor](https://wordpress.org/support/article/wordpress-editor/) ## 📝 Summary - Equalize Digital released significant updates to their Accessibility Checker WordPress plugin (free v1.37.0, pro v1.2.0) - Core improvement: switched from HTML markup-based to CSS selector-based unique issue identification - Why it matters: eliminates false grouping of identical issues, improves accuracy and user experience - Key stakeholders: WordPress developers, accessibility professionals, site maintainers - Risks: requires database updates, potential edge cases in selector generation - Bottom line: more accurate accessibility scanning with better performance and user workflow ## 📖 Main Content The Accessibility Checker plugin historically identified unique issues based on HTML markup fragments. This approach created problems when multiple identical elements (like empty paragraph tags) existed on the same page - the system would only flag the first occurrence and group subsequent instances as duplicates. The new selector-based approach uses CSS selectors with nth-child values to uniquely identify each issue instance. For example, empty paragraph tags are now identified as "p:nth-child(5)", "p:nth-child(6)", etc., rather than just "". Technical improvements include: - **Performance gains**: Selector-based queries are approximately 15x faster than markup-based searches - **DOM ordering**: Issues now display in top-to-bottom page order rather than database storage order - **Enhanced highlighting**: Front-end issue highlighting uses native JavaScript querySelector for accuracy - **Fallback system**: Three-tier system tries selector, then ancestor, then legacy markup for maximum reliability The plugin also refined style management for the "disable styles" feature, addressing complex cascading stylesheet scenarios common in page builders and custom implementations. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/2hwdgKtM6C0?t=0) — [H1] Live stream introduction and plugin overview - Key idea: Second live stream of 2026 covering Accessibility Checker updates - Evidence: "Free plugin release is version 1.37.0 and the pro release version is 1.2.0" #### ⏱️ [03:45](https://youtu.be/2hwdgKtM6C0?t=225) — [H2] Core problem: Issue identity challenges - Key idea: Historical grouping of identical markup caused accuracy problems - Evidence: "If you had two identical issues on the same page, the accessibility checker would think they were the same and would only surface it once" #### ⏱️ [05:30](https://youtu.be/2hwdgKtM6C0?t=330) — [H1] Empty paragraph example demonstrates the problem - Key idea: Block editor easily generates multiple empty paragraphs that appear identical - Evidence: "If you had like three empty paragraph tags, the plugin would say 'Hey, you have an empty paragraph tag.' And you would fix it. And then it would say 'Hey, you have an empty paragraph tag'" #### ⏱️ [07:15](https://youtu.be/2hwdgKtM6C0?t=435) — [H1] Database preparation for selector-based system - Key idea: Plugin has been collecting selector data for 8-9 months in preparation - Evidence: "We've quietly been collecting this data in the database... We haven't been collecting it. It's in your database on your website" #### ⏱️ [09:20](https://youtu.be/2hwdgKtM6C0?t=560) — [H2] Database structure demonstration - Key idea: Selectors provide unique identification with nth-child values - Evidence: Database shows "p:nth-child(5)" as unique identifier vs generic "" markup #### ⏱️ [13:45](https://youtu.be/2hwdgKtM6C0?t=825) — [H1] Performance improvements from selector approach - Key idea: Selector queries are significantly faster than markup fragment searches - Evidence: "Searching by this selector is probably 15 times faster than searching by this item" #### ⏱️ [16:30](https://youtu.be/2hwdgKtM6C0?t=990) — [H2] Native JavaScript integration benefits - Key idea: CSS selectors work directly with document.querySelector - Evidence: "This selector right here can be passed into native JavaScript functions... Document.querySelector is the function and this is native JavaScript" #### ⏱️ [19:00](https://youtu.be/2hwdgKtM6C0?t=1140) — [H1] User experience improvements from accurate counting - Key idea: Plugin now counts multiple instances as separate issues for accurate assessment - Evidence: "We're no longer grouping like five empty paragraphs together and counting it as one. We will actually now count that as five individual issues" #### ⏱️ [22:15](https://youtu.be/2hwdgKtM6C0?t=1335) — [H2] DOM ordering enhancement - Key idea: Issues now display in top-to-bottom page order instead of database order - Evidence: "We've decided to order from the top of the DOM down. So your first issue in the DOM will be the first one that's highlighted" #### ⏱️ [25:40](https://youtu.be/2hwdgKtM6C0?t=1540) — [H1] Three-tier fallback system for reliability - Key idea: Layered approach ensures issues are found even if primary method fails - Evidence: "It first tries to use the unique selector... if that fails, then it would go down to the ancestor... in the rare case that both fail, it will go to our legacy code object selector" #### ⏱️ [28:30](https://youtu.be/2hwdgKtM6C0?t=1710) — [H2] Highlighter positioning improvements - Key idea: Fixed bugs in visual positioning when multiple issues exist on same element - Evidence: "William took kind of a fine tooth comb through that positioning and reworked how the targets are positioned" #### ⏱️ [31:20](https://youtu.be/2hwdgKtM6C0?t=1880) — [H1] Disable styles functionality refinements - Key idea: Complex style restoration improved for page builders and inline styles - Evidence: "We're inserting them back to where they belong or where they started... you need to reverse the order so you don't mess up that inheritance" #### ⏱️ [38:45](https://youtu.be/2hwdgKtM6C0?t=2325) — [H2] CPU performance optimization - Key idea: Eliminated unnecessary style repainting when closing highlighter - Evidence: "We noticed that the styles would reload anytime you tried to close the accessibility checker front-end highlighter panel... in most cases it only needs to actually reload those when you have styles disabled" #### ⏱️ [42:10](https://youtu.be/2hwdgKtM6C0?t=2530) — [H1] Fasttrack improvements demonstration - Key idea: Better counting and labeling for multiple instances of same issue type - Evidence: "15 instances of empty paragraph across five pages... this label here used to be pages and now it is affected pages" #### ⏱️ [46:30](https://youtu.be/2hwdgKtM6C0?t=2790) — [H2] Sorting enhancements with visual indicators - Key idea: Improved default sorting by severity and count with better UI indicators - Evidence: "By default sorted by severity and severity is a two-tier sort... now there is good visual indicators" ## 📚 References - [Accessibility Checker Free Plugin](https://wordpress.org/plugins/accessibility-checker/) - [Accessibility Checker Pro Plugin](https://equalizedigital.com/accessibility-checker/) - [CSS Selectors Documentation](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Selectors) - [Document.querySelector Reference](https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector) ## 🗣️ Paraphrase - The plugin switched from identifying issues by HTML markup to using CSS selectors, which provides unique identification for each issue instance and dramatically improves performance - DOM ordering now presents issues from top to bottom of the page rather than in database storage order, creating a more logical workflow for remediation - Style management was refined to handle complex cascading scenarios and eliminate unnecessary CPU-intensive repainting operations when the highlighter panel closes ## 📰 Newsletter **Major Accessibility Checker Plugin Update Improves Issue Detection Accuracy** The latest Accessibility Checker releases (free v1.37.0, pro v1.2.0) deliver significant improvements to how the plugin identifies and manages accessibility issues on WordPress sites. The biggest change addresses a longstanding challenge: when multiple identical elements (like empty paragraph tags) existed on a page, the plugin would only flag the first occurrence. Now, using CSS selector-based identification, each issue gets unique tracking - meaning you'll see accurate counts and can systematically fix all instances. **Key Benefits:** - **15x faster** issue detection using native CSS selectors - Issues display in logical top-to-bottom page order - More accurate accessibility scoring and reporting - Improved front-end highlighting performance **Practical Impact:** If your site had 5 empty paragraph tags, the old system showed "1 issue" that seemed impossible to fix. The new system correctly shows "5 issues" with precise locations, making remediation straightforward and progress trackable. The updates also refined the "disable styles" feature for complex page builder sites and added CPU optimizations that especially benefit mobile users and lower-powered devices. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### WordPress - Core: Evaluate selector-based approaches for core accessibility features - Themes: Test theme compatibility with new accessibility scanner highlighting - Plugins: Review plugin interaction with automated accessibility tools - Documentation: Update accessibility testing guidance to reflect new capabilities - Community: Share accessibility scanning improvements with developer community #### DevRel - Education: Create workshops on automated accessibility testing workflows - Developer experience: Document integration patterns for accessibility plugins - Developer marketing: Highlight accessibility tooling improvements in WordPress ecosystem - Community management: Gather feedback on accessibility plugin user experience #### Community - Maintainers: Evaluate automated accessibility testing in plugin development workflows - Contributors: Share accessibility scanning results and remediation strategies - Sponsors: Support accessibility tooling development through plugin sponsorship ## 🧪 Hypotheses - Selector-based issue identification will reduce false positive groupings by 90%+ compared to markup-based approach - DOM ordering will decrease remediation time by providing logical top-to-bottom workflow - Performance improvements will have greatest impact on mobile devices and lower-powered systems - Accurate issue counting will improve accessibility improvement tracking and goal-setting ### 📊 Methodology - A/B testing between markup-based and selector-based identification accuracy - Performance benchmarking across device types and CPU capabilities - User experience studies measuring remediation workflow efficiency - Database query performance analysis comparing search methods ### ❓ Questions - How will the three-tier fallback system perform in edge cases with complex dynamic content? - What impact will more accurate issue counting have on accessibility compliance reporting? - How can other WordPress accessibility tools adopt similar selector-based approaches? ### 🔮 Future Research - Integration of automated accessibility scanning with WordPress core development workflows - Standardization of accessibility issue identification across WordPress ecosystem tools - Performance optimization techniques for real-time accessibility scanning ### 💡 Implications - Practice: More reliable automated accessibility testing enables better compliance workflows - Policy: Accurate issue tracking supports more meaningful accessibility compliance reporting - Education: Improved tooling reduces barrier to entry for accessibility testing and remediation - Funding: Better automation may shift accessibility budget allocation toward remediation vs. detection ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: Database structure screenshots, UI comparisons, selector examples - Improve: Workflow diagrams showing before/after issue detection processes #### 🔊 Aural learners - Present: Live demonstration with verbal explanation of technical concepts - Improve: Audio-only summary of key improvements and benefits #### 🗣️ Verbal learners - Present: Technical terminology explained with analogies, step-by-step descriptions - Improve: Glossary of CSS selector and accessibility testing terms #### 🧩 Kinesthetic learners - Present: Live database queries, interactive plugin demonstration - Improve: Hands-on tutorial for testing new features, practice exercises #### 🧠 Logical learners - Present: Performance benchmarks, systematic problem-solution explanation - Improve: Decision tree for when to use different identification methods #### 🧑‍🤝‍🧑 Social learners - Present: Live Q&A format, community-focused live stream - Improve: User forum discussion prompts, peer testing groups #### 🧘‍♀️ Solitary learners - Present: Detailed technical documentation, self-paced feature exploration - Improve: Written implementation guides, independent testing checklists #### 🌿 Naturalistic learners - Present: Real-world website examples, ecosystem impact discussion - Improve: Environmental impact of performance improvements, sustainability connections ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear headings, technical concepts explained in context - Improve: More descriptive alt text for database screenshots #### Keyboard navigation - Present: Standard video controls, accessible live stream interface - Improve: Keyboard shortcuts for navigating technical demonstrations #### Contrast and readability - Present: Standard video player with good contrast - Improve: High contrast code examples, larger font sizes for technical content #### Text resizing and reflow - Present: Responsive video player, scalable interface - Improve: Ensure technical diagrams remain readable at 200% zoom #### Media and captions - Present: Video content with live audio narration - Improve: Add captions for technical terminology, provide transcript #### Forms and interactions - Present: Basic video interaction controls - Improve: Accessible comments and feedback forms for live streams ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focus on WordPress global community impact - Improve: Examples from different geographic regions, accessibility law variations #### Inclusive language - Present: Technical language explained clearly, avoiding jargon - Improve: Define all technical terms, provide plain language summaries #### Neurodiversity support - Present: Clear structure with timestamps, logical progression - Improve: Visual breaks between sections, consistent formatting #### Representation - Present: Technical discussion focused on tool improvements - Improve: Diverse use cases, different user perspectives on accessibility needs #### Psychological safety - Present: Supportive tone about accessibility challenges - Improve: Acknowledge accessibility learning curve, provide encouragement ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Technical problem → solution → implementation results follows logically - Inductive strength: Performance testing → generalized improvement claims well-supported --- ## Full Transcript [00:05] All right, [snorts] we're live. [00:09] How's it going? [00:10] >> Yeah, it's going pretty good. No [00:12] complaints. [00:13] >> No complaints. Well, that's good. [00:16] >> I've got lots of complaints, but end up [00:18] in here. [00:21] >> Yeah. So, it looks like uh looks like [00:23] we're going out live just fine. Um, [00:27] we check X and make sure we're doing [00:31] we're going out there. [00:36] Okay. [00:38] Yeah. So, second live stream of 2026. We [00:42] are just plowing through 2026 already. [00:46] >> Only one 12th of the way. [00:48] >> Only 112th. But boy, it went fast, [00:50] didn't it? [00:51] >> Yep, it did for sure. [00:55] It did. So, we have been busy working on [00:58] new features for accessibility checker [01:02] and yep, looks like we're going out live [01:04] on X. So, cool. So, welcome anybody [01:10] joining now or after the fact. Uh we do [01:14] pre we do uh save these recordings for [01:16] later so you can enjoy them in your in [01:18] your own time and in your own leisure. [01:21] Um, [01:22] this is the accessibility craft change [01:25] log liveream [01:27] uh where we go over the latest features [01:29] in the accessibility checker WordPress [01:31] plugin which is an automated [01:33] accessibility [01:34] scanning plugin to help your website [01:36] become and stay accessible. We have a [01:39] full suite of plugins. We have a free [01:41] plugin uh that is fullfeatured for [01:44] scanning uh individual post. We have a [01:46] pro plugin where you can do site level [01:49] scans and get more advanced uh auditing [01:53] and remediation features. And then we [01:55] have a few add-ons that go along with [01:57] our pro plugin. We have an audit history [01:59] to track accessibility issues over time. [02:01] A multi-sight plugin to help uh you uh [02:05] manage your accessibility licenses and [02:09] stats and activations at the network [02:12] site level of a WordPress multicight. [02:15] And we have an export add-on that allows [02:17] you to export your issues to CSV. So you [02:20] can import them into any uh system you [02:23] desire. So today we're talking about [02:27] stability, ordering, and issue clarity. [02:30] So it's not a huge release, but it's an [02:32] important release. So we're continually [02:34] we're always trying to refine things and [02:36] make things better and to be able to [02:40] detect issues with greater accuracy. And [02:43] in this case, being able to surface uh [02:47] identical issues where we have [02:50] historically had uh a little bit of [02:52] trouble surfacing those accurately. [02:56] So the the plug-in updates are in our [02:59] free plugin and our pro plugin. Free uh [03:02] plug-in release is version 1.37.0 [03:07] and the pro release version is 1.2.0. [03:13] All right. So, welcome William. [03:16] >> Hey, [03:17] >> doing good. [03:19] >> Yeah, doing good to there. [03:20] >> All right. So, [03:23] let's dive in and start going through [03:26] these and William will help me describe [03:28] some of the things that we've done and [03:31] uh some of these improvements. So, first [03:32] off, we're going to start with issue [03:34] identity, knowing when two things are [03:37] the same. [03:38] So, historically, like I mentioned, um [03:41] if you had two identical issues on the [03:44] same page, the accessibility checker [03:47] would a lot of times think that they [03:50] were the same and would only surface it [03:52] once. [03:54] And what we've and and this is because [03:56] of the way that AC accessibility checker [03:58] has historically worked and how it [04:02] uniquely or how it was identifying [04:04] issues and basically it was evaluating [04:07] based on the the code object that it [04:11] detected as the issue on the page. And [04:15] do you want to describe why that's [04:17] problematic, William? [04:19] >> Yeah. So if pre previously the entire [04:22] HTML fragment was the unique identifier [04:25] for an individual issue and that you [04:29] know in some instances might be true. [04:32] You might only have one skip link on a [04:33] page. That's fine. You might only have [04:35] one homepage logo on a page. That's also [04:38] fine. But what you're likely to also [04:40] have is a lot of paragraphs. And say for [04:43] example there's two empty paragraph [04:45] tags. they will look exactly the same as [04:47] far as our system processing [04:50] previously would work. So only the first [04:52] discovered item would be flaggable. The [04:55] subsequent items would be considered as [04:58] the same. The the system wouldn't know [05:00] that it was a second item. And in most [05:02] cases that's fine. In some cases it's [05:06] not. As I said in in the case of empty [05:08] paragraphs, but what if you also had the [05:10] same broken link on a page? it would [05:14] only be flagged once and that has some [05:17] cascading issues. So, if you fix the [05:20] link, the issue wouldn't go away. You [05:22] would think you fixed it because you [05:24] would see the first instance of that [05:26] issue. You would be able to click the [05:28] the view on page button. It would take [05:30] you to it. You would fix it. The issue [05:32] wouldn't go away. It would actually just [05:34] highlight another issue on subsequent [05:37] scans. So, it would look like you're it [05:39] would effectively look like you're not [05:41] doing anything and hence the the [05:43] problem. it wasn't an issue for a long [05:45] time or wasn't realized to be an issue [05:48] for a long time, but it it turns out [05:50] there are some some pretty nasty edge [05:53] cases that [05:55] >> make things maybe not necessarily [05:58] true. [05:59] >> Yeah. Yeah. And I think where it pops up [06:00] a lot of times is like in the WordPress [06:03] block editor, like it's very easy to [06:06] generate empty paragraph tags just by, [06:09] you know, hitting a return in the wrong [06:11] place and not putting any any uh, you [06:14] know, text. And so like you can end up [06:17] with empty paragraph tags. And like [06:18] William said, if you had like three [06:20] empty paragraph tags, the plugin would [06:23] say, "Hey, you have an empty paragraph [06:24] tag." And you would fix it. And then it [06:25] would say, "Hey, you have an empty [06:26] paragraph tag." then you would fix the [06:28] next one until they were losing. [06:30] >> So because that issue was so prevalent, [06:32] there was some affordances added that [06:34] made padigraphs technically unique. So [06:37] there would be if you had three empty [06:39] paragraphs, it would be stored as three [06:40] unique games. However, then they [06:42] wouldn't properly be grouped in the pro [06:44] plugins open initials tab, the fasttrack [06:46] tab because they weren't the same markup [06:50] object because we treated the markup [06:52] object as the only unique aspect when [06:55] that just ended up just not being true. [06:59] >> Yeah. So to that um this has been quite [07:03] some time in the making and uh we we [07:07] started storing additional uh selector [07:11] information in the database. I I want to [07:14] say like eight or nine months ago. [07:16] >> It's been quite a while. I think most [07:19] people will already have selector data [07:21] stored. [07:23] >> Yeah. So we've quietly been collecting [07:25] this data in in the database in in your [07:28] database. We haven't been collecting it. [07:30] It's in your database on your website [07:32] and [07:32] >> your website, your data, your markup. [07:35] >> Yeah. So when we scan a rule, we get uh [07:40] uh certain artifacts that come from that [07:42] scan and of course the code object is [07:44] one and we have historically been using [07:47] that as the source of truth for what's [07:49] unique. And you have a selector, you [07:52] have an ancestor, and you have an [07:55] expath. And so those three uh metrics [08:00] have been or those three artifacts of [08:02] the scan have have been added in several [08:06] releases ago so that when we did switch [08:08] to this we didn't we didn't have to uh [08:12] you know run an update process or um but [08:16] that being said if for some reason [08:19] somebody hasn't scanned in like nine [08:20] months we do have an update process in [08:24] in that case to actually put in a unique [08:26] identifier into that selector field so [08:29] that the functionality we've added will [08:31] work even if you haven't rescanned in 9 [08:35] months. [08:37] So in making the making every like empty [08:42] paragraph unique. So now we've switched [08:44] to the selector as the unique identifier [08:48] and and how does that make it unique [08:50] William? Why is that any different than [08:53] the code object? Yeah. So, if you want [08:55] to pull up my screen, I actually have an [08:58] actual database from one of my test sets [09:00] up that shows how this is unique. So, [09:03] right here we have previously how we [09:05] would store paragraph tags and this [09:08] markup fragment here signifies a less [09:11] than tag [09:13] and some of these require signify [09:15] greater than tags. But this is an empty [09:17] P tag and if you see this inside the [09:19] curly brackets there is a p child five. [09:24] So this is the fifth P tag on [09:28] post ID [09:30] 2616. [09:32] [snorts] [09:33] So this is a unique selector. However, [09:35] this was not how we originally were [09:38] storing the selectors. If I scroll up to [09:40] the the top of this, you can see here [09:43] this does not contain the nth child [09:45] value in the object. However, we have a [09:48] selector over on this side. And if we [09:52] see here sixth, seventh, eighth child, [09:54] ninth, 10th child. So these all appear [09:56] on the same page and these are the [09:58] unique selectors for this object. This [10:01] is quite a simple selector, the sixth [10:03] paragraph tag on the page. And we are [10:06] fairly certain that this is a unique [10:08] selector. However, sometimes the [10:10] selector isn't as simple as this one. [10:12] For example, [10:14] this item here, which is a YouTube [10:17] embedded frame. So this selector is much [10:20] [clears throat] longer. It has [snorts] [10:24] four different levels of of selector [10:28] only the iframe is the same that we are [10:30] targeting but it's inside an embed [10:33] wrapper from core which has an [10:36] identifier of an embedded YouTube block [10:40] and it's inside from a plug-in from [10:42] called newsletter glue. So all of these [10:45] combined together to make this unique [10:48] and the reason that the selector is so [10:50] long is because there probably is other [10:52] iframes on this page. That means the I [10:56] frame on its own is not sufficient. Um [10:59] if we look at the item above this, this [11:01] is wp- image-570. [11:05] This is unique on the page. This is a [11:07] unique selector and as such can be short [11:10] and with these selectors it is far [11:12] easier to identify the actual item on [11:16] the page. So if we look at this which is [11:19] row 21 in the database this image scroll [11:22] back to what the object looks like it it [11:26] is significantly larger. [11:28] >> Mhm. [11:29] >> Some most of the markup fragments will [11:31] be much larger than the the selectors [11:34] now. So we will be more effective in [11:36] what we have to deliver to the page to [11:38] find games aims [11:40] >> and and more efficient to some degree in [11:43] some of our queries as well. [11:45] >> Correct. I think I've done some initial [11:47] measurements, nothing entirely [11:49] scientific, but searching by [11:53] this selector is probably 15 times [11:56] faster than searching by this item. Um, [12:00] it is roughly the same when you're [12:01] searching for a paragraph because it's a [12:03] small markup fragment, but the larger [12:06] the markup fragment is, the more time [12:09] we're going to save on our queries. So, [12:12] yeah, ultimately we're going to save [12:13] several seconds every time we done run a [12:15] scan. [12:16] >> Mhm. [12:16] >> Most likely. [12:19] >> Yeah. So, switch switching to using this [12:21] selector uh is is a better long-term uh [12:26] solution for the plugin. And uh it you [12:29] know it brings a certain level of [12:31] stability and consistency in issue [12:34] tracking whereas the selector is kind of [12:37] it's a kind of a known pattern on how [12:39] that's generated. Whereas a piece of [12:42] relying on markup alone can can is can [12:45] can really it could be anything and [12:47] we're not in complete control of the [12:50] markup that's detected. Well, but if we [12:53] were searching by this markup, um, we we [12:56] previously did write the code that would [12:58] find this markup on the page and handle [13:00] the highlighting. And it was a a rather [13:03] complicated solution to to find this and [13:05] also not very performant on the front [13:07] end, whereas this selector right here [13:10] can be passed into native JavaScript [13:12] functions. [13:14] >> Yep. [13:16] Yep. Without any fancy parsing. Yep. [13:20] >> Document.wi query selector is the the [13:22] function and this is native JavaScript. [13:25] Almost everyone will have probably used [13:28] this if they have ever written [13:29] JavaScript before and you can find this [13:31] exact element with this one line. [13:34] Nothing else required and we because we [13:37] have made sure that this is stored as a [13:39] unique selector. We know this is only [13:41] going to return one object. It's never [13:43] going to return more than one. [13:50] >> Yeah. So I mean the reason why this [13:51] matters for accessibility is is that we [13:54] can surface and report on the overall [13:58] state of the accessibility more [14:00] accurately. So we're not we're no longer [14:02] grouping like say five empty paragraphs [14:06] together and counting it as one. we will [14:09] actually now count that as five [14:11] individual issues giving you more more [14:14] of an accurate uh assessment and [14:16] accurate stats on where the [14:18] accessibility of your page sits. [14:22] >> And not to call it something that was [14:24] negative about the way we were doing it [14:25] previously. However, we have had at [14:27] least one customer support query come in [14:29] where someone was fixing an issue and [14:32] getting slightly frustrated that the [14:34] issue was never going away. And the [14:36] reason why is because there was several [14:37] of this the same markup on the page and [14:40] they were fixing one and the next one [14:42] was the one identified and it it was [14:45] frustrating for them. So now we're [14:46] removing that as a potential issue that [14:49] someone might run into. [14:51] >> Right. Right. So reducing noise and [14:53] >> correct. [14:54] So, it's repeated noise to and it's [14:58] putting a lot on the remediator's hands [15:00] to to say they're they identify an [15:04] issue, they fix it, and then then it's [15:05] they're presenting with the exact issue. [15:07] It's not the exact issue, but it'll [15:09] actually [15:10] >> and then it looks like the same issue in [15:11] the back end, unless they're using the [15:13] front end highly, they might not know [15:15] that it's a different instance. [15:17] >> Yep. Cool. So, [15:19] >> no longer an issue. [15:20] >> No longer an issue. So all of your [15:22] duplicate uh uh identical markup will [15:27] now be uniquely identified by [15:29] accessibility checker. So that was kind [15:31] of the first step in improving that. And [15:34] then we've taken that and we've done the [15:37] second step which is improving the [15:39] front-end highlighter [15:41] uh in regards to uh you know uh [15:45] surfacing unique issues and the [15:48] stability around having these selectors [15:51] and the ancestor and and XPath and [15:55] improving how um issues are identified [15:59] and highlighted on the uh front-end [16:01] highlighter. [16:03] So, I'll pull us back up, William. Um, [16:08] so we added stability selectors and DOM [16:11] ordering. So, before in the front-end [16:14] highlighter, you would when you would [16:17] pull up an issue and we have a next and [16:19] a previous button. So, you can just, you [16:21] know, quickly toggle through the issues [16:23] on the page, [snorts] it would actually [16:25] go in the order in which those issues [16:28] were identified and stored in the [16:30] database. [16:32] And um we wanted to give a more uh [16:37] seamless and fluid experience to going [16:41] through the the front end of your [16:43] website and and fixing accessibility [16:46] issues. So we've decided to order from [16:49] the top of the DOM down. So your first [16:53] issue in the DOM will be the first one [16:55] that's highlighted and then so on down [16:58] the page. [17:00] And this helps just bring bring a a less [17:06] jumpy experience to tabbing through [17:09] those because if issues were identified [17:10] in the top of the page and then the [17:12] bottom of the page, it would lit [17:13] literally jump down to the bottom of the [17:15] page and then jump back to the top of [17:17] the page. So it's it's just a way of [17:20] making it more of a seamless experience. [17:24] And um [17:26] in do in doing that we switched it to [17:30] using the selector to identify these [17:33] these issues and so the targets actually [17:37] end up more accurately in the right [17:39] place. [17:41] Um, [17:42] >> and like I said earlier on, it is at [17:44] least 15 times faster at discovering [17:47] these issues on the front end, which [17:50] might not matter so much for someone who [17:51] has a fairly high-end PC, but for [17:54] someone that might have a PC that is [17:56] running background tasks or doing other [17:59] things, it is actually noticeable. I [18:02] didn't realize how noticeable it was [18:03] until we ran the the CPU throttle [18:06] simulation yesterday [18:08] >> and it it is quite a lot faster to find [18:11] by selector. Yeah, because I mean a a a [18:15] code object [18:17] like William said could be I mean it [18:19] could be a thousand characters like I [18:22] mean we've done a really good job of of [18:24] reducing that down to the to the [18:26] smallest uh HTML character we can to [18:30] identify the issue but it could be a [18:32] pretty big piece of code and when you [18:35] take that and then you try to parse it [18:37] and generate a selector from it uh there [18:40] can be some inconsistencies and We [18:42] actually did work on so the the [18:45] front-end highlighter that we would [18:47] actually take that code object and we we [18:49] would pull out and generate a JavaScript [18:51] selector from it. And what what we've [18:54] done is we've taken and that had been [18:56] refined over over several years and it [18:59] was very accurate but this is actually [19:02] more accurate than that. And not only [19:05] that, using the selector is it more [19:07] accurate, it's it's like William said, [19:09] it's way more performant to only pull [19:11] like in some of those cases it's five [19:13] characters and you have a unique [19:15] identifier whereas you know the code [19:18] object could be quite a few you know [19:20] like it could be a 100 characters easily [19:22] >> and um and and so the so we had that we [19:28] would build a selector before and what [19:30] we've done is we still have that [19:32] functionality And from a programmatic [19:35] standpoint, what we've done is we've [19:36] built a layered uh kind of try and uh [19:41] switch case kind of like u it first [19:45] tries to use the unique selector to find [19:47] the issue on the page and if it actually [19:50] fails to do that which in most cases I [19:53] don't think it will. [19:53] >> I have not found a fail case in the last [19:56] like two weeks. [19:57] >> It always finds the selector. [20:00] If if that fails, then it it would it'll [20:03] go down to the ancestor and it'll try to [20:06] find it with the unique ancestor. And in [20:10] the rare case that both of those [20:11] actually fail to identify the issue, it [20:14] will go to our our legacy code object [20:18] selector to try to find it. So, we're [20:21] doing everything we can to make the the [20:23] selection of these issues on the front [20:25] end of your page as accurate as [20:27] possible. And we can't promise 100% [20:30] accuracy, but I would say that it is [20:32] very close to that now at finding issues [20:35] on the page. [20:36] >> Yeah. Well, one of the the benefits of [20:38] the selectorbacked [20:40] discovery is an issue I've previously [20:42] run into is code on the front end of a [20:45] website changing what the HTML looks [20:48] like. Sometimes it injects data [20:49] attributes for [20:52] image lazy loading or you know pre [20:56] prefetch like a lot of things are added [20:59] sometimes on the page after it renders [21:02] and if you're searching for a specific [21:04] issue and the markup has changed then [21:07] sometimes you are not going to be able [21:09] to find that item. [21:11] >> Y sorry William looks like I dropped [21:14] off. Um [clears throat] [21:15] >> that's fine. I was yammering away. [21:18] [laughter] [21:19] >> There we go. And it's We're back. And [21:25] cool. Looks like we switched positions, [21:27] but I like you on the left. It's better. [21:28] It's good. [21:30] >> I think I can move it, but I'm afraid [21:32] to. Yeah. So, we we must have a we must [21:35] had an internet uh problem there. But, [21:37] uh [21:39] >> Cool. [21:40] >> I think we're moving on to the what the [21:42] changes to the highlighter position. [21:44] Yeah, [21:45] >> which also be got more significantly [21:48] more accurate [21:50] um in terms of visually where it gets [21:52] placed and also the order in which the [21:56] AMS are presented. [22:00] >> Yeah. So in a previous release, William, [22:02] you had worked on a feature to try to [22:04] spread out [22:06] uh uh targets like it like highlight [22:10] targets so that they don't [22:11] >> if there's one object, one one markup [22:14] object that had two issues, they would [22:16] stack on top of each other. You wouldn't [22:18] be able to individually click them with [22:20] a mouse. [22:21] >> You would need to use the highlighter to [22:24] >> the previous and next buttons to find [22:26] them. And before we made the recent [22:28] change, they may not be in the correct [22:29] order. They may actually be very [22:32] different. They might not be side by [22:33] side in the previous and next. Um, now [22:36] they are, which is, you know, a good [22:38] improvement, but I did previously make [22:40] an affordance that would add five plus [22:44] pixels off to the side, which would [22:47] allow them to be clickable as well. Um, [22:50] as a side effect of that introduce some [22:53] bugs. [22:54] >> Yeah. Yeah. and position and accounting. [22:58] >> Yeah. Which and with the adding in the [23:01] unique uh issues and reordering the DOM [23:06] the targets in the in DOM order kind of [23:09] highlighted a a little bit of a bug with [23:11] that. So this is a bug that was [23:13] generated with some of our our changes [23:15] unreleased changes. And so William took [23:18] kind of a fine tooth comb through that [23:20] positioning and uh reworked how the [23:25] targets are pos initially positioned and [23:28] how they're repainted when the page [23:30] scrolls to kind of make that just a a [23:33] more accurate and a a better uh visual [23:37] experience and to work with these new [23:40] features that we we introduced. [23:44] So [23:46] that brings us to um some more front-end [23:50] highlighter changes we made. So disable [23:54] style improvements. So we got a little [23:55] bit of feedback that our disable styles [23:59] does uh some funny things every now and [24:01] then. And um the disable styles is a bit [24:06] of a complex thing. I mean in theory [24:09] it's simple. So I if you're looking on [24:12] the frontend highlighter and you're [24:14] going through issues, you may come [24:15] across an issue where the front end [24:17] highlighter says it's not visible on the [24:19] page and there there can be many reasons [24:22] for that and the number one reason is [24:25] typically it's something that's hidden [24:27] on the desktop view. So like a mobile [24:29] menu and and there's an accessibility [24:32] issue inside of that and it and it says [24:34] hey we know this issue is not visible on [24:36] the page. you know you can toggle off [24:39] the styles and it and if you toggle off [24:42] the styles then you can see the target [24:44] and you can see the element in which uh [24:47] has the accessibility issue. So you can [24:50] toggle that it removes all the styles [24:52] from the page. You basically get like a [24:54] old school looking like HTML page and um [24:59] you know if you're from the early days [25:01] of the internet like William and I you [25:03] you were used to those HTML pages. I [25:06] kind of like it. [25:07] >> I do too. It's a little nostalgic, but [25:10] uh [snorts] [25:11] >> I do want to jump in here though and say [25:13] that earlier you mentioned that it was [25:15] quite complicated to do this disable [25:17] styles. It isn't actually complicated to [25:19] disable them at all. You just remove [25:21] them completely, but [25:23] >> reenabling them is surprisingly complex. [25:27] >> Yeah. Yeah. So, this [clears throat] was [25:29] most notably on websites that used like [25:32] page builders or websites that had a lot [25:34] of snippets or websites that had custom [25:39] code added in places throughout the page [25:43] rather than, you know, like uh your [25:46] styles and your being collected into a [25:48] unified stylesheet that's incued in the [25:51] header, which is which is a much easier [25:54] place to like pluck out and and put [25:56] back. Um, so when you were and and the [26:00] reason why is because if you have like [26:02] inline styles or you have a style tag [26:04] somewhere in the middle of the page, um, [26:07] and you have other styles that are [26:09] loaded in the header and you got maybe [26:10] you could even have styles loaded in the [26:12] footer. Who who knows? And and so you [26:14] you're you're fighting an a cascading [26:18] stylesheet inheritance g. So, every [26:22] style that's inserted has the ability to [26:25] modify or uh or inherit styles that are [26:29] added further up in the page [26:32] >> or specifically to override them if the [26:35] specificity is exactly the same. [26:37] >> Right. Right. So, [26:39] >> so the order in which the sales are [26:41] presented is quite important. [26:44] >> Quite important and it's really [26:45] highlighted on websites like that. And [26:48] um [snorts] [26:49] so we kind of reworked it a bit um to [26:53] where we are, you know, we're going [26:55] through and we're we're removing the [26:57] styles and maybe even setting flags to [26:59] where they should be. And then we're [27:01] when it the styles are reenabled, we're [27:04] we're inserting them back to where they [27:06] belong or where they or where they [27:08] started. I'm not sure if that's where [27:10] they belong, but [laughter] [27:13] >> back back to where they were. Yeah. back [27:15] to where they were in the order in which [27:17] they were there. And programmatically, [27:20] when you're doing this, you're doing it [27:21] from top down. And then when you go to [27:23] put them back, you kind of need to [27:25] reverse the order so you don't mess up [27:26] that in inheritance. [27:29] So, um, like William said, simple on its [27:32] face, but like complex in practice. [27:37] >> Yeah. And it's not just complex because [27:39] you have stylesheets to contend with. [27:41] You also have inline styles and you also [27:44] have inline style tags as well and they [27:46] are treated quite differently. um [27:49] particularly in generally in the cascade [27:51] inline styles on a specific element are [27:54] going to have the highest specificity [27:55] the highest priority all the time and if [27:59] you don't restore them back to the [28:00] existing object then that is going to be [28:03] pretty problematic because they will [28:07] instantly lose all of their specific [28:09] which you know is a thing we did see on [28:11] some test sets when we were refactoring [28:13] this is we seen images that had inline [28:15] sizing suddenly grow when you reenable [28:18] the styles. Um quite often we see an [28:20] extra space at the end of pages because [28:23] margin collapse wasn't present. [28:26] >> Yeah. [clears throat] [28:28] So we consider this quite the [28:29] improvement. Um and um we you know we [28:34] we're always trying to improve the the [28:36] product. We're always trying to take the [28:37] feedback we get about the features in [28:39] the plug-in and and make it better. And [28:42] um we consider this uh quite the [28:44] improvement. Um, so in regards to like [28:48] we did some like CPU throttling testing [28:51] of the plugin and [snorts] we were [28:53] messing with these styles. We noticed [28:55] that the styles would reload anytime you [28:58] tried to close the uh accessibility [29:00] checker uh front-end highlighter panel [29:04] and and in most CA in some cases [29:09] it only needs to actually reload those [29:11] when you have styles disabled so that [29:14] your page restores to normal. If your [29:17] styles are not disabled, it doesn't need [29:19] to do that. So, [29:20] >> and it was just whenever you closed it [29:23] doing it by default and as you said we [29:25] were doing CPU throttling and realized [29:27] that low power devices [29:30] well I already knew this but page CSS [29:33] painting on the page is quite a [29:36] expensive process in terms of CPU cycles [29:40] and most of us don't notice it dayto-day [29:41] because or you know we have high power [29:44] computers or whatever but if you're on a [29:46] mobile device for example and you have [29:47] to close that box, you're probably going [29:51] to notice a flicker because it's going [29:53] to take time to repaint every single [29:56] style that was on that page. And if we [29:57] don't need to do it, we just shouldn't. [30:00] And you know, that is now how it works. [30:02] We don't we don't do it if we don't need [30:04] to. [30:05] >> Yeah. And likely the in most cases we [30:09] don't need to do it. [30:10] >> Yes. [30:11] >> So, [30:12] >> exactly. We were absolutely doing it [30:13] [clears throat] in most cases when we [30:14] didn't require it, which is wasteful. [30:17] >> Yep. Now we don't waste those CPU [30:19] cycles. [30:20] >> So we are passing the CPU savings on to [30:23] you the accessibility checker users. [30:26] >> Yep. Save yourself like two cents of [30:28] electricity per month [30:30] >> per Yeah. per lifetime. [30:32] >> Yeah. [laughter] [30:33] It's worth it. Save the planet a little [30:35] bit at a time. [30:36] >> That's right. That's right. Um, and [30:38] plus, you know, it it it hedges against [30:41] if that reenable styles really does have [30:44] a slight issue on on any on a certain [30:48] website, it it hedges against not [30:51] modifying the page. Like, don't mess [30:53] with the page if you don't have to. [30:54] >> Correct. [30:55] >> And uh Cool. So, that was a nice little [30:59] added bonus into uh adding improvements [31:03] to the disabled styles. [31:05] So finally let's move on to uh sorting [31:09] and fasttrack improvements. [31:12] So along with uh generating unique ID uh [31:17] unique objects um we had to make a few [31:21] updates to our um [31:24] uh I'm skipping ahead to the fasttrack [31:26] one here William but the we had to make [31:29] some updates to the fasttrack [31:31] improvements [31:33] uh or to the fasttrack page so that the [31:36] numbers [31:38] uh make more sense When [31:42] it was initially coded, it was coded [31:45] under the assumption that [31:49] there there wouldn't be [31:50] >> one instance per page. [31:52] >> There be one instance of every object [31:54] per page. Whereas now that that [31:57] assumption is incorrect. There could be [31:59] five instances. There could be 99 [32:02] instances of the same code object on the [32:05] page. Um do you have this up? Do you [32:07] want to show this? Yes, I have this up [32:09] on a demo site. So, [32:14] um Oh, maybe I should zoom in cuz this [32:18] code object might be unreadable, right? [32:21] >> Yeah. [32:22] >> Yeah. So, this is our fast track page. [32:25] And as we this specific issue here is an [32:28] empty paragraph and I keep using this as [32:30] a way of testing things because this is [32:33] the smallest markup chunk that I can [32:34] write that creates an issue. Um, but as [32:38] we can see this is on five affected [32:40] pages, one failing check, which the [32:42] check is the empty paragraph tag. But [32:45] when we open the issues panel, it says [32:48] there's 15 instances of this check. [32:51] Previously, this would only be able to [32:52] detect one instance per page. So this [32:55] number would be five for instances and [32:58] five affected pages and the title of [33:01] this column was actually affected pages [33:03] previously. However, now that there can [33:06] be more than one detected markup [33:08] fragment that's the same on a page, this [33:11] has been renamed to be instances and [33:13] there's 15 instances of anti [33:15] paredagramraph across five pages. So now [33:18] this label here used to be pages and now [33:21] it is affected pages. It contains the [33:24] view pages link. If I click on this, it [33:27] opens up a panel which has one, two, [33:30] three, four, five pages and that matches [33:35] the the affected pages here. So if we [33:38] click on any one of these view on page [33:40] links, it will take us to the page and [33:42] highlight the first empty paragraph [33:44] instance. So let's see if I click on [33:47] this one. And here we go. We have a [33:49] bunch of empty paragraphs and this is [33:52] the first instance of it on this page. [33:58] >> Yeah. So previously with previous logic [34:00] this would have showed 15 pages which [34:02] would have been a bit redundant. [34:03] >> Correct. And it would have been five. So [34:05] there's probably this page here probably [34:08] has five on it. This probably has one. [34:11] there would be this link would appear [34:13] five times if there was five instances [34:15] on this page which [34:17] >> you know you don't need all of those [34:18] links [34:20] and it would read out quite nastily to [34:23] screen readers as I discovered. So [34:26] >> yeah. Yeah. So it just it'd be duplicate [34:28] links over and over again and add a bit [34:30] of confusion. So, we've kind of rolled [34:32] those all up and u tried to make this uh [34:37] logically make a little bit more sense [34:39] when we're dealing with uh duplicated uh [34:43] identical issues. [34:46] Cool. So, since you have your screen up, [34:49] do you want to jump over to the open [34:51] issue sorting? [34:54] So in a previous release we released uh [34:58] this more advanced uh sorting when it [35:01] comes to open issues. We sort by [35:03] severity and then and then by account by [35:06] count and um we made the ability to to [35:10] sort these columns. So if you want to [35:12] see what these look like ordered [35:14] differently, you can. And uh we have [35:18] since refined this a bit. Do you want to [35:21] speak to that, William? [35:23] Um yes. So I think the refinements we've [35:27] made is by default you there is now an [35:29] indicator. You can see this is by [35:31] default sorted by severity and severity [35:34] is a two-tier sort as you were just [35:36] saying. [35:37] >> Mhm. [35:37] >> Um previously there wasn't good visual [35:40] indicators. So now there is we can [35:43] change these. [35:45] Um, you also just go back to the the [35:47] default sort. [35:52] >> Yeah. So, that's the default. [35:56] >> Actually, you're you're sorted. Yeah, [35:57] you're sorting by by severity. If you [35:59] want to go back to the default, we have [36:01] a [36:02] >> reset to default sorting because the [36:04] default sorting is is a bit custom, [36:06] right? It's it's two tiered. [36:08] >> Yes, it is. So, I didn't I actually [36:09] didn't notice the count was not sorted [36:11] properly on only sort. So if you sort by [36:15] severity individually by clicking on the [36:18] the top of the table, you can you can [36:20] sort uh you can sort just by severity [36:24] without regards to the count [36:27] and and vice versa. If you want to just [36:29] see what issu issues have the highest [36:31] count, you can just click on count and [36:34] get the lowest or the highest uh count [36:36] of issues to start working on. The [36:39] reason we sort this uh default sorting [36:42] is we're trying to highlight to you [36:45] what's the most critical issue and and [36:48] which one has the most. So, like if [36:50] you're trying to, you know, improve your [36:52] accessibility [36:54] uh coverage or your numbers, you you go [36:57] you click on this top one, which in this [36:58] case is missing form label, and you fix [37:01] these four issues, and you've you fix [37:04] the most severe and the highest number [37:07] of of issues. It's it's kind of like a [37:11] what's my biggest bang for my buck, [37:13] right? Where can I most devote my time? [37:16] But if that's it's mostly for the [37:17] critical issues though is what's the the [37:20] most high severity issue that you can [37:22] solve. If you are looking for most bang [37:24] for your buck as far as raw numbers go, [37:27] you probably are going to want to use [37:29] the the fast track, [37:30] >> right? [37:31] >> Because I could fix this link here, [37:32] which would be 13 pages solved, [37:35] >> right? [37:37] >> And you just have to fix it in one [37:38] place. [37:39] >> Yes. Exactly. [37:40] >> Yeah. Yeah. Well, yeah. Yeah. In that [37:43] instance, one place. Yeah. [37:46] >> So, [37:48] yep. So, those are the improvements in [37:50] the latest releases. Um, we try to put [37:53] out releases every two weeks and we try [37:55] to move fast here and and have a really [37:58] iterative uh development release [38:00] workflow so that we can fix these things [38:02] and we can get these out to you the user [38:05] as quick as possible. Um, so we are [38:11] working on new things as well. Um, we [38:15] can't really tease too much of it, but [38:17] we are currently in a uh a workflow uh [38:22] work cycle of doing some UI improvements [38:25] to help [snorts] u bring accessibility [38:28] checker more in line with uh some modern [38:32] WordPress layouts and uh as you know [38:36] Williams pulled up here our uh current [38:39] metab box. So, a little tease is that we [38:42] are um we're kind of bringing this metab [38:45] box kind of into the WordPress editor in [38:50] a more Hey, don't don't be highlighting [38:52] stuff like don't click on that. [38:55] [laughter] [38:56] >> I can't click on it. It's broken. [38:58] >> Okay. [38:58] >> Haven't I haven't made it work yet. [39:00] >> So, William's teasing here. He's he's uh [39:04] looking at the WordPress editor sidebar [39:06] and there there appears to be something [39:09] in regards to accessibility checker in [39:11] that sidebar that I will not speak of [39:14] here but I just want to let uh our users [39:17] know that um we're doing a lot of UI and [39:21] UX enhancements to try to improve the [39:24] experience and the layout of our metab [39:26] box and we are really excited to get [39:30] this out to you here in uh and an [39:32] upcoming release hopefully not too too [39:35] far from now. So, [39:38] well, that's our episode. Kind of a [39:40] short one this time. Um, but uh some [39:44] important features, you know, having [39:46] unique being able to identify uh items [39:50] uniquely is huge. And being able to [39:52] improve the selector and the accuracy of [39:54] the front-end highlighter we think is [39:57] pretty huge. and uh being able to [40:00] restore those styles without issues is [40:02] seems minor, but it's it's important. [40:06] So, we're always continually improving [40:08] the accessibility checker, and we do [40:11] these live streams twice a month. Um, we [40:14] do it on the first and third, [40:18] >> the second and the fourth. [40:19] >> Second and fourth. That's right. Second [40:21] and fourth. I'm off because of January [40:23] because like January 1st was like on a [40:26] Thursday and that would have been Well, [40:28] I I think technically it's the second [40:30] and the last. [40:31] >> Yeah, the second. [40:32] >> Some months might have five. [40:34] >> Yeah. Yeah. So, we should be on a normal [40:37] uh schedule for February. So, uh look [40:41] for this live stream here in a couple [40:43] weeks and we look forward to joining you [40:45] and and thanks for being with us today. [40:48] See you.  [[3. Resources/Readwise/Full Document Contents/Articles/Stability, Ordering, and Issue Clarity|Full Document Contents]] ## Document Notes --- tags: #wordpress #accessibility #automated-testing #web-development #plugin-development author: Equalize Digital source: YouTube reference: https://www.youtube.com/watch?v=2hwdgKtM6C0 date created: 2025-01-26 20:45 --- # 🏷️ Title: Stability, Ordering, and Issue Clarity - Accessibility Checker Plugin Updates ## 🧰 Action Inbox - [H1] Update accessibility scanning workflow to leverage unique selector-based identification — reduces false positives #wordpress #accessibility - [H2] Test new DOM ordering functionality on sites with multiple identical issues — improves remediation workflow #automated-testing - [H3] Review fasttrack improvements for better issue prioritization — maximizes accessibility improvement efficiency #web-development ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Accessibility Checker Plugin](https://equalizedigital.com/accessibility-checker/) - [WordPress Block Editor](https://wordpress.org/support/article/wordpress-editor/) ## 📝 Summary - Equalize Digital released significant updates to their Accessibility Checker WordPress plugin (free v1.37.0, pro v1.2.0) - Core improvement: switched from HTML markup-based to CSS selector-based unique issue identification - Why it matters: eliminates false grouping of identical issues, improves accuracy and user experience - Key stakeholders: WordPress developers, accessibility professionals, site maintainers - Risks: requires database updates, potential edge cases in selector generation - Bottom line: more accurate accessibility scanning with better performance and user workflow ## 📖 Main Content The Accessibility Checker plugin historically identified unique issues based on HTML markup fragments. This approach created problems when multiple identical elements (like empty paragraph tags) existed on the same page - the system would only flag the first occurrence and group subsequent instances as duplicates. The new selector-based approach uses CSS selectors with nth-child values to uniquely identify each issue instance. For example, empty paragraph tags are now identified as "p:nth-child(5)", "p:nth-child(6)", etc., rather than just "". Technical improvements include: - **Performance gains**: Selector-based queries are approximately 15x faster than markup-based searches - **DOM ordering**: Issues now display in top-to-bottom page order rather than database storage order - **Enhanced highlighting**: Front-end issue highlighting uses native JavaScript querySelector for accuracy - **Fallback system**: Three-tier system tries selector, then ancestor, then legacy markup for maximum reliability The plugin also refined style management for the "disable styles" feature, addressing complex cascading stylesheet scenarios common in page builders and custom implementations. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/2hwdgKtM6C0?t=0) — [H1] Live stream introduction and plugin overview - Key idea: Second live stream of 2026 covering Accessibility Checker updates - Evidence: "Free plugin release is version 1.37.0 and the pro release version is 1.2.0" #### ⏱️ [03:45](https://youtu.be/2hwdgKtM6C0?t=225) — [H2] Core problem: Issue identity challenges - Key idea: Historical grouping of identical markup caused accuracy problems - Evidence: "If you had two identical issues on the same page, the accessibility checker would think they were the same and would only surface it once" #### ⏱️ [05:30](https://youtu.be/2hwdgKtM6C0?t=330) — [H1] Empty paragraph example demonstrates the problem - Key idea: Block editor easily generates multiple empty paragraphs that appear identical - Evidence: "If you had like three empty paragraph tags, the plugin would say 'Hey, you have an empty paragraph tag.' And you would fix it. And then it would say 'Hey, you have an empty paragraph tag'" #### ⏱️ [07:15](https://youtu.be/2hwdgKtM6C0?t=435) — [H1] Database preparation for selector-based system - Key idea: Plugin has been collecting selector data for 8-9 months in preparation - Evidence: "We've quietly been collecting this data in the database... We haven't been collecting it. It's in your database on your website" #### ⏱️ [09:20](https://youtu.be/2hwdgKtM6C0?t=560) — [H2] Database structure demonstration - Key idea: Selectors provide unique identification with nth-child values - Evidence: Database shows "p:nth-child(5)" as unique identifier vs generic "" markup #### ⏱️ [13:45](https://youtu.be/2hwdgKtM6C0?t=825) — [H1] Performance improvements from selector approach - Key idea: Selector queries are significantly faster than markup fragment searches - Evidence: "Searching by this selector is probably 15 times faster than searching by this item" #### ⏱️ [16:30](https://youtu.be/2hwdgKtM6C0?t=990) — [H2] Native JavaScript integration benefits - Key idea: CSS selectors work directly with document.querySelector - Evidence: "This selector right here can be passed into native JavaScript functions... Document.querySelector is the function and this is native JavaScript" #### ⏱️ [19:00](https://youtu.be/2hwdgKtM6C0?t=1140) — [H1] User experience improvements from accurate counting - Key idea: Plugin now counts multiple instances as separate issues for accurate assessment - Evidence: "We're no longer grouping like five empty paragraphs together and counting it as one. We will actually now count that as five individual issues" #### ⏱️ [22:15](https://youtu.be/2hwdgKtM6C0?t=1335) — [H2] DOM ordering enhancement - Key idea: Issues now display in top-to-bottom page order instead of database order - Evidence: "We've decided to order from the top of the DOM down. So your first issue in the DOM will be the first one that's highlighted" #### ⏱️ [25:40](https://youtu.be/2hwdgKtM6C0?t=1540) — [H1] Three-tier fallback system for reliability - Key idea: Layered approach ensures issues are found even if primary method fails - Evidence: "It first tries to use the unique selector... if that fails, then it would go down to the ancestor... in the rare case that both fail, it will go to our legacy code object selector" #### ⏱️ [28:30](https://youtu.be/2hwdgKtM6C0?t=1710) — [H2] Highlighter positioning improvements - Key idea: Fixed bugs in visual positioning when multiple issues exist on same element - Evidence: "William took kind of a fine tooth comb through that positioning and reworked how the targets are positioned" #### ⏱️ [31:20](https://youtu.be/2hwdgKtM6C0?t=1880) — [H1] Disable styles functionality refinements - Key idea: Complex style restoration improved for page builders and inline styles - Evidence: "We're inserting them back to where they belong or where they started... you need to reverse the order so you don't mess up that inheritance" #### ⏱️ [38:45](https://youtu.be/2hwdgKtM6C0?t=2325) — [H2] CPU performance optimization - Key idea: Eliminated unnecessary style repainting when closing highlighter - Evidence: "We noticed that the styles would reload anytime you tried to close the accessibility checker front-end highlighter panel... in most cases it only needs to actually reload those when you have styles disabled" #### ⏱️ [42:10](https://youtu.be/2hwdgKtM6C0?t=2530) — [H1] Fasttrack improvements demonstration - Key idea: Better counting and labeling for multiple instances of same issue type - Evidence: "15 instances of empty paragraph across five pages... this label here used to be pages and now it is affected pages" #### ⏱️ [46:30](https://youtu.be/2hwdgKtM6C0?t=2790) — [H2] Sorting enhancements with visual indicators - Key idea: Improved default sorting by severity and count with better UI indicators - Evidence: "By default sorted by severity and severity is a two-tier sort... now there is good visual indicators" ## 📚 References - [Accessibility Checker Free Plugin](https://wordpress.org/plugins/accessibility-checker/) - [Accessibility Checker Pro Plugin](https://equalizedigital.com/accessibility-checker/) - [CSS Selectors Documentation](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Selectors) - [Document.querySelector Reference](https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector) ## 🗣️ Paraphrase - The plugin switched from identifying issues by HTML markup to using CSS selectors, which provides unique identification for each issue instance and dramatically improves performance - DOM ordering now presents issues from top to bottom of the page rather than in database storage order, creating a more logical workflow for remediation - Style management was refined to handle complex cascading scenarios and eliminate unnecessary CPU-intensive repainting operations when the highlighter panel closes ## 📰 Newsletter **Major Accessibility Checker Plugin Update Improves Issue Detection Accuracy** The latest Accessibility Checker releases (free v1.37.0, pro v1.2.0) deliver significant improvements to how the plugin identifies and manages accessibility issues on WordPress sites. The biggest change addresses a longstanding challenge: when multiple identical elements (like empty paragraph tags) existed on a page, the plugin would only flag the first occurrence. Now, using CSS selector-based identification, each issue gets unique tracking - meaning you'll see accurate counts and can systematically fix all instances. **Key Benefits:** - **15x faster** issue detection using native CSS selectors - Issues display in logical top-to-bottom page order - More accurate accessibility scoring and reporting - Improved front-end highlighting performance **Practical Impact:** If your site had 5 empty paragraph tags, the old system showed "1 issue" that seemed impossible to fix. The new system correctly shows "5 issues" with precise locations, making remediation straightforward and progress trackable. The updates also refined the "disable styles" feature for complex page builder sites and added CPU optimizations that especially benefit mobile users and lower-powered devices. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### WordPress - Core: Evaluate selector-based approaches for core accessibility features - Themes: Test theme compatibility with new accessibility scanner highlighting - Plugins: Review plugin interaction with automated accessibility tools - Documentation: Update accessibility testing guidance to reflect new capabilities - Community: Share accessibility scanning improvements with developer community #### DevRel - Education: Create workshops on automated accessibility testing workflows - Developer experience: Document integration patterns for accessibility plugins - Developer marketing: Highlight accessibility tooling improvements in WordPress ecosystem - Community management: Gather feedback on accessibility plugin user experience #### Community - Maintainers: Evaluate automated accessibility testing in plugin development workflows - Contributors: Share accessibility scanning results and remediation strategies - Sponsors: Support accessibility tooling development through plugin sponsorship ## 🧪 Hypotheses - Selector-based issue identification will reduce false positive groupings by 90%+ compared to markup-based approach - DOM ordering will decrease remediation time by providing logical top-to-bottom workflow - Performance improvements will have greatest impact on mobile devices and lower-powered systems - Accurate issue counting will improve accessibility improvement tracking and goal-setting ### 📊 Methodology - A/B testing between markup-based and selector-based identification accuracy - Performance benchmarking across device types and CPU capabilities - User experience studies measuring remediation workflow efficiency - Database query performance analysis comparing search methods ### ❓ Questions - How will the three-tier fallback system perform in edge cases with complex dynamic content? - What impact will more accurate issue counting have on accessibility compliance reporting? - How can other WordPress accessibility tools adopt similar selector-based approaches? ### 🔮 Future Research - Integration of automated accessibility scanning with WordPress core development workflows - Standardization of accessibility issue identification across WordPress ecosystem tools - Performance optimization techniques for real-time accessibility scanning ### 💡 Implications - Practice: More reliable automated accessibility testing enables better compliance workflows - Policy: Accurate issue tracking supports more meaningful accessibility compliance reporting - Education: Improved tooling reduces barrier to entry for accessibility testing and remediation - Funding: Better automation may shift accessibility budget allocation toward remediation vs. detection ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: Database structure screenshots, UI comparisons, selector examples - Improve: Workflow diagrams showing before/after issue detection processes #### 🔊 Aural learners - Present: Live demonstration with verbal explanation of technical concepts - Improve: Audio-only summary of key improvements and benefits #### 🗣️ Verbal learners - Present: Technical terminology explained with analogies, step-by-step descriptions - Improve: Glossary of CSS selector and accessibility testing terms #### 🧩 Kinesthetic learners - Present: Live database queries, interactive plugin demonstration - Improve: Hands-on tutorial for testing new features, practice exercises #### 🧠 Logical learners - Present: Performance benchmarks, systematic problem-solution explanation - Improve: Decision tree for when to use different identification methods #### 🧑‍🤝‍🧑 Social learners - Present: Live Q&A format, community-focused live stream - Improve: User forum discussion prompts, peer testing groups #### 🧘‍♀️ Solitary learners - Present: Detailed technical documentation, self-paced feature exploration - Improve: Written implementation guides, independent testing checklists #### 🌿 Naturalistic learners - Present: Real-world website examples, ecosystem impact discussion - Improve: Environmental impact of performance improvements, sustainability connections ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear headings, technical concepts explained in context - Improve: More descriptive alt text for database screenshots #### Keyboard navigation - Present: Standard video controls, accessible live stream interface - Improve: Keyboard shortcuts for navigating technical demonstrations #### Contrast and readability - Present: Standard video player with good contrast - Improve: High contrast code examples, larger font sizes for technical content #### Text resizing and reflow - Present: Responsive video player, scalable interface - Improve: Ensure technical diagrams remain readable at 200% zoom #### Media and captions - Present: Video content with live audio narration - Improve: Add captions for technical terminology, provide transcript #### Forms and interactions - Present: Basic video interaction controls - Improve: Accessible comments and feedback forms for live streams ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focus on WordPress global community impact - Improve: Examples from different geographic regions, accessibility law variations #### Inclusive language - Present: Technical language explained clearly, avoiding jargon - Improve: Define all technical terms, provide plain language summaries #### Neurodiversity support - Present: Clear structure with timestamps, logical progression - Improve: Visual breaks between sections, consistent formatting #### Representation - Present: Technical discussion focused on tool improvements - Improve: Diverse use cases, different user perspectives on accessibility needs #### Psychological safety - Present: Supportive tone about accessibility challenges - Improve: Acknowledge accessibility learning curve, provide encouragement ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Technical problem → solution → implementation results follows logically - Inductive strength: Performance testing → generalized improvement claims well-supported --- ## Full Transcript [00:05] All right, [snorts] we're live. [00:09] How's it going? [00:10] >> Yeah, it's going pretty good. No [00:12] complaints. [00:13] >> No complaints. Well, that's good. [00:16] >> I've got lots of complaints, but end up [00:18] in here. [00:21] >> Yeah. So, it looks like uh looks like [00:23] we're going out live just fine. Um, [00:27] we check X and make sure we're doing [00:31] we're going out there. [00:36] Okay. [00:38] Yeah. So, second live stream of 2026. We [00:42] are just plowing through 2026 already. [00:46] >> Only one 12th of the way. [00:48] >> Only 112th. But boy, it went fast, [00:50] didn't it? [00:51] >> Yep, it did for sure. [00:55] It did. So, we have been busy working on [00:58] new features for accessibility checker [01:02] and yep, looks like we're going out live [01:04] on X. So, cool. So, welcome anybody [01:10] joining now or after the fact. Uh we do [01:14] pre we do uh save these recordings for [01:16] later so you can enjoy them in your in [01:18] your own time and in your own leisure. [01:21] Um, [01:22] this is the accessibility craft change [01:25] log liveream [01:27] uh where we go over the latest features [01:29] in the accessibility checker WordPress [01:31] plugin which is an automated [01:33] accessibility [01:34] scanning plugin to help your website [01:36] become and stay accessible. We have a [01:39] full suite of plugins. We have a free [01:41] plugin uh that is fullfeatured for [01:44] scanning uh individual post. We have a [01:46] pro plugin where you can do site level [01:49] scans and get more advanced uh auditing [01:53] and remediation features. And then we [01:55] have a few add-ons that go along with [01:57] our pro plugin. We have an audit history [01:59] to track accessibility issues over time. [02:01] A multi-sight plugin to help uh you uh [02:05] manage your accessibility licenses and [02:09] stats and activations at the network [02:12] site level of a WordPress multicight. [02:15] And we have an export add-on that allows [02:17] you to export your issues to CSV. So you [02:20] can import them into any uh system you [02:23] desire. So today we're talking about [02:27] stability, ordering, and issue clarity. [02:30] So it's not a huge release, but it's an [02:32] important release. So we're continually [02:34] we're always trying to refine things and [02:36] make things better and to be able to [02:40] detect issues with greater accuracy. And [02:43] in this case, being able to surface uh [02:47] identical issues where we have [02:50] historically had uh a little bit of [02:52] trouble surfacing those accurately. [02:56] So the the plug-in updates are in our [02:59] free plugin and our pro plugin. Free uh [03:02] plug-in release is version 1.37.0 [03:07] and the pro release version is 1.2.0. [03:13] All right. So, welcome William. [03:16] >> Hey, [03:17] >> doing good. [03:19] >> Yeah, doing good to there. [03:20] >> All right. So, [03:23] let's dive in and start going through [03:26] these and William will help me describe [03:28] some of the things that we've done and [03:31] uh some of these improvements. So, first [03:32] off, we're going to start with issue [03:34] identity, knowing when two things are [03:37] the same. [03:38] So, historically, like I mentioned, um [03:41] if you had two identical issues on the [03:44] same page, the accessibility checker [03:47] would a lot of times think that they [03:50] were the same and would only surface it [03:52] once. [03:54] And what we've and and this is because [03:56] of the way that AC accessibility checker [03:58] has historically worked and how it [04:02] uniquely or how it was identifying [04:04] issues and basically it was evaluating [04:07] based on the the code object that it [04:11] detected as the issue on the page. And [04:15] do you want to describe why that's [04:17] problematic, William? [04:19] >> Yeah. So if pre previously the entire [04:22] HTML fragment was the unique identifier [04:25] for an individual issue and that you [04:29] know in some instances might be true. [04:32] You might only have one skip link on a [04:33] page. That's fine. You might only have [04:35] one homepage logo on a page. That's also [04:38] fine. But what you're likely to also [04:40] have is a lot of paragraphs. And say for [04:43] example there's two empty paragraph [04:45] tags. they will look exactly the same as [04:47] far as our system processing [04:50] previously would work. So only the first [04:52] discovered item would be flaggable. The [04:55] subsequent items would be considered as [04:58] the same. The the system wouldn't know [05:00] that it was a second item. And in most [05:02] cases that's fine. In some cases it's [05:06] not. As I said in in the case of empty [05:08] paragraphs, but what if you also had the [05:10] same broken link on a page? it would [05:14] only be flagged once and that has some [05:17] cascading issues. So, if you fix the [05:20] link, the issue wouldn't go away. You [05:22] would think you fixed it because you [05:24] would see the first instance of that [05:26] issue. You would be able to click the [05:28] the view on page button. It would take [05:30] you to it. You would fix it. The issue [05:32] wouldn't go away. It would actually just [05:34] highlight another issue on subsequent [05:37] scans. So, it would look like you're it [05:39] would effectively look like you're not [05:41] doing anything and hence the the [05:43] problem. it wasn't an issue for a long [05:45] time or wasn't realized to be an issue [05:48] for a long time, but it it turns out [05:50] there are some some pretty nasty edge [05:53] cases that [05:55] >> make things maybe not necessarily [05:58] true. [05:59] >> Yeah. Yeah. And I think where it pops up [06:00] a lot of times is like in the WordPress [06:03] block editor, like it's very easy to [06:06] generate empty paragraph tags just by, [06:09] you know, hitting a return in the wrong [06:11] place and not putting any any uh, you [06:14] know, text. And so like you can end up [06:17] with empty paragraph tags. And like [06:18] William said, if you had like three [06:20] empty paragraph tags, the plugin would [06:23] say, "Hey, you have an empty paragraph [06:24] tag." And you would fix it. And then it [06:25] would say, "Hey, you have an empty [06:26] paragraph tag." then you would fix the [06:28] next one until they were losing. [06:30] >> So because that issue was so prevalent, [06:32] there was some affordances added that [06:34] made padigraphs technically unique. So [06:37] there would be if you had three empty [06:39] paragraphs, it would be stored as three [06:40] unique games. However, then they [06:42] wouldn't properly be grouped in the pro [06:44] plugins open initials tab, the fasttrack [06:46] tab because they weren't the same markup [06:50] object because we treated the markup [06:52] object as the only unique aspect when [06:55] that just ended up just not being true. [06:59] >> Yeah. So to that um this has been quite [07:03] some time in the making and uh we we [07:07] started storing additional uh selector [07:11] information in the database. I I want to [07:14] say like eight or nine months ago. [07:16] >> It's been quite a while. I think most [07:19] people will already have selector data [07:21] stored. [07:23] >> Yeah. So we've quietly been collecting [07:25] this data in in the database in in your [07:28] database. We haven't been collecting it. [07:30] It's in your database on your website [07:32] and [07:32] >> your website, your data, your markup. [07:35] >> Yeah. So when we scan a rule, we get uh [07:40] uh certain artifacts that come from that [07:42] scan and of course the code object is [07:44] one and we have historically been using [07:47] that as the source of truth for what's [07:49] unique. And you have a selector, you [07:52] have an ancestor, and you have an [07:55] expath. And so those three uh metrics [08:00] have been or those three artifacts of [08:02] the scan have have been added in several [08:06] releases ago so that when we did switch [08:08] to this we didn't we didn't have to uh [08:12] you know run an update process or um but [08:16] that being said if for some reason [08:19] somebody hasn't scanned in like nine [08:20] months we do have an update process in [08:24] in that case to actually put in a unique [08:26] identifier into that selector field so [08:29] that the functionality we've added will [08:31] work even if you haven't rescanned in 9 [08:35] months. [08:37] So in making the making every like empty [08:42] paragraph unique. So now we've switched [08:44] to the selector as the unique identifier [08:48] and and how does that make it unique [08:50] William? Why is that any different than [08:53] the code object? Yeah. So, if you want [08:55] to pull up my screen, I actually have an [08:58] actual database from one of my test sets [09:00] up that shows how this is unique. So, [09:03] right here we have previously how we [09:05] would store paragraph tags and this [09:08] markup fragment here signifies a less [09:11] than tag [09:13] and some of these require signify [09:15] greater than tags. But this is an empty [09:17] P tag and if you see this inside the [09:19] curly brackets there is a p child five. [09:24] So this is the fifth P tag on [09:28] post ID [09:30] 2616. [09:32] [snorts] [09:33] So this is a unique selector. However, [09:35] this was not how we originally were [09:38] storing the selectors. If I scroll up to [09:40] the the top of this, you can see here [09:43] this does not contain the nth child [09:45] value in the object. However, we have a [09:48] selector over on this side. And if we [09:52] see here sixth, seventh, eighth child, [09:54] ninth, 10th child. So these all appear [09:56] on the same page and these are the [09:58] unique selectors for this object. This [10:01] is quite a simple selector, the sixth [10:03] paragraph tag on the page. And we are [10:06] fairly certain that this is a unique [10:08] selector. However, sometimes the [10:10] selector isn't as simple as this one. [10:12] For example, [10:14] this item here, which is a YouTube [10:17] embedded frame. So this selector is much [10:20] [clears throat] longer. It has [snorts] [10:24] four different levels of of selector [10:28] only the iframe is the same that we are [10:30] targeting but it's inside an embed [10:33] wrapper from core which has an [10:36] identifier of an embedded YouTube block [10:40] and it's inside from a plug-in from [10:42] called newsletter glue. So all of these [10:45] combined together to make this unique [10:48] and the reason that the selector is so [10:50] long is because there probably is other [10:52] iframes on this page. That means the I [10:56] frame on its own is not sufficient. Um [10:59] if we look at the item above this, this [11:01] is wp- image-570. [11:05] This is unique on the page. This is a [11:07] unique selector and as such can be short [11:10] and with these selectors it is far [11:12] easier to identify the actual item on [11:16] the page. So if we look at this which is [11:19] row 21 in the database this image scroll [11:22] back to what the object looks like it it [11:26] is significantly larger. [11:28] >> Mhm. [11:29] >> Some most of the markup fragments will [11:31] be much larger than the the selectors [11:34] now. So we will be more effective in [11:36] what we have to deliver to the page to [11:38] find games aims [11:40] >> and and more efficient to some degree in [11:43] some of our queries as well. [11:45] >> Correct. I think I've done some initial [11:47] measurements, nothing entirely [11:49] scientific, but searching by [11:53] this selector is probably 15 times [11:56] faster than searching by this item. Um, [12:00] it is roughly the same when you're [12:01] searching for a paragraph because it's a [12:03] small markup fragment, but the larger [12:06] the markup fragment is, the more time [12:09] we're going to save on our queries. So, [12:12] yeah, ultimately we're going to save [12:13] several seconds every time we done run a [12:15] scan. [12:16] >> Mhm. [12:16] >> Most likely. [12:19] >> Yeah. So, switch switching to using this [12:21] selector uh is is a better long-term uh [12:26] solution for the plugin. And uh it you [12:29] know it brings a certain level of [12:31] stability and consistency in issue [12:34] tracking whereas the selector is kind of [12:37] it's a kind of a known pattern on how [12:39] that's generated. Whereas a piece of [12:42] relying on markup alone can can is can [12:45] can really it could be anything and [12:47] we're not in complete control of the [12:50] markup that's detected. Well, but if we [12:53] were searching by this markup, um, we we [12:56] previously did write the code that would [12:58] find this markup on the page and handle [13:00] the highlighting. And it was a a rather [13:03] complicated solution to to find this and [13:05] also not very performant on the front [13:07] end, whereas this selector right here [13:10] can be passed into native JavaScript [13:12] functions. [13:14] >> Yep. [13:16] Yep. Without any fancy parsing. Yep. [13:20] >> Document.wi query selector is the the [13:22] function and this is native JavaScript. [13:25] Almost everyone will have probably used [13:28] this if they have ever written [13:29] JavaScript before and you can find this [13:31] exact element with this one line. [13:34] Nothing else required and we because we [13:37] have made sure that this is stored as a [13:39] unique selector. We know this is only [13:41] going to return one object. It's never [13:43] going to return more than one. [13:50] >> Yeah. So I mean the reason why this [13:51] matters for accessibility is is that we [13:54] can surface and report on the overall [13:58] state of the accessibility more [14:00] accurately. So we're not we're no longer [14:02] grouping like say five empty paragraphs [14:06] together and counting it as one. we will [14:09] actually now count that as five [14:11] individual issues giving you more more [14:14] of an accurate uh assessment and [14:16] accurate stats on where the [14:18] accessibility of your page sits. [14:22] >> And not to call it something that was [14:24] negative about the way we were doing it [14:25] previously. However, we have had at [14:27] least one customer support query come in [14:29] where someone was fixing an issue and [14:32] getting slightly frustrated that the [14:34] issue was never going away. And the [14:36] reason why is because there was several [14:37] of this the same markup on the page and [14:40] they were fixing one and the next one [14:42] was the one identified and it it was [14:45] frustrating for them. So now we're [14:46] removing that as a potential issue that [14:49] someone might run into. [14:51] >> Right. Right. So reducing noise and [14:53] >> correct. [14:54] So, it's repeated noise to and it's [14:58] putting a lot on the remediator's hands [15:00] to to say they're they identify an [15:04] issue, they fix it, and then then it's [15:05] they're presenting with the exact issue. [15:07] It's not the exact issue, but it'll [15:09] actually [15:10] >> and then it looks like the same issue in [15:11] the back end, unless they're using the [15:13] front end highly, they might not know [15:15] that it's a different instance. [15:17] >> Yep. Cool. So, [15:19] >> no longer an issue. [15:20] >> No longer an issue. So all of your [15:22] duplicate uh uh identical markup will [15:27] now be uniquely identified by [15:29] accessibility checker. So that was kind [15:31] of the first step in improving that. And [15:34] then we've taken that and we've done the [15:37] second step which is improving the [15:39] front-end highlighter [15:41] uh in regards to uh you know uh [15:45] surfacing unique issues and the [15:48] stability around having these selectors [15:51] and the ancestor and and XPath and [15:55] improving how um issues are identified [15:59] and highlighted on the uh front-end [16:01] highlighter. [16:03] So, I'll pull us back up, William. Um, [16:08] so we added stability selectors and DOM [16:11] ordering. So, before in the front-end [16:14] highlighter, you would when you would [16:17] pull up an issue and we have a next and [16:19] a previous button. So, you can just, you [16:21] know, quickly toggle through the issues [16:23] on the page, [snorts] it would actually [16:25] go in the order in which those issues [16:28] were identified and stored in the [16:30] database. [16:32] And um we wanted to give a more uh [16:37] seamless and fluid experience to going [16:41] through the the front end of your [16:43] website and and fixing accessibility [16:46] issues. So we've decided to order from [16:49] the top of the DOM down. So your first [16:53] issue in the DOM will be the first one [16:55] that's highlighted and then so on down [16:58] the page. [17:00] And this helps just bring bring a a less [17:06] jumpy experience to tabbing through [17:09] those because if issues were identified [17:10] in the top of the page and then the [17:12] bottom of the page, it would lit [17:13] literally jump down to the bottom of the [17:15] page and then jump back to the top of [17:17] the page. So it's it's just a way of [17:20] making it more of a seamless experience. [17:24] And um [17:26] in do in doing that we switched it to [17:30] using the selector to identify these [17:33] these issues and so the targets actually [17:37] end up more accurately in the right [17:39] place. [17:41] Um, [17:42] >> and like I said earlier on, it is at [17:44] least 15 times faster at discovering [17:47] these issues on the front end, which [17:50] might not matter so much for someone who [17:51] has a fairly high-end PC, but for [17:54] someone that might have a PC that is [17:56] running background tasks or doing other [17:59] things, it is actually noticeable. I [18:02] didn't realize how noticeable it was [18:03] until we ran the the CPU throttle [18:06] simulation yesterday [18:08] >> and it it is quite a lot faster to find [18:11] by selector. Yeah, because I mean a a a [18:15] code object [18:17] like William said could be I mean it [18:19] could be a thousand characters like I [18:22] mean we've done a really good job of of [18:24] reducing that down to the to the [18:26] smallest uh HTML character we can to [18:30] identify the issue but it could be a [18:32] pretty big piece of code and when you [18:35] take that and then you try to parse it [18:37] and generate a selector from it uh there [18:40] can be some inconsistencies and We [18:42] actually did work on so the the [18:45] front-end highlighter that we would [18:47] actually take that code object and we we [18:49] would pull out and generate a JavaScript [18:51] selector from it. And what what we've [18:54] done is we've taken and that had been [18:56] refined over over several years and it [18:59] was very accurate but this is actually [19:02] more accurate than that. And not only [19:05] that, using the selector is it more [19:07] accurate, it's it's like William said, [19:09] it's way more performant to only pull [19:11] like in some of those cases it's five [19:13] characters and you have a unique [19:15] identifier whereas you know the code [19:18] object could be quite a few you know [19:20] like it could be a 100 characters easily [19:22] >> and um and and so the so we had that we [19:28] would build a selector before and what [19:30] we've done is we still have that [19:32] functionality And from a programmatic [19:35] standpoint, what we've done is we've [19:36] built a layered uh kind of try and uh [19:41] switch case kind of like u it first [19:45] tries to use the unique selector to find [19:47] the issue on the page and if it actually [19:50] fails to do that which in most cases I [19:53] don't think it will. [19:53] >> I have not found a fail case in the last [19:56] like two weeks. [19:57] >> It always finds the selector. [20:00] If if that fails, then it it would it'll [20:03] go down to the ancestor and it'll try to [20:06] find it with the unique ancestor. And in [20:10] the rare case that both of those [20:11] actually fail to identify the issue, it [20:14] will go to our our legacy code object [20:18] selector to try to find it. So, we're [20:21] doing everything we can to make the the [20:23] selection of these issues on the front [20:25] end of your page as accurate as [20:27] possible. And we can't promise 100% [20:30] accuracy, but I would say that it is [20:32] very close to that now at finding issues [20:35] on the page. [20:36] >> Yeah. Well, one of the the benefits of [20:38] the selectorbacked [20:40] discovery is an issue I've previously [20:42] run into is code on the front end of a [20:45] website changing what the HTML looks [20:48] like. Sometimes it injects data [20:49] attributes for [20:52] image lazy loading or you know pre [20:56] prefetch like a lot of things are added [20:59] sometimes on the page after it renders [21:02] and if you're searching for a specific [21:04] issue and the markup has changed then [21:07] sometimes you are not going to be able [21:09] to find that item. [21:11] >> Y sorry William looks like I dropped [21:14] off. Um [clears throat] [21:15] >> that's fine. I was yammering away. [21:18] [laughter] [21:19] >> There we go. And it's We're back. And [21:25] cool. Looks like we switched positions, [21:27] but I like you on the left. It's better. [21:28] It's good. [21:30] >> I think I can move it, but I'm afraid [21:32] to. Yeah. So, we we must have a we must [21:35] had an internet uh problem there. But, [21:37] uh [21:39] >> Cool. [21:40] >> I think we're moving on to the what the [21:42] changes to the highlighter position. [21:44] Yeah, [21:45] >> which also be got more significantly [21:48] more accurate [21:50] um in terms of visually where it gets [21:52] placed and also the order in which the [21:56] AMS are presented. [22:00] >> Yeah. So in a previous release, William, [22:02] you had worked on a feature to try to [22:04] spread out [22:06] uh uh targets like it like highlight [22:10] targets so that they don't [22:11] >> if there's one object, one one markup [22:14] object that had two issues, they would [22:16] stack on top of each other. You wouldn't [22:18] be able to individually click them with [22:20] a mouse. [22:21] >> You would need to use the highlighter to [22:24] >> the previous and next buttons to find [22:26] them. And before we made the recent [22:28] change, they may not be in the correct [22:29] order. They may actually be very [22:32] different. They might not be side by [22:33] side in the previous and next. Um, now [22:36] they are, which is, you know, a good [22:38] improvement, but I did previously make [22:40] an affordance that would add five plus [22:44] pixels off to the side, which would [22:47] allow them to be clickable as well. Um, [22:50] as a side effect of that introduce some [22:53] bugs. [22:54] >> Yeah. Yeah. and position and accounting. [22:58] >> Yeah. Which and with the adding in the [23:01] unique uh issues and reordering the DOM [23:06] the targets in the in DOM order kind of [23:09] highlighted a a little bit of a bug with [23:11] that. So this is a bug that was [23:13] generated with some of our our changes [23:15] unreleased changes. And so William took [23:18] kind of a fine tooth comb through that [23:20] positioning and uh reworked how the [23:25] targets are pos initially positioned and [23:28] how they're repainted when the page [23:30] scrolls to kind of make that just a a [23:33] more accurate and a a better uh visual [23:37] experience and to work with these new [23:40] features that we we introduced. [23:44] So [23:46] that brings us to um some more front-end [23:50] highlighter changes we made. So disable [23:54] style improvements. So we got a little [23:55] bit of feedback that our disable styles [23:59] does uh some funny things every now and [24:01] then. And um the disable styles is a bit [24:06] of a complex thing. I mean in theory [24:09] it's simple. So I if you're looking on [24:12] the frontend highlighter and you're [24:14] going through issues, you may come [24:15] across an issue where the front end [24:17] highlighter says it's not visible on the [24:19] page and there there can be many reasons [24:22] for that and the number one reason is [24:25] typically it's something that's hidden [24:27] on the desktop view. So like a mobile [24:29] menu and and there's an accessibility [24:32] issue inside of that and it and it says [24:34] hey we know this issue is not visible on [24:36] the page. you know you can toggle off [24:39] the styles and it and if you toggle off [24:42] the styles then you can see the target [24:44] and you can see the element in which uh [24:47] has the accessibility issue. So you can [24:50] toggle that it removes all the styles [24:52] from the page. You basically get like a [24:54] old school looking like HTML page and um [24:59] you know if you're from the early days [25:01] of the internet like William and I you [25:03] you were used to those HTML pages. I [25:06] kind of like it. [25:07] >> I do too. It's a little nostalgic, but [25:10] uh [snorts] [25:11] >> I do want to jump in here though and say [25:13] that earlier you mentioned that it was [25:15] quite complicated to do this disable [25:17] styles. It isn't actually complicated to [25:19] disable them at all. You just remove [25:21] them completely, but [25:23] >> reenabling them is surprisingly complex. [25:27] >> Yeah. Yeah. So, this [clears throat] was [25:29] most notably on websites that used like [25:32] page builders or websites that had a lot [25:34] of snippets or websites that had custom [25:39] code added in places throughout the page [25:43] rather than, you know, like uh your [25:46] styles and your being collected into a [25:48] unified stylesheet that's incued in the [25:51] header, which is which is a much easier [25:54] place to like pluck out and and put [25:56] back. Um, so when you were and and the [26:00] reason why is because if you have like [26:02] inline styles or you have a style tag [26:04] somewhere in the middle of the page, um, [26:07] and you have other styles that are [26:09] loaded in the header and you got maybe [26:10] you could even have styles loaded in the [26:12] footer. Who who knows? And and so you [26:14] you're you're fighting an a cascading [26:18] stylesheet inheritance g. So, every [26:22] style that's inserted has the ability to [26:25] modify or uh or inherit styles that are [26:29] added further up in the page [26:32] >> or specifically to override them if the [26:35] specificity is exactly the same. [26:37] >> Right. Right. So, [26:39] >> so the order in which the sales are [26:41] presented is quite important. [26:44] >> Quite important and it's really [26:45] highlighted on websites like that. And [26:48] um [snorts] [26:49] so we kind of reworked it a bit um to [26:53] where we are, you know, we're going [26:55] through and we're we're removing the [26:57] styles and maybe even setting flags to [26:59] where they should be. And then we're [27:01] when it the styles are reenabled, we're [27:04] we're inserting them back to where they [27:06] belong or where they or where they [27:08] started. I'm not sure if that's where [27:10] they belong, but [laughter] [27:13] >> back back to where they were. Yeah. back [27:15] to where they were in the order in which [27:17] they were there. And programmatically, [27:20] when you're doing this, you're doing it [27:21] from top down. And then when you go to [27:23] put them back, you kind of need to [27:25] reverse the order so you don't mess up [27:26] that in inheritance. [27:29] So, um, like William said, simple on its [27:32] face, but like complex in practice. [27:37] >> Yeah. And it's not just complex because [27:39] you have stylesheets to contend with. [27:41] You also have inline styles and you also [27:44] have inline style tags as well and they [27:46] are treated quite differently. um [27:49] particularly in generally in the cascade [27:51] inline styles on a specific element are [27:54] going to have the highest specificity [27:55] the highest priority all the time and if [27:59] you don't restore them back to the [28:00] existing object then that is going to be [28:03] pretty problematic because they will [28:07] instantly lose all of their specific [28:09] which you know is a thing we did see on [28:11] some test sets when we were refactoring [28:13] this is we seen images that had inline [28:15] sizing suddenly grow when you reenable [28:18] the styles. Um quite often we see an [28:20] extra space at the end of pages because [28:23] margin collapse wasn't present. [28:26] >> Yeah. [clears throat] [28:28] So we consider this quite the [28:29] improvement. Um and um we you know we [28:34] we're always trying to improve the the [28:36] product. We're always trying to take the [28:37] feedback we get about the features in [28:39] the plug-in and and make it better. And [28:42] um we consider this uh quite the [28:44] improvement. Um, so in regards to like [28:48] we did some like CPU throttling testing [28:51] of the plugin and [snorts] we were [28:53] messing with these styles. We noticed [28:55] that the styles would reload anytime you [28:58] tried to close the uh accessibility [29:00] checker uh front-end highlighter panel [29:04] and and in most CA in some cases [29:09] it only needs to actually reload those [29:11] when you have styles disabled so that [29:14] your page restores to normal. If your [29:17] styles are not disabled, it doesn't need [29:19] to do that. So, [29:20] >> and it was just whenever you closed it [29:23] doing it by default and as you said we [29:25] were doing CPU throttling and realized [29:27] that low power devices [29:30] well I already knew this but page CSS [29:33] painting on the page is quite a [29:36] expensive process in terms of CPU cycles [29:40] and most of us don't notice it dayto-day [29:41] because or you know we have high power [29:44] computers or whatever but if you're on a [29:46] mobile device for example and you have [29:47] to close that box, you're probably going [29:51] to notice a flicker because it's going [29:53] to take time to repaint every single [29:56] style that was on that page. And if we [29:57] don't need to do it, we just shouldn't. [30:00] And you know, that is now how it works. [30:02] We don't we don't do it if we don't need [30:04] to. [30:05] >> Yeah. And likely the in most cases we [30:09] don't need to do it. [30:10] >> Yes. [30:11] >> So, [30:12] >> exactly. We were absolutely doing it [30:13] [clears throat] in most cases when we [30:14] didn't require it, which is wasteful. [30:17] >> Yep. Now we don't waste those CPU [30:19] cycles. [30:20] >> So we are passing the CPU savings on to [30:23] you the accessibility checker users. [30:26] >> Yep. Save yourself like two cents of [30:28] electricity per month [30:30] >> per Yeah. per lifetime. [30:32] >> Yeah. [laughter] [30:33] It's worth it. Save the planet a little [30:35] bit at a time. [30:36] >> That's right. That's right. Um, and [30:38] plus, you know, it it it hedges against [30:41] if that reenable styles really does have [30:44] a slight issue on on any on a certain [30:48] website, it it hedges against not [30:51] modifying the page. Like, don't mess [30:53] with the page if you don't have to. [30:54] >> Correct. [30:55] >> And uh Cool. So, that was a nice little [30:59] added bonus into uh adding improvements [31:03] to the disabled styles. [31:05] So finally let's move on to uh sorting [31:09] and fasttrack improvements. [31:12] So along with uh generating unique ID uh [31:17] unique objects um we had to make a few [31:21] updates to our um [31:24] uh I'm skipping ahead to the fasttrack [31:26] one here William but the we had to make [31:29] some updates to the fasttrack [31:31] improvements [31:33] uh or to the fasttrack page so that the [31:36] numbers [31:38] uh make more sense When [31:42] it was initially coded, it was coded [31:45] under the assumption that [31:49] there there wouldn't be [31:50] >> one instance per page. [31:52] >> There be one instance of every object [31:54] per page. Whereas now that that [31:57] assumption is incorrect. There could be [31:59] five instances. There could be 99 [32:02] instances of the same code object on the [32:05] page. Um do you have this up? Do you [32:07] want to show this? Yes, I have this up [32:09] on a demo site. So, [32:14] um Oh, maybe I should zoom in cuz this [32:18] code object might be unreadable, right? [32:21] >> Yeah. [32:22] >> Yeah. So, this is our fast track page. [32:25] And as we this specific issue here is an [32:28] empty paragraph and I keep using this as [32:30] a way of testing things because this is [32:33] the smallest markup chunk that I can [32:34] write that creates an issue. Um, but as [32:38] we can see this is on five affected [32:40] pages, one failing check, which the [32:42] check is the empty paragraph tag. But [32:45] when we open the issues panel, it says [32:48] there's 15 instances of this check. [32:51] Previously, this would only be able to [32:52] detect one instance per page. So this [32:55] number would be five for instances and [32:58] five affected pages and the title of [33:01] this column was actually affected pages [33:03] previously. However, now that there can [33:06] be more than one detected markup [33:08] fragment that's the same on a page, this [33:11] has been renamed to be instances and [33:13] there's 15 instances of anti [33:15] paredagramraph across five pages. So now [33:18] this label here used to be pages and now [33:21] it is affected pages. It contains the [33:24] view pages link. If I click on this, it [33:27] opens up a panel which has one, two, [33:30] three, four, five pages and that matches [33:35] the the affected pages here. So if we [33:38] click on any one of these view on page [33:40] links, it will take us to the page and [33:42] highlight the first empty paragraph [33:44] instance. So let's see if I click on [33:47] this one. And here we go. We have a [33:49] bunch of empty paragraphs and this is [33:52] the first instance of it on this page. [33:58] >> Yeah. So previously with previous logic [34:00] this would have showed 15 pages which [34:02] would have been a bit redundant. [34:03] >> Correct. And it would have been five. So [34:05] there's probably this page here probably [34:08] has five on it. This probably has one. [34:11] there would be this link would appear [34:13] five times if there was five instances [34:15] on this page which [34:17] >> you know you don't need all of those [34:18] links [34:20] and it would read out quite nastily to [34:23] screen readers as I discovered. So [34:26] >> yeah. Yeah. So it just it'd be duplicate [34:28] links over and over again and add a bit [34:30] of confusion. So, we've kind of rolled [34:32] those all up and u tried to make this uh [34:37] logically make a little bit more sense [34:39] when we're dealing with uh duplicated uh [34:43] identical issues. [34:46] Cool. So, since you have your screen up, [34:49] do you want to jump over to the open [34:51] issue sorting? [34:54] So in a previous release we released uh [34:58] this more advanced uh sorting when it [35:01] comes to open issues. We sort by [35:03] severity and then and then by account by [35:06] count and um we made the ability to to [35:10] sort these columns. So if you want to [35:12] see what these look like ordered [35:14] differently, you can. And uh we have [35:18] since refined this a bit. Do you want to [35:21] speak to that, William? [35:23] Um yes. So I think the refinements we've [35:27] made is by default you there is now an [35:29] indicator. You can see this is by [35:31] default sorted by severity and severity [35:34] is a two-tier sort as you were just [35:36] saying. [35:37] >> Mhm. [35:37] >> Um previously there wasn't good visual [35:40] indicators. So now there is we can [35:43] change these. [35:45] Um, you also just go back to the the [35:47] default sort. [35:52] >> Yeah. So, that's the default. [35:56] >> Actually, you're you're sorted. Yeah, [35:57] you're sorting by by severity. If you [35:59] want to go back to the default, we have [36:01] a [36:02] >> reset to default sorting because the [36:04] default sorting is is a bit custom, [36:06] right? It's it's two tiered. [36:08] >> Yes, it is. So, I didn't I actually [36:09] didn't notice the count was not sorted [36:11] properly on only sort. So if you sort by [36:15] severity individually by clicking on the [36:18] the top of the table, you can you can [36:20] sort uh you can sort just by severity [36:24] without regards to the count [36:27] and and vice versa. If you want to just [36:29] see what issu issues have the highest [36:31] count, you can just click on count and [36:34] get the lowest or the highest uh count [36:36] of issues to start working on. The [36:39] reason we sort this uh default sorting [36:42] is we're trying to highlight to you [36:45] what's the most critical issue and and [36:48] which one has the most. So, like if [36:50] you're trying to, you know, improve your [36:52] accessibility [36:54] uh coverage or your numbers, you you go [36:57] you click on this top one, which in this [36:58] case is missing form label, and you fix [37:01] these four issues, and you've you fix [37:04] the most severe and the highest number [37:07] of of issues. It's it's kind of like a [37:11] what's my biggest bang for my buck, [37:13] right? Where can I most devote my time? [37:16] But if that's it's mostly for the [37:17] critical issues though is what's the the [37:20] most high severity issue that you can [37:22] solve. If you are looking for most bang [37:24] for your buck as far as raw numbers go, [37:27] you probably are going to want to use [37:29] the the fast track, [37:30] >> right? [37:31] >> Because I could fix this link here, [37:32] which would be 13 pages solved, [37:35] >> right? [37:37] >> And you just have to fix it in one [37:38] place. [37:39] >> Yes. Exactly. [37:40] >> Yeah. Yeah. Well, yeah. Yeah. In that [37:43] instance, one place. Yeah. [37:46] >> So, [37:48] yep. So, those are the improvements in [37:50] the latest releases. Um, we try to put [37:53] out releases every two weeks and we try [37:55] to move fast here and and have a really [37:58] iterative uh development release [38:00] workflow so that we can fix these things [38:02] and we can get these out to you the user [38:05] as quick as possible. Um, so we are [38:11] working on new things as well. Um, we [38:15] can't really tease too much of it, but [38:17] we are currently in a uh a workflow uh [38:22] work cycle of doing some UI improvements [38:25] to help [snorts] u bring accessibility [38:28] checker more in line with uh some modern [38:32] WordPress layouts and uh as you know [38:36] Williams pulled up here our uh current [38:39] metab box. So, a little tease is that we [38:42] are um we're kind of bringing this metab [38:45] box kind of into the WordPress editor in [38:50] a more Hey, don't don't be highlighting [38:52] stuff like don't click on that. [38:55] [laughter] [38:56] >> I can't click on it. It's broken. [38:58] >> Okay. [38:58] >> Haven't I haven't made it work yet. [39:00] >> So, William's teasing here. He's he's uh [39:04] looking at the WordPress editor sidebar [39:06] and there there appears to be something [39:09] in regards to accessibility checker in [39:11] that sidebar that I will not speak of [39:14] here but I just want to let uh our users [39:17] know that um we're doing a lot of UI and [39:21] UX enhancements to try to improve the [39:24] experience and the layout of our metab [39:26] box and we are really excited to get [39:30] this out to you here in uh and an [39:32] upcoming release hopefully not too too [39:35] far from now. So, [39:38] well, that's our episode. Kind of a [39:40] short one this time. Um, but uh some [39:44] important features, you know, having [39:46] unique being able to identify uh items [39:50] uniquely is huge. And being able to [39:52] improve the selector and the accuracy of [39:54] the front-end highlighter we think is [39:57] pretty huge. and uh being able to [40:00] restore those styles without issues is [40:02] seems minor, but it's it's important. [40:06] So, we're always continually improving [40:08] the accessibility checker, and we do [40:11] these live streams twice a month. Um, we [40:14] do it on the first and third, [40:18] >> the second and the fourth. [40:19] >> Second and fourth. That's right. Second [40:21] and fourth. I'm off because of January [40:23] because like January 1st was like on a [40:26] Thursday and that would have been Well, [40:28] I I think technically it's the second [40:30] and the last. [40:31] >> Yeah, the second. [40:32] >> Some months might have five. [40:34] >> Yeah. Yeah. So, we should be on a normal [40:37] uh schedule for February. So, uh look [40:41] for this live stream here in a couple [40:43] weeks and we look forward to joining you [40:45] and and thanks for being with us today. [40:48] See you. ## Highlights - to, to say they're, that they identify an issue, they fix it, and then, then it's, they're presenting with the exact issue. It's not the exact issue, but it'll actually, William: then it looks like the same issue in the back end. Unless they're using the front end entirely. They might not know that it's a different instance. Steve: Yeah, cool. So William: No longer an issue. Steve: No longer an issue. So all of your duplicate uh, uh, identical markup will now be uniquely identified by Accessibility Checker. ([View Highlight](https://read.readwise.io/read/01kjbcbwwdmb5pevbrae4xc2bk)) - Tags: 👻 ai highlighted - So that was kind of the first step in improving that. And then we've taken that and we've done the second step, which is improving the front end highlighter. Uh, In regards to, uh. You know, uh, surfacing unique issues and the stability around having these selectors and the ancestor and, and XPath and improving how um, issues are identified and highlighted on the uh, front end highlighter. ([View Highlight](https://read.readwise.io/read/01kjbcbwxd878v48q3rqc6axbq)) - Tags: 👻 ai highlighted - And um, we wanted to give a more uh, seamless and fluid experience to. Going through the, the front end of your website and, and fixing accessibility issues. So we've decided to order from the top of the DOM down. So your first issue in the dom will be the first one that's highlighted, and then so on down the page. ([View Highlight](https://read.readwise.io/read/01kjbcbwybqz7tsybrg6m75r9b)) - Tags: 👻 ai highlighted - And this helps just bring, bring a, a. Less jumpy experience to tabbing through those. 'cause if issues were identified in the top of the page and then in the bottom of the page it would lit, literally jump down to the bottom of the page and then jump back to the top of the page. So it's, it's just a way of making it more of a seamless experience and, um. in do. In doing that, we switched it to using the selector to identify these, these ([View Highlight](https://read.readwise.io/read/01kjbcbwzazndb932qjdtfc7qc)) - Tags: 👻 ai highlighted - I would say that it is very close to that now at finding issues on the page. William: Yeah. Well, one of the, the benefits of the selector backed discovery is an issue I've previously run into is code on the front end of a website changing what the HTML looks like. Sometimes injects data attributes for image lazy loading or you know, pre prefetch. But a lot of things are added sometimes on the page after it renders. ([View Highlight](https://read.readwise.io/read/01kjbcbx0f51hdg13d347grc6f)) - Tags: 👻 ai highlighted - A more accurate and a, a better uh, visual experience and to work with these new features that we, we introduced. So that brings us to um, some more frontend, highlighter changes we made. So disable style improvement. So we got a little bit of feedback that our disable styles does uh, some funny ([View Highlight](https://read.readwise.io/read/01kjbcbx1ww1a4p751zq326sjc)) - Tags: 👻 ai highlighted - and there's an accessibility issue inside of that, and it, and it says, Hey, we know this issue's not visible on the page. You can toggle off the styles and it, and if you toggle off the styles, then you can see the target and you can see the element in which uh, has the accessibility issue. So you can toggle that. It removes all the styles from the page. You basically get like a old school looking like HTML page. And um, it, you know, if you're. ([View Highlight](https://read.readwise.io/read/01kjbcbx5rttzm6dptpmzzxqzx)) - Tags: 👻 ai highlighted - Um, And, um. we, you know, we we're always trying to improve the, the product. We're always trying to take the feedback we get about the features and the plugin and, and make it better. And um, we consider this uh, quite the improvement. Um, So in regards to like, we did some like CPU throttling testing of the plugin and we were messing with these styles. We noticed that the styles would reload anytime you tried to close the uh, Accessibility Checker front end highlighter panel and in, in most ca in ([View Highlight](https://read.readwise.io/read/01kjbcbx7gxm8k5k09q4g4xnwy)) - Tags: 👻 ai highlighted