無障礙作為平台：個人語音、即時語音、眼動追蹤、音樂觸覺

個人語音（iOS 17）、即時語音（iOS 17）、眼動追蹤（iOS 18）、音樂觸覺（iOS 18）、語音捷徑（iOS 18）。Apple近期無障礙功能發布的軌跡相當一致：過去需要第三方應用程式、專屬硬體或特殊整合才能實現的功能，正逐漸成為作業系統處理的平台能力。結果是使用者要安裝的應用程式變少了，而開發者的參與模式也不一樣了：開發者不再自行打造該功能，而是選擇加入系統介面（個人語音授權），或是遵循每個應用程式本就應該達到的標準（眼動追蹤所需的正確無障礙標籤與點擊區域）。

這篇文章逐一介紹每項功能的開發者介面。框架是「我的應用程式必須做什麼才能參與」，而非「我該如何實作這項功能」。Apple已經打造了該功能；問題在於應用程式是否已準備好使用它。

TL;DR

• 個人語音（iOS 17+）讓使用者錄製15分鐘的音訊，在裝置上合成出一個專屬語音，供AAC與輔助溝通應用程式使用。應用程式透過AVSpeechSynthesizer.requestPersonalVoiceAuthorization()整合,並檢查voiceTraits是否包含.isPersonalVoice¹。
• 即時語音（iOS 17+）是系統層級的功能：使用者輸入文字,裝置便將其朗讀出來（可選擇使用其個人語音）。應用程式無需直接整合即時語音；該功能在作業系統層級運作,涵蓋通話、FaceTime與面對面溝通。
• 眼動追蹤（iOS 18+）透過前置鏡頭以凝視加上停留控制操控裝置。應用程式只要遵循無障礙標準（正確的無障礙標籤、點擊區域大小、聚焦順序）即可參與；大多數應用程式不需要專屬的API²。
• 音樂觸覺（iOS 18+）將音樂播放轉譯為與音訊同步的Taptic Engine震動,透過MediaAccessibility.framework中的MAMusicHapticsManager API實現。任何音樂應用程式只要在Info.plist中設定MusicHapticsSupported、成為當前的Now Playing應用程式,並提供ISRC,即可整合³。
• 語音捷徑（iOS 18+）讓使用者指定自訂片語來觸發Siri捷徑,包含第三方的AppIntent動作。此功能與App Intents的採用相輔相成（詳見App Intents Are Apple’s New API to Your App）。

個人語音：授權模式

個人語音是無障礙功能中最直接面對開發者的¹。使用者透過「設定」>「輔助使用」>「個人語音」選擇加入,錄製大約15分鐘的隨機提示朗讀,裝置便利用裝置端機器學習在本地合成出一個語音。該語音為使用者私人所有；除非使用者明確選擇與iCloud配對裝置共享,否則不會離開裝置。

應用程式若要在AVSpeechSynthesizer中使用使用者的個人語音,必須:

1. 透過AVSpeechSynthesizer.requestPersonalVoiceAuthorization(completionHandler:)請求授權。
2. 等待使用者透過系統提示授予權限。
3. 獲得核准後,查詢AVSpeechSynthesisVoice.speechVoices()並篩選出voiceTraits中包含.isPersonalVoice的語音。
4. 將取得的AVSpeechSynthesisVoice如同其他語音般使用於AVSpeechUtterance中。

import AVFoundation

AVSpeechSynthesizer.requestPersonalVoiceAuthorization { status in
    guard status == .authorized else { return }

    let personalVoices = AVSpeechSynthesisVoice.speechVoices().filter { voice in
        voice.voiceTraits.contains(.isPersonalVoice)
    }

    if let voice = personalVoices.first {
        let utterance = AVSpeechUtterance(string: "Hello.")
        utterance.voice = voice
        synthesizer.speak(utterance)
    }
}

授權十分敏感。Apple的指引是,個人語音應主要用於擴大及替代溝通（AAC）應用程式及類似的輔助情境。一般用途的語音朗讀應用程式若請求個人語音授權,很可能會被使用者拒絕,並可能在App Store審查中受到質疑。

裝置端優先的架構在此格外重要。使用者的語音訓練資料以及產生的語音模型,除非使用者明確選擇加入iCloud共享,否則永遠不會離開裝置的安全隔離區。使用個人語音的應用程式,在App Store隱私營養標籤中應反映零資料收集,因為合成發生在本地,而音訊輸出則直接送往揚聲器,而非網路。

即時語音：零整合的系統功能

即時語音是個人語音面向消費者的搭配功能⁴。使用者輸入文字,裝置將其朗讀出來,可選擇使用其個人語音。即時語音可在電話通話、FaceTime通話、Mac SharePlay,以及透過裝置揚聲器進行的面對面對話中使用。

