Skip to content

Commit 6e2b5e5

Browse files
committed
Accessibility skill
1 parent 780c395 commit 6e2b5e5

1 file changed

Lines changed: 96 additions & 0 deletions

File tree

  • .claude/skills/docs-accessibility
Lines changed: 96 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,96 @@
1+
---
2+
name: docs-accessibility
3+
description: Analyzes a single documentation page and generates suggestions for writing with accessibility in mind, without making any edits. Use when you want to assess whether a page is compliant with accessibility guidelines.
4+
user-invocable: true
5+
disable-model-invocation: false
6+
---
7+
8+
Analyze the open page(s) and identify any accessibility guideline breaches. Follow the [Google developer documentation style guide](https://developers.google.com/style/accessibility) on writing accessible documentation.
9+
Do not make changes automatically. Instead, list out all suggestions first.
10+
11+
## Comprehensive Accessibility Checklist
12+
13+
Systematically check the documentation page for the following accessibility issues:
14+
15+
### Directional Language
16+
17+
Search for and flag all instances of directional or spatial references:
18+
19+
* Vertical directions – above, below, over, under, top, bottom
20+
* Horizontal directions – left, right, beside, next to
21+
* Visual verbs – see, look, watch, view, visualize, observe
22+
* Pointing language – here, there, this one, that one (without clear antecedent)
23+
24+
Screen reader users navigate non-linearly; content reflows on different devices; users with cognitive differences may process spatial information differently.
25+
26+
**Acceptable alternatives**:
27+
28+
* Use section names – "in the Widget Types section"
29+
* Use demonstratives with clear antecedent – "this example", "these properties"
30+
* Use descriptive references – "in the Toggle example", "in the JSON structure"
31+
* Use specific labels – "the first code block", "Example 1"
32+
33+
### Image Alt Text
34+
35+
For every image (figure shortcode):
36+
37+
* Check presence – Does it have alt text?
38+
* Check quality – Does the alt text describe what the image shows, not just where it is or what it's called?
39+
40+
Bad example: `alt="Toggle property in Studio Pro"` (locational only)
41+
Good example: `alt="Screenshot showing a toggle checkbox labeled 'My Toggle Property' with descriptive text below it in the Studio Pro properties panel"` (descriptive)
42+
43+
For decorative images, ensure `alt=""` is used (empty, not omitted).
44+
45+
### Link Text Quality
46+
47+
* Avoid "click here", "read more", "this link", "here".
48+
* Ensure link text makes sense out of context.
49+
* Check if link text describes the destination or action.
50+
* Flag links embedded in parenthetical phrases that reduce discoverability.
51+
52+
### Code Examples Context
53+
54+
* Check if code blocks have sufficient introduction. This ensures screen reader users understand what the code demonstrates before encountering it.
55+
* Flag bare "Here is an example" without specific context.
56+
* Check if code comments explain non-obvious syntax (like ellipsis notation).
57+
58+
### Ableist or Exclusionary Language
59+
60+
* Avoid "simply", "just", "easy", "obvious", "clearly" (minimizes difficulty).
61+
* Avoid "normal user", "regular workflow" (implies some users are abnormal).
62+
* Avoid assumptions about physical ability (standing, walking, seeing, hearing).
63+
* Check for gender-neutral language.
64+
65+
### Structural Accessibility
66+
67+
* Verify heading hierarchy (no skipped levels).
68+
* Check if lists are properly formatted.
69+
* Ensure tables have appropriate headers.
70+
* Verify alert boxes are used appropriately for important information.
71+
72+
### Content Clarity
73+
74+
* Check for sufficient context before technical terms.
75+
* Verify acronyms are defined on first use.
76+
* Ensure instructions can be followed without visual cues alone.
77+
* Flag time-based language without specific dates ("recently", "soon", "upcoming").
78+
79+
### Keyboard and Interaction Patterns
80+
81+
* Check if keyboard shortcuts use proper `<kbd>` tags.
82+
* Ensure interactive instructions don't assume mouse usage.
83+
* Verify multi-step procedures are numbered clearly.
84+
85+
## Output Format
86+
87+
For each issue found, display the following:
88+
89+
1. Line number and quote of problematic text
90+
2. Issue type from the previous checklist
91+
3. Specific problem explanation
92+
4. Suggested fix with concrete alternative wording
93+
94+
Group findings by priority: High, Medium, Low.
95+
96+
Also list positive accessibility features already present in the document.

0 commit comments

Comments
 (0)