tabs-accessibility

Use when reviewing templates, rendered HTML, or shared components related to Make tabs keyboard navigable. Validate the final browser-facing markup, not just the source framework abstraction.

Quality

66%

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/tabs-accessibility/SKILL.md

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 skill is well-structured with good progressive disclosure and specific ARIA role names, but it suffers from mild redundancy, lacks any inline executable markup example, and has no validation/verification step in its review workflow. Adding a concrete HTML snippet and a re-verification checkpoint would lift the weaker dimensions.

Suggestions

Add a short copy-paste-ready correct tabs HTML snippet (tablist/tab/tabpanel with aria-selected and roving tabindex) inline instead of deferring all code to the reference.

Remove the redundancy between Quick Reference and the Check/Fix sections, or merge them so each role appears once.

Add an explicit verification step such as 'After fixing, re-test by tabbing through and confirming only one tab is in the tab order and arrow keys move between tabs.'

Dimension	Reasoning	Score
Conciseness	The body is mostly lean with bullet points, but the Check and Fix sections restate the same roles already listed in Quick Reference, and the opening sentence explains impact ('trap keyboard users', 'screen reader users unable to understand') that Claude already knows.	2 / 3
Actionability	It names specific ARIA roles and attributes (tablist, tab, tabpanel, aria-selected, aria-controls/aria-labelledby), but provides no inline executable HTML example, defers code to the reference, and leaves 'proper keyboard interaction patterns' vague.	2 / 3
Workflow Clarity	Sections are sequenced (Check -> Fix -> Explain -> Code Review), but there are no validation checkpoints or feedback loops such as 're-verify with the keyboard after fixing', which the rubric expects for a 3.	2 / 3
Progressive Disclosure	A concise overview points to a single well-signaled, one-level-deep reference ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md'), and that file exists, matching the clear-overview anchor.	3 / 3
	Total	9 / 12 Passed

Description

75%

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 clearly covers both what and when with an explicit 'Use when' trigger and a well-scoped niche, but its action verbs are somewhat generic and the phrasing leans technical in places. Tightening the jargon and naming more concrete review/fix actions would raise specificity and trigger quality.

Suggestions

Replace jargon like 'source framework abstraction' and 'browser-facing markup' with terms users naturally say (e.g., 'rendered HTML', 'final page HTML').

List more concrete actions (e.g., 'check ARIA roles, verify roving tabindex, flag missing aria-selected') instead of generic 'reviewing' and 'Validate'.

Add common trigger variations such as 'tabs accessibility', 'ARIA tabs', or 'keyboard navigation'.

Dimension	Reasoning	Score
Specificity	It names the domain (tabs accessibility) and a couple of actions ('reviewing templates, rendered HTML, or shared components', 'Validate the final browser-facing markup'), but these are generic verbs rather than a list of multiple distinct concrete operations like extract/fill/merge, so it falls short of 3.	2 / 3
Completeness	It explicitly answers both what ('Validate the final browser-facing markup') and when via an explicit 'Use when reviewing templates, rendered HTML, or shared components...' trigger clause, satisfying the rubric's bar for an explicit trigger.	3 / 3
Trigger Term Quality	Relevant natural keywords appear ('templates', 'rendered HTML', 'shared components', 'tabs', 'keyboard navigable'), but the description mixes in technical jargon ('browser-facing markup', 'source framework abstraction') that users would not naturally say, keeping it below 3.	2 / 3
Distinctiveness Conflict Risk	It targets a clear niche (keyboard-navigable tabs in rendered HTML/components) with distinct triggers, making it unlikely to fire for unrelated skills.	3 / 3
	Total	10 / 12 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/tabs-accessibility/SKILL.md
Commit: 48405aa

Reviewed: about 8 hours 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.