WWDC Quick Look 💓 By SwiftGGTeam
Developer spotlight: Accessibility

Developer spotlight: Accessibility

元の動画を見る

ハイライト

Apple は、視覚障害者と聴覚障害者の開発者の実例を通して、アクセシビリティの向上はボタンのラベル、VoiceOver テスト、多感覚フィードバックから始まり、同じアプリをより多くのユーザーや開発者が使用できるようにすることを示しています。

主要内容

多くのチームは、リリース前のチェックとしてアクセシビリティを重視しています。インターフェイスを終了したら、VoiceOver を開いてもう一度試してください。ボタンが読めない、画像に説明がない、インタラクションが音声に依存していることがわかった場合は、それらを後で修正するタスクとしてリストアップします。

このスピーチで挙げられた問題点はより具体的です。ある開発者は、グラフィカル ボタンにラベルがなく、VoiceOver ユーザーがボタンの意味を理解できないアプリがあると述べました。開発者がタグを追加した後、アプリが基本的にアクセスできるようになるまでにわずか 1 日かかりました。

Apple はこの話を API リリースにはしませんでした。これにより、視覚障害者や聴覚障害のある開発者が自分たちの仕組みについて話すことができます。聴覚障害のある開発者は、当然のことながら、音なしでアプリを実行できるかどうかを確認します。視覚障害のある開発者は、毎日スクリーン リーダーを使用してコードを作成し、アプリをテストし、バグを送信します。

これにより、アクセシビリティの出発点が変わります。開発者は、最初に別のバージョンを設計する必要はありません。まず同じことのバージョンを実行して、ボタンに名前が付き、VoiceOver で状態を読み取ることができ、音声プロンプトに視覚的な代替手段があり、視覚的なタスクに音声ガイダンスが表示されるようにします。

ボタンのラベルから始めます

完全にアクセスできないアプリの場合、グラフィカル ボタンにラベルがないため、問題は軽微である可能性があります。スクリーン リーダーは「ボタン」としか発音できず、ユーザーは次に何が起こるかわかりません。

ラベルを追加すると、ユーザーはインターフェイスを理解できるようになります。この変更にはスキーマの書き換えは必要ありません。開発者はコントロールのセマンティクスをシステムに引き渡す必要があります。

ツール自体にもアクセスできる必要があります

聴覚障害のある開発者が VoiceOver のバグを受け取ったとき、次のような疑問が生じます。VoiceOver の読み上げが聞こえない場合、どうやってテストすればよいでしょうか?

答えは、VoiceOver のキャプション バーです。 「ツイートと返信、ボタン」など、VoiceOver が話した内容がテキストとして表示されます。この小さな機能により、聴覚障害のある開発者は VoiceOver の問題をデバッグできます。

個人的な問題点に基づいて製品を作成する

AI を見ることは、視覚障害のある開発者の個人的なニーズから来ています。周囲の世界を説明し、テキストを読み取り、人や物体を認識します。バーコードがスキャンされると、チームは「ホットまたはコールド」方式で音声ガイドを提供します。つまり、ターゲットに近づくほどビープ音が速くなります。

Cardzilla は、聴覚障害のある開発者の配車サービスの経験から生まれました。彼は当初、ドライバーとのコミュニケーションにメモ アプリを使用していましたが、テキストが小さすぎました。そこで、文字を拡大して相手が読みやすくなり、コミュニケーションが早くなるアプリを作りました。

詳細

1. グラフィック ボタンに読みやすいラベルを付ける

(02:05) 講演の最初の具体例はボタンのラベルです。グラフィック ボタンにはラベルがないため、VoiceOver ユーザーはアプリを使用できません。開発者がタグを追加すると、アプリは基本的にアクセス可能になります。

SwiftUIではグラフィックボタンが使用可能accessibilityLabelセマンティックな名前を提供します。以下は完全な最小限の例です。

import SwiftUI

struct PlaybackControls: View {
    @State private var isPlaying = false

    var body: some View {
        Button {
            isPlaying.toggle()
        } label: {
            Image(systemName: isPlaying ? "pause.fill" : "play.fill")
        }
        .accessibilityLabel(isPlaying ? "Pause" : "Play")
    }
}

struct PlaybackControls_Previews: PreviewProvider {
    static var previews: some View {
        PlaybackControls()
    }
}

重要なポイント:

  • import SwiftUISwiftUI の導入により、サンプルを SwiftUI アプリに直接配置したり、プレビューで実行したりできます。
  • @State private var isPlaying = false再生ステータスを保存すると、ボタンをクリックするとインターフェースが更新されます。
  • Button { ... } label: { ... }アイコンのみのボタンを作成します。
  • Image(systemName:)ステータスに応じて再生または一時停止アイコンを表示します。
  • .accessibilityLabel(isPlaying ? "Pause" : "Play")グラフィック ボタンに、VoiceOver が読み取れる名前を付けます。
  • PlaybackControls_Previewsアクセシビリティ プレビューの検査を容易にする Xcode プレビューの入り口を提供します。

