I’m trying to set the accessibilityActivationPoint directly on a UITableViewCell so that VoiceOver activate on a specific button inside the cell. However, this approach doesn’t seem to work. Instead, when I override the accessibilityActivationPoint property inside the UITableViewCell subclass and return the desired point, it works as expected. Why doesn’t setting accessibilityActivationPoint directly on the cell work, but overriding it inside the cell does? Is there a recommended approach for handling this scenario? The following approach works, override var accessibilityActivationPoint: CGPoint { get { return convert(toggleSwitch.center, to: nil) } set{ super.accessibilityActivationPoint = newValue } } but setting accessibility point directly not works private func configureAccessibility() { isAccessibilityElement = true accessibilityLabel = titleLabel.text accessibilityTraits = .toggleButton accessibilityActivationPoint = self.convert(toggleSwitch.center, to: self) accessibilityValue = toggleSwitch.accessibilityValue }

I'm seeing a build failure when archiving for TestFlight due to removing landscape support from the project. I see tons of apps that lock portrait in the app store. Is this a new requirement for apps compatible with both iPhone and iPad? What is the best approach if I am focused on portrait? Make the app iPhone only?

I have a parent view containing 10 subviews. To control the VoiceOver navigation order, I set only a few elements in accessibilityElements. However, the remaining elements are not being focused or are completely inaccessible. Is this the expected behavior? If I only specify a subset of elements in accessibilityElements, does it exclude the rest? What’s the best way to ensure all elements remain accessible while customising the order?

For the last 2 years, our team at Panda has had one goal in mind: to change the failing connection application industry. The business model is severely flawed - evidenced in decline of users in match group etc (all public info). We are building the only connections app in the market without paid features – "We Don't Play Games”. This in itself revolutionizes a space which currently commodifies human connection; true connections aren’t forged through super-likes, platinum memberships and such pay-to-win models, where users that don’t pay are unfairly disadvantaged. Key Differentiators: Never having paid features 50/50 Male-Female Ratio: Our app will ensure a balanced male-to-female ratio, something not found in other apps, especially in countries like India, where dating apps are dominated by men. This helps create a healthier, more equitable user experience for all genders. In a country like India, how can any connections app succeed with 99.9% men and 0.1% women? Panda Duos: A first-of-its-kind feature where two sets of best friends can match with each other – an industry-first that no other major connections app offers. These elements, along with the app's core ethos, make Panda unique in an otherwise saturated market. The traditional models used by Match Group/Bumble are failing, as shown in their earnings reports, because they rely on a pay-to-win approach that doesn't deliver real value. Given these unique aspects, having received 4,550+ pre sign-ups, and our backing by a top VC, we strongly believe that Panda will offer an entirely different experience to users and remake a failing industry. This is not what Apple stands for, goes against fairness, and undermines the trust and respect that it should have as the only app store for iOS phones.

SwiftUI provides the accessibilityCustomContent(_:_:) modifier to add additional accessibility information for an element. However, I couldn’t find a similar approach in UIKit. Is there a way to achieve this in UIKit?

Hi! I have noticed a few glitches as well as some overall unfortunate cons with the assistive access mode. Alarms, timers, stopwatch, etc. do not sound or alert. However, I have an infant monitor app and I do get that sound alert so I know it is possible.. do I need to download a separate alarm app for it to work? Cannot make FaceTime calls with favorite contacts. Find My iPhone cannot jump to the maps app. Camera cannot zoom in or out. Photos cannot be deleted, edited, or shared in a shared album in the photos app. Photos/videos cannot be sent in messages. Spotify cannot be accessed from the lock screen. Apps do not stay open if you lock the phone screen or leave it on too long without touching the screen (auto locks). There is no flashlight option. I downloaded an app to have this feature but without being touched the screen will lock which shuts off the flashlight feature in the app until I unlock the phone again.

