ios-test
Build, launch, and visually test iOS/SwiftUI apps in the Simulator using computer use. Automated screen navigation, crash log analysis, state testing…
Scan SwiftUI views and add missing accessibility identifiers using a consistent {screen}-{type}-{name} naming convention. Also flags Dynamic Type compatibility issues. Use when you need to add accessibility support, make views testable, add VoiceOver labels, or prepare for UI
$ npx -y skills add yusufkaran/swiftui-autotest-skill --skill add-accessibility --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/add-accessibilityContext preview
The summary Claude sees to decide when to auto-load this skill.
Scan SwiftUI views and add missing accessibility identifiers using a consistent {screen}-{type}-{name} naming convention. Also flags Dynamic Type compatibility issues. Use when you need to add accessibility support, make views testable, add VoiceOver labels, or prepare for UI
name: add-accessibility
description: Scan SwiftUI views and add missing accessibility identifiers using a consistent {screen}-{type}-{name} naming convention. Also flags Dynamic Type compatibility issues. Use when you need to add accessibility support, make views testable, add VoiceOver labels, or prepare for UI testing.Use this skill to scan all SwiftUI files in a project, find interactive elements missing accessibility identifiers, and add them using a consistent `{screen}-{type}-{name}` naming convention. Also flags Dynamic Type compatibility issues without auto-fixing them.
1. Find all `*.swift` files in the project 2. Filter to files containing SwiftUI views (`struct X: View`, `#Preview`, etc.) 3. In each file, detect these interactive elements:
4. For each element, check existing accessibility state:
Naming convention: `{screen}-{type}-{name}`
**Screen name**: derived from the filename
**Type**: based on the element type
| SwiftUI Element | Type | |----------------|------| | Button | `button` | | TextField | `textfield` | | SecureField | `securefield` | | Image | `image` | | Toggle | `toggle` | | Slider | `slider` | | Picker | `picker` | | DatePicker | `datepicker` | | NavigationLink | `navlink` | | Link | `link` | | .onTapGesture view | `tap` | | TabView item | `tab` |
**Name**: derived from the element's content
**Example results:**
login-button-continue login-textfield-email login-securefield-password onboarding-image-hero-banner settings-toggle-notifications home-tab-profile
Add `.accessibilityIdentifier("generated-id")` to each element missing one:
// BEFORE
Button("Continue") {
viewModel.proceed()
}
// AFTER
Button("Continue") {
viewModel.proceed()
}
.accessibilityIdentifier("login-button-continue")**For Images**, also add `accessibilityLabel` (for VoiceOver):
// BEFORE
Image(systemName: "gear")
// AFTER
Image(systemName: "gear")
.accessibilityIdentifier("settings-image-gear")
.accessibilityLabel("Settings")**For onTapGesture views**, mark as accessibility elements:
// BEFORE
HStack {
Image("avatar")
Text(user.name)
}
.onTapGesture { showProfile() }
// AFTER
HStack {
Image("avatar")
Text(user.name)
}
.onTapGesture { showProfile() }
.accessibilityElement(children: .combine)
.accessibilityIdentifier("profile-tap-user-row")
.accessibilityAddTraits(.isButton)Check Text elements for Dynamic Type compatibility:
1. **Flag** (report as warnings, do NOT auto-fix):
2. **Report format:**
⚠️ Dynamic Type Warnings:
LoginView.swift:42 - Text("Welcome back...") → missing lineLimit or minimumScaleFactor
LoginView.swift:58 - Text(...).font(.system(size: 14)) → consider using dynamic font (.body, .caption, etc.)
SettingsView.swift:23 - Text(longString) → missing lineLimit, risk of overflow with large textShow a summary when the scan is complete:
✅ Accessibility Scan Complete
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Files scanned: 24
Elements found: 87
Already present: 31 (skipped)
Newly added: 56
- Button: 18
- TextField: 8
- Image: 12
- Toggle: 6
- Other: 12
⚠️ Dynamic Type Warnings: 7
(details above)
Pattern: {screen}-{type}-{name}1. **NEVER modify or remove existing accessibility modifiers** 2. **NEVER change the view's functionality or appearance** 3. Only add `.accessibilityIdentifier()`, `.accessibilityLabel()`, `.accessibilityElement()`, `.accessibilityAddTraits()` 4. Do NOT wrap in `#if DEBUG` — identifiers must be in production too (for real accessibility / VoiceOver) 5. If unsure about a name, use `{screen}-{type}-{index}` format and flag it in verbose mode 6. Dynamic Type warnings are REPORT ONLY — do not auto-fix, leave it to the user 7. In `--dry-run` mode, do not modify any files — only show the plan 8. After modifying each file, run a compile check — if a syntax error is introduced, revert
Open-source Agent Skills for automated visual testing and accessibility setup of iOS/SwiftUI applications using Claude Code's computer use.
Build, launch, and visually test iOS/SwiftUI apps in the Simulator using computer use. Automated screen navigation, crash log analysis, state testing…