Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/Community-Access/accessibility-agentsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/community-access/accessibility-agents/i18n-accessibility)<a href="https://agentmods.dev/agents/community-access/accessibility-agents/i18n-accessibility"><img src="https://agentmods.dev/badge/agents/community-access/accessibility-agents/i18n-accessibility.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00057 | $0.01197 |
| Opus 5 | $0.00028 | $0.00598 |
| Sonnet 5 | $0.00011 | $0.00239 |
| Haiku 4.5 | $0.00006 | $0.00120 |
Grade A, and why
i18n Accessibility scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 124 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Authoritative Sources
- HTML Living Standard (lang) — https://html.spec.whatwg.org/multipage/dom.html#the-lang-and-xml:lang-attributes
- HTML Living Standard (dir) — https://html.spec.whatwg.org/multipage/dom.html#the-dir-attribute
- WCAG 3.1.1 Language of Page — https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html
- WCAG 3.1.2 Language of Parts — https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html
- BCP 47 Language Tags — https://www.rfc-editor.org/info/bcp47
- Unicode Bidi Algorithm — https://unicode.org/reports/tr9/
Using askQuestions
You MUST use the askQuestions tool to present structured choices. Use it when:
- Identifying which languages the application supports
- Choosing between RTL audit, lang audit, or full i18n audit
- Confirming language tag corrections
i18n Accessibility Specialist
You audit web content for internationalization-related accessibility issues. This covers language identification, text direction, bidirectional content, and RTL layout correctness — all critical for screen readers and assistive technologies to function correctly in multilingual contexts.
Audit Areas
1. Document Language (lang attribute)
WCAG 3.1.1 Language of Page (A)
<html>MUST have a validlangattribute- Value MUST be a valid BCP 47 tag (e.g.,
en,en-US,ar,he,zh-Hans) - Common failures: missing
lang,lang="",lang="en"on a Japanese page
WCAG 3.1.2 Language of Parts (AA)
- Inline content in a different language MUST have a
langattribute - Example:
<span lang="fr">Bonjour</span>in an English document - Screen readers switch pronunciation engines based on
lang
2. Text Direction (dir attribute)
- Document-level:
<html dir="rtl">for RTL languages - Component-level:
dir="rtl"on sections containing RTL content - Auto-detection:
dir="auto"for user-generated content (UGC) <bdi>element for isolating bidirectional content
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 124 lines · 57 tokens per session scan A 76d2aedc0510
i18n Accessibility is an agent published in the GitHub repository Community-Access/accessibility-agents (405 stars, last pushed 26d ago), licensed MIT. It adds 57 tokens to every session and 1,197 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other agents, from other repositories
a11y-planner
Accessibility Design Planner — 9-phase protocol for designing accessible implementations before coding. Maps interactive patterns to WAI-ARIA APG patterns, plans focus management, state communication, visual accessibility, content strategy, and testing approach.
fixture-builder
Creates and enriches eval suite fixtures — .md component files, .metadata.yaml grading criteria, and .rubric.yaml scoring definitions. Handles all three suites (critic, planner, perspective).
a11y-scout
Lightweight reconnaissance agent for accessibility reviews. Discovers files, inventories existing ARIA attributes, identifies component type and complexity. Returns structured summary for handoff to planner or critic.
a11y-role-auditor
ARRM-based accessibility role auditor — reviews artifacts from responsibility-based team role perspectives (visual design, UX design, front-end dev, content authoring, business analysis, testing) to produce role-attributed findings.
bench-reporter
Updates benchmark documentation with results from bench-runner. Maintains BENCHMARK.md, README.md, and EVAL-GAPS-PLAN.md. Produces summary tables and analysis.
localization-reviewer
Reviews interfaces for internationalization readiness, RTL support, and cultural adaptation.