When I toggle on VoiceOver in Device Hub, it looks very promising! But how can I emulate the gestures, double tap to activate, etc... Is this not possible? Right now I can just focus on different elements by clicking on them with the mouse. But, again, I can't activate anything, press button etc.

反饋標題： 建議新增「螢幕反轉／感應器遮蓋」自訂觸發功能，以提升輔助使用與操作效率 反饋內容： 您好， 本人為 iPhone 長期用戶，現就「輔助使用」與「捷徑」功能提出一項新功能建議，希望貴公司考慮於未來 iOS 版本中加入。 建議功能： 新增一項感應器觸發條件，當偵測到「螢幕反轉朝下」或「 proximity sensor 被遮蓋」時，自動執行用戶預先指定的動作。此功能可整合至「捷徑」自動化或「輔助使用」設定中。 建議可選動作包括： 將螢幕亮度調至最低，或開啟「降低白點值」 直接黑屏（模擬熄屏，但不鎖機） 靜音，或開啟指定專注模式 執行指定捷徑 開啟指定輔助功能 模擬「轉輪」操作，直接跳至或選取指定項目 關於第 2 項的具體建議： 當手機反轉朝下或感應器被遮蓋時，自動將螢幕變黑，但影片或音訊內容繼續播放，用戶可以純粹聆聽聲音，無需觀看畫面。如此既可節省電量，亦可避免螢幕長時間亮著造成耗電及燒屏風險，特別適合以下場景： · 聽 YouTube、Podcast、音樂影片時只想聽聲 · 睡前聽影片或節目，不想螢幕光影響睡眠 · 乘車、步行時只聽內容，不需要看畫面 · 小朋友聽故事影片時，避免長時間看螢幕 關於第 6 項的具體建議： 用戶可預先設定「手部遮住感應器達 2 秒」為觸發條件，觸發後自動執行「轉輪」中指定項目，例如： · 複製焦點框內容 · 返回 · 下一頁 · 上一頁 · 其他自訂轉輪選項 此設計可讓用戶無需觸控螢幕，只需用手遮住感應器約 2 秒，即可快速執行常用操作，特別適合單手操作、駕駛、運動或不便觸控螢幕的場景。 關於輔助使用及手部協調的具體建議： 此功能亦可輔助手部協調較弱的人士。對於手部協調能力較弱、容易手震，或因中風、柏金遜症、腦麻痺、肌肉萎縮等情況而難以精準觸控螢幕的用戶，現時要完成「長按」、「拖曳」、「雙指縮放」或準確點擊細小按鈕等操作，往往相當困難，甚至會誤觸其他功能。若能透過「反轉手機」或「遮住感應器」這類簡單、大幅度、無需精準定位的動作作為觸發條件，便可大大降低操作門檻，令這類用戶更容易使用 iPhone。 具體可應用於以下輔助場景： · 手震或協調困難用戶，不需要準確點擊「靜音」按鈕，只需將手機反轉放低即可靜音 · 難以完成「長按複製」動作的用戶，可以改為遮住感應器 2 秒即可複製焦點內容 · 難以滑動返回上一頁的用戶，可以遮住感應器代替滑動手勢 · 難以同時按實體鍵截圖的用戶，可以設定反轉手機或遮蓋感應器觸發截圖捷徑 · 難以精準控制螢幕亮度的用戶，可以反轉手機即自動調至最低亮度或黑屏 這類設計符合「輔助使用」中「替代操作方式」的原則，讓不同能力的用戶都可以用最適合自己的方式操作手機，而無需強行遷就現時以精準觸控為主的互動模式。 使用場景舉例： · 開會或上課時，將手機反轉放於桌面即自動靜音，無需解鎖操作 · 睡前將手機反轉即自動調暗螢幕，繼續聆聽影片內容或故事 · 視障或行動不便用戶，可透過簡單遮蓋手勢快速啟動輔助功能 · 手部協調困難用戶，可透過反轉或遮蓋感應器代替精準觸控操作 · 瀏覽網頁或文件時，遮住感應器 2 秒即可返回上一頁或跳至下一頁 · 需要複製文字時，無需長按或尋找選單，遮住感應器即可執行複製 · 聽影片或節目時，反轉手機即黑屏但繼續播放聲音，節省電量 建議加入防誤觸設計： · 延遲 1 至 2 秒才觸發，避免放置於袋或口袋時誤啟動 · 反轉回正面或設定觸發後震動提示，確認動作已執行 現時限制： 目前 iPhone 雖有 proximity sensor（通話時貼耳熄屏）及「螢幕距離」提示，但用戶無法自訂觸發後的動作；「捷徑」亦無「方向改變」或「感應器遮蓋」作為自動化觸發條件，令上述使用場景無法實現。現時用戶若想聽影片聲音而不看畫面，只能手動熄屏或切換 App，但往往會中斷播放，無法做到「黑屏但繼續播放」的效果。對於手部協調困難的用戶，現時亦缺乏簡單、大幅度、無需精準觸控的替代操作方式。 期望： 希望 Apple 可考慮開放此感應器作為自訂觸發條件，並容許用戶選擇上述動作。此功能對輔助使用、無障礙操作、省電及日常便利性均有明顯幫助，亦能進一步發揮 iPhone 感應器與捷徑生態的潛力。 感謝您閱讀此建議，期待未來 iOS 能加入相關功能。 ·

