The link accessibility trait is applied to UI elements that open some web content. It usually appears in-line in the content and represented by underlined text, but not always. VoiceOver will say "link" after the accessibility label.

The header accessibility trait makes VoiceOver announce something as a header. More importantly, it lets the user navigate through headings, swiping up/down, significantly speeding up navigation and making it easier to explore/discover content.

Meet the rotor. A menu that you activate (and change options) by rotating two fingers on the screen. It lets you select different navigation modes and customizations. Like navigating through headings or changing VoiceOver’s speaking rate.

If a table view cell has a disclosure indicator accessory type configured, the button trait gets added automatically. A good reminder that when following Apple's Human Interface Guidelines, things are more accessible out of the box.

With the button trait VoiceOver will read “button” after the accessibility label and will indicate the user that, when focused, they can double tap anywhere on the screen to interact with it. UIButton has this trait by default.

A component can have more than one accessibility trait, they can be combined. A heading can be a button too, for example. Or a button could be selected. You can insert or remove the selected trait to the button, when needed.

An accessibility trait is the role of the component. Among other things, it gives the user information on how they can interact (or not) with it. When using VoiceOver, the trait is usually (not always) read after the accessibility label. At the time of writing this tweet, there are 18 different accessibility traits: https://developer.apple.com/documentation/uikit/uiaccessibilitytraits Some examples are: button, header, selected, adjustable or not enabled.

Today starts the . Apple announces what new APIs we'll be able to use to make more inclusive and accessible apps. There's also Labs, Digital Lounges and Sessions, for free. Check out the schedule here: https://developer.apple.com/wwdc25/topics/accessibility-inclusion/ Last year, Apple presented Audio Graphs to make graphs more accessible. This year, they introduced Swift Charts, that lets you build a wide variety of charts in SwiftUI and they have great VoiceOver support. https://developer.apple.com/documentation/Charts @dnlyong has a great thread going through lots of the new accessibility features presented this year. https://x.com/dnlyong/status/1533897274274639873 As noted by @RobRWAPP and @mecid, Apple is tweaking the style of the SwiftUI accessibility modifiers. https://x.com/RobRWAPP/status/1533900962615762945 Sessions this year include topics like gaming (with Unity), localisation and internationalisation. You can check these (as they get published during the week) and previous accessibility sessions here: https://developer.apple.com/videos/accessibility-inclusion/ SwiftUI lets you now add multiple accessibility actions at once and quick actions to be show by the system when active: https://developer.apple.com/documentation/swiftui/view/accessibilityactions(_:)?changes=latest_minor https://developer.apple.com/documentation/swiftui/view/accessibilityquickaction(style:content:)?changes=latest_minor

Do you have a fancy custom loading animation instead of an UIActivityIndicatorView? You may want to check if it has an accessibility label so a VoiceOver user knows that something is happening. Something like "In progress" or "Loading" could work.

You can check if some features, like VoiceOver, are on. Experiences should not diverge too much. It could be used to avoid auto-hiding UI elements. iOS probably checks this to show search fields by default, without having to pull them down. From the documentation: isVoiceOverRunning: https://developer.apple.com/documentation/uikit/uiaccessibility/isvoiceoverrunning

Two more examples on better accessibility labels for abbreviations. "4 days ago" is better than "4 D", with a RelativeDateTimeFormatter and a spellOut units style. "Monday" is better than "Mon", accessing the weekdaySymbols from a Calendar. Some useful links: Relative Date Time Formatter: https://developer.apple.com/documentation/foundation/relativedatetimeformatter Units Style: https://developer.apple.com/documentation/foundation/relativedatetimeformatter/unitsstyle-swift.enum/spellout Weekday symbols: https://developer.apple.com/documentation/foundation/calendar/weekdaysymbols

Tip for abbreviations. Something like "3h 24m" will be read by VoiceOver as "3 h 24 meters". Formatters can help. DateComponentsFormatter with a "spellOut" units style will give you a more suitable label: "three hours, twenty-four minutes" Example code in the image: ```swift let dailyAverageLabel = UILabel() let abbreviatedReadableFormatter = DateComponentsFormatter() abbreviatedReadableFormatter.allowedUnits = [.hour, .minute] abbreviatedReadableFormatter.unitsStyle = .spellOut let abbreviatedReadableDuration = abbreviatedReadableFormatter.string(from: 12240) dailyAverageLabel.accessibilityLabel = abbreviatedReadableDuration ``` Some useful links: * Date Components Formatter: * Units Style: By the way! Formatters are also great for localisation.