Thanks for being a part of WWDC25!

How did we do? We’d love to know your thoughts on this year’s conference. Take the survey here

What is the appropriate accessibility trait for selectable UITableViewCell?

I’m trying to understand the best practice for assigning accessibilityTraits to a UITableViewCell that users can select from a list of options.

In Apple’s first-party apps like Settings, I’ve noticed an inconsistent approach—some cells use the Button trait, while others simply announce the label along with the Selected trait when applicable, without any additional role like Button or Adjustable.

So my question is:

  1. What is the most appropriate accessibility trait to use for a selectable table view cell that updates a selection (like a settings option)?
  2. Is using .button the right approach, or should we rely solely on .selected?
  3. Is there any user experience guideline from Apple that recommends one over the other?

Would love to hear how others handle this for clarity and consistency in VoiceOver behavior.

Ideally, accessibility traits are consistent in an experience, but for apps as large as Settings or as big as your own it may be possible for inconsistencies to arise in applying the .button trait. In these cases, VoiceOver users are typically able to intuit the functionality of accessibility elements based on the context of the UI around it. There's not really a wrong answer here, but it may be omitted for brevity if it's clear otherwise.

The .selected trait is certainly the more important of the two, and its usage should be applied anywhere a selection or choice is made and communicated through symbols like this checkmark.

What is the appropriate accessibility trait for selectable UITableViewCell?
 
 
Q