2. すべてのユーザーにサービスを提供するには同じバージョンを使用します

(01:43) 熱心な開発者らは、目標は「Pro Toolsのブラインドバージョン」を作ることではないと言っている。目標は、誰もがステップアップして使用できるバージョンです。

この原則は、通常、元のコントロールにステータス、アクション、ラベルを配置することによってコードに実装され、システム補助機能が同じインターフェイスのセットを読み取ることができます。次の例では、追加のアクセシビリティ インターフェイスを複製せずに、ミュート ボタンを同じコントロールに作成します。

import SwiftUI

struct MuteButton: View {
    @State private var isMuted = false

    var body: some View {
        Button {
            isMuted.toggle()
        } label: {
            Label(isMuted ? "Unmute" : "Mute",
                  systemImage: isMuted ? "speaker.slash.fill" : "speaker.wave.2.fill")
        }
        .accessibilityValue(isMuted ? "Muted" : "Sound on")
    }
}

struct MuteButton_Previews: PreviewProvider {
    static var previews: some View {
        MuteButton()
    }
}

重要なポイント:

  • @State private var isMuted = false現在のサウンド状態を保存します。
  • Buttonすべてのユーザーが共有するインタラクティブなポータルです。
  • Labelテキスト アイコンとシステム アイコンの両方が含まれており、ビジュアル ユーザーと VoiceOver ユーザーの両方が名前を使用できます。
  • systemImageステータスの変化に応じて、ビジュアルインターフェイスでミュートステータスを表現できます。
  • .accessibilityValue現在の値を読み上げて、ボタンが現在「ミュート」または「サウンドオン」に対応しているかどうかをユーザーに知らせます。

3. 音声を持たないユーザーが VoiceOver をチェックできるようにする

(03:03) 聴覚障害のある開発者が VoiceOver のバグを受け取りました。彼は、VoiceOver には、話された内容をテキストとして表示できる字幕バーがあることを発見しました。演説の字幕には「ツイートと返信、ボタン」「メディア、ボタン」「いいね、ボタン」と書かれていた。

アプリケーションを開発するときは、読み取り可能なラベルと表示されるテキストを同時に準備できます。このようにして、聴覚障害のあるテスターは字幕バーを通じて VoiceOver 出力を確認でき、視覚障害のあるユーザーはスクリーン リーダーを通じて同じセマンティクスを聞くことができます。

import SwiftUI

struct ProfileTabs: View {
    var body: some View {
        HStack {
            Button("Tweets and replies") {}
            Button("Media") {}
            Button("Likes") {}
        }
        .padding()
    }
}

struct ProfileTabs_Previews: PreviewProvider {
    static var previews: some View {
        ProfileTabs()
    }
}

重要なポイント:

  • HStack音声字幕バー内の 3 つのフォーカス可能な要素に対応して、3 つのボタンが水平に配置されています。
  • Button("Tweets and replies") {}テキスト タイトルを使用すると、VoiceOver で直接読み上げることができます。
  • Button("Media") {}そしてButton("Likes") {}タグが失われる可能性を減らすために、同じパターンを維持してください。
  • .padding()視覚的なレイアウトにのみ影響し、アクセシビリティのセマンティクスは変更されません。
  • 実行中にVoiceOver字幕バーが開くので、テスターは読み上げ結果をテキストで確認できます。

4. カメラタスクの音声ガイドを提供する

(03:59) Seeing AI チームは、ユーザーがバーコードをスキャンするときにカメラがターゲットに向けられているかどうかを知る必要があることを発見しました。チームは「ホットまたはコールド」ゲーム ルールを使用しています。つまり、バーコードに近づくほどビープ音が速くなります。

このアイデアは、ユーザーがターゲットを狙う必要があるすべてのタスクに適しています。このコードは、まず「近接度」を 0 から 1 までの値に抽象化し、次にそれをビープ音の間隔に変換します。

import Foundation

struct BarcodeAudioGuide {
    func beepInterval(for proximity: Double) -> TimeInterval {
        let clampedProximity = min(max(proximity, 0), 1)
        let slowestInterval = 1.0
        let fastestInterval = 0.15
        return slowestInterval - (slowestInterval - fastestInterval) * clampedProximity
    }
}

let guide = BarcodeAudioGuide()
let interval = guide.beepInterval(for: 0.75)
print(interval)

