ヤフーの中野と申します。よろしくお願いいたします。 今までスポンサーセッションで話をしていましたが、今回は通常セッションで話をさせていただきます。 「ウェブはすべての人が使えるべきもの 障がい者の力でアクセシビリティ改善」というタイトルで、過去を含めたヤフーの取り組みを紹介します。 ----- 始めに自己紹介です。 中野 信と申します。 ヤフーのサービスUIのガイドラインを作ったり運用したりしている組織で、ウェブアクセシビリティの向上に関わっています。 また、アクセシビリティでは「黒帯」という肩書きで技術エヴァンジェリストを5期任命されて勤めています。 ヤフーの社外では、昨年9月に発足したデジタル庁で、民間登用のアクセシビリティアナリストを非常勤でしています。 加えて、ウェブアクセシビリティ基盤委員会というJIS規格の周辺ドキュメントを運用している委員会で、理解と普及という作業部会で委員をしています。 プライベートでは、娘が二人いて日々育児に追われています。 新型コロナウィルスの影響で2020年から在宅勤務をしてますが、仕事の環境が大きく変わった反面子供と接する時間が多くなったのはよかったと思います。 ----- ヤフーのウェブアクセシビリティの主な取り組みです。 Yahoo!天気・災害の各種図の視認性検証、 選挙広報をテキスト化して提供する聞こえる選挙、 LINEと経営統合した際にリリースされた各種ページの視認性検証をしています。 ----- これは、Yahoo!天気・災害で提供している天気図です。 スライドでは色覚特性のシミュレーションを表示していますが、実際にはシミュレーションに加えてロービジョンの社員が都度検証しています。 天気図に限らず、新しい図が追加されるごとに定常的に検証をしています。 ----- 続けて、聞こえる選挙です。 もともとは、全盲の方が選挙公報から断絶されているという社会問題に対して、問題提起のためにリリースしたサイトでした。 その後、正式にサービスとして運用する改修と、アクセシビリティの規格、JIS X 8341-3:2016のレベルAに準拠する改修をして、定常的にサービスとして運用できるようにしたサイトです。 このサイトは衆議院・参議院の国会議員の議員選挙で運用されています。 ----- 3つ目、ヤフー・LINEの経営統合した時にリリースした、各種ページの視認性検証です。 今スライドで表示しているページは2021年3月にヤフーとLINEが経営統合した時に公開したページです。 ヤフーとLINEそれぞれのブランドカラーが赤と緑という、色覚特性によっては区別しにくい色だったため、 シミュレーターでの検証に加えて、ロービジョンの社員による検証もしました。 経営統合を発表したページは1ページでしたが、合わせて超PayPay祭りなど各種イベントが連動していたため、短期間で大量のページやサービスを確認しました。 ----- 今回ご紹介する話です。 1. ガイドラインでアクセシビリティを改善 2. 当事者と一緒にアクセシビリティを改善 3. ガイドラインとユーザーテストで改善 それぞれ話をします。 ----- まずは1つ目、ガイドラインでアクセシビリティ改善についてご紹介します。 ----- ヤフーでは、サービスを開発するときに守ることをまとめたガイドラインがいくつかあって、そちらに則ることで品質やセキュリティを一定水準に保つようになっています。 そのガイドラインの一つ、UI、ユーザーインターフェースのガイドライン、UIガイドラインの中にアクセシビリティのガイドラインがあります。 ウェブアクセシビリティ、アプリアクセシビリティ、文字という3つのガイドラインです。 ----- まずはウェブアクセシビリティのガイドラインです。 こちらは、ウェブアクセシビリティのJIS規格、JIS X 8341-3:2016の適合レベルAの達成基準とほぼ同じ内容となっています。 JIS X 8341-3:2016は原文の英文のほぼ直訳になっていて、初見では分かりにくい文章になっています。 加えて、抽象度の高いガイドラインとなっているため、サービス開発の関係者が読んだときにガイドラインから自分たちが何をすべきかが分かりにくくなっています。 そのため、抽象度を落として平易な文章にすることで、作業に組みいれやすいようにしています。 ----- ここでは達成基準1.3.2 意味のある順序を例として上げています。 JIS規格では「コンテンツが提示されている順序が意味に影響を及ぼす場合には、正しく読む順序はプログラムによる解釈が可能である。」と書かれていますが、 これを「コンテンツの順序に意味がある場合、機械がその順序を解釈できるようにします。」という文章にしています。 ----- 次に、アプリアクセシビリティです。 こちらは、JIS規格の適合レベルAの達成基準を元に項目を編集しています。 ウェブの技術、HTMLを想定した達成基準を削除して、WCAG2.1のスマートフォン操作に関わる達成基準「入力モダリティ」の項目を追加しました。 さらに、iOSとAndroidの実装方法例を追加しています。 ----- 最後のガイドライン、文字です。 一般的な文字の視認性やビジュアルトーンを統一するためのフォントの定義がガイドラインの大部分を占めますが、 文字サイズと背景とのコントラスト比は、WCAG2.0の達成基準を元にしています。 文字サイズ13ピクセルの場合はコントラスト比4.5:1以上、 文字サイズ21ピクセルの場合はコントラスト比3:1以上にするよう、定義しています。 ----- 2つ目、当事者と一緒にアクセシビリティを改善、についてご紹介します。 ----- この取り組みには、社内で3つの組織の関係者が登場します。 1人目がヤフーのサービスを開発・運用しているサービス関係者です。 そもそもアクセシビリティ改善を行いたい、というニーズがないとテストができません。 外部要因と内部要因それぞれの場合がありますが、テストのニーズを確認とテスト後の改善をしてもらいます。 2人目はノーマライゼーションプロジェクトの方々です。ヤフーには障害当事者が特性を活かしてサービス改善を行うというプロジェクトがあります。 サービスのニーズに応じて、ロービジョン、全盲といった障害当事者の方々にテストをしてもらいます。 3人目は私、中野です。 私はウェブアクセシビリティの知識に加えてユーザビリティテストの知識と経験があるため、 テストの計画・実施・レポートなどをしています。 ----- それぞれの思惑・ニーズがあります。 サービス関係者はガイドラインの対応だけでは解決できないアクセシビリティの検証をしたい、 ノーマライゼーションプロジェクトはサービス改善に関りたい、 中野はガイドラインだけでは分からないアクセシビリティの課題を知りたい、という思惑があります。 ----- 実際にどのように進めるかという、テストの流れです。 まず、関係者全員でテストの要件定義をします。 次に、テスターの調整をテスト設計を並行してやります。 それらができたらテストをして、 テストで見つかった課題を整理していから、改善作業を行うという流れになります。 ----- 具体的に、どのようなテストを行ったかを紹介します。 Yahoo!天気・災害では、 JISの達成基準にあるコントラスト比や色の使い方だけでは判断が難しい、図の視認性を確認するためにテストをしました。 色だけで情報を伝える箇所が多々あったため、ユニバーサルカラーを使うという選択肢もありましたが、天気・災害では図の中で情報の優先度をつけて対応するという方法を取っています。 2つ目の聞こえる選挙は、視覚障害者に選挙公報を届けるという、特定の障害に特化したサービスのため、スクリーンリーダーのユーザビリティを確認するためにテストをしました。 これは社内ではなく社外の方5人に協力いただきましたが、スクリーンリーダーとブラウザの組み合わせが全員違ったため、ひとくちにスクリーンリーダー対応とは言えないということを気づきを得られました。 3つ目の社内ツールでは、ツールの利用者にロービジョンや全盲のユーザーがいることをサービス関係者に気づいてもらう、という目的でテストを行いました。 スクリーンリーダーでツールを使えることを知ってもらえたり、Windowsの拡大鏡やローコントラストのテーマを知ってもらえたりと気づきの多いテストになりました。 ----- 実際のテストの様子です。 これは社内ツールをスクリーンリーダーを使って操作している様子です。 Webミーティングのツール、Zoomを使ってテストをしている人の画面と音声を共有してもらい、 その様子を見聞きしながらシナリオに沿ってテストを行います。 弊社は2020年から社員のほぼ全員が在宅勤務でリモートワークをしていますが、 もともと、Yahoo!天気・災害の開発拠点が大阪だったため、テストはそれ以前からリモートでした。 そのため、働く環境はこの数年で大きく変わりましたがテストは大きな変化もなく進められています。 ----- 社内ツールのテストを行って見つかった課題はこのようなものがありました。 ロービジョンの方によるテストでは、事前のヒアリングでも指摘があったテキストエリアの枠線が見えづらい課題に加え、 テキストリンクやバツアイコンなどの操作部分の視認性、 一部記号の視認性の課題が見つかりました。 スクリーンリーダーによるテストでは、事前のヒアリングでも指摘があったチェックボックスの状態がわからない課題に加えて、入力フォームのキーワードサジェストが長い場合にそこで操作が止まってしまう課題や、 一部エラーメッセージが読み上げられないといった課題が見つかりました。 ----- これらの課題を、作業の難しさと重要度を考えながら優先度をつけて、改善をしていきます。 今回は、テキストエリアの枠線の調整と、スクリーンリーダーでもチェックボックスのオンオフが分かるような改善をしました。 ----- 3つ目、ガイドラインとユーザーテストの関係について話をします。 ----- 今回、ガイドラインを使ったアクセシビリティの改善と、当事者によるユーザビリティテストによるアクセシビリティの改善の話をしました。 どちらか一方だけでも十分なのでは? と思う方もいるかもしれませんが、それぞれの方法に特長があると考えます。 ガイドライン、JIS規格やWCAGは様々な障がいや状態を網羅しているため、これを使うことで全般的な課題を見つけることができます。 一方、ユーザビリティテストは特定の状況や障害の課題を集中的に検証することができます。 また、ガイドラインは一般化や抽象化されているため、ガイドラインに対応してるだけでは実際のユーザーをイメージしずらいこともありますが、 ユーザビリティテストを行うことで利用している状況を具体的にイメージしたり共感できるようになります。 ----- 図にするとこのようになります。 アクセシビリティの課題や状態をガイドラインで広く確認します。 その中の特定の課題や状態をユーザビリティテストで確認するイメージです。 ユーザビリティテストで網羅的な検証をすることは難しいですが、 サービス個別、障害個別の課題を検証することができるため、ガイドラインとユーザビリティテスト両方で補完しながらアクセシビリティを高めることが有効であるといえます。 ----- 最後に、今後の目標について話をさせてください。 ----- 今回、ヤフーの取り組みを紹介しました。 ガイドラインとユーザビリティテストの2段階の検証と改善の仕組みがありますが、アクセシビリティの取り組みは必須ではないため、対応しているサービスはまだ多くはありません。 そのため、対応範囲をより多くのサービスに広げたいと考えています。 そして、アクセシビリティの向上・改善に意欲を持った人が増えることで、アクセシビリティの改善や向上が例えばUXのように、より普遍的な取り組みになるとよいと考えています。 ----- 以上で、「ウェブはすべての人が使えるべきもの 障がい者の力でアクセシビリティ改善」の話を終わります。 ご清聴ありがとうございました。