ATAG 2.0 structure:

• Part A: the authoring interface itself is accessible (authors can have disabilities too).
• Part B: the tool supports producing accessible output (prompts, checks, repair help, accessible defaults).

Why “missing standard”: WCAG is widely discussed, but ATAG adoption is limited. Many systems treat author support as documentation, not product requirements.

Reference: ATAG 2.0 (W3C Recommendation). https://www.w3.org/TR/ATAG20/

Claims behind the bullets:

• ATAG 2.0 predates today’s LLM tooling. The original guidance assumed mostly static rules and limited context awareness.
• Rules-based guardrails are useful but shallow. They catch “missing alt” but not “bad alt for this image and this page goal.”
• Local AI can provide contextual assistance at authoring time: suggestions, checks, and coaching tied to the actual draft content.
• This is not about generating more content. It is about better decisions by humans, supported by tooling.

Reference for the standard basis: ATAG 2.0. https://www.w3.org/TR/ATAG20/

Claims behind the bullets:

• We4Authors was a cross-tool effort to improve authoring experiences and defaults ahead of the European Accessibility Act context.
• The emphasis was user research with authors and practical defaults, not only compliance checklists.
• At the time, the missing piece was scalable contextual guidance inside authoring tools.

Reference (DrupalCon Europe session): https://events.drupal.org/europe2020/sessions/top-cms-tools-are-working-together-build-more-inclusive-world.html

Related talk (FOSDEM archive): https://archive.fosdem.org/2023/schedule/event/accessibility_and_open_source/

What these opportunities represent: recurring high-impact failure modes where authoring tools can prevent defects before publication.

• Language: correct language tags, mixed-language spans, and author prompts.
• Tables: header association, captions, scope, and discouraging layout tables.
• Alt text: presence, quality checks, and context-aware suggestions.
• Forms: labels, instructions, error prevention, and error recovery support.
• Video: captions, transcripts, audio description prompts, and publishing gates.
• Testing: live checks while authoring, plus document and site-level evaluations.

Reference archive: https://mgifford.github.io/We4Authors/

Claims behind the bullets:

• Privacy-first: Draft content often includes personal data, sensitive policy, or unpublished material. Many organizations cannot send it to third-party AI services.
• CMS boundary: Keeping the pipeline local reduces legal and procurement friction and supports regulated environments.
• Choice of models: Administrators need options (small language models, local deployments, enterprise-approved models) and the ability to tune prompts for authoring context.
• Guardrails: Constrain inputs and outputs, log what was suggested, and require human confirmation where it matters.

Why this matters: Local SLMs can be an open-source advantage if the community builds shared modules, prompts, and evaluation datasets.

Claims behind the bullets:

• Shift left: Catch issues during authoring when fixes are cheap and obvious.
• Author empowerment: The tool should explain what to do and why, not just block publishing.
• Cross-organization impact: When checks are built into the workflow, you do not depend on individual expertise or a single accessibility specialist.

Examples:

• Sa11y (in-page checking model): https://sa11y.netlify.app/
• Editoria11y (CMS integration model): https://editoria11y.princeton.edu/

Claims behind the bullets:

• Alt text quality: AI can draft better starting points than many humans, but it still needs verification for accuracy and relevance.
• Plain language & captions: AI can draft simplifications and media alternatives, but accessibility risk rises if teams treat drafts as final.
• Friction as safety: Require explicit review actions (for example, a checkbox, a short confirmation, or “explain why this is accurate”) before publish.
• Structural hints: Tools can detect common anti-patterns (bold used as headings, broken list structure) and guide correction.

Reference (your prior talk): Alternative Text for Images: How Bad Are Our ALT text Anyway? https://archive.fosdem.org/2025/schedule/event/fosdem-2025-4709-alternative-text-for-images-how-bad-are-our-alt-text-anyway-/

Standards anchor: This aligns with ATAG Part B’s intent: tools should assist authors in producing accessible content, not just warn after the fact. https://www.w3.org/TR/ATAG20/

Claims behind the bullets:

• Authoring support reduces audit scope: fewer basic failures make evaluation faster and increase pass rates on repeat audits.
• WCAG-EM: provides a repeatable evaluation methodology (define scope, explore site, select representative sample, audit, report).
• AI support: can help with page discovery, sampling, evidence capture, and report drafting, but not final conformance decisions.
• ACR tooling: Structured reports (OpenACR) reduce vendor spin and force disclosure of gaps and evidence.
• Why it matters: These artifacts feed legal reporting and procurement expectations (WAD statements in the public sector context, EAA service accessibility info in services context).

References:

• WCAG-EM (revised draft): https://w3c.github.io/wai-wcag-em/
• python-acr: https://github.com/mgifford/python-acr
• ACR editor (Section508.gov): https://acreditor.section508.gov/

Claims behind the bullets:

• Full automation is not realistic. Many success criteria require human judgment and user testing.
• What can be automated: crawling, representative/random sampling, collecting evidence artifacts, organizing findings by WCAG success criteria, and writing structured outputs (JSON) that tools can reuse.
• What stays manual: task testing, usability friction, cognitive load issues, assistive technology workflows, and validation with disabled users where appropriate.
• The outcome should still include a public statement and a maintenance process, not a one-time report.

Reference: WCAG-EM draft: https://w3c.github.io/wai-wcag-em/

Claims behind the bullets:

• ATAG Part B is implementable in pieces. Teams do not need to solve everything at once.
• The W3C ATAG Community Group is the coordination venue for shared patterns, requirements, and reference implementations.
• Open collaboration is how we avoid each CMS building incompatible, proprietary authoring assistants.
• Inclusive LLM behavior is not automatic. Vendors optimize for “helpful,” not necessarily for accessibility, accuracy, or safe author workflows.

References:

• Digital Accessibility Ethics — Disability Inclusion in All Things Tech
• ATAG CG GitHub: https://github.com/w3c-cg/atag
• Designing Content Authoring Experiences (Greg Dunlap): https://authoringexperience.com/

Reference: Digital Accessibility Ethics — Disability Inclusion in All Things Tech.

1. I am one of 39 authors from 10 countries contributing to Digital Accessibility Ethics: Disability Inclusion in All Things Tech, releasing later this spring. Together we bring over 600 years of combined accessibility and disability experience.
2. The book introduces the first digital accessibility ethics framework.
3. My chapter applies the framework to issues facing the open source community.
4. Chapter title: "Digital Accessibility and Open Source Need Each Other".
5. The framework centres 10 values essential to inclusion in open source.
6. I focus on honesty, transparency, trust, accountability, awareness, education, and sustainability as core open source values.
7. The framework is practical: actions to take and questions to ask to build more ethical open source projects.
8. Learn more and pre-order: Digital Accessibility Ethics: Disability Inclusion in All Things Tech.

Use these links as the “take-home kit”:

• ATAG 2.0: the standards basis for accessible authoring tools and author support. https://www.w3.org/TR/ATAG20/
• ATAG Community Group: where coordination and modern tooling alignment is happening. https://github.com/w3c-cg/atag
• WCAG-EM draft: the evolving evaluation methodology that can be partially automated. https://w3c.github.io/wai-wcag-em/
• We4Authors archive: prior research, gaps, and recommendations. https://mgifford.github.io/We4Authors/

Prompt: Scan the QR and write down one specific change you will implement (one ATAG Part B practice, one editor check, one publishing gate, or one evaluation automation).