你好，我是一名iPhone使用者。 我強烈建議 Apple 在 iOS 系統的內建「時鐘」App 中，新增「定點報時」功能。 目前的痛點： 一直以來，iPhone都沒有原生、簡單的定點報時功能。 如果想做到每30分鐘或每60分鐘自動播報時間，使用者只有兩個非常麻煩的選擇： 用「快捷指令」App自己建立自動化：但因為iOS的限制，沒有「每小时」這個選項，導致需要手動建立24個（甚至更多）自動化，步驟極其繁瑣，而且很容易遺漏或設定錯誤。 下載第三方報時App：雖然稍微方便，但往往伴隨著大量廣告、需要付費，而且長期在後臺執行會增加耗電，更有隱私安全上的隱患。 建議方案： 希望Apple可以考慮在「時鐘」App中，加入以下原生功能： ·報時頻率：允許使用者自定義每30分鐘、每60分鐘（或者每15分鐘）報時一次。 ·報時方式：提供「語音播報現在時間」（例如：「現在是下午3點30分」）或「純聲音提示」（例如：鐘聲、滴答聲）兩種選擇。 · 生效時間：允許使用者設定報時的時間段（例如：只限早上8點到晚上10點），避免晚上睡覺時被打擾。 · 專注模式配合：可以選擇在「靜音模式」或者「專注模式」下自動暫停報時。 為什麼需要原生功能？ 「時鐘」App 是一個基礎且高頻使用的工具。 加入原生定點報時，不能幫助到需要定時提醒的使用者（例如：辦公室工作、做飯、運動計時、長者提醒），還可以大大提升系統的一體化體驗。 使用者不需要再依賴第三方應用程式，也不需要浪費時間去建立幾十個「快捷指令」自動化，一舉多得。 希望蘋果開發團隊可以認真考慮這個建議，在未來的iOS版本中加入這個人性化的功能。 謝謝！

你好，我是一名 iPhone 用户。我强烈建议 Apple 在 iOS 系统的内置“时钟”App 中，新增“定点报时”功能。 目前的痛点： 一直以来，iPhone 都没有一个原生、简单的定点报时功能。如果想做到每 30 分钟或者每 60 分钟自动播报时间，用户只有两个非常麻烦的选择： 用“快捷指令”App 自己建立自动化：但因为 iOS 的限制，没有“每小时”这个选项，导致需要手动建立 24 个（甚至更多）自动化，步骤极其繁琐，而且很容易遗漏或者设置错误。 下载第三方报时 App：虽然稍微方便，但往往伴随大量广告、需要付费，而且长期在后台运行会增加耗电，更有隐私安全上的隐患。 建议方案： 希望 Apple 可以考虑在“时钟”App 中，加入以下原生功能： · 报时频率：允许用户自定义每 30 分钟、每 60 分钟（或者每 15 分钟）报时一次。 · 报时方式：提供“语音播报现在时间”（例如：“现在是下午 3 点 30 分”）或者“纯声音提示”（例如：钟声、滴答声）两种选择。 · 生效时间：允许用户设置报时的时间段（例如：只限早上 8 点至晚上 10 点），避免晚上睡觉时被打扰。 · 专注模式配合：可以选择在“静音模式”或者“专注模式”下自动暂停报时。 为何需要原生功能？ “时钟”App 是一个非常基础且高频使用的工具。加入原生定点报时，不仅可以帮到需要定时提醒的用户（例如：办公室工作、做饭、运动计时、长者提醒），还可以大大提升系统的一体化体验。用户不需要再依赖第三方 App，也不需要浪费时间去建立几十个“快捷指令”自动化，一举多得。 希望 Apple 开发团队可以认真考虑这个建议，在未来的 iOS 版本加入这项人性化的功能。谢谢！

