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.

Quality

70%

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

Quality

Content

65%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 skill body is a well-structured, token-efficient overview that correctly pushes detail into references/rule.md, scoring strongly on progressive disclosure and conciseness. Its weakness is actionability and workflow clarity — the Check/Fix/Explain sections are templated and vague, with the concrete, executable guidance living only in the reference file.

Suggestions

Make the Check section actionable with concrete inspection steps (e.g., 'Confirm each <th> has scope="col"/"row"; verify <caption> or aria-labelledby is present; run axe/Lighthouse on the rendered table').

Turn the Fix section into specific, copy-ready fixes keyed to the Quick Reference rules instead of a single generic sentence.

Add an explicit verification step (e.g., 'Re-check with a screen reader or axe to confirm headers are announced per cell') so the workflow has a clear checkpoint.

Dimension	Reasoning	Score
Conciseness	The body is lean (~35 lines) with a concrete Quick Reference and no padding about concepts Claude already knows; the only mild over-explanation is the motivational opener about screen readers, which keeps it just below the 5 anchor.	4 / 5
Actionability	Quick Reference gives concrete rules (use <th> with scope, add <caption>, use id/headers for complex tables), but the Check/Fix/Explain sections are generic ('Verify tables use proper th elements...', 'Add proper table headers...') and the executable detail lives entirely in the reference file, leaving the body itself with incomplete guidance.	3 / 5
Workflow Clarity	Check → Fix → Explain → Code Review implies a loose sequence, but the sections read as analysis categories rather than a sequenced workflow, and there are no explicit verification checkpoints; this is acceptable for a non-destructive review skill but does not reach the 4 anchor.	3 / 5
Progressive Disclosure	The body is a clean overview that delegates full implementation, code examples, and framework guidance to a single one-level-deep, clearly signaled reference (references/rule.md), which exists in the bundle, matching the 5 anchor.	5 / 5
	Total	15 / 20 Passed

Description

75%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 the skill does and when to trigger it, with concrete review actions and natural trigger terms. Its main weakness is a copy-paste artifact — the rule title 'Use semantic table markup for screen readers' is embedded mid-sentence — which hurts readability and slightly broadens conflict risk.

Suggestions

Remove the duplicated rule title from inside the description (e.g., '...design-system patterns. Check native semantics first...') so the sentence reads naturally.

Tighten the trigger to the actual niche — mention 'data tables' / 'table markup' up front to reduce overlap with generic accessibility-review skills.

Lead with the concrete 'what' before the 'when' so the skill's purpose is immediately clear.

Dimension	Reasoning	Score
Specificity	Lists several concrete review actions — 'inspect keyboard behavior, focus flow, accessible names, and screen-reader output' — but coverage is review-oriented rather than a comprehensive set of concrete operations, so it sits below the 5 anchor.	4 / 5
Completeness	Both 'what' (check native semantics, inspect keyboard/focus/accessible-names/screen-reader output) and 'when' ('Use when reviewing rendered HTML, interactive components, or design-system patterns') are explicit, but the mid-sentence rule-title insertion muddies the phrasing, keeping it below the 5 anchor.	4 / 5
Trigger Term Quality	Includes natural terms a user would say ('rendered HTML', 'interactive components', 'design-system patterns', 'screen-reader output', 'keyboard behavior'), with good but not exhaustive synonym coverage; the embedded rule title 'Use semantic table markup for screen readers' is awkward but adds relevant keywords.	4 / 5
Distinctiveness Conflict Risk	The table/screen-reader niche is fairly distinct, yet the broad triggers ('rendered HTML, interactive components, or design-system patterns') overlap with general accessibility-review skills, so minor conflict risk remains versus the 5 anchor.	4 / 5
	Total	16 / 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/accessible-tables/SKILL.md
Commit: 30756a7

Reviewed: 17 days 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.