CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

aria-live-regions

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Announce dynamic content with ARIA live regions. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

Quality

80%

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-live-regions/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.

A well-organized, lean instruction body for a simple single-purpose review skill: exact attribute values and roles in the Quick Reference, a coherent check/fix/explain flow with fix-verification guidance, and an appropriately split structure pointing to a real one-level-deep reference file. Remaining gaps are minor — trim the motivational opener and duplicated URL, add one inline markup example, and merge the overlapping Check/Code Review sections.

Suggestions

Drop the motivational first sentence (screen-reader users missing updates is known context) and the duplicated rule-page URL to tighten the token budget.

Add one minimal inline example such as `<div role="status" aria-live="polite">Item added to cart</div>` to make the guidance copy-paste ready.

Merge the overlapping Check and Code Review sections into a single review step so the workflow reads as one unambiguous sequence.

DimensionReasoningScore

Conciseness

The body is lean and well-sectioned; the Quick Reference bullets deliver dense, useful specifics. Not 5 because the motivational opener ("they won't know their form submitted, their cart updated, or an error occurred") explains motivation Claude already knows, and the rule URL is duplicated from the frontmatter.

4 / 5

Actionability

Concrete, specific directives with exact attribute values and roles — "Use aria-live='polite' for non-urgent updates (cart count, status messages)", "Add aria-live attributes with correct politeness levels (polite, assertive)", plus the key timing gotcha "The live region must exist in DOM before content changes". Not 5 because there is no inline markup example (e.g. a `<div role="status">` snippet) and the Check section is a single generic sentence.

4 / 5

Workflow Clarity

The Check → Fix → Explain sequence is coherent and the Code Review section adds verification guidance ("note how to verify the fix with browser accessibility tooling or assistive tech"), which suits this non-destructive review skill. Not 5 because the Check and Code Review sections substantially overlap, blurring the workflow, and steps are not sharply sequenced.

4 / 5

Progressive Disclosure

The short body is a clear overview with a single well-signaled, one-level-deep reference — "For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`" — and the referenced file exists (156 lines) with no nested references. Content is appropriately split and navigation is easy.

5 / 5

Total

17

/

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.

A solid description with an explicit "Use when" trigger, concrete review actions, and good natural keywords, but it is held back by an awkward construction where the rule title "Announce dynamic content with ARIA live regions" is pasted mid-sentence, and by generic review boilerplate that dilutes distinctiveness. Rewriting the embedded clause into a natural sentence and adding live-region-specific synonyms would lift it to the top anchor.

Suggestions

Rewrite the mangled clause "related to Announce dynamic content with ARIA live regions" into natural prose, e.g. "Use when reviewing rendered HTML or interactive components that announce dynamic content (notifications, form errors, cart updates) via ARIA live regions."

Add common trigger synonyms such as "aria-live", "role=alert", "role=status", or "screen reader announcements" so users phrasing the need differently still match.

Replace the generic checklist boilerplate with at least one live-region-specific action (e.g. "check politeness levels and that the live region exists in the DOM before content changes") to sharpen the what and reduce overlap with sibling accessibility rules.

DimensionReasoningScore

Specificity

Lists several concrete actions — "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" — anchored in a stated domain (rendered HTML, ARIA live regions). Not 5 because the actions are the generic accessibility-review checklist rather than comprehensive live-region-specific coverage, and the core capability is muddled by the awkwardly embedded rule title "related to Announce dynamic content with ARIA live regions".

4 / 5

Completeness

Both parts are explicitly present: "Use when reviewing rendered HTML, interactive components, or design-system patterns..." (when) and "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" (what). Not 5 because the when-clause is broad (any rendered-HTML review) and the what-phrase is grammatically mangled by the mid-sentence rule title, making both less crisp than the 5-anchor examples.

4 / 5

Trigger Term Quality

Contains strong natural terms users would say — "ARIA live regions", "screen-reader output", "dynamic content", "rendered HTML", "interactive components". Not 5 because common variations like "aria-live", "announcements", "notifications", or "role=alert" are missing; not 3 because the keywords are domain-specific and natural, well beyond generic jargon.

4 / 5

Distinctiveness Conflict Risk

"ARIA live regions" is a clear niche term that distinguishes this skill and gives distinct triggers. Not 5 because the surrounding boilerplate ("reviewing rendered HTML, interactive components, or design-system patterns... check native semantics, keyboard behavior, focus flow") is generic accessibility-review language that overlaps with closely related sibling accessibility skills.

4 / 5

Total

16

/

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/aria-live-regions/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.