|
| 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