A11y, or You Can Call It Accessibility

1 in 6 people on Earth has a disability. That's 1.3 billion potential users—16% of the global population. Yet most apps still aren't built for them.

With the European Accessibility Act now in force (June 28, 2025) and similar regulations tightening worldwide, accessibility isn't optional anymore—it's a legal requirement and a massive market opportunity.

If you've seen "A11y" in developer circles, it's just shorthand for "Accessibility" (11 letters between the 'A' and 'y'). But what it represents matters far more than its name: building apps that work for everyone.

Accessibility (A11y) in iOS Development: Building Apps Everyone Can Use

Accessibility (often shortened to A11y) is not just good practice—it's a requirement for modern, inclusive design. Making apps usable by everyone, regardless of ability, is both a moral and legal responsibility, especially as international accessibility regulations tighten between 2025–2030.

What A11y Means

A11y is a numeronym for Accessibility—the "11" represents the eleven letters between A and y. In iOS development, this means ensuring that your apps work seamlessly with assistive technologies such as:

VoiceOver — Apple's screen reader that narrates UI elements
Switch Control — Supports users with physical or motor impairments
Voice Control — Enables hands-free navigation using voice commands
Dynamic Type — Lets users adjust text size system-wide

Your app needs to work for users regardless of vision, hearing, mobility, or cognitive differences.

Why Accessibility Matters for Startups and Investors

Accessible design isn't just compliance—it's opportunity. Apps that follow WCAG and platform accessibility guidelines reach broader audiences, improve usability for everyone, and reduce the risk of future legal issues.

The Business Case

Market Expansion: - 1.3 billion people worldwide live with disabilities - 87 million in the EU alone - 61 million adults in the US - These users represent significant purchasing power and loyalty

Legal Protection: For investors and startup founders, accessibility compliance is now a critical metric. The European Accessibility Act (EAA) and the U.S. Department of Justice's 2024 accessibility rules create new legal obligations that directly affect: - Product timelines - Market access - Legal liability - Investor confidence

Real Enforcement:

- EU penalties can reach €500K+ for EAA violations - 4,000+ ADA lawsuits filed in the US in 2023

- UK organizations face unlimited fines for Equality Act violations

- Many countries conduct regular accessibility audits

Competitive Advantage: Startups that anticipate EAA compliance now gain both legal and competitive advantages by 2025. Demonstrating compliance readiness adds credibility to due diligence reports and opens doors to larger markets.

Global Accessibility Standards and Regulations

WCAG 2.2 — Current Standard

The Web Content Accessibility Guidelines (WCAG) 2.2 became a W3C Recommendation on October 5, 2023. Following WCAG 2.2 Level AA is now considered the global best practice for digital products, including mobile applications. Apple's Human Interface Guidelines align closely with these principles.

European Accessibility Act (EAA)

Applies to: All digital products and services sold within the EU market
Compliance deadline: June 28, 2025 for new products and services
Transition period: Some categories may extend compliance up to 2030, allowing phased adaptation
Standard: EN 301 549 V3.2.1 (incorporates WCAG 2.1 Level AA)

Investors should note these timelines—startups that anticipate EAA compliance now gain both legal and competitive advantages by 2025.

U.S. Department of Justice (DOJ) Rule — April 2024

In April 2024, the DOJ issued a final rule requiring state and local governments to meet WCAG 2.1 Level AA compliance by 2026–2027, depending on population size. This signals increasing international enforcement of accessibility standards.

Apple's Human Interface Guidelines (HIG)

Apple's HIG provides comprehensive accessibility guidance specifically for iOS, iPadOS, macOS, watchOS, and tvOS. Key principles include:

Perceivable — Information must be presented in ways users can perceive (visual, auditory, tactile)
Operable — Interface components must be operable by all users
Understandable — Information and operation must be clear
Robust — Content must work with assistive technologies, now and in the future

The HIG emphasizes that accessibility should be considered from the beginning of the design process, not added as an afterthought. Key guidance includes: - Minimum 44x44pt touch targets - Proper color contrast ratios (4.5:1 for text, 3:1 for UI components) - Comprehensive VoiceOver implementation

Accessibility in iOS: Core Principles

