CtrlK
BlogDocsLog inGet started
Tessl Logo

object-alt

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Provide alternative text for objects. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

60

Quality

71%

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/object-alt/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%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 lean, well-organized overview with a clean single-level pointer to references/rule.md, which verifiably contains the deferred code examples and verification steps. The main gap is actionability — the inline Check/Fix guidance stays high-level with no example markup, so Claude must open the reference before it can act concretely.

Suggestions

Inline one compact correct/incorrect `<object>` fallback markup pair (like the examples already in references/rule.md) so the Fix step is immediately actionable without loading the reference.

Cut the one-sentence rationale intro and fold the Quick Reference bullets into Check/Fix to remove duplication.

Turn the Code Review section's verification mention into an explicit checkpoint, e.g., "After fixing, re-check the element in the browser accessibility tree or with axe/Lighthouse."

DimensionReasoningScore

Conciseness

The ~30-line body is efficient with clear sections and mostly earns its tokens, but the intro sentence ("If an object fails to load...alternative text ensures that the information is still accessible") explains a concept Claude already knows, and the Quick Reference bullets largely duplicate the Check/Fix sections.

4 / 5

Actionability

"Check all `<object>` elements in the HTML to ensure they contain descriptive fallback content" and "Add alternative text or a semantic fallback inside the `<object>` tags" give concrete but incomplete guidance — no example of good fallback markup or a specific fix pattern appears in the body (it is all deferred to the reference file).

3 / 5

Workflow Clarity

Check → Fix → Explain → Code Review sequences the review task clearly, and verification is mentioned ("note how to verify the fix with browser accessibility tooling or assistive tech"), but it is a mention rather than an explicit checkpoint with a retry loop, so it falls short of a 5.

4 / 5

Progressive Disclosure

The body is a concise, well-sectioned overview that clearly signals a one-level-deep reference ("For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`"), and that file exists and indeed holds the code examples, exceptions, and verification details the body defers.

5 / 5

Total

16

/

20

Passed

Description

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

The description explicitly covers both what and when with several concrete review actions and decent natural trigger terms. Its main weakness is distinctiveness: the boilerplate review language dominates, leaving the rule title as the only differentiator from sibling accessibility skills.

Suggestions

Replace the generic action list with object-specific checks, e.g., "Verify every <object> element contains descriptive fallback content (text links, fallback images) so users who cannot load the object still get the information."

Add natural trigger phrasings users would actually say: "alt text", "object fallback", "accessibility review", and "<object> element".

Differentiate from sibling accessibility skills by leading with the object/alt-text niche rather than the shared "reviewing rendered HTML, interactive components, or design-system patterns" template.

DimensionReasoningScore

Specificity

Lists several concrete review actions ("Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output") but they are generic accessibility-review steps with minor gaps — no object-specific checks like fallback content or alt text verification are named.

4 / 5

Completeness

Both what ("Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output") and when ("Use when reviewing rendered HTML, interactive components, or design-system patterns") are explicitly present, but the when embeds the rule title awkwardly and lacks concrete trigger phrases a user would naturally say.

4 / 5

Trigger Term Quality

Good keyword coverage with natural terms ("rendered HTML", "keyboard behavior", "focus flow", "accessible names", "screen-reader output", "alternative text"), but common user phrasings like "alt text", "accessibility", "fallback content", and "<object>" are missing.

4 / 5

Distinctiveness Conflict Risk

The action clauses are generic accessibility-review boilerplate shared by sibling rule skills; only the embedded rule title "Provide alternative text for objects" distinguishes it, so it could still overlap with other accessibility-check skills.

3 / 5

Total

15

/

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
thedaviddias/Front-End-Checklist
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.