Built the Website With an AI, but Is It Accessible

Built the Website With an AI, but Is It Accessible? ![rw-book-cover](https://img.youtube.com/vi/SkbilSmku60/maxresdefault.jpg) 🔗 **Source:** [Built the Website With an AI, but Is It Accessible?](https://www.youtube.com/watch?v=SkbilSmku60) > [!note]+ Document Notes > tags: [accessibility, ai-website-builders, wcag, wordpress, screen-readers] > author: Janaki Konar and Fahad Lambate > source: WordPress Accessibility Day 2025 (BarrierBreak) > reference: https://www.youtube.com/watch?v=SkbilSmku60 > date created: 2026-09-08 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Built the Website With an AI, but Is It Accessible? >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor Appendix](#-refactor-appendix--built-the-website-with-an-ai-but-is-it-accessible) ### 🔗 References - [Video: Built the Website With an AI, but Is It Accessible?](https://www.youtube.com/watch?v=SkbilSmku60) - Feedback form mentioned in-talk: 2025.wpaccessibility.day/feedback ## 📝 Summary - **What happened.** At WordPress Accessibility Day 2025, Janaki Konar and Fahad Lambate of BarrierBreak presented a talk built around three "zones" — green (things AI website builders get right), red (things AI gets wrong), and yellow (things that need manual human review) — using a WordPress AI website builder as their working example, then demoed BarrierBreak's own scanning tool, A11yInspect. - **Why it matters.** AI page builders (the talk names Shopify, Wix, Squarespace, Hostinger, and WordPress's built-in AI assistant) are lowering the skill floor for building sites, which means more non-technical people are shipping pages without knowing whether they're accessible. The speakers' core finding: AI handles structural basics reasonably well but cannot be trusted for interactive components, alt text accuracy, or heading logic without a human checking the output. - **Key stakeholders.** BarrierBreak (accessibility vendor and speaker), Equalize Digital (event host, gold sponsor), WordPress Accessibility Day organizers, AI website-builder vendors, and non-technical site owners using these tools without accessibility training. - **Risks and tradeoffs.** The speakers state AI-driven automated testing "only catches 30% to 40% of the issue[s]" (t=1684s) — the rest needs manual keyboard/screen-reader testing and, per Fahad, evaluation input from people with disabilities (t=1781s). Relying on a prompt like "make an accessible web page" is explicitly called out as insufficient (t=1248-1257s). - **Bottom line.** AI speeds up site construction and gets some accessibility fundamentals right (landmarks, skip links, simple menu toggles, basic form labeling, some color contrast), but does not guarantee accessibility, and specific failure modes — accordions, link text, heading hierarchy, alt text — recur even with careful prompting. ## 📖 Main Content The talk is a two-presenter walkthrough (Janaki Konar covers the "what" and "why" of accessibility plus the execution plan; Fahad Lambate covers the zone-by-zone technical findings and the tool demo) structured around a single working example: a webpage built with an AI WordPress builder, which the speakers then audit by hand and with BarrierBreak's own tool. **Green zone — what AI got right (Fahad, from t=730s):** semantic landmarks (header/main/footer tags used correctly), a working skip-to-content link that moves keyboard focus to main content, a hamburger menu built with a native `<button>` element, a dynamic "open menu"/"close menu" label, and focus trapped inside the open menu. Color contrast was described as "the most constant thing which was done right" (t=952-958s) when the prompt specified an accessible color theme — their example hit a 21:1 contrast ratio. Forms fared well too: label/input association done without ARIA overuse, `required` paired with `aria-required="true"` on mandatory fields, inline error messages with `aria-invalid="true"`, and focus moving automatically to the first field with an error. List markup (`<ul>`/`<li>`) was used correctly for navigation and social-link groups. **Red zone — where AI failed even with careful prompting:** a simple accordion (expand/collapse) never got keyboard support, "even after additional prompt[s]" (t=942-946s) — visually it looked interactive but had no real interactivity. Color contrast still failed in specific instances even where a theme was chosen for accessibility — an error-message text example measured roughly 1.86:1 (t=1372-1380s), well under the 4.5:1 minimum for normal text. Repeated, non-descriptive link text ("join now") appeared with no distinguishing context across a page (t=1387-1420s), and one of those links had no `href` attribute at all, so it couldn't receive keyboard focus (t=1571-1576s). Heading structure was wrong at the page-architecture level: the logo/home link was coded as an `<h1>` on every page (t=1451-1468s), when H1 should describe that specific page's content and vary page to page; large font-size text was also given heading markup where no heading was warranted. Alt text problems split into two types: incomplete (an artisan-bread image described only part of what was shown — no mention of bread types or prices, t=1515-1528s) and inaccurate/over-general (a bakery basket image described simply as "a bakery" without conveying what was actually depicted, t=1536-1546s). **Yellow zone — what still needs a human (Fahad, from t=1611s):** the speakers are explicit that even their own product, A11yInspect, isn't "a 100% detection tool" (t=1646-1656s), and that automated testing broadly "only catches 30% to 40% of the issue[s]" (t=1684-1686s), with the remainder needing manual validation. Manual review is required for: judging whether an image is decorative or informative (context-dependent), dynamic content announcements, modal dialog focus management (focus moves into the dialog on open, stays trapped inside, and returns to the triggering element on close — "All these things AI can't detect," t=1752s), keyboard navigation and focus-order testing, and heading hierarchy correctness based on content meaning rather than font size. Fahad states plainly that people with disabilities must be part of the evaluation or "your evaluation will be incomplete" (t=1785-1788s). **Execution plan (Janaki, from t=1930s):** run an automated tool first to scan code and flag issues, then perform manual testing with keyboard and screen reader to catch what the tool missed and to resolve judgment calls (e.g., whether flagged link text like "learn more" is actually unclear in context, whether a skipped heading level like H2→H4 should become H3 or shouldn't be a heading at all). **Tool demo — A11yInspect (t=2153-2569s):** installed as a browser extension, accessible from developer tools. A scan of their AI-built demo page returned 5 issue types / 9 issues under "Fail" and 14 issue types / 28 issues under "Validate" (items needing manual confirmation). Of the 9 failures, 8 fell under WCAG Level A and 1 under Level AA. The blocker-severity example was a link that fails to receive keyboard focus, mapped to WCAG 2.1.1 (Keyboard). The Validate tab surfaced an alt-text case where an image already flagged as decorative had a full text description anyway — a manual call about whether that's correct. The Suggestions tab flagged duplicate H1s (one in header, one in footer) as a best-practice issue. The tool also has a page-structure view (landmarks and headings, which surfaced a "multiple banners" question), a color-contrast checker (color picker or hex/RGB input, checked against AA/AAA for large vs. non-text), a CSS overview tab (all color combinations, font sizes, families in use, flagging combinations to avoid), a unit converter, and a "pause script" control that freezes JavaScript-driven content so a tester can inspect code that would otherwise collapse or vanish on interaction. Bookmarklets in the tool confirmed correct `<ul>`/`<li>` list markup and caught a table coded with `<table>`/`<tbody>`/`<tr>` but no `<th>` header cells. **Uncertainties/contested claims:** the speakers flag their own example as debatable in two places — whether every page needs a skip link (t=791-799s) and whether an end-of-form error summary text like "Please fill out the form correctly" is correctly placed (they argue it should be at the top of the form, not the bottom, t=1122-1132s). These are presented as the speakers' professional judgment calls, not settled rules. ### 🗒️ Notes #### ⏱️ [00:01:32](https://www.youtube.com/watch?v=SkbilSmku60&t=92s) Welcome and speaker introductions - Chris Hinds (COO, Equalize Digital) introduces the session and both speakers. - Janaki Konar: IAAP-certified web accessibility specialist, accessibility testing QA lead at BarrierBreak, 9+ years of accessibility experience. - Fahad Lambate: IAAP-certified professional in web accessibility, associate accessibility director at BarrierBreak. #### ⏱️ [00:02:22](https://www.youtube.com/watch?v=SkbilSmku60&t=142s) BarrierBreak overview - BarrierBreak does remediation and auditing of websites, applications, and documents; VPAT authoring; design review; and playbooks. - Products named: A11yInspect, A11yNow, ACE Learning. #### ⏱️ [00:03:07](https://www.youtube.com/watch?v=SkbilSmku60&t=192s) Agenda: three zones - Agenda covers what digital accessibility is and why it matters, AI website-building benefits, three identified zones (green/red/yellow), inspecting/testing/fixing accessibility issues with a demo of A11yInspect, and conclusions. #### ⏱️ [00:03:54](https://www.youtube.com/watch?v=SkbilSmku60&t=234s) What digital accessibility means - Accessibility = making digital content, apps, documents, tools, and systems usable and understandable by everyone, including people with disabilities. - Covers both permanent and situational disability (dark mode as an eye-strain/low-light necessity; text-to-speech or screen magnifier when glasses aren't handy, t=337-343s). #### ⏱️ [00:05:48](https://www.youtube.com/watch?v=SkbilSmku60&t=348s) Why accessibility matters - Goals: everyone can use and interact with the product and participate equally; legal requirements exist in some regions. - Business case: brand reputation, audience reach, SEO — plus "the right thing to do" framing (t=425-430s). #### ⏱️ [00:07:21](https://www.youtube.com/watch?v=SkbilSmku60&t=441s) Rise of AI website building - AI now assists across the build process: visuals/icons/images, layout and color-scheme suggestions, HTML/CSS code, and full-page content generation from plain-language prompts. - Named tools: Shopify, Wix, Squarespace, Hostinger, plus WordPress's built-in AI assistant in the dashboard. - AI lowers the barrier for non-technical users and small businesses/freelancers without budget for a full team, but "does not guarantee that the webpage that the AI has created comes with 100% accessibility" (t=677-682s). #### ⏱️ [00:11:42](https://www.youtube.com/watch?v=SkbilSmku60&t=702s) Green zone begins: landmarks and skip links - Header/main/footer landmark tags used correctly. - Skip-to-content link works: keyboard-focusable, moves focus to main content on activation. #### ⏱️ [00:14:03](https://www.youtube.com/watch?v=SkbilSmku60&t=843s) Expand/collapse: hamburger menu works, accordion fails - Hamburger menu: native `<button>`, dynamic open/close label, focus trapped inside the menu. - Accordion control: AI could not make it keyboard-accessible even after additional prompts — visually present, not functionally interactive. #### ⏱️ [00:15:51](https://www.youtube.com/watch?v=SkbilSmku60&t=951s) Color contrast done right (in this example) - 21:1 contrast ratio measured on a white/black/orange color scheme, well above the minimum requirement. #### ⏱️ [00:16:57](https://www.youtube.com/watch?v=SkbilSmku60&t=1017s) Forms: labels and required-field handling - Label/input association done correctly without ARIA overuse; `required="true"` paired with `aria-required="true"` on mandatory fields. #### ⏱️ [00:18:10](https://www.youtube.com/watch?v=SkbilSmku60&t=1090s) Error messages - Inline error messages carry `aria-invalid="true"`; focus moves to the first field with an error. - Debatable placement: a summary error message sits at the bottom of the form near the send button rather than at the top. #### ⏱️ [00:19:51](https://www.youtube.com/watch?v=SkbilSmku60&t=1191s) List structure - Navigation links and social-media links both coded correctly as `<ul>`/`<li>` lists. #### ⏱️ [00:20:25](https://www.youtube.com/watch?v=SkbilSmku60&t=1225s) Transition to red zone: accessibility is not a checkbox - Key framing line: prompting "make an accessible web page" doesn't reliably produce one; specific prompts are needed, and even those may not guarantee accessibility. #### ⏱️ [00:22:06](https://www.youtube.com/watch?v=SkbilSmku60&t=1326s) Common AI misses, part 1: color contrast failures - Error-message text measured at roughly 1.86:1 contrast against its background — a clear fail even when the overall theme was chosen for accessibility. #### ⏱️ [00:23:05](https://www.youtube.com/watch?v=SkbilSmku60&t=1385s) Non-meaningful link text and missing href - Repeated "join now" links with no distinguishing context; one link had no `href`, so it couldn't receive keyboard focus. #### ⏱️ [00:23:52](https://www.youtube.com/watch?v=SkbilSmku60&t=1432s) Heading hierarchy mistakes - The logo/home link was coded as `<h1>` on every page instead of a page-specific heading; large-font text was marked up as a heading unnecessarily. #### ⏱️ [00:24:59](https://www.youtube.com/watch?v=SkbilSmku60&t=1499s) Alt text: incomplete and inaccurate examples - An artisan-bread image's alt text omitted bread types and prices; a bakery-basket image's alt text was too generic relative to what was shown. #### ⏱️ [00:26:39](https://www.youtube.com/watch?v=SkbilSmku60&t=1599s) Yellow zone: manual review bridges the gap - Automated tools including BarrierBreak's own A11yInspect are explicitly not presented as 100%-detection tools; AI testing "only catches 30% to 40% of the issue[s]" (t=1684s). #### ⏱️ [00:29:27](https://www.youtube.com/watch?v=SkbilSmku60&t=1767s) People with disabilities in the evaluation loop - Fahad states BarrierBreak has included people with disabilities in auditing "since the start"; without that, "your evaluation will be incomplete" (t=1785-1788s). #### ⏱️ [00:31:52](https://www.youtube.com/watch?v=SkbilSmku60&t=1912s) Execution plan handoff to Janaki - Two-step plan: automated scan first, then manual keyboard/screen-reader testing to catch what the tool misses and resolve human-judgment calls (link clarity, heading appropriateness, alt-text quality, focus visibility, dynamic-content announcements). #### ⏱️ [00:35:43](https://www.youtube.com/watch?v=SkbilSmku60&t=2143s) A11yInspect demo begins - Scan results: 5 issue types / 9 issues fail; 14 issue types / 28 issues need manual validation. 8 of 9 failures are WCAG Level A, 1 is Level AA. - Blocker example: link fails to receive keyboard focus (WCAG 2.1.1). #### ⏱️ [00:37:57](https://www.youtube.com/watch?v=SkbilSmku60&t=2277s) Validate tab and Suggestions tab - Alt-text validation example: an image flagged decorative already carried a full text description — a manual call. - Duplicate H1s (header and footer) flagged as a best-practice suggestion. #### ⏱️ [00:39:12](https://www.youtube.com/watch?v=SkbilSmku60&t=2352s) Page structure, color contrast, CSS overview, unit converter, pause script - Page-structure view surfaces landmarks/headings and a "multiple banners" question needing review. - Color-contrast tab checks AA/AAA via picker or hex/RGB input; CSS overview tab lists all color/font combinations in use and flags what to avoid. - "Pause script" freezes JS-driven content so a tester can inspect elements that would otherwise collapse on interaction. #### ⏱️ [00:41:57](https://www.youtube.com/watch?v=SkbilSmku60&t=2517s) Bookmarklets: list and table checks - List bookmarklet confirms correct `<ul>`/`<li>` markup; table bookmarklet finds a table with no `<th>` header cells. #### ⏱️ [00:42:56](https://www.youtube.com/watch?v=SkbilSmku60&t=2576s) Conclusion - AI speeds up building and handles some accessibility, but doesn't guarantee full accessibility; testing (tool + manual) is required, and accessibility needs ongoing review, not a one-time checklist. #### ⏱️ [00:44:21](https://www.youtube.com/watch?v=SkbilSmku60&t=2661s) Q&A - On how far non-specialist users are from generating "reasonably accessible" sites: Janaki says results are "somewhat there, somewhat not there" even with detailed prompts; Fahad adds that human-coded sites without AI aren't reliably "reasonably accessible" either — it depends on the builder's accessibility knowledge, and complex components still need manual engineering. - Closing "one thing to change" question: Janaki wants AI-generated code to be correct by default (role, focus, contrast); Fahad wants AI to proactively surface accessibility prompts/checks during the build (e.g., suggesting alt-text or keyboard-support checks as elements are created) — he was cut off by the host before finishing the thought. ## 📚 References - [Video: Built the Website With an AI, but Is It Accessible?](https://www.youtube.com/watch?v=SkbilSmku60) — WordPress Accessibility Day 2025 - WCAG 2.1.1 (Keyboard) — cited in-talk as the success criterion for the "link fails to receive keyboard focus" blocker (t=2242s) - 2025.wpaccessibility.day/feedback — feedback form mentioned by the host (t=3013s) ## 🗣️ Paraphrase AI website builders — including WordPress's own dashboard AI assistant and tools like Shopify, Wix, Squarespace, and Hostinger — have made it possible for non-technical people to spin up a functional, reasonably well-structured site from a plain-language prompt. That's genuinely useful for small businesses and freelancers without the budget for a dedicated design or dev team, and it speeds up turnaround for agencies too. But speed and structure aren't the same as accessibility. In BarrierBreak's testing of an AI-built WordPress page, the fundamentals — landmarks, skip links, a simple menu toggle, basic form labeling, and color contrast when a theme was chosen for it — came out mostly right. What consistently broke were the harder interactive and judgment-dependent pieces: an accordion that never got real keyboard support even with extra prompting, link text repeated across a page with no distinguishing context, a heading structure that reused H1 for the site logo on every page, and alt text that was either incomplete or too generic to be useful. The speakers' throughline is that automated testing — AI-driven or tool-driven, including their own product — catches roughly 30-40% of what matters, and the rest depends on a human running keyboard and screen-reader tests and, ideally, on people with disabilities taking part in the evaluation itself. Their proposed workflow is sequential: run an automated scanner first to flag code-level issues, then do manual testing to resolve everything that depends on context and judgment — is this alt text accurate, does this heading actually belong at this level, does focus move correctly when a modal opens and closes. Their closing point undercuts any read of this as an anti-AI talk: developers who build without AI aren't automatically "reasonably accessible" either. The gap is accessibility knowledge, not the presence or absence of an AI tool in the workflow. ## 📰 Newsletter Building a WordPress site with an AI assistant now takes minutes instead of days — but BarrierBreak's Janaki Konar and Fahad Lambate used WordPress Accessibility Day 2025 to show exactly where that speed still leaves gaps. Testing an AI-built WordPress page, they found the fundamentals mostly solid: correct landmarks, a working skip link, a hamburger menu with proper focus trapping, and (when an accessible theme was chosen) a 21:1 color-contrast ratio. What broke: an accordion control that never gained keyboard support even after repeated prompting, "join now" links repeated with zero context, an H1 reused as the site logo on every page instead of describing each page's actual content, and alt text that was either incomplete or too vague to be useful. Their headline number — automated testing, AI or otherwise, catches only 30-40% of accessibility issues — is the reason their execution plan pairs an automated scan (they demoed their own tool, A11yInspect) with mandatory manual keyboard/screen-reader testing and, per Fahad, evaluation input from people with disabilities. Worth watching if you're evaluating an AI site builder or reviewing content someone else built with one: [full talk](https://www.youtube.com/watch?v=SkbilSmku60). ## ✅ Action Items #### DevRel - Developer advocacy: build a short demo showing the accordion-vs-hamburger-menu contrast from this talk (t=843-946s) as a concrete "prompt harder, verify anyway" example for developer audiences. - Education: workshop or office-hours session on prompting AI website builders for accessibility, using the talk's green/red/yellow zone framing. - Developer experience: Not applicable to this source — no SDK, docs, or quickstart work is discussed. - Developer marketing: Not applicable to this source — no campaign or funnel content discussed. - Community management: Not applicable to this source — no moderation or code-of-conduct topics discussed. - Internal/external/cross-project: Not applicable to this source — no cross-team SLA or feedback-loop topics discussed. #### OSPO - Policy & Governance: Not applicable to this source — talk covers vendor tooling and testing practice, not open-source contribution governance. - License Compliance: Not applicable to this source. - Security Management: Not applicable to this source. - Software Inventory: Not applicable to this source. - Developer Support: Not applicable to this source. - Community Engagement: Not applicable to this source. - Strategic Alignment: Not applicable to this source. #### Community - Maintainers: Consider a documented accessibility checklist for AI-generated WordPress content, mirroring the talk's green/red/yellow zones, for anyone maintaining an AI-assisted site. - Contributors: Not applicable to this source — no contributor-onboarding content discussed. - Sponsors: Not applicable to this source — sponsor list is event boilerplate, not talk content. - Ecosystem: Not applicable to this source — no cross-project incident or disclosure content discussed. #### WordPress - Core: Not applicable to this source — talk doesn't touch WordPress core code or release criteria. - Core Performance: Not applicable to this source. - Core AI: Track the talk's finding that the WordPress dashboard AI assistant (t=548s) generates functional but not reliably accessible markup — relevant input for any responsible-AI guardrail or evaluation-set work on Core AI features. - Core Program Team: Not applicable to this source. - Mobile: Not applicable to this source. - Playground: Not applicable to this source. - Community: Not applicable to this source — see Community section above for the closer WordCamp/meetup-adjacent fit. - Training: Adapt the talk's execution plan (automated scan, then manual keyboard/screen-reader pass) into a training module for site owners using WordPress's AI page-building features. - Marketing: Not applicable to this source. - Support: Document the recurring failure patterns (accordion keyboard support, duplicate/misplaced H1, generic alt text) as known issues to check for in support triage when a user reports "my AI-built page isn't working right." - Design: Not applicable to this source. - Documentation: Add a documentation note under AI-assisted page building warning about the accordion/keyboard-support failure mode and the H1-per-page requirement, both demonstrated directly in this talk. - Photos: Not applicable to this source. - TV: Not applicable to this source. - Polyglots: Not applicable to this source. - Accessibility: Direct fit — feed this talk's zone framework (green/red/yellow) and specific failure list (accordion, non-meaningful links, missing href, H1 misuse, alt text) into the WordPress accessibility team's audit heatmap and issue triage for AI-page-building features. - Meta: Not applicable to this source. - CLI: Not applicable to this source. - Hosting: Not applicable to this source — hosting sponsors are event boilerplate, not talk content. - Tide: Not applicable to this source. - Openverse: Not applicable to this source. - Themes: Flag AI-assisted theme customization as a place to test for the color-contrast failure mode described (t=1342-1380s) even when a theme was chosen for accessibility. - Plugins: Not applicable to this source — talk doesn't discuss plugin review. #### The WPOCC - Programs: Not applicable to this source — talk is vendor/practitioner content, not WPOCC program design. - Projects: Not applicable to this source. - Funding experiments: Not applicable to this source. #### FAIR - Technical independence: Not applicable to this source — talk doesn't touch FAIR's provenance or signature-check scope. - Policies and covenants: Not applicable to this source. - Productized governance artifacts: Not applicable to this source. ## 🧪 Hypotheses - H1: AI website builders produce correct semantic landmarks (header/main/footer) and skip links more reliably than they produce correct heading hierarchy. - H2: Simple, native-element interactive controls (buttons, menu toggles) are more likely to come out keyboard-accessible from an AI builder than composite widgets like accordions. - H3: Automated accessibility scanners (AI-driven or rule-based) catch a minority of real accessibility issues on AI-generated pages, with the majority requiring manual keyboard/screen-reader review. - H4: Alt text generated by AI page builders is more often incomplete or overly generic than outright missing. - H5: Prompt specificity (naming a WCAG criterion or concrete requirement) measurably changes whether an AI builder produces an accessible result, compared with a generic "make this accessible" prompt. ### 📊 Methodology - For H1-H2 and H4: build a sample set of pages across multiple AI website builders (WordPress AI assistant, Shopify, Wix, Squarespace, Hostinger) using matched prompts, then run structural audits (landmark presence, heading order, interactive-element keyboard testing, alt-text completeness scoring) across the sample. - For H3: run both an automated scanner (e.g., A11yInspect) and a full manual keyboard/screen-reader pass on the same set of pages, then compare issue counts and severities to compute the automated-detection rate directly, rather than relying on the talk's stated 30-40% figure. - For H5: A/B test generic versus specific prompts (e.g., "make this accessible" vs. "ensure this button has a role, receives keyboard focus, and meets 4.5:1 contrast") across the same builder and measure pass/fail rate against WCAG 2.2 AA success criteria. ### ❓ Questions - Does prompt specificity have diminishing returns — is there a point past which more detailed prompts stop improving accessibility outcomes? - Why did the accordion fail specifically, when the hamburger menu (a comparable expand/collapse pattern) succeeded — is it a training-data gap for ARIA-pattern components generally? - Do different AI website builders (WordPress AI, Shopify, Wix, Squarespace, Hostinger) show the same green/red/yellow pattern, or does it vary by vendor and underlying model? - How does the 30-40% automated-detection figure change as scanning tools add more AI-assisted judgment for context-dependent issues like alt text and heading meaning? ### 🔮 Future Research - A controlled comparison across multiple AI website builders using the same prompt set, scored against WCAG 2.2 AA, to see whether BarrierBreak's findings generalize beyond the one WordPress AI builder demoed here. - Longitudinal tracking of whether AI builders improve on the specific failure modes named (accordion keyboard support, H1 reuse, generic alt text) as underlying models are updated. - Research into whether "accessibility-aware" prompt templates or system prompts, distributed as reusable snippets, close the gap Fahad describes between low-hanging-fruit fixes (color contrast) and complex-component fixes (accordions, modals). ### 💡 Implications - **Practice:** teams using AI page builders need a manual QA step for interactive components and heading structure; the talk's own execution plan (automated scan → manual keyboard/screen-reader test) is a reusable template. - **Policy:** legal accessibility-compliance obligations (mentioned generically at t=376-380s) don't relax because a page was AI-generated — the speakers' framing implies the same liability applies regardless of who or what wrote the code. - **Security:** Not applicable to this source — no security topics discussed. - **Education:** the "low-hanging fruit vs. complex component" split Fahad describes (t=2845-2885s) is a useful teaching frame: color contrast and basic labels are prompt-solvable now; accordions and modals still need engineering knowledge. - **Funding models:** Not applicable to this source — no funding-model discussion. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ≈ 8-9 (conversational spoken register, short clauses, frequent restatement typical of live Q&A transcripts; formula: FKGL = 0.39 × (words/sentences) + 11.8 × (syllables/words) − 15.59, estimated from transcript sampling rather than full automated scoring). #### 👀 Visual learners - Present: the talk relies heavily on screenshots described verbally (the color-contrast example, the form error message, the A11yInspect scan results) but the transcript alone carries no image data. - Improve: pair this note with the original slide deck or recorded screen share; add labeled before/after screenshots of the accordion failure and the H1-duplication example. #### 🔊 Aural learners - Present: the source is a live-recorded talk with two speakers and natural Q&A — well suited to audio learners as-is. - Improve: a standalone 3-5 minute audio recap of the three-zone framework would let aural learners skip the sponsor-roll and tool-demo segments. #### 🗣️ Verbal learners - Present: the speakers define terms conversationally (e.g., what a landmark is, why skip links matter) before using them. - Improve: a short glossary (landmark, skip link, ARIA-required, contrast ratio) would help verbal learners cross-reference terms used across the 44-minute talk. #### 🧩 Kinesthetic learners - Present: the live A11yInspect demo (t=2153-2569s) is a step-by-step, reproducible walkthrough. - Improve: a companion checklist letting a reader replicate the same scan on their own AI-built page would convert the demo into a hands-on exercise. #### 🧠 Logical learners - Present: the green/red/yellow zone framework is itself a structured decision model; the execution plan (scan, then manually test) is a clear two-step process. - Improve: a decision table mapping issue type → detectable by automation? → requires manual judgment? would make the zone logic scannable rather than narrated. #### 🧑‍🤝‍🧑 Social learners - Present: live Q&A at the end includes real audience questions relayed by the host. - Improve: a discussion prompt ("what accessibility issue has your team's AI-built page hit?") would extend the social component past the live session. #### 🧘‍♀️ Solitary learners - Present: the talk's structure (zones, then execution plan, then tool demo, then conclusion) supports self-paced note-taking. - Improve: a self-check quiz ("which zone does a missing href fall into?") would let solitary learners verify retention. #### 🌿 Naturalistic learners - Present: Not applicable to this source — no sustainability, environment, or lifecycle-impact content discussed. - Improve: Not applicable to this source. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: the talk itself models good semantics in its subject matter (landmarks, list structure) but as a transcript-only source, has no independent heading/landmark structure of its own to assess. - Improve: WCAG 1.3.1 (Info and Relationships) — if published as a standalone page, ensure the note's own headings and lists use real semantic markup, not visual styling alone. #### Keyboard navigation - Present: Not applicable to this source in its transcript form — no interactive elements exist in a plain-text transcript. - Improve: WCAG 2.1.1 (Keyboard), 2.4.3 (Focus Order) — if this content is later embedded in an interactive page (e.g., with jump links per timestamp), ensure all links are keyboard-reachable and follow a logical focus order, directly mirroring the talk's own "link fails to receive keyboard focus" finding (t=2239s). #### Contrast and readability - Present: Not applicable to this source — transcript text has no color styling to assess. - Improve: WCAG 1.4.3 (Contrast Minimum) — any rendered version of this note should target at least 4.5:1 for body text, per the talk's own repeatedly-cited standard. #### Text resizing and reflow - Present: Not applicable to this source — plain text reflows natively. - Improve: WCAG 1.4.4 (Resize Text), 1.4.10 (Reflow) — if rendered as HTML, verify no clipping at 200% zoom. #### Media and captions - Present: the source video was clearly captioned live (the host references "our captioners," t=2990s) and this transcript is itself a caption-derived artifact. - Improve: WCAG 1.2.2 (Captions), 1.2.9 (Audio-only, Live) — publish an official downloadable transcript (this note partially serves that function) and confirm captions are archived with the video, not only available live. #### Forms and interactions - Present: Not applicable to this source — no forms in the note itself. - Improve: Not applicable to this source. #### Standards reference - Gaps identified above map to WCAG 2.2 AA: 1.2.2, 1.2.9, 1.3.1, 1.4.3, 1.4.4, 1.4.10, 2.1.1, 2.4.3 — all traceable to specific claims made in the source talk itself. ### 🌍 DEIB Assessment #### Cultural breadth - Present: both speakers work at BarrierBreak, an India-based accessibility firm, giving the talk an international practitioner perspective; no specific regional or multilingual examples are given. - Improve: add examples of accessibility legal requirements by region (the talk only gestures at "some regions" having legal requirements, t=372-380s, without naming which). #### Inclusive language - Present: the speakers consistently distinguish "permanent disability" from "situational disability" (t=270-278s), a widely-used inclusive framing. - Improve: define "screen reader," "ARIA," and "contrast ratio" on first use for readers newer to accessibility terminology. #### Neurodiversity support - Present: the talk's zone-based (green/red/yellow) structure and step-by-step execution plan provide predictable, chunked content. - Improve: the live talk moves quickly through many discrete examples in sequence (color contrast → forms → lists → red zone) without visual section breaks in speech alone; a written version with clear headers (as this note provides) helps. #### Representation - Present: the talk foregrounds disabled users' needs throughout, and Fahad explicitly states people with disabilities must be included in evaluation, not just discussed abstractly (t=1781-1788s). - Improve: the talk doesn't cite specific disabled users' direct testimony or named community members — adding first-person accounts would strengthen representation further. #### Psychological safety - Present: the talk frames AI-builder shortcomings without blaming users — Fahad's Q&A answer explicitly notes human-coded sites aren't automatically "reasonably accessible" either, avoiding a shame framing around AI use (t=2824-2837s). - Improve: Not applicable beyond what's present — no contentious or high-conflict topic requiring additional content warnings appears in this source. ### ✅ Logical Validity #### Strong reasoning - **Causal/evidentiary, located at t=2153-2569s:** the speakers back their central claim (AI doesn't guarantee accessibility) with a live, reproducible tool scan showing concrete numbers — 9 failing issues, 28 needing validation, 8 of 9 failures at WCAG Level A — rather than asserting the claim abstractly. This is strong because it ties a general claim to a specific, checkable instance. - **Analogical, located at t=2824-2837s:** Fahad's answer that human-coded sites without AI aren't automatically "reasonably accessible" either reframes the entire talk's finding as being about accessibility knowledge generally, not an AI-specific defect — a stronger and more defensible claim than "AI is bad at accessibility" alone. - To clarify further: naming the specific AI builder/model version tested (only "AI WordPress builder" is given, t=764s) would let readers verify or replicate the finding against a named tool. #### Fallacies - None identified as a clear formal or informal fallacy. The talk's strongest claims (30-40% automated-detection rate, specific WCAG criteria, concrete before/after examples) are backed by demonstrated evidence rather than assertion, and the speakers repeatedly qualify claims as debatable where their own judgment is involved (skip-link necessity, error-message placement) rather than overstating certainty. One soft spot: the 30-40% detection-rate figure (t=1684s) is stated without citing a source study or the sample size behind it — this is an unsupported statistic rather than a named fallacy, and the fix is simply to cite the study or dataset it comes from. #### Tone of voice - Practitioner-to-practitioner, measured and hedged: frequent qualifiers like "I'll say," "debatable," and "might be" (e.g., t=791-799s, t=1122-1132s) signal the speakers presenting professional judgment rather than absolute rules. The tone stays constructive toward AI tooling throughout — critical of specific failure modes, not dismissive of AI-assisted building as a category. ### 🛡️ DARVO Analysis - **Deny:** Not applicable to this source — the speakers openly document their own tool's limitations ("we don't necessarily say it is a 100% detection tool," t=1646-1656s) rather than denying any shortfall. - **Attack:** Not applicable to this source — no accuser or critic is named or targeted in this talk; it's a practitioner presentation, not a response to criticism. - **Reverse victim/offender:** Not applicable to this source — no conflict or accusation exists in this source for either party to reframe. ## 🎯 Conclusion AI website builders speed up construction and get structural basics right — landmarks, skip links, simple toggles, basic form labeling, and, when prompted for it, color contrast — but the speakers' own testing shows AI-generated pages fail on accordions, non-meaningful link text, heading hierarchy, and alt-text accuracy, even with careful prompting. Automated testing, including the speakers' own tool, catches an estimated 30-40% of accessibility issues (t=1684s); the rest requires manual keyboard and screen-reader testing plus evaluation input from people with disabilities. Practical next step for anyone using an AI page builder: treat the output as a first draft requiring the same manual accessibility pass a human-coded page would need, with particular attention to interactive widgets, heading structure, and alt text — the three areas where this talk's examples repeatedly broke. ## 🔄 Refactor Appendix — Built the Website With an AI, but Is It Accessible? ### 📚 Literature Atoms (H3) #### [H1] Automated tools catch 30-40% of accessibility issues > [!quote] ID:rw_transcript > it only catches 30% to 40% of the issue. **Context & use**: - t=1684s (Fahad Lambate), during the yellow-zone discussion of why manual review is required. - Central number underpinning the whole talk's argument for a hybrid tool-plus-manual workflow; useful anywhere the note discusses AI/automated accessibility testing limits. **Tags**: #xref **Highlight**: [view highlight](https://www.youtube.com/watch?v=SkbilSmku60&t=1684s)  #### [H2] AI-built accordion never gains keyboard accessibility > [!quote] ID:rw_transcript > Over there, the AI struggled because many times with certain prompts or with additional prompts also, that accordion was unable to be accessible using the keyboard **Context & use**: - t=909-921s (Fahad Lambate), the talk's clearest example of an AI failure surviving additional prompting. - Reusable as the canonical counter-example to "just prompt for accessibility" claims about AI page builders. **Tags**: #xref **Highlight**: [view highlight](https://www.youtube.com/watch?v=SkbilSmku60&t=909s)  #### [H3] Human-coded sites aren't automatically accessible either > [!quote] ID:rw_transcript > they are not "reasonably accessible" as well. **Context & use**: - t=2828-2831s (Fahad Lambate), Q&A response reframing the talk's finding as about accessibility knowledge, not AI specifically. - Load-bearing for any argument that this talk is not an anti-AI piece. **Tags**: #xref **Highlight**: [view highlight](https://www.youtube.com/watch?v=SkbilSmku60&t=2828s)  #### [H4] People with disabilities must be part of accessibility evaluation > [!quote] ID:rw_transcript > You need people with disabilities involved in this evaluation. **Context & use**: - t=1781s (Fahad Lambate), stated as a hard requirement, not a nice-to-have. - Anchors any claim in this note about evaluation methodology or manual review completeness. **Tags**: #xref **Highlight**: [view highlight](https://www.youtube.com/watch?v=SkbilSmku60&t=1781s)  ### 🧠 Permanent Candidates (H4) #### [P1] AI page builders need a manual accessibility pass before publishing **Claim** (one sentence, Courtney's voice): Treat any AI-generated webpage as a first draft that still needs a manual keyboard, screen-reader, and heading-structure check before it ships. **Evidence pointer**: [[#H1]] [[#H2]] **Scope & conditions**: Applies to pages built with AI website builders (WordPress AI assistant, Shopify, Wix, Squarespace, Hostinger, and similar); holds regardless of how detailed the accessibility prompt was, since the accordion example failed even after additional prompting. **Links** (≥1 with annotation): - [[WCAG 2.2 AA]] — because evidence-for the specific success criteria (2.1.1, 1.4.3) the talk's own tool cited as failures  #### [P2] Prompt specificity narrows but doesn't close the AI-accessibility gap **Claim** (one sentence, Courtney's voice): Specific accessibility prompts fix low-hanging-fruit issues like color contrast and basic labels, but complex interactive components still need manual engineering. **Evidence pointer**: [[#H2]] [[#H3]] **Scope & conditions**: Holds for AI website builders as demonstrated in this talk; untested against other AI code-generation contexts (e.g., component libraries, design systems) not covered by this source.  ### ✏️ Fleeting Queue - [F1] Check whether A11yInspect's browser-extension scan output could plug into the site-health-audit skill's accessibility checks — https://www.youtube.com/watch?v=SkbilSmku60 #xref - [F2] Watch for a named AI website-builder version/model in follow-up BarrierBreak talks — this one only says "AI WordPress builder" without naming the underlying model. #xref ### → Things 3 (max 2 actions) - [ ] Cross-reference this talk's accordion/H1/alt-text failure list against courtneyr.dev's own AI-assisted content workflow — WordPress Accessibility Day 2025 talk #things  📄 **Full text:** [[Full Document Contents/Articles/Built the Website With an AI, but Is It Accessible.md|Built the Website With an AI, but Is It Accessible? by Janaki Konar and Fahad Lambate]] ## Highlights - In certain cases, when we tried to create an expand/collapse for the control, which is more of an accordion. Over there, the AI struggled because many times with certain prompts or with additional prompts also, that accordion was unable to be accessible using the keyboard because it was not giving the keyboard support to it. It was just giving a plain structure to it, ([View Highlight](https://read.readwise.io/read/01m21epjas7ymcfkmet3x9paz0)) - Note: The specific failure mode: repeated prompting never got the AI-generated accordion to keyboard-accessible. It produced structure without behavior — which is exactly the class of defect an automated scan is least likely to catch. - Tags: ai-website-builders, atom/literature/h2, keyboard-navigation - it only catches 30% to 40% of the issue. That is also the threshold. Even in this 30%, 40%, you will need some validation to be done manually to ensure that is an issue or not. Manual review will also help you understand the context-related problems. We also spoke about image, wherein it could be decorative or informative. Apart from that, the dynamic updating context ([View Highlight](https://read.readwise.io/read/01m21epdj445repg3jg3nd3w8h)) - Note: BarrierBreak says automated testing — including their own A11yInspect — catches 30-40% of real issues, and even those need manual validation. Notable because they're naming the ceiling on the tool they sell. - Tags: atom/literature/h1, accessibility-testing, ai-website-builders