CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

fixing-accessibility

Audit, fix, and validate accessibility issues. Use when adding or reviewing controls, forms, dialogs, keyboard behavior, focus management, ARIA labels, color contrast, or WCAG compliance.

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./Skills/frontend-ui/fixing-accessibility/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

50%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a well-organized, concise process contract with sound fail-fast validation discipline, but it is entirely generic: it contains no accessibility-specific tools, checks, commands, or remediation patterns, so it does not tell Claude how to actually audit or fix accessibility. The deferred-content path also does not correspond to the bundle files that actually exist.

Suggestions

Name concrete validators and checks in the Validation section (e.g., axe-core, eslint-plugin-jsx-a11y, Lighthouse accessibility audit, computed contrast-ratio checks) so 'run the narrowest real validator' becomes executable.

Enumerate the accessibility surfaces to inspect in the workflow (e.g., focus order and traps, keyboard operability, ARIA roles/labels, form error messaging, color contrast ratios, semantic structure) instead of the generic 'Inspect 2-3 focused surfaces'.

Fix the Progressive Disclosure section to reference the actual bundle files (references/contract.yaml, references/evals.yaml, references/task-profile.json) rather than a non-existent 'Infrastructure/references/deferred-skill-context/...' path.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence, but it duplicates the frontmatter description verbatim ('Audit, fix, and validate accessibility issues...') and the 'Avoid', 'Gotchas', and 'Anti-Patterns' sections overlap in content, so a few tokens could be trimmed.

4 / 5

Actionability

Guidance is high-level with no concrete tools, commands, or specific accessibility checks — 'Inspect 2-3 focused surfaces' and 'Run the narrowest real validator or command path available' never name a validator (e.g., axe-core, eslint-plugin-jsx-a11y) or enumerate what to audit (contrast ratios, focus order, alt text). It provides process hints but is missing the specific steps to execute an accessibility audit or fix.

2 / 5

Workflow Clarity

A five-step sequence exists with explicit fail-fast and rerun checkpoints ('Stop at the first failed gate or blocker and report exact evidence', 'Rerun the relevant validation after fixes before claiming completion'), but the steps and gates are generic — no validator, command, or pass criterion is defined — leaving checkpoints implicit in practice.

3 / 5

Progressive Disclosure

Sections are well-organized and a deferred-loading policy is stated, but the single referenced path ('Infrastructure/references/deferred-skill-context/frontend-ui-fixing-accessibility/') does not match the actual bundle, whose files (references/contract.yaml, references/evals.yaml, references/task-profile.json) are never referenced by name — so navigation to bundle content is unclear.

3 / 5

Total

12

/

20

Passed

Description

83%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: concrete third-person actions, an explicit 'Use when...' clause with concrete trigger phrases, and a distinct accessibility niche. The only gaps are a few natural synonyms ('a11y', 'screen reader') and minor overlap risk on generic UI terms.

DimensionReasoningScore

Specificity

'Audit, fix, and validate accessibility issues' lists three concrete actions on a named domain, but the 'what' does not enumerate the specific audit/remediation actions, so it matches 'several specific actions; minor gaps' rather than comprehensive coverage.

4 / 5

Completeness

It explicitly answers both 'what' ('Audit, fix, and validate accessibility issues') and 'when' ('Use when adding or reviewing controls, forms, dialogs, keyboard behavior, focus management, ARIA labels, color contrast, or WCAG compliance') with concrete trigger phrases, matching the top anchor pattern.

5 / 5

Trigger Term Quality

Natural trigger coverage is strong ('controls, forms, dialogs, keyboard behavior, focus management, ARIA labels, color contrast, or WCAG compliance'), but common variations users actually say — 'a11y' and 'screen reader' — are missing, so it falls short of comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

Accessibility/WCAG/ARIA terms form a clear niche with minimal conflict, but generic trigger terms like 'controls, forms, dialogs' carry minor overlap risk with closely related frontend UI review skills.

4 / 5

Total

17

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository

jscraik/Agent-Skills

Path

Skills/frontend-ui/fixing-accessibility/SKILL.md

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.