CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

accessible-tables

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

61

Quality

77%

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/accessible-tables/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

78%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 compact, well-structured overview for a simple single-purpose review skill: a concrete Quick Reference, a clear Check/Fix/Explain workflow, and a properly signaled one-level-deep reference to a real file that carries the code examples and verification detail. The main weaknesses are mild — a redundant concept explanation, near-duplicative Check/Fix/Explain sections, and generic templated Code Review text.

DimensionReasoningScore

Conciseness

The body is lean and mostly earns its tokens: "Use <th> elements for headers with scope='col' or scope='row'", "Use id/headers for complex tables with merged cells" are tight and directive. Minor trimming opportunities keep it below 5: the opening concept explanation ("Screen readers read table data cell-by-cell—without proper headers, users hear meaningless numbers") tells Claude something it already knows, and the Check/Fix/Explain sections restate the same guidance three ways ("Add proper table headers with scope attributes, captions for context…").

4 / 5

Actionability

For an instruction-only skill the guidance is largely actionable: the Quick Reference names exact elements and attributes (th + scope='col'/'row', caption, id/headers for merged cells, CSS Grid/Flexbox over layout tables) and even reviewer prioritization ("Prefer one strong table-semantics finding over multiple weaker enhancements"). Not a 5 because some directives stay abstract ("ensure tables are not used for layout", "Check native semantics first, then inspect keyboard behavior…" — the Code Review section is generic template text rather than table-specific), and executable markup examples are deferred entirely to the reference file.

4 / 5

Workflow Clarity

The Check → Fix → Explain → Code Review sections give a clear, ordered review workflow, and verification is addressed ("note how to verify the fix with browser accessibility tooling or assistive tech"), with concrete automated/manual checks one level deep in references/rule.md. Not a 5 because the inline verification pointer is implicit rather than an explicit checkpoint — the actual validation steps (axe/Lighthouse, NVDA table navigation) live only in the reference file.

4 / 5

Progressive Disclosure

The ~35-line body is a genuine overview: a tight Quick Reference with the essentials, and a clearly signaled one-level-deep pointer — "For full implementation details, code examples, and framework-specific guidance, see references/rule.md" — which is a real file containing exactly that (code examples, scope attribute table, React component, verification steps). Content is appropriately split with no nested references and easy navigation.

5 / 5

Total

17

/

20

Passed

Description

66%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 has an explicit and useful "Use when…" trigger with several concrete review actions and natural keywords like "semantic table markup" and "screen readers". However, it reads as a category-level template: the actions and triggers are generic accessibility-review boilerplate rather than table-semantics-specific, and the awkward embedded rule title ("related to Use semantic table markup for screen readers") both garbles the phrasing and raises overlap risk with sibling accessibility skills sharing the same template.

Suggestions

Rewrite the trigger clause so the rule title integrates grammatically, e.g. "Use when reviewing or fixing data tables in rendered HTML — checking th/scope/caption semantics for screen readers" instead of "related to Use semantic table markup for screen readers".

Replace the generic action list with table-specific ones: "Flag tables missing <th> scope, <caption>, or id/headers on merged cells, and layout tables that should be CSS Grid/Flexbox."

Add distinguishing keywords ("accessibility", "data table", "table headers", "a11y") so it does not collide with sibling accessibility rules built from the same template.

DimensionReasoningScore

Specificity

Concrete actions are listed ("Check native semantics first", "inspect keyboard behavior, focus flow, accessible names, and screen-reader output"), but they are generic review-template actions — none are specific to table semantics (no th, scope, caption, or headers attributes), so coverage of the actual skill has more than minor gaps. Fits the 3 anchor (domain named, concrete actions present, not comprehensive) better than 4, whose "minor gaps" these are not.

3 / 5

Completeness

Both parts are explicitly present: the "what" via "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" and the "when" via "Use when reviewing rendered HTML, interactive components, or design-system patterns related to…" — so it clears the missing-'Use when' cap. Not a 5 because the "what" is generic boilerplate not tied to table markup, and the "when" clause is broad/templated rather than a concrete table-specific trigger.

4 / 5

Trigger Term Quality

Good natural keyword coverage: "semantic table markup", "screen readers", "rendered HTML", "interactive components", "keyboard", "focus" — phrases a user would plausibly say. A few natural terms are missing ("accessibility", "a11y", "table headers", "scope/caption"), and the templated embedding "related to Use semantic table markup" reads awkwardly, keeping it below the 5 anchor's comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

"semantic table markup for screen readers" carves out a niche, but the trigger surface "rendered HTML, interactive components, or design-system patterns" is broad, and the action list ("keyboard behavior, focus flow, accessible names") overlaps heavily with sibling accessibility skills that would share this identical template text. Matches the 3 anchor (somewhat specific but still overlaps with similar skills) rather than 4's "minor overlap risk only with closely related skills".

3 / 5

Total

14

/

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

Path

skills/accessible-tables/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.