This post is a translated and condensed version of the original article: https://developer.apple.com/forums/thread/843626. ChatGPT was used to help refine the English wording and shorten the content to meet the 7,000-word limit. The original meaning and key suggestions have been retained as much as possible. A Letter to Apple’s Accessibility Engineering Team 1. Purpose I am a visually impaired user from Hong Kong and have used iPhone VoiceOver and Zoom for many years. I have encountered issues with zoom gestures, focus handling, and pop-up navigation. Please log these proposals and diagnostic files as a formal feature request and forward them to Apple’s Asia-Pacific accessibility engineering team. 2. User Feedback Challenges Many visually impaired users face similar barriers, but official feedback often receives no follow-up. Front-line staff may lack the expertise to communicate these issues accurately, so reports can be treated as general usability problems rather than accessibility concerns. Small system changes could help many people, while active reporters represent only a fraction of those affected. 3. Screen Zoom Gestures When VoiceOver is enabled, activating Zoom with a three-finger double-tap can be difficult for people with hand tremors or limited dexterity. Coordinating three fingers makes it hard to target an area accurately, pan smoothly, and maintain consistent screen contact. The Zoom Controller can obscure content and may be accidentally activated alongside nearby controls. Apple could explore simpler gestures like Android’s magnification, which uses one finger to activate and two fingers to adjust or pan, while retaining the zoom level after the fingers leave the screen. 4. VoiceOver Gestures and Focus 4.1 Customisable Gestures Common actions can require navigating several Rotor options. Add customisable gesture combinations, such as swiping up then down or left then right, to trigger shortcuts. Customisable virtual bars along both screen edges could also provide audio or haptic feedback when touched and held, then trigger shortcuts when users swipe up or down by different distances. 4.2 Automatic Focus Grouping In third-party apps, labels and their switches are often separate VoiceOver focus elements. Automatically grouping related labels and switches would let VoiceOver announce the information and allow users to operate the switch without an extra swipe. 5. Contrast and Selection Visibility System switches can be difficult for users with low vision to distinguish. Consider a highly saturated dark-blue track when enabled, with a contrasting thumb colour, to make its state clearer than the grey disabled track. Make Settings checkmarks bolder or give selected items a dark background. In multi-select lists, consider a separate tab for selected items or automatically moving selected items to the top. This would make selection states easier to identify visually and with VoiceOver. 6. Native iOS Keyboard Keyboard size and editing: Allow keyboard-height adjustment and an optional full-screen text-editing mode for reviewing text in small third-party fields. High contrast: Offer a black keyboard with white text and keep its appearance consistent across apps when Dark Mode or Smart Invert is enabled. Dictation: Let users start dictation by holding the space bar and stop when they release it. Chinese speech-to-text: Improve language models and use sentence context to distinguish homophones and correct errors, especially for long dictation by VoiceOver users. 7. Assistive Access Assistive Access can disable VoiceOver gestures, including swiping up from the bottom to return Home. Improve compatibility between the two features. Consider adding power-saving options such as reducing screen resolution and CPU frequency, using a pure-black theme, and disabling image loading. These options could help users with older devices, visual impairments, or other accessibility needs. 8. Real-Time AI Screen Recognition Third-party apps may have buttons that cannot receive accessibility focus, missing labels, or controls that existing screen recognition cannot identify. Apple could develop system-level AI to analyse screens in real time, identify interface elements, generate labels, and make interactive controls actionable. If reliable enough, this could address more barriers at system level. Apple could also explore a shared accessibility-label database where users submit corrections that synchronise across apps and devices. 9. Navigation and Pop-up Dismissal With VoiceOver, returning to a previous page often means swiping through elements to find a small Back button. Expand its accessibility hit area so it is easier to locate and activate. Close and Cancel buttons appear in inconsistent locations, and pop-ups, nested menus, or keyboards can be difficult to dismiss. Where appropriate, tapping outside a pop-up should dismiss it by default, reducing the risk of users becoming trapped. 10. Traditional Chinese Settings and Navigation Some Traditional Chinese accessibility settings have vague names or descriptions. Clarify options such as VoiceOver “Hints” and reduce redundant announcements that may continue even after Hints are turned off. Group related settings—such as Raise to Wake, Tap to Wake, and automatic brightness—on the same page. Place icons beside titles and descriptions rather than stacking them vertically, so more options fit on screen and VoiceOver users need to scroll less. 11. Ultra Low Power Mode Add an Ultra Low Power Mode alongside Low Power Mode, with optional controls to: Pause animations and GIFs. Disable non-essential system animations and visual effects. Disable autoplay for message effects, video previews, and animated content. Disable selected display adjustments where supported. Turn off Liquid Glass effects where possible. Turn off Raise to Wake by default. Disable app suggestions, learning, and shortcuts in Search, widgets, and notifications. Place these controls in one panel, with a low-power default and the option to re-enable features individually. Reducing unnecessary animation and background processing could improve battery life, responsiveness, and device temperature, depending on the device and implementation. A simpler interface could also reduce visual distractions for VoiceOver users. 12. Summary These proposals address barriers to the everyday independence of people who are blind or have low vision. Even small changes could help users operate their devices more easily. I hope Apple will take these suggestions and users’ real-world experiences seriously. Submitted by: A visually impaired user from Hong Kong, China