應用程式不直接整合即時語音。該功能在作業系統層級運作,從系統的即時語音介面攔截輸入的文字,並將其透過音訊堆疊路由出去。從應用程式的角度來看,即時語音是隱形的:在通話中傳出的音訊串流(或在面對面使用時從裝置揚聲器播放的聲音)聽起來像使用者本人,但完全不涉及應用程式程式碼。

這對應用程式開發者的意涵在於:若您的應用程式處理語音(通話應用程式、視訊聊天應用程式、無障礙輔助工具),應用程式的音訊管線必須尊重系統的音訊路由,以便即時語音能透過同一個通道輸出。那些對抗音訊工作階段(在不考慮系統層級疊加聲音的情況下宣稱獨佔控制權)的應用程式,會破壞即時語音。

眼動追蹤:遵循標準的功能

眼動追蹤於iOS 18推出,讓使用者透過凝視方向加上停留控制來操作iPhone與iPad²。使用者只需數秒便可校準前置鏡頭,接著只要看向UI元素即可瀏覽介面;在元素上維持凝視達設定的停留逾時時間,就能啟動該元素(輕點、滑動或其他手勢,可在「切換控制」中設定)。

實作完全在裝置端進行。前置鏡頭透過裝置端機器學習處理凝視資料;資料不會離開裝置。無需額外硬體。

對大多數應用程式而言,支援眼動追蹤不需要專屬程式碼。任何遵循標準無障礙慣例的UI都能與此功能相容:

• 適當的點擊區域。 Apple人機介面指引規定可點擊元素的最小點擊區域為44pt乘以44pt。眼動追蹤遵循此規範。小於最小尺寸的按鈕較難精準停留瞄準。
• 無障礙標籤。 每個互動元素都應有實用的accessibilityLabel(SwiftUI)或accessibilityLabel屬性(UIKit)。當使用者在元素附近停留時,眼動追蹤會將該標籤顯示為類似工具提示的內容。
• 合理的聚焦順序。 Mac上的Tab鍵與tvOS上的聚焦引擎所使用的聚焦順序,與眼動追蹤跳躍切換元素時所用的順序相同。使用SwiftUI標準排版基本元素的應用程式可免費獲得這項支援;覆寫聚焦行為的應用程式則需驗證。
• 對停留友善的模態模式。 若一個模態視窗在外部點擊時會自動關閉,可能會讓眼動追蹤使用者感到挫折,因為其凝視點可能短暫離開模態區域。具有模態UI的應用程式應提供明確的關閉按鈕。

對於想要在特定畫面(敏感內容、複雜的手勢類遊戲)中退出眼動追蹤的應用程式,目前並無專為眼動追蹤記載的退出API。該功能會在任何可見內容上運作,而應用程式的責任是確保標準無障礙介面正確無誤。

Three Surfaces of an iOS App這篇文章涵蓋了更廣泛的模式:可見的UI是其中一個介面,App Intents是另一個,無障礙是第三個。眼動追蹤參與的是可見UI介面;將該介面做好,正是讓眼動追蹤、切換控制、VoiceOver與語音控制能同時運作的關鍵。

音樂觸覺:音訊到觸覺的橋樑

音樂觸覺將音樂播放轉譯為與音訊同步的Taptic Engine震動³。該功能由使用者選擇加入(設定>輔助使用>音樂觸覺),並適用於任何正確整合API的音樂應用程式,而不僅是Apple Music。

開發者介面位於MediaAccessibility.framework的MAMusicHapticsManager(iOS 18+)。音樂應用程式透過三個步驟整合音樂觸覺:

1. 在Info.plist中宣告支援。 加入MusicHapticsSupported鍵,值設為YES。系統據此判斷該應用程式是否參與音樂觸覺渲染。
2. 成為當前的Now Playing應用程式。 應用程式必須透過MPNowPlayingInfoCenter.default().nowPlayingInfo發布播放中繼資料,並擁有當前播放的音訊工作階段。系統需要一個已知的當前Now Playing來源來驅動觸覺合成。
3. 提供當前播放曲目的ISRC。 MPNowPlayingInfoPropertyInternationalStandardRecordingCode鍵(國際標準錄音代碼)讓系統能查詢與該音訊配對的觸覺軌道。Apple維護一個以ISRC為索引的觸覺資產庫;沒有ISRC的曲目雖然不會獲得觸覺,但其餘的now-playing整合仍可正常運作。

import MediaPlayer
import MediaAccessibility

// Info.plist: MusicHapticsSupported = YES (boolean)