Accessibility in iOS apps means enabling interaction across all ability levels. Core areas include:

1. Visual Accessibility

Support Dynamic Type, Dark Mode, and High Contrast
Use semantic colors and test for color blindness
Provide descriptive labels for icons and non-text elements
Ensure minimum 4.5:1 contrast ratio for text

2. Motor Accessibility

Ensure full functionality via Voice Control or Switch Control
Respect system gestures and avoid requiring precision tapping
Use large touch targets (minimum 44x44pt) and adequate spacing
Support alternative input methods

3. Auditory Accessibility

Provide subtitles, closed captions, or visual alternatives to sounds
Avoid sound-only notifications
Offer visual feedback for audio events

4. Cognitive Accessibility

Keep interfaces consistent and predictable
Offer clear feedback for every interaction
Avoid unnecessary animations that may distract or confuse users
Use simple, clear language

Real Talk: The Implementation Gap

Let's be honest—most of us learned to code without thinking about accessibility. We focus on features, performance, and design, but overlook the 16% of users who need assistive technologies.

The Most Common Accessibility Challenges

Dynamic Layouts with Dynamic Type: Supporting larger text sizes often breaks carefully crafted layouts. You'll need to design flexible UIs that can accommodate text scaling from XS to XXXL accessibility sizes. Use flexible constraints and avoid fixed heights.

Custom Controls: Standard UIKit controls have built-in accessibility support, but custom controls require manual implementation of accessibility protocols. This includes defining custom actions, adjusting values, and providing appropriate feedback.

Gesture-Heavy Interfaces: Apps relying heavily on swipes, pinches, or multi-touch gestures need alternative interaction methods for users with motor impairments or those using assistive technologies. Provide voice or switch control alternatives.

Visual-Only Information: Charts, graphs, and data visualizations need textual alternatives or audio descriptions. Conveying complex visual information through VoiceOver is challenging but crucial for users who cannot see the screen.

Time Pressure: Keeping accessibility a priority when deadlines are tight is difficult. It's easy to defer accessibility work, but retrofitting is always harder than building it in from the start. Make accessibility part of your definition of "done."

From Bad to Good: A Real Example

Let me show you the difference accessibility makes. Here's a login screen—before and after improvements.

UIKit — Before (What Not to Do)

Swift

import UIKit

class LoginViewController: UIViewController {
    let logoImageView = UIImageView(image: UIImage(named: "logo"))
    let emailTextField = UITextField()
    let passwordTextField = UITextField()
    let loginButton = UIButton()
    let forgotPasswordButton = UIButton()
    let errorLabel = UILabel()

    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .white

        // Email field - fixed size
        emailTextField.placeholder = "Email"
        emailTextField.borderStyle = .roundedRect
        emailTextField.font = UIFont.systemFont(ofSize: 14)

        // Password field - fixed size
        passwordTextField.placeholder = "Password"
        passwordTextField.borderStyle = .roundedRect
        passwordTextField.isSecureTextEntry = true
        passwordTextField.font = UIFont.systemFont(ofSize: 14)

        // Login button - unclear label
        loginButton.setTitle("→", for: .normal)
        loginButton.backgroundColor = .systemBlue
        loginButton.layer.cornerRadius = 8

        // Forgot password - too small
        forgotPasswordButton.setTitle("Forgot?", for: .normal)
        forgotPasswordButton.setTitleColor(.systemBlue, for: .normal)
        forgotPasswordButton.titleLabel?.font = UIFont.systemFont(ofSize: 12)

        // Error label - fixed size
        errorLabel.textColor = .red
        errorLabel.font = UIFont.systemFont(ofSize: 12)
        errorLabel.numberOfLines = 0
        errorLabel.isHidden = true

        // Layout code...
    }
}

Problems: - Fixed font sizes ignore Dynamic Type - Arrow icon "→" is meaningless to VoiceOver - "Forgot?" is cryptic and text too small - No accessibility labels, hints, or proper traits - Touch targets might be too small (< 44pt) - No error announcements for VoiceOver users

UIKit — After (Accessible)

Swift

import UIKit

