CtrlK
BlogDocsLog inGet started
Tessl Logo

aria-text

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Avoid focusable descendants in role='text' elements. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

65

Quality

78%

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/aria-text/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%

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-structured overview that correctly defers detailed code and verification to references/rule.md (one level deep). Its weaknesses are mild internal redundancy and guidance that stays directional rather than executable, with verification checkpoints left implicit.

Suggestions

Tighten redundancy: the 'no interactive/focusable children inside role=text' rule appears in the opening paragraph, Quick Reference, and Check section — consolidate to one statement and one scannable bullet list.

Make the verification loop explicit in the body: after Fix, add a 'Re-check' step (re-run the accessibility tree inspection / keyboard test and confirm the fix holds) rather than only 'note how to verify the fix'.

Surface one concrete inline verification cue — e.g., 'inspect the browser accessibility tree' or 'run axe/Lighthouse' — instead of the generic 'browser accessibility tooling or assistive tech', so the body is actionable without opening the reference.

DimensionReasoningScore

Conciseness

Mostly efficient, but the 'no interactive/focusable children inside role=text' point is restated three times — the opening 'effectively hides any interactive elements', the Quick Reference 'should not contain interactive children', and the Check 'verify they do not contain any focusable elements' — so it could be tightened rather than earning 'every token earns its place'.

2 / 3

Actionability

Concrete direction is present ('Remove role="text" from containers that have interactive children or move the interactive elements outside'), but executable specifics — tool commands and code examples — are deferred to references/rule.md, and verification is only 'browser accessibility tooling or assistive tech', leaving key details in the reference.

2 / 3

Workflow Clarity

A clear Check → Fix → Explain → Code Review sequence exists, but validation is only a passing 'note how to verify the fix' with no explicit validate→fix→re-verify checkpoint, so checkpoints are implicit rather than the explicit feedback loop of the top anchor.

2 / 3

Progressive Disclosure

A concise overview points cleanly to one-level-deep detail — 'For full implementation details, code examples, and framework-specific guidance, see references/rule.md' — and rule.md is a real, self-contained file with no nested references, matching the 'clear overview with well-signaled one-level-deep references' anchor.

3 / 3

Total

9

/

12

Passed

Description

100%

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 is well-crafted: it pairs an explicit 'Use when' trigger with a concrete list of review actions and is scoped to a distinct ARIA niche. Voice is third person and there is no vague fluff.

DimensionReasoningScore

Specificity

Lists multiple concrete review actions — 'Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output' — matching the 'lists multiple specific concrete actions' anchor rather than the vague single-action level below.

3 / 3

Completeness

Explicitly answers both: 'Use when reviewing rendered HTML...' (when) and 'Check native semantics first, then inspect...' (what); the present 'Use when' clause satisfies the trigger-guidance requirement that would otherwise cap completeness at 2.

3 / 3

Trigger Term Quality

Covers natural terms a user would say — 'reviewing rendered HTML, interactive components, or design-system patterns' plus 'keyboard behavior, focus flow, accessible names, and screen-reader output' — giving good coverage rather than only 'some relevant keywords'.

3 / 3

Distinctiveness Conflict Risk

Targets a narrow, well-defined niche — 'Avoid focusable descendants in role="text" elements' — with distinct triggers unlikely to collide with other skills, matching the 'clear niche with distinct triggers' anchor.

3 / 3

Total

12

/

12

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.

Validation15 / 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.