CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

ios-accessibility

Implement or audit accessibility for SwiftUI, UIKit, and AppKit, including VoiceOver, Dynamic Type, focus, actions, traversal, contrast, motion preferences, keyboard access, and accessibility testing. Use when accessibility behavior or compliance evidence is in scope.

Quality

88%

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

SKILL.md
Quality
Evals
Security

Quality

Content

92%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.

An excellent instruction-only skill body: lean prescriptive rules, a sequenced audit workflow with explicit re-verification, and clean progressive disclosure into three real, well-scoped reference files. The only minor weakness is that a few directives (announcements, focus restoration, contrast checking) defer their concrete APIs or thresholds entirely to the reference file rather than naming them inline.

DimensionReasoningScore

Conciseness

The body is lean and directive throughout ("Expose changing state through value or traits, not only color or animation", "Hide decorative content, but never hide information needed to understand state or complete a task") with zero padding and no explanation of concepts Claude already knows; every line states a project-specific rule, routing decision, or verification requirement, so it matches "every token earns its place".

5 / 5

Actionability

Guidance is largely concrete — named modifiers (".accessibilityLabel", ".accessibilityAction", ".isButton"), named tools (Accessibility Inspector), named system preferences (Reduce Motion, Reduce Transparency, Differentiate Without Color, Increased Contrast, Button Shapes), and specific routing targets — but a few directives lack their API or invocation in the body ("Announce important asynchronous outcomes" and "restore focus" name no API; contrast has no threshold or Inspector audit step), leaving minor gaps appropriate for anchor 4.

4 / 5

Workflow Clarity

The five-step Audit Workflow is a clearly sequenced process with an explicit re-validation step ("Re-run automated checks and manually exercise the affected assistive-technology path") forming a fix-then-verify feedback loop, reinforced by a dedicated Verification section and a ten-item Review Checklist — matching "clear sequence with explicit validation steps... checklists for complex processes".

5 / 5

Progressive Disclosure

The body is a well-organized overview with clearly signaled, one-level-deep references — "Read [Accessibility Patterns](references/a11y-patterns.md) for SwiftUI/UIKit/AppKit recipes, focus management, rotors, and XCTest examples" — and all three referenced files exist with substantive content matching those claims (verified: recipes, focus, rotors, XCTest sections present; no nested .md chains); the split (patterns / media / store declarations) is appropriate and navigation is easy.

5 / 5

Total

19

/

20

Passed

Description

78%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 strong description that answers both what (implement/audit across an enumerated set of accessibility areas for Apple frameworks) and when (explicit "Use when" clause), using third person and Apple-specific trigger terms. The "when" clause is somewhat abstract and natural-term coverage omits common synonyms like "a11y", "screen reader", and "WCAG".

Suggestions

Make the trigger clause concrete: e.g. "Use when the user mentions accessibility, VoiceOver, Dynamic Type, screen readers, or asks for an accessibility audit or WCAG/ADA compliance evidence" instead of the abstract "is in scope" phrasing.

Add natural synonyms such as "a11y", "screen reader", and "assistive technology" to widen trigger-term coverage.

Mention the remaining capability areas (Switch Control, Voice Control) in the enumeration to close the specificity gap.

DimensionReasoningScore

Specificity

"Implement or audit accessibility for SwiftUI, UIKit, and AppKit, including VoiceOver, Dynamic Type, focus, actions, traversal, contrast, motion preferences, keyboard access, and accessibility testing" names the domain with a broad, mostly comprehensive enumeration of capability areas, but the concrete action verbs are limited to "implement or audit" and a few areas (Switch Control, Voice Control, hearing accessibility) go unmentioned — "lists several specific actions; minor gaps in coverage" rather than the fully comprehensive anchor 5.

4 / 5

Completeness

Both parts are present: a clear "what" ("Implement or audit accessibility for SwiftUI, UIKit, and AppKit, including...") and an explicit "Use when accessibility behavior or compliance evidence is in scope" clause, so it clears the anchor-3 cap; but the "when" is abstract phrasing ("is in scope") rather than concrete trigger phrases like "when the user mentions VoiceOver or asks for an accessibility audit", keeping it at anchor 4.

4 / 5

Trigger Term Quality

Natural terms users would say are present — "accessibility", "VoiceOver", "Dynamic Type", "contrast", "keyboard access" — but common synonyms and variations ("a11y", "screen reader", "WCAG", "assistive technology") are missing, matching "good keyword coverage; a few natural terms missing" rather than comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

"accessibility for SwiftUI, UIKit, and AppKit" combined with strongly Apple-specific triggers (VoiceOver, Dynamic Type) carves out a clear niche with distinct triggers and minimal conflict risk against generic UI, layout, or animation skills; "compliance evidence" reads as accessibility-compliance evidence (audit reports, testing), which belongs to this skill.

5 / 5

Total

17

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

thienqo/ios-skills

Path

skills/ios-accessibility/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.