卓越したアクセシビリティ体験の提供

(音楽)

(拍手) おはようございます 私はスカイラー iOSアクセシビリティチームの 一員です Mac アクセシビリティチームの バビヤもいます 極上のアクセシビリティ体験を 実現する― アプリケーションの 開発について話します

一般的にアクセシビリティとは 技術を誰でも 使えるようにすることです Appleではアクセシビリティを ４つの領域に分けて考えます 学習と読み書き 身体機能 視覚 聴覚です アクセシビリティへの配慮は OSにも多数あります でも アプリケーションが 支援技術に対応してこそ― 障がい者の方々に選ばれる プラットフォームになります 皆さんの秀逸なコンテンツを アクセシブルにして 誰もがつながれる社会を 作りましょう そして世界の人々の生活を 向上させるのです

今日の私たちの話では 基本的な内容は飛ばします アクセシビリティの話が 初めての人や APIを見たことがない人は いますか？ その場合 2017年のWWDCも ご確認ください 私たちの話は 初心者にも有益ですが 話の流れが 早く感じるでしょう 応用の話が主だからです まず この言葉に 着目してください “使用可能” 大事なことです 支援技術が全コンテンツを 認識していることは 重要な第一歩です そうは言っても ただ使えるだけでは不十分です 理想は使用可能な アプリケーションではなく 極上のアプリケーションです 私たちはユーザを 喜ばせたいのです それを具体的に どう実現するのかを これから説明します 皆さんの開発のヒントになれば 幸いです

アクセシビリティの評価や検討は 主に２つの見地から 行ってください １つ目はビジュアルデザインで ２つ目は アクセシビリティユーザの体験です まずビジュアルデザインです

第１に 透過とぼかしについて 考えてみます iOSでは透過とぼかしを よく使います 鮮やかで独特な感覚を 生むからです しかし 低視力の人などには 文字が読みにくくなるため 目を酷使する原因にも なります そこで この効果を 低減させる設定を実現 画面を このように 大きく変えられます 背景が暗くなるのです 最低限の情報を出しつつ 視覚的なノイズを排除 にじんで見えていた背景は 無地になりました フォルダも同様です

Spotlightも この例では ユーザの壁紙から 色を取ったのが分かります よって 無地であっても パーソナライズできていて コントラストと読みやすさが 向上しました

皆さんも 各自のアプリケーションのUIで 透明度を下げる設定を生かせるか 試してください iOSでは UIAccessibilityで isReduceTransparencyEnabledとし macOSでは NSWorkspaceで accessibilityDisplayShould ReduceTransparencyとします

第２にコントラストです

コンテンツと背景のコントラストは 見やすさに影響します 色が似ていると 識別しづらくなります 小さくなると 読みにくくなる色もあります 字が小さいと にじんで見えるのです

色の組み合わせの コントラスト比を計算し 読めるか確認してください Web Content Accessibility Guidelinesに従って 皆さんも 最低限の 4.5：１以上を目指すべきです

最もコントラストが高いのは 白と黒で 比は21：１です どの文字サイズにも 適しています グレーの文字は― 大きければ読めますが 小さいと見えにくいです 文字の形が分かりません これがコントラスト比4.5：１で 最低限です さらに別のグレーです この大画面では 読めるかもしれませんが 小さなデバイスでは フォントが大きくても判読不能です コントラスト比2.9：１は 低すぎます

XcodeのAccessibility Inspector 内蔵ツールを使えば コントラスト比が分かります 及第点になる色のペアや 文字サイズが分かるツールで 先に述べたガイドラインに 従うものです ただし これで推奨されている 4.5：１という数値を超えていても 低視力の人にとっては まだ読みにくいかもしれません そこで コントラストを 上げる設定を作りました 以前のiOSで Darken Colorsと 呼んでいた機能です isDarkerSystemColorsEnabledと 入れてください 標準のUIKitコントロールで tintColorをオンに設定しても それで機能します macOSではaccessibilityDisplay ShouldIncreaseContrastとします

第３にサイズです

コンテンツのサイズを変えても 読みやすさは劇的に向上します 低視力者には非常に有益です カレンダーの例です 左はデフォルトのサイズで 右はテキストサイズを 大きくしたものです 低視力の人に この２つを見せたら 右の画面なら 文字が読める可能性が高いでしょう

iOSでは ユーザが テキストサイズを指定でき デフォルトは ７段階の真ん中です アクセシビリティ設定では さらに５段階 増やせます

