CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

63

Quality

75%

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

57%

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

A well-structured, appropriately split body that delegates detail to a real reference file. It is weakened by repetition between sections, abstract Check/Fix/Explain prose, and an implicit rather than explicit verification step.

Suggestions

Replace the abstract Check/Fix/Explain prose with a short concrete checklist or a minimal runnable HTML snippet, or fold them into the Quick Reference to remove repetition.

Add an explicit verification checkpoint (e.g. 'Run axe/Lighthouse on a rendered state; confirm headers are announced') rather than only hinting at verification in the Code Review section.

Trim the intro's explanation of how screen readers work — Claude already knows this — and lead with the rule and its strongest finding.

DimensionReasoningScore

Conciseness

The body is mostly lean, but the intro restates how screen readers work ('Screen readers read table data cell-by-cell...') and the Check/Fix/Explain sections repeat the Quick Reference bullets, so it could be tightened.

2 / 3

Actionability

Quick Reference gives concrete items ('Use <th> with scope', 'Add <caption>'), but Check/Fix/Explain are abstract ('Verify tables use proper th elements...') with no executable code in the body — concrete guidance is present but incomplete.

2 / 3

Workflow Clarity

The Check/Fix/Explain/Code Review sections provide a loose sequence, but verification is only implicit ('note how to verify the fix') rather than an explicit checkpoint, matching the 'steps listed but validation gaps' anchor.

2 / 3

Progressive Disclosure

The body is a concise overview that clearly signals a single one-level-deep reference ('see references/rule.md'), and that file exists and holds the detailed examples — matching the well-organized, clear-navigation anchor.

3 / 3

Total

9

/

12

Passed

Description

92%

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, third-person description with explicit triggers and concrete actions covering both what and when. Its main weakness is the broad review trigger surface and a garbled mid-sentence rule-title insertion that slightly muddies distinctiveness.

Suggestions

Tighten the embedded rule title — 'patterns related to Use semantic table markup for screen readers' reads as a copy-paste artifact; integrate it grammatically (e.g. 'patterns involving semantic table markup').

Narrow the 'Use when' trigger toward table-specific contexts (e.g. 'when reviewing data tables or table-like markup') to reduce overlap with general accessibility skills.

DimensionReasoningScore

Specificity

The description names multiple concrete actions — 'reviewing rendered HTML, interactive components, or design-system patterns' and 'inspect keyboard behavior, focus flow, accessible names, and screen-reader output' — matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

It explicitly answers 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').

3 / 3

Trigger Term Quality

It uses natural terms a reviewer would say ('rendered HTML', 'interactive components', 'design-system patterns', 'screen-reader output') with a clear 'Use when' clause. The awkwardly embedded rule title slightly weakens phrasing but the keyword coverage is strong.

3 / 3

Distinctiveness Conflict Risk

Although the underlying rule is narrow (table markup for screen readers), the trigger surface ('rendered HTML, interactive components, or design-system patterns') is broad and could overlap with general accessibility-review skills, fitting the 'somewhat specific but could still overlap' anchor.

2 / 3

Total

11

/

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.