。 2026年2月23日，我對部分錯別字及語句進行了修訂，並重新整理內容分段，期望能讓各位更易理解所述內容，謝謝各位。 一、申請事由 本人為香港視障用戶，長期使用iPhone的「旁白」及「放大模式」功能，發現系統中的放大手勢、焦點識別及彈窗返回邏輯存在諸多操作障礙。我已整理完整的改良方案及機器系統診斷檔案，並不希望僅作為一般問題記錄處理，懇請協助將此登記為正式功能申請，並轉交亞太區無障礙研發小組跟進。 致蘋果無障礙工程團隊的一封信 二、用戶意見反饋所面臨的困境 我與身邊許多同路人皆有一致感受：系統內許多無障礙邏輯實有相當大的改善空間，但每次經由官方管道反饋意見，最終大多石沉大海。負責接收意見的前線人員普遍缺乏無障礙領域的專業認知，無法準確傳遞我們所遇到的核心痛點，僅會將其視為一般使用問題歸檔，不會列為優先處理事項，自然無法傳達至具決策權的工程團隊及管理層。 很多時候，一個看似微小的邏輯調整，便能大幅改善全體視障用戶的使用體驗。然而團隊往往認為這些僅屬小眾用戶需求，不值得投入資源優化。但各位未必知曉，會主動花時間反饋問題的用戶，本來即屬小眾群體中的少數，每一則意見背後，代表的皆是成千上萬擁有相同困擾的使用者。 三、螢幕縮放手勢邏輯優化建議 關於螢幕縮放功能的手勢邏輯，我認為存在相當大的優化空間。目前iOS須以三指連點兩下才能開啟放大，此設計對於有手震、手指靈活性不足的用戶而言，門檻實在過高。三指同時點擊，根本無法精準對準欲放大的位置；拖動畫面時須三指同步移動，經常猶如打滑般，完全無法掌控畫面移動的幅度。只要其中一隻手指的指甲稍長，接觸螢幕不均勻，失誤率便會大幅上升；再者，對於手指不靈敏的人來說，這簡直是高難度的協調動作，極不人性化。 我知道iOS設有縮放控制器，可以單指點擊按鈕放大、拖動平移，但一旦鬆開手，畫面便會自動縮小，完全不符合日常使用習慣。再者，須按指定位置的放大按鈕，而螢幕上新增的浮動按鈕屬於懸浮式，有機會遮擋部分內容；在旁白場景下使用時，點擊時可能誤觸其他按鈕，這亦不甚人性化。反觀Android系統的放大邏輯則合理得多：任意位置單指連點三下即可開啟放大模式，單指接觸面積小，點擊位置的準確度大幅提升。開啟後以雙指捏合即可自由調整放大倍率，雙指一同拖曳即可平移畫面，即使手指離開螢幕，放大狀態仍會維持，不會自動退出。不論是操作難度或實用性，皆遠勝於iOS現有的放大邏輯操作手勢，確實亟需改善。 四、旁白快捷手勢與焦點識別的改良方案 4.1 擴充旁白可用的快捷手勢 旁白的快捷手勢數量亦有擴充之必要。目前旁白可用的手勢數量有限，許多常用功能須進入轉輪選單翻越數層方能使用，操作效率甚低。建議可參考Android的手勢設計，加入組合方向手勢，例如先向上再向下、先向下再向上、先向左再向右、先向下再向左等連續滑動手勢，每個組合均可讓用戶自訂對應的快捷功能，無須每次轉動轉輪挑選，單次手勢即可完成操作。 升級小橫條功能 參考現有螢幕底部中央指示小橫條的操作形式，進行功能擴充。新增兩組小橫條，可自訂的側邊虛擬橫條，置於畫面左側和右側。用戶對橫條進行短暫停留觸控，成功偵測後給予聲音或震動反饋，其後再向上、向下滑動不同長度，以觸發各項自定義快捷功能。 4.2 新增智能焦點自動合併功能 智能焦點合併功能亦是我們相當期待的一項優化。特別是第三方App，許多功能的標題與對應的開關皆分為兩個獨立焦點，旁白須掃描兩次才能讀完資訊再操作開關。自動合併功能可將具對應關係的標題與開關穩定合併為單一焦點，旁白朗讀一次即可直接控制開關狀態，減少所有介面多餘的滑動步驟。 五、系統開關顏色對比度的調整建議 系統控件的顏色對比度對低視力用戶至關重要。目前系統開關的開啟底色與滑動圓點顏色過於接近，對比度不足，開關的小圓點是白色，開啟的底色是綠色，關閉的底色是灰色，三種的顏色對比不明顯。低視力人士難以一眼分辨為開啟或關閉。建議將開啟的小圓點和狀態的底色改為高飽和度的深藍色，與關閉狀態的灰色形成強烈對比。 目前設定中的勾選圖標辨識度偏低，難以直觀分辨開關的啟用狀態。另外，在多選勾選的場景中，建議將選中的勾號改為粗體，或直接為選中項目加上深色底色，讓低視力用戶能快速判斷選擇狀態。 額外增加兩種優化方案：第一，新增獨立分頁，將所有已選取的選項統一收納於此頁面中；第二，令已勾選的項目自動排序至清單最上方，依序擺放。如此可方便低視力使用者一眼分清選取狀態，搭配旁白使用時亦可減少辨識耗時，提升操作順暢度。 六、原生系統鍵盤的功能改良建議 iOS原廠鍵盤存在數處使用上的不便，對視障人士及手部活動不靈活的用戶尤為困難，具體改良建議如下： 1. 容許用戶自行微調，調節鍵盤的高度，並加入鍵盤內置可固定使用的全螢幕文字編輯模式。許多第三方應用程式的輸入框面積狹窄，難以修改文字內容，統一內置鍵盤的全螢幕輸入能大幅提升編輯準確度，可選擇常開或手動切換。另外，希望新增專屬的黑色高對比鍵盤樣式，切換深色模式、開啟智慧型反轉時，所有程式統一調為黑色底色配白色文字，杜絕強制彈出白色鍵盤的情況，幫助低視力用戶清晰分辨文字。現時第三方Apps有些會強制彈出白色鍵盤。 2. 增設快捷操作手勢，長按空白鍵即啟動語音輸入，放開手指即時停止錄音，無須點擊麥克風圖示。 3. 優化iOS系統的語音輸入轉文字模組，升級中文語言模型，利用完整句子的前後語境進行語義邏輯推算，避免單獨辨識字音而產生大量同音字錯誤。透過上下文判斷詞彙的真實含義，自動修正同音錯字，大幅提高轉換精準度，尤其適合開啟旁白的視障用戶口述長篇文字、撰寫反饋意見的使用場景。 七、輔助取用模式的兼容性與功能優化 輔助取用模式的定位與兼容性亦有相當大的調整空間。目前開啟輔助取用模式後，許多旁白的原生手勢會直接失效，最常見者即為底部橫條上滑返回主畫面的手勢失效，此點務必優化兼容。同時，建議重新定位該模式的實用性。與其僅為放大介面，不如加入超級省電的選項，容許用戶自訂降低螢幕解析度與CPU更新率，再配合純黑色主題，並可選擇關閉圖片載入的開關。如此不僅能大幅提升電池續航，還能加快系統運行速度，對於舊機用戶、視障用戶及特殊族群而言，會比單純放大按鈕實用得多。 八、螢幕AI即時識別功能的升級方案 現有螢幕識別功能的升級，是解決第三方App無障礙問題的關鍵。目前許多第三方App的無障礙適配做得甚差，有些按鈕沒有焦點，導致無法點擊操作；按鈕沒有文字標籤、控件無法識別，單靠現有的螢幕識別功能難以應付。建議團隊研發更強大的螢幕即時AI分析功能，透過系統層級的AI，自動識別App中的按鈕、文字、圖片及各種控件，自動加上對應的標籤與可操作框架。若此技術能臻於成熟，便無須再依賴第三方開發者進行無障礙適配，單靠系統即可解決絕大部分App的無障礙問題，從根本上改善視障用戶使用第三方App的體驗。同時，可建立一個共用的按鈕標籤資料庫，透過AI自動修正、補全沒有標籤的按鈕，並支援全世界所有用戶雲端同步修正。 九、頁面返回與彈窗退出交互邏輯的優化 頁面返回與退出的邏輯，是長期以來的頭痛問題。開啟旁白後，絕大部分第三方App無法用手勢快速返回上一頁，必須逐一掃動，找到左上角那顆細小的返回按鈕才能操作，步驟繁瑣且難以定位。建議從兩方面著手改進：一是系統層面強制擴大返回按鈕的旁白焦點感應範圍，即使按鈕本身細小，焦點感應區仍擴大到周邊空白位置，方便直接點擊。 此外，所有關閉、取消這類按鈕的位置沒有統一規範，有時在左上角，有時在右上角，有時在底部，非常不人性化。同樣的問題也出現在彈窗、二級菜單及鍵盤的退出上。很多時候開啟旁白時，我們無法透過點擊空白區域退出彈窗或收起鍵盤，必須找到取消、關閉等按鈕才能操作，有時甚至會被困在頁面中。建議優化所有二級菜單與彈窗的交互邏輯，預設點擊空白區域即等同取消或關閉，解決使用者被圍困的問題。 十、繁體中文系統設置所有功能，文字說明的優化建議 繁體中文介面的翻譯與功能說明亦有優化之必要。目前設定中許多無障礙功能的標題與解釋皆甚模糊，容易令使用者混淆。舉例而言，旁白詳細程度中的「提示」功能，其作用為關閉多餘的新手引導播報，但目前的命名完全無法體現其用途，許多新用戶根本不知此功能為何。建議改為「新手提示」等更清晰的名稱，同時優化所有功能的說明文字，讓用戶一眼即明用途。同時，優化旁白的冗餘播報邏輯，當用戶關閉新手提示後，應儘量減少多餘的重複播報，提升操作效率。現時的繁體中文介面，關閉了新手提示，還是有很多多餘的播報。 設定佈局標題優化 系統設置，裏面。很多功能。拆分於不同分類頁面；抬起手機亮屏、點一下螢幕亮屏、自動調整螢幕亮度，等同屬螢幕喚醒與顯示的功能，亦分散於多個設定頁籤。使用者須穿梭多個頁面方能完成同類設定調整。 2. 設定項目垂直佈局空間浪費嚴重：現有設定頁面每個功能選項採用垂直堆疊排版，圖標、標題、說明文字上下排列，單一選項約佔六行高度，大幅消耗畫面空間。單頁可顯示的設定項目數量有限，使用者須頻繁上下滾動頁面尋找功能，大幅增加旁白導覽的操作步驟與時間。 改良建議 1. 按照功能使用場景與屬性重新規劃設定目錄架構，將同屬性的關聯功能整合至同一主題分頁，歸為一類，將所有螢幕喚醒、亮度調節相關開關集中於同一分頁，無須穿梭多個頁面切換開關。 2. 優化設定選項的排版邏輯，將圖標、標題、說明改為橫向排列：圖標固定於左側，標題與說明文字靠右側水平展示，壓縮單個選項的垂直高度，提升單頁資訊密度，讓同一畫面能顯示更多設定項目，減少滾動操作次數，優化旁白導覽的操作流暢度。 十一、建議在現有省電模式基礎上新增獨立的超級省電模式 。。 超級省電模式新增管控項目（標準省電模式未涵蓋）： 1. 動態內容全數暫停：動態圖標、動態圖案、GIF動畫等所有頁面動態影像停止播放。 2. 系統動畫全面停用：所有過場移動動畫、偏好交疊效果、淡出過場效果全數關閉。 3. 自動播放功能全關：訊息動畫效果、影片預覽自動播放、動態影像自動播放全部停用。 4. 畫面調色停用：「開啟減少明亮效果」、關閉原色調自動色彩適配功能。 5. 高耗電視覺架構停用：Liquid Glass相關視覺特效全數關閉。 6. 感應喚醒預設關閉：抬起手機喚醒功能預設停用。 7. App智能推薦全關：「在搜尋中顯示App」、從此App學習、App智能建議內容、App捷徑於搜尋/小工具/通知顯示等功能全部預設關閉。 在標準省電模式基礎上，進一步削減動態內容、視覺特效、智能推薦等多餘功耗，續航延長效果更為明顯，實現最佳省電化。 所有省電開關集中於同一控制面板，無須穿梭多層設定頁面；視障用戶透過旁白可快速檢視所有功能狀態，逐項調整，一目了然。預設極致省電組態，同時保留單項功能手動開啟權限，用戶可按自身使用場景自由組合，不強制全套捆綁套用。 視障用戶無須花俏的畫面特效，乾淨、簡潔、低干擾的系統環境才是核心訴求。超級省電模式可完全剔除多餘視覺元素干擾，讓旁白焦點更清晰、朗讀更連貫，無障礙體驗更佳。 大量多餘視覺運算與後台智能分析停止運作，大幅降低CPU與GPU負載，減少機身發熱與無故卡頓；對旁白等無障礙功能的運行穩定性提升尤其顯著，完全符合我們視障團體追求流暢穩定系統的核心需求。 十一、整體訴求總結 以上所述種種，絕非錦上添花的優化，而是真正能改變視障群體使用體驗的核心調整。前人種樹，後人乘涼，每一個細微的改動，都能讓許多視障人士更獨立、更方便地使用手機。期盼團隊能真正站在視障使用者的角度，從真實的操作困難出發，重視這些來自用戶的聲音。 申請人：來自中國香港的視障用戶