Dynamic Typeの話は このくらいにしましょう アプリケーションで Dynamic Typeを活用する方法は どうぞご自身で チェックしてください

テキストサイズを 変えるのが嫌でも やはりデフォルトでは 読みにくいフォントがあります その場合 文字を太くできます これでグリフの線も 濃くなります

標準のUIコントロールと システムフォントなら iOSの太文字設定が おそらくそのまま使えます カスタムフォントを 使っている場合や 境界線を太くするといったことが したい場合は― 必要に応じて 変更してください

第４に動きです アニメーションは楽しく 画面が活気づきますし ユーザインタラクションと そのアクションの効果を増やします ただ 内耳の症状などで 平衡感覚に問題がある人には アニメーションは厄介です めまいや吐き気の 原因となるからです

これから具体的な例を お見せします 動きの知覚に問題のある人は しばらく 画面を 直視しないようにお願いします

最初は拡大とズームです 左が アプリケーションを開く時の デフォルトの動きです

例えば時計を開くと アイコンが拡大します 右は 視差効果を減らした場合で クロスフェードで切り替わります

次は回転と渦巻きです メッセージで フルスクリーンエフェクトを使うと 吹き出しが回転し 大きさも変わります これが問題になることも 視差効果を減らすと 自動再生ではなくプロンプトが出て エフェクトを再生するか ユーザが選べるようになります

次はプレーンシフトです Safariで すべてのタブを 見るボタンを押すと カードが傾き 3D空間が演出されます 右では 動きが少なく クロスフェードです カードが一度 点滅し― 最後に見ていたページがどれか 分かる仕組みです

多方向や多速度も 問題になり得ます 例えばメッセージの 吹き出しです 実物は この動画より もっと派手な動きです スクロールすると跳ねます 吹き出しが拡大縮小し 隙間も変動します 視差効果を減らしておくと この動きもなくなります

最後に 周辺視野の動きです 天気アプリケーションの背景は アニメーションで 現在の天気を表現します 左の背景では 雲が流れ わずかな日射しも見えています ところが 下部の予報を見る時 これが視野に入るので 車の中で読書をした時と同様に 酔う可能性があります 焦点より上の水平な動きに 脳が反応するからです 視差効果を減らせば 背景は静止します

アニメーションを 減らすべきかは 各OSで設定を確認し 適切な変更を行ってください iOSでは isReducedMotionEnabled macOSではaccessibilityDisplay ShouldReduceMotionです ただ動きを排除するだけでは 不十分なことが多いです 体験を貧弱にするのではなく 実用的で 同等に楽しい 別の効果を加えるべきです

第５に UIを複雑にしない 配慮が必要です アプリケーションの 重要性が増し シンプルで使いやすい技術が 求められています 人間に負担を かけないことが大事です

米国だけでも 発達障がい児は６人に１人 発語を含む言語の障がいから 自閉症まで様々です 認知障がいや慢性病を 持つ人にとって アプリケーションの使用は 体力を要します シンプルに使える アプリケーションが必要です

似た構造を持ち 論理的で 画面操作が楽でなければなりません 一般的なタスクを障壁なく 完了できるようにすべきです そして 動作の一貫性も必要です 学びを応用できる環境に するのです 標準のUIKitを使えば ユーザが慣れますし iOSの設計言語としても 機能します カスタム設計でも― UIKitと統一していれば ユーザは直感的に操作できます

これがユーザの使用体験に 直結します VoiceOverなどの利用者にも 大事なことです では アクセシビリティユーザの 体験を向上させるには？

支援技術を使ったユーザ体験は 通常画面のそれとは異なります 例えば スワイプや 複数指でのタップの多用です

操作方法を設定できる スイッチコントロールにも VoiceOverにも 標準的な動作が組み込まれています では 極上のユーザ体験を 生み出すには？ “使用可能”では不十分で いい体験が欲しいのです

体験自体は異なっても 支援技術を使うユーザも いい体験をすべきだというのが 私たちの設計理念です 画面操作が簡単で 挙動が予測でき 優先順位が合理的で 一貫していることです 別の要素がコンテキストを 伝えているなら それも伝えられるべきです では ここでバビヤが― アクセシビリティの査定を 実演します どうぞ (拍手) 私はバビヤ ソフトウェアエンジニアです アクセシビリティ体験の 向上について 試作アプリケーションを使い 説明します 名前はExceptional Dogs 保護犬の譲渡を 容易にするために ユーザが候補の犬を 閲覧するものです 見てみましょう

