Accessibility Audit (iOS)

Why this matters

Every SwiftUI Image, UIImageView, icon-only Button, and tap-gesture-bearing view that conveys meaning needs an .accessibilityLabel(...) (and ideally an .accessibilityHint(...)). Without it:

• Users with vision impairments — VoiceOver reads "Image" or skips silently. They cannot complete tasks that require interacting with iconographic UI (close, back, navigate, scan, expand).
• Automation tests — XCUITest, Appium, BrowserStack, MagicPod, every iOS automation framework, query elements by app.buttons["Cart"] — that string is the accessibilityLabel. Without labels, tests fall back to indices (app.buttons.element(boundBy: 3)) — brittle, breaks on any layout change.
• Voice Control — Apple's Voice Control feature lets users drive the app by saying "tap cart". Without an accessibilityLabel, the user has no name to say.
• App Store — Apple's App Review explicitly checks accessibility. Submission can be flagged or rejected when major flows fail VoiceOver.
• Compliance — WCAG 1.1.1, ADA, AODA, Section 508, EN 301 549. Same as Android — missing labels are a direct fail.

Decision matrix — when to label, when to hide

Audit findings — concrete sites

SwiftUI Image without accessibilityLabel

Total identified: ~136 instances across Costco/Costco/ and Costco-Digital/. Sample of high-impact sites:

onTapGesture without accessibility traits

Total identified: ~239 instances. Each is a custom-tappable view that VoiceOver announces as "image" or skips entirely. Sample:

Tap targets below 44pt minimum (WCAG 2.5.5 + Apple HIG)

Total identified: ~105 sites with explicit frame dimensions below 44pt — Apple's documented minimum for tap targets. Sample:

accessibilityHidden(true) on potentially meaningful content

~192 sites use .accessibilityHidden(true). Many are correct (decorative chevrons, separators) — but several are on content that carries meaning. Sample of suspicious ones to audit:

NSLocalizedString with empty translation comments

~205 sites. Empty comments mean translators have no context for the string — they may translate "Close" with the wrong gendered article in French or wrong word order in Japanese. Sample:

• UserVisibleStringConstants.swift:58, 60 — two different "Close" strings, both comment: ""
• UserVisibleStringConstants.swift:188-192 — warehouse callout actions ("See Warehouse Details", "Set as My Warehouse", "Map It") all without translator context
• UserVisibleStringConstants.swift:469-470 — "day" / "days" without context — translators can't know if it's a count, weekday, etc.
• WarehouseLocatorAPIHandler.swift:147, 192, 237 — error messages without context

Hot files (most violations)

1. Costco-Digital/.../ViewComponent/AdView/AdView.swift — multiple Image + accessibility-hidden sites
2. Costco-Digital/.../ViewComponent/HeaderView/HeaderView.swift — small frames + hidden icons
3. Costco-Digital/.../ProductCardFeature/Views/RatingFiveStarView.swift — every star without label
4. Costco/.../UserVisibleStringConstants.swift — 100+ NSLocalizedString sites with empty comments
5. Costco-Digital/.../ViewComponent/CouponSet/CouponItemView.swift — multiple hidden + small-frame issues

How fixing this helps automation

iOS automation frameworks query by accessibility identifier or label. The same labels you set for VoiceOver are what XCUITest finds elements by:

Pair this with the matching Android contentDescription work and your test team can run the same Appium test against both apps — the accessibility label becomes a cross-platform contract.

Specific patterns to apply

SwiftUI — icon-only Button

// Before
Button(action: dismiss) {
    Image(systemName: "xmark.circle.fill")
}

// After
Button(action: dismiss) {
    Image(systemName: "xmark.circle.fill")
}
.accessibilityLabel("Close")
.accessibilityHint("Closes this view")

SwiftUI — onTapGesture pattern

// Before
Image("cart")
    .onTapGesture { showCart() }

// After
Image("cart")
    .onTapGesture { showCart() }
    .accessibilityLabel("Cart")
    .accessibilityHint("View your shopping cart")
    .accessibilityAddTraits(.isButton)

SwiftUI — composite component

// Before — 5 stars, 5 separate elements VoiceOver reads
HStack {
    Image(systemName: "star.fill")
    Image(systemName: "star.fill")
    Image(systemName: "star.fill")
    Image(systemName: "star.fill")
    Image(systemName: "star")
}

// After — one element, one announcement
HStack {
    ForEach(0..<5) { i in
        Image(systemName: i < rating ? "star.fill" : "star")
    }
}
.accessibilityElement(children: .ignore)
.accessibilityLabel("Rating: \(rating) out of 5 stars")

UIKit — UIImageView

// Before
let icon = UIImageView(image: UIImage(named: "ic_phone"))

// After
let icon = UIImageView(image: UIImage(named: "ic_phone"))
icon.isAccessibilityElement = true
icon.accessibilityLabel = NSLocalizedString("Phone", comment: "Icon indicating warehouse phone number")
icon.accessibilityTraits = .image  // or .button if tappable

Migration plan

1. Sprint 1 — Add .accessibilityLabel to the 13 high-impact icon-only Buttons (close, back, dismiss, expand, fullscreen). Localize each label.
2. Sprint 1 — Sweep the 9 listed onTapGesture sites; add .accessibilityLabel + .accessibilityHint + .accessibilityAddTraits(.isButton).
3. Sprint 2 — Audit the ~192 .accessibilityHidden(true) sites. Where the content carries meaning (badges, status icons), replace with composite accessibility (one parent label + children: .ignore).
4. Sprint 2 — Sweep tap targets below 44pt; add .frame(minWidth: 44, minHeight: 44) + .contentShape(Rectangle()).
5. Sprint 3 — Fill in NSLocalizedString comments. Each comment should say where the string appears + the linguistic role (verb / noun / count / etc.).
6. Ongoing — Custom SwiftLint rule banning new Image(systemName:) without an accessibility modifier in the same statement. Snapshot test at environment(\.dynamicTypeSize, .accessibility5).

Verification

• Manual VoiceOver pass — turn VoiceOver on (⌘ Option F5 on a connected iPhone), navigate Home → Cart → Checkout-equivalent flow. Every interactive element should be announced with name + role + (where useful) hint.
• Accessibility Inspector (free, Xcode) — connect to a running simulator, click Audit. Fix all warnings on critical screens until count = 0.
• UI test rewrite — pick one feature; rewrite XCUITest queries to use .accessibilityIdentifier. Verify they survive a cosmetic refactor.
• Apple Privacy Manifest review — accessibility issues are flagged during App Review. Submit a test build and read the review report.
• SwiftLint baseline — bake-in custom rules; baseline diff must reach zero new violations per PR.