class LoginViewController: UIViewController {
    let logoImageView = UIImageView(image: UIImage(named: "logo"))
    let emailTextField = UITextField()
    let passwordTextField = UITextField()
    let loginButton = UIButton()
    let forgotPasswordButton = UIButton()
    let errorLabel = UILabel()

    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .white
        setupAccessibility()

        // Email field with Dynamic Type
        emailTextField.placeholder = "Email"
        emailTextField.borderStyle = .roundedRect
        emailTextField.font = UIFont.preferredFont(forTextStyle: .body)
        emailTextField.adjustsFontForContentSizeCategory = true
        emailTextField.accessibilityLabel = "Email address"
        emailTextField.accessibilityHint = "Enter your email address"
        emailTextField.accessibilityIdentifier = "emailField"
        emailTextField.keyboardType = .emailAddress
        emailTextField.textContentType = .emailAddress
        emailTextField.autocapitalizationType = .none

        // Password field with Dynamic Type
        passwordTextField.placeholder = "Password"
        passwordTextField.borderStyle = .roundedRect
        passwordTextField.isSecureTextEntry = true
        passwordTextField.font = UIFont.preferredFont(forTextStyle: .body)
        passwordTextField.adjustsFontForContentSizeCategory = true
        passwordTextField.accessibilityLabel = "Password"
        passwordTextField.accessibilityHint = "Enter your password"
        passwordTextField.accessibilityIdentifier = "passwordField"
        passwordTextField.textContentType = .password

        // Login button with clear label
        loginButton.setTitle("Log In", for: .normal)
        loginButton.backgroundColor = .systemBlue
        loginButton.layer.cornerRadius = 8
        loginButton.titleLabel?.font = UIFont.preferredFont(forTextStyle: .headline)
        loginButton.titleLabel?.adjustsFontForContentSizeCategory = true
        loginButton.accessibilityLabel = "Log in"
        loginButton.accessibilityHint = "Double tap to log in with your credentials"
        loginButton.accessibilityIdentifier = "loginButton"
        loginButton.accessibilityTraits = .button
        // Minimum touch target size (44x44pt)
        loginButton.heightAnchor.constraint(greaterThanOrEqualToConstant: 44).isActive = true

        // Forgot password with proper sizing
        forgotPasswordButton.setTitle("Forgot Password?", for: .normal)
        forgotPasswordButton.setTitleColor(.systemBlue, for: .normal)
        forgotPasswordButton.titleLabel?.font = UIFont.preferredFont(forTextStyle: .callout)
        forgotPasswordButton.titleLabel?.adjustsFontForContentSizeCategory = true
        forgotPasswordButton.accessibilityLabel = "Forgot password"
        forgotPasswordButton.accessibilityHint = "Double tap to reset your password"
        forgotPasswordButton.accessibilityIdentifier = "forgotPasswordButton"
        forgotPasswordButton.accessibilityTraits = .button

        // Error label with Dynamic Type
        errorLabel.textColor = .systemRed
        errorLabel.font = UIFont.preferredFont(forTextStyle: .callout)
        errorLabel.adjustsFontForContentSizeCategory = true
        errorLabel.numberOfLines = 0
        errorLabel.isHidden = true
        errorLabel.accessibilityTraits = .staticText
        errorLabel.accessibilityIdentifier = "errorLabel"

        // Layout code...
    }

    func setupAccessibility() {
        // Logo is decorative
        logoImageView.isAccessibilityElement = true
        logoImageView.accessibilityLabel = "Company logo"
        logoImageView.accessibilityTraits = .image

        // Set proper accessibility order
        view.accessibilityElements = [
            logoImageView,
            emailTextField,
            passwordTextField,
            loginButton,
            forgotPasswordButton,
            errorLabel
        ]
    }

    func showError(_ message: String) {
        errorLabel.text = message
        errorLabel.isHidden = false

        // Announce error to VoiceOver users (iOS 11+)
        UIAccessibility.post(notification: .announcement, argument: "Error: \(message)")

        // Move VoiceOver focus to error
        UIAccessibility.post(notification: .layoutChanged, argument: errorLabel)
    }
}

SwiftUI — Before (Inaccessible)

Swift

import SwiftUI