こちらです トップのUIはカルーセルで ここに様々な犬の写真が出ます 左下のボタンを押せば お気に入りに登録でき 右下のボタンを押せば モーダルで ギャラリーが表示されます

ギャラリーボタンは オプションで 次のレイラのように 写真が複数ない時は消えます カルーセルの下は 犬の名前や品種などのデータです カルーセルをスワイプすると 更新されます

一番下は その犬がいる保護施設名で マップを開いたり 電話したりできます

視覚的には かなり複雑です でも私とスカイラーは アクセシビリティを意識して VoiceOverでの読み上げを 可能にしました では VoiceOverで― 低視力者が この複雑な画面を どう把握するか確認します

“VoiceOver オン” “Exceptional Dogs　ピンキー” 画像を認識し 犬の名前を読み上げました スワイプで写真をスクロール “レイラ ブロ プディング” “お気に入りボタン オフ” “プディング ブロ” 犬の名前を全部 読み上げたあと ようやくお気に入りボタンに 言及しました 指をボタンの上に置けば 読み上げますが… “お気に入りボタン オフ” VoiceOverユーザは 典型的には― スワイプで 次の要素を見つけます 現状 スワイプでは最後まで 画像上のボタンが見つかりません 体験としては貧弱です 犬を全部 見るまで ボタンにアクセスできないからです 今は強制的に ギャラリーを起動します “ギャラリーを見る” “ギャラリーを見る” “ブロの写真１　画像” ギャラリーをスクロール “ブロの写真２” “ブロの写真３” “ピンキー” “レイラ”

ギャラリーを スクロールできましたが フォーカスが バックグラウンドに行きました 必要なコンテンツには たどり着けますが 極上体験とは言えません フォーカスがモーダルから外れると 混乱します ダブルタップで モーダルを閉じます “閉じる” “閉じる” “レイラ” データ部分をスワイプします “名前 品種” “レイラ ラブラドール” “名前”と聞いた直後が 犬の名前ではなく “品種”でした 視覚的には いいレイアウトですが VoiceOverが 読み上げにくい構造なのです よって 聞き手の認知に 負担がかかります

保護施設名から ボタンへスワイプします “スカイラー保護施設” “マップで場所を表示　ボタン” “発信　ボタン” ボタンを押すことは可能ですが コンテキストが欠けています “発信”と聞くだけでは 何のことか分かりません ボタンが施設名の横にあることが 明白でないからです

“VoiceOver オフ”

今のような問題があっても アプリケーションは使えますが ユーザに負担がかかります 目標は極上の体験を 創り出すことです 改めて スカイラーから― Exceptional Dogsを 極上にする方法を説明します

(拍手) いくつか問題が発覚したので アクセシビリティAPIを 確認しましょう

まずカルーセルの問題です 画像上のボタン２つに 最後まで言及しませんでしたね 個別データの読み上げも 後回しでした データとアクションに 早く到達するため―

使うのは UIAccessibilityElementです これで新しい要素を 作るのです UIAccessibilityElementは カスタム要素を作るクラスで 大抵は アクセス不能な UI上のパーツに使います でも 今回のように カスタム体験を作る時にも使えます ビューのaccessibilityElements プロパティから 任意のカスタム要素を 返します すると その特定のビューの 子要素と それを読み上げる順序が 支援技術に伝わります

これで スワイプで 各犬のコンテンツに進めます では 別の犬を 閲覧するには？

インクリメントと デクリメントを使います カスタム要素に 可変のTraitを加え 要素が コールバックに応答すると 支援技術に理解させます これで VoiceOver起動中は 上下のスワイプで ビューが前後にスクロールされます

次に情報のラベルを 見ましょう 先ほどは順序がバラバラで 値とラベルのコンテキストが 欠けていました コンテキストは重要です 譲渡済みか知ろうと ラベルに触れたのに “イエス”とだけ返されたら 途方に暮れるでしょう 何を肯定したのか 分かりません 画面操作も問題でした 情報を得るため 14ものラベルをスワイプしましたね 組み合わせれば 操作が半分になり 早くなります ラベルをグループ化し １要素にすれば ラベルと値の関係が 理解できます ここでも使うのは UIAccessibilityElementです ラベル１組に対して要素を作り ビューのaccessibilityElements プロパティから返すのです

また 先ほどのデモでは 施設のビューが ３要素に分かれていました 施設名 マップボタン 発信ボタンです

ボタンにも コンテキストが欠けていました 施設名より先に触ると 何のボタンか分かりません

３つが分離していると 要素の数が増え 情報を探すのに 時間がかかります だから１要素にまとめ 操作を簡略化するのです