let info: [String: Any] = [
    MPMediaItemPropertyTitle: track.title,
    MPMediaItemPropertyArtist: track.artist,
    MPNowPlayingInfoPropertyInternationalStandardRecordingCode: track.isrc,
    // ... other now-playing properties
]
MPNowPlayingInfoCenter.default().nowPlayingInfo = info

此整合適用於任何音樂應用程式:基於AVAudioEngine打造的串流客戶端、有自訂解碼器的DJ應用程式、具備樣本播放的音樂學習應用程式。限制條件是ISRC與當前Now Playing角色,而非底層的音訊API。沒有ISRC的應用程式(無中繼資料的使用者上傳音樂、生成式音樂)單純就不會有觸覺;其餘播放整合不受影響。

對於相鄰領域的應用程式(節奏遊戲、音樂視覺化、音效引擎),這類音訊並非音樂觸覺的設計目標。這些應用程式應直接使用CHHapticEngine,搭配與其音訊來源同步的手工編寫觸覺模式。

語音捷徑:無障礙與App Intents的交會

語音捷徑讓使用者指定自訂語音片語給Siri捷徑,包括由第三方AppIntent類型支援的捷徑⁵。使用者可以將「Marker」設定為觸發某待辦事項應用程式註冊的AddTodoIntent;不論使用者身在何處,只要說出「Marker」便能觸發該意圖,無需先呼叫Siri的喚醒詞。

整合使用本系列已大量介紹過的App Intents框架,但有一個容易被忽略的結構性環節:應用程式必須宣告一個AppShortcutsProvider,以暴露具有明確phrases的AppShortcut項目。系統中存在的純粹AppIntent只能透過捷徑編輯器調用,使用者必須在其中手動組裝一個捷徑。AppShortcutsProvider則註冊系統可見的捷徑,使用者可立即將其指定給語音捷徑、動作按鈕、Siri或Spotlight。

struct TodoShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: AddTodoIntent(),
            phrases: [
                "Add a todo in \(.applicationName)",
                "\(.applicationName) marker"
            ],
            shortTitle: "Add Todo",
            systemImageName: "checkmark.circle"
        )
    }
}

phrases陣列就是系統呈現給Siri與語音捷徑的內容。一旦提供者就位,App Intent便立即具備語音啟動的資格。若沒有它,該意圖仍可透過手動捷徑設定運作,但路徑較長,許多使用者永遠不會走完。

此模式與App Intents以及App Intents vs MCP Tools相輔相成。一個值得在使用者的Apple Intelligence介面中佔有一席之地的App Intent,搭配宣告使用者如何調用它的AppShortcutsProvider,也同樣值得作為語音捷徑目標。本系列關於App Intents是「應用程式能做什麼」之跨系統契約的論點亦適用於此:語音捷徑是同一份契約的另一位消費者。

跨領域模式:標準即整合

上述無障礙功能擁有共同的結構性特質:每一項都建立在應用程式本就應達到的標準之上,僅在應用程式必須明確配合的情況下提供小型的選擇加入API介面(個人語音授權、透過MPMusicPlayerController整合音樂觸覺)。

這對開發團隊的意涵在於:無障礙工作並非應用程式上架後才進行的獨立工作流。應用程式的無障礙標籤、點擊區域、聚焦順序與標準系統API的使用,正是讓眼動追蹤運作、即時語音正確路由、音樂觸覺啟動,以及語音捷徑呈現正確意圖的根本。將無障礙視為週期末端的勾選項目的應用程式,推出的功能可能在VoiceOver上能用,卻對眼動追蹤失效;或是以即時語音無法跟隨的方式路由音訊。

本系列的What I Refuse to Write About文章主張拒絕作為一種定位策略。無障礙領域的拒絕則是相反的:不是「我拒絕加入這個」,而是「我拒絕推出未能達成每個iOS應用程式都應該做到之標準的東西」。

應用程式何時需要自訂無障礙程式碼

有三種情況,標準遵循模式無法涵蓋全部:

自訂繪圖介面。 繪圖應用程式、圖表、自訂渲染的遊戲UI都繞過了SwiftUI/UIKit的無障礙樹。應用程式必須使用UIAccessibilityCustomAction、UIAccessibilityElement,並為每個有意義的元素設定明確的無障礙屬性,自行建立其無障礙樹。眼動追蹤、VoiceOver與切換控制都仰賴無障礙樹被填入內容。

即時手勢互動。 具有連續手勢輸入(繪圖、拖曳瞄準)的遊戲無法自然對應到基於停留或切換的輸入。正確做法是提供替代的控制方案(以按鈕為基礎的輸入作為選項),而非對抗無障礙系統。

