Review and improve accessibility of UI for web and mobile.
SkillScore100Maintained
Automatic
◆Frontend / UI pack
Last verified 8/3/2026
What it changes
Passed 22 of 22 test cases with the skill, and 21 of 22 without it.
Without skill95%
With skill100%
Checks it passed that the model alone missed
Set the minimum touch target dimension to at least 44 by 44 units.
1 fixed21 passed either way0 still failing0 broke
Pass-rate lift
+5 pp
Tokens
+24%
Agent turns
0%
Response time
-29%
Model gemini-3.6-flashMeasured 8/3/2026v122 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
Design a small React Native touchable icon button for a mobile application toolbar where layout space is constrained. What size dimensions should be set for the touchable area?
What was checked, without and with the skill
Checked
Without skill
With skill
Set the minimum touch target dimension to at least 44 by 44 units.
Missed
Passed
case-07 · gemini-3.6-flash · 8/3/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md67 linessingle file
Accessibility Skill
Purpose
Ensure UI is usable via keyboard, screen readers, and assistive technology, and meets baseline accessibility expectations, without breaking visual design.
When to Use
Building new interactive UI (forms, buttons, modals, menus, custom widgets).
Reviewing existing UI for accessibility gaps.
As part of finishing any UI task, before marking it complete.
Static, non-interactive decorative elements with no semantic meaning (though these still need correct handling, e.g. alt="" or aria-hidden).
Required Inputs
The component/page/screen being built or reviewed.
Platform context: web (HTML/ARIA) vs. native (Expo/React Native accessibility props).
Assumptions
Semantic HTML/native elements are the first choice; ARIA/custom props are a supplement, not a replacement.
Visual design and accessibility are not in conflict — accessible patterns can be styled to match design.
Step-by-Step Workflow
Use semantic elements first: <button> for actions, <a> for navigation, <label> for form fields, headings (<h1>–<h6>) for structure, lists for grouped items.
Check interactive elements:
Are all clickable elements actually interactive elements (button, a, native Pressable/TouchableOpacity with accessibility props), not div/span with onClick only?
Can every interactive element be reached and activated via keyboard (web) — Tab to focus, Enter/Space to activate?
Check focus states: every focusable element has a visible focus indicator; focus order follows a logical reading order.
Check forms:
Every input has an associated label (<label for> or aria-label).
Error messages are associated with their input (e.g. aria-describedby) and announced.
Required fields are indicated both visually and programmatically.
Check images/icons: meaningful images have descriptive alt text; decorative images/icons use alt="" or aria-hidden="true".
Check dynamic content: loading states, error messages, and important updates are announced to assistive tech (e.g. aria-live where appropriate) without being overused.
Check color/contrast: text and interactive elements meet reasonable contrast against their background (don't rely on color alone to convey state/errors — pair with text/icon).
For Expo/React Native: use accessible, accessibilityLabel, accessibilityRole, accessibilityState props; ensure touch targets meet minimum size (~44x44pt).
Re-check after styling changes: confirm focus, hover, disabled, and error states are still visually distinguishable.
Rules and Best Practices
Use ARIA only when native semantics genuinely aren't enough — don't add redundant ARIA to elements that already convey the right semantics.