這個狀況，好像只是在網頁版出現。 https://www.icloud.com/iclouddrive/0aeH0i3LlslhNLZpH6asupAkg 上面是，影片示範。 這條影片示範，兩種語言不同步。 https://www.icloud.com/iclouddrive/003CXcS2B4Cm7uE6YxhgFah_g 第一，旁白內「偵測語言」開關關閉後，部分文字與符號會出現無法朗讀的情況，系統已設定繁體中文、簡體 中文，問題仍然存在。此現象在 iOS 26 之前的版本並未發生。 如果開啟了偵測語言，，第二種語言速度無法調節，導致體驗很差。 希望解決的問題是。關閉，偵測語言，所有語言也是用預設的旁白去，朗讀。。速度一樣，旁白聲音也一樣。 修復，有些符號文字，或者其他語言，無法朗讀的問題。 之前在iOS 27供測版也反應過這個問題。一直沒有解決。

Every new build of macOS 26 further breaks some part of text-to-speech or voice control. I have filed multiple bug reports on this, yet the situation gets worse, not better, with each new build. I am begging you to fix this! I am disabled and rely on these features to work. Accessibility in macOS is more than 50% of my reasons for choosing Macs over Windows. Here's some of what is currently broken: Speak announcements only works if the Samantha voice is selected. If other voices are selected either the announcements don't speak, or they default to the Samantha voice. This became broken with 26.1. Announce the time only works with some voices. I would like to use Australian English Siri 2 but with that voice selected it defaults to Samantha. This became broken with 26.4. With voice control enabled there are two menu bar icons. The blue voice control icon and an orange microphone "an application is accessing the microphone" icon. This orange icon started appearing with 26.3. For four years of macOS releases, the orange warning didn't apply to system services. And note that with voice control enabled on iOS there is no orange icon. It wastes valuable menu bar space and defeats its purpose. With that orange icon always being there I have no indication if a nefarious app starts recording me. This became broken with 26.3. Overlay shows numbers even when it is set to none. This has been broken since at least 14.0. I don't remember if it was broken in prior versions but it has been broken in every version since 14.0. The voice control control center widget is defective. If voice control is not in the menu bar (for example if I've said "Siri turn off voice control") using the control center widget to turn it on brings about the orange icon, but not the blue icon actually used for controlling voice control. If you do have the blue voice control icon and use control center to turn off voice control the blue icon stays but voice control is not enabled. This became broken in 26.0, was fixed in 26.2, broke again in 26.4. When using voice control to edit text (aka dictation mode) saying "go to the end of the line" invariably goes to the beginning of the line. Once in a blue moon it will go to the end, but there is no rhyme or reason and it's rare that it does. Since this bug was added it has worked correctly exactly twice. This became broken in 26.3 (possibly 26.4). I know I am missing some issues. Voice control and text-to-speech have new bugs with each new build of macOS 26. My main Mac is being repaired and once I get it back I'll be installing macOS 15 Sequoia on it because of these issues. These issues stop me from buying a new Mac because any new Mac will only run the broken macOS 26. I file bug reports on each build when I discover another new issue, but these reports seemingly go unread. I would suggest Apple get a focus group of disabled people together and do research into how we use macOS. Find what's broken and what works. And if Apple does this I would be glad to be a part of that group. My place, or yours. Accessibility at one time was something Apple was proud of. It was some Apple showed off. But now, I'm not so sure. It's starting to look like Apple doesn't care. I hope I'm wrong, and that Apple does care, so... Please, Apple. I am begging you. Fix broken Text-To-Speech and Voice Control!

標題重點： 螢幕反轉即黑屏，停止亮度感應器與 Face ID 自動掃描，開啟黑屏功能 反饋內容： 您好，我經常使用 iPhone 的旁白功能。建議在旁白開啟時，新增「螢幕反轉即黑屏」選項。 目前建議改善。 手機螢幕朝下反轉時，遇到來電、鬧鐘或新訊息通知，螢幕仍會全程亮起，Face ID 與光線感應器持續運作， 建議功能： 螢幕反轉時立即黑屏，停止 Face ID 與光線感應器掃描，並可選擇靜音。 螢幕反轉時，或可自動將螢幕亮度調到最低；翻回正面時，自動恢復原本亮度。 黑屏狀態下仍可繼續聆聽影片聲音與旁白朗讀內容。 恢復正常方向時，所有功能自動回復。 全程由感應器自動判斷，無需手動操作黑屏。 利用距離感應器與陀螺儀，自動偵測手機是否反轉朝下，即時開啟或關閉黑屏模式，更加人性化與智能。 實用場景例子： · 睡前聽小說： 用旁白聆聽純文字小說，手機反轉放床頭，螢幕不亮、不干擾睡眠，卻能持續聽內容。 · 搭車看影片： 通勤時用手機看影片，反轉手機放在口袋或腿上，只聽聲音，避免螢幕亮起引人側目或耗電。 · 開會或上課： 手機反轉放桌上，來電或通知不會亮屏，只以震動或靜音提示，需要時再翻回查看。 · 低視力者操作： 仍有剩餘視力的使用者，反轉時可黑屏省電，翻回正面又能用剩餘視力輔助操作，兼顧聆聽與視覺。 · 早上起床： 鬧鐘響起時，反轉手機即可停止鬧鐘或貪睡一會兒，螢幕不亮，避免強光刺眼。 益處： 對仍有剩餘視力的使用者特別有幫助，既能省電、降低干擾，又能用剩餘視力輔助操作，同時享受旁白聆聽體驗。全程自動感應，無需手動切換，更加人性化與智能。 希望 Apple 能考慮新增此無障礙選項，

https://www.icloud.com/iclouddrive/040HIn78YWELC_Yq34koLgcIg 上面的是影片示範。 意見反應：統一密碼輸入介面、語音提示與改善旁白朗讀 系統中多個輸入密碼的介面不一致，例如： 影片示範，前半部。 · 輔助使用 > Face ID 與螢幕注視：輸入密碼時會朗讀「密碼」，還有一連串多餘數字。 影片示範，中段。 · 輔助使用 > 輔助取用：輸入密碼時最好，只有聲音提示，沒有多餘朗讀。 影片示範，尾段。 · 設定 > Face ID 與密碼：只朗讀「密碼」，希望連這個也隱藏。 希望統一所有密碼輸入介面，全部採用「輔助取用」的方式：只保留聲音提示，不朗讀密碼字詞，也不播報輸入的數字。 統一介面的好處：方便完全失明的使用者，只需記住一個密碼輸入介面，就能直接捉摸位置、快速操作，不用每次重新適應不同介面。 另外，設定 > 輔助使用 > 旁白 > 詳細內容 > 提示，這個「提示」建議改成「新手提示」，讓使用者更容易理解這項功能的作用。目前即使關閉了這個功能，還是有很多地方會朗讀多餘的內容。希望在繁體中文介面上，可以減少多餘的朗讀，讓操作更簡潔。 header 1

When navigating web components (such as accordion containers or form card containers) using Safari with VoiceOver Hints enabled, VoiceOver inappropriately prefix-announces "list item" prior to speaking form field labels ( or aria-label). Inspection of the rendered DOM confirms there are no list elements (, , ) or list ARIA roles (role="list", role="listitem") anywhere in the element hierarchy or parent container. This behavior is reproducible on native/standard web components across multiple domains, including non-Salesforce test sites such as WebAIM.org. Environment & Configuration Operating System: macOS Sonoma / Sequoia (or iOS 17 / iOS 18) Browser: Safari (Latest Stable & WebKit Nightly) Assistive Technology: VoiceOver Required VoiceOver Settings: VoiceOver Utility > Verbosity > Hints → Enabled Steps to Reproduce Enable VoiceOver (Cmd + F5 on macOS). Ensure VoiceOver Hints are turned ON under VoiceOver Utility > Verbosity > Hints. Open Safari and navigate to any standard web container containing a form field (e.g., an accordion element or card container wrapping standard text inputs). Use VoiceOver navigation key commands (VO + Left/Right Arrow or Tab navigation) to place focus onto a form field label or text input inside the container. Listen to the VoiceOver speech output string. Expected Behavior VoiceOver should announce only the accessible name/label, input role, and state. Example: "First Name, edit text" Actual Behavior VoiceOver speaks "list item" prior to reading the label and role. Example: "List item, First Name, edit text" Code / DOM Verification To verify that this is an accessibility tree/rendering engine misinterpretation rather than a markup bug, the target container was inspected: HTML

Platform & OS Version: iOS 27 Screen Reader: VoiceOver Framework: SwiftUI / UIKit / WebKit (WKWebView) Issue Summary: When updating dynamic text or UI elements containing fraction values—whether using Unicode fraction glyphs (e.g., ½, ¾) VoiceOver in iOS 27 completely omits and skips reading the fraction value entirely. Steps to Reproduce: Enable VoiceOver on iOS 27 (Settings > Accessibility > VoiceOver). Open an app or web view where fraction values, tap to focus on the element or trigger voice over Expected Result: VoiceOver should speak the accessible label or text content (e.g., "one half") Actual Result: VoiceOver skips the fraction entirely, reading only surrounding text or remaining silent over the fraction value.

I am testing out the new auto-generated subtitles feature on iOS 27 and tvOS 27. It works on iOS, but not on tvOS. Very same HLS videos. Anyone have any experience with auto-generated subtitles on tvOS 27? AFAICT, there is no special code needed to enable this feature for our apps, correct?

https://www.icloud.com/iclouddrive/0e16-6zsa3ZnMkAsuLtdqiInA 不好意思，發現到之前給你們的意見中沒有附件，有時候勾選了的附件檔案，它沒有上載到，可能是我操作失誤。 另外，不確定是不是附件檔案限制或容量問題，我這邊有些影片上載後，選擇下載觀看時會提示失敗。有些沒有檔案。 我花了很多心機錄製反饋問題的影片，真的很抱歉，我重新將之前的所有內容發一次，改用 iCloud 空間發給你們看視頻反饋，這樣會更清楚明白遇到的問題，也方便你們在優化上參考。 謝謝你們，辛苦了。 希望可以重點關注。。 第一張。 第二章。 第三章。 重點關注者，三個優化 主题：关于无障碍体验优化的反馈与建议 尊敬的开发者团队： 您好！ 我是一名低视力用户，平时在使用各类应用时，会同时从视觉和屏幕朗读操作层面发现一些无障碍相关问题。 相比一般用户，我反馈的内容往往更全面、具体，也更能反映视障群体实际遇到的困难。 另外，我本人也有手部协调方面的问题，因此对于放大屏幕后所需操作手势所遇到的困难，我更能体会，也更加理解。尤其是返回（Back）操作是否便捷，对我来说尤为重要。 感谢你们一直以来的用心开发与持续维护。 我想特别说明一点：每一则意见背后，可能都代表着成千上万拥有相同困扰的使用者。但会主动花时间反馈问题的人，本来就是小众中的少数。团队有时可能会认为这些只是小众需求，不值得投入资源优化。然而很多时候，一个看似微小的逻辑调整，便能大幅改善全体视障用户的使用体验。 因此，诚挚希望你们能重视这类无障碍问题，多多参考视障团体的反馈，并在后续版本中进行修复与优化，让视障用户也能平等、顺畅地使用各项功能。 感谢你们一直以来的用心开发，期待你们的优化，谢谢！ [https://drive.google.com/file/d/1GL9cm8NbJfvOECpl0x08VRXQXQX0tACZ/view?usp=drivesdk)

Hello, I'm having a very hard time finding where any documentation or session or any WWDC related announcement related to the FaceTime API that was mentioned in this press release last month. https://www.apple.com/newsroom/2026/05/apple-unveils-new-accessibility-features-and-updates-with-apple-intelligence/ "For sign language interpretation app developers, a new API supports users in adding a human interpreter to an ongoing FaceTime video call." Can anyone please point me in the right direction? I have searched everywhere in Developer.app, documentation released during this WWDC, and here in the Forums and have yet to find anything.

I am unable to dismiss Voice Control Siri AI bubble when enabling Voice Control in iOS 27. Can someone from accessibility team provide guidance on how to dismiss without touching the screen in the activation flow? Siri bubble remains on screen... Thank you, and appreciate all the work you do. Voice Control is an amazing capability system wide.

Hello, In this press release from last month: https://www.apple.com/newsroom/2026/05/apple-unveils-new-accessibility-features-and-updates-with-apple-intelligence/ It indicates the following: "For sign language interpretation app developers, a new API supports users in adding a human interpreter to an ongoing FaceTime video call." I have looked over the WWDC26 sessions but have not been able to find any information on this new API. Can you point me in the right direction? Thank you!

Feature Request: Native Acapela Voice Library Integration & Cross-Pipeline Voice Sharing Associated Feedback Feedback Assistant Ticket: FB23666342 1. The Core Proposal On behalf of the assistive technology and screen-reader community, I am requesting the native system-level integration of the comprehensive Acapela Voice Library into iOS and macOS. This library should be added as a native synthesizer tier alongside existing options like Eloquence. Additionally, we request cross-pipeline voice compatibility, allowing the Siri assistant to utilize configured VoiceOver voice assets, and allowing VoiceOver to utilize Expressive Siri neural models. 2. Structural UI Layout Concept To maintain system cleanliness while maximizing user choice, we propose grouping the Acapela catalog exactly like the current native Eloquence implementation: A main, expandable heading titled Acapela inside the Speech rotor settings. Under this heading, voices should be strictly categorized by global regional dialects (including English U.S., English UK, Australia, India, Scotland, and all other languages offered to AT vendors). This deployment must include all specialized character profiles (such as the Little Creature variant) and their pediatric/child voices catalog. 3. Addressing Ear Fatigue and Equity While parametric synthesizers are excellent for high-speed text scanning, extended multi-hour document audits cause severe cognitive ear fatigue due to compressed, robotic waveforms. Integrating the full Acapela catalog—including both 22kHz HQ (High Quality) profiles for natural reading stamina and 22kHz CO (Colibri/Compact) profiles for rapid responsiveness—allows blind and low-vision power users to pick their preferred acoustic texture. Natively licensing this library eliminates the unfair financial barrier of third-party lifetime licensing fees, creating true out-of-the-box system equity. If you want to check out my post on expressive Siri, see below. Link: https://developer.apple.com/forums/thread/834920

Hi everyone, With the initial rollout of the iOS 27 Beta, the advanced configuration sliders for the new, highly expressive Siri voice models are currently hidden/disabled on devices operating under an 8GB RAM threshold. While the local AFM 3 Core Advanced engine is memory-gated to 12GB+ hardware due to local footprint constraints, this creates a significant barrier for users who rely on next-generation vocal expressivity and fluid dictation features for accessibility. To address this, I have filed a formal feature request (FB23178983) asking Apple to route the expressive Siri framework through Private Cloud Compute (PCC) on 8GB devices (like the iPhone 15 Pro or base iPhone 16 models). By utilizing server-side rendering over secure, stateless cloud nodes, Apple could easily deliver these vital accessibility configurations without exhausting the local 8GB memory footprint. I’m curious if other accessibility testers and auditors on this board are looking for this exact routing path? If you or your users rely on advanced speech synthesis features and are currently locked out by the local RAM gate, please consider filing a duplicate request or adding your diagnostic logs to FB23178983 to help increase visibility with the Core Accessibility and Software Architecture triage teams. Looking forward to hearing your thoughts and experiences with the current voice-indexing behaviors on 8GB hardware!

Hi, guys, so some apps needed accessibility in order to do some things on my mac, (macos 27) yet the tab has disappeared from my privacy and security tab?

Feedback Assistant ID: FB24788469 (Cross-reference: Complementary to third-party TTS framework initiatives logged in FB23666342) Overview With the continued evolution of on-device machine learning and Apple Silicon's unified memory architecture, I propose that Apple evaluate expanding the native VoiceOver speech library in the upcoming iOS 28 cycle to incorporate lightweight, natural acoustic and neural voice models—specifically the profiles utilized across ChromeOS, Android, and CNET accessibility pipelines (including the natural Google Assistant voice profile). Hardware Feasibility & RAM Footprint • Demonstrated Efficiency on 8GB Systems: In real-world desktop testing across both an ASUS laptop and an HP laptop configured with 8GB of RAM, these voice profiles operate with near-instantaneous responsiveness, zero audio stutter, and negligible memory overhead. • Client-Side Execution Proof: In testing with NonVisual Desktop Access (NVDA)—an open-source Windows screen reader for blind and vision-impaired users—these voices run client-side using Google's WebAssembly (WASM) text-to-speech engine via background Chromium runtimes. Even during heavy UI tree navigation and multitasking, the 8GB systems run effortlessly without memory pressure warnings, UI latency, or process termination. • Viability Across 8GB & 12GB Apple Silicon: Apple Silicon devices leverage high-bandwidth unified memory and dedicated Neural Engine cores. Compiling or running these lightweight neural acoustic models via Core ML on all 8GB and 12GB devices running iOS 28—as well as future hardware generations—leaves substantial headroom for foreground apps without risking memory eviction. Technical & Practical Justification 1. Prosody and Auditory Fatigue: Modern neural synthesis captures natural cadence, warmth, and contextual phrasing, substantially reducing listening fatigue during multi-hour screen reading sessions compared to older formant or diphone synthesizers. 2. Deterministic On-Device Latency (Sub-50ms): Screen reader users require immediate auditory feedback when navigating character-by-character or word-by-word. Running these models locally on-device guarantees the sub-50ms response times essential for VoiceOver, with zero network latency and complete offline reliability. 3. Cross-Platform Continuity & Inter-Platform Synergy: Blind and low-vision users who switch between desktop environments (such as Windows with NVDA or ChromeOS) and iOS benefit greatly from vocal consistency across their workflows. Furthermore, given Apple's established collaboration with Google regarding foundational AI models, exploring speech asset licensing or compiling these lightweight voice packages into native iOS speech audio units represents a logical, accessible extension of existing synergy. Proposed Solution Provide downloadable, on-device voice packages for these high-efficiency neural and ChromeOS-style profiles directly within: Settings > Accessibility > VoiceOver > Speech > Voice in iOS 28. It would be greatly appreciated if I could get community feedback. If posting in a language other than English, I'll use Gemini to translate it into English and post the translation for English speakers as a reply to this post. Also, if you want to check out my posts on Acapela's voice library integration, and my Expressive Siri posts, check out the links below and give me your thoughts on them as well. This post will be cross-linked on those as well, creating a closed triangular circuit. Expressive Siri Link: https://developer.apple.com/forums/thread/834920 Acapela Voice Library Integration Link: https://developer.apple.com/forums/thread/837701

header 1 於無障礙旁白功能使用上，存在數項可優化項目。 第一，旁白內「偵測語言」開關關閉後，部分文字與符號會出現無法朗讀的情況，系統已設定繁體中文、簡體中文，問題仍然存在。此現象在iOS 26之前的版本並未發生。 第二，旁白朗讀功能有時會失效、沒有聲音，必須關閉旁白再重新啟用，才能恢復正常。 第三，旁白詳細程度設定中，雖已關閉新手提示，仍然會出現大量多餘播報內容。另外在輔助快取模式之下，部分旁白手勢無法正常運作，最常用由底部向上滑動返回主螢幕的手勢會失效。 懇請開發團隊優化中文介面旁白多餘播報內容，在已關閉新手提示的前提下，讓旁白播報更加清爽簡潔，並修復上述各項狀況。

Hello everyone, I am the developer of a macOS window management app called NeoTiler. I am currently optimizing it entirely for Apple Silicon using Swift. I am using the Accessibility API (AXUIElementSetAttributeValue) to resize windows. While it works flawlessly on Safari and native apps, I've noticed a slight animation stutter when resizing Electron-based apps like VS Code or Discord. Has anyone experienced this specific stutter with AX APIs on M-series chips? Are there any workaround flags I should pass? Thanks!

Hi 👋, I’m working on improving Full Keyboard Access support in an iOS app and would love to hear about your experience. When developing for keyboard navigation, what approach do you usually take for navigating between UI elements? Do you mainly use Tab/Ctrl+Tab, arrow keys, or a combination of both? I’ve already watched some WWDC sessions and Apple's docs on this topic: https://developer.apple.com/design/human-interface-guidelines/keyboards https://developer.apple.com/videos/play/wwdc2021/10120/ https://developer.apple.com/videos/play/wwdc2021/10260/ https://developer.apple.com/documentation/UIKit/navigating-an-app-s-user-interface-using-a-keyboard However, I’d appreciate any recommendations for useful resources, documentation, or things to be aware of when implementing keyboard accessibility. :🙏