android-accessibility
Expert checklist and prompts for auditing and fixing Android accessibility issues, especially in Jetpack Compose.
Install with Tessl CLI
npx tessl i github:new-silvermoon/awesome-android-agent-skills --skill android-accessibility62
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
Discovery
32%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description identifies a clear domain (Android accessibility in Jetpack Compose) but lacks the specificity and completeness needed for reliable skill selection. It fails to include explicit trigger guidance and misses common user terminology, making it harder for Claude to know when to select this skill from a large pool.
Suggestions
Add a 'Use when...' clause with explicit triggers like 'Use when the user asks about Android accessibility, TalkBack support, a11y issues, or accessible Compose components'
List specific concrete actions such as 'audit content descriptions, fix focus order, implement semantic properties, test with TalkBack'
Include common user terminology variations: 'a11y', 'screen reader', 'TalkBack', 'accessibility scanner', 'content description'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Android accessibility, Jetpack Compose) and mentions 'auditing and fixing' as actions, but lacks specific concrete actions like 'add content descriptions', 'fix focus order', or 'implement TalkBack support'. | 2 / 3 |
Completeness | Describes what it does (checklist/prompts for auditing accessibility) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. | 1 / 3 |
Trigger Term Quality | Includes relevant keywords like 'Android', 'accessibility', 'Jetpack Compose', but misses common user terms like 'a11y', 'screen reader', 'TalkBack', 'content description', or 'accessible'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'Android accessibility' and 'Jetpack Compose' provides some distinctiveness, but 'accessibility issues' is broad enough to potentially overlap with general accessibility or other Android development skills. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, concise accessibility checklist that efficiently covers key Android/Compose accessibility concerns. Its main weakness is the lack of executable code examples showing how to implement the fixes (e.g., actual Modifier.semantics usage), which limits immediate actionability for an agent.
Suggestions
Add executable Kotlin/Compose code snippets for each fix, such as a complete example of Modifier.semantics(mergeDescendants = true) or MinTouchTargetSize usage.
Include a brief sequential workflow for conducting an accessibility audit (e.g., 1. Run TalkBack, 2. Check each category, 3. Verify fixes with accessibility scanner).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient, presenting only essential accessibility criteria without explaining what accessibility is or how Android/Compose works. Every section delivers actionable standards without padding. | 3 / 3 |
Actionability | Provides specific standards (48x48dp, 4.5:1 contrast) and mentions specific APIs (Modifier.semantics, mergeDescendants), but lacks executable code examples. The fixes are described rather than demonstrated with copy-paste ready snippets. | 2 / 3 |
Workflow Clarity | The checklist format provides clear categories to check, but lacks a sequential workflow for conducting an audit. No validation steps or feedback loops for verifying fixes are included. | 2 / 3 |
Progressive Disclosure | For a simple checklist skill under 50 lines, the content is well-organized with clear section headers. No external references are needed, and the structure allows easy scanning of each accessibility aspect. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
68%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 16 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
description_trigger_hint | Description may be missing an explicit 'when to use' trigger hint (e.g., 'Use when...') | Warning |
metadata_version | 'metadata' field is not a dictionary | Warning |
license_field | 'license' field is missing | Warning |
body_output_format | No obvious output/return/format terms detected; consider specifying expected outputs | Warning |
body_steps | No step-by-step structure detected (no ordered list); consider adding a simple workflow | Warning |
Total | 11 / 16 Passed | |
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.