Back to browse
AccessLint – iOS accessibility static analysis (25 WCAG rules)

AccessLint – iOS accessibility static analysis (25 WCAG rules)

by synctek·Feb 12, 2026·1 point·0 comments

AI Analysis

●●SolidSolve My ProblemShip It

SwiftLint for accessibility—25 WCAG rules caught pre-build, no runtime SDK needed, free tier.

Strengths
  • Parses Swift source statically, enabling CI gates before runtime—solves real friction in accessibility testing workflow
  • WCAG 2.1 criterion mapping on every finding makes compliance auditable and non-arbitrary
  • Free tier (10 rules) + transparent pricing model lowers barrier for indie iOS teams
Weaknesses
  • Accessibility linting for mobile is niche; desktop and web have more mature competitors (axe DevTools, pa11y)
  • Only covers Swift/SwiftUI/UIKit; excludes hybrid apps, Kotlin, React Native
Target Audience

iOS developers, accessibility teams, DevOps engineers running CI/CD pipelines

Similar To

SwiftLint (style linting) · Accessibility Inspector (Apple's manual tool) · axe DevTools (web accessibility)

Post Description

Hey HN,

I built a static analyzer for iOS accessibility. It reads your Swift source files and reports accessibility violations — line numbers, severity, fix suggestions, and the WCAG success criterion each finding maps to.

25 rules covering SwiftUI and UIKit: missing VoiceOver labels, fixed font sizes that break Dynamic Type, images without decorative markers, buttons without labels, touch targets below 44pt, missing reduce motion checks, orientation locks, heading structure issues, and more.

The problem: every existing iOS accessibility tool requires a running app. Xcode Accessibility Inspector is manual — you tap through screens one at a time. VoiceOver testing is essential but slow and not automatable. Neither runs in CI.

AccessLint works at the source level, like SwiftLint but focused on accessibility. It parses your Swift files, applies the rules, and exits with a code your CI can gate on. Every finding maps to a WCAG 2.1 success criterion (1.1.1, 4.1.2, 1.4.4, etc.), so when your compliance team asks "are we WCAG AA?" you can point them at the report.

Install:

brew tap synctek-llc/accesslint && brew install accesslint accesslint analyze --path ./Sources

It works in any CI that runs macOS — just install via Homebrew in your workflow and run the CLI. Exit codes let you gate PRs on accessibility regressions.

Free tier: 10 rules, terminal output. Team ($19.99/mo): all 25 rules, JSON and Markdown reports, cloud baselines for tracking regressions. Enterprise ($49.99/mo): custom rules and SSO.

I'm a solo founder building this at SyncTek LLC. Started because I kept finding accessibility bugs in production that a linter could have caught at the PR stage. Happy to answer questions about the rule engine, the analysis approach, or anything else.

Docs: https://accesslint.app/docs.html

Similar Projects

AccessLint – Static accessibility analysis for iOS/Swift

It reads your Swift sources and flags accessibility problems with exact line numbers, suggested fixes, and WCAG references — handy for catching issues in CI or locally via a Homebrew-installable CLI. Practical execution is clear (SwiftUI/UIKit rules, Xcode/CI output), but the rule set is small and several checks are behind a paywall, so it's a strong team tool rather than a category-redefining product.

Niche GemSolve My Problem
synctek
104mo ago