優先順位も考慮すべきです 最も必要な情報は その犬がいる施設名です よってそれを最初に伝え 場所の特定と発信はあとにします これを実現するAPIは accessibilityCustomActionsです これなら要素に アクションを加えられて ユーザは順に 情報に当たれます 特定のビューに カスタムアクション配列を返せて アクションに名前もつきます ユーザが聞けば アクションの内容が分かる名前です ターゲットとセレクタも 関連づけられます

これで施設ビューの アクセシビリティが向上します

あとはギャラリーです 先ほどはバックグラウンドでの スワイプが可能でした モーダルビューに見えて 違ったわけです View Controllerで モーダルにするのではなく 階層のトップに 加えていただけだからです バックグラウンドの コンテンツが見えるため VoiceOverが除外しません

VoiceOverが 認識した 全ギャラリーを読み上げれば ユーザはコンテキストを見失い 混乱します

そこでaccessibilityViewIsModalと オーバーライドして 今 アクセスできる要素は ビュー内だけだと認識させます

オンスクリーン要素が 変わった時に 再フォーカスを 促す通知も必要です これにはScreen Changeの 通知が使えます

ここからはバビヤが 今 紹介したAPIの実装をします よろしく

(拍手) ありがとう アクセシビリティ体験を 極上にしましょう Xcodeを開きます

まずトップのカルーセルです DogCarouselContainerViewクラスに 犬のコレクションビューと ２つのボタンが入っています ここにインクリメントと デクリメントを実装し 上下スワイプでのスクロールを 可能にします そこで ここに プロパティを作ります CarouselAccessibilityElementです これはカスタムの UIAccessibilityElementです

では実装しましょう

UIAccessibilityElementの サブクラスになります 現在のオブジェクトを特定する プロパティも作ります

イニシャライザと―

ラベルや値も記述しましょう

ラベルは“Dog Picker”で 値は犬の名前と “お気に入り”のステータスです

次にインクリメントと デクリメントの機能です まず accessibilityTraitsを オーバーライド

先に インクリメントで―

コレクションビューを 先に送る機能を実装します

一番上の機能名を 見てください スクロールで送るか戻すか ブーリアンで決めます 細かく見ていきます containerViewとcurrentDogと リスト全体を参照 fowardsで currentDogの インデックスが 境界を超えないか確認します 超えないなら １つ先のインデックスへ 戻る時は インデックスが マイナスにならないか確かめて コレクションビューを １インデックス戻します

ではインクリメントの 実装です

前へのスクロールはtrueに デクリメントも 同様にできます

違いは 戻るため falseにする点です カルーセルの設定は以上です containerViewに戻ります

CarouselAccessibilityElementを 開示するため accessibilityElementsを オーバーライドします

この機能で currentDogを参照し 要素を作る前に 有効か確認します

CarouselAccessibilityElementの インスタンスを生成します

もしこれが既存なら先に参照し なければ― インスタンスを生成します

アクセシビリティフレームを dogCollectionViewにし ここに参照を保存 最後に要素の配列を返します その前に 要素を少し 配列に加えたく思います

currentDogに 写真が複数あるか確認します CarouselAccessibilityElementと ２つのボタンで 配列を構成したいからです 写真が１枚なら ギャラリーボタンは省きます

containerViewで 当該のプロパティが更新されれば CarouselAccessibilityElementで currentDogプロパティも更新します

あと少しです カルーセルをスワイプした時 犬の情報も 連動して変わりましたね だからVoiceOverの起動中も 画像が更新されたら VoiceOverに理解させるべきです そこで スクロール時に レイアウト変更通知を出します

そこでView Controllerに行き scrollViewDidScroll機能の中で 最後にこのように レイアウト変更通知を書きます

containerViewはこれで万全

アクセシビリティ要素を 使ったり作ったりするのがカギです データ部分の問題にも 同じ発想を応用できます 情報が分断され コンテキストが欠けていましたね そこで カルーセルと同様に データ部分の情報も グループ化します

データはDogStatsViewに 入っています

まずaccessibilityElementsを オーバーライド

作った要素をキャッシュすれば 何度も再計算せずに済みます そこでプライベートプロパティ accessibilityElementsを作成 これがキャッシュになります

そして機能です

キャッシュを確認し 空なら要素を追加します

全titleLabelsを反復し “品種”といった タイトルラベルを参照します “ラブラドール”など 該当する値も参照

タイトルと値を参照したら アクセシビリティ要素を作り 両者をつなぎます