struct LoginView: View {
    @State private var email = ""
    @State private var password = ""
    @State private var errorMessage = ""
    @State private var showError = false

    var body: some View {
        VStack(spacing: 20) {
            Image("logo")
                .resizable()
                .frame(width: 100, height: 100)

            TextField("Email", text: $email)
                .textFieldStyle(RoundedBorderTextFieldStyle())
                .font(.system(size: 14))

            SecureField("Password", text: $password)
                .textFieldStyle(RoundedBorderTextFieldStyle())
                .font(.system(size: 14))

            Button(action: login) {
                Text("→")
                    .foregroundColor(.white)
                    .frame(maxWidth: .infinity)
                    .padding()
                    .background(Color.blue)
                    .cornerRadius(8)
            }

            Button("Forgot?") {
                // Forgot password action
            }
            .font(.system(size: 12))

            if showError {
                Text(errorMessage)
                    .foregroundColor(.red)
                    .font(.system(size: 12))
            }
        }
        .padding()
    }

    func login() {
        // Login logic
    }
}

SwiftUI — After (Accessible)

Swift

import SwiftUI

struct LoginView: View {
    @State private var email = ""
    @State private var password = ""
    @State private var errorMessage = ""
    @State private var showError = false
    @AccessibilityFocusState private var isErrorFocused: Bool

    var body: some View {
        VStack(spacing: 20) {
            Image("logo")
                .resizable()
                .frame(width: 100, height: 100)
                .accessibilityLabel("Company logo")
                .accessibilityAddTraits(.isImage)

            TextField("Email", text: $email)
                .textFieldStyle(RoundedBorderTextFieldStyle())
                .font(.body)
                .textContentType(.emailAddress)
                .keyboardType(.emailAddress)
                .autocapitalization(.none)
                .accessibilityLabel("Email address")
                .accessibilityHint("Enter your email address")

            SecureField("Password", text: $password)
                .textFieldStyle(RoundedBorderTextFieldStyle())
                .font(.body)
                .textContentType(.password)
                .accessibilityLabel("Password")
                .accessibilityHint("Enter your password")

            Button(action: login) {
                Text("Log In")
                    .foregroundColor(.white)
                    .frame(maxWidth: .infinity)
                    .frame(minHeight: 44) // Minimum touch target
                    .padding()
                    .background(Color.blue)
                    .cornerRadius(8)
            }
            .accessibilityLabel("Log in")
            .accessibilityHint("Double tap to log in with your credentials")

            Button(action: { /* Forgot password */ }) {
                Text("Forgot Password?")
            }
            .font(.callout)
            .accessibilityLabel("Forgot password")
            .accessibilityHint("Double tap to reset your password")

            if showError {
                Text(errorMessage)
                    .foregroundColor(.red)
                    .font(.callout)
                    .multilineTextAlignment(.center)
                    .accessibilityAddTraits(.isStaticText)
                    .accessibilityFocused($isErrorFocused)
            }
        }
        .padding()
        .onChange(of: showError) { newValue in
            if newValue {
                // Move VoiceOver focus to error message
                isErrorFocused = true
            }
        }
    }

    func login() {
        // Login logic
        if email.isEmpty || password.isEmpty {
            errorMessage = "Please enter both email and password"
            showError = true
        }
    }
}

Key Accessibility Improvements Made

Dynamic Type Support — Changed from fixed font sizes (size: 14) to preferredFont (UIKit) and .body/.callout(SwiftUI)
Meaningful Labels — Replaced visual-only cues like "→" with descriptive text "Log In"
Accessibility Labels & Hints — Added clear labels and hints explaining what each element does
Touch Targets — Ensured minimum 44x44pt height for all interactive elements
Content Type — Added textContentType for better autofill and assistive technology context
Error Announcements — Errors are announced to VoiceOver users and focus moves to error message
Proper Traits — Added appropriate accessibility traits (.button, .staticText, .image)
Logical Focus Order — Set explicit accessibility order in UIKit
Keyboard Types — Appropriate keyboard types for email (.emailAddress) and password fields
Accessibility Identifiers — Added identifiers for UI testing automation

How to Audit Accessibility in Swift Apps

Startups can audit accessibility early in development using Apple's built-in tools:

Built-in Testing Tools

Accessibility Inspector (Xcode > Developer Tools): - Simulates VoiceOver behavior - Validates elements in real-time - Checks contrast ratios - Identifies missing labels and hints

VoiceOver and Rotor Testing: Enable VoiceOver in Settings → Accessibility → VoiceOver. Navigate your app with your eyes closed. If you can't use it, neither can your users. This helps ensure logical focus order and navigation.

Dynamic Type Scaling Test: Test your app at all text sizes, especially accessibility sizes (XXXL). Your layouts must remain functional and readable.

Contrast Checker: Confirms color contrast meets WCAG 2.2 AA standards (4.5:1 for text, 3:1 for UI components).

Environment Overrides: Test Dynamic Type, Dark Mode, and other settings instantly in Xcode without changing system settings.

Tip: Incorporate automated accessibility checks into your CI/CD pipeline to catch regressions early.

Automated Testing with XCTest

Apple's Native Accessibility Audits (iOS 17+):

Swift

import XCTest

func testAccessibilityQuoteTabView() throws {
    let app = XCUIApplication()
    app.launch()

    // Navigate to the view you want to test
    app.tabBars.buttons["Quotes"].tap()

    // Run accessibility audit (iOS 17+)
    try app.performAccessibilityAudit { issue in
        // Handle specific issues
        var shouldIgnore = false

        // Log all issues
        print("Accessibility Issue: \(issue.auditType)")
        print("Element: \(issue.element?.description ?? "unknown")")
        print("Description: \(issue.compactDescription)")

        // You can choose to ignore certain issues
        if issue.auditType == .contrast {
            // Example: ignore contrast issues for decorative elements
            shouldIgnore = issue.element?.label == "Decorative Icon"
        }

        return shouldIgnore
    }
}

What performAccessibilityAudit() checks: - Missing accessibility labels and hints - Insufficient contrast ratios (below WCAG standards) - Elements too small to interact with (< 44x44pt) - Dynamic Type support issues - Hit region problems - Clipped or truncated text

Visual Regression Testing with AccessibilitySnapshot

AccessibilitySnapshot, created by Cash App, provides a powerful way to create visual snapshots of your app's accessibility tree. It builds on top of SnapshotTesting to generate images showing all accessibility elements with their labels, hints, and traits.

Installation via Swift Package Manager:

Plain text

// In Package.swift
dependencies: [
    .package(
        name: "AccessibilitySnapshot",
        url: "https://github.com/cashapp/AccessibilitySnapshot.git",
        from: "0.4.1"
    ),
]

targets: [
    .testTarget(
        name: "MyAppTests",
        dependencies: [
            "MyApp",
            "AccessibilitySnapshot"
        ]
    )
]

Basic Usage:

Swift

import AccessibilitySnapshot
import XCTest

class LoginViewAccessibilityTests: XCTestCase {
    func testLoginViewAccessibility() {
        let loginView = LoginView()
        loginView.frame = CGRect(x: 0, y: 0, width: 375, height: 667)

        // Generate accessibility snapshot
        assertSnapshot(matching: loginView, as: .accessibilityImage)
    }

    func testLoginViewWithActivationPoints() {
        let loginView = LoginView()
        loginView.frame = CGRect(x: 0, y: 0, width: 375, height: 667)

        // Show activation points for all elements
        assertSnapshot(
            matching: loginView,
            as: .accessibilityImage(showActivationPoints: .always)
        )
    }

    // Test with Dynamic Type
    func testLoginViewWithLargeText() {
        let loginView = LoginView()
        loginView.traitCollection = UITraitCollection(
            preferredContentSizeCategory: .accessibilityExtraExtraExtraLarge
        )

        assertSnapshot(
            matching: loginView,
            as: .accessibilityImage,
            named: "xxxlarge-text"
        )
    }
}

What AccessibilitySnapshot Tests:

The library generates snapshot images showing accessibility labels, hints, traits, and activation points for each element. This helps catch regressions in accessibility and speeds up iteration when working on UI changes.

Benefits of Snapshot Testing:

Visual regression detection: See exactly what changed
Faster iteration: No need to manually test with VoiceOver after every change
Documentation: Snapshots serve as visual documentation
CI/CD integration: Catch accessibility regressions in pull requests
Team awareness: Makes accessibility visible to all team members

Manual Testing Checklist

Essential Tests:

✅ Can you navigate the entire app using VoiceOver?
✅ Does the app work at the largest text size (accessibility XXXL)?
✅ Is there sufficient color contrast in all states (light and dark mode)?
✅ Can all actions be performed using Voice Control?
✅ Are error messages clearly announced?
✅ Do custom controls have appropriate traits and actions?
✅ Are images properly labeled or hidden from accessibility?
✅ Does the app work correctly in RTL languages (Arabic, Hebrew)?

Test with Real Users:

While automated testing and VoiceOver are essential, nothing replaces testing with actual users who rely on assistive technologies daily.

Consider:

Recruiting accessibility testers with various disabilities
Participating in accessibility user testing programs
Engaging with disability advocacy organizations
Using platforms like Fable or Access Works

Real user feedback often reveals issues that automated tools miss, such as confusing navigation patterns, overwhelming information density, or missing context that makes features unusable despite being technically accessible.

Accessibility Compliance as a Growth Strategy

Market Expansion

Accessibility opens your app to millions of additional users worldwide. Over 1.3 billion people (16% of the global population) experience significant disability. These users represent substantial purchasing power and loyalty when apps work for them.

Legal Protection

Compliance reduces risk under EAA, ADA, and other frameworks. Non-compliance can result in: - EU penalties up to €500K+ - US lawsuits (4,000+ filed in 2023) - UK unlimited fines - Blocked market access in regulated regions

Brand Reputation

Inclusive products demonstrate ethical leadership and corporate responsibility. Accessibility shows you care about all users, not just the majority.

Investor Confidence

Demonstrating compliance readiness adds credibility to due diligence reports. Investors now ask about accessibility compliance as a standard part of technical due diligence.

Better User Experience for Everyone

Accessibility improvements benefit all users: - Larger touch targets are easier for everyone to tap - Better contrast improves readability in bright sunlight - Captions help users in noisy environments - Clear navigation benefits users who are multitasking

Consistency and Documentation

When documenting or marketing your accessibility compliance:

Use consistent terminology, e.g., "WCAG 2.1 Level AA" or "WCAG 2.2 Level AA"
Reference testing methodologies and tools used
Include short accessibility statements in app descriptions or investor decks
Document your accessibility roadmap and progress
Make accessibility part of your release notes

Let's Talk Action Items

For Developers

This Week: Enable VoiceOver and navigate through one of your apps
This Month: Add accessibility labels to all interactive elements in one feature
This Quarter: Implement automated accessibility testing in your CI/CD pipeline
By June 2025: Ensure your app meets WCAG 2.1 Level AA standards

For Startups & Product Teams

Immediate: Audit your app's current accessibility state
Q1 2025: Create accessibility compliance roadmap
Q2 2025: Train development team on accessibility best practices
Before June 28, 2025: Achieve EAA compliance for EU market access

For Hiring Managers

Now: Add accessibility experience to job descriptions
During Interviews: Ask candidates about accessibility implementation
Team Building: Budget for accessibility training and tools
Long-term: Make accessibility a core competency in your team

How I Can Help

If your startup needs help auditing its app ahead of the 2025-2030 compliance deadlines, let's connect!

I specialize in:

Accessibility Audits — Comprehensive reviews of iOS apps against WCAG 2.2 and EAA requirements
Implementation Guidance — Practical, hands-on accessibility improvements with code examples
Team Training — Workshops on accessible iOS development for your team
Compliance Preparation — Roadmaps for EAA, ADA, and WCAG compliance
Technical Leadership — Building accessibility into development culture and CI/CD pipelines

Together, we can make your product accessible, future-proof, and investor-ready.

Essential Resources

Official Apple Resources

Apple Human Interface Guidelines - Accessibility: - Foundations — Core accessibility principles - Accessibility for UIKit - Accessibility for SwiftUI

WWDC Sessions (Essential Viewing): - "What's New in Accessibility" (annual updates) - "Build accessible apps with SwiftUI and UIKit" - "Deliver an exceptional accessibility experience"