I'm learning XPC by inspecting the GitHub Copilot project. I figured out that the schema works as follows: The host app with a UI to manage settings A Service Extension that controls the Xcode Editor A communication bridge cli app that connects the first two As far as I understand an app appears in the Accessibility Permission when it calls the next method: let key = kAXTrustedCheckOptionPrompt.takeRetainedValue() as NSString AXIsProcessTrustedWithOptions([key: true] as CFDictionary) This method is only called by the Service Extension. However, when I run a release build from the /Application folder (where launch agents point to), there are two records appearing in the Accessibility Permission list: The host app The needed Service Extension I compared all metadata files from Copilot with my copy line-by-line, but still can't figure out why the host app record appears in the Accessibility Permission, since the host app does not call the AXIsProcessTrustedWithOptions() method at all. Could you give me any clue to help me wrap my head around it?

In SwiftUI, the date picker component is breaking in colour contrast accessibility. Below code has been use to create date picker: struct ContentView: View { @State private var date = Date() @State private var selectedDate: Date = .init() var body: some View { let min = Calendar.current.date(byAdding: .day, value: 14, to: Date()) ?? Date() let max = Calendar.current.date(byAdding: .year, value: 4, to: Date()) ?? Date() DatePicker( "Start Date", selection: $date, in: min ... max, displayedComponents: [.date] ) .datePickerStyle(.graphical) .frame(alignment: .topLeading) .onAppear { selectedDate = Calendar.current.date(byAdding: .day, value: 14, to: Date()) ?? Date() } } } #Preview { ContentView() } attaching the screenshot of failure accessibility.

I’m trying to add the .header accessibility trait to a UISegmentedControl so that VoiceOver recognizes it accordingly. However, setting the trait using the following code doesn’t seem to have any effect: segmentControl.accessibilityTraits = segmentControl.accessibilityTraits.union(.header) Even after applying this, VoiceOver doesn’t announce it as a header. Is there any workaround or recommended approach to achieve this?

I have implemented a SwiftUI view containing a grid of TextField elements, where focus moves automatically to the next field upon input. This behavior works well on iOS 16 and 17, maintaining proper focus highlighting when keyboard full access is enabled. However, in iOS 18 and above, the keyboard full access focus behaves differently. It always stays behind the actual focus state, causing a mismatch between the visually highlighted field and the active text input. This leads to usability issues, especially for users navigating with an external keyboard. Below is the SwiftUI code for reference: struct AutoFocusGridTextFieldsView: View { private let fieldCount: Int private let columns: Int @State private var textFields: [String] @FocusState private var focusedField: Int? init(fieldCount: Int = 17, columns: Int = 5) { self.fieldCount = fieldCount self.columns = columns _textFields = State(initialValue: Array(repeating: "", count: fieldCount)) } var body: some View { let rows = (fieldCount / columns) + (fieldCount % columns == 0 ? 0 : 1) VStack(spacing: 10) { ForEach(0..<rows, id: \.self) { row in HStack(spacing: 10) { ForEach(0..<columns, id: \.self) { col in let index = row * columns + col if index < fieldCount { TextField("", text: $textFields[index]) .frame(width: 40, height: 40) .multilineTextAlignment(.center) .textFieldStyle(RoundedBorderTextFieldStyle()) .focused($focusedField, equals: index) .onChange(of: textFields[index]) { newValue in if newValue.count > 1 { textFields[index] = String(newValue.prefix(1)) } if !textFields[index].isEmpty { moveToNextField(from: index) } } } } } } } .padding() .onAppear { focusedField = 0 } } private func moveToNextField(from index: Int) { if index + 1 < fieldCount { focusedField = index + 1 } } } struct AutoFocusGridTextFieldsView_Previews: PreviewProvider { static var previews: some View { AutoFocusGridTextFieldsView(fieldCount: 10, columns: 5) } } Has anyone else encountered this issue with FocusState in iOS 18? I really do believe that this is a bug strictly connected to keyboard navigation since I experienced similar problem also on UIKit equivalent of the view. Any insights or suggestions would be greatly appreciated!

