Reimagining Accessibility Checker in the Block Editor Sidebar [01kkw275mz5jdzrqakwn9nzzc3]

Reimagining Accessibility Checker in the Block Editor Sidebar 🔗 **Source:** [Reimagining Accessibility Checker in the Block Editor Sidebar](https://www.youtube.com/watch?v=xDybU7hj2Y8&t=1s&rw_yt_language=en-orig) > [!note]+ Document Notes > tags: #wordpress #accessibility #gutenberg #block-editor #ux-design #wcag #plugin-development #semantic-versioning > author: Equalize Digital > source: YouTube > reference: https://www.youtube.com/watch?v=xDybU7hj2Y8&t=1s > date created: 2024-12-19 10:30 > > # 🏷️ Title: Reimagining Accessibility Checker in the Block Editor Sidebar >  ## 🧰 Action Inbox - [H1] Test Accessibility Checker 1.38.0 beta with new block editor sidebar integration — #wordpress #beta-testing - [H2] Evaluate UI/UX changes from metabox to sidebar for accessibility scanning workflows — #ux-design #accessibility - [H3] Consider front-end highlighter compatibility with page builders like Bricks — #page-builders #compatibility ## 🧭 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/gutenberg/) - [WCAG Guidelines](https://www.w3.org/WAI/WCAG21/quickref/) ## 📝 Summary - Equalize Digital demonstrates major UI/UX overhaul of their Accessibility Checker WordPress plugin - New block editor sidebar integration replaces classic metabox approach after 5 years - Key changes include terminology shifts (errors/warnings → problems/needs review), severity-based ordering, and improved visual hierarchy - Four new panels: Accessibility Status, Analysis, Dismissed Issues, and Readability Analysis - Enhanced features include global dismiss, issue modals, WCAG integration, and real-time updates ## 📖 Main Content Equalize Digital's Accessibility Checker plugin is undergoing its most significant redesign since launching five years ago. The team has rebuilt the interface from a classic WordPress metabox into a modern block editor sidebar integration, addressing the evolution of WordPress's editing experience while maintaining backward compatibility. The redesign addresses spatial constraints of the sidebar (approximately 245 pixels width) while improving the user experience through better information hierarchy, modern WordPress components, and enhanced accessibility features. The team conducted extensive design phases and user testing to balance feature completeness with cognitive load reduction. Key architectural changes include separating remediation artifacts from active issues, implementing severity-based ordering, and introducing new terminology that better reflects user workflows. The integration leverages core WordPress components while adding custom accessibility features that weren't available in standard Gutenberg components. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/xDybU7hj2Y8?t=0) — [H1] Introduction and Context - Key idea: Five-year-old plugin getting major UI/UX overhaul for modern WordPress - Evidence: "Accessibility checker has just had its fifth birthday. It's five years old." #### ⏱️ [02:30](https://youtu.be/xDybU7hj2Y8?t=150) — [H1] Block Editor Integration Rationale - Key idea: Moving from wide metabox to narrow sidebar requires complete UX rethinking - Evidence: "We're going from having a very wide space for the metabox to having a very narrow space for the sidebar. You have to make a lot of UI and UX considerations." #### ⏱️ [05:45](https://youtu.be/xDybU7hj2Y8?t=345) — [H2] Technical Implementation Success - Key idea: WordPress block editor components proved surprisingly reusable and accessible - Evidence: "The components that already exist that are used to build Gutenberg itself or the block editor are all available to reuse and they are quite reusable." #### ⏱️ [08:20](https://youtu.be/xDybU7hj2Y8?t=500) — [H1] Accessibility of Block Editor Components - Key idea: Block editor accessibility has improved significantly, enabling accessible plugin development - Evidence: "I actually think I've changed my generalized opinion on whether the block editor is accessible or not. I think they've made an awful lot of progress." #### ⏱️ [12:15](https://youtu.be/xDybU7hj2Y8?t=735) — [H1] Four-Panel Structure Overview - Key idea: Sidebar organized into Status, Analysis, Dismissed Issues, and Readability Analysis panels - Evidence: "We have four panels in the sidebar, and these correlate to our old metabox." #### ⏱️ [15:30](https://youtu.be/xDybU7hj2Y8?t=930) — [H2] Terminology Changes: Problems vs Needs Review - Key idea: Replaced errors/warnings with problems/needs review to clarify actionable vs investigative workflows - Evidence: "We've removed that terminology of errors and warnings and we've replaced it with problems and needs review because that really is the distinction." #### ⏱️ [18:45](https://youtu.be/xDybU7hj2Y8?t=1125) — [H3] Page Builder Compatibility Challenges - Key idea: Current sidebar limited to block/classic editor, but front-end solutions planned - Evidence: "We have future plans to bring all of these new features to a new front end highlighter, moderator, scanner system." #### ⏱️ [22:10](https://youtu.be/xDybU7hj2Y8?t=1330) — [H2] Visual Design Philosophy: Icons, Shapes, and Color - Key idea: Moved from color-only indicators to combined icon, shape, and color system - Evidence: "We're conveying meaning with color icon and shape, not just colors." #### ⏱️ [25:40](https://youtu.be/xDybU7hj2Y8?t=1540) — [H2] Pass Checks Redesign Rationale - Key idea: Demoted pass checks from prominent green circles to informational status - Evidence: "Pass checks just runs a calculation on how many of our rules is this post passing... there could be a whole lot of reasons not to necessarily convey good." #### ⏱️ [30:15](https://youtu.be/xDybU7hj2Y8?t=1815) — [H1] Severity-Based Issue Ordering - Key idea: Critical issues surface first within problem categories for better prioritization - Evidence: "We are now ordering these in critical criticality. So the most critical will be at the top and the least at the bottom." #### ⏱️ [35:20](https://youtu.be/xDybU7hj2Y8?t=2120) — [H2] Code Snippet Removal Trade-offs - Key idea: Removed inline code display due to space constraints, moved to modal view - Evidence: "The code snippet is the thing I was talking about earlier that I thought I was going to miss a lot... It turns out not so much." #### ⏱️ [40:30](https://youtu.be/xDybU7hj2Y8?t=2430) — [H1] New Issue Modal with Enhanced Features - Key idea: Single issue modal provides comprehensive details including WCAG information and syntax highlighting - Evidence: "We've introduced this new issue single issue modal... we show the issue ID at the top... our WCAG information." #### ⏱️ [45:50](https://youtu.be/xDybU7hj2Y8?t=2750) — [H2] Dismiss vs Ignore Terminology - Key idea: Changed "ignore" to "dismiss" with categorized reasons for better workflow clarity - Evidence: "We no longer use the term ignore because we actually are not ignoring an issue. We're dismissing it after careful consideration." #### ⏱️ [50:25](https://youtu.be/xDybU7hj2Y8?t=3025) — [H3] Real-time Updates and Scanning - Key idea: Sidebar updates immediately on issue actions, with manual scan option for content changes - Evidence: "It does update live. So if I go here and I dismiss this... you can see it just updated." ## 📚 References - [Equalize Digital Accessibility Checker](https://equalizedigital.com/accessibility-checker/) - [WordPress Gutenberg Components](https://developer.wordpress.org/block-editor/reference-guides/components/) - [WCAG 2.1 Guidelines](https://www.w3.org/WAI/WCAG21/quickref/) ## 🗣️ Paraphrase - Equalize Digital redesigned their 5-year-old Accessibility Checker plugin to work natively in WordPress's block editor sidebar instead of the traditional metabox - The narrow sidebar space (245 pixels) required complete rethinking of information hierarchy, visual design, and user workflows - Major terminology changes include replacing "errors/warnings" with "problems/needs review" and "ignore" with "dismiss" to better reflect user actions and decision-making processes ## 📰 Newsletter The Accessibility Checker plugin is getting a major makeover! After five years of serving the WordPress community through a classic metabox interface, Equalize Digital has rebuilt their popular accessibility scanning tool for the modern block editor. The new sidebar integration puts accessibility insights right alongside your content editing workflow. Key improvements include severity-based issue prioritization, enhanced WCAG documentation integration, and a cleaner visual hierarchy using icons, shapes, and color together. This update demonstrates how mature plugins can evolve with WordPress's changing landscape while maintaining the robust functionality users depend on. The team's focus on reducing cognitive load while improving information access sets a strong example for plugin UX design. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer experience: Create migration guides for UI/UX changes, document new component usage patterns - Developer marketing: Showcase block editor integration best practices, highlight accessibility-first design approach - Community management: Gather feedback from beta users, moderate accessibility-focused discussions #### WordPress - Core: Evaluate accessibility improvements in block editor components, contribute findings back to Gutenberg - Design: Document successful narrow-space UI patterns, share color/shape/icon accessibility principles - Accessibility: Review plugin's WCAG integration approach, consider standardizing accessibility metadata APIs - Plugins: Examine block editor migration patterns, document sidebar development best practices #### Community - Maintainers: Share lessons learned from major UI overhauls, provide sidebar integration templates - Contributors: Contribute accessibility testing feedback, help refine developer experience documentation ## 🧪 Hypotheses - Users will adapt more quickly to terminology changes (problems/needs review vs errors/warnings) when the workflow separation is clear - Sidebar integration will increase accessibility checking frequency due to reduced context switching - Severity-based ordering will improve remediation efficiency compared to rule-based grouping - Icon/shape/color combination will provide better accessibility than color-only indicators ### 📊 Methodology - A/B testing between old metabox and new sidebar for task completion times and user satisfaction - User interviews comparing workflow efficiency before and after terminology changes - Analytics tracking on dismiss categorization usage patterns and global dismiss adoption - Accessibility testing of the plugin interface itself using screen readers and keyboard navigation ### ❓ Questions - How will the 245-pixel width constraint affect future feature additions to the sidebar? - Can the WCAG information integration model be standardized across WordPress accessibility tools? - What impact will the UI overhaul have on existing power users' established workflows? ### 🔮 Future Research - Investigate standardized accessibility metadata APIs for WordPress plugins - Explore cross-plugin compatibility patterns for block editor sidebar integrations - Study the effectiveness of severity-based vs rule-based issue organization in accessibility tools ### 💡 Implications - Practice: Major plugin UI overhauls require extensive user testing and gradual terminology transitions - Policy: WordPress plugin guidelines should include block editor integration recommendations - Education: Plugin developers need resources for accessible component usage in narrow-space interfaces - Funding: Mature plugins benefit from periodic UX investment to stay current with platform evolution ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical plugin development content) #### 👀 Visual learners - Present: Extensive sidebar screenshots, UI component demonstrations, before/after comparisons - Improve: Flow diagrams showing user workflow changes, component hierarchy visuals #### 🔊 Aural learners - Present: Live demonstration with detailed narration of UI interactions - Improve: Audio-only summary of key terminology changes and workflow benefits #### 🗣️ Verbal learners - Present: Clear terminology explanations, analogies comparing old vs new approaches - Improve: Glossary of old vs new terms, story-driven examples of user scenarios #### 🧩 Kinesthetic learners - Present: Live plugin demonstration, interactive sidebar exploration - Improve: Beta testing checklist, hands-on migration guide #### 🧠 Logical learners - Present: Technical implementation details, component decision rationale - Improve: Decision tree for UI component selection, performance metrics comparison #### 🧑‍🤝‍🧑 Social learners - Present: Team discussion of design decisions, community feedback integration - Improve: Beta user feedback compilation, developer community discussion prompts #### 🧘‍♀️ Solitary learners - Present: Self-guided plugin exploration, individual testing scenarios - Improve: Personal reflection prompts on workflow changes, self-assessment checklist #### 🌿 Naturalistic learners - Present: Plugin evolution over time, adaptation to WordPress ecosystem changes - Improve: Ecosystem impact analysis, sustainability of design decisions ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Proper heading hierarchy, landmark usage, comprehensive alt text on UI demonstrations - Improve: More detailed descriptions of visual layout changes, component relationship explanations #### Keyboard navigation - Present: Discussion of keyboard support in WordPress components, tab order considerations - Improve: Explicit keyboard navigation testing results, focus management examples #### Contrast and readability - Present: Discussion of moving away from color-only indicators - Improve: Specific contrast ratios for new icon/shape/color system #### Media and captions - Present: Live stream with real-time audio description of UI interactions - Improve: Downloadable transcript, chapter markers for key sections #### Forms and interactions - Present: Modal form design discussion, dismiss categorization UI - Improve: Error state handling examples, validation feedback patterns ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focus on making accessibility tools accessible regardless of technical background - Improve: Examples from diverse WordPress user contexts, international plugin usage patterns #### Inclusive language - Present: Thoughtful terminology changes from "ignore" to "dismiss", "errors" to "problems" - Improve: Plain language summaries of technical concepts, jargon definitions #### Neurodiversity support - Present: Discussion of cognitive load reduction, information hierarchy improvements - Improve: Specific examples of how changes support different cognitive processing styles #### Representation - Present: Team with diverse skill sets contributing to design decisions - Improve: More diverse user testing feedback, varied use case examples ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear logical progression from space constraints to UI decisions - Inductive strength: Good use of user feedback patterns to inform design changes - Causal reasoning: Well-established connections between terminology confusion and workflow problems - Analogical strength: Effective comparison between old and new interface approaches #### Fallacies - Appeal to novelty: Minor tendency to present new features as inherently better without full evaluation - False dilemma: Occasionally presents choices as binary when multiple solutions might exist #### Tone of voice - Overall tone: Professional and thoughtful, with good balance of technical detail and user-focused explanations ### 🛡️ DARVO Analysis - Deny: No problematic denial patterns observed - Attack: No attacks on users or critics present - Reverse victim/offender: No victim/offender reversals noted - Emotional cues: Positive, collaborative tone focused on improvement and user experience ## 🎯 Conclusion Equalize Digital's Accessibility Checker sidebar integration represents a thoughtful approach to plugin evolution, balancing modern WordPress integration with user workflow needs. The emphasis on terminology clarity, visual hierarchy, --- ## Full Transcript [00:02] All right, I think we are live. [00:06] >> Looks like it. [00:08] >> We checking the stream. [00:12] >> Yep. Checking on YouTube. [00:14] It is going. [00:18] I'm presuming everything else is fine. [00:21] >> Yep, probably is. [00:24] >> Cool. So, how's it going, William? You [00:26] doing good? [00:27] >> Yeah, doing all right. Can't complain. [00:29] It's been a little bit. We [00:32] >> It has [00:33] >> We missed the uh [00:36] the last one, the one that we normally [00:38] have at the beginning of the month, but [00:40] that's for good reason, right? [00:43] >> Yeah. It's because we didn't do any work [00:45] that month. [00:46] >> That's right. No work at all. Just [00:51] >> just a bunch of slackers. Not coding. [00:54] No. [00:54] >> Signed in chat a bit. [00:56] >> That's right. [00:57] >> Left. [00:59] No, we're being uh facitious. [01:01] We've actually been working very hard on [01:04] some new stuff and some stuff that just [01:07] needed that extra couple weeks of work. [01:10] So, we're give it a little bit of time, [01:12] see if anybody joins us. If not, we're [01:15] just push forward and and talk about new [01:19] stuff. [01:21] So, um this is the accessibility checker [01:26] change log live stream where we talk [01:28] about uh the WordPress plugin, the [01:31] accessibility checker, which is an [01:34] automated accessibility scanning plugin [01:36] to help your WordPress website become [01:39] and stay accessible. We have a free uh [01:44] fullfeatured plug-in [01:46] uh called accessibility checker. We have [01:49] a pro version that you can get to that [01:51] extends upon that and adds uh lots of [01:55] prolevel premium features and and we [01:58] also have uh three add-ons to our pro [02:02] plugin that you can get at different [02:04] subscription levels. We have an audit [02:06] history plugin to track your [02:08] accessibility uh compliance over time. [02:11] We have a multi-sight add-on that allows [02:12] you to manage your license and stats and [02:16] activations across a multi-sight [02:18] network. And we have an export add-on [02:21] that allows you to export your [02:23] accessibility uh scan data to a CSV [02:27] file. So you could import that into your [02:30] system of choice. So [02:33] today's theme, William, is re-imagining [02:38] accessibility checker in the block [02:40] editor sidebar. [02:43] >> Yeah. So we did not have any sidebar [02:46] integration. We effectively didn't [02:48] really have any block editor [02:51] integration, any deep integration for a [02:53] long time. So now that changes and we [02:58] went all in. [02:59] >> Yeah, we went all in. So, [03:02] so for those that don't know, [03:04] accessibility checker is is is quite old [03:08] or as my teenage children would say, uh, [03:12] unc. [03:16] And with him shaking his head at me. [03:18] Can't believe this. [03:19] >> I know what that means. [03:21] >> Just means old. Uh, so accessibility [03:24] checker has just had its fifth birthday. [03:26] It's five years old. And five years ago, [03:29] the the block editor was not quite where [03:33] it is today. And um we used a classic [03:37] metab box. If you're a current user of [03:39] the uh plugin, you are very familiar [03:42] with our our metab box that you use to [03:46] uh check your status and and see how [03:49] many issues you have and and to manage [03:51] your readability. [03:53] So, what our goal here for the new year [03:56] is to go through uh the plugin and kind [04:00] of do some UI and UX overhaul. Since [04:03] it's been five years, it's time to give [04:05] the plug-in a little bit of a refresh, a [04:08] little bit more of a visual um um modern [04:11] visual look, and to help integrate it [04:14] more deeply into the WordPress admin to [04:17] make it feel like it works more [04:19] seamlessly with the block editor and at [04:23] the same time maintaining backward [04:25] support for post types or websites that [04:28] don't support the block editor. So what [04:31] we've done is we took the the current [04:34] classic metab box and just rethought it. [04:37] How how if we're rebuilding this in the [04:40] sidebar of the block editor, [04:43] how can we rethink this? And if if [04:45] you've used the block editor and you [04:47] know the sidebar is a very [04:50] it's a not a very wide space. So, we're [04:53] going from having a a a very wide space [04:56] for the the metab box to having a very [05:00] narrow space for the sidebar. And when [05:04] that happens, you have to make a lot of [05:06] UI and UX considerations. And you have [05:08] to really think deeply about the [05:11] information you're trying to service and [05:14] very deeply about uh what all you put in [05:17] there because like it can you know you [05:19] can't put big blocks of text because [05:21] they wrap and and it [05:23] >> it look it looks bad. [05:24] >> Effectively you have 265 [05:26] pixels [05:29] which doesn't account for padding. So [05:32] you got to pad that out a little bit as [05:34] well. You may get to 40 pixels worth of [05:37] usable space. It's It's nothing. [05:40] >> Yeah, [05:40] >> you can fit a button side by side and [05:41] that's about it. [05:42] >> That's right. Even your text labels have [05:45] to have some consideration, right? [05:47] >> Yep. [05:48] So, um, but the but the big benefit of [05:51] the block editor sidebar is is it [05:53] surfaces the accessibility checker one [05:56] at the top of the page inside of the [05:59] toolbar [06:01] alongside the other sidebars that other [06:03] plugins may add or or the default [06:06] sidebars that are there and it services [06:09] it beside your content. So, no longer [06:11] are you looking at your content [06:13] scrolling down to the metab box. Okay, [06:15] what is this? Trying to find that issue [06:18] in your editor and you know this just [06:21] back and forth. What? It push it to the [06:23] side. Your contents on the left, your [06:26] sidebar on the right. I I think you can [06:27] move these sidebars, can't you? [06:29] >> To the right and left. [06:30] >> I think you can swap them to the other [06:32] side. I have never had any reason to [06:34] move it to the other side. I believe you [06:36] can. [06:37] >> But it it puts it in one p one pane in [06:40] in two columns. you now have a visual of [06:43] your content and the accessibility [06:45] checker at the same time. So, um there's [06:50] a lot to talk about in regards to what [06:52] we did, but I think we should pull it up [06:54] and we should start going through it and [06:56] just kind of kind of start talking about [06:58] some of the changes that we made because [07:01] there are a lot of terminology changes. [07:04] We we had a lot of internal discussion [07:05] if we should build a glossery since [07:07] terminology is being reconsidered so [07:09] much and and trying to unify terminology [07:12] throughout all of our our products. Um [07:16] but let me pull it up and we're we'll [07:18] just walk through it piece by piece. [07:21] Cool. [07:24] So this is just a normal uh post in the [07:28] WordPress admin. And you now say you can [07:32] now see that we have a little icon up [07:35] here in the top toolbar in the right. [07:39] And uh if you use like uh the Yoast [07:41] plugin, you can you have Yoast has their [07:44] sidebar here. So now we have ours. But [07:47] we wanted to make sure that you know [07:49] since we're moving this and creating new [07:51] functionality that that you didn't [07:52] overlook it. So we've added a metab box [07:54] down below [07:57] uh in the post sidebar [08:00] uh for accessibility checker says you [08:02] have 12 problems to address and 16 [08:04] issues that need to be reviewed with a [08:06] button that will initiate that sidebar. [08:10] So that's just us kind of helping you if [08:12] you're in this default view that hey [08:14] accessibility checker is running there [08:16] are issues and this kind of just helps [08:19] bridge the gap between the old metab box [08:21] and the new sidebar. So I'll go ahead [08:24] and click on the sidebar icon to pull it [08:27] up. So we are presented with the default [08:32] view here. Is this large enough? [08:34] William, should I try to [08:36] >> If you could zoom in, I think that might [08:37] be quite good. Yeah, that that looks [08:41] better. It is. You don't realize how [08:45] small it is until you have to start [08:46] shining. [08:47] >> Yeah. Yeah. So, since since it's since [08:49] uh [08:51] since the sidebar is quite small, I will [08:54] show it at a zoomed in uh view here so [08:58] we can look at it in the screen share [09:00] together easily. [09:02] So, [09:04] so William, before I talk through some [09:07] of this stuff, uh, were there huge [09:11] technical challenges in in getting here? [09:14] >> Um, so surprisingly, [09:17] the components that already exist that [09:19] are used to build Gutenberg itself or [09:22] the block editor are all available to [09:24] reuse and they are quite reusable. A lot [09:26] of this is [09:29] core UI components. It will look very [09:32] familiar to people. You will recognize [09:34] the panels. These are the same panels [09:36] that exist in style edits. For example, [09:39] if you have a block open to edit, these [09:42] are the same panels. So, as far as [09:44] technical hurdles go, [09:46] easier than expected. Not simple, but [09:49] not complicated either. [09:51] >> Yeah. So, we're able to like uh take [09:55] accessibility checker data and kind of [09:58] take uh WordPress core block editor [10:02] components and kind of utilize those and [10:06] and build out this sidebar. And those [10:09] sure there's a custom there's a a few [10:11] custom element uh components that we've [10:14] added here, but it's just a much more [10:16] mature application way of building it. [10:19] And um we were pleased to find that in [10:23] using those components that we did have [10:26] um what are called properties props [10:28] inside these components that actually do [10:30] allow us to achieve the level of [10:34] accessibility uh that we're trying to [10:36] achieve here. Um it it can be discussed [10:40] a little bit in the Gutenberg [10:43] block editor, [10:45] you know, that it's completely [10:47] inaccessible or it's not usable. But uh [10:49] we've seen a lot of maturity in regards [10:51] to accessibility inside the block [10:54] editor. And we were actually kind of [10:56] pleased to find ourselves uh that these [10:59] components uh maybe not out of the box [11:02] were set exactly the way we wanted them [11:03] set for uh accessibility, but the the [11:07] props were there for us to achieve the [11:10] level of accessibility with our own [11:12] plug-in that we're trying to achieve. [11:16] >> Yeah, I actually think I've changed my [11:19] generalized opinion on whether the block [11:21] editor is accessible or not. I think [11:23] they've made an awful lot of progress [11:26] since the last time I had evaluated [11:30] >> this. Like a huge amount of progress. [11:33] >> Yeah, I I would agree. And I think that [11:36] may be a little bit of our delay to move [11:39] accessibility checker into the the the [11:42] block editor [11:44] uh for for those reasons and and maybe [11:46] some of our own misconceptions as well [11:48] why we delayed on that because what we [11:51] try to do with accessibility checker is [11:53] it's a plugin that is used to scan your [11:56] website for accessibility problems. But [11:58] we also try to practice what we preach [12:01] and we try to make our plug-in [12:03] accessible itself because we want if you [12:06] know regardless of somebody's ability if [12:09] they if they want to make their website [12:11] accessible we want our tool to be [12:13] accessible to check the accessibility of [12:15] their website. So um so we were pleased [12:18] to find that uh we were able to achieve [12:22] a good level of accessibility while [12:25] moving into the block editor. Um, [12:28] >> yeah, labels were readily available to [12:31] you to add. Keyboard navigation was [12:34] surprisingly high level on the majority [12:38] of the components we needed them to be [12:41] on. [12:42] >> Mhm. [12:42] >> Um, tabs for example, which we will see [12:45] shortly, I was incredibly surprised had [12:47] full keyboard support, [12:48] >> right? [12:49] >> So, and implemented properly. [12:52] >> Yeah. With arrow keys. Yes. Yes. [12:54] >> Yep. [12:55] >> Yeah. Cool. So, let's take a look. We [12:59] have mult uh I'm going to close this [13:01] one. We have four panels in the sidebar, [13:04] and these correlate to our old metab [13:06] box. Um, but you'll notice that the [13:09] terminologyy's changed a little bit. So, [13:11] we used to have the summary tab in the [13:14] metab box, which is now the [13:15] accessibility status [13:18] uh accordion here. And we used to have [13:22] the details panel which is now the [13:24] accessibility analysis panel. [13:27] And uh we you in the metab box and we're [13:32] going to talk about the metab box here [13:33] in a little bit too because it it has [13:36] been brought up to date and we're trying [13:38] to keep things in par with the sidebar [13:42] as much as we can. Um we actually uh in [13:46] the details the previous details panel [13:49] uh what we used to call ignored items uh [13:54] were they're they're filtered in with [13:56] the other issues. So what we've done is [13:58] we've actually separated them out now in [14:01] the sidebar. [14:02] So, so we now have a panel called [14:04] dismissed issues and and the the [14:07] reasoning [14:09] for moving those out and surfacing them [14:12] into their own panel is we're trying to [14:14] create separation between [14:17] um what needs to be actioned on and what [14:21] are artifacts of remediation. [14:24] So we want before we were kind of [14:27] collating those things and and now we [14:30] want to separate those out u to create [14:33] greater separation on what you've done [14:35] and what you need to do. [14:38] And then finally we have a fourth panel [14:41] called the readability analysis which [14:45] was called readability before. [14:48] >> It was just called readability. Correct. [14:50] >> Yes. [14:51] So let's let's dive into each panel [14:53] individually. [14:55] So William, you want to talk about the [14:57] accessibility status panel? [15:00] >> Um, sure. So the accessibility status [15:03] panel is very much the same as what you [15:06] would see in the [15:09] existing or the previous metbox. It has [15:12] all the surface level information that [15:14] you might need to make a decision about [15:17] what you're going to focus on while [15:20] editing this page. So in this example [15:23] here, we have 12 problems and 16 items [15:26] that needs review. You know, [15:29] immediately, you know, arguably problems [15:32] are bad, but things that you need to [15:34] review might actually be worse because [15:36] we don't know if they're problems. Um, [15:39] but one major difference here is we no [15:42] longer break out contrast headers. [15:46] Previously, we would break contrast [15:47] headers out and have eders as two [15:49] separate groups. Contrast eders are [15:52] eders and all eders are problems. Um, [15:55] contrast eders now are included in the [15:58] problems count. They are they are the [16:00] same. They they need they need to be [16:02] dealt with. So, [16:04] >> they're a single group. Um the other big [16:06] change here is that the the number pass [16:09] checks used to be named pass tests and [16:12] it used to be the largest object on in [16:16] the metab box. After some consideration, [16:19] we decided maybe it isn't the most [16:21] important aspect of the data here and as [16:24] such it has a similar weight as as all [16:26] of the other items. [16:28] >> Yeah. [16:31] Yeah. So I mean to tag on that a little [16:33] bit the the ordering has been moved [16:36] around too. So so William said said that [16:38] like we had problems and then we had [16:40] contrast issues. And I think our [16:41] original thought around separating those [16:43] out as two individual u issues is [16:47] because color contrast can be a lot of [16:50] times with themes and WordPress themes [16:52] one of the biggest things to focus on. [16:54] But um as far as like giving weight to [16:57] things they really have the same weight. [16:58] So we've just decided to collect those [17:00] into into one one uh data point and um [17:07] so those are now called problems. So [17:09] we're we're no longer calling them [17:11] errors because what we've introduced is [17:14] we'll talk about here in a little bit is [17:15] severity. So if we if we're calling issu [17:19] if we're calling things errors and [17:21] warnings and then we have a severity [17:24] like if a warning has a critical [17:26] severity and an error an error has a low [17:30] severity like which which one takes [17:32] priority. So what we've done is we've um [17:35] we've removed that terminology of errors [17:37] and warnings and we've replaced it with [17:39] problems and needs review because that [17:42] really is the distinction. [17:44] Previously an error before was something [17:46] that we could programmatically with with [17:49] good accurate with very good accuracy [17:52] tell that this is an issue and need to [17:55] review is something that [17:57] programmatically we we couldn't with [17:59] 100% or 99.9% [18:02] accuracy [18:03] um tell you that this is an issue. It [18:06] actually required a little bit of uh [18:08] human review and you know alt text is a [18:11] perfect example of of something that [18:13] gets flagged as needs review because [18:15] there could be a ca there could be a [18:17] very valid case for not adding [18:20] alt text to a decorative image. So we [18:23] have a question here. Let me pull this [18:25] up [18:28] um [18:30] from from Daniel. Is there any chance [18:32] for this to eventually roll out to other [18:35] editors, [18:37] i.e. Bricks Builder? [18:40] Um, so [18:43] what I like I stated earlier, we're [18:46] looking down the road to major UI and UX [18:49] overhaul of the accessibility checker [18:52] this year. This is the first step. Um, [18:56] there the there is a step coming up. I [18:58] don't know if it's next or if it's the [19:00] one after the next one to um make new [19:04] considerations for how accessibility [19:07] checker is shown on the front. We [19:08] currently have our front-end highlighter [19:11] that was made uh several years ago and [19:13] we are looking at a a fe a future new [19:16] tool to um uh expose and manage [19:21] accessibility issues on the front end in [19:24] in a in a much better way. Um I have not [19:28] used bricks builder but um [19:32] I would imagine that [19:36] does is it a I'm not sure if it's a back [19:38] end or a front end builder. [19:39] >> So bricks is a front endish type of [19:42] builder. So we will not be able to [19:44] deploy this exact permutation of this [19:47] sidebar on bricks. If you want to use [19:51] this sidebar, you will need to use the [19:54] classic editor or the block editor. Um, [19:58] however, as Steve was saying, we have [20:00] future plans to bring all of these new [20:02] features, which you know, we maybe [20:04] haven't yet spoke about, but we will be [20:06] bringing all those features to a new [20:09] front end [20:11] highlighter, [20:12] moderator, [20:14] scanner system. [20:17] >> Yeah. So, does do you know, William, if [20:19] the front-end highlighter works with [20:21] bricks? [20:22] >> So, when I looked at this with Daniel [20:24] previously, so hi Daniel. Um, it it [20:28] works [20:29] okay for highlighting issues, but the [20:31] rescan doesn't work so well with bricks [20:34] because of its overlayesque. [20:37] >> No. Okay. [20:38] >> system. So it would be able to detect [20:41] issues, but it also detects [20:45] bricks overlay as well. So it doesn't it [20:49] doesn't work that as well as it does on [20:51] just a markup base page, [20:54] >> right? Yeah, totally. There there are [20:56] challenges with page builders and we [20:58] know that like our front-end highlighter [20:59] works quite well with Elementor. [21:02] um doesn't seem to conflict with [21:04] Elementor's panels a whole bunch. And um [21:08] we're we're working, you know, we're [21:10] working with Kevin over at Etch to make [21:13] sure that our front-end highlighter is [21:15] working uh with Etch and we we got we've [21:19] got some uh updates coming in regards to [21:22] that. Uh so yeah, so we're looking what [21:27] this future thing that we haven't really [21:29] scoped out a whole bunch and we haven't [21:32] really talked about a lot publicly. We [21:34] are looking for a solution that that [21:37] solves the front-end exposure of issues [21:42] um for you know for anything regardless [21:45] of what page builder or what platform [21:47] it's running and maybe even if it's not [21:50] running WordPress. [21:52] So, um, so thanks for your question, [21:57] Daniel. Daniel's got a followup. [22:06] Yeah. Yeah. Yeah. This is a great point. [22:08] I'm gonna I'm gonna pull this up. [22:10] So Daniel said, "I asked about uh Bricks [22:13] not only because I use it because its [22:17] user base tends to care about [22:19] accessibility more than the users of [22:22] some other builders." You know, that's a [22:23] great point, uh, Daniel, and we should [22:27] definitely, uh, pull up bricks, William. [22:30] We should put a put that on our list to [22:32] do some testing on to make sure that our [22:34] front-end highlighter is compatible and [22:37] that we can help that community and [22:39] support that community in making their [22:41] websites accessible. [22:42] >> Yeah, for sure. Actually, as I said, I [22:44] have spoken with Daniel before and [22:46] maybe, you know, maybe we could actually [22:48] sync up again and find out more from an [22:51] actual user what the needs are. So, I [22:54] might email you back on that thread, [22:56] Daniel, and we can connect and figure [22:59] out the best way to make sure BRIX is [23:01] supported fully. [23:03] >> Yeah. Awesome. Cool. Sounds great. [23:07] Cool. So, back to the uh the status [23:09] here. Um, so [23:13] that's I was kind of explaining like the [23:15] the difference between errors and [23:16] warnings. They're now problems and needs [23:18] review. And we're going to talk a little [23:21] bit more about severity in a little bit. [23:23] If you use our pro plugin, you kind of [23:24] know about our severity flags that we [23:26] added a few versions back. Um, but we'll [23:30] talk about that here in a minute. And [23:32] then, yeah, so reading level, not much [23:34] has changed in regards to reading level [23:36] here. The way we display it there. I'm [23:39] going to talk about the icons here in a [23:40] minute, William, because that's really [23:42] important. [23:42] >> Yep. and and then like William said, [23:44] past checks has been [23:47] um kind of brought down in priority. It [23:50] doesn't have a big circle. Now, we have [23:52] maintained this in the the metab box and [23:53] we'll talk about that when we get to the [23:55] metab box and I'll tell you why we're [23:57] maintaining the previous kind of layout [23:59] for that. But uh pass checks has been [24:02] brought down in priority and we had a [24:04] lot of internal discussion about this [24:06] because [24:08] pass checks just it it just runs a [24:10] calculation on how many of our rules [24:13] um is this post passing and then it [24:18] gives you a percentage of past. And [24:21] previously it used color to indicate [24:23] good when there could be a whole lot of [24:26] reasons not to necessarily uh convey [24:29] good. Um because there's issues when [24:32] you're scanning a page to where if a [24:34] rule doesn't apply to that page, you're [24:38] you're still getting credit for that [24:40] rule passing. [24:41] >> Yeah. And I do want to call that out [24:43] actually specifically. So in we did [24:46] change this. It used to be called pass [24:48] tests and we have changed it to pass [24:50] checks but we had a lot of back and [24:52] forth about even the term on this [24:54] because the this is 81% are not [24:58] applicable to this content. It doesn't [25:00] mean they're passed really it means that [25:04] they have not failed [25:06] >> and there there is a big difference [25:07] there. I think arguably a more important [25:10] metric is [25:13] 19% of the checks did not pass here. [25:16] Right. [25:17] >> And you know, maybe in the future we'll [25:19] offer a toggle to flip this number [25:22] around for person like [25:25] >> for personal [25:28] whichever one someone might want. I [25:29] actually would prefer this to be [25:30] inverted. [25:31] >> Yeah. Yeah. Totally. I I I do too. And [25:35] and what that does is it kind of [25:36] obscures away whether or not the rule [25:39] passed because an issue existed on the [25:42] page and it was was accessible. was done [25:44] right or it didn't exist on the page and [25:46] the rule didn't apply. Um so so if you [25:52] inverse it and you focus on only what [25:54] failed, you're only looking at, you [25:56] know, where you need to improve. And [25:58] yeah, we really went back and forth [26:00] about this. Uh like I I was calling it [26:02] coverage in an early iteration of this [26:05] and and I will like side I will tag on [26:09] here. Uh we did kind of go through a [26:12] full design phase on this which we don't [26:14] do a lot uh and we haven't done a lot in [26:16] a while but um and a lot of people may [26:20] not not know this. I'm not just the CTO [26:22] of Equalized Digital. I'm not just a [26:24] developer but I actually went to college [26:27] to be a designer. So, I have these all [26:30] these weird [26:32] weird skill sets that uh kind of work [26:35] together and really I don't really flex [26:37] the design stuff much anymore, but uh as [26:41] of building this I did and and really [26:44] brought in in that convergence between [26:47] the design and the development into how [26:50] we can present a a much better uh uh [26:54] visual UI and a much better user [26:57] experience because what We're trying to [26:59] do an accessibility checker. We're not [27:00] just trying to make something pretty and [27:02] and something eye-catching. We're trying [27:05] to surface data and expose it to you to [27:08] get you to take take action and and and [27:12] to not give confusion to you or [27:15] cognitive overload as well because like [27:18] accessibility at first can be like, oh, [27:20] I got I got 12 problems or I got 16 [27:23] needs review. I don't know what to do. [27:25] Um, so, so we're trying to surface this [27:28] stuff. Say, hey, you need to take [27:29] action, but here's the most important [27:31] thing to take action on, right? And, and [27:34] not overloads. So, [27:38] I want to talk about the icons a little [27:40] bit. So, before we were kind of using [27:42] these big washes of blocks of color uh, [27:45] to convey whether or not something was [27:48] good or bad, right? Green or red, right? [27:52] um we've taken a step back and we've [27:54] kind of changed how we're using color, [27:57] how we're using shape and and and [28:01] how we're using icons to convey meaning. [28:05] Uh so we've removed those big deep uh [28:10] colors and and we've opted for icons to [28:16] to handle that. So [28:20] before uh so like accessibility status. [28:24] So right now you can see I have 12 [28:26] problems. If you look at the the top [28:29] accordion here so at the top level we're [28:32] surfacing whether or not you need to [28:34] open this accordion. If everything was [28:36] passed [28:38] this would be this would be a green box [28:40] with a check in it. So we we have for [28:43] something that needs attention we have a [28:46] circle the the uh is that information [28:51] icon is that what or alert icon [28:54] >> it's the exclamation mark [28:56] >> exclamation thanks so we have like a red [29:00] circle with an explanation and then if [29:02] it's something that is a little less [29:04] critical than that [29:06] we have a triangle with an explanation [29:10] in it. So the explanation on both of [29:12] those signifies that at some level [29:15] they're the same, but the triangle and [29:19] it being orange signifies that it's a [29:22] little less it's slightly less of a of a [29:27] huge concern. [29:29] And then and then we have a square [29:33] checkbox that's green if something's [29:36] good. So we're can we're conveying [29:38] meaning with with with color icon and [29:42] shape [29:43] um not just colors. [29:45] >> Yeah. The the shape indicator here meant [29:50] made an awful lot of difference for me [29:52] actually. I didn't realize previously [29:55] how if everything was a circle then [29:56] nothing was [29:58] a notice bubble [30:00] >> as such. Now we we do have the shapes [30:02] and it so everything is signified by [30:05] color and shape and in some cases also [30:08] the icon that's inside of the shape but [30:12] we are no longer just using color or [30:14] just using an icon. It's always both. [30:18] >> Yeah. Yeah. Yeah. [30:21] So yeah we have Troy joining us and uh [30:25] >> Hey Troy. [30:26] >> Hey Troy. How's it going? Uh said Troy [30:29] said, "You guys did one heck of a great [30:31] job fitting a lot of important data into [30:34] a small space. Very clean. Uh fits into [30:37] the overall look of core as well." Yeah, [30:39] thanks Troy. And and and I do want to [30:43] >> It was not easy. And and you know we [30:47] went through many rounds of reduction [30:49] and even from design what we ended up [30:52] with in design over to code we we still [30:55] have pulled pulled things out and we [31:00] have to keep asking ourselves does [31:02] removing this actually you know convey [31:06] less meaning or or does this act it [31:08] actually cause the user to have a worse [31:11] experience by removing it. If not, we [31:13] should just remove it, move on. We can [31:15] explain these things in documentation in [31:18] other places. And uh and it just it it's [31:23] it's hard. It's hard too for a mature [31:25] plugin that's been around for 5 years. [31:27] Uh for somebody, you know, and we use [31:29] our plugin in our own remediations. And [31:31] when you're used to where things are, [31:33] what things are called, and and when you [31:36] start pulling things out, people on the [31:38] team can start to be like, "Oh, well, [31:39] where'd this go? Why why isn't this [31:41] here?" And [31:42] >> yeah, but we are about to come up to [31:44] something that I was very much against [31:46] removing until I realized [31:49] I didn't actually use it. I just liked [31:52] it to be there. [31:53] >> Yeah. I don't know what that is, but [31:55] >> I'll point it out when we get there. [31:57] >> Okay. So, to finish up on the status [32:00] panel, I I want to talk about the pass [32:03] check icon a little bit. So the pass [32:05] check icon, you'll notice before in the [32:08] metab box the p the pass check would be [32:10] green and it was almost always like if [32:12] it was 81% it was green. If it was 10% [32:15] it was green. Almost always saying good [32:18] job, good job. Especially if those [32:20] didn't if those those checks didn't [32:22] apply then you're getting green and a [32:24] thumb, you know, like a good a job well [32:26] done, a pat on the back for something [32:27] you didn't do. [32:30] And uh so with some of the ambiguity [32:34] around what pass checks is trying to [32:37] convey, we've change the icon to [32:40] anformational icon. And uh [32:45] and and and [32:48] that is to to say, hey, this [32:49] isformational. you should look at this [32:52] and and pay attention to it, but we're [32:54] not going to make uh any kind of [32:57] assumption on whether or not this is [32:59] green good or red bad. So, well, looks [33:04] like our fearless CEO has joined the [33:06] party. Welcome to the party, Amber. Glad [33:08] to have you. [33:09] >> Yeah, I think the information icon is [33:11] just also a signifier of this is [33:13] supplementary. This does not really [33:16] impact your decision. Yeah, [33:19] >> but this is here when you need it. So [33:21] you'll see that is on the past checks, [33:23] but you'll also notice that it is on [33:24] dismissed issues as well, [33:26] >> right? [33:27] >> We will explain when we get to dismiss [33:29] issues why we think they're [33:31] onlyformational, [33:32] >> right? Cool. So, a feature added to the [33:36] stat the accessibility status [33:38] previously, the summary is is and oddly [33:43] enough, this is something that's been [33:44] requested from many people that have [33:46] used the plugin is in the summary, the [33:48] old summary tab, they they want to be [33:50] able to click on it and get to the [33:52] stuff. So, we've added that [33:54] functionality, something that seems very [33:56] simple, but uh so what I'll do is I'll [33:58] show you like if you're looking at [34:00] problems and you click on a problem, it [34:02] automatically opens the accessibility [34:05] analysis and goes to the problems tab [34:07] and opens it up. So, that brings us to [34:10] the next tab, the accessibility [34:12] analysis. In the metab box, this was [34:14] called the details panel. And um we [34:17] we're calling it analysis because we [34:20] want to convey that hey these these are [34:22] the things that we've scanned that you [34:24] need to take action on and and that's [34:28] all that's in here, right? We're not [34:29] mixing in, you know, remediation [34:31] artifacts and things like that. So, [34:34] so when looking at this panel like at [34:36] the at the top level, you can see that [34:38] we have the the the explanation icon [34:42] that's red showing that there are issues [34:44] in here that are problems. If there were [34:47] no problems in the accessibility [34:49] analysis and only needs review, that [34:52] icon would be the the explanation uh [34:55] triangle that is orange. Um so and and [35:01] we are now at the top level we are [35:04] surfacing the number of total issues. So [35:07] before you open a panel you can kind of [35:09] see uh I can see hey there's some [35:12] there's some problems in here I need to [35:15] review and there's 28 total pro issues [35:18] in here. [35:21] Cool. So in problems we now have these [35:24] tabs which William talked about a little [35:26] bit. These are core components that we [35:28] found to be fairly accessible and we [35:31] were very appreciative of that. Um, you [35:34] can see I have 12 problems and I have 16 [35:37] needs reviews. So, we've separated these [35:40] out. Why why do we separate them out, [35:42] William? [35:43] >> Well, problems are something that, you [35:45] know, you need to do something about, [35:47] but needs review are things you [35:50] Well, you need to review them. We we are [35:52] uncertain and we will need a human eye [35:55] to take a look and you know you [35:58] they're two quite different workflows. [36:01] Anything that is in problem needs a [36:02] remediation effort but anything that in [36:04] needs review needs to be looked at and [36:06] it might not have a remediation effort [36:08] required. [36:10] It might actually just be able to be [36:11] dismissed. [36:13] >> Yeah. [36:13] >> It needs a human to to look at it but [36:15] the these are two separate workflows and [36:18] you don't really need the same [36:19] information. [36:21] right [36:21] >> at the same time when you're tackling [36:23] either. [36:24] >> Yeah. So, this goes back to like the [36:25] cognitive load, right? We're we're we're [36:27] making two folders here. We're saying, [36:30] "Hey, look at these first, but know that [36:33] they're equal. They live on the same [36:34] plane here, right? So we do have [36:37] explanation icons for both problems and [36:40] needs review um that are slightly [36:43] different but at the same time we're [36:45] surfacing them kind of the same because [36:47] we don't really know because the needs [36:50] review requires a human audit and [36:53] >> and some of the estras in needs review [36:55] might actually be more problematic than [36:57] problems [36:58] >> or more know that yet. [37:00] >> Yeah. Or more critical. Yeah, totally. [37:03] So um so now if we go down a level we [37:06] look at the the the um the rule the [37:10] individual rules. So we're still [37:11] grouping issues into rules like we did [37:15] in the old metab box. Um and we can see [37:18] that I have ambiguous anchor text. I [37:20] have three of those and that it's [37:22] critical. And we are now ordering these [37:25] in critical criticality. So the most [37:28] critical will be at the top and the [37:30] least at the bottom. So again, putting [37:33] these in the separate folders and then [37:35] then collating these folders folders to [37:38] surface the the items that need the [37:41] greatest attention [37:43] and uh so I will go into the ambiguous [37:47] anchor text according so you see the [37:50] issues now. [37:53] So this was the next uh really [37:57] difficult UI um UI UX change that we [38:03] made and and we evaluated a lot of other [38:06] accessibility tools to see how they [38:08] handle this and and a lot of them handle [38:11] it in the same fashion. But previously [38:13] in the old metab box when you would open [38:16] this up you would actually see the code [38:17] snippet right so um you'd open it up [38:21] you'd see the affected code and then [38:23] you'd see a couple other action items to [38:24] the right and so we're in a sidebar [38:27] that's you know whatever 245 pixels at [38:32] most right and we have to show a huge [38:36] code snippet [38:38] >> the code snippet is the thing I was [38:39] talking about earlier that I thought I [38:41] was going to miss a lot. [38:44] >> Yeah. [38:45] >> And it turns out not so much. I only [38:48] ever looked at it on the front end where [38:49] I could find that markup snippet. [38:51] >> Yeah. [38:52] >> Can't find it here. [38:53] >> Well, and this is this is where like UI [38:56] and UX get real complicated because, you [38:58] know, [39:00] William's experience on how he interacts [39:02] with the plugin is different than [39:04] Amber's experience with the plugin and [39:06] how she interacts with it. And it's [39:08] different than the way I interact with [39:09] it. And and it may be different for like [39:13] if I looked in the old metab box and I [39:15] pulled it open and I see this affected [39:18] code and it's a big huge block of code. [39:21] I'm a developer. Amber Amber's a power [39:24] user uh slashdeveloper [39:28] and and she can kind of look at that [39:30] code and I can look at that code and [39:32] William can look at that code and we can [39:33] kind of you know we can you know it's [39:35] like the Matrix when you see the letters [39:37] going down the screen you can see [39:38] pictures. We can kind of tell what that [39:40] is and where it is on the page and [39:45] oh and yeah so Amber says yeah I want I [39:51] want the code snippet ASAP. [39:54] >> I thought I wanted the code snippet as [39:55] well. [39:56] >> I didn't. [39:58] >> But Amber [40:00] >> this was hard for me. I think I fell in [40:01] the middle of where you and Amber are [40:03] and I I fell in the I fell into I want [40:07] it in the sidebar, but I know that from [40:09] a UI perspective, it just can't happen. [40:13] And [40:14] >> well, I think we reached a fairly good [40:16] compromise on where it could live. [40:19] >> Yep. So when we go to these issues, so [40:23] you're see we have an issue number. So [40:26] this is basically a a database ID. Every [40:29] issue gets a unique number. [40:33] And then we do have [40:34] >> hopefully most users have less numbers [40:37] than this one, which is what 300,000. [40:40] >> Well, this is my local uh site copy. And [40:44] I will say that this has probably been [40:46] around for numerous years. Um, and test [40:50] and testing the accessibility checker [40:52] here. Um, so most people don't have [40:55] 300,000 [40:56] plus issues. So, we have that and it [40:59] links and we're we'll show you that in a [41:01] minute. But then we have this ellipses [41:03] menu to the right, which is our issue [41:06] actions. If I click on that, this is [41:09] where the actions live. I can view this [41:11] on page, I can show the code, or I can [41:13] dismiss the issue. So, if I click view [41:15] on page, and now I'm super zoomed in, so [41:18] this may look a little funny, but [41:20] actually it doesn't look that bad. Um, [41:23] so it does our normal it highlights it [41:26] on the front end and you can get all the [41:28] information on the front end you want. [41:30] Like William said, he looks at this code [41:32] box here on the front front end to show [41:35] the code. [41:36] >> And we're trying to like make the plugin [41:38] more nondeveloper [41:40] friendly. So that this code snippets [41:43] here for power users, ones that really [41:45] want to get into it and maybe for future [41:48] use, uh, being able to modify this. But [41:51] uh we we're trying to make this a little [41:53] more user friendly for nontechnical [41:56] people. [41:57] So those are some of the actions you can [41:59] take and and let's go ahead and open up [42:03] the modal. [42:04] >> Well, I do want to call it there's one [42:06] additional action which you do not see [42:08] because we don't have anything for [42:09] ambiguous anchor text, but there is also [42:11] a fix action that can appear on some of [42:15] the issues. If we have an automated fix [42:18] for it, you're not going to see one [42:19] here. you [42:21] um [42:22] >> link opens new window [42:23] >> link open new window. [42:24] >> Yeah, [42:25] >> there is a fix for this. So [42:27] >> yeah, so there is an apply fix and the [42:28] these are the same actions that you you [42:31] would get in the metab box. [42:33] >> Correct. [42:34] >> So um so let me jump back over to [42:37] problem to that problem. I'm going to [42:39] click on the issue and now we're [42:41] presented with this new modal. And so in [42:47] an effort to try to make the sidebar [42:50] live on, you know, the side and your [42:52] content side by side, but we still want [42:54] to be able to expose a lot of data to [42:57] you about that issue. And and we can't [42:59] fit it all in the sidebar there. So we [43:02] needed a place to put it. So we've [43:04] introduced this new issue single issue [43:07] modal uh which is a modal that shows the [43:10] issue ID at the top. We have a future [43:12] plan to maybe allow this issue title to [43:16] be edited. Um, and then below we have [43:21] our WIKAG information that we introduced [43:23] in the pro plugin uh several a few [43:26] versions back. Um, [43:30] Amber went through and did a amazing [43:32] amount of work on surfacing, you know, [43:34] WIKAD criterion inside the plugin and we [43:38] show that on our open issues page. Um, [43:41] but that has not been available for free [43:43] users until now. Um, so we're now [43:46] surfacing that here. I do have the pro [43:49] plugin installed um, and activated. So, [43:54] if the pro plugin is installed and [43:55] activated, you do get this uh, toggle to [43:58] show explanation. When you open that up, [44:00] it tells you, you know, why this issue [44:03] matters, how to fix it, and then a link [44:06] over to our documentation [44:08] uh for much more inde uh detailed uh [44:12] instructions on how to fix these issues. [44:14] >> Yeah. And if you're a free user, you [44:16] have that link that takes you to the [44:19] detailed documentation. You don't miss [44:22] out on being able to access that [44:24] information. for pro users. It's just [44:26] readily available and as such we can [44:28] show it here in this box, [44:30] >> right? [44:31] >> Format. [44:32] >> Yep. [44:32] >> But that all that information is [44:34] available to everyone. You just have to [44:36] visit the website to get the the quick [44:38] how to fix. [44:39] >> Yeah. So, we've just what we've done is [44:41] we've surfaced this information that's [44:43] already in the open issues to pro users [44:47] right here in the same panel. And like [44:50] William said, if you're a free user, [44:51] this link actually just shows right [44:52] here. So you have access to the same [44:55] information. [44:57] So um [45:00] before I keep going down the content [45:01] here, I want to look at the the sidebar [45:03] here. So we have a sidebar where we show [45:06] the type which we know is a problem [45:08] because we were just in the problems tab [45:11] and we show the severity which is [45:13] critical and the landmark which is main [45:17] and this is a link. So, if I click main, [45:20] this jumps over and highlights the the [45:22] landmark. This was added a few versions [45:25] back in in the plug-in as well. [45:29] Um, and then we have our view on page [45:31] link that was in that action that was in [45:34] that action menu as well. So, we can [45:37] view this on the front end if we would [45:40] like. [45:41] So, back to the main content. William, [45:44] you want to talk about? [45:45] >> Yeah. So here we have the affected code [45:48] which is what I really thought I would [45:49] miss in the sidebar. It turns out I [45:52] don't miss it as much. However, we also [45:55] have code m available from WordPress [45:58] which allows us to do syntax [45:59] highlighting. So in the previous old [46:03] metab box, this would just be a code box [46:06] and or inside the code tag or pre-tag [46:09] and it would just be a gray background, [46:12] black text. Now we have full syntax [46:14] highlighting. So regardless of what type [46:17] of markup this is, it should actually be [46:19] easier to identify the important aspects [46:23] of this. For a developer, the syntax [46:26] highlighting may not be very useful for [46:29] a lot of our users, but for me, it's [46:31] very nice. [46:32] >> Yeah. Yeah. [46:34] >> Yeah. It's pretty. [46:42] >> We got a question asked. You want to [46:44] read this one? [46:46] >> Yes. So, love the references to WIKG [46:48] docs. Are you guys maintaining anything [46:51] that helps generate the data in the [46:52] popover or is that all being pulled from [46:55] an official endpoint somewhere? So, it [46:57] turns out there is not an official [46:59] endpoint from WIKG and this is [47:02] self-maintained information. Some of it [47:05] is mostly readily available from WIKG, [47:08] but a few of the aspects of it like how [47:10] to fix and some of the references that [47:12] are available for pro users are [47:15] maintained by us and mostly maintained [47:18] by Amber. Thanks, not by me. [47:22] >> Yeah. Yeah. Yeah. And you know that's [47:25] interesting you bring this up Troy that [47:27] this was actually something that William [47:29] and I were just talking about earlier [47:30] today because like I said we are we are [47:34] working on uh you know expanding [47:36] accessibility checker uh into different [47:39] applications and services and and that [47:42] information is is is actually not [47:46] available in a public API and we [47:49] actually were discussing about building [47:51] our own API to handle that. [47:54] So great question. [48:02] >> So cool. So that's something in the [48:05] works. And the next one here, William. [48:07] >> Yeah. So the dismiss issue. Previously [48:10] you you could ignore an issue. We no [48:13] longer use the term ignore because we [48:15] actually are not ignoring it's an issue. [48:17] We're dismissing it after careful [48:21] consideration. We hope um and previously [48:25] you could only comment and that was it. [48:27] Now there is also some options here that [48:30] you can flag your issue as the reason [48:32] you've dismissed it. So you might think [48:34] it's a false positive which could happen [48:37] especially in niche review type issues. [48:39] Um you've maybe remediated it and it [48:41] will go away next time you scan or [48:43] you've confirmed it's accessible because [48:45] some niche review items we just don't [48:48] know whether they're problematic. For [48:49] example, if we detect a slider is [48:51] present, we will flag that as a nature [48:53] view item, but you might actually have a [48:55] fully accessible SL slider, which is [48:58] quite uncommon. So definitely check, but [49:02] you might have confirmed it's [49:03] accessible, in which case you can flag [49:06] it as such when you dismiss this issue. [49:08] >> Yeah. Yeah. So a little bit to why we [49:12] don't say ignore items anymore. Um [49:15] because one it was always a little [49:18] awkward to say ignored items or is it [49:22] ignore items? Like it was always a kind [49:24] of a weird thing to say. And uh we're [49:29] trying to think a little bit about the [49:30] meaning of the terminology that we're [49:32] using. Like what does ignore mean? Like [49:35] if it's an accessibility issue and it's [49:38] been surfaced, why would we ignore it? [49:41] like are we ignoring it for a period of [49:44] time? Are we ignoring it forever? Are we [49:48] ignoring it because we want our score to [49:50] go up? Uh you know, are we gaming the [49:53] system by using the ignore system? And [49:56] um u what we wanted to do was kind of [49:59] bring a little bit more of of clarity to [50:03] why things are being quote unquote [50:05] ignored. So we we did land on the word [50:08] dismiss. [50:10] So you can dismiss it for, you know, for [50:13] many many reasons, but it it's it's more [50:16] actionable. It's I took this action to [50:19] dismiss it. I'm not just ignoring. I'm [50:21] ignoring it. Not my problem. Right. And [50:24] and [50:25] >> yeah, the term ignored is is almost [50:27] always used in a negative way and we [50:30] didn't necessarily want that. Um I will [50:32] point out some of these reasons here. [50:34] This might been news to Steve because I [50:36] haven't mentioned this yet, but I do [50:38] think there will be a filter introduced [50:39] over these reasons. So, if users have [50:41] very specific workflow in their local [50:44] sites, they will be able to use a filter [50:46] to potentially add additional reasons [50:48] here. [50:49] >> Yep. [50:50] >> So, these are the three that we surface [50:52] for you now, but with a filter, you can [50:54] probably add more of those in the the [50:56] not too distant future. Yeah, I'll read [50:59] those out too just so so anybody [51:01] listening or that can't see this can [51:04] have so we have dismiss issue as and we [51:07] have radios for false positive [51:10] remediated and confirmed accessible. [51:13] So um and that is a brand new feature [51:16] added in uh to help with remediation. [51:20] So we have our comment box. Um, this [51:25] wasn't called comment before, was it [51:27] called something else? [51:28] >> Um, I have it up, so let me take a look. [51:32] It was It was just called comment, but [51:34] it didn't say it was optional. Oh, [51:36] >> okay. Yeah. Um, so we have the comment [51:39] box. You can, you know, go in here and [51:41] type your comment. And it's kind of cool [51:42] because it's a component and it expands [51:43] as you type, right? Like it, um, so it's [51:47] a lot more modern feeling. And we did [51:49] add in uh the ability to do a t a little [51:53] bit of code formatting. So with bold, [51:56] italics, and then uh links, you can you [52:00] can link [52:02] uh text now. [52:04] >> Yeah. So personally, I don't see that I [52:06] would ever have a use for this, but [52:09] there was a case made that maybe [52:10] instructions might be left here. So [52:12] someone might be coming in and doing [52:14] remediation work and dictating what [52:16] might need to be done to tackle this [52:18] issue. So instructions can be left here [52:21] for example by someone and you know some [52:23] basic formatting might be nice for that [52:26] >> right [52:26] >> and potentially a developer can come [52:28] back later on and fix the problem or [52:30] maybe even the content author can can [52:32] cycle back and read that comment. [52:35] >> Yep. [52:36] Cool. So then below that you can see [52:39] that we have a button called dismiss [52:41] issue and that will will dismiss this. I [52:45] I'll just so everybody on the call can [52:47] see I'll go ahead and dismiss an issue. [52:50] we get a notification that issue uh [52:53] dismissed successfully and then you can [52:56] see the comment and and um I must have a [53:00] I must have a space space in there [53:02] >> and then uh the reason why and who it [53:06] was dismissed by and the date and these [53:08] are things that we had before and I will [53:10] say that we are running um this is 38 [53:15] uh accessibility checker version 1.38.0 [53:19] zero beta 1, right? [53:22] >> Yes. [53:23] >> Okay. So, this is a beta version of the [53:25] plugin. These features have not released [53:27] yet. They will come out shortly. Uh the [53:30] plugin is currently in user testing [53:32] right now. Um but uh this is a piece [53:36] that is still being uh worked on and [53:39] some design and CSS stuff is still being [53:42] worked on this. Um so I can reopen the [53:45] issue now that I've uh you know, maybe I [53:47] accidentally hit the button. And I could [53:49] reopen it here. But when I go to close [53:51] the modal, you see that the issue has [53:54] been uh dismissed. And it is now it now [53:58] lives down in dismissed issues. You can [54:00] see there's four now instead of three. [54:02] And we returned focus back to the [54:06] the current rule because that item [54:08] actually removed. and we didn't think [54:11] that would make sense to actually move [54:13] focus back to the dismissed item because [54:15] we want to keep you in in your [54:18] remediation. And so ideally, your next [54:21] thing would be to go back through that [54:23] list and keep remediating. But that's [54:27] not all. There's more to the dismiss [54:29] issues. William, you want to talk about [54:30] that? [54:31] >> Um, yes. So, there's two additional [54:35] options here in this dropdown. The first [54:36] one is just uh a nice user friendly [54:40] feature dismiss and close model, right? [54:42] It saves you having to make one click. [54:45] It'll dismiss as soon as it gets a [54:46] successful result back from the API [54:49] where the dismiss happens from the model [54:52] will close and that's just a nice UI [54:56] ease of use type of thing like quality [54:58] of life. Um the other one is dismiss [55:01] globally. So previously you would not be [55:03] able to do a global dismiss from this [55:06] page and this is a pro feature because [55:10] global ignores are a pro feature or [55:13] global dismiss as they will be in [55:15] future. Um so if you're using the pro [55:18] plugin you can globally dismiss this [55:20] right from the individual page and that [55:22] saves you having to go find this issue [55:24] in the open issues tab or the fasttrack [55:26] tab. You can just globally dismiss it [55:30] right from here. [55:32] and it has all the same things. Um, [55:35] globals dismisses don't necessarily have [55:38] comments assigned. However, now you can [55:40] add an individual comment here to the [55:42] issue you're dismissing. It won't [55:44] propagate to all the dismissed items [55:46] globally, but [55:48] it it will on this local issue. [55:52] >> Yeah. Yep. So, that's a new feature that [55:54] we've brought. You can uh globally [55:56] dismiss from the single issues page. [55:59] Looks like uh we got another question [56:01] from Daniel here. [56:06] Sorry if I missed this earlier. Does the [56:07] sidebar update errors and counts live as [56:11] the user edits or only upon saving? It's [56:14] a great question. It does it live. [56:17] So if I go here and I dismiss this [56:20] dismiss and close, it's going to close [56:22] the modal and you can see it just [56:23] updated. Um, I do want to make sure that [56:25] Daniel isn't asking if it updates as [56:28] you're editing content here because it [56:31] currently does not add update as you [56:32] edit the content yet. It it has to scan [56:35] a rendered page. So, a save does have to [56:37] occur, but if you [56:38] >> modify an issue by a dismiss, [56:41] >> the numbers reflect immediately in the [56:43] sidebar or or nearly immediately. [56:46] >> Um, [56:47] >> yeah, [56:47] >> we did skip a feature. So, maybe we can [56:49] cycle back to that. So if in the title [56:51] bar here beside accessibility checker, [56:53] there is actually now um a menu that you [56:58] can click to scan the page [57:01] from. [57:04] >> So that just did a scan, right? [57:07] >> It did. And obviously none of the [57:08] content has changed. So nothing is being [57:12] reflected as updated. But if you're [57:14] editing content, you can actually come [57:16] up here and click that scan button and [57:17] it will scan a preview [57:21] >> Yeah. [57:21] >> of the content prior to needing to save. [57:25] >> Oh, yeah. Yeah. So, Daniel did confirm [57:28] that you were right, William. So, [57:31] this is this is a thing that we can do [57:34] this. Um, but part of the problem in [57:38] doing that is that we don't know what [57:40] your final save state is going to be. [57:43] Um, so the way accessibility checker [57:46] works is like if you're if it's polling [57:49] like and you know there there's a code [57:50] term polling if it's like checking every [57:54] you know 5 seconds to see if there's any [57:57] content updated or I think that the [57:59] block editor even dispatches a an edit u [58:04] you know an edit uh [58:06] >> an edit event that is yeah um it has a [58:10] debounce attached and it is every 5 [58:12] seconds, I believe. [58:14] >> Yeah. Yeah. And um we could do that and [58:18] you could be making changes and this [58:20] stuff is actually being written to a [58:22] database. We're not just scanning like a [58:24] a snapshot and storing it locally. This [58:27] is all all your issues get saved to a [58:29] database because they could be managed [58:30] at a global level. It so if we were [58:34] doing that, you're you'd be writing to [58:35] the database and then what if you just [58:38] closed off that page and didn't save it? [58:41] you didn't do a final save. You just [58:43] closed out and you you know you get that [58:45] little notice that says are you sure you [58:46] want to uh you know there's unsaved [58:49] changes. Are you sure? And you you hit [58:51] fine and and you go off. We've actually [58:54] written stuff to the database that's not [58:55] source the source of truth. So we can do [59:00] that but it's a little risky. But like [59:02] William said, we do have what we call [59:04] sidebar actions at the top where you can [59:07] rescan the page in in real time and you [59:11] can actually refresh the content. Do you [59:12] want to explain the refresh? [59:14] >> Yeah. So the refresh action has it [59:17] probably is a little bit of a niche use [59:19] case. However, if some for example, if [59:21] someone is a pro user, they might be [59:24] ignoring issues from the fasttrack page [59:26] which won't immediately be reflected in [59:28] the sidebar. So you might want to [59:30] refresh the sidebar without resaving [59:32] your content. Um or also you could have [59:35] maybe changed the theme of a website in [59:39] which case you can refresh to make sure [59:41] the data gets re repulled if things have [59:44] if things outside of the editor have [59:46] changed. [59:47] >> You might want to refresh the data that [59:49] is in this sidebar just to make sure [59:50] that it is always up to date. [59:54] >> And this final [59:55] >> Yeah. So this is uh does almost exactly [59:59] the same as the clear issues button in [60:02] the old metab box does. It just deletes [60:05] all the data for the issues on this post [60:08] and lets it either be rescanned if [60:11] needed or you know I think there's [60:14] limited use again for this clear issues [60:16] button. We added this to solve a problem [60:18] that no longer exists. [60:20] It's a nice to have I think. [60:22] >> Yeah. And we found that uh you know [60:24] internally um our own auditors [60:28] uh like to use this tool from time to [60:30] time. I I can I can hit uh clear issues [60:33] just to show you. I hit clear. It says [60:36] this will clear all issues for this post [60:38] is saved will be required to trigger a [60:41] re a fresh scan of the post. Do you want [60:44] to continue? Yes, I do. So it's going to [60:46] go through and it cleared out all of [60:49] >> So that's interesting. So I need to [60:52] update that message because you don't [60:54] actually need to save anymore [60:57] >> because we have the the the rescan [61:00] >> rescan. [61:01] >> So without saving the post, I can now [61:03] initiate a rescan and now I have all my [61:06] data back. [61:07] >> Correct. And you will notice that your [61:09] numbers have changed because you had [61:11] dismissed issues that are no longer [61:12] dismissed. However, if you scroll down, [61:14] if you had any globally dismissed [61:17] issues, [61:18] >> they would show. You didn't, but they [61:19] would still be dismissed if they were [61:21] globally dismissed. [61:22] >> Right. Right. Cool. So, that is the [61:26] sidebar actions. And these are helpful [61:29] to help manage your scan overall. [61:32] Sometimes you don't want to, like I know [61:34] if I'm on a client's website and I go [61:36] into their post and I know it needs a [61:40] rescan, sometimes I'm nervous to hit the [61:42] the rescan because I don't know what [61:44] services or plugins they have attached [61:46] to a post that trigger when a post [61:49] >> don't want to resave their [61:51] >> Yeah. Is it going to send an email if I [61:53] resave to like all their users? So it is [61:56] kind of nice having something exclusive [61:58] to the accessibility checker to manage [62:00] that that scan and re rescan. [62:05] So cool. So that's sidebar actions. We [62:09] were down in the accessibility analysis [62:12] panel going through some issues. I think [62:15] in the modal we need to show something [62:18] with an image and possibly a fix. [62:20] William. [62:23] >> Yes. So for the fix we can show this. [62:27] >> Yeah. So I've I've gone to the next tab. [62:29] Like I said, we've collated problems and [62:31] needs review out. And if I click on [62:34] needs review, you can see I have items [62:36] that need to be manually reviewed by a [62:38] human auditor to confirm that they are [62:41] accessible or not accessible. And we [62:44] have the severity flags here. You can [62:46] see. And we've ordered the most severe [62:48] at the top. So, if I click on possible [62:51] heading. Oh, that's not what I wanted. I [62:54] wanted um something with an image. [62:57] Let's see. Okay. So, just like before, [63:00] we would try to pull an image out of the [63:02] code snippet to kind of give you more of [63:04] an indicator of where this is or what [63:06] image it is. And so, we're doing that [63:09] the same here. You can see this is the [63:11] image. [63:12] And of course, if this doesn't need alt [63:15] text, you can you can go ahead and [63:17] dismiss it. [63:19] Um I do want to point out here so while [63:21] this is you know feature par it's the [63:25] same almost you can see the image um [63:28] there has been a slight enhancement here [63:29] so if you have an issue that might have [63:31] multiple images in it for example again [63:34] the slider is present might have six or [63:36] seven images one for each slide all of [63:39] those images will actually be available [63:41] to see in this panel here as opposed to [63:44] just the first image which is what the [63:46] old metab box would [63:48] Right. [63:50] So, [63:53] so I'll just dismiss that because I'm [63:55] saying it's decorative. It's not, but I [63:58] just said it was [64:00] for for demonstration purposes only. [64:04] So, that's the accessibility panel. So, [64:06] you can go through and you can see all [64:08] of your rules and all the issues and go [64:11] in and uh remediate them and u get those [64:15] all accessible. [64:17] and your need to review items uh follows [64:20] the same pattern. [64:22] So, we've talked about dismissed issues. [64:26] So, like I said, we're we're uncolating [64:30] dismissed issues from um the analysis [64:34] because this is this is something that [64:36] you've that an auditor or a user has [64:38] taken action on and we want to kind of [64:40] filter that away. But at the same time, [64:44] we want the them to still be able to [64:47] come in and see what has dismissed and [64:50] maybe review why it was dismissed. Um [64:54] and for that so since we have the [64:57] dismissed as reason now uh when you pull [65:00] up a this is the same the same uh rule [65:05] you know the same pattern UI pattern for [65:08] dismissed issues as the accessibility [65:11] analysis [65:12] >> it's the very same component [65:15] >> um but the dismissed as reason is [65:18] actually flagged on the issue here. So [65:21] you can come here and you can see why it [65:23] was dismissed at just a just a glance um [65:26] without having to open the modal and go [65:30] down here and and read why. But I will [65:33] show like you don't have to take all [65:35] those clicks. You can use the action [65:37] item to reopen the issue [65:41] and uh brings your focus down to the [65:45] current place and reopens it. So, and [65:48] then you can actually review what's here [65:50] and dismiss it again if if if you like. [65:53] >> Yeah. And as as far as screen readers [65:55] go, these notices that are appeared when [65:58] you dismiss or reopen initial, they get [66:01] announced to screen readers as soon as [66:03] they appear. So, issue reopen [66:04] successfully will be announced to screen [66:06] read user if they use that action and [66:09] end up on this page. So, they don't lose [66:11] context. Even though we're moving them [66:13] around, they still get told what just [66:15] has occurred. [66:16] >> Yep. [66:18] So, that will go away. Did we look at [66:21] fixes? Let's see. Um, [66:23] >> we did not look at [66:24] >> say, sorry for the we're jumping around [66:26] a little bit, but um, let me find one [66:28] that has a fix. It's probably link opens [66:30] in a new window. [66:32] >> That's the easiest one to showcase. [66:35] So I could either just open the modal [66:37] and go to it or I can actually hit the [66:39] action the issue action items and hit [66:42] apply fix and that'll open the modal and [66:46] we'll focus on the fix issue. I'm zoomed [66:49] in quite a bit so let me zoom out a [66:50] little bit. [66:52] >> So this is an interesting issue to [66:55] showcase fixes because this has two [66:57] potential fixes in our plug-in. We can [66:59] either prevent it from opening a new [67:01] window by removing the target equals [67:04] blank or we can add a warning the same [67:06] as what our new window warning plugin [67:09] does. It will add a an icon and a label [67:12] that says for screen reader users that [67:15] it opens in a new window. So there's two [67:17] options here. Most issues with effects [67:19] have only one option, but this one has [67:22] two. [67:24] >> Yeah. So if I choose prevent links from [67:27] opening in a new window. So, I have five [67:29] of these. These should all go away, [67:31] right? [67:32] >> Fingers crossed. You save this. [67:35] >> So, I save this. I get a save [67:36] notification. Once I close the modal, [67:38] it's going to rescan and they're all [67:40] gone. [67:41] >> Correct. [67:42] >> Beautiful. [67:43] >> Instantly fixed, unchecked, verified. [67:46] >> Instantly. The way the access Yeah. The [67:49] way accessibility works is you apply the [67:51] fix, it rescans the page, and all your [67:55] issues go away. So, we're not just [67:56] applying a fix and hoping for the best [67:59] because what if our fix actually doesn't [68:00] work in some circumstance. We're fixing [68:02] it, rescanning it, and and if it still [68:06] is an issue, it will resurface back in. [68:09] >> Actually, if someone does encounter an [68:11] issue where they apply a fix and the [68:13] issue doesn't go away, I would love to [68:15] hear about it so that I could make sure [68:16] that [68:17] >> Yep. [68:18] >> that exact markup in that case is added [68:20] to our test suite, which will make sure [68:22] we actually fix it and keep it fixed. [68:25] with our automated fixes. That was a lot [68:28] of times to say fix. [68:30] >> Yeah. [68:33] So, um, so that's kind of how the fixes [68:36] work. They worked that way before, but I [68:38] think it it it kind of you can see it in [68:40] action a little bit here real quick. We [68:43] we fixed and remediated [68:46] uh five issues just with a click of a [68:48] button. Um, so if you're not using the [68:50] fixes in the plugin, uh, take a look at [68:53] them. Um, you there's a lot you can do. [68:56] I mean, I'll pull them up here since [68:57] we're talking about it. [69:00] Um, [69:01] I'm zoomed in a lot. The [69:05] So, you can see we got a lot lot of [69:06] fixes in here for fixing things like, [69:08] you know, removing tab index and title [69:11] attributes, forcing underlines, you [69:14] know, viewport uh changes link like we [69:18] just went through. So you can see that [69:20] we toggled block links from opening in a [69:23] new window and you can see that that's [69:25] toggled here because this is what we [69:27] just did on that single post. Now those [69:29] are at a global level. It does fix it [69:31] for the whole the whole website. So if [69:34] you are running pro, you might want to [69:36] run a fullsight scan after enabling [69:38] these [69:39] um [69:41] uh block PDF uploads. So, we have some [69:44] some of these are pro fixes that are [69:46] available only in our pro plugin. Um, [69:50] I'm I'd have to disable pro. I'd have to [69:53] disable pro to tell you which ones, [69:55] let's see. [69:57] Um, [69:59] deactivate accessibility checker pro. [70:02] So, you can see in the free plugin which [70:04] ones are pro only. So, block uh PDF [70:07] uploads, add file size and type to [70:10] links, uh add missing page titles, and [70:13] we did have a previous change log uh all [70:17] about our fixes. So, you can go back to [70:19] a pre to the episode, which I'm not sure [70:22] we'll have that linked in the uh in the [70:25] show notes and the post that goes out [70:27] about this change log. [70:30] So, let me jump back over to [70:35] my post again. [70:39] Back to my sidebar. [70:42] So, I think that's everything. So, let's [70:44] go to the final tab here and take a look [70:47] at readability analysis. So, [70:50] >> well, I actually do want to point out [70:52] that now you have a different icon [70:54] here [70:55] >> in readability analysis. So, this was [70:59] This was part of [71:00] >> it previously was green. [71:01] >> Yeah. So explain explain why we changed [71:04] this. [71:04] >> Yeah. So well well first off I'm going [71:07] to comment on the fact that this was [71:08] green earlier and is now [71:12] the triangular warning issue rather than [71:14] the green square because when you [71:17] deleted all the data about the post, the [71:19] summary also was removed. So now this is [71:22] a 12th grade reading level. So, it's got [71:25] the warning sign because this needs a [71:27] summary and there is no summary. If you [71:29] add a summary here that is under a nth [71:32] grade reading level, the icon will [71:34] change. [71:36] >> Yeah, I was more spec specifically [71:38] talking about why we're using the orange [71:41] triangle which was warning before uh [71:44] rather than the error, the red circle. [71:50] So it I'll answer my own question but [71:53] the [71:55] readability the the reading level is is [71:58] not necessarily a wikag uh doublea [72:02] requirement. It um it I think it is at [72:06] triple level and I um so but we don't [72:10] currently have a way in the plugin to u [72:14] define the wickag level that you want to [72:16] comply with. If you did uh have a AAA [72:20] requirement defined in the plug-in or [72:22] the ability to do that, we would make [72:24] this red um to to show that it is [72:28] something of attention. But we changed [72:31] it to the to the orange triangle [72:34] explanation to kind of say, hey, this is [72:36] something you need to notice, take [72:37] notice of. It's not necessarily like [72:41] it's a a violation, but uh you need to [72:45] be aware of it and you should you should [72:46] pay some attention to this and and we've [72:49] just done this in an effort to try to [72:51] convey meaning a lot better with our [72:53] icons and our text. So, we can demo [72:58] this. And this this is how the plug-in [73:00] has worked for a long time. Um, [73:04] I thought I had some [73:06] text somewhere. [73:09] >> You can probably just grab the first [73:11] sentence or the first two sentences here [73:12] to to indicate it. It doesn't look like [73:14] it's a lot of long [73:17] There's a couple of long words, but [73:20] >> yeah, it's still 12th grade. [73:22] >> If if you just delete some of the longer [73:23] words, the sentences will no longer make [73:26] sense, but [73:29] you'll get different [73:34] Well, I'm I'm asking [73:37] AI for some [73:40] for some text below a certain grade [73:43] level. Okay. So, [73:45] >> yeah, while you're pulling that up, this [73:47] is a AAA level success criteria 3.1 [73:52] five. Um, yeah, comprehension. [73:57] >> Yeah, [74:00] cool. So, I added in uh uh text that was [74:03] below a ninth grade reading level uh as [74:06] a simplified summary. Um you can see I [74:09] have this 12th grade reading level text [74:12] here which is actually Alice in [74:14] Wonderland. Um [74:18] the and and now you can see that we've [74:20] evaluated your simplified summary and [74:23] it's below the ninth grade reading level [74:25] and and you get the green checkbox and [74:29] the 12th grade reading level of the post [74:32] now uses the gray or black information [74:38] icon. Um, we don't turn this to a to a [74:42] check, a green check, because your [74:45] initial post is still above [74:49] uh the recommended reading level. Um, [74:52] but the simplified summary actually does [74:54] bring it into compliance with the the [74:58] AAA requirement. And you'll see if you [75:01] if you pull open the accessibility [75:04] status panel, you can see under that [75:07] reading level stat that you now have the [75:09] green checkbox and that it says summary [75:12] provided. So if I remove that summary [75:16] and rescan [75:18] and you don't have to save the post for [75:20] this to scan, [75:22] you can see in the summary the [75:24] accessibility status that the reading [75:26] level is said has the warning or the the [75:30] orange triangle explanation icon and it [75:33] says summary required. [75:37] So, um, just doing what we can to [75:40] surface, uh, where the reading level is [75:43] in the stats and give you all the tools [75:46] you need to add a simplified summary to [75:49] supplement your, uh, post that has a [75:52] higher reading grade level. [75:55] And, uh, that works pretty much like the [75:58] old metab box. Um, [76:01] and speaking of the old metab box, I [76:05] know we're running long here, [76:08] but [76:08] >> yeah. So, if you want to swap to my [76:10] screen, actually, I have both the old [76:11] one and the new one up with the same [76:13] data in it in two different windows, so [76:15] we can do a comparison [76:18] if you want to go on quick. [76:21] Oh, but actually, maybe I shared only a [76:23] window and I don't I don't have both up. [76:25] >> Um, [76:26] >> well, well, you can show yours here. [76:29] cycle back. So, [76:31] >> and I I have the other one open. So, [76:34] this was the the old man box that [76:37] everybody's very familiar with using. [76:41] And so, in changing the sidebar, you [76:43] know, it kind of brought up the [76:44] conversation. [76:46] Um, well, we've made a lot of [76:49] terminology changes, a lot of layout [76:51] changes, you know, a lot of the way [76:53] things are displayed changes. [76:57] How do we have to keep parody between [76:59] the two? Like, is the metab box legacy [77:01] at this point? Um, and it really isn't [77:04] legacy because the sidebar is only going [77:07] to work on a on a uh a on a block uh on [77:14] a Gutenberg block editor compatible [77:17] website. if they're running classic [77:19] editor or even if your custom post type [77:21] is only uh classic editor, you still [77:26] need a way to manage the accessibility [77:28] checker. [77:30] So, um let's take a take a look at [77:34] >> So, for me, one of the big differences [77:36] here is first off, you know, these giant [77:40] blocks of color, you know, they're this [77:43] is color for information without any [77:45] other real [77:47] nullifier. So, red is bad, green is [77:51] good, yellow or orange is [77:55] in the middle, I guess. [77:57] >> Mhm. [77:57] >> But, but yeah, so the these are huge [78:00] blocks of color with very little data [78:02] attached. They're they're just numbers, [78:04] and we have a lot of space here in [78:06] comparison to the amount of space that's [78:08] in the sidebar. But, you know, these [78:13] these look different and they also use [78:15] different terms as you'll see in a [78:16] second. But this is the classic box that [78:19] everyone is used to seeing. [78:22] >> Mhm. [78:23] >> And this blue icon and all the other [78:25] ones being white annoys me. The blue [78:27] icon on the warnings panel. [78:29] >> Yeah. [78:29] >> White white icon doesn't pass [78:32] >> color contrast. Yeah. [78:34] >> So, uh so Troy has another question [78:36] here. Um he says that uh [78:40] has there been any consideration given [78:43] to adding any of this to templates? Say [78:47] if I were to show templates while [78:48] editing content but my template had an [78:51] error. [78:53] I'm going to make an assumption [78:54] assumption that you're talking about uh [78:56] full-sight editing templates. [78:59] Is that correct, [79:02] Troy? [79:05] There has been some consideration [79:08] given to the full-sight editing and how [79:12] we can implement the accessibility [79:14] checker [79:15] on uh you know like template parts. Yes, [79:19] that's exact. Yeah. Yeah. So we we have [79:21] internally talked about this. We I think [79:23] there actually is an issue open in our [79:25] GitHub in regard to this on how in the [79:27] full site editor when you're when you're [79:30] modifying a a template part or like a [79:32] header footer how we can run [79:34] accessibility checker just on on that [79:36] template part. And um last year we [79:40] introduced uh scanning of custom post [79:42] types and taxonomies. [79:45] So we now have a mechanism to store uh [79:48] data in what we call a virtual custom [79:51] post type and um we have virtual custom [79:54] post type u there's like a taxonomy that [79:57] goes along with this is a virtual custom [80:00] post type taxonomy these are taxonomy [80:03] taxonomies and custom post types used [80:05] inside of accessibility checker to to [80:09] give the same feel to things that aren't [80:12] actual post and I think we can extend [80:14] that to to fullsight editing parts, [80:17] right, William? [80:19] >> Yes. So, it it's not trivial, but is [80:23] absolutely feasible that we will be able [80:25] to use the features we introduced for [80:28] archive scans and taxonomy scans to be [80:31] able to be applied to template parts as [80:33] well. I did initially do some [80:35] pre-scoping of that, but it wasn't [80:38] feasible for initial release, but it [80:40] absolutely is possible to scan template [80:42] parts individually. [80:44] um and potentially propagate those exact [80:47] results from the template parts through [80:48] to pages which contain those templates. [80:52] >> Yep, it's a great it's a great question, [80:54] Troy. Thanks. So, we have another one [80:57] from uh Daniel. You want to read this [81:00] one? [81:01] >> Yeah. So, Daniel asked, "What will this [81:03] update do to previously ignored DMs? [81:05] Will there be a way for us to go through [81:07] and mark them as one of the three?" So [81:10] the only way you can do that is to und [81:13] dismiss the item and then redismiss it [81:16] with an item on it. There is no [81:19] backporting of the labels currently. [81:23] I'm going to take note of that because [81:25] maybe we do want to add a migration that [81:27] allows people to customize that if they [81:30] can write a filter. M [81:33] >> um but yeah, currently you would have to [81:35] un ignore and then redismiss [81:38] the issue to get one of the reasons [81:41] applied. [81:42] >> Yeah. So since you brought it up, Troy, [81:45] I think we can or sorry Daniel, I think [81:48] we can um [81:50] we can show that. So you do have a [81:53] mechanism. So, like if I have a [81:55] dismissed issue here, [81:58] um, and we're jumping into the the new [82:01] modified metab box here a little bit, [82:04] but um, some things are the same, but [82:08] you can see here that that dismissed [82:11] issue had has a a false positive. You [82:14] can reopen it like your your your issue [82:17] will your issue will show it just these [82:20] won't be selected, right, William? [82:23] >> Correct. These will be empty by default [82:25] and it will be disabled while it is [82:28] dismissed but as soon as you reopen it [82:30] you'll be able to edit. [82:32] >> You can choose it but you do have to do [82:34] it at on a per basis because this is a [82:37] new feature. So it's like a moving [82:39] forward feature. There's not [82:41] >> I actually do think I will provide a WP [82:44] CLI command for backporting these. I'm [82:47] going to probably build that today. [82:49] >> Cool. That'd be awesome. [82:52] We'll make a make a make a card in our [82:54] in linear for you for in our in GitHub [82:57] for you and you can track the progress [83:00] of that. Um, so cool. So that jumps us [83:05] into and and uh Troy does have an AI [83:08] question here and and William and I uh [83:12] are big AI geeks, but we're a little bit [83:16] we're big we're a little bit uh [83:18] realistic about AI, too. We use it a lot [83:22] and we're actually trying to to lean on [83:24] it as much as we can to make our our [83:27] small team operate as quickly and and [83:31] bigger than the size we actually are. [83:34] But we can talk about this. We can [83:36] sidebar on this and jump into the metab [83:38] box. [83:39] But Roy said, "Nice. I was curious as I [83:42] expected with AI building more themes, [83:44] we will see more A1Y issues and [83:47] templates." So this is a this is a [83:50] really interesting question because [83:52] um you could go both ways with it. Like [83:56] you could say arguably that the [83:59] accessibility might be better. [84:02] >> In some cases I have found actually that [84:04] the especially when we were [84:06] transitioning our PHP rules to [84:09] JavaScript rules so we could scan [84:10] everything on the front end. Um, we have [84:13] some AI code review tools, Code Rabbit [84:16] specifically, that was incredibly [84:18] insightful about missteps with [84:22] accessibility messes that the old PHP [84:25] rules might have not accounted for all [84:27] edge cases. And, you know, if [84:32] if your codebase or the prompts ask for [84:36] accessible content, I I actually think [84:39] the AI is [84:42] better than average [84:45] at producing accessible output. It is um [84:50] >> surprisingly good sometimes at [84:52] recognizing labels or missing labels and [84:56] also keyboard handlers if you add a link [84:59] that's not a button. Code rabbit did [85:02] shout at me one time that I didn't add [85:03] the space bar handler. [85:06] I mean it was correct. I missed it. And [85:08] I actually think the AI can sometimes do [85:12] good reviews of code that has [85:17] I don't want to say bad code, but code [85:18] that people forgot a thing. [85:20] >> I often forget. The AI can sometimes [85:23] catch you. But it it can go the opposite [85:25] way. If you're moving incredibly [85:27] quickly, you just want it finished. [85:30] >> The AI might just [85:32] drop you a chunk of markup and it could [85:34] be horribly inaccessible. [85:36] >> Yeah. I mean, I think that's a whole the [85:38] whole breakdown on the methodology [85:39] around the application of AI and what we [85:42] do, right? Sure, there's the crowd [85:44] that's going to try to capitalize off of [85:46] it just because it can do stuff fast and [85:48] they don't even have to think about it [85:50] or review it. And I think the way that [85:52] like we use it is we're we're trying to [85:54] use it to make the software better. [85:57] the there there is a lot of conversation [86:00] internally in our company whether or not [86:02] the AI AI is making us faster. [86:06] Um but we can say that it is making us [86:10] better. It is making the software [86:12] better. It is catching bugs. It is [86:14] catching accessibility issues before it [86:16] goes out. Um so it's just better tooling [86:20] to help us make better software. We're [86:22] not necessarily trying to just turn out [86:24] slop to so we can release something. Um, [86:28] you know, which that that may be the [86:30] crowd that gets in a little bit of [86:31] trouble with the accessibility there. [86:33] But I will say like uh if those template [86:38] parts that are being made in a full site [86:40] uh in the full site editor uh if those [86:43] template parts are used on the front end [86:45] of the website they're they're going to [86:46] be scanned by accessibility checker and [86:48] they're going to be exposed on the page [86:50] and which which they live. If it's if [86:53] your homepage gets scanned it's going to [86:55] surface as a global issue, right? And uh [86:58] so we're still catching those, but it [87:01] will it would be a great enhancement for [87:02] the accessibility checker to actually [87:05] expose those issues in the back end [87:07] while while you're editing those [87:09] template parts because those template [87:12] parts, you could be adding links and you [87:14] could be adding images and if you're not [87:15] adding alt text or you you know you're [87:18] you're making ambiguous text inside your [87:20] links, we could expose it there. So I [87:22] think that's a a great idea. [87:26] Um, we do have one more question. I [87:28] guess we we're very much past time, so [87:30] we need to wrap up soon, but we do have [87:32] another question from Daniel. He asked, [87:34] "For pages not in the block editor, will [87:36] the old metab boxes remain available as [87:39] is for now?" And the answer to that [87:42] loosely is yes. However, they also have [87:45] had almost all of the enhancements we [87:47] created for the sidebar backported and [87:50] they've had a visual refresh as well. [87:52] But those me the classic mailbox is not [87:55] going away probably ever. People who use [87:58] classic editor or any non-block based [88:00] editor will always need that classic [88:03] mailbox. So [88:05] >> yeah, [88:05] >> it will be there. [88:07] >> So let's since we're running short on [88:09] time, let's kind of do a lightning round [88:11] on on the metab box and what we've done [88:13] to kind of bring it in parody with the [88:14] the sidebar. So the metabox we've tried [88:18] to keep it familiar [88:22] but but update the UI and the design to [88:25] kind of match the sidebar. So there are [88:27] some things that we kind of left that we [88:29] removed in the sidebar as far as like [88:31] contrast problems. And these are things [88:34] that we may modify in in you know uh [88:36] future releases to make these even more [88:38] in parody with each other. Um, but we [88:41] didn't want to make the metab box such a [88:43] huge uh change that it was alarming. [88:47] Now, not having the colors in here the [88:49] way they were is kind of alarming. This [88:51] is a much more uh simplified kind of [88:54] blank white clean look, but we wanted to [88:57] bring in the same iconography that we [88:59] used in the sidebar to convey the same [89:02] the same meaning here. Um so this is the [89:06] what was previously this the summary [89:08] panel which is now the accessibility [89:10] status panel. Um uh like like we said we [89:14] talked a lot about the past checks which [89:16] used to be called past tests and this [89:18] progress bar. Um we have left the [89:21] progress bar for now to kind of keep [89:23] that familiarity but we've we've changed [89:26] the color to more of a neutral blue so [89:28] we're not making a a big assumption on [89:31] you know green good bad right. Um I [89:35] don't know if there's anything else on [89:36] here that major that we've changed. [89:38] Anything you want to comment on, [89:39] William? [89:40] >> Just the terminology changes in the [89:42] right hand side. It is problems and [89:43] needs review and dismissed now. They're [89:46] not issues, warnings ignored. [89:49] >> So we did update that. And as you said, [89:51] the iconography, [89:53] >> yeah, [89:53] >> circles with exclamation marks, squares [89:55] with X, triangles, [89:58] >> it's in sync. [90:00] >> Cool. So on the accessibility analysis [90:03] panel which was previously the details [90:05] panel um the updates that have been made [90:08] here oh let me collapse this down. Um so [90:11] the updates that have been made here [90:13] again is pulling in the iconography. Um [90:16] we used to have the count in a little [90:18] bubble that was a color over here. So [90:21] we've brought in the iconography with [90:23] the same coloring and we've moved the [90:25] count to the to the back of the the [90:29] rule. Um so uh to bring it exactly in [90:32] line with the way that the sidebar [90:35] displays the count of issues, we've [90:38] added in the severity and we've updated [90:42] the ordering to order by severity in in [90:45] this panel. Um so we have a new flag [90:48] here. This was you know like I said [90:50] something that was introduced in the pro [90:51] plugin last year and we are now [90:54] surfacing severity throughout the [90:55] plugin. [90:57] And I think that's all the updates [90:59] there. If I open up an issue [91:03] um and we we just talked about this, you [91:05] want to just summarize it. [91:07] >> So we brought the dismiss reason over to [91:10] this [91:12] the individual dismisses and the the [91:14] single a single issue for each of the [91:17] meta boxes. You can now use the dismiss [91:19] reasons. This was a new feature [91:20] specifically for the sidebar, but we [91:23] backported it here. So you don't lose [91:25] this feature if you do not use the new [91:27] sidebar. You still have access to this. [91:30] >> Yep. [91:32] Cool. So that is some of the changes to [91:36] to the accessibility analysis panel. And [91:40] then finally the readability analysis [91:42] panel which was previously just [91:45] readability. [91:46] Um, we've updated this with the same [91:50] iconography from the the sidebar just so [91:54] again these match up and there's no [91:57] confusion going back and forth. We've [92:00] removed colors [92:02] the the the grade level used to switch [92:05] between red and green based on if it's [92:07] passing or not and we have removed that [92:09] and we're allowing the iconography to to [92:13] drive the uh urgency of that. Um, but [92:17] other than that, I think just some [92:20] terminology updates and some buttonup [92:22] label updates is about all we've changed [92:25] there. [92:29] So, that is a quick overview of the new [92:35] accessibility uh the new accessibility [92:37] checker sidebar [92:39] and our first iteration on new UI [92:43] enhancements. [92:44] Do we have any other questions before we [92:46] go, William? Let's see. [92:49] I [92:49] >> don't see any new questions come in. [92:52] >> Although I appreciate everyone asking [92:54] questions and being around today. [92:55] >> Yeah. Yeah. Makes it more [92:56] conversational. [92:59] See, Troy said, "I've had some success [93:01] in guiding AI design to fix, but there's [93:04] part of me that knows that some folks [93:07] won't think to do that." Yes, AI is a [93:10] great tool. And like uh if if you have [93:14] the knowledge already like of [93:17] accessibility or software engineering [93:19] the AI becomes a superpower and um but [93:23] again in the wrong hands it can kind of [93:26] create what we call slop. [93:30] Um so it's a great observation. You got [93:35] anything to add to that William? [93:36] >> No I think that is absolutely on the [93:39] head. If [93:41] if you don't know what to ask the AI, [93:43] then [93:44] you're not going to know what to value [93:47] when it gives you a back. So So it's the [93:50] same. I I guess we are somewhat biased [93:53] in that sense that we ask things [93:56] differently to what an average person [93:57] might. [93:58] >> Yeah. [93:58] >> And that could be the reason why we get [94:01] okay results for accessibility from the [94:03] AI. [94:04] >> Yeah. Yeah. Yeah. Amber says, um, I [94:07] agree. You get better output if you know [94:10] how to prompt it. It's totally true. And [94:13] and like even in the discussion that [94:16] William and I were having a couple weeks [94:18] ago or whatever, I was I was making some [94:22] quick comment about like, you know, AI, [94:26] why can't you get it to do this? And [94:27] like it does it great for me, right? [94:29] like or not him but like just an [94:31] observation on people's you us using [94:34] using uh AI and and then William's like [94:38] I don't think you know this but you [94:40] prompt a lot different than probably a [94:41] lot of other people. So [94:43] >> yes [94:44] >> so there's probably a little bit of I'm [94:47] going to coin a term William I'm going [94:49] to copyright it after this but I'm gonna [94:51] copyright it after this. I got to make [94:52] an expose about this cuz I'll get all [94:54] kinds of but uh prompt bias, right? Like [95:00] >> I think that's very very much real. I [95:02] write prompts in a very specific way [95:05] that encourages it to [95:08] be quite verbose sometimes with [95:10] comments. And I've seen people write [95:13] produce a lot of AI code that contains [95:15] zero comments at all. I think everyone [95:18] does have a bit of a bias towards what [95:20] they like to write their code like and [95:23] that extends into how they ask the AI to [95:25] produce the code as well. [95:27] >> Right. Well, and you ask questions like [95:32] you you you ask questions to answers [95:35] that you already know because you want [95:38] to see what it does. [95:39] >> Yeah. Well, it's always good to get [95:41] alternative perspectives. That's [95:43] sometimes the AI can be the other pair [95:45] of eyes, [95:46] >> right? [95:47] So cool. Well, one of these days we'll [95:50] have to do uh just a a big WordPress AI [95:56] accessibility live stream and go real [95:59] deep on this AI stuff and how we're [96:01] using it and how it can help uh with [96:04] accessibility and you know just [96:06] development in general. um and [96:08] remediating your website like uh we do a [96:11] lot of remediations at Equalized Digital [96:14] and uh our our remediations are are [96:17] definitely um going a lot quicker uh [96:21] with the use of AI and um when we're [96:25] fixing things in like page builders and [96:26] stuff like that, there's a the AI can [96:28] really assist us in that and and the net [96:32] then I don't we don't necessarily get a [96:35] a a boost or a huge uh win internally [96:40] for us, but the client does we can go [96:43] further on the website with with the [96:46] client's aotted budget. [96:49] So [96:50] >> yeah, there there is quite a lot of like [96:52] you know we talked earlier on about tabs [96:54] and how tabs need to be arrow key usable [96:58] and that's actually a misstep that most [96:59] people who build tabs forget. um [97:03] you know you you should use arrow keys [97:05] to navigate through a set of tabs and [97:07] the amount of code that's required to do [97:09] that is actually quite a lot [97:11] >> and there's no out ofthe-box package to [97:14] do that but you can quite easily ask the [97:17] AI and explain the requirements and the [97:19] AI can look at the code on the page and [97:22] work out the exact selectors that need [97:25] to be applied to the right items and [97:28] you're still telling it what needs done [97:30] but it can hype faster than you can. And [97:33] that's where the speed acceleration [97:34] comes from. [97:36] >> Yeah. Cool. Well, I think that wraps [97:38] this episode. This one was a long one. [97:40] Um, but I'm I you know, I'm so [97:43] appreciative of of you all joining us [97:46] and listening in and adding uh [97:48] conversation and questions. And u look [97:52] for these new features to come out in [97:54] the the next release of accessibility [97:56] checker that will hopefully be out in [97:59] the next week or so. And uh we look [98:02] forward to seeing you on the next uh [98:04] live stream. [98:07] >> Thanks everyone. See you later. See you.  ## 📺 Video ![](https://www.youtube.com/watch?v=xDybU7hj2Y8) --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: Reimagining Accessibility Checker in the Block Editor Sidebar ## 🧰 Action Inbox - [H1] Test Accessibility Checker 1.38.0 beta with new block editor sidebar integration — #wordpress #beta-testing - [H2] Evaluate UI/UX changes from metabox to sidebar for accessibility scanning workflows — #ux-design #accessibility - [H3] Consider front-end highlighter compatibility with page builders like Bricks — #page-builders #compatibility ## 🧭 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/gutenberg/) - [WCAG Guidelines](https://www.w3.org/WAI/WCAG21/quickref/) ## 📝 Summary - Equalize Digital demonstrates major UI/UX overhaul of their Accessibility Checker WordPress plugin - New block editor sidebar integration replaces classic metabox approach after 5 years - Key changes include terminology shifts (errors/warnings → problems/needs review), severity-based ordering, and improved visual hierarchy - Four new panels: Accessibility Status, Analysis, Dismissed Issues, and Readability Analysis - Enhanced features include global dismiss, issue modals, WCAG integration, and real-time updates ## 📖 Main Content Equalize Digital's Accessibility Checker plugin is undergoing its most significant redesign since launching five years ago. The team has rebuilt the interface from a classic WordPress metabox into a modern block editor sidebar integration, addressing the evolution of WordPress's editing experience while maintaining backward compatibility. The redesign addresses spatial constraints of the sidebar (approximately 245 pixels width) while improving the user experience through better information hierarchy, modern WordPress components, and enhanced accessibility features. The team conducted extensive design phases and user testing to balance feature completeness with cognitive load reduction. Key architectural changes include separating remediation artifacts from active issues, implementing severity-based ordering, and introducing new terminology that better reflects user workflows. The integration leverages core WordPress components while adding custom accessibility features that weren't available in standard Gutenberg components. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/xDybU7hj2Y8?t=0) — [H1] Introduction and Context - Key idea: Five-year-old plugin getting major UI/UX overhaul for modern WordPress - Evidence: "Accessibility checker has just had its fifth birthday. It's five years old." #### ⏱️ [02:30](https://youtu.be/xDybU7hj2Y8?t=150) — [H1] Block Editor Integration Rationale - Key idea: Moving from wide metabox to narrow sidebar requires complete UX rethinking - Evidence: "We're going from having a very wide space for the metabox to having a very narrow space for the sidebar. You have to make a lot of UI and UX considerations." #### ⏱️ [05:45](https://youtu.be/xDybU7hj2Y8?t=345) — [H2] Technical Implementation Success - Key idea: WordPress block editor components proved surprisingly reusable and accessible - Evidence: "The components that already exist that are used to build Gutenberg itself or the block editor are all available to reuse and they are quite reusable." #### ⏱️ [08:20](https://youtu.be/xDybU7hj2Y8?t=500) — [H1] Accessibility of Block Editor Components - Key idea: Block editor accessibility has improved significantly, enabling accessible plugin development - Evidence: "I actually think I've changed my generalized opinion on whether the block editor is accessible or not. I think they've made an awful lot of progress." #### ⏱️ [12:15](https://youtu.be/xDybU7hj2Y8?t=735) — [H1] Four-Panel Structure Overview - Key idea: Sidebar organized into Status, Analysis, Dismissed Issues, and Readability Analysis panels - Evidence: "We have four panels in the sidebar, and these correlate to our old metabox." #### ⏱️ [15:30](https://youtu.be/xDybU7hj2Y8?t=930) — [H2] Terminology Changes: Problems vs Needs Review - Key idea: Replaced errors/warnings with problems/needs review to clarify actionable vs investigative workflows - Evidence: "We've removed that terminology of errors and warnings and we've replaced it with problems and needs review because that really is the distinction." #### ⏱️ [18:45](https://youtu.be/xDybU7hj2Y8?t=1125) — [H3] Page Builder Compatibility Challenges - Key idea: Current sidebar limited to block/classic editor, but front-end solutions planned - Evidence: "We have future plans to bring all of these new features to a new front end highlighter, moderator, scanner system." #### ⏱️ [22:10](https://youtu.be/xDybU7hj2Y8?t=1330) — [H2] Visual Design Philosophy: Icons, Shapes, and Color - Key idea: Moved from color-only indicators to combined icon, shape, and color system - Evidence: "We're conveying meaning with color icon and shape, not just colors." #### ⏱️ [25:40](https://youtu.be/xDybU7hj2Y8?t=1540) — [H2] Pass Checks Redesign Rationale - Key idea: Demoted pass checks from prominent green circles to informational status - Evidence: "Pass checks just runs a calculation on how many of our rules is this post passing... there could be a whole lot of reasons not to necessarily convey good." #### ⏱️ [30:15](https://youtu.be/xDybU7hj2Y8?t=1815) — [H1] Severity-Based Issue Ordering - Key idea: Critical issues surface first within problem categories for better prioritization - Evidence: "We are now ordering these in critical criticality. So the most critical will be at the top and the least at the bottom." #### ⏱️ [35:20](https://youtu.be/xDybU7hj2Y8?t=2120) — [H2] Code Snippet Removal Trade-offs - Key idea: Removed inline code display due to space constraints, moved to modal view - Evidence: "The code snippet is the thing I was talking about earlier that I thought I was going to miss a lot... It turns out not so much." #### ⏱️ [40:30](https://youtu.be/xDybU7hj2Y8?t=2430) — [H1] New Issue Modal with Enhanced Features - Key idea: Single issue modal provides comprehensive details including WCAG information and syntax highlighting - Evidence: "We've introduced this new issue single issue modal... we show the issue ID at the top... our WCAG information." #### ⏱️ [45:50](https://youtu.be/xDybU7hj2Y8?t=2750) — [H2] Dismiss vs Ignore Terminology - Key idea: Changed "ignore" to "dismiss" with categorized reasons for better workflow clarity - Evidence: "We no longer use the term ignore because we actually are not ignoring an issue. We're dismissing it after careful consideration." #### ⏱️ [50:25](https://youtu.be/xDybU7hj2Y8?t=3025) — [H3] Real-time Updates and Scanning - Key idea: Sidebar updates immediately on issue actions, with manual scan option for content changes - Evidence: "It does update live. So if I go here and I dismiss this... you can see it just updated." ## 📚 References - [Equalize Digital Accessibility Checker](https://equalizedigital.com/accessibility-checker/) - [WordPress Gutenberg Components](https://developer.wordpress.org/block-editor/reference-guides/components/) - [WCAG 2.1 Guidelines](https://www.w3.org/WAI/WCAG21/quickref/) ## 🗣️ Paraphrase - Equalize Digital redesigned their 5-year-old Accessibility Checker plugin to work natively in WordPress's block editor sidebar instead of the traditional metabox - The narrow sidebar space (245 pixels) required complete rethinking of information hierarchy, visual design, and user workflows - Major terminology changes include replacing "errors/warnings" with "problems/needs review" and "ignore" with "dismiss" to better reflect user actions and decision-making processes ## 📰 Newsletter The Accessibility Checker plugin is getting a major makeover! After five years of serving the WordPress community through a classic metabox interface, Equalize Digital has rebuilt their popular accessibility scanning tool for the modern block editor. The new sidebar integration puts accessibility insights right alongside your content editing workflow. Key improvements include severity-based issue prioritization, enhanced WCAG documentation integration, and a cleaner visual hierarchy using icons, shapes, and color together. This update demonstrates how mature plugins can evolve with WordPress's changing landscape while maintaining the robust functionality users depend on. The team's focus on reducing cognitive load while improving information access sets a strong example for plugin UX design. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer experience: Create migration guides for UI/UX changes, document new component usage patterns - Developer marketing: Showcase block editor integration best practices, highlight accessibility-first design approach - Community management: Gather feedback from beta users, moderate accessibility-focused discussions #### WordPress - Core: Evaluate accessibility improvements in block editor components, contribute findings back to Gutenberg - Design: Document successful narrow-space UI patterns, share color/shape/icon accessibility principles - Accessibility: Review plugin's WCAG integration approach, consider standardizing accessibility metadata APIs - Plugins: Examine block editor migration patterns, document sidebar development best practices #### Community - Maintainers: Share lessons learned from major UI overhauls, provide sidebar integration templates - Contributors: Contribute accessibility testing feedback, help refine developer experience documentation ## 🧪 Hypotheses - Users will adapt more quickly to terminology changes (problems/needs review vs errors/warnings) when the workflow separation is clear - Sidebar integration will increase accessibility checking frequency due to reduced context switching - Severity-based ordering will improve remediation efficiency compared to rule-based grouping - Icon/shape/color combination will provide better accessibility than color-only indicators ### 📊 Methodology - A/B testing between old metabox and new sidebar for task completion times and user satisfaction - User interviews comparing workflow efficiency before and after terminology changes - Analytics tracking on dismiss categorization usage patterns and global dismiss adoption - Accessibility testing of the plugin interface itself using screen readers and keyboard navigation ### ❓ Questions - How will the 245-pixel width constraint affect future feature additions to the sidebar? - Can the WCAG information integration model be standardized across WordPress accessibility tools? - What impact will the UI overhaul have on existing power users' established workflows? ### 🔮 Future Research - Investigate standardized accessibility metadata APIs for WordPress plugins - Explore cross-plugin compatibility patterns for block editor sidebar integrations - Study the effectiveness of severity-based vs rule-based issue organization in accessibility tools ### 💡 Implications - Practice: Major plugin UI overhauls require extensive user testing and gradual terminology transitions - Policy: WordPress plugin guidelines should include block editor integration recommendations - Education: Plugin developers need resources for accessible component usage in narrow-space interfaces - Funding: Mature plugins benefit from periodic UX investment to stay current with platform evolution ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical plugin development content) #### 👀 Visual learners - Present: Extensive sidebar screenshots, UI component demonstrations, before/after comparisons - Improve: Flow diagrams showing user workflow changes, component hierarchy visuals #### 🔊 Aural learners - Present: Live demonstration with detailed narration of UI interactions - Improve: Audio-only summary of key terminology changes and workflow benefits #### 🗣️ Verbal learners - Present: Clear terminology explanations, analogies comparing old vs new approaches - Improve: Glossary of old vs new terms, story-driven examples of user scenarios #### 🧩 Kinesthetic learners - Present: Live plugin demonstration, interactive sidebar exploration - Improve: Beta testing checklist, hands-on migration guide #### 🧠 Logical learners - Present: Technical implementation details, component decision rationale - Improve: Decision tree for UI component selection, performance metrics comparison #### 🧑‍🤝‍🧑 Social learners - Present: Team discussion of design decisions, community feedback integration - Improve: Beta user feedback compilation, developer community discussion prompts #### 🧘‍♀️ Solitary learners - Present: Self-guided plugin exploration, individual testing scenarios - Improve: Personal reflection prompts on workflow changes, self-assessment checklist #### 🌿 Naturalistic learners - Present: Plugin evolution over time, adaptation to WordPress ecosystem changes - Improve: Ecosystem impact analysis, sustainability of design decisions ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Proper heading hierarchy, landmark usage, comprehensive alt text on UI demonstrations - Improve: More detailed descriptions of visual layout changes, component relationship explanations #### Keyboard navigation - Present: Discussion of keyboard support in WordPress components, tab order considerations - Improve: Explicit keyboard navigation testing results, focus management examples #### Contrast and readability - Present: Discussion of moving away from color-only indicators - Improve: Specific contrast ratios for new icon/shape/color system #### Media and captions - Present: Live stream with real-time audio description of UI interactions - Improve: Downloadable transcript, chapter markers for key sections #### Forms and interactions - Present: Modal form design discussion, dismiss categorization UI - Improve: Error state handling examples, validation feedback patterns ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focus on making accessibility tools accessible regardless of technical background - Improve: Examples from diverse WordPress user contexts, international plugin usage patterns #### Inclusive language - Present: Thoughtful terminology changes from "ignore" to "dismiss", "errors" to "problems" - Improve: Plain language summaries of technical concepts, jargon definitions #### Neurodiversity support - Present: Discussion of cognitive load reduction, information hierarchy improvements - Improve: Specific examples of how changes support different cognitive processing styles #### Representation - Present: Team with diverse skill sets contributing to design decisions - Improve: More diverse user testing feedback, varied use case examples ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear logical progression from space constraints to UI decisions - Inductive strength: Good use of user feedback patterns to inform design changes - Causal reasoning: Well-established connections between terminology confusion and workflow problems - Analogical strength: Effective comparison between old and new interface approaches #### Fallacies - Appeal to novelty: Minor tendency to present new features as inherently better without full evaluation - False dilemma: Occasionally presents choices as binary when multiple solutions might exist #### Tone of voice - Overall tone: Professional and thoughtful, with good balance of technical detail and user-focused explanations ### 🛡️ DARVO Analysis - Deny: No problematic denial patterns observed - Attack: No attacks on users or critics present - Reverse victim/offender: No victim/offender reversals noted - Emotional cues: Positive, collaborative tone focused on improvement and user experience ## 🎯 Conclusion Equalize Digital's Accessibility Checker sidebar integration represents a thoughtful approach to plugin evolution, balancing modern WordPress integration with user workflow needs. The emphasis on terminology clarity, visual hierarchy, --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=xDybU7hj2Y8)* **[00:02]** All right, I think we are live. >> Looks like it. >> We checking the stream. >> Yep. Checking on YouTube. It is going. I'm presuming everything else is fine. >> Yep, probably is. >> Cool. So, how's it going, William? You doing good? >> Yeah, doing all right. Can't complain. It's been a little bit. We >> It has **[00:33]** >> We missed the uh the last one, the one that we normally have at the beginning of the month, but that's for good reason, right? >> Yeah. It's because we didn't do any work that month. >> That's right. No work at all. Just >> just a bunch of slackers. Not coding. No. >> Signed in chat a bit. >> That's right. >> Left. No, we're being uh facitious. We've actually been working very hard on **[01:04]** some new stuff and some stuff that just needed that extra couple weeks of work. So, we're give it a little bit of time, see if anybody joins us. If not, we're just push forward and and talk about new stuff. So, um this is the accessibility checker change log live stream where we talk about uh the WordPress plugin, the accessibility checker, which is an **[01:34]** automated accessibility scanning plugin to help your WordPress website become and stay accessible. We have a free uh fullfeatured plug-in uh called accessibility checker. We have a pro version that you can get to that extends upon that and adds uh lots of prolevel premium features and and we also have uh three add-ons to our pro plugin that you can get at different subscription levels. We have an audit **[02:06]** history plugin to track your accessibility uh compliance over time. We have a multi-sight add-on that allows you to manage your license and stats and activations across a multi-sight network. And we have an export add-on that allows you to export your accessibility uh scan data to a CSV file. So you could import that into your system of choice. So today's theme, William, is re-imagining **[02:38]** accessibility checker in the block editor sidebar. >> Yeah. So we did not have any sidebar integration. We effectively didn't really have any block editor integration, any deep integration for a long time. So now that changes and we went all in. >> Yeah, we went all in. So, so for those that don't know, accessibility checker is is is quite old **[03:08]** or as my teenage children would say, uh, unc. And with him shaking his head at me. Can't believe this. >> I know what that means. >> Just means old. Uh, so accessibility checker has just had its fifth birthday. It's five years old. And five years ago, the the block editor was not quite where it is today. And um we used a classic metab box. If you're a current user of **[03:39]** the uh plugin, you are very familiar with our our metab box that you use to uh check your status and and see how many issues you have and and to manage your readability. So, what our goal here for the new year is to go through uh the plugin and kind of do some UI and UX overhaul. Since it's been five years, it's time to give the plug-in a little bit of a refresh, a little bit more of a visual um um modern **[04:11]** visual look, and to help integrate it more deeply into the WordPress admin to make it feel like it works more seamlessly with the block editor and at the same time maintaining backward support for post types or websites that don't support the block editor. So what we've done is we took the the current classic metab box and just rethought it. How how if we're rebuilding this in the sidebar of the block editor, **[04:43]** how can we rethink this? And if if you've used the block editor and you know the sidebar is a very it's a not a very wide space. So, we're going from having a a a very wide space for the the metab box to having a very narrow space for the sidebar. And when that happens, you have to make a lot of UI and UX considerations. And you have to really think deeply about the information you're trying to service and **[05:14]** very deeply about uh what all you put in there because like it can you know you can't put big blocks of text because they wrap and and it >> it look it looks bad. >> Effectively you have 265 pixels which doesn't account for padding. So you got to pad that out a little bit as well. You may get to 40 pixels worth of usable space. It's It's nothing. >> Yeah, >> you can fit a button side by side and that's about it. >> That's right. Even your text labels have **[05:45]** to have some consideration, right? >> Yep. So, um, but the but the big benefit of the block editor sidebar is is it surfaces the accessibility checker one at the top of the page inside of the toolbar alongside the other sidebars that other plugins may add or or the default sidebars that are there and it services it beside your content. So, no longer are you looking at your content scrolling down to the metab box. Okay, **[06:15]** what is this? Trying to find that issue in your editor and you know this just back and forth. What? It push it to the side. Your contents on the left, your sidebar on the right. I I think you can move these sidebars, can't you? >> To the right and left. >> I think you can swap them to the other side. I have never had any reason to move it to the other side. I believe you can. >> But it it puts it in one p one pane in in two columns. you now have a visual of your content and the accessibility checker at the same time. So, um there's **[06:50]** a lot to talk about in regards to what we did, but I think we should pull it up and we should start going through it and just kind of kind of start talking about some of the changes that we made because there are a lot of terminology changes. We we had a lot of internal discussion if we should build a glossery since terminology is being reconsidered so much and and trying to unify terminology throughout all of our our products. Um but let me pull it up and we're we'll just walk through it piece by piece. **[07:21]** Cool. So this is just a normal uh post in the WordPress admin. And you now say you can now see that we have a little icon up here in the top toolbar in the right. And uh if you use like uh the Yoast plugin, you can you have Yoast has their sidebar here. So now we have ours. But we wanted to make sure that you know since we're moving this and creating new functionality that that you didn't **[07:52]** overlook it. So we've added a metab box down below uh in the post sidebar uh for accessibility checker says you have 12 problems to address and 16 issues that need to be reviewed with a button that will initiate that sidebar. So that's just us kind of helping you if you're in this default view that hey accessibility checker is running there are issues and this kind of just helps bridge the gap between the old metab box and the new sidebar. So I'll go ahead **[08:24]** and click on the sidebar icon to pull it up. So we are presented with the default view here. Is this large enough? William, should I try to >> If you could zoom in, I think that might be quite good. Yeah, that that looks better. It is. You don't realize how small it is until you have to start shining. >> Yeah. Yeah. So, since since it's since uh since the sidebar is quite small, I will **[08:54]** show it at a zoomed in uh view here so we can look at it in the screen share together easily. So, so William, before I talk through some of this stuff, uh, were there huge technical challenges in in getting here? >> Um, so surprisingly, the components that already exist that are used to build Gutenberg itself or the block editor are all available to reuse and they are quite reusable. A lot **[09:26]** of this is core UI components. It will look very familiar to people. You will recognize the panels. These are the same panels that exist in style edits. For example, if you have a block open to edit, these are the same panels. So, as far as technical hurdles go, easier than expected. Not simple, but not complicated either. >> Yeah. So, we're able to like uh take accessibility checker data and kind of **[09:58]** take uh WordPress core block editor components and kind of utilize those and and build out this sidebar. And those sure there's a custom there's a a few custom element uh components that we've added here, but it's just a much more mature application way of building it. And um we were pleased to find that in using those components that we did have um what are called properties props **[10:28]** inside these components that actually do allow us to achieve the level of accessibility uh that we're trying to achieve here. Um it it can be discussed a little bit in the Gutenberg block editor, you know, that it's completely inaccessible or it's not usable. But uh we've seen a lot of maturity in regards to accessibility inside the block editor. And we were actually kind of pleased to find ourselves uh that these **[10:59]** components uh maybe not out of the box were set exactly the way we wanted them set for uh accessibility, but the the props were there for us to achieve the level of accessibility with our own plug-in that we're trying to achieve. >> Yeah, I actually think I've changed my generalized opinion on whether the block editor is accessible or not. I think they've made an awful lot of progress since the last time I had evaluated **[11:30]** >> this. Like a huge amount of progress. >> Yeah, I I would agree. And I think that may be a little bit of our delay to move accessibility checker into the the the block editor uh for for those reasons and and maybe some of our own misconceptions as well why we delayed on that because what we try to do with accessibility checker is it's a plugin that is used to scan your website for accessibility problems. But we also try to practice what we preach **[12:01]** and we try to make our plug-in accessible itself because we want if you know regardless of somebody's ability if they if they want to make their website accessible we want our tool to be accessible to check the accessibility of their website. So um so we were pleased to find that uh we were able to achieve a good level of accessibility while moving into the block editor. Um, >> yeah, labels were readily available to **[12:31]** you to add. Keyboard navigation was surprisingly high level on the majority of the components we needed them to be on. >> Mhm. >> Um, tabs for example, which we will see shortly, I was incredibly surprised had full keyboard support, >> right? >> So, and implemented properly. >> Yeah. With arrow keys. Yes. Yes. >> Yep. >> Yeah. Cool. So, let's take a look. We have mult uh I'm going to close this **[13:01]** one. We have four panels in the sidebar, and these correlate to our old metab box. Um, but you'll notice that the terminologyy's changed a little bit. So, we used to have the summary tab in the metab box, which is now the accessibility status uh accordion here. And we used to have the details panel which is now the accessibility analysis panel. And uh we you in the metab box and we're **[13:32]** going to talk about the metab box here in a little bit too because it it has been brought up to date and we're trying to keep things in par with the sidebar as much as we can. Um we actually uh in the details the previous details panel uh what we used to call ignored items uh were they're they're filtered in with the other issues. So what we've done is we've actually separated them out now in the sidebar. **[14:02]** So, so we now have a panel called dismissed issues and and the the reasoning for moving those out and surfacing them into their own panel is we're trying to create separation between um what needs to be actioned on and what are artifacts of remediation. So we want before we were kind of collating those things and and now we want to separate those out u to create **[14:33]** greater separation on what you've done and what you need to do. And then finally we have a fourth panel called the readability analysis which was called readability before. >> It was just called readability. Correct. >> Yes. So let's let's dive into each panel individually. So William, you want to talk about the accessibility status panel? >> Um, sure. So the accessibility status panel is very much the same as what you **[15:06]** would see in the existing or the previous metbox. It has all the surface level information that you might need to make a decision about what you're going to focus on while editing this page. So in this example here, we have 12 problems and 16 items that needs review. You know, immediately, you know, arguably problems are bad, but things that you need to review might actually be worse because **[15:36]** we don't know if they're problems. Um, but one major difference here is we no longer break out contrast headers. Previously, we would break contrast headers out and have eders as two separate groups. Contrast eders are eders and all eders are problems. Um, contrast eders now are included in the problems count. They are they are the same. They they need they need to be dealt with. So, >> they're a single group. Um the other big **[16:06]** change here is that the the number pass checks used to be named pass tests and it used to be the largest object on in the metab box. After some consideration, we decided maybe it isn't the most important aspect of the data here and as such it has a similar weight as as all of the other items. >> Yeah. Yeah. So I mean to tag on that a little bit the the ordering has been moved around too. So so William said said that **[16:38]** like we had problems and then we had contrast issues. And I think our original thought around separating those out as two individual u issues is because color contrast can be a lot of times with themes and WordPress themes one of the biggest things to focus on. But um as far as like giving weight to things they really have the same weight. So we've just decided to collect those into into one one uh data point and um so those are now called problems. So **[17:09]** we're we're no longer calling them errors because what we've introduced is we'll talk about here in a little bit is severity. So if we if we're calling issu if we're calling things errors and warnings and then we have a severity like if a warning has a critical severity and an error an error has a low severity like which which one takes priority. So what we've done is we've um we've removed that terminology of errors and warnings and we've replaced it with **[17:39]** problems and needs review because that really is the distinction. Previously an error before was something that we could programmatically with with good accurate with very good accuracy tell that this is an issue and need to review is something that programmatically we we couldn't with 100% or 99.9% accuracy um tell you that this is an issue. It actually required a little bit of uh human review and you know alt text is a **[18:11]** perfect example of of something that gets flagged as needs review because there could be a ca there could be a very valid case for not adding alt text to a decorative image. So we have a question here. Let me pull this up um from from Daniel. Is there any chance for this to eventually roll out to other editors, i.e. Bricks Builder? Um, so **[18:43]** what I like I stated earlier, we're looking down the road to major UI and UX overhaul of the accessibility checker this year. This is the first step. Um, there the there is a step coming up. I don't know if it's next or if it's the one after the next one to um make new considerations for how accessibility checker is shown on the front. We currently have our front-end highlighter that was made uh several years ago and we are looking at a a fe a future new **[19:16]** tool to um uh expose and manage accessibility issues on the front end in in a in a much better way. Um I have not used bricks builder but um I would imagine that does is it a I'm not sure if it's a back end or a front end builder. >> So bricks is a front endish type of builder. So we will not be able to deploy this exact permutation of this **[19:47]** sidebar on bricks. If you want to use this sidebar, you will need to use the classic editor or the block editor. Um, however, as Steve was saying, we have future plans to bring all of these new features, which you know, we maybe haven't yet spoke about, but we will be bringing all those features to a new front end highlighter, moderator, scanner system. **[20:17]** >> Yeah. So, does do you know, William, if the front-end highlighter works with bricks? >> So, when I looked at this with Daniel previously, so hi Daniel. Um, it it works okay for highlighting issues, but the rescan doesn't work so well with bricks because of its overlayesque. >> No. Okay. >> system. So it would be able to detect issues, but it also detects bricks overlay as well. So it doesn't it **[20:49]** doesn't work that as well as it does on just a markup base page, >> right? Yeah, totally. There there are challenges with page builders and we know that like our front-end highlighter works quite well with Elementor. um doesn't seem to conflict with Elementor's panels a whole bunch. And um we're we're working, you know, we're working with Kevin over at Etch to make sure that our front-end highlighter is working uh with Etch and we we got we've **[21:19]** got some uh updates coming in regards to that. Uh so yeah, so we're looking what this future thing that we haven't really scoped out a whole bunch and we haven't really talked about a lot publicly. We are looking for a solution that that solves the front-end exposure of issues um for you know for anything regardless of what page builder or what platform it's running and maybe even if it's not **[21:50]** running WordPress. So, um, so thanks for your question, Daniel. Daniel's got a followup. Yeah. Yeah. Yeah. This is a great point. I'm gonna I'm gonna pull this up. So Daniel said, "I asked about uh Bricks not only because I use it because its user base tends to care about accessibility more than the users of **[22:22]** some other builders." You know, that's a great point, uh, Daniel, and we should definitely, uh, pull up bricks, William. We should put a put that on our list to do some testing on to make sure that our front-end highlighter is compatible and that we can help that community and support that community in making their websites accessible. >> Yeah, for sure. Actually, as I said, I have spoken with Daniel before and maybe, you know, maybe we could actually sync up again and find out more from an actual user what the needs are. So, I **[22:54]** might email you back on that thread, Daniel, and we can connect and figure out the best way to make sure BRIX is supported fully. >> Yeah. Awesome. Cool. Sounds great. Cool. So, back to the uh the status here. Um, so that's I was kind of explaining like the the difference between errors and warnings. They're now problems and needs review. And we're going to talk a little bit more about severity in a little bit. If you use our pro plugin, you kind of **[23:24]** know about our severity flags that we added a few versions back. Um, but we'll talk about that here in a minute. And then, yeah, so reading level, not much has changed in regards to reading level here. The way we display it there. I'm going to talk about the icons here in a minute, William, because that's really important. >> Yep. and and then like William said, past checks has been um kind of brought down in priority. It doesn't have a big circle. Now, we have maintained this in the the metab box and we'll talk about that when we get to the **[23:55]** metab box and I'll tell you why we're maintaining the previous kind of layout for that. But uh pass checks has been brought down in priority and we had a lot of internal discussion about this because pass checks just it it just runs a calculation on how many of our rules um is this post passing and then it gives you a percentage of past. And previously it used color to indicate good when there could be a whole lot of **[24:26]** reasons not to necessarily uh convey good. Um because there's issues when you're scanning a page to where if a rule doesn't apply to that page, you're you're still getting credit for that rule passing. >> Yeah. And I do want to call that out actually specifically. So in we did change this. It used to be called pass tests and we have changed it to pass checks but we had a lot of back and forth about even the term on this because the this is 81% are not **[24:58]** applicable to this content. It doesn't mean they're passed really it means that they have not failed >> and there there is a big difference there. I think arguably a more important metric is 19% of the checks did not pass here. Right. >> And you know, maybe in the future we'll offer a toggle to flip this number around for person like >> for personal whichever one someone might want. I **[25:29]** actually would prefer this to be inverted. >> Yeah. Yeah. Totally. I I I do too. And and what that does is it kind of obscures away whether or not the rule passed because an issue existed on the page and it was was accessible. was done right or it didn't exist on the page and the rule didn't apply. Um so so if you inverse it and you focus on only what failed, you're only looking at, you know, where you need to improve. And yeah, we really went back and forth **[26:00]** about this. Uh like I I was calling it coverage in an early iteration of this and and I will like side I will tag on here. Uh we did kind of go through a full design phase on this which we don't do a lot uh and we haven't done a lot in a while but um and a lot of people may not not know this. I'm not just the CTO of Equalized Digital. I'm not just a developer but I actually went to college to be a designer. So, I have these all **[26:30]** these weird weird skill sets that uh kind of work together and really I don't really flex the design stuff much anymore, but uh as of building this I did and and really brought in in that convergence between the design and the development into how we can present a a much better uh uh visual UI and a much better user experience because what We're trying to do an accessibility checker. We're not **[27:00]** just trying to make something pretty and and something eye-catching. We're trying to surface data and expose it to you to get you to take take action and and and to not give confusion to you or cognitive overload as well because like accessibility at first can be like, oh, I got I got 12 problems or I got 16 needs review. I don't know what to do. Um, so, so we're trying to surface this stuff. Say, hey, you need to take action, but here's the most important **[27:31]** thing to take action on, right? And, and not overloads. So, I want to talk about the icons a little bit. So, before we were kind of using these big washes of blocks of color uh, to convey whether or not something was good or bad, right? Green or red, right? um we've taken a step back and we've kind of changed how we're using color, how we're using shape and and and **[28:01]** how we're using icons to convey meaning. Uh so we've removed those big deep uh colors and and we've opted for icons to to handle that. So before uh so like accessibility status. So right now you can see I have 12 problems. If you look at the the top accordion here so at the top level we're **[28:32]** surfacing whether or not you need to open this accordion. If everything was passed this would be this would be a green box with a check in it. So we we have for something that needs attention we have a circle the the uh is that information icon is that what or alert icon >> it's the exclamation mark >> exclamation thanks so we have like a red circle with an explanation and then if it's something that is a little less **[29:04]** critical than that we have a triangle with an explanation in it. So the explanation on both of those signifies that at some level they're the same, but the triangle and it being orange signifies that it's a little less it's slightly less of a of a huge concern. And then and then we have a square checkbox that's green if something's **[29:36]** good. So we're can we're conveying meaning with with with color icon and shape um not just colors. >> Yeah. The the shape indicator here meant made an awful lot of difference for me actually. I didn't realize previously how if everything was a circle then nothing was a notice bubble >> as such. Now we we do have the shapes and it so everything is signified by color and shape and in some cases also **[30:08]** the icon that's inside of the shape but we are no longer just using color or just using an icon. It's always both. >> Yeah. Yeah. Yeah. So yeah we have Troy joining us and uh >> Hey Troy. How's it going? Uh said Troy said, "You guys did one heck of a great job fitting a lot of important data into a small space. Very clean. Uh fits into the overall look of core as well." Yeah, **[30:39]** thanks Troy. And and and I do want to >> It was not easy. And and you know we went through many rounds of reduction and even from design what we ended up with in design over to code we we still have pulled pulled things out and we have to keep asking ourselves does removing this actually you know convey less meaning or or does this act it actually cause the user to have a worse **[31:11]** experience by removing it. If not, we should just remove it, move on. We can explain these things in documentation in other places. And uh and it just it it's it's hard. It's hard too for a mature plugin that's been around for 5 years. Uh for somebody, you know, and we use our plugin in our own remediations. And when you're used to where things are, what things are called, and and when you start pulling things out, people on the team can start to be like, "Oh, well, where'd this go? Why why isn't this here?" And **[31:42]** >> yeah, but we are about to come up to something that I was very much against removing until I realized I didn't actually use it. I just liked it to be there. >> Yeah. I don't know what that is, but >> I'll point it out when we get there. >> Okay. So, to finish up on the status panel, I I want to talk about the pass check icon a little bit. So the pass check icon, you'll notice before in the metab box the p the pass check would be green and it was almost always like if **[32:12]** it was 81% it was green. If it was 10% it was green. Almost always saying good job, good job. Especially if those didn't if those those checks didn't apply then you're getting green and a thumb, you know, like a good a job well done, a pat on the back for something you didn't do. And uh so with some of the ambiguity around what pass checks is trying to convey, we've change the icon to anformational icon. And uh **[32:45]** and and and that is to to say, hey, this isformational. you should look at this and and pay attention to it, but we're not going to make uh any kind of assumption on whether or not this is green good or red bad. So, well, looks like our fearless CEO has joined the party. Welcome to the party, Amber. Glad to have you. >> Yeah, I think the information icon is just also a signifier of this is supplementary. This does not really **[33:16]** impact your decision. Yeah, >> but this is here when you need it. So you'll see that is on the past checks, but you'll also notice that it is on dismissed issues as well, >> right? >> We will explain when we get to dismiss issues why we think they're onlyformational, >> right? Cool. So, a feature added to the stat the accessibility status previously, the summary is is and oddly enough, this is something that's been requested from many people that have used the plugin is in the summary, the **[33:48]** old summary tab, they they want to be able to click on it and get to the stuff. So, we've added that functionality, something that seems very simple, but uh so what I'll do is I'll show you like if you're looking at problems and you click on a problem, it automatically opens the accessibility analysis and goes to the problems tab and opens it up. So, that brings us to the next tab, the accessibility analysis. In the metab box, this was called the details panel. And um we we're calling it analysis because we **[34:20]** want to convey that hey these these are the things that we've scanned that you need to take action on and and that's all that's in here, right? We're not mixing in, you know, remediation artifacts and things like that. So, so when looking at this panel like at the at the top level, you can see that we have the the the explanation icon that's red showing that there are issues in here that are problems. If there were no problems in the accessibility analysis and only needs review, that **[34:52]** icon would be the the explanation uh triangle that is orange. Um so and and we are now at the top level we are surfacing the number of total issues. So before you open a panel you can kind of see uh I can see hey there's some there's some problems in here I need to review and there's 28 total pro issues in here. Cool. So in problems we now have these **[35:24]** tabs which William talked about a little bit. These are core components that we found to be fairly accessible and we were very appreciative of that. Um, you can see I have 12 problems and I have 16 needs reviews. So, we've separated these out. Why why do we separate them out, William? >> Well, problems are something that, you know, you need to do something about, but needs review are things you Well, you need to review them. We we are uncertain and we will need a human eye **[35:55]** to take a look and you know you they're two quite different workflows. Anything that is in problem needs a remediation effort but anything that in needs review needs to be looked at and it might not have a remediation effort required. It might actually just be able to be dismissed. >> Yeah. >> It needs a human to to look at it but the these are two separate workflows and you don't really need the same information. right >> at the same time when you're tackling either. >> Yeah. So, this goes back to like the **[36:25]** cognitive load, right? We're we're we're making two folders here. We're saying, "Hey, look at these first, but know that they're equal. They live on the same plane here, right? So we do have explanation icons for both problems and needs review um that are slightly different but at the same time we're surfacing them kind of the same because we don't really know because the needs review requires a human audit and >> and some of the estras in needs review might actually be more problematic than **[36:57]** problems >> or more know that yet. >> Yeah. Or more critical. Yeah, totally. So um so now if we go down a level we look at the the the um the rule the individual rules. So we're still grouping issues into rules like we did in the old metab box. Um and we can see that I have ambiguous anchor text. I have three of those and that it's critical. And we are now ordering these in critical criticality. So the most **[37:28]** critical will be at the top and the least at the bottom. So again, putting these in the separate folders and then then collating these folders folders to surface the the items that need the greatest attention and uh so I will go into the ambiguous anchor text according so you see the issues now. So this was the next uh really difficult UI um UI UX change that we **[38:03]** made and and we evaluated a lot of other accessibility tools to see how they handle this and and a lot of them handle it in the same fashion. But previously in the old metab box when you would open this up you would actually see the code snippet right so um you'd open it up you'd see the affected code and then you'd see a couple other action items to the right and so we're in a sidebar that's you know whatever 245 pixels at most right and we have to show a huge **[38:36]** code snippet >> the code snippet is the thing I was talking about earlier that I thought I was going to miss a lot. >> Yeah. >> And it turns out not so much. I only ever looked at it on the front end where I could find that markup snippet. >> Yeah. >> Can't find it here. >> Well, and this is this is where like UI and UX get real complicated because, you know, William's experience on how he interacts with the plugin is different than Amber's experience with the plugin and how she interacts with it. And it's **[39:08]** different than the way I interact with it. And and it may be different for like if I looked in the old metab box and I pulled it open and I see this affected code and it's a big huge block of code. I'm a developer. Amber Amber's a power user uh slashdeveloper and and she can kind of look at that code and I can look at that code and William can look at that code and we can kind of you know we can you know it's like the Matrix when you see the letters going down the screen you can see **[39:38]** pictures. We can kind of tell what that is and where it is on the page and oh and yeah so Amber says yeah I want I want the code snippet ASAP. >> I thought I wanted the code snippet as well. >> I didn't. >> But Amber >> this was hard for me. I think I fell in the middle of where you and Amber are and I I fell in the I fell into I want it in the sidebar, but I know that from **[40:09]** a UI perspective, it just can't happen. And >> well, I think we reached a fairly good compromise on where it could live. >> Yep. So when we go to these issues, so you're see we have an issue number. So this is basically a a database ID. Every issue gets a unique number. And then we do have >> hopefully most users have less numbers than this one, which is what 300,000. **[40:40]** >> Well, this is my local uh site copy. And I will say that this has probably been around for numerous years. Um, and test and testing the accessibility checker here. Um, so most people don't have 300,000 plus issues. So, we have that and it links and we're we'll show you that in a minute. But then we have this ellipses menu to the right, which is our issue actions. If I click on that, this is where the actions live. I can view this **[41:11]** on page, I can show the code, or I can dismiss the issue. So, if I click view on page, and now I'm super zoomed in, so this may look a little funny, but actually it doesn't look that bad. Um, so it does our normal it highlights it on the front end and you can get all the information on the front end you want. Like William said, he looks at this code box here on the front front end to show the code. >> And we're trying to like make the plugin more nondeveloper friendly. So that this code snippets **[41:43]** here for power users, ones that really want to get into it and maybe for future use, uh, being able to modify this. But uh we we're trying to make this a little more user friendly for nontechnical people. So those are some of the actions you can take and and let's go ahead and open up the modal. >> Well, I do want to call it there's one additional action which you do not see because we don't have anything for ambiguous anchor text, but there is also a fix action that can appear on some of **[42:15]** the issues. If we have an automated fix for it, you're not going to see one here. you um >> link opens new window >> link open new window. >> Yeah, >> there is a fix for this. So >> yeah, so there is an apply fix and the these are the same actions that you you would get in the metab box. >> Correct. >> So um so let me jump back over to problem to that problem. I'm going to click on the issue and now we're presented with this new modal. And so in **[42:47]** an effort to try to make the sidebar live on, you know, the side and your content side by side, but we still want to be able to expose a lot of data to you about that issue. And and we can't fit it all in the sidebar there. So we needed a place to put it. So we've introduced this new issue single issue modal uh which is a modal that shows the issue ID at the top. We have a future plan to maybe allow this issue title to be edited. Um, and then below we have **[43:21]** our WIKAG information that we introduced in the pro plugin uh several a few versions back. Um, Amber went through and did a amazing amount of work on surfacing, you know, WIKAD criterion inside the plugin and we show that on our open issues page. Um, but that has not been available for free users until now. Um, so we're now surfacing that here. I do have the pro plugin installed um, and activated. So, **[43:54]** if the pro plugin is installed and activated, you do get this uh, toggle to show explanation. When you open that up, it tells you, you know, why this issue matters, how to fix it, and then a link over to our documentation uh for much more inde uh detailed uh instructions on how to fix these issues. >> Yeah. And if you're a free user, you have that link that takes you to the detailed documentation. You don't miss out on being able to access that **[44:24]** information. for pro users. It's just readily available and as such we can show it here in this box, >> right? >> Format. >> Yep. >> But that all that information is available to everyone. You just have to visit the website to get the the quick how to fix. >> Yeah. So, we've just what we've done is we've surfaced this information that's already in the open issues to pro users right here in the same panel. And like William said, if you're a free user, this link actually just shows right here. So you have access to the same **[44:55]** information. So um before I keep going down the content here, I want to look at the the sidebar here. So we have a sidebar where we show the type which we know is a problem because we were just in the problems tab and we show the severity which is critical and the landmark which is main and this is a link. So, if I click main, this jumps over and highlights the the landmark. This was added a few versions **[45:25]** back in in the plug-in as well. Um, and then we have our view on page link that was in that action that was in that action menu as well. So, we can view this on the front end if we would like. So, back to the main content. William, you want to talk about? >> Yeah. So here we have the affected code which is what I really thought I would miss in the sidebar. It turns out I don't miss it as much. However, we also have code m available from WordPress **[45:58]** which allows us to do syntax highlighting. So in the previous old metab box, this would just be a code box and or inside the code tag or pre-tag and it would just be a gray background, black text. Now we have full syntax highlighting. So regardless of what type of markup this is, it should actually be easier to identify the important aspects of this. For a developer, the syntax highlighting may not be very useful for **[46:29]** a lot of our users, but for me, it's very nice. >> Yeah. Yeah. >> Yeah. It's pretty. >> We got a question asked. You want to read this one? >> Yes. So, love the references to WIKG docs. Are you guys maintaining anything that helps generate the data in the popover or is that all being pulled from an official endpoint somewhere? So, it turns out there is not an official endpoint from WIKG and this is **[47:02]** self-maintained information. Some of it is mostly readily available from WIKG, but a few of the aspects of it like how to fix and some of the references that are available for pro users are maintained by us and mostly maintained by Amber. Thanks, not by me. >> Yeah. Yeah. Yeah. And you know that's interesting you bring this up Troy that this was actually something that William and I were just talking about earlier today because like I said we are we are **[47:34]** working on uh you know expanding accessibility checker uh into different applications and services and and that information is is is actually not available in a public API and we actually were discussing about building our own API to handle that. So great question. >> So cool. So that's something in the **[48:05]** works. And the next one here, William. >> Yeah. So the dismiss issue. Previously you you could ignore an issue. We no longer use the term ignore because we actually are not ignoring it's an issue. We're dismissing it after careful consideration. We hope um and previously you could only comment and that was it. Now there is also some options here that you can flag your issue as the reason you've dismissed it. So you might think it's a false positive which could happen **[48:37]** especially in niche review type issues. Um you've maybe remediated it and it will go away next time you scan or you've confirmed it's accessible because some niche review items we just don't know whether they're problematic. For example, if we detect a slider is present, we will flag that as a nature view item, but you might actually have a fully accessible SL slider, which is quite uncommon. So definitely check, but you might have confirmed it's accessible, in which case you can flag it as such when you dismiss this issue. **[49:08]** >> Yeah. Yeah. So a little bit to why we don't say ignore items anymore. Um because one it was always a little awkward to say ignored items or is it ignore items? Like it was always a kind of a weird thing to say. And uh we're trying to think a little bit about the meaning of the terminology that we're using. Like what does ignore mean? Like if it's an accessibility issue and it's been surfaced, why would we ignore it? **[49:41]** like are we ignoring it for a period of time? Are we ignoring it forever? Are we ignoring it because we want our score to go up? Uh you know, are we gaming the system by using the ignore system? And um u what we wanted to do was kind of bring a little bit more of of clarity to why things are being quote unquote ignored. So we we did land on the word dismiss. So you can dismiss it for, you know, for **[50:13]** many many reasons, but it it's it's more actionable. It's I took this action to dismiss it. I'm not just ignoring. I'm ignoring it. Not my problem. Right. And and >> yeah, the term ignored is is almost always used in a negative way and we didn't necessarily want that. Um I will point out some of these reasons here. This might been news to Steve because I haven't mentioned this yet, but I do think there will be a filter introduced over these reasons. So, if users have very specific workflow in their local **[50:44]** sites, they will be able to use a filter to potentially add additional reasons here. >> Yep. >> So, these are the three that we surface for you now, but with a filter, you can probably add more of those in the the not too distant future. Yeah, I'll read those out too just so so anybody listening or that can't see this can have so we have dismiss issue as and we have radios for false positive remediated and confirmed accessible. So um and that is a brand new feature **[51:16]** added in uh to help with remediation. So we have our comment box. Um, this wasn't called comment before, was it called something else? >> Um, I have it up, so let me take a look. It was It was just called comment, but it didn't say it was optional. Oh, >> okay. Yeah. Um, so we have the comment box. You can, you know, go in here and type your comment. And it's kind of cool because it's a component and it expands as you type, right? Like it, um, so it's **[51:47]** a lot more modern feeling. And we did add in uh the ability to do a t a little bit of code formatting. So with bold, italics, and then uh links, you can you can link uh text now. >> Yeah. So personally, I don't see that I would ever have a use for this, but there was a case made that maybe instructions might be left here. So someone might be coming in and doing remediation work and dictating what might need to be done to tackle this **[52:18]** issue. So instructions can be left here for example by someone and you know some basic formatting might be nice for that >> right >> and potentially a developer can come back later on and fix the problem or maybe even the content author can can cycle back and read that comment. >> Yep. Cool. So then below that you can see that we have a button called dismiss issue and that will will dismiss this. I I'll just so everybody on the call can see I'll go ahead and dismiss an issue. **[52:50]** we get a notification that issue uh dismissed successfully and then you can see the comment and and um I must have a I must have a space space in there >> and then uh the reason why and who it was dismissed by and the date and these are things that we had before and I will say that we are running um this is 38 uh accessibility checker version 1.38.0 zero beta 1, right? **[53:22]** >> Yes. >> Okay. So, this is a beta version of the plugin. These features have not released yet. They will come out shortly. Uh the plugin is currently in user testing right now. Um but uh this is a piece that is still being uh worked on and some design and CSS stuff is still being worked on this. Um so I can reopen the issue now that I've uh you know, maybe I accidentally hit the button. And I could reopen it here. But when I go to close the modal, you see that the issue has **[53:54]** been uh dismissed. And it is now it now lives down in dismissed issues. You can see there's four now instead of three. And we returned focus back to the the current rule because that item actually removed. and we didn't think that would make sense to actually move focus back to the dismissed item because we want to keep you in in your remediation. And so ideally, your next thing would be to go back through that list and keep remediating. But that's **[54:27]** not all. There's more to the dismiss issues. William, you want to talk about that? >> Um, yes. So, there's two additional options here in this dropdown. The first one is just uh a nice user friendly feature dismiss and close model, right? It saves you having to make one click. It'll dismiss as soon as it gets a successful result back from the API where the dismiss happens from the model will close and that's just a nice UI ease of use type of thing like quality **[54:58]** of life. Um the other one is dismiss globally. So previously you would not be able to do a global dismiss from this page and this is a pro feature because global ignores are a pro feature or global dismiss as they will be in future. Um so if you're using the pro plugin you can globally dismiss this right from the individual page and that saves you having to go find this issue in the open issues tab or the fasttrack tab. You can just globally dismiss it **[55:30]** right from here. and it has all the same things. Um, globals dismisses don't necessarily have comments assigned. However, now you can add an individual comment here to the issue you're dismissing. It won't propagate to all the dismissed items globally, but it it will on this local issue. >> Yeah. Yep. So, that's a new feature that we've brought. You can uh globally dismiss from the single issues page. Looks like uh we got another question **[56:01]** from Daniel here. Sorry if I missed this earlier. Does the sidebar update errors and counts live as the user edits or only upon saving? It's a great question. It does it live. So if I go here and I dismiss this dismiss and close, it's going to close the modal and you can see it just updated. Um, I do want to make sure that Daniel isn't asking if it updates as you're editing content here because it currently does not add update as you **[56:32]** edit the content yet. It it has to scan a rendered page. So, a save does have to occur, but if you >> modify an issue by a dismiss, >> the numbers reflect immediately in the sidebar or or nearly immediately. >> Um, >> yeah, >> we did skip a feature. So, maybe we can cycle back to that. So if in the title bar here beside accessibility checker, there is actually now um a menu that you can click to scan the page from. **[57:04]** >> So that just did a scan, right? >> It did. And obviously none of the content has changed. So nothing is being reflected as updated. But if you're editing content, you can actually come up here and click that scan button and it will scan a preview >> Yeah. >> of the content prior to needing to save. >> Oh, yeah. Yeah. So, Daniel did confirm that you were right, William. So, this is this is a thing that we can do this. Um, but part of the problem in **[57:38]** doing that is that we don't know what your final save state is going to be. Um, so the way accessibility checker works is like if you're if it's polling like and you know there there's a code term polling if it's like checking every you know 5 seconds to see if there's any content updated or I think that the block editor even dispatches a an edit u you know an edit uh >> an edit event that is yeah um it has a **[58:10]** debounce attached and it is every 5 seconds, I believe. >> Yeah. Yeah. And um we could do that and you could be making changes and this stuff is actually being written to a database. We're not just scanning like a a snapshot and storing it locally. This is all all your issues get saved to a database because they could be managed at a global level. It so if we were doing that, you're you'd be writing to the database and then what if you just closed off that page and didn't save it? **[58:41]** you didn't do a final save. You just closed out and you you know you get that little notice that says are you sure you want to uh you know there's unsaved changes. Are you sure? And you you hit fine and and you go off. We've actually written stuff to the database that's not source the source of truth. So we can do that but it's a little risky. But like William said, we do have what we call sidebar actions at the top where you can rescan the page in in real time and you can actually refresh the content. Do you **[59:12]** want to explain the refresh? >> Yeah. So the refresh action has it probably is a little bit of a niche use case. However, if some for example, if someone is a pro user, they might be ignoring issues from the fasttrack page which won't immediately be reflected in the sidebar. So you might want to refresh the sidebar without resaving your content. Um or also you could have maybe changed the theme of a website in which case you can refresh to make sure the data gets re repulled if things have **[59:44]** if things outside of the editor have changed. >> You might want to refresh the data that is in this sidebar just to make sure that it is always up to date. >> And this final >> Yeah. So this is uh does almost exactly the same as the clear issues button in the old metab box does. It just deletes all the data for the issues on this post and lets it either be rescanned if needed or you know I think there's **[60:14]** limited use again for this clear issues button. We added this to solve a problem that no longer exists. It's a nice to have I think. >> Yeah. And we found that uh you know internally um our own auditors uh like to use this tool from time to time. I I can I can hit uh clear issues just to show you. I hit clear. It says this will clear all issues for this post is saved will be required to trigger a re a fresh scan of the post. Do you want to continue? Yes, I do. So it's going to **[60:46]** go through and it cleared out all of >> So that's interesting. So I need to update that message because you don't actually need to save anymore >> because we have the the the rescan >> rescan. >> So without saving the post, I can now initiate a rescan and now I have all my data back. >> Correct. And you will notice that your numbers have changed because you had dismissed issues that are no longer dismissed. However, if you scroll down, if you had any globally dismissed **[61:17]** issues, >> they would show. You didn't, but they would still be dismissed if they were globally dismissed. >> Right. Right. Cool. So, that is the sidebar actions. And these are helpful to help manage your scan overall. Sometimes you don't want to, like I know if I'm on a client's website and I go into their post and I know it needs a rescan, sometimes I'm nervous to hit the the rescan because I don't know what services or plugins they have attached to a post that trigger when a post **[61:49]** >> don't want to resave their >> Yeah. Is it going to send an email if I resave to like all their users? So it is kind of nice having something exclusive to the accessibility checker to manage that that scan and re rescan. So cool. So that's sidebar actions. We were down in the accessibility analysis panel going through some issues. I think in the modal we need to show something with an image and possibly a fix. **[62:20]** William. >> Yes. So for the fix we can show this. >> Yeah. So I've I've gone to the next tab. Like I said, we've collated problems and needs review out. And if I click on needs review, you can see I have items that need to be manually reviewed by a human auditor to confirm that they are accessible or not accessible. And we have the severity flags here. You can see. And we've ordered the most severe at the top. So, if I click on possible **[62:51]** heading. Oh, that's not what I wanted. I wanted um something with an image. Let's see. Okay. So, just like before, we would try to pull an image out of the code snippet to kind of give you more of an indicator of where this is or what image it is. And so, we're doing that the same here. You can see this is the image. And of course, if this doesn't need alt text, you can you can go ahead and dismiss it. Um I do want to point out here so while **[63:21]** this is you know feature par it's the same almost you can see the image um there has been a slight enhancement here so if you have an issue that might have multiple images in it for example again the slider is present might have six or seven images one for each slide all of those images will actually be available to see in this panel here as opposed to just the first image which is what the old metab box would Right. So, **[63:53]** so I'll just dismiss that because I'm saying it's decorative. It's not, but I just said it was for for demonstration purposes only. So, that's the accessibility panel. So, you can go through and you can see all of your rules and all the issues and go in and uh remediate them and u get those all accessible. and your need to review items uh follows the same pattern. So, we've talked about dismissed issues. **[64:26]** So, like I said, we're we're uncolating dismissed issues from um the analysis because this is this is something that you've that an auditor or a user has taken action on and we want to kind of filter that away. But at the same time, we want the them to still be able to come in and see what has dismissed and maybe review why it was dismissed. Um and for that so since we have the **[64:57]** dismissed as reason now uh when you pull up a this is the same the same uh rule you know the same pattern UI pattern for dismissed issues as the accessibility analysis >> it's the very same component >> um but the dismissed as reason is actually flagged on the issue here. So you can come here and you can see why it was dismissed at just a just a glance um without having to open the modal and go **[65:30]** down here and and read why. But I will show like you don't have to take all those clicks. You can use the action item to reopen the issue and uh brings your focus down to the current place and reopens it. So, and then you can actually review what's here and dismiss it again if if if you like. >> Yeah. And as as far as screen readers go, these notices that are appeared when you dismiss or reopen initial, they get **[66:01]** announced to screen readers as soon as they appear. So, issue reopen successfully will be announced to screen read user if they use that action and end up on this page. So, they don't lose context. Even though we're moving them around, they still get told what just has occurred. >> Yep. So, that will go away. Did we look at fixes? Let's see. Um, >> we did not look at >> say, sorry for the we're jumping around a little bit, but um, let me find one that has a fix. It's probably link opens in a new window. **[66:32]** >> That's the easiest one to showcase. So I could either just open the modal and go to it or I can actually hit the action the issue action items and hit apply fix and that'll open the modal and we'll focus on the fix issue. I'm zoomed in quite a bit so let me zoom out a little bit. >> So this is an interesting issue to showcase fixes because this has two potential fixes in our plug-in. We can either prevent it from opening a new window by removing the target equals **[67:04]** blank or we can add a warning the same as what our new window warning plugin does. It will add a an icon and a label that says for screen reader users that it opens in a new window. So there's two options here. Most issues with effects have only one option, but this one has two. >> Yeah. So if I choose prevent links from opening in a new window. So, I have five of these. These should all go away, right? >> Fingers crossed. You save this. **[67:35]** >> So, I save this. I get a save notification. Once I close the modal, it's going to rescan and they're all gone. >> Correct. >> Beautiful. >> Instantly fixed, unchecked, verified. >> Instantly. The way the access Yeah. The way accessibility works is you apply the fix, it rescans the page, and all your issues go away. So, we're not just applying a fix and hoping for the best because what if our fix actually doesn't work in some circumstance. We're fixing it, rescanning it, and and if it still **[68:06]** is an issue, it will resurface back in. >> Actually, if someone does encounter an issue where they apply a fix and the issue doesn't go away, I would love to hear about it so that I could make sure that >> Yep. >> that exact markup in that case is added to our test suite, which will make sure we actually fix it and keep it fixed. with our automated fixes. That was a lot of times to say fix. >> Yeah. So, um, so that's kind of how the fixes work. They worked that way before, but I **[68:38]** think it it it kind of you can see it in action a little bit here real quick. We we fixed and remediated uh five issues just with a click of a button. Um, so if you're not using the fixes in the plugin, uh, take a look at them. Um, you there's a lot you can do. I mean, I'll pull them up here since we're talking about it. Um, I'm zoomed in a lot. The So, you can see we got a lot lot of fixes in here for fixing things like, **[69:08]** you know, removing tab index and title attributes, forcing underlines, you know, viewport uh changes link like we just went through. So you can see that we toggled block links from opening in a new window and you can see that that's toggled here because this is what we just did on that single post. Now those are at a global level. It does fix it for the whole the whole website. So if you are running pro, you might want to run a fullsight scan after enabling these **[69:39]** um uh block PDF uploads. So, we have some some of these are pro fixes that are available only in our pro plugin. Um, I'm I'd have to disable pro. I'd have to disable pro to tell you which ones, let's see. Um, deactivate accessibility checker pro. So, you can see in the free plugin which ones are pro only. So, block uh PDF uploads, add file size and type to **[70:10]** links, uh add missing page titles, and we did have a previous change log uh all about our fixes. So, you can go back to a pre to the episode, which I'm not sure we'll have that linked in the uh in the show notes and the post that goes out about this change log. So, let me jump back over to my post again. Back to my sidebar. **[70:42]** So, I think that's everything. So, let's go to the final tab here and take a look at readability analysis. So, >> well, I actually do want to point out that now you have a different icon here >> in readability analysis. So, this was This was part of >> it previously was green. >> Yeah. So explain explain why we changed this. >> Yeah. So well well first off I'm going to comment on the fact that this was green earlier and is now **[71:12]** the triangular warning issue rather than the green square because when you deleted all the data about the post, the summary also was removed. So now this is a 12th grade reading level. So, it's got the warning sign because this needs a summary and there is no summary. If you add a summary here that is under a nth grade reading level, the icon will change. >> Yeah, I was more spec specifically talking about why we're using the orange triangle which was warning before uh **[71:44]** rather than the error, the red circle. So it I'll answer my own question but the readability the the reading level is is not necessarily a wikag uh doublea requirement. It um it I think it is at triple level and I um so but we don't currently have a way in the plugin to u define the wickag level that you want to **[72:16]** comply with. If you did uh have a AAA requirement defined in the plug-in or the ability to do that, we would make this red um to to show that it is something of attention. But we changed it to the to the orange triangle explanation to kind of say, hey, this is something you need to notice, take notice of. It's not necessarily like it's a a violation, but uh you need to be aware of it and you should you should **[72:46]** pay some attention to this and and we've just done this in an effort to try to convey meaning a lot better with our icons and our text. So, we can demo this. And this this is how the plug-in has worked for a long time. Um, I thought I had some text somewhere. >> You can probably just grab the first sentence or the first two sentences here to to indicate it. It doesn't look like it's a lot of long **[73:17]** There's a couple of long words, but >> yeah, it's still 12th grade. >> If if you just delete some of the longer words, the sentences will no longer make sense, but you'll get different Well, I'm I'm asking AI for some for some text below a certain grade level. Okay. So, >> yeah, while you're pulling that up, this **[73:47]** is a AAA level success criteria 3.1 five. Um, yeah, comprehension. >> Yeah, cool. So, I added in uh uh text that was below a ninth grade reading level uh as a simplified summary. Um you can see I have this 12th grade reading level text here which is actually Alice in Wonderland. Um **[74:18]** the and and now you can see that we've evaluated your simplified summary and it's below the ninth grade reading level and and you get the green checkbox and the 12th grade reading level of the post now uses the gray or black information icon. Um, we don't turn this to a to a check, a green check, because your initial post is still above **[74:49]** uh the recommended reading level. Um, but the simplified summary actually does bring it into compliance with the the AAA requirement. And you'll see if you if you pull open the accessibility status panel, you can see under that reading level stat that you now have the green checkbox and that it says summary provided. So if I remove that summary and rescan and you don't have to save the post for **[75:20]** this to scan, you can see in the summary the accessibility status that the reading level is said has the warning or the the orange triangle explanation icon and it says summary required. So, um, just doing what we can to surface, uh, where the reading level is in the stats and give you all the tools you need to add a simplified summary to supplement your, uh, post that has a **[75:52]** higher reading grade level. And, uh, that works pretty much like the old metab box. Um, and speaking of the old metab box, I know we're running long here, but >> yeah. So, if you want to swap to my screen, actually, I have both the old one and the new one up with the same data in it in two different windows, so we can do a comparison if you want to go on quick. Oh, but actually, maybe I shared only a **[76:23]** window and I don't I don't have both up. >> Um, >> well, well, you can show yours here. cycle back. So, >> and I I have the other one open. So, this was the the old man box that everybody's very familiar with using. And so, in changing the sidebar, you know, it kind of brought up the conversation. Um, well, we've made a lot of terminology changes, a lot of layout changes, you know, a lot of the way **[76:53]** things are displayed changes. How do we have to keep parody between the two? Like, is the metab box legacy at this point? Um, and it really isn't legacy because the sidebar is only going to work on a on a uh a on a block uh on a Gutenberg block editor compatible website. if they're running classic editor or even if your custom post type is only uh classic editor, you still **[77:26]** need a way to manage the accessibility checker. So, um let's take a take a look at >> So, for me, one of the big differences here is first off, you know, these giant blocks of color, you know, they're this is color for information without any other real nullifier. So, red is bad, green is good, yellow or orange is in the middle, I guess. **[77:57]** >> Mhm. >> But, but yeah, so the these are huge blocks of color with very little data attached. They're they're just numbers, and we have a lot of space here in comparison to the amount of space that's in the sidebar. But, you know, these these look different and they also use different terms as you'll see in a second. But this is the classic box that everyone is used to seeing. >> Mhm. >> And this blue icon and all the other ones being white annoys me. The blue **[78:27]** icon on the warnings panel. >> Yeah. >> White white icon doesn't pass >> color contrast. Yeah. >> So, uh so Troy has another question here. Um he says that uh has there been any consideration given to adding any of this to templates? Say if I were to show templates while editing content but my template had an error. I'm going to make an assumption assumption that you're talking about uh full-sight editing templates. **[78:59]** Is that correct, Troy? There has been some consideration given to the full-sight editing and how we can implement the accessibility checker on uh you know like template parts. Yes, that's exact. Yeah. Yeah. So we we have internally talked about this. We I think there actually is an issue open in our GitHub in regard to this on how in the full site editor when you're when you're **[79:30]** modifying a a template part or like a header footer how we can run accessibility checker just on on that template part. And um last year we introduced uh scanning of custom post types and taxonomies. So we now have a mechanism to store uh data in what we call a virtual custom post type and um we have virtual custom post type u there's like a taxonomy that goes along with this is a virtual custom **[80:00]** post type taxonomy these are taxonomy taxonomies and custom post types used inside of accessibility checker to to give the same feel to things that aren't actual post and I think we can extend that to to fullsight editing parts, right, William? >> Yes. So, it it's not trivial, but is absolutely feasible that we will be able to use the features we introduced for archive scans and taxonomy scans to be **[80:31]** able to be applied to template parts as well. I did initially do some pre-scoping of that, but it wasn't feasible for initial release, but it absolutely is possible to scan template parts individually. um and potentially propagate those exact results from the template parts through to pages which contain those templates. >> Yep, it's a great it's a great question, Troy. Thanks. So, we have another one from uh Daniel. You want to read this one? **[81:01]** >> Yeah. So, Daniel asked, "What will this update do to previously ignored DMs? Will there be a way for us to go through and mark them as one of the three?" So the only way you can do that is to und dismiss the item and then redismiss it with an item on it. There is no backporting of the labels currently. I'm going to take note of that because maybe we do want to add a migration that allows people to customize that if they can write a filter. M **[81:33]** >> um but yeah, currently you would have to un ignore and then redismiss the issue to get one of the reasons applied. >> Yeah. So since you brought it up, Troy, I think we can or sorry Daniel, I think we can um we can show that. So you do have a mechanism. So, like if I have a dismissed issue here, um, and we're jumping into the the new modified metab box here a little bit, **[82:04]** but um, some things are the same, but you can see here that that dismissed issue had has a a false positive. You can reopen it like your your your issue will your issue will show it just these won't be selected, right, William? >> Correct. These will be empty by default and it will be disabled while it is dismissed but as soon as you reopen it you'll be able to edit. >> You can choose it but you do have to do **[82:34]** it at on a per basis because this is a new feature. So it's like a moving forward feature. There's not >> I actually do think I will provide a WP CLI command for backporting these. I'm going to probably build that today. >> Cool. That'd be awesome. We'll make a make a make a card in our in linear for you for in our in GitHub for you and you can track the progress of that. Um, so cool. So that jumps us **[83:05]** into and and uh Troy does have an AI question here and and William and I uh are big AI geeks, but we're a little bit we're big we're a little bit uh realistic about AI, too. We use it a lot and we're actually trying to to lean on it as much as we can to make our our small team operate as quickly and and bigger than the size we actually are. But we can talk about this. We can **[83:36]** sidebar on this and jump into the metab box. But Roy said, "Nice. I was curious as I expected with AI building more themes, we will see more A1Y issues and templates." So this is a this is a really interesting question because um you could go both ways with it. Like you could say arguably that the accessibility might be better. >> In some cases I have found actually that the especially when we were **[84:06]** transitioning our PHP rules to JavaScript rules so we could scan everything on the front end. Um, we have some AI code review tools, Code Rabbit specifically, that was incredibly insightful about missteps with accessibility messes that the old PHP rules might have not accounted for all edge cases. And, you know, if if your codebase or the prompts ask for accessible content, I I actually think **[84:39]** the AI is better than average at producing accessible output. It is um >> surprisingly good sometimes at recognizing labels or missing labels and also keyboard handlers if you add a link that's not a button. Code rabbit did shout at me one time that I didn't add the space bar handler. I mean it was correct. I missed it. And I actually think the AI can sometimes do **[85:12]** good reviews of code that has I don't want to say bad code, but code that people forgot a thing. >> I often forget. The AI can sometimes catch you. But it it can go the opposite way. If you're moving incredibly quickly, you just want it finished. >> The AI might just drop you a chunk of markup and it could be horribly inaccessible. >> Yeah. I mean, I think that's a whole the whole breakdown on the methodology around the application of AI and what we do, right? Sure, there's the crowd **[85:44]** that's going to try to capitalize off of it just because it can do stuff fast and they don't even have to think about it or review it. And I think the way that like we use it is we're we're trying to use it to make the software better. the there there is a lot of conversation internally in our company whether or not the AI AI is making us faster. Um but we can say that it is making us better. It is making the software better. It is catching bugs. It is catching accessibility issues before it **[86:16]** goes out. Um so it's just better tooling to help us make better software. We're not necessarily trying to just turn out slop to so we can release something. Um, you know, which that that may be the crowd that gets in a little bit of trouble with the accessibility there. But I will say like uh if those template parts that are being made in a full site uh in the full site editor uh if those template parts are used on the front end of the website they're they're going to be scanned by accessibility checker and **[86:48]** they're going to be exposed on the page and which which they live. If it's if your homepage gets scanned it's going to surface as a global issue, right? And uh so we're still catching those, but it will it would be a great enhancement for the accessibility checker to actually expose those issues in the back end while while you're editing those template parts because those template parts, you could be adding links and you could be adding images and if you're not adding alt text or you you know you're **[87:18]** you're making ambiguous text inside your links, we could expose it there. So I think that's a a great idea. Um, we do have one more question. I guess we we're very much past time, so we need to wrap up soon, but we do have another question from Daniel. He asked, "For pages not in the block editor, will the old metab boxes remain available as is for now?" And the answer to that loosely is yes. However, they also have had almost all of the enhancements we created for the sidebar backported and **[87:50]** they've had a visual refresh as well. But those me the classic mailbox is not going away probably ever. People who use classic editor or any non-block based editor will always need that classic mailbox. So >> yeah, >> it will be there. >> So let's since we're running short on time, let's kind of do a lightning round on on the metab box and what we've done to kind of bring it in parody with the the sidebar. So the metabox we've tried to keep it familiar **[88:22]** but but update the UI and the design to kind of match the sidebar. So there are some things that we kind of left that we removed in the sidebar as far as like contrast problems. And these are things that we may modify in in you know uh future releases to make these even more in parody with each other. Um, but we didn't want to make the metab box such a huge uh change that it was alarming. Now, not having the colors in here the way they were is kind of alarming. This is a much more uh simplified kind of **[88:54]** blank white clean look, but we wanted to bring in the same iconography that we used in the sidebar to convey the same the same meaning here. Um so this is the what was previously this the summary panel which is now the accessibility status panel. Um uh like like we said we talked a lot about the past checks which used to be called past tests and this progress bar. Um we have left the progress bar for now to kind of keep that familiarity but we've we've changed **[89:26]** the color to more of a neutral blue so we're not making a a big assumption on you know green good bad right. Um I don't know if there's anything else on here that major that we've changed. Anything you want to comment on, William? >> Just the terminology changes in the right hand side. It is problems and needs review and dismissed now. They're not issues, warnings ignored. >> So we did update that. And as you said, the iconography, >> yeah, >> circles with exclamation marks, squares with X, triangles, **[89:58]** >> it's in sync. >> Cool. So on the accessibility analysis panel which was previously the details panel um the updates that have been made here oh let me collapse this down. Um so the updates that have been made here again is pulling in the iconography. Um we used to have the count in a little bubble that was a color over here. So we've brought in the iconography with the same coloring and we've moved the count to the to the back of the the **[90:29]** rule. Um so uh to bring it exactly in line with the way that the sidebar displays the count of issues, we've added in the severity and we've updated the ordering to order by severity in in this panel. Um so we have a new flag here. This was you know like I said something that was introduced in the pro plugin last year and we are now surfacing severity throughout the plugin. And I think that's all the updates **[90:59]** there. If I open up an issue um and we we just talked about this, you want to just summarize it. >> So we brought the dismiss reason over to this the individual dismisses and the the single a single issue for each of the meta boxes. You can now use the dismiss reasons. This was a new feature specifically for the sidebar, but we backported it here. So you don't lose this feature if you do not use the new sidebar. You still have access to this. **[91:30]** >> Yep. Cool. So that is some of the changes to to the accessibility analysis panel. And then finally the readability analysis panel which was previously just readability. Um, we've updated this with the same iconography from the the sidebar just so again these match up and there's no confusion going back and forth. We've removed colors **[92:02]** the the the grade level used to switch between red and green based on if it's passing or not and we have removed that and we're allowing the iconography to to drive the uh urgency of that. Um, but other than that, I think just some terminology updates and some buttonup label updates is about all we've changed there. So, that is a quick overview of the new **[92:35]** accessibility uh the new accessibility checker sidebar and our first iteration on new UI enhancements. Do we have any other questions before we go, William? Let's see. I >> don't see any new questions come in. >> Although I appreciate everyone asking questions and being around today. >> Yeah. Yeah. Makes it more conversational. See, Troy said, "I've had some success in guiding AI design to fix, but there's part of me that knows that some folks **[93:07]** won't think to do that." Yes, AI is a great tool. And like uh if if you have the knowledge already like of accessibility or software engineering the AI becomes a superpower and um but again in the wrong hands it can kind of create what we call slop. Um so it's a great observation. You got anything to add to that William? >> No I think that is absolutely on the **[93:39]** head. If if you don't know what to ask the AI, then you're not going to know what to value when it gives you a back. So So it's the same. I I guess we are somewhat biased in that sense that we ask things differently to what an average person might. >> Yeah. >> And that could be the reason why we get okay results for accessibility from the AI. >> Yeah. Yeah. Yeah. Amber says, um, I agree. You get better output if you know **[94:10]** how to prompt it. It's totally true. And and like even in the discussion that William and I were having a couple weeks ago or whatever, I was I was making some quick comment about like, you know, AI, why can't you get it to do this? And like it does it great for me, right? like or not him but like just an observation on people's you us using using uh AI and and then William's like I don't think you know this but you **[94:40]** prompt a lot different than probably a lot of other people. So >> yes >> so there's probably a little bit of I'm going to coin a term William I'm going to copyright it after this but I'm gonna copyright it after this. I got to make an expose about this cuz I'll get all kinds of but uh prompt bias, right? Like >> I think that's very very much real. I write prompts in a very specific way that encourages it to be quite verbose sometimes with **[95:10]** comments. And I've seen people write produce a lot of AI code that contains zero comments at all. I think everyone does have a bit of a bias towards what they like to write their code like and that extends into how they ask the AI to produce the code as well. >> Right. Well, and you ask questions like you you you ask questions to answers that you already know because you want to see what it does. >> Yeah. Well, it's always good to get **[95:41]** alternative perspectives. That's sometimes the AI can be the other pair of eyes, >> right? So cool. Well, one of these days we'll have to do uh just a a big WordPress AI accessibility live stream and go real deep on this AI stuff and how we're using it and how it can help uh with accessibility and you know just development in general. um and remediating your website like uh we do a **[96:11]** lot of remediations at Equalized Digital and uh our our remediations are are definitely um going a lot quicker uh with the use of AI and um when we're fixing things in like page builders and stuff like that, there's a the AI can really assist us in that and and the net then I don't we don't necessarily get a a a boost or a huge uh win internally for us, but the client does we can go **[96:43]** further on the website with with the client's aotted budget. So >> yeah, there there is quite a lot of like you know we talked earlier on about tabs and how tabs need to be arrow key usable and that's actually a misstep that most people who build tabs forget. um you know you you should use arrow keys to navigate through a set of tabs and the amount of code that's required to do that is actually quite a lot >> and there's no out ofthe-box package to **[97:14]** do that but you can quite easily ask the AI and explain the requirements and the AI can look at the code on the page and work out the exact selectors that need to be applied to the right items and you're still telling it what needs done but it can hype faster than you can. And that's where the speed acceleration comes from. >> Yeah. Cool. Well, I think that wraps this episode. This one was a long one. Um, but I'm I you know, I'm so appreciative of of you all joining us **[97:46]** and listening in and adding uh conversation and questions. And u look for these new features to come out in the the next release of accessibility checker that will hopefully be out in the next week or so. And uh we look forward to seeing you on the next uh live stream. >> Thanks everyone. See you later. See you.