A11y explained weekly: newsletter #3
Let's discuss web accessibility news, pros & cons of AI, how to create accessible Linkedin post, Lucy Edwards' story
Accessibility news
1. States double down on accessibility ahead of compliance deadlines
📅 Published: 14 October 2025
🔗 Source: Statescoop — Accessibility emerges alongside AI as priority for state tech leaders at NASCIO conference StateScoop
Highlights:
State technology leaders reported that accessibility has risen sharply in priority at the NASCIO annual conference. With an impending April 2026 deadline for states to make websites, apps, and digital services compliant, many governments are now dedicating resources and leadership oversight. StateScoop Some states are appointing accessibility coordinators and embedding accountability in digital strategy.
🔎 Why it matters for web accessibility:
This shift signals that accessibility is no longer a niche concern, but a core public infrastructure issue. For developers and organizations, it’s a reminder: accessibility must be baked into planning, not bolted on at the end.
2. Michigan State launches campus-wide accessibility monitoring
📅 Published: Early October 2025
🔗 Source: MSU Today — The MSU quest for digital accessibility Michigan State University
Highlights:
Michigan State University has established a network of 200 “digital accessibility liaisons” across departments. They use automated scanning tools (e.g. Silktide) to assess over 135,000 web pages every five days, track videos, course materials, and surface accessibility issues for remediation. Michigan State University
🔎 Why it matters for web accessibility:
This is a great example of ongoing governance rather than one-off fixes. Even well-intentioned sites degrade over time. Regular monitoring, distributed ownership, and accountability are essential to long-term accessibility.
3. New model aligns AI systems to generate more accessible UIs
📅 Published / Preprint: 15 October 2025
🔗 Source: arXiv — A11YN: aligning LLMs for accessible web UI code generation arXiv
Highlights:
A new approach called A11YN proposes reframing large language models so their web UI outputs are penalized for accessibility violations (e.g. missing ARIA, bad contrast). In tests, it reduced inaccessibility by ~60% compared to default generations. arXiv
🔎 Why it matters for web accessibility:
This research is promising because it addresses one of AI’s biggest challenges: copying bad patterns. If generative tools can be aligned with accessibility guidelines, they might become allies rather than liabilities — but this is academic, not plug-and-play yet.
Love–hate relationship of AI & web accessibility
I’ll be honest - this topic confuses me. AI can be a powerful ally for accessibility... or a quiet barrier creator.
Every tool that promises to “solve accessibility” for us risks removing the human understanding that’s at the core of inclusion and that’s the problem that I see here. People don’t want to think and understand, they want a quick solution.
Let’s look at a few examples and their hidden traps:
1. AI-generated alt text
▷ How it helps: AI can detect objects and create descriptions automatically — a time-saver for large image libraries.
▷ Hidden risk: it can lead to mindless automation. People start adding alt text everywhere - even when it’s decorative - and stop thinking about meaning. AI also tends to over-describe (I got 150+ characters everytime) and miss context.
▷ Examples: AltText.ai, Microsoft Azure Vision, Google Cloud Vision API
2. Automatic captions and subtitles
▷ How it helps: AI transcription tools can generate accurate captions faster than ever in multiple languages.
▷ Hidden risk: background noise, accents, or technical vocabulary can easily confuse models. Review and edit are still essential.
▷ Examples: YouTube auto-captioning, Whisper by OpenAI, Phonetik.ai, Nagish Live Transcribe
3. Sign language translation and learning tools
▷ How it helps: AI avatars and recognition systems can interpret or teach sign language — bridging communication gaps and giving people more independence.
▷ Hidden risk: we still need authentic representation with real deaf creators, accurate signing, and awareness of regional sign language variations.
▷ Example: Silence Speaks (AI sign language avatar project)
4. AI coding assistants
▷ How they help: they speed up development, suggest solutions, and write components within seconds.
▷ Hidden risk: most don’t “understand” accessibility. They produce code that fails basic WCAG — missing ARIA labels, poor heading structure, inaccessible forms. Fixing it later often means overwriting and adding more code, not correcting the real issue.
▷ Examples: GitHub Copilot, ChatGPT, Codeium
5. AI accessibility overlays
▷ How they help: overlays claim to make any website accessible instantly by injecting code and “adjusting” elements automatically.
▷ Hidden risk: in reality, they often block assistive technologies, confuse screen readers, and give organizations a false sense of compliance. Accessibility can’t be added with a script — it needs to be built in by design.
▷ Examples: accessiBe, UserWay, EqualWeb
For every tool mentioned above, the solution is simple: use AI as a helper, not as a decision-maker. I am convinced that it’s time we make web accessibility education mandatory — so we guide AI in what and how to do things, not the other way around.
Designing for real accessibility: Lucy Edwards’ story
Too often, we follow accessibility guidelines as rules, without pausing to truly put ourselves in the shoes of people with disabilities. We tick boxes, run audits, and call it a day.
But real stories help us feel what it’s really like. Like the one that I read recently about Lucy Edwards.
“I just wanted to book a holiday—but the website wouldn’t let me.”
Lucy, a blind journalist and creator, recently shared her experience navigating travel websites. For her, planning a trip means relying on a screen reader, yet many sites make that nearly impossible:
· Images without alt text — she can’t visualize destinations.
· Pop-ups that freeze her screen reader — leaving her stuck mid-booking.
· Buttons without labels — making “next” or “pay” a guessing game.
Lucy’s story turns a technical issue into a human one. It reminds us that accessibility isn’t just about compliance; it’s about real people, independence, and dignity.
Here’s what we can take from her experience:
1. Use meaningful labels and alt text
Don’t just follow the guidelines - describe what matters. Alt text should convey purpose, not just content. Button labels should indicate the action clearly.
2. Design for screen reader flow
Test how your forms, modals, and pop-ups behave with assistive technology. Avoid traps that freeze or confuse users.
3. Prioritize content structure
Headings, landmarks, and logical tab order are not optional - they’re essential for someone navigating without sight.
4. Consider context, not just elements
Accessibility is about tasks, not just components. Ask: can a blind person actually complete the booking without help?
5. Empathy-driven testing beats checklists
Guidelines tell you what to do. Stories like Lucy’s show you why it matters.
The internet should empower, not exclude. Lucy’s experience is a wake-up call: empathy, curiosity, and real-world testing are essential to inclusive design.
If you’ve faced accessibility challenges, as a user or a designer, please share your experience (openly in the comments or by writing me a private message). Let’s make the web a place everyone can navigate with independence and dignity.
Checklist that helps to create an accessible Linkedin post