共享資料夾連結相關檔案參考。 https://www.icloud.com/iclouddrive/0679UprC8IUlrCvNL9vZfn3zQ 已開啟「智慧型反轉顏色」，期望主螢幕能全域呈現黑底白字，是為「智慧型富片」；然而，開啟該功能後，主螢幕並未套用一致的黑色主題，導致無法啟用全域的「智慧型富片」，僅能手動，個別App設定，逐一為個別應用程式設定開啟智慧型負片，造成使用上的不便。 希望進一步優化「智慧型富片」功能，使其真正取代一般系統的黑色主題。因為在一般黑色主題下，許多第三方應用程式或部分系統介面仍無法呈現黑底白字，而「智慧型富片」正好能彌補此一缺陷。 然而，現時仍不夠徹底：無論開啟白色主題或黑色主題，並同時開啟「智慧型富片」，皆無法達成全域黑底白字。不是此處白色，就是彼處白色，始終無法真正做到全域黑色背景。 因此，誠摯希望加強「智慧型富片」功能，使其更人性化，甚至達成以下目標： · 一鍵開啟後，自動全域呈現黑底白字，無須手動設定任何背景顏色； · 不使用灰底，直接採用純黑色背景，並搭配高對比度的文字與按鈕； · 主螢幕與鎖定螢幕底色自動變為黑色； · 下拉工具欄、下拉通知欄等目前常為白底之處，也一併變黑； · 開啟此模式後，自動將背景、通知欄、工具欄與解鎖畫面強制設為黑色背景； · 無須進入設定，亦無須手動逐項調整，真正做到全域暗黑模式； · 開關按鈕的對比色亦請改善，目前難以直觀分辨開啟或關閉。 這不只是外觀問題，更是無障礙中極其重要的一環；對怕光者、眼疾患者與需要無障礙輔助的人而言，更是不可或缺。萬分感謝你們願意關注並優化，這些細節對我們而言，就是最直接、最關鍵的輔助。

