Questionable Accessibility Advice

[chriscm2006]

New Issue Checklist

A fellow friend of mine passionate about iOS Accessibility shared this issue description with me.

https://github.com/realm/SwiftLint/blob/ff1e966e3ae8ef9876ec5e80c060a46b5faae8f4/Source/SwiftLintBuiltInRules/Rules/Lint/AccessibilityTraitForButtonRule.swift

I love the idea of a Linting library for Accessibility. I actually built one attached to LLVM for Deque back like 10 years ago attached to CLANG for Objective C analysis... The logic I found analyzing UIView ASTSs back then applies to Swift the same. This rule needs some help :).

The description for this issues suggests that every tappable iOS Control should be Button or a Link. This shows a misunderstanding of what these traits do and their relationship to the Rotor. Counterexamples to this rule include:

• Interactive GridView Items - Like the iOS launcher screen.
• Switches, checkboxes, etc.
• Interactive selectable ListViewCells

Note: There are more counter examples than examples.

A rule that would more accurately satisfy the documented intent of this rule would be a rule that made sure controls that were attempting to exhibit single tap behavior did so utilizing gestures that Voice Control and Switch Control recognize as having a default action... being clickable.

Or even a rule that recommended removing the Trait of Button or Link from a control with a changing value... "Switch Button" should never happen.

Let's chat! :) https://www.linkedin.com/in/ciaiguy/

[SimplyDanny]

@rcole34: You originally contributed the rule. Mentioning you in case you are interested in a chat with @chriscm2006. Unfortunately, I don't have enough experience in this area to judge the apparently conflicting opinions on the rule.

[rcole34]

Hey @chriscm2006 thanks for the feedback! I agree this rule may not be perfect for all scenarios, but I added it to help counteract a common anti-pattern I was seeing in a lot of SwiftUI code where developers would just add a tap gesture to views rather than using a Button to avoid dealing with unwanted ButtonStyle behaviors. This resulted in views that visually looked like buttons, but had no indication with VoiceOver that they were interactive. There are definitely exceptions where it’s ok to not have a button trait, but I still think the consequences of having a view that assistive technologies do not see as interactive are much worse than the consequences of having a trait where it’s not strictly needed.

I do agree though that we could add the isToggle trait to the list of things you could add along with a tap gesture to not have the rule warn about adding a button trait.

At the end of the day, plenty of SwiftLint rules aren’t about the “right” or “wrong” way to do something and are more suggestions for what is someone’s idea of better style. This is an opt-in rule that people can turn on if they choose, and the target audience for this and the accessibility label for image rule that I added is more people who are getting started with accessibility or are trying to have a gentle reminder for their development team to be thinking about accessibility in their process. If you have ideas for a heuristic that could be used to determine when it would be fine to omit the trait then feel free to contribute to the open source project if you have ideas to make it better!