無障礙專屬功能。 AAC應用程式、語音擴增應用程式、手語翻譯應用程式。這些應用程式本身就是無障礙產品,並深度整合系統框架(個人語音、Speech框架、用於手語偵測的Vision框架)。這類整合工作既是真實的,也是刻意為之的。

此模式對iOS 26+應用程式的意義

三點啟示。

1. 無障礙的參與大多是遵循標準,而非建構功能。 Apple一直在將無障礙推進到平台層。工作重點是確保您的應用程式達到眼動追蹤、切換控制、VoiceOver與語音控制全都仰賴的標準:適當的標籤、點擊區域、聚焦順序、系統音訊路由。

2. 個人語音整合需謹慎。 如果您的應用程式有真正的AAC使用情境(輔助溝通、語音擴增、無障礙工具),個人語音授權是正確的整合選擇。對一般用途的應用程式而言,請求個人語音授權更可能讓使用者感到困惑,而非帶來幫助。

3. App Intents就是無障礙基礎建設。 一個乾淨的AppIntent會自動具備語音捷徑的資格、透過捷徑取得可訪問的UI介面,並與系統的語音驅動和切換驅動控制模式整合。本系列關於採用App Intents的論點同樣適用於無障礙領域。

完整的Apple Ecosystem系列:類型化App Intents;MCP伺服器;路由問題;Foundation Models;執行階段對工具LLM的區分;三個介面;單一真相來源模式;Two MCP Servers;Apple開發的hooks;Live Activities;watchOS執行階段;SwiftUI內部結構;RealityKit的空間心智模型;SwiftData架構紀律;Liquid Glass模式;多平台發布;平台矩陣;Vision框架;Symbol Effects;Core ML推論;Writing Tools API;Swift Testing;Privacy Manifest;我拒絕撰寫的主題。系列中樞位於Apple Ecosystem Series。若需更廣泛的iOS搭配AI代理人脈絡,請參閱iOS Agent Development guide。

FAQ

我需要撰寫任何程式碼來支援眼動追蹤嗎?

對大多數應用程式而言,不需要。眼動追蹤可自動配合任何遵循標準無障礙慣例的UI:適當的點擊區域(最小44pt)、實用的無障礙標籤、合理的聚焦順序,以及標準系統控制項。自行繪製UI的應用程式(自訂視圖、遊戲、圖表)需要使用UIAccessibilityElement或SwiftUI的無障礙修飾符明確填入無障礙樹;這項工作同時也讓應用程式能與VoiceOver及切換控制相容。

我可以在一般用途的語音朗讀應用程式中使用個人語音嗎?

系統透過AVSpeechSynthesizer.requestPersonalVoiceAuthorization()允許這麼做,但Apple的指引以及App Store審查流程強調個人語音應用於輔助情境(AAC,擴大及替代溝通)。請求個人語音授權的一般用途語音朗讀應用程式面臨兩項挑戰:使用者不太可能授予授權,且審查可能會以不當使用為由拒絕該請求。如果您的使用情境真的具輔助性質,該整合是合適的;如果是一般用途的旁白,系統語音才是正確的工具。

即時語音與個人語音有什麼區別?

個人語音是聽起來像使用者本人的裝置端合成語音。即時語音則是讓使用者輸入文字後由裝置朗讀(可使用系統語音或其個人語音)的系統功能。兩者互補:個人語音提供聲音,即時語音提供輸入轉語音的UI。應用程式透過Speech Synthesizer API整合個人語音;即時語音對應用程式而言是隱形的,在作業系統層級運作。

我該如何為使用AVAudioEngine的音樂應用程式加入音樂觸覺?

可以做到。音樂觸覺並未限定於特定的播放API。整合方式為:在Info.plist中加入MusicHapticsSupported = YES,透過MPNowPlayingInfoCenter.default().nowPlayingInfo發布播放中曲目的中繼資料(讓系統識別您的應用程式為當前的Now Playing來源),並包含MPNowPlayingInfoPropertyInternationalStandardRecordingCode與該曲目的ISRC。系統會從這裡開始處理觸覺合成。沒有ISRC的曲目不會獲得觸覺,但其餘的now-playing整合會正常運作。

哪種App Intent設計能帶來最佳的語音捷徑體驗?

四項原則。第一,為應用程式宣告一個AppShortcutsProvider,並為您希望可透過語音存取的意圖註冊AppShortcut項目。沒有提供者的話,該意圖只能透過手動編輯捷徑來抵達語音捷徑。第二,title與shortTitle應為簡短的動詞片語(「Add Todo」、「Start Timer」),而非描述。第三,參數應設為可選或具有預設值,讓使用者能在不指定每個欄位的情況下調用該意圖。第四,description應為單一清晰句子,說明該意圖的效果;當使用者選擇要指定的片語時,這會作為脈絡呈現出來。

References