Using Accessibility Rules with SwiftLint

For developers who develop iOS applications in SwiftUI, one of the most popular linters has been SwiftLint. SwiftLint enforces the style guide rules that are generally accepted by the Swift community.

Although vastly used, there a little known set of rules that can check for accessibility issues as you develop! So what are these rules and how do we turn them on? Let's dive in!

Accessibility Rules

SwiftLint contains two simple accessibility rules:

1. Accessibility Trait for Button - All views with tap gestures added should include the .isButton or the .isLink accessibility traits
2. Accessibility Label for Image - Images that provide context should have an accessibility label or should be explicitly hidden from accessibility

The kicker here, the rules are OFF by default. So in order to properly enforce these two rules, you need to turn them on!

Turning on the Rules

In your SwiftUI project, locate your *.swiftlint.yml file. Inside the .yml opt in to the rules under opt_in_rules add the following:

 yml

opt_in_rules: # some rules are only opt-in
  - empty_count
  - missing_docs
  - accessibility_label_for_image
  - accessibility_trait_for_button

Once done, rebuild the project and the accessibility rules should now be working!

Example use cases

You may be asking yourself, "this is only two rules what impact could this really have?". Great question!

Mobile accessibility awareness is still relatively new. There are still not a lot of development teams that are aware that mobile accessibility features even exist on iOS. The result, is the most basic issues are pushed into applications.

One prime example, using text or a non-native control and adding a tap gesture to it.

 swift
   Text("Learn more")
                .onTapGesture(count: 1) {
                    print("tapped")
                }
                .foregroundColor(.white)

If the Accessibility Trait for Button rule is activated, it would catch there is a tap gesture tied to this and suggest to add a trait of .isButton.

Now, should the developer just use a native control such as a button? Absolutely! But that is an entire other topic we can dive into at another time. For now, this issue is caught and will be fixed by the developer before release!

Benefits of Accessibility Rules

Including these two rules has many benefits that can greatly improve your development team, including:

• Catching issues as you build your SwiftUI content
• Building accessibility knowledge for your developers
• Enforcing good coding practices (Button vs Text)

However, the biggest one is the simplicity of use. If you are a team that cannot slow down and are struggling to get accessibility into the day to day development, using these two rules with SwiftLint is a great starting point to a much larger path to accessibility in your mobile applications!