重要なポイント:

  • import Foundation導入TimeInterval
  • BarcodeAudioGuideバーコード音声ガイダンスの計算ロジックを保存します。
  • beepInterval(for:)近接受信、0遠くという意味、1近いという意味です。
  • min(max(proximity, 0), 1)計算に影響を与える異常値を避けるために、入力を 0 ~ 1 に制限します。
  • slowestInterval最も遅いビープ音の間隔です。
  • fastestIntervalは最速のビープ音間隔です。
  • return近接に応じて間隔が短くなります。ターゲットに近づくほど、戻り値は小さくなります。
  • print(interval)サンプルを直接実行して結果を観察してください。

5. 文字を拡大して対面コミュニケーションを解決する

(04:27) Cardzilla の出発点は非常に日常的なものです。聴覚障害のある開発者がタクシーに乗るとき、メモ アプリを使用して運転手にテキストを読み上げますが、テキストが小さすぎます。そこで彼は、テキストを増幅してコミュニケーション効率を向上させるアプリを作成しました。

この機能は複雑ではありません。入力内容をすぐに大きく中央に配置することで、相手が読みやすくすることがポイントです。

import SwiftUI

struct LargeMessageCard: View {
    @State private var message = "Please take me home."

    var body: some View {
        VStack(spacing: 24) {
            TextEditor(text: $message)
                .frame(height: 120)
                .border(Color.secondary)

            Text(message)
                .font(.system(size: 56, weight: .bold))
                .multilineTextAlignment(.center)
                .minimumScaleFactor(0.4)
                .padding()
        }
        .padding()
    }
}

struct LargeMessageCard_Previews: PreviewProvider {
    static var previews: some View {
        LargeMessageCard()
    }
}

重要なポイント:

  • @State private var message相手に見せたい文章を保存します。
  • TextEditor(text: $message)ユーザーがコンテンツを編集できるようにします。
  • .frame(height: 120)表示領域のためのスペースを確保するために、入力領域の高さを制限します。
  • Text(message)コンテンツを拡大して表示します。
  • .font(.system(size: 56, weight: .bold))遠くからでも読みやすくするために、大きなフォント サイズと太字のフォントを使用します。
  • .multilineTextAlignment(.center)複数行のテキストを中央揃えにします。
  • .minimumScaleFactor(0.4)テキストが長すぎて切り詰められない場合は、テキストを自動的に縮小します。

重要ポイント

  1. 対処方法: すべてのアイコン ボタンに読みやすい名前を追加します。 実行する価値がある理由: スピーチの事例では、ボタンのラベルがないとアプリに完全にアクセスできなくなることが示されました。ラベルを追加した後、アプリは基本的に 1 日以内に使用できるようになります。 開始方法: よく使うページを開いてアイコンを一つずつ確認してくださいButton、SwiftUIに追加.accessibilityLabel、UIKitで設定accessibilityLabel

  2. やるべきこと: 音声プロンプトの視覚的検査パスを追加します。 実行する価値がある理由: 聴覚障害のある開発者は、VoiceOver のバグをデバッグするために VoiceOver 字幕バーに依存しています。これは、テスト ツールとデバッグ情報が五感を介して提示される必要があることを示しています。 開始方法: VoiceOver 字幕バーを開き、フォーカス可能な各要素によって読み取られるテキストを確認します。音声依存のステータス プロンプトにテキスト、アイコン、または振動フィードバックを追加します。

  3. やるべきこと: カメラ スキャンに「より近くてより密な」フィードバックを追加します。 実行する価値がある理由: Seeing AI のバーコード スキャンでは、ユーザーがターゲットを狙うのに役立つビープ音の周波数が使用され、ビューファインダー画面が見えない場合の操作上の問題が解決されます。 開始方法: まず、画面内のターゲットの信頼度または距離を計算し、それをビープ音の間隔、振動のリズム、または画面のプロンプトにマッピングします。

  4. やるべきこと: 大きな文字を使用した対面コミュニケーション モデルを作成します。 実行する価値がある理由: Cardzilla のシナリオはタクシーのコミュニケーションから生まれており、重要な要件は相手にテキストをすぐに理解させることです。 開始方法: を使用しますTextEditor大きなフォントサイズでコンテンツを入力するTextフルスクリーンで表示し、音声入力入り口を追加します。

  5. やるべきこと: 障害のあるユーザーをベータ テスト プロセスに参加させます。 実行する価値がある理由: 講演では、アクセシビリティには社内および社外のベータ テスターからの意見が必要であると述べられました。チームの多様性は、より直接的な問題発見につながります。 開始方法: TestFlight 募集手順で、VoiceOver、字幕、キーボード アクセス、スイッチ コントロール ユーザー フィードバックを明示的に歓迎し、フィードバックを特定のページとコントロールに分類します。

関連セッション

コメント

GitHub Issues · utterances