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.
npx skills add RadOrigin-LLC/RAD-Claude-Skills --skill astro-accessibilitygit clone --depth 1 https://github.com/RadOrigin-LLC/RAD-Claude-SkillsWrote 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/skills/radorigin-llc/rad-claude-skills/astro-accessibility)<a href="https://agentmods.dev/skills/radorigin-llc/rad-claude-skills/astro-accessibility"><img src="https://agentmods.dev/badge/skills/radorigin-llc/rad-claude-skills/astro-accessibility/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/radorigin-llc/rad-claude-skills/astro-accessibility"><img src="https://agentmods.dev/badge/skills/radorigin-llc/rad-claude-skills/astro-accessibility.svg" alt="Reviewed on agentmods" width="80" 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.00087 | $0.02614 |
| Opus 5.5 | $0.00035 | $0.01046 |
| Sonnet 5.5 | $0.00017 | $0.00523 |
| Haiku 4.5 | $0.00009 | $0.00261 |
Grade A, and why
astro-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 1mo 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 — 150 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Astro Accessibility (WCAG 2.2 AA)
Core Principle: Semantic HTML First
Astro's static-first model is inherently accessibility-friendly because HTML renders without JavaScript. Leverage this advantage fully.
- Use native HTML elements (
<nav>,<button>,<dialog>,<main>,<header>,<footer>) for their intended purpose. NEVER style<div>or<span>elements to look like interactive controls. - Native elements provide built-in keyboard support, screen reader announcements, and focus management for free. A
<button>handles Enter, Space, focus, and role automatically — a styled<div>provides none of this. - The browser builds the accessibility tree from your HTML structure. Using the wrong elements confuses assistive technology and breaks the experience for users who depend on it.
- Structure your document with landmark regions: one
<main>, a<nav>for navigation,<header>and<footer>for page-level landmarks. Screen reader users navigate by landmarks. - Maintain a proper heading hierarchy. Use exactly one
<h1>per page, then<h2>through<h6>in logical order without skipping levels. Headings are the primary navigation mechanism for screen reader users.
ARIA Rules
Follow the first rule of ARIA: do NOT use ARIA if a native HTML element or attribute exists that provides the semantics you need. ARIA is a last resort, not a first choice.
- Use ARIA only for custom components that have no native HTML equivalent (tab panels, tree views, custom comboboxes).
- Roles define what an element IS:
role="tablist",role="alert",role="status",role="dialog". Apply roles only when you cannot use the native element. - States define the current condition of an element:
aria-expanded="true|false",aria-selected="true|false",aria-pressed="true|false". Update these dynamically as the UI changes. - Properties define relationships between elements:
aria-labelledby,aria-describedby,aria-controls,aria-owns. Use these to connect related content that is not adjacent in the DOM. - NEVER use
aria-labelto override visible text. This creates a mismatch where screen reader users hear one thing while sighted users see another, violating WCAG 2.5.3 (Label in Name). - For dynamic UI updates (toasts, notifications, live regions), use
role="status"oraria-live="polite". Content injected into these regions is announced by screen readers without interrupting the user. - Reserve
aria-live="assertive"strictly for critical interruptions: form validation errors, time-sensitive alerts, or session expiration warnings. Overusing assertive announcements degrades the experience.
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.
- 1mo ago First seen · 150 lines · 87 tokens per session scan A 42defad6cb6e
astro-accessibility is a skill published in the GitHub repository RadOrigin-LLC/RAD-Claude-Skills (5 stars, last pushed 2mo ago), licensed Apache-2.0. It adds 87 tokens to every session and 2,614 once invoked, about $0.0003 per session on Opus 5.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-08-31.
Other skills, from other repositories
bug-reporting
Load this skill whenever you are filing, reviewing, or generating accessibility bug reports — whether from automated tool output, manual testing, user reports, or testing with disabled people. The purpose of this skill is to make accessibility findings easier to report accurately, connect them to real people and…
audio-video
Load this skill whenever the project contains audio or video content, media players, podcasts, video embeds, or any / elements. Under no circumstances publish audio or video without captions, transcripts, and audio descriptions where required. Absolutely always apply WCAG 1.2 criteria for time-based media.
charts-graphs
Load this skill whenever the project contains charts, graphs, data visualizations, infographics, or any visual representation of data (bar charts, line charts, pie charts, scatter plots, dashboards). Under no circumstances render a chart without a text alternative, data table, or summary. Prioritize conveying the same…
ci-cd
Load this skill when configuring or reviewing CI/CD pipelines, GitHub Actions workflows, or automated testing setups. Ensures accessibility regressions are caught before code reaches production by enforcing quality gates, structured reporting, and layered automated + manual testing across all pages and user…
forms
Load this skill whenever the project contains forms, inputs, selects, checkboxes, radio buttons, text areas, or any validation flow. Under no circumstances create a form without visible labels, error identification, and keyboard accessibility. Absolutely always associate every input with a label and provide clear…
keyboard
Load this skill for every project containing interactive UI elements — buttons, links, modals, dropdowns, sliders, tabs, carousels, or any custom widget. Under no circumstances create an interactive component that cannot be fully operated by keyboard alone. Absolutely always ensure visible focus indicators, logical…