共享資料夾檔案視頻參考標題： https://www.icloud.com/iclouddrive/013lIxYMffIk6kqO2qLED6yUw 捷徑開啟旁白後項目無焦點框，無法選取、修改及返回 內容： 環境： 裝置型號：____ 系統版本：iOS 27 正式版 / iOS 27.2 公測版（問題自 iOS 27 公測版開始持續存在） 旁白：開啟 App：捷徑 問題描述： 自 iOS 27 公測版開始，到現在的 iOS 27 正式版，還有最新的 iOS 27.2 公測版，均未解決此問題。在「捷徑」中開啟旁白後，選取相關項目時不會顯示焦點框，導致無法選取項目或修改內容。返回上一頁的操作也無法觸發；目前必須先關閉旁白，手動點擊左上角的返回按鈕，再重新開啟旁白進入頁面，才能修改內容。 重現步驟： 開啟旁白並進入「捷徑」。 嘗試選取相關項目。 項目沒有顯示焦點框，無法選取或修改。 嘗試返回上一頁，操作無法觸發。 關閉旁白，手動點擊左上角返回按鈕，再開啟旁白進入頁面，才能修改內容。 影響： 旁白使用者無法正常操作「捷徑」，必須反覆開關旁白，嚴重影響無障礙操作體驗。 期望： 修復焦點框缺失及返回操作無法觸發的問題，使旁白可正常選取、修改項目並返回上一頁。

Hello, We develop an accessibility app that provides real-time captions for phone calls. Our app allows users to enable or disable call forwarding using carrier codes (e.g., **21#), allowing them to receive captioned inbound calls. With the iOS 27 rollout, the new "Trust Insights" feature began blocking these codes with a "Malicious Link Blocked" warning. In iOS 27.2 Beta, the warning changed to "Call Forwarding Link Blocked," directing users to manage call forwarding through Apple's native settings. However, we've observed inconsistent behavior across carriers: Tello eSIM: Call forwarding codes are blocked even when manually entered into the native iPhone dialer. T-Mobile: Manually entering the same type of code into the native dialer still works, although dialing through our app is blocked. This inconsistency makes it difficult to provide our users with reliable setup instructions. More importantly, blocking these codes introduces significant friction for users with disabilities who rely on our app for accessible phone calls. Is there a process for accessibility apps to request an exemption from these restrictions, or an alternative to preserve call forwarding in our app?

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!