Accessibility is essential in 2026 - CourtneyR.dev's 2nd Brain

Accessibility is essential in 2026 ![rw-book-cover](https://img.youtube.com/vi/CJLMe1UJrKM/maxresdefault.jpg) > [!note]+ Document Notes > --- > tags: #accessibility #wordpress #inclusive-design #block-editor #ai-readiness #seo #enterprise > author: Rian Rietveld > source: WordPress Event/Conference > reference: https://www.youtube.com/watch?v=CJLMe1UJrKM > date created: 2024-12-28 10:30 > --- > # 🏷️ Title: Accessibility is essential in 2026 > ## 🧰 Action Inbox > - [H1] Train your entire team on accessibility fundamentals — this is the highest ROI investment #accessibility #training > - [H2] Review and test all WordPress blocks for accessibility compliance — table block has known issues #block-editor #testing > - [H3] Contribute to WP accessibility knowledge base documentation project — wpaccessibility.org #contribution #documentation > ## 🧭 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 > - [WP Accessibility Knowledge Base](https://wpaccessibility.org) > - [WordPress Accessibility Team GitHub](https://github.com/WPaccessibility) > - [Click-Away Pound Survey](https://click-away.co.uk/capreport19/) > ## 📝 Summary > - WordPress accessibility consultant Rian Rietveld discusses the current state and future of accessibility in WordPress, emphasizing that accessibility is both a business requirement and revenue opportunity > - WordPress core and default themes are accessible out-of-the-box, but plugins and blocks can compromise accessibility > - The WP Accessibility Knowledge Base project aims to consolidate scattered documentation into a single source of truth > - Full Site Editing and the Block Editor present opportunities for accessible component-based design, but require vigilant testing > - Accessible markup benefits both assistive technology users and AI agents, making accessibility an AI-readiness strategy > - Training teams on accessibility fundamentals provides the highest return on investment for organizations > ## 📖 Main Content > Rian Rietveld, with over 25 years of experience in accessibility consulting, presents accessibility as essential for WordPress sites in 2026. She defines accessibility as making websites workable and usable for as many people as possible across different devices, emphasizing both ethical and business imperatives. > The current WordPress accessibility landscape is mixed: core WordPress and default themes are accessible, but the ecosystem's extensibility means plugins and blocks can undermine accessibility. This creates a critical dependency on plugin developers and block creators to maintain accessibility standards. > Rietveld leads the WP Accessibility Knowledge Base project, addressing the scattered and outdated state of WordPress accessibility documentation. The initiative consolidates information for designers, developers, content creators, and compliance professionals into a single authoritative resource at wpaccessibility.org, with plans to integrate into WordPress's developer documentation. > Full Site Editing presents both opportunities and challenges. Component-based design enables accessible building blocks, but requires each component to be properly implemented. Some blocks like tables still have significant accessibility issues, creating a need for curated lists of accessible blocks and components. > The discussion connects accessibility to AI readiness, noting that structured, semantic markup required for accessibility also enables machine parsing by AI agents. This positions accessibility as both an inclusive design strategy and a technical preparation for AI-driven content consumption. > ## 🗒️ Notes > #### ⏱️ [00:00](https://youtu.be/CJLMe1UJrKM?t=0) — [H1] Introduction and Context Setting > - Key idea: Accessibility is both a business requirement and opportunity for better user experiences > - Evidence: "We already know accessibility is a business requirement but it's also an opportunity to create better experiences for everybody on the web" > #### ⏱️ [02:30](https://youtu.be/CJLMe1UJrKM?t=150) — [H2] Defining Web Accessibility > - Key idea: Accessibility means making websites workable for as many people as possible across all devices > - Evidence: "Accessibility is making a website or a web shop workable and usable for as many people as possible and also on all kind of different devices" > #### ⏱️ [03:15](https://youtu.be/CJLMe1UJrKM?t=195) — [H1] WordPress Accessibility State Assessment > - Key idea: Core WordPress is accessible but plugins and blocks can compromise accessibility > - Evidence: "If you use out of the box WordPress and use a default theme, those are all accessible. But if you add plugins or add blocks that are not really accessible, then you can ruin everything" > #### ⏱️ [04:30](https://youtu.be/CJLMe1UJrKM?t=270) — [H1] WP Accessibility Knowledge Base Project Origins > - Key idea: WordPress accessibility documentation was scattered, outdated, and duplicated across multiple locations > - Evidence: "I read through all the documentation there is and it was really scattered around the place all dated duplicate content content that was not really true" > #### ⏱️ [06:00](https://youtu.be/CJLMe1UJrKM?t=360) — [H2] Knowledge Base Solution and Roadmap > - Key idea: Creating a centralized accessibility documentation hub at wpaccessibility.org for all stakeholder types > - Evidence: "We created a website wpaccessibility.org to start writing and we are at the moment the website is ready and we are putting in documentation" > #### ⏱️ [07:45](https://youtu.be/CJLMe1UJrKM?t=465) — [H3] Community Contribution Opportunities > - Key idea: The project welcomes contributions through GitHub repository and community feedback > - Evidence: "Go to the website there is there's a section about this documentation and there you can find a section about how to contribute" > #### ⏱️ [09:00](https://youtu.be/CJLMe1UJrKM?t=540) — [H1] Full Site Editing Accessibility Opportunities > - Key idea: Component-based design in Full Site Editing enables accessible building blocks when properly implemented > - Evidence: "Full site editing and the block editor has a huge opportunity to make a website accessible because you can have components like a menu or like a block the new block for an accordion that are perfectly accessible" > #### ⏱️ [10:30](https://youtu.be/CJLMe1UJrKM?t=630) — [H2] Block Accessibility Challenges > - Key idea: Not all WordPress blocks are accessible, with table block having significant issues > - Evidence: "There are blocks like the table block that has huge accessibility issues. So it puts a lot of responsibility for the people who work for core who make these components" > #### ⏱️ [12:00](https://youtu.be/CJLMe1UJrKM?t=720) — [H3] Need for Accessible Block Documentation > - Key idea: Users need guidance on which blocks are safe to use from accessibility perspective > - Evidence: "I got this question also like in a presentation I gave on which blocks can I use. So maybe it's a good idea to on the wpaccessibility.org have like a list of blocks that you can use" > #### ⏱️ [14:15](https://youtu.be/CJLMe1UJrKM?t=855) — [H1] Accessibility as AI Readiness Strategy > - Key idea: Accessible markup with semantic HTML enables both assistive technology and AI agent comprehension > - Evidence: "If you write good semantic HTML use good heading structure when you have a form use real labels and input fields. So it's like a machine has to be able to analyze your website" > #### ⏱️ [16:30](https://youtu.be/CJLMe1UJrKM?t=990) — [H1] Revenue Impact of Inaccessibility > - Key idea: Excluding people with disabilities means losing significant market share and revenue > - Evidence: "The lost business revenue has grown to 17 billion pounds in the UK only in one year. So that's a lot of money you throw away" > #### ⏱️ [18:00](https://youtu.be/CJLMe1UJrKM?t=1080) — [H1] Training as Highest ROI Investment > - Key idea: Training teams on accessibility fundamentals provides the best return on investment > - Evidence: "Training train your people train yourself train your designer your content creator your developers how to build accessible" > #### ⏱️ [20:30](https://youtu.be/CJLMe1UJrKM?t=1230) — [H2] Keyboard Navigation as Core Requirement > - Key idea: Keyboard accessibility remains fundamental requirement for web accessibility compliance > - Evidence: "Navigating with keyboard that's like the essence of accessibility. A website must be able and all functionality must be able to work with the keyboard only" > ## 📚 References > - [WP Accessibility Knowledge Base](https://wpaccessibility.org) > - [WordPress Accessibility Team GitHub - WP-A11Y-docs](https://github.com/WPaccessibility/WP-A11Y-docs) > - [Click-Away Pound Survey 2019](https://click-away.co.uk/capreport19/) > - [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/WCAG21/quickref/) > ## 🗣️ Paraphrase > - WordPress core and default themes provide accessible foundations, but the ecosystem's plugin and block architecture can undermine accessibility if developers don't prioritize inclusive design > - The scattered state of WordPress accessibility documentation creates barriers to learning, necessitating the consolidated WP Accessibility Knowledge Base project to serve as a single source of truth > - Full Site Editing's component-based approach offers unprecedented opportunities for accessible WordPress sites, but requires systematic vetting of blocks and ongoing developer education to realize this potential > ## 📰 Newsletter > **WordPress Accessibility Gets Organized: New Knowledge Base Launches** > Great news for WordPress developers and site builders! The WordPress accessibility community is consolidating years of scattered documentation into a comprehensive knowledge base at wpaccessibility.org. Led by accessibility expert Rian Rietveld, this project addresses a critical gap in WordPress education. > **What's New:** A centralized hub for accessibility guidance covering designers, developers, content creators, and compliance professionals. The documentation will eventually integrate into WordPress's official developer resources. > **Why It Matters:** With Full Site Editing making component-based design mainstream, having vetted, accessible building blocks becomes crucial. The project will include curated lists of accessible blocks and clear guidance on avoiding problematic implementations. > **Get Involved:** Contribute through the GitHub repository (WPaccessibility/WP-A11Y-docs) or reach out to Rian directly (@rianrietveld on most platforms). > **Bottom Line:** Accessibility training provides the highest ROI for teams, and semantic markup benefits both users with disabilities and AI agents parsing your content. > Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) > ## ✅ Action Items > #### DevRel > - Developer advocacy: Create accessibility-focused talks for WordCamps highlighting business case and AI readiness benefits > - Education: Develop accessibility workshops for enterprise teams, focus on keyboard testing and semantic markup > - Developer experience: Review block editor documentation for accessibility guidance gaps > - Developer marketing: Promote WP Accessibility Knowledge Base launch through developer channels > - Community management: Facilitate connections between accessibility team and plugin developers > #### WordPress > - Core: Review and prioritize accessibility issues in existing blocks, particularly table block problems > - Core Performance: Consider accessibility impact in performance optimizations, ensure semantic markup preservation > - Training: Integrate accessibility modules into existing WordPress training curricula > - Community: Support WP Accessibility Knowledge Base integration into official documentation > - Support: Create escalation paths for accessibility-related support requests > - Documentation: Audit DevHub for accessibility documentation gaps and outdated content > - Accessibility: Accelerate block accessibility auditing and create public accessibility status dashboard > - Meta: Ensure .org infrastructure meets accessibility standards, test with assistive technology > - Themes: Require accessibility compliance for default themes, provide accessibility review rubrics > - Plugins: Develop accessibility guidelines for plugin directory, create accessibility testing recommendations > ## 🧪 Hypotheses > - Training teams on accessibility fundamentals provides higher ROI than post-hoc remediation efforts > - Accessible markup improves AI agent comprehension and content parsing effectiveness > - Component-based Full Site Editing architecture can achieve better accessibility outcomes than traditional theme development > - Centralized accessibility documentation increases adoption rates among WordPress developers > ### 📊 Methodology > - Study design: Compare accessibility compliance rates before and after team training interventions > - Data sources: Analyze correlation between semantic markup quality and AI agent performance metrics > - Experiments: A/B test traditional themes vs FSE components for accessibility compliance rates > ### ❓ Questions > - How can WordPress core ensure accessibility standards are maintained as the block ecosystem expands? > - What metrics best demonstrate the business value of accessibility investments to enterprise stakeholders? > - How might AI-driven content creation tools incorporate accessibility best practices by default? > ### 🔮 Future Research > - Long-term impact study of centralized accessibility documentation on WordPress ecosystem compliance rates > - Investigation of automated accessibility testing integration in WordPress development workflows > - Analysis of correlation between accessibility compliance and search engine/AI agent content preference > ### 💡 Implications > - Practice: Teams should prioritize accessibility training over compliance checklists, emphasizing keyboard testing and semantic markup > - Policy: WordPress governance should consider accessibility requirements for plugin directory inclusion > - Security: Accessible markup patterns may provide more reliable content parsing for security scanning tools > - Education: Accessibility education should be integrated into all WordPress training programs, not treated as specialized knowledge > - Funding: Organizations should budget for accessibility training as infrastructure investment rather than compliance cost > ### 🧠 Learning Styles Assessment > Reading level estimate: Flesch-Kincaid Grade Level 8-9 > #### 👀 Visual learners > - Present: Video presentation format with speaker demonstrations > - Improve: Architecture diagrams showing accessible component relationships, visual accessibility audit examples > #### 🔊 Aural learners > - Present: Video discussion format with clear verbal explanations > - Improve: Audio-only version of key accessibility concepts, pronunciation guide for technical terms > #### 🗣️ Verbal learners > - Present: Clear definitions of accessibility terms, real-world examples and analogies > - Improve: Glossary of accessibility terminology, comparison tables between accessible and inaccessible approaches > #### 🧩 Kinesthetic learners > - Present: References to hands-on keyboard testing recommendations > - Improve: Step-by-step accessibility testing checklists, interactive accessibility audit tools > #### 🧠 Logical learners > - Present: Clear causal relationships between accessibility and business outcomes, structured documentation approach > - Improve: Decision trees for accessibility implementation, quantified ROI calculations > #### 🧑‍🤝‍🧑 Social learners > - Present: Community contribution opportunities through GitHub and feedback channels > - Improve: Accessibility mentorship programs, peer review processes for accessibility implementations > #### 🧘‍♀️ Solitary learners > - Present: Self-directed learning through documentation project > - Improve: Self-assessment accessibility rubrics, individual progress tracking tools > #### 🌿 Naturalistic learners > - Present: Connection to inclusive ecosystem thinking > - Improve: Sustainability connections between accessibility and digital inclusion > ### 📊 Accessibility Assessment > #### Screen reader semantics > - Present: Video includes proper speaker introductions and context > - Improve: Transcript with heading structure, speaker identification for all dialogue > #### Keyboard navigation > - Present: Emphasis on keyboard testing as fundamental requirement > - Improve: Demonstration of keyboard navigation patterns in presentation materials > #### Contrast and readability > - Present: Clear verbal communication of key concepts > - Improve: High-contrast presentation slides, readable font sizes in any visual materials > #### Text resizing and reflow > - Present: Content accessible through multiple channels (video, transcript) > - Improve: Responsive presentation materials that work at 200% zoom > #### Media and captions > - Present: Full transcript provided for video content > - Improve: Time-coded captions, audio descriptions for visual elements > #### Forms and interactions > - Present: Clear instructions for contribution and feedback > - Improve: Accessible forms on wpaccessibility.org, proper error handling > #### Standards reference > - Maps to WCAG 2.2 AA requirements for multimedia content and documentation > ### 🌍 DEIB Assessment > #### Cultural breadth > - Present: Global accessibility perspective, UK-specific revenue data included > - Improve: International accessibility legislation examples, multilingual resource links > #### Inclusive language > - Present: Person-first language when discussing disability, avoids medical model terminology > - Improve: Consistent terminology guide, avoid assumptions about user capabilities > #### Neurodiversity support > - Present: Structured presentation format > --- > ## Full Transcript > [00:05] Welcome back everybody. Uh we're running [00:09] a tad behind schedule but like all the [00:11] sessions are happening and we have uh [00:14] our next speaker with us. We're going to [00:16] chat about accessibility. [00:18] Uh we already know accessibility is a [00:20] business requirement but it's also an [00:23] opportunity to create better experiences [00:26] for everybody on the web. And in this [00:28] upcoming session, I'm going to be [00:29] chatting uh to one of my favorite people [00:31] in the WordPress community. Uh and we're [00:33] going to go beyond compliance checklists [00:36] and we'll explore the realworld impact [00:40] of accessible design. Uh we're going to [00:42] do that with uh Rian uh who's got more [00:46] than 25 years of experience [00:49] uh helping teams build build inclusive [00:51] digital products. She is uh an [00:54] accessibility consultant and a trainer. [00:57] She teaches through the accessibility [00:59] collective. Uh she contributes to [01:01] WordPress uh and to WordPress [01:04] accessibility documentation in in [01:06] particular. And unless you've been like [01:09] living under a rock, you must have heard [01:12] Rian speak at least once in the last [01:14] decade on any of the WordPress stages [01:17] that uh that she's been on uh teaching [01:20] people about uh all the things [01:24] accessibility. So I'm going to pull Rian [01:26] up uh right now. There you are. [01:30] Uh and [01:32] >> thank you for making me feel very old. [01:35] >> What? No. I mean, hey, look, like I've [01:38] been there for the last decade as well. [01:40] So, you know, [01:42] fair is fair. We're we are WordPress [01:45] veterans, Rian. Like, I don't think that [01:47] >> there's anything we can do to change [01:50] that. [01:51] >> Um, right. Okay. Well, um, I'm really [01:55] happy uh to be having this conversation [01:57] with you. Uh thank you so much for [01:59] accepting the invite to uh speak and to [02:02] share some of your uh some of your [02:04] thoughts on like all all the things [02:06] WordPress accessibility and you know [02:10] 2026. [02:11] So uh let's let's do with like a let's [02:14] start with a short kind of intro [02:16] question. What is accessibility and why [02:20] is an accessible website so important [02:24] for a company? [02:27] Well, accessibility is making a website [02:29] or a web shop um workable and usable uh [02:34] for as many people as possible and also [02:37] on all kind of different devices. [02:40] So really important that people who come [02:42] to your website actually can use it and [02:46] that's not only good for your business, [02:48] it's also good for your income. [02:52] >> Awesome. What is the current kind of [02:54] state of accessibility within WordPress? [02:56] What what would you say is where are we [02:59] compared to when the work on [03:01] accessibility started? [03:03] >> Well, it depends. Um, [03:06] for example, well, if you use out of the [03:10] box WordPress and use a default theme, [03:12] those are all accessible. Um, but if you [03:16] can if you add plugins or add blocks uh [03:19] that are not really accessible, then you [03:21] can ruin everything. So, it depends on [03:24] how you use WordPress. if uh the website [03:27] you build with it is accessible or not. [03:30] >> Yeah. [03:30] >> I see. All right. So, for the last [03:33] several years uh I believe you've been [03:35] working on the WP accessibility [03:37] knowledge base. Can you tell us a little [03:39] bit about it? Who is it for? What [03:41] problems does it solve and uh you know [03:45] that didn't have a good answer before? [03:47] What's the road map? Like tell us a [03:49] little bit about the project. [03:51] >> Yeah. Um, a few years ago at Word Camp [03:54] Europe, um, I went to the contributor, [03:57] uh, table of the accessibility team and [04:00] I said to Joe Dawson, he runs the stuff [04:03] there. Um, I asked one, give me work and [04:06] he said, well, can you take a look at [04:08] all the accessibility documentation [04:10] there is on WordPress.org? [04:12] And well, I took a quiet place and a [04:16] coffee and I read through all the [04:18] documentation there is and it was really [04:21] scattered around the place all dated um [04:25] duplicate content content that was not [04:27] really true. Um very hard to find. So I [04:31] thought if you want to learn about [04:33] accessibility from WordPress.org or [04:36] that's uh very hard to do because [04:39] there's so many places a bit of [04:41] information not really one source one a [04:44] source of truth where you can go to and [04:47] learn everything. So then we had the [04:50] idea we're going to start like a [04:52] knowledge base uh where you can go to [04:54] and you can find for if you're a [04:56] designer a developer content creator [04:59] want to know about legislation one place [05:03] uh where you can find everything and [05:04] then in the rest of all the [05:06] documentation you can point to that so [05:08] you don't have to duplicate everything. [05:10] So that was the plan. So um we created a [05:14] website wpaccessibility.org [05:16] or to start writing and we are at the [05:20] moment the website is ready and we are [05:22] putting in documentation at the moment. [05:26] >> Awesome. [05:26] >> So yeah so um the plan is if that [05:30] documentation is ready enough we're [05:33] going to give that back to WordPress.org [05:36] with the developers resources. There [05:38] will be a separate section accessibility [05:41] and all the documentation rewritten will [05:44] be copied to the developer.pest.org [05:47] in a section accessibility [05:49] and we hope to do that well I hope end [05:52] of this year maybe maybe soon later [05:54] depends on how many time [05:57] um we have to do that so that's so visit [06:01] wpacessibility.org [06:03] and give uh us your opinion because we [06:06] are writing this for you. [06:08] >> I I was going to ask how people can get [06:10] involved with that. Is there a way for [06:12] uh others to contribute to the project [06:14] or like provide feedback etc. So that's [06:17] just going to the website um [06:19] >> go to yeah go to the website there is [06:21] there's a section about this [06:24] documentation and there you can find a [06:26] section about how to contribute. We have [06:28] a GitHub repository [06:30] um that's on WP that is GitHub um [06:35] account is called WP accessibility and [06:38] there's the uh WP- [06:41] A11Y- [06:42] docs that's a repo. [06:45] Um maybe someone can send it in in the [06:47] in the chat. Yeah, [06:48] >> in the chat. Yeah. Um yeah, we will do [06:52] we'll make sure we do. Um Awesome. Um [06:55] All right. Well, a lot of love for the [06:57] project. Let's see if these uh bloody [06:59] gestures work. There we go. Yay. [07:02] >> Sometimes they do, sometimes they don't. [07:04] You know, usually appear. Yeah, usually [07:06] appear. [07:07] >> You have to have the um Apple whatever [07:12] >> turned on for this to work. [07:14] >> Um All right, cool. So, let's talk a [07:17] little bit about accessibility and full [07:19] sight editing and the the block editor. [07:21] Uh so full-sight editing the block [07:23] editor have changed how a lot of teams [07:26] build with WordPress. Has that shift [07:29] made accessibility [07:32] easier or harder in practice for uh for [07:36] WordPress development? Where is the gap [07:39] uh still the widest and is it harder for [07:43] uh enterprise teams to adapt and kind of [07:46] improve? There's a lot of questions. [07:49] Let's start like from [07:50] >> Yeah, I think um full set editing and [07:53] the block editor has a huge opportunity [07:56] to make um a website accessible because [07:59] you can have components like a menu or [08:03] um uh like a block the new block for an [08:06] accordion that are perfectly accessible. [08:09] So you can really put things together. [08:13] Um and then your website is is [08:16] accessible like the components are [08:18] accessible. Um that is not really for [08:22] every block and every component true [08:25] because there are blocks like the table [08:27] block that has huge accessibility [08:29] issues. So it puts a lot of [08:33] responsibility for the people who work [08:35] for core who make these components for [08:38] full site editing and for blocks um that [08:41] they are accessible. new blocks um well [08:45] they're really checked well but all the [08:48] blocks well they're still a problem and [08:50] if you have like a block library with [08:53] everybody can just add to that or for [08:56] plugins that add blocks well it's the [08:59] responsibility of the plug-in owner of [09:01] the people who write the blocks to make [09:03] them accessible so in potential if [09:06] everything is accessible when you can [09:08] put together a website that will be a [09:10] huge advantage [09:12] Um but yeah it's not always the case and [09:17] yeah you have to test on can I use this [09:20] block. I got this question also like in [09:23] a presentation I gave on uh which blocks [09:26] can I use. So maybe it's a good idea to [09:29] on the wpacessibility.org [09:32] have like a list of blocks that you can [09:34] use. Um so you can have your sure [09:38] something like that offer like a service [09:40] like well you can use the menu because [09:43] in full setting but that's fully [09:45] accessible. [09:46] >> Yeah. Is that something that you're [09:47] already that you're considering adding [09:49] to the WP [09:52] it takes work because someone needs to [09:54] check that. So, [09:56] >> okay. So, this is another way that [09:58] people can contribute. Basically, if you [10:00] know a blog that is already accessible, [10:01] maybe like send send that to the [10:06] accessibility.org team and like you can [10:08] start compiling that list uh that list [10:11] of um [10:13] >> that list of uh accessible uh tools and [10:16] blocks. Great. [10:18] >> Yeah. [10:20] >> Awesome. Um all right. I'm anything but [10:23] like a cheerleader for contributors like [10:24] looking for new ways to kind of bring [10:26] people in. So if you're developing with [10:28] WordPress and if you're using full-size [10:30] editing and uh the block editor and [10:33] you've developed accessible plugins or [10:35] you found a plug-in that is already [10:36] accessible like definitely get involved [10:38] on the WP accessibility or [10:40] >> well you can you can also reach yeah you [10:42] can also reach out to me in Slack or I'm [10:46] called everybody on every platform I'm [10:50] 12 so you can uh reach out to me and [10:52] then I can help you. Yeah. [10:54] >> Awesome. All right. Um, cool. Let's talk [10:57] a little bit about like we heard [10:59] earlier, Noel talked a little bit about [11:01] uh the future trajectory of WordPress [11:05] becoming an agentic platform. So like AI [11:09] agents reading and acting on content. Uh [11:12] does structured accessible markup [11:15] actually make your site more uh eligible [11:19] to those like legible to those agents? [11:22] like is accessibility becoming an AI [11:26] readiness strategy almost? [11:29] >> Well, maybe [11:31] um the previous talk by Alex Moss [11:34] actually answered that question. [11:37] >> If you write good semantic HTML um use [11:40] good heading structure um when you have [11:42] a form um use real labels and input [11:46] fields. So it's it's like a machine has [11:48] to be able to analyze your website. It's [11:51] like assist of technology. It's like um [11:54] not someone with eyes and a mouse but [11:56] really a machine must be able to analyze [11:58] and understand content. And then you [12:01] need good HTML, good um good markdown [12:05] and accessibility is for the most part [12:08] good markdown, really good HTML and um [12:12] everything validating. So I think um [12:17] it's actually the same as with SEO to be [12:20] able to scrape your website the machine [12:23] must be able to make sense of the [12:26] content and of the importance and the [12:27] structure of the content and that's the [12:29] same for I I think I'm not an expert but [12:32] if Alex says it then then it's true. [12:35] Yeah. [12:37] >> All right. So yeah, there is yeah there [12:40] is an obvious link uh to the ways like [12:44] search is changing but like basically [12:46] the the the what we can take from this [12:49] is like the more accessible your website [12:52] is the better it will perform uh in [12:54] regards to uh AI agents kind of uh doing [12:59] that. [13:00] Okay. Interesting. Interesting. For the [13:04] enterprise brands we'll hear from later [13:08] in the panel, uh so media organizations, [13:11] large scale publishers, what's the cost [13:13] do you think of not investing in [13:15] accessibility in 2026 beyond like [13:19] regulatory risk? What is revenue? [13:23] >> Yeah, you call it revenue. If you um [13:27] create only for perfect people, people [13:30] who have perfect eyesight, are clear of [13:32] mind, can move their uh hands, [13:35] uh are web savvy. [13:38] Well, then you say, okay, only those [13:40] people are allowed in my web shop and [13:43] the rest of the people I don't give [13:45] access to and the rest of the people is [13:47] quite a lot of people. So you have to [13:50] take in account that you um build for [13:53] everyone not only for perfect people. [13:57] So um I think um if you disregard all [14:02] the Yeah, the door is ringing. If you uh [14:04] disregard all the uh people that are not [14:08] perfect, then you miss out on money. [14:10] People won't buy with you and also those [14:12] people will tell around. you know, [14:14] that's a really bad website and they go [14:17] to the competitor that is accessible and [14:19] order the stuff there. [14:21] >> So, it's also an inclusivity issue like [14:24] but directly impacting revenue. [14:28] >> Sorry, [14:29] >> it's also an inclusivity issue. You [14:31] know, it's kind of you're creating um [14:34] you're not creating for everybody that [14:36] is able to use your product. Yeah, there [14:38] is a website the click away pound and [14:42] that did two um surveys and the last [14:45] survey was in 2019 [14:49] and I have to look it up. I don't know [14:51] by heart um [14:56] so um the lost business revenue has [15:00] grown to 17 million pounds in the UK [15:04] only in one year. 17 mill billion 17 [15:09] billion pounds. So that's a lot of money [15:12] you throw away. And also if you really [15:14] optimize your website for SEO or for AI [15:18] and then um [15:21] people come to your website and they [15:23] cannot use your website and go away, you [15:25] throw also away the money you spent on [15:27] optimizing your site. [15:28] >> Of course. Yeah. [15:30] >> So that's a double loss. Yeah. [15:33] >> Yeah. Thank you. Yeah. I mean um I [15:36] definitely hope that people take uh your [15:38] advice at heart because uh yeah losing [15:41] revenue for something like that is it's [15:44] like not something that should be [15:45] overlooked. Um okay so if you are [15:49] advising a senior developer or digital [15:52] leader attending today what is the one [15:56] accessibility investment in 2026 that [15:59] will have the highest return like [16:02] technically and commercially do you [16:04] think [16:05] >> training train your people train [16:08] yourself [16:09] >> train your designer your content creator [16:12] um your developers um how to build [16:15] accessible [16:16] because most of it is just decent code, [16:20] decent HTML, um yeah uh decent uh [16:25] feedback on dynamic changes so that [16:28] people don't guess what's happening or [16:30] cannot use like uh the website with the [16:33] keyboard. If you train people um they [16:37] also become better in their jobs and [16:39] also learn that there are other ways [16:41] that people uh use the web. [16:45] Is patcha gone only for me? [16:55] I'm going to refresh. [17:21] Hey folks. Uh, sorry about that. [17:30] We [18:52] We are having some accessibility issues [18:54] which is uh you know isn't it ironic [18:57] like the amazing uh Marset uh to say [19:01] like accessibility session how [19:04] accessible is crowdcast that's like [19:06] another question to be asking uh [19:08] entirely. Um, [19:12] so, um, I'm not entirely sure whether [19:14] Rian is going to be able to get back in. [19:17] Uh, and we are already over time. Uh, [19:21] we're going to do a last effort to kind [19:24] of pull Rian for a Q&A Q&A session. Uh, [19:28] we're sending her a link uh, [19:33] right now. Um, and while we do that Oh, [19:35] there we go. [19:38] All right. Back again. [19:40] Hi. [19:41] >> Okay. [19:42] >> Um well, I mean it was bound to happen [19:45] accessibility issues uh in the [19:48] accessibility session. [19:51] Um [19:53] sorry. Uh okay, we've got uh one [19:58] question in the Q&A panel. Uh Rian, [20:01] let's uh end with that. I think you are [20:03] so clear about uh what is the one thing [20:07] that uh people need to invest in and [20:09] that's training training your staff [20:11] about accessibility. Let's move on to [20:13] the Q&A session uh before we close uh [20:16] the session for the day. So uh Matthew [20:20] is asking I remember at high school in [20:24] college uh being a lot there being a lot [20:27] of focus on text size options and high [20:29] contact contract contrast I assume that [20:33] is also navigating via keyboard. Are [20:36] these still the case today? Uh I heard [20:39] dark mode's term most recently. [20:44] Oh well, a lot of people like dark mode [20:46] to switch between that. It's not really [20:49] an accessible requirement, but it can [20:51] help a lot of people. And um making text [20:55] bigger is something your browser can do [20:57] if you do like control plus or command [21:00] plus uh your browser can make text [21:03] bigger. Um [21:06] um [21:08] um yeah, I don't know. It's still it [21:10] it's all helped but the accessibility is [21:12] is defined by uh WK that there's um a [21:17] lot of guidelines [21:19] and uh size options text size is not [21:23] really a guideline but it helps people. [21:25] Uh dark and uh white mode is light mode [21:29] is is not really an uh guideline but it [21:32] helps people. So um it's still an issue [21:36] but it's not really uh an accessibility [21:38] requirements [21:39] for the web content accessibility [21:42] guidelines but navigating with keyboard [21:44] that's like the essence of [21:46] accessibility. A website must be able [21:49] and all functionality must be able to [21:53] work with the keyboard only. So that's [21:55] super important to test that and you [21:57] everybody has a keyboard. So please test [21:59] your work with a keyboard. [22:02] Yep. Is that answering your question? [22:18] Bachel I cannot hear you. [22:21] Yes. Now say something. [22:24] >> Uh I think we're going to close the [22:26] session. I think there are some [22:27] connectivity issues uh with Rian. So, [22:31] let's move on to the next question for [22:33] today. We're going to pull you in in [22:34] evidence. See you. Unfortunately, Youtube does not provide subtitles for this video, Accessibility is essential in 2026, YouTube, 01kkmf0309xnggsxeg7ns0nssx.