ここに要素を作り ラベルとフレームを設定して 該当するタイトルと値を 組み合わせます

この要素を配列に追加

タイトルと値の全ペアを ループしたら キャッシュをこの配列と等しくして 要素を返します

犬オブジェクトが 更新されたら 都度キャッシュをリセットし 新しい犬の要素も計算させます そのため ここはnilに設定します

DogStatsViewは以上です 次に 発信とマップのボタンに コンテキストを加えます

施設情報はShelterInfoView

施設名 マップボタン 発信ボタンを参照しています

両ボタンは カスタムアクションにしたいので アクセシビリティ要素として ビューを開示します

施設名なので 記述式ラベルにします

accessibilityCustomActionsを オーバーライド

カスタムアクションは ２つ作ります mapActionとcallActionです “マップで場所を表示” “発信”と発声されます ストリングはローカライズを

各アクションが機能を呼び出し ボタンがアクティブになります mapActionなら activateMapButtonが呼び出され マップボタンがアクティブに

機能はこちらで定義しました

メソッドが成功すれば trueを返します

以上が施設のビューで―

最後にモーダルビューも 改善しましょう

DogModalViewで定義します VoiceOverにモーダルビューだと 認識させるため accessibilityViewIsModalと オーバーライド

あと少しです

ギャラリーボタンを 押した時には レイアウト変更を アプリケーションに伝え― VoiceOverの フォーカスを保ちます そこで ギャラリーボタン押下で 画面変更を通知します

View Controllerに入ります

ギャラリーボタンを 押した時の機能で モーダルビューで動きがあれば 変更通知を入れます

これだけです

アクセシビリティを 更新したので 体験が改善されたか 確認しましょう

VoiceOverをオンにします

“VoiceOver オン” “Exceptional Dogs” “犬を選択　ピンキー” “調整可能” “１本指で上下にスワイプして 値を調整” 上下スワイプが可能だと 言いましたね カルーセルを動かしましょう “レイラ” 下にスワイプします “ピンキー” 左から右にスワイプして ボタンを見つけます “お気に入りボタン オフ” “ギャラリーを見る ボタン” これですべての犬に アクセスでき ２つのボタンも すぐ見つかりました 左から右にスワイプすれば データ部分に飛べます “名前 ピンキー” カルーセル閲覧を中断でき 体験が改善しました データ部分の操作を 続けましょう 左から右にスワイプします “品種 ミックス” “年齢 7.0歳” 情報がグループ化され コンテキストができ 全ラベルを開かなくてよくなり 操作が早くなりました 施設名の上に指を置きます “スカイラー保護施設” “アクション可能” アクションがあるとのことなので 上にスワイプ “マップで場所を表示” “発信” 施設名に関連のある アクションであることが明白になり コンテキストができました 最後にギャラリーボタンを ダブルタップ “ギャラリーを見る ボタン”

“ピンキーの写真１　画像” 左から右にスワイプ “写真２ 写真３” “閉じる 閉じる 閉じる” “ボタン” フォーカスは モーダルビューから外れません

“VoiceOver オフ”

(拍手) これでアクセシビリティ体験が 使用可能から極上になりました 実際の操作感を確認しながら 開発を行ったことで ユーザの負担を 劇的に軽減させました ユーザはデベロッパの努力を喜び アプリケーションを楽しめます 締めはスカイラーから

(拍手) ありがとう

今のバビヤのデモで 微調整が生む変化が 分かったと思います インターフェイスを カスタムにしなくても 単純な修正で アクセシビリティを向上できます アプリケーションを アクセシブルにする際は 表面的な考え方を捨て― 支援技術を使うユーザにとって 何が大事か考えるのです

まとめとして 冒頭の話に戻ります 使えることは 大きな第一歩ですが 上を目指しましょう 各ユーザの ニーズに応える― 極上の楽しい体験を 提供できるはずです

アプリケーションを 極上にする方法はいくつもあります アクセシブルな設計には 利点があります 色のコントラスト比を 推奨値以上にしたり レイアウトを変えられたりすれば 全ユーザが恩恵を受けます ユーザの設定に合わせて デフォルト設計を拡張してください

支援技術を使った アクセシビリティ体験には 目的意識と 優先順位が大事です 簡単で直感的な操作と コンテキストを忘れずに

このセッションの詳細と デモをしたアプリケーションは 画面のURLにあります また 私たちは― アクセシビリティに関する ラボも行います ご自分のアプリケーションを アクセシブルにする方法など 具体的な質問にも答えます そちらもご参加ください では 楽しいWWDCを (拍手)