In VoiceOver, when using Group Navigation style, the cursor first focuses on the semantic group. To navigate inside the group, a two-finger swipe (left or right) can be used. This behavior works for default containers like the Navigation Bar, Tab Bar, and Tool Bar. How can I achieve the same behavior for a custom view? I tried setting accessibilityContainerType = .semanticGroup, but it only works for Mac Catalyst. Is there an equivalent approach for iOS?

VoiceOver reads out all visible content on the screen, which is essential for visually challenged users. However, this raises a privacy concern—what if a user accidentally focuses on sensitive information, like a bank account password, and it gets read aloud? How can developers prevent VoiceOver from exposing confidential data while still maintaining accessibility? Are there best practices or recommended approaches to handle such scenarios effectively?

I’m currently focused on an element at the bottom of the screen. What is the proper way to quickly navigate to the top element? By default, there’s a four-finger single tap to move to the first element, but should I use the Rotor action instead to focus on the element I need? For example, in the Contacts app while adding a new contact, if I enter a value in a field at the bottom, there’s no quick way to directly save the contact. I have to manually navigate all the way to the top to tap the Done button, which feels a bit inconvenient. Is there a better way to handle this using VoiceOver?

I have a UITextField in my application for entering a state. If I tap on it, a UIPickerView pops up and let's the user select a state (but they can still type too). The issue relates to Full Keyboard Access. If we select the UITextField using an external keyboard, the UIPickerView appears, but in order to get to it the user has to tab through the whole view controller to get to the UIPickerView at the end. What would be nice is to a) move focus directly to the UIPickerView (have it highlighted in blue and scrollable right away with keyboard) or b) make the UIPickerView the next view that's accessible when tabbing over or using the arrow keys. I've tried using: UIAccessibility notifications (both .screenChanged and .layoutChanged, with and without a delay). This ended up only announcing the view, but didn't help with full keyboard access. Making the UIPickerView a first responder when it appears. Attempting to change the accessibilityElements order (but with so many views and views within views, this isn't really a viable option either). Pressing tab + -> (tab and right arrow button) will quickly take the user to the end of the chain of accessibility elements, in other words, to the UIPickerView. But there has to be a cleaner way of just automatically setting the focus to the UIPickerView or making it the next element by pressing the arrow key.

Hello, I struggle to do some UI testing using accessibility identifiers when I wrap some SwiftUI view using UIHostingController (our app is mainly coded using UIKit). Considering this SwiftUI view (simplified for this post): HStack { Text(self.title.uppercased()) .albusTheme(.header) .lineLimit(self.isMultiline ? nil : 1) .multilineTextAlignment(.leading) .accessibilityAddTraits(.isStaticText) .accessibilityIdentifier("section_title") } This view and its controller are embedded as a UITableViewHeaderFooterView in a UITableView. This is an extract of recursiveDescription output: | | | | | | <_UITableViewHeaderFooterContentView: 0x1076ad720; frame = (0 0; 393 40); layer = <CALayer: 0x6000006b1720>> | | | | | | | <_TtGC13ListComponent19SwiftUIFieldContentV20ListComponentLibrary17FormSectionHeader_: 0x1076ab980; baseClass = UIControl; frame = (0 0; 393 40); layer = <CALayer: 0x6000006b1da0>> | | | | | | | | <_TtGC7SwiftUI14_UIHostingViewV20ListComponentLibrary17FormSectionHeader_: 0x1078f9600; frame = (0 0; 393 40); gestureRecognizers = <NSArray: 0x600000e25d70>; backgroundColor = UIExtendedSRGBColorSpace 0.0666667 0.133333 0.227451 1; layer = <SwiftUI.UIHostingViewDebugLayer: 0x6000006b19a0>> | | | | | | | | | <_TtCOCV7SwiftUI11DisplayList11ViewUpdater8Platform13CGDrawingView: 0x106985550; frame = (16 12.6667; 147.667 14.6667); anchorPoint = (0, 0); opaque = NO; autoresizesSubviews = NO; layer = <_TtCOCV7SwiftUI11DisplayList11ViewUpdater8PlatformP33_65A81BD07F0108B0485D2E15DE104A7514CGDrawingLayer: 0x6000026b8240>> CGDrawingView seems to hide the underlying view hierarchy. Is there a way to access accessibility settings using the integration of SwiftUI in UIKit?

In some places of our app we make use of NSAccessibilityElement subclasses to vend some extra items to accessibility clients. We need to know which item has the VoiceOver focus so we can keep track of it. setAccessibilityFocused: does not get called when accessibility clients focus NSAccessibilityElements. This method is only called when accessibility clients focus view-based accessibility elements (i.e. when a NSView subclass gets focused). At the same time we need to programmatically move VoiceOver focus to those items when something happens. Those accessibility elements inherit from NSObject so we can't make them first responder. Is this the expected behavior? What are our options in terms of reacting to VoiceOver cursor moving around? What are our options in terms of programmatically moving the VoiceOver cursor to a different element? Here's a sample project that demonstrates the first part of the issue: https://github.com/vendruscolo/apple-rdars/tree/master/DTS12368714%20-%20NSAccessibilityElement%20focus%20tracking If you run the app, a window will show up. It contains a button and a red square. If you enable VoiceOver you'll be able to move the cursor over the red square, and a message will be logged. You'll also notice there's an extra element after the red square. That element is available to VoiceOver, however when it gets focuses, no message gets logged.

iOS 18.3.1, iPhone 16 Pro. I pick photos using connected physical keyboard from the user's photo library using: .photosPicker(isPresented: $viewModel.isImagePickerPresented, selection: $viewModel.selectedImageItem, matching: .images) When picker appears, accessibility focus is moved to "dynamic Island" instead of cancel button. There is no possibility to navigate by keyboard in photos picker view without tapping on this view and move focus to this view manually . I noticed the same behavior in Notes app.

Using the new floating tab bar with ios18 on ipad with an RTL language, when the tabbar is correctly flipped and the right buttons become left buttons, the buttons are pushed off the screen on initial load but do come back after some navigating / reloading, have recreated in a fresh project.

I’ve tried implementing the accessibilityPerformMagicTap() method in a specific UIViewController, its view, and even in AppDelegate, but I am not receiving any callbacks. I directly overrode this method in the mentioned areas, but it never gets triggered when performing a magic tap. How can I properly observe and handle the accessibilityPerformMagicTap() action?

I’m currently exploring VoiceOver accessibility in iOS and looking for the best way to reduce the number of swipes required to navigate a UITableView. I’ve come across a couple of potential solutions but am unsure which is preferred. Solution 1: Grouping Subviews in Each Cell Combine all subviews inside a UITableViewCell into a single accessibility element. Provide a concise and meaningful accessibilityLabel. Use custom actions (UIAccessibilityCustomAction) or accessibilityActivationPoint to handle interactions on specific elements within the cell. Solution 2: Using UIAccessibilityContainerDataTableCell & UIAccessibilityContainerDataTable Implement UIAccessibilityContainerDataTable for structured table navigation. Make each cell conform to UIAccessibilityContainerDataTableCell, defining its row and column positions. However, I’m finding this approach a bit complex, and I need guidance on properly implementing these protocols. Additionally, in my case, VoiceOver is not navigating to Section 2—I’m not sure why. Questions: Which of these approaches is generally preferred for better VoiceOver navigation? How do I properly implement UIAccessibilityContainerDataTable so that all sections and rows are navigable? Any best practices or alternative recommendations? Would really appreciate any insights or guidance!