International Guidelines & Standards

WCAG Resources: - WCAG 2.1 Quick Reference - WCAG 2.2 What's New - W3C Mobile Accessibility Guidelines

European Union Compliance: - European Accessibility Act Full Text - EN 301 549 V3.2.1 Standard - European Commission Digital Accessibility

US Regulations: - Section 508 - ADA Requirements - DOJ 2024 Accessibility Rule

Other Regions: - UK GDS Accessibility - Canada ACA Information - Australia DTA Standards

Testing & Development Tools

Accessibility Inspector — Xcode's built-in tool
AccessibilitySnapshot — Visual regression testing by Cash App
WAVE Web Accessibility Tool — For web views

Community & Learning

A11ycasts YouTube Series
WebAIM Resources
The A11Y Project
Appt Foundation — Comprehensive mobile accessibility handbook
Mark Steadman's Articles — iOS accessibility testing guides

Join the Conversation

What accessibility challenges have you faced in your iOS projects?

How are you preparing for the June 2025 EAA deadline?

What's your biggest accessibility "aha moment"?

Share your experience, questions, or favorite tips in the comments. Let's make accessibility part of our culture, not just compliance.

About Swift in Practice

Swift in Practice is more than just a newsletter—it's a community dedicated to helping iOS developers grow, learn, and build better apps together. Whether you're tackling accessibility challenges, exploring new Swift features, or seeking guidance on best practices, this is your space to connect, share, and support each other.

Have accessibility questions? Facing implementation challenges? Share them in the comments or reach out directly. We're here to help.

Remember

Accessibility isn't a feature—it's good design. It's a fundamental aspect of software development and a legal obligation in most markets.

Every user deserves a great experience with your app, regardless of their abilities.

Start small, test often, and make accessibility part of your workflow from day one. Build it into your definition of "done," include it in code reviews, and celebrate accessibility wins with your team.

Every improvement you make opens your app to more users and creates a better experience for everyone.

The time to act is now. Let's build apps everyone can use.

Updated for WCAG 2.2, the European Accessibility Act (June 2025), and the U.S. DOJ Accessibility Rule (2024).

☕ Enjoying Swift in Practice? It's free and reader-supported. If an edition saved you some debugging time, you can buy me a coffee: https://buymeacoffee.com/swiftinpractice

Originally published as a Swift in Practice edition on LinkedIn. Comments and discussion happen there.

A11y, or You Can Call It Accessibility

Accessibility (A11y) in iOS Development: Building Apps Everyone Can Use

What A11y Means

Why Accessibility Matters for Startups and Investors

The Business Case

Real Enforcement:

Global Accessibility Standards and Regulations

WCAG 2.2 — Current Standard

European Accessibility Act (EAA)

U.S. Department of Justice (DOJ) Rule — April 2024

Apple's Human Interface Guidelines (HIG)

Accessibility in iOS: Core Principles

1. Visual Accessibility

2. Motor Accessibility

3. Auditory Accessibility

4. Cognitive Accessibility

Real Talk: The Implementation Gap

The Most Common Accessibility Challenges

From Bad to Good: A Real Example

UIKit — Before (What Not to Do)

UIKit — After (Accessible)

SwiftUI — Before (Inaccessible)

SwiftUI — After (Accessible)

Key Accessibility Improvements Made

How to Audit Accessibility in Swift Apps

Built-in Testing Tools

Automated Testing with XCTest

Visual Regression Testing with AccessibilitySnapshot

Installation via Swift Package Manager:

Basic Usage:

What AccessibilitySnapshot Tests:

Benefits of Snapshot Testing:

Manual Testing Checklist

Essential Tests:

Accessibility Compliance as a Growth Strategy

Market Expansion

Legal Protection

Brand Reputation

Investor Confidence

Better User Experience for Everyone

Consistency and Documentation

Let's Talk Action Items

For Developers

For Startups & Product Teams

For Hiring Managers

How I Can Help

Essential Resources

Official Apple Resources

International Guidelines & Standards

Testing & Development Tools

Community & Learning

Join the Conversation

What accessibility challenges have you faced in your iOS projects?

About Swift in Practice

Remember

Was this edition useful?