video-accessibility

Use when reviewing templates, rendered HTML, or shared components related to Make videos accessible with captions. Validate the final browser-facing markup, not just the source framework abstraction.

Quality

73%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/video-accessibility/SKILL.md

Quality

Content

77%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.

A lean, well-structured rule skill whose reference bundle is correctly used for depth while the body stays navigable. Its main inefficiency is redundancy between Quick Reference and Check plus an Explain section that restates common accessibility knowledge.

Suggestions

Merge the Quick Reference into the Check section (or vice versa) — the two currently repeat the same caption/audio-description/autoplay items nearly verbatim.

Trim the Explain section to a one-line pointer on when to communicate rationale rather than restating how captions help deaf users, which Claude already knows.

Inline one minimal <track kind="captions"> snippet so the fix is executable without opening the reference, and state concretely where a transcript should be provided.

Dimension	Reasoning	Score
Conciseness	The ~30-line body is mostly tight, but the Quick Reference section duplicates the Check section ('Always provide accurate closed captions (not auto-generated)' vs. 'Verify videos have accurate closed captions (not auto-generated)'), and the Explain section re-teaches concepts Claude already knows (how captions help deaf and hard-of-hearing users). Not 2: padding is modest; not 4: the duplication and known-concept explanation are real inefficiencies.	3 / 5
Actionability	Check and Fix give concrete directives ('Add track elements for captions and audio descriptions', 'Confirm spacebar pauses video without scrolling the page'), and the executable code lives in references/rule.md. Not 5: there is no inline code snippet, and guidance on transcripts and focus management stays high-level.	4 / 5
Workflow Clarity	This is a simple single-purpose skill and the Check -> Fix -> Explain -> Code Review sequence is unambiguous, with a concrete validation check ('Confirm spacebar pauses video without scrolling the page'). The simple-skill exception applies; no destructive or batch operations are involved.	5 / 5
Progressive Disclosure	Under 50 lines with well-organized sections and a single, clearly signaled one-level-deep reference ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md') that exists in the bundle and holds the full code example. No nesting or buried references.	5 / 5
	Total	17 / 20 Passed

Description

70%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 solid description with an explicit trigger clause and a genuine what/when distinction, but it leans on trigger phrasing while only hinting at the concrete checks the skill performs. Enumerating the actual accessibility checks would lift specificity and completeness.

Suggestions

Enumerate the concrete capabilities in the description (e.g., check captions tracks, audio descriptions, transcripts, keyboard-accessible controls, and autoplay settings) to raise specificity from domain-plus-actions to a comprehensive action list.

Add natural trigger synonyms such as 'transcripts', 'autoplay', or 'a11y/accessibility' so users phrasing the need differently still match this skill.

Differentiate the trigger from sibling markup-review skills by anchoring it to video-specific contexts (e.g., 'Use when code outputs <video> or <track> elements') to reduce conflict risk.

Dimension	Reasoning	Score
Specificity	Names the domain (video accessibility in markup review) and 1-2 concrete actions ('reviewing templates, rendered HTML, or shared components', 'Validate the final browser-facing markup'), but never enumerates the actual capabilities (captions, audio descriptions, transcripts, autoplay, keyboard controls). Not 4: the coverage gaps are more than minor.	3 / 5
Completeness	Both parts are present: an explicit 'Use when reviewing templates, rendered HTML, or shared components...' trigger and a what ('Validate the final browser-facing markup, not just the source framework abstraction'). Not 5: the what says to validate markup without stating what to validate, so it is less explicit than it could be.	4 / 5
Trigger Term Quality	Good natural keywords a user would say: 'templates', 'rendered HTML', 'shared components', 'videos', 'captions'. Not 5: common variations such as 'transcripts', 'autoplay', 'accessibility', or 'a11y' are missing.	4 / 5
Distinctiveness Conflict Risk	The video/captions niche is clearly distinct with specific triggers. Not 5: the boilerplate 'reviewing templates, rendered HTML, or shared components' phrasing would equally match sibling frontend markup-review skills, creating minor overlap risk.	4 / 5
	Total	15 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/video-accessibility/SKILL.md
Commit: 7bfd868

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

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.