Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Webアクセシビリティ入門_2024

Recruit
August 09, 2024

 Webアクセシビリティ入門_2024

2024年度リクルート エンジニアコース新人研修の講義資料です

Recruit

August 09, 2024
Tweet

More Decks by Recruit

Other Decks in Technology

Transcript

  1. 事前準備(2/2) • 以下の手順でVoiceOverが起動することを確認してください 1. 適当なWebサイトを開きます 2. 以下のいずれかの方法でVoiceOverを起動します ▪ command +

    F5 ▪ command + Touch IDを素早く3回 ▪ システム環境設定 > アクセシビリティ > VoiceOver > VoiceOverを有効にするチェックボッ クス 3. VoiceOverのチュートリアルが表示された場合は、それを行うかスキップし、次回からは表示され ないようにします 4. 適当なWebサイトのテキストの一部を選択し、それが読み上げられることを確認します 5. 起動時と同じ方法でVoiceOverを終了します • 演習サイトをセットアップ・起動し、実際にサイトが表示されることを確認してください 1. 詳細はリンク先のREADMEを参照してください 3
  2. 自己紹介(講師) • 名前:雫石 卓耶(しずくいし たくや)(@sititou70) • 2021年新卒入社 • 所属:横断エンジニアリング部 アプリケーション・ソリューショ ン・グループ(ASG)

    • 普段:Webフロントエンドの設計や実装 • 好きなもの:アクセシビリティ ◦ 勉強したり ▪ 本 / ガイドラインを読む ▪ Trusted Tester:TT-2404-05928 ◦ チームに布教したり ▪ レビュー / テスト整備 / ドキュメント作成 • よろしくお願いします 4 フローリングの アイコンが私
  3. 定義 • accessibility = access + ability • accessibility =

    アクセス + できること(またはその程度のこと) • a11yと略される ◦ aとyの間に文字が11個あるから 8 参考:ウェブアクセシビリティ導入ガイドブック, デジタル庁, 2022。以降の出典ではタイトルだけ記載
  4. Web a11yが低い例 • Aさんはロービジョン(弱視)の障がいを持っている • あるサイトの文章は、Aさんが読むにはコントラストが低い ◦ →最低限のコントラストを考慮してデザインすればよかった • Aさんは、視覚的に文章を読むのを諦めた。代わりにスクリーンリーダーを使用

    して読み上げ音声を聞こうとした。しかし文章はすべて文字画像で、alt属性など は指定されていなかった ◦ →適切な代替テキストがあればよかった • 結果的に、このサイトはAさんにとってa11yが低かったと言える 10
  5. 重要性:なぜa11yを改善すべきなのか? • 代表的なものをピックアップして紹介します ◦ アクセスできない / しにくい人を減らすため ◦ SEO対策のため ◦

    さまざまなデバイスに対応するため ◦ UX改善のため 11 参考:太田良典, 伊原力也, デザイニングWebアクセシビリティ, 株式会社 ボーンデジタル, 2016。以降の出典ではタイトルだけ記載
  6. アクセスできない / しにくい人を減らすため(1/4) • a11y改善がメリットとなる障がい者の数*1 ◦ 国内だけで428.7万人 ◦ 視覚 /

    聴覚 / 言語 / 内部障がい、肢体不自由など • 総人口で割ると ◦ 428.7万人 / 12,399万人*2 ≒ 3.4% ◦ 100人アクセスしたら3人にメリットあり? ▪ 意外に多いと思いませんか? 12 *1:ウェブアクセシビリティ導入ガイドブックより。*2:人口推計, 2024年2月報, 総務省統計局 , 2023
  7. アクセスできない / しにくい人を減らすため(2/4) • 障がい者ではないがa11y改善がメリットになる人 ◦ クイズ:そのような例を思いつくだけ挙げてみてください ▪ (時間:1分) ▪

    ヒント: • 例えば目が見えづらい原因は、障がい以外に何かありますか。 • 他にも、音が聞こえづらい、操作が難しいなどについてはどうです か。 13
  8. アクセスできない / しにくい人を減らすため(3/4) • 障がい者ではないがa11y改善がメリットになる人の例 ◦ メガネを忘れてきた / 壊れている ◦

    陽の光が眩しくて画面の色を認識しづらい ◦ 高齢になり、最近目が悪くなってきた ▪ →コントラストが強く、文字が大きいほうが良い ◦ 電車が揺れてスマホでポインティングが難しい ◦ 最近PCを買ってみた。マウスの操作にはまだ慣れていない ▪ →ボタンが大きめだとうれしい 14
  9. アクセスできない / しにくい人を減らすため(4/4) • 障がい者ではないがa11y改善がメリットになる人の例 ◦ イヤホンを忘れてきた / 充電切れ /

    つけるのが面倒 ◦ 周りがうるさくて音が聞こえない ▪ →動画や音声コンテンツに、字幕や書き起こしがあるとうれしい ◦ 一時的に腕を怪我していてマウスが使えない ◦ マウスを使うだけのスペースが無い、またはマウスを忘れてきた ◦ 単純にキーボード操作が好き(例:エンジニアなど、つまり僕) ▪ →キーボードで操作できると良い 15
  10. さまざまなデバイスに対応するため • a11yの基準を守っていると、特殊なデバイスにも対応できる場合がある • 達成基準 2.5.5 ターゲットのサイズ:ボタンやリンクなど、ポインタのターゲッ トが一定よりも大きいこと ◦ →ポインティングが普通より難しいデバイスに対応

    ◦ 例:家庭用ゲーム機Wiiのブラウザ、Wiiリモコンでポインティングする • 達成基準 1.4.3 コントラスト (最低限):ページの色使いに一定以上のコントラス トがあり、はっきり見えること ◦ →白黒表示のデバイスに対応 ◦ 例:Kindle端末、モノクロ印刷機 16
  11. SEOのため(1/3) • a11y改善とSEOの方法には共通する部分が多い • 例1:titleタグ ◦ SEO:<title> 要素に具体的でわかりやすいテキストを記述する*1 ◦ a11y:ウェブページには、主題又は目的を説明したタイトルがある*2

    • 例2:alt属性 ◦ SEO:画像に alt 属性を指定することでユーザーが目的のコンテンツを見つけやす くなる*3 ◦ a11y:利用者に提示されるすべての非テキストコンテンツには、同等の目的を果 たすテキストによる代替が提供されている*4 ▪ 非テキストコンテンツ:画像など ▪ テキストによる代替:alt属性など 17 *1:最適なタイトルリンクを出しやすくするためのベストプラクティス, Google。*2:WCAG 達成基準 2.4.2 ページタイトル, W3C。*3:Google 画像検索 SEO ベストプラクティス, Google。*4:WCAG 達成基準 1.1.1 非テキストコンテンツ, W3C
  12. UXの例(2/5):アクセスしやすい • title要素が適切でない例 ◦ 「新しいドキュメント」というtitle ▪ 何のページかわからない ◦ 「PRT-12345-67 |

    家庭用プリンタ」というtitle。内容はPR動画 ◦ 「PRT-12345-67 | 家庭用プリンタ」というtitle。内容は消耗品案内 ◦ 「PRT-12345-67 | 家庭用プリンタ」というtitle。内容は説明書 ▪ あいまい。どれにアクセスすればいいかわからない • →今回はtitle要素が具体的でわかりやすかったため、アクセスしやすかった 23
  13. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 34 出典:Essential Components of Web Accessibility

    Webサイトを作るソフトウェア 例:CMS、ブラウザのDev Tools、テキストエディタ、 HTML WYSIWYGエディタ…
  14. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 39 出典:Essential Components of Web Accessibility

    支援技術 例:スクリーンリーダー、点字ディスプレ イ、その他の特別な入出力装置…
  15. WCAGの歴史:WCAG 2.0 • 2008-12-11勧告 ◦ 1.0の勧告から約8.5年 • 構造を刷新、より現代的なWebの環境に対応 • 61個の達成基準(a11yを達成するための要件)

    • 標準化 ◦ ISO/IEC 40500:2012と互換 ◦ JIS X 8341-3:2016と互換 ▪ クイズ:8341という番号は、ある理由によって選ばれました。その理 由とは?(時間:30秒) 47
  16. WCAGの歴史:WCAG 2.0 • 2008-12-11勧告 ◦ 1.0の勧告から約8.5年 • 構造を刷新、より現代的なWebの環境に対応 • 61個の達成基準(a11yを達成するための要件)

    • 標準化 ◦ ISO/IEC 40500:2012と互換 ◦ JIS X 8341-3:2016と互換 ▪ →「やさしい(8341)」の語呂合わせらしいです 48
  17. WCAGの歴史:WCAG 2.1 • 2018-06-05勧告 ◦ 2.0の勧告から約9.5年 • 78個の達成基準 ◦ 17個の基準を追加

    • モバイルデバイスを考慮 • 弱視、認知障害、学習障害のための基準を追加 49
  18. WCAGの歴史:WCAG 2.2(最新) • 2023-10-05に勧告 ◦ 2.1の勧告から約5年 ◦ 現状勧告されているWCAGの中で最新 • 86個の達成基準

    ◦ 2.1の1つの基準を廃止*1 ◦ 9個の基準を追加 • フォーカス、入力操作と支援、認証、ヘルプについて基準を追加 50 *1:詳細:How and why is success criteria 4.1.1 Parsing obsolete?
  19. WCAGの歴史:WCAG 3.0(作成中) • 完成はあと数年後 ◦ リポジトリのコミットを見る限り、2018-04頃から作成に取り掛かっていた 様子*1 ▪ WCAG 2.1勧告のちょっと前

    • 構造を刷新 ◦ 草案には、VR(仮想現実)やAR(拡張現実)といった単語も見られる 51 *1:リポジトリ:https://github.com/w3c/silver
  20. 達成基準と分類 • ガイドラインは達成基準で構成されます*1 ◦ 達成基準:a11yを達成するための要件 • 達成基準は大きく4つに分類されています ◦ 知覚可能 ◦

    操作可能 ◦ 理解可能 ◦ 堅牢 • alt属性は、その画像が何なのかを知覚するためのもの ◦ →「知覚可能」を見れば良さそう 54 *1:以降は、WCAG 2.1の場合の話で、他のバージョンには当てはまらない場合があります
  21. 56

  22. 58 • レベルA:基準の分類。より優先して満たすべき重要な基準はA。次にAA、 AAAと続く。 • 適合レベル ◦ レベルAに適合:全てのレベルAの基準を満たすこと。「このサイトは WCAG 2.1

    レベルAに適合している」などと言う ◦ レベルAAに適合:AA以下の基準(レベルA、AA)を満たすこと ◦ レベルAAAに適合:AAA以下の基準(レベルA、AA、AAA、つまり全 て)を満たすこと。最も難しく、a11yが高いWebコンテンツだとみなさ れる
  23. 63

  24. コントラスト(AA) • テキスト*1 ◦ ⭕サイズの大きなテキストに3:1以上のコントラスト比がある ◦ ⭕そうでないテキストに4.5:1以上のコントラスト比がある ◦ サイズの大きなテキスト*2 ▪

    英語の場合:約24px以上の通常の文字、または約18.6px以上の太字 ▪ 日本語の場合:約29px以上の通常の文字、または約24px以上の太字 • ⭕非テキスト:以下について、隣接する色に3:1以上のコントラスト比がある*3 ◦ ユーザーインターフェースコンポーネント*4、およびその状態の特定 ◦ コンテンツを理解するのに必要なグラフィック 82 *1:達成基準 1.4.3 コントラスト (最低限)、*2:サイズの大きなテキスト、*3:達成基準 1.4.11 非テキストのコントラスト、*4:単一のコントロールとして利用者が知覚するもの。テキストボックスやラジオボタンが含まれる 1.4.3、1.4.11
  25. 改善例:コントラスト(2/4) • H2のスタイルを修正する 87 参考:テキスト (及び文字画像) とその背景の間に、少なくとも 3:1 のコントラスト比を確保する diff

    src/styles/common.scss h2 { flex-wrap: wrap; column-gap: 0.5em; width: fit-content; - color: var(--color-accent); + color: var(--color-base);
  26. クイズ:色の使用(回答例) • リンクであることを色だけで伝えている ◦ 周囲のテキストとの十分なコントラストも無い • フォームの必須要素を色だけで伝えている 93 参考:達成基準 1.4.1

    の失敗例 - 色覚なしで視覚的にはっきりと分からないリンクを作成する、達成基準 1.4.1 の失敗例 - 色の違いだけで、必須又はエラーフィールドを特定している
  27. 改善例:色の使用(1/2) • リンクに下線をつける 94 参考:文字色の違いが情報を伝えるために使用される場合に、利用可能な追加の視覚的な手がかりを確保する diff src/styles/footer.scss - a {

    - text-decoration: none; - } diff src/styles/nav.scss font-size: 3rem; - text-decoration: none; diff src/styles/works.scss position: relative; display: block; min-width: 400px; - text-decoration: none; diff src/styles/service.scss display: block; padding: 10px 50px 10px 20px; max-width: 500px; - text-decoration: none;
  28. ターゲットのサイズ • ⭕ポインタ入力のターゲットのサイズが44 × 44px以上である(AAA) • ⭕ポインタ入力のターゲットのサイズが24 × 24px以上である(AA) •

    ただし、いくつか例外ケースがある*1 ◦ 同じ機能の大きいボタンがある ◦ インラインである:リンク、文中のボタンなど ◦ ブラウザが提供する機能をそのまま使っている 98 *1:ここに記載した以外にも例外のケースがある。詳しくはWCAGを参照 2.5.5、2.5.8
  29. 改善例:リフロー、ターゲットのサイズ • min-widthを削除する • ボタンを大きくする 100 diff src/styles/works.scss a {

    position: relative; display: block; - min-width: 400px; diff src/index.html - <button type="button">送信</button> + <button type="button">アンケートを送信</button> diff src/styles/campaign.scss button { display: block; width: fit-content; + padding: 1em;
  30. コラム:どんな人がキーボードでWebを閲覧する? • ぼく(特に障がいなし) ◦ できるだけキーボードから手を離したくないと思ったとき ◦ うまくポインティングできないとき ▪ 例)ノートPCのトラックパッドの精度が悪い ▪

    例)揺れる乗り物のうえでPCを使っている ▪ 例)腕を怪我している ▪ 例)マウスを使うスペースがない • 障がいによって手、腕の震えがあり、うまくポインティングできない人 • ロービジョンにより、画面上のポインタを見つけたり、目で追ったりするのが困 難な人 102
  31. トレーニング:キーボードでWebページを操作する • フォーカス可能: ◦ 可能:a, button, チェックボックス, ラジオボタン, textareaなど ◦

    不可能:div, span, p, h1など • 次のフォーカス可能な要素にフォーカス:tabまたはoption + tab • 前のフォーカス可能な要素にフォーカス:shift + tabまたはoption + shift + tab • リンクに遷移する:フォーカスを当ててenter • ボタンを押す:フォーカスを当ててspace • チェックボックスを切り替える:フォーカスを当ててspace • ラジオボタンを切り替える:フォーカスを当てて上下左右キー • テキストエリアに入力する:フォーカスを当てて、そのまま文字を入力する • 前 / 次のページに移動:alt + 左右キー 103
  32. トレーニング:キーボードでWebページを操作する:演習 • まずGoogleを開きます • ここからキーボードのみで操作します • 課題1:カレーのWikipediaを表示してみてください • 課題2.1:以下のタイトルのページを表示してみてください ◦

    Checkbox Example (Two State) | APG | WAI | W3C • 課題2.2:そのページ内にあるチェックボックスを操作してみてください • 課題3.1:以下のタイトルのページを表示してみてください ◦ Radio Group Example Using Roving tabindex | APG | WAI | W3C • 課題3.2:そのページ内にあるラジオボタンを操作してみてください 104
  33. クイズ:フォーカスの可視化(回答例) • a, button, inputタグ全般 107 参考:達成基準 2.4.7 の失敗例 -

    視覚的なフォーカスインジケータを除去する又は不可視にするような方法で、要素のアウトライン及びボーダーをスタイル指定する
  34. diff src/styles/common.scss +.focus-indicator { + outline: 2px solid var(--color-accent); +

    outline-offset: 4px; + box-shadow: 0 0 0 8px var(--color-base); +} + +// normalize.cssを上書きするためbuttonを個別に指定する +*, +button[type="button"] { + &:focus-visible { + @extend .focus-indicator; + } +} 改善例:フォーカスの可視化(3/3) • 可視性の良いフォーカスインジケータを独自に実装する 110
  35. 改善例:キーボード操作(1/12) • ラジオボタンの現状 116 label { input[type="radio"] { display: none;

    // もともとのinputは非表示 &:checked { + span { // チェック時のスタイル } } } span { // ここで独自のスタイルを定義 } } display: none;してしまうと、キー ボードや支援技術からも見えなくな り、操作できなくなってしまう
  36. 改善例:キーボード操作(2/12) • 今回やりたいこと:見た目上は隠したいが、支援技術等には引き続き公開したい ◦ これは通称、Visually-Hiddenと呼ばれる ◦ ぱっと見て「visibility: hidden;」と似ているが、混同しないようにする • いろいろな実装方法が考えられるが、今回は以下にあるvisually-hiddenスタイル

    をコピペして使う*1 ◦ WCAGが提供するvisually-hiddenスタイルの例 117 *1:Visually-Hiddenによる実装は理論的には正しいですが、支援技術によっては動作しない場合があるかもしれません。そのため、ターゲットとする技術を使って実際にテストし、動作しない場合は別の実装を行うこともできます。詳しくは「改善例:キーボード操作 (補足)」のスライドを参照してください。
  37. 改善例:キーボード操作(3/12) 118 diff src/styles/common.scss +.visually-hidden { + clip-path: inset(100%); +

    clip: rect(1px, 1px, 1px, 1px); + height: 1px; + overflow: hidden; + position: absolute; + white-space: nowrap; + width: 1px; +} diff src/index.html <div class="radio"> <label> - <input type="radio" name="advantage" value="polite" checked /> + <input + type="radio" + name="advantage" + value="polite" + class="visually-hidden" + checked + /> <span>ヒアリングが丁寧</span> 以降ほかのラジオボタンも同様 *1:Visually Hiddenのスタイルは次を参考にした:https://waic.jp/translations/WCAG21/Techniques/css/C7
  38. 改善例:キーボード操作(6/12) • ナビゲーションメニューの開閉ボタンに関しても同じように修正する 121 diff src/index.html <label class="nav_open"> - <button></button>

    + <button class="visually-hidden"></button> <div>MENU</div> </label> <div class="container"> <label class="nav_close"> - <button></button> + <button class="visually-hidden"></button> <div>CLOSE</div> </label> diff src/styles/nav.scss .nav_open, .nav_close { button { - display: none; + &:focus-visible { + + div { + @extend .focus-indicator; + } + }
  39. 改善例:キーボード操作(11/12) • Dialog要素を使ってナビゲーションメニューを実装してみる 126 diff src/index.html - <div class="container"> +

    <dialog class="container"> - </div> + </dialog> diff src/styles/nav.scss .container { position: fixed; top: 0; left: 0; - display: none; diff src/scripts/nav.js navOpenButton.addEventListener("click", () => { - navContainer.style.display = "block"; + navContainer.showModal(); }); navCloseButton.addEventListener("click", () => { - navContainer.style.display = "none"; + navContainer.close(); });
  40. コラム:どんな人がスクリーンリーダーでWebを閲覧する? • 盲目(79.5% • ロービジョン・視覚障がい(21.9% • 他にも ◦ 認知障がい・学習障がい(3.2% ◦

    運動機能障がい(2.4% ◦ 難聴(7.3% ▪ 注意:スクリーンリーダーはテキストを点字ディスプレイに送信する機 能も持っている ▪ 例:盲目かつ難聴で、スクリーンリーダー + 点字ディスプレイを使用 136 参考:https://webaim.org/projects/screenreadersurvey9/#disabilitytypes
  41. トレーニング:スクリーンリーダーの操作(VoiceOver)1 • VoiceOverのオン/オフ:以下のいずれか ◦ command + F5 ◦ command +

    Touch IDを素早く3回 ◦ システム環境設定 > アクセシビリティ > VoiceOver > VoiceOverを有効に するチェックボックス • フォーカスの操作は同じ ◦ フォーカスを移動すると、そこを読み上げる • テキストをマウスで選択すると、そこを読み上げる 141
  42. トレーニング:スクリーンリーダーの操作(VoiceOver)2 • VOキー:以下のいずれか ◦ CapsLock ◦ control + option •

    次を読み上げ:VO + → • 前を読み上げ:VO + ← • 領域に入る / 出る:VO + shift + ↓ / ↑ 142
  43. トレーニング:スクリーンリーダーの操作(VoiceOver)3 • 見出しやリンク、ランドマークの一覧を見る:VO + u ◦ さらに、 ▪ 一覧を切り替え:左右キー ▪

    項目を移動:上下キー ▪ 項目を選択:enter ▪ 閉じる:esc • ヘルプ:VO + h • 注意:WebナビゲーションはDOMモードで統一します ◦ デフォルトはDOMです ◦ 切替方法:ヘルプ > コマンドヘルプ > Web > WebナビゲーションのDOM / グ ループを切り替える 143
  44. クイズ:リンクの目的(回答例) • フッターの「こちら」リンク • サービス内のリンクテキストがおかしい ◦ 例:UIデザイン right_arrow 147 参考:達成基準

    2.4.9 の失敗例 - リンクテキストを具体的なテキストに変更するメカニズムなしで、「ここをクリック」又は「続きを読む」などの不明確なリンクを使用している
  45. 改善例:リンクの目的(1/2) • フッターの「こちら」リンク 148 diff src/index.html このサイトはアクセシビリティの学習のために作られました。詳しくは - <a href="https://github.com/sititou70/komaru-corp-a11y">こちら</a>

    + <a href="https://github.com/sititou70/komaru-corp-a11y"> + 当サイトのGitHubリポジトリ + </a> を参照してください 参考:リンクの目的を説明したリンクテキストを提供する
  46. 改善例:リンクの目的(2/2) • サービス内のリンクテキストにalt属性の不適切な値が含まれてしまう問題 • VOのリンク一覧に表示されている文字列は、リンクのアクセシブルネーム ◦ アクセシブルネーム:ユーザーがWebコンテンツの一部を識別するための文 字列 • ある要素のアクセシブルネームは、その子要素から以下の規則で計算される

    ◦ Accessible Name and Description Computation 1.2 • アクセシブルネームをDev Toolsから確認する方法がある • ここでは、子要素である画像のalt属性もアクセシブルネームの計算対象に含ま れ、それが不適切であるためおかしくなっている • 次の改善で同時に修正される 149
  47. 改善例:適切なAlt属性 • アンケート結果のグラフ:Alt属性がない • VOで読み上げてみると「/graph02.jpg ラベルのない画像」となってしまう。こ れではアンケート結果が利用者に伝わらない • 基本的に、画像にある文字をそのままAlt属性に書けば良い 151

    diff src/index.html - <img src="/assets/graph2.jpg" /> + <img + src="/assets/graph2.jpg" + alt="満足:70% 不満:30%" + /> 参考:達成基準 1.1.1 の失敗例 - img 要素、area 要素、及び type "image" の input 要素の alt 属性又はテキストによる代替を省略している
  48. 改善例:適切なAlt属性 • サービスのリンク内にあるアイコン画像:Alt属性が不適切 ◦ 「right_arrow」と読み上げられても困る • これは純粋な装飾画像なので無視したい ◦ alt=””と書く ◦

    属性自体の省略はできないことに注意 152 diff src/index.html - <img src="/assets/right_arrow.svg" alt="right_arrow" /> + <img src="/assets/right_arrow.svg" alt="" /> 参考:支援技術が無視すべき画像に対して、img 要素の alt テキストを空にして、title 属性を付与しない
  49. 改善例:適切なAlt属性 • 制作実績のリンク内の画像:Alt属性がない • →画像に含まれるテキストはすでにリンク内に存在するためalt=””とする ◦ もし「alt=”五百年の歴史と共に 駒瑠神社”」としたとすると ◦ リンクテキストは「ホームページ制作

    五百年の歴史と共に 駒瑠神社 五百年 の歴史と共に 駒瑠神社 公式サイト」と冗長になってしまう • クイズ:以下のように、もし画像が単独でリンクなら?(時間:30秒) 153
  50. 改善例:適切なAlt属性 • 制作実績のリンク内の画像:Alt属性がない • →画像に含まれるテキストはすでにリンク内に存在するためalt=””とする ◦ もし「alt=”五百年の歴史と共に 駒瑠神社”」としたとすると ◦ リンクテキストは「ホームページ制作

    五百年の歴史と共に 駒瑠神社 五百年 の歴史と共に 駒瑠神社 公式サイト」と冗長になってしまう • クイズ:もし画像が単独でリンクなら? ◦ →「alt=”五百年の歴史と共に 駒瑠神社”」とすべき ◦ 「alt=””」だと、リンクテキストが空になってしまう • 全体としてどうなれば自然か?を意識しましょう 154
  51. クイズ:適切な見出し(回答例) • 「先月のアンケート結果」見出しが一覧に表示されない • 「 注意:お電話のかけ間違いが多くなっております。十分ご注意ください」が見 出しとして表示されてしまう 158 参考:達成基準 1.3.1

    の失敗例 - コンテンツにおける関係を表さない方法で、構造的なマークアップを使用している、達成基準 1.3.1 の失敗例 - 情報を伝えるために、適切なマークアップ又はテキストを用いずに、テキストの提示の変化を使用している
  52. 改善例:適切な見出し • 「先月のアンケート結果」見出し ◦ 見出し要素ではなくspanにスタイルを当てたものだった ◦ したがってVOの見出し一覧に現れなかった 159 diff src/index.html

    - <span class="result">先月のアンケート結果</span> + <h3>先月のアンケート結果</h3> diff src/styles/campaign.scss - .result { - font-size: 1.2rem; - font-weight: bold; - } 参考:見出しを特定するために、h1 要素~ h6 要素を使用する
  53. 改善例:適切な見出し • 「 注意:お電話のかけ間違いが多くなっております。〜〜」見出し ◦ 文章を強調するためにh3要素を使っていた ◦ strong要素を使うように修正する 160 diff

    src/index.html - <h3> + <strong> 注意:お電話のかけ間違いが多くなっております。十分ご注意ください - </h3> + </strong> 参考:構造をマークアップするために、セマンティックな要素を使用する
  54. コラム:見出しの重要性 • How Users Read on the Web の調査によれば、ほとんどの ユーザーはWebページを流し

    読みしている • Screen Reader User Survey #9 Resultsによれば、ユー ザーは見出しによるナビゲー ションをよく使う。これはラ ンドマークやページ内検索よ りも高い割合 162 グラフの出典:https://webaim.org/projects/screenreadersurvey9/#finding
  55. 改善例:適切なラベル • 氏名の入力:可視ラベルとアクセシブルネームが一致していない 165 diff src/index.html - 氏名:<input name="name" />

    + <label> + <span>氏名:</span> + <input name="name" /> + </label> 参考:アクセシブルな名前 (accessible name) を視覚的なラベルと一致させる
  56. 改善例:適切なラベル • 電話番号の入力:それぞれのinputに適切な可視ラベルがない ◦ 直前のテキストが可視ラベルだとすると、tel2とtel3のラベルは「-」という ことになってしまう • テキストボックスを1つにして、続けて入力してもらうようにする 166 diff

    src/index.html - <input name="tel1" required="required" /> - - <input name="tel2" required="required" /> - - <input name="tel3" required="required" /> + <p>ハイフン・スペース無し、半角数字</p> + <input name="tel" required="required" /> diff src/styles/campaign.scss - .tel { - input { - width: 3em; - } - } + p { + margin: 0; + } 参考:達成基準 3.3.2 の失敗例 - 電話番号のフィールド一式を視覚的にフォーマットしているが、テキストラベルを含んでいない
  57. 入力目的の特定 • ⭕適切なautocomplete属性を使用している • これにより ◦ ブラウザは情報を自動入力できるようになる ▪ 特に、言語や記憶、運動に関して障がいのある人に役立つ ◦

    例えば、autocomplete="tel"の要素の前に電話のアイコン「📠」を表示す る支援技術を利用できる ▪ 一部の利用者は、コミュニケーションに画像を使用するのを好む場合が ある 168 1.3.5
  58. 改善例:入力目的の特定 169 diff src/index.html - <input name="name" /> + <input

    name="name" autocomplete="name" /> - <input name="tel" required="required" /> + <input name="tel" required="required" autocomplete="tel" />
  59. 改善例:アニメーションの抑制 • ヒーローヘッダーの背景動画:停止させるコントロールを作る 172 diff src/index.html <script src="/scripts/nav.js" defer></script> +

    <script src="/scripts/hero.js" defer></script> <div class="word2">Everyone</div> </div> + <button type="button" class="stop">STOP</button> diff src/scripts/hero.js +const bgVideo = document.querySelector(".hero .bg"); +const stopButton = document.querySelector(".hero .stop"); + +stopButton.addEventListener("click", () => { + bgVideo.pause(); +});
  60. 改善例:アニメーションの抑制 • ヒーローヘッダーの背景動画:停止させるコントロールを作る 173 diff src/styles/hero.scss + button { +

    position: absolute; + right: 10px; + bottom: 10px; + padding: 0.7em 1em; + border: 2px solid var(--color-text); + } 参考:動きのあるコンテンツ、点滅するコンテンツ、又は自動更新するコンテンツを停止させるコントロールを使用する
  61. 改善例:アニメーションの抑制 • 制作実績のリンク:スクロールするとアニメーションが実行される • prefers-reduced-motionで抑制できるようにする 174 diff src/styles/works.scss +@media (prefers-reduced-motion)

    { + @keyframes appear { + } +} diff src/styles/works.scss &.is-displayed { animation: appear 0.5s both ease; } + @media (prefers-reduced-motion) { + opacity: 1; + } 参考:モーションの防止に CSS reduce-motion クエリを使用する
  62. Evaluation Tools:自動評価ツール • HTML / CSSバリデータ:基本的な構文等を検査 • Axe(Deque社) ◦ 平均して、WCAG全体の57%の問題点を自動的に発見可能とされる*1

    ◦ 以下のツールで内部的に利用されている ▪ Lighthouse ▪ storybook-addon-a11y ▪ eslint-plugin-jsx-a11y ▪ Accessibility Insights for Web • WAVE(WebAIM Community) • IBM Equal Access Toolkit(IBM社) • Firefox A11yインスペクターのチェック機能(Mozilla社) 178 *1:axe-coreのREADMEより
  63. 自動チェックツールだけでは十分でない • 例:Alt属性 ◦ ツールは「Alt属性が設定されていない」ことを検出できる ◦ しかし、「Alt属性にどのような値を設定すればいいか」はわからない ▪ 装飾画像なら:空文字 ▪

    文字列を含むなら:その文字列 ▪ etc…… ◦ →「その画像がどのような意図を持つか」は人間にしかわからない • (余裕があれば)badブランチをチェックアウトして、自動チェックツールを実 行してみましょう ◦ 今日見てきた問題点はすべて検出されましたか? • 自動チェックと手動チェックを組み合わせるのが大事 179
  64. a11yをテストコードでも活用する • 現状のテストコード 181 it("ナビゲーションメニューを開ける", () => { cy.visit("/"); //

    画面上に表示されていないボタンをクリックするためにforceが必要 cy.get(".nav_open button").click({ force: true }); cy.get(".navigation .container").should("have.css", "display", "block"); }); it("アンケート:氏名は任意要素", () => { cy.visit("/"); cy.get(".campaign form input[name=name]").should("not.have.attr", "required"); });
  65. a11yをテストコードでも活用する • ロールやアクセシブルネームを使った書き方に変えてみる 182 - cy.get(".nav_open button").click({ force: true });

    + cy.findByRole("button", { name: /MENU/i }).click({ force: true }); - cy.get(".navigation .container").should("have.css", "display", "block"); + cy.findByRole("dialog", { name: /MENU/i }).should("have.attr", "open"); - cy.get(".campaign form input[name=name]").should("not.have.attr", "required"); + cy.findByRole("textbox", { name: /氏名/i }).should( + "not.have.attr", + "required" + ); →class名やDOM構造に依存するよりも堅牢に
  66. a11yをテストコードでも活用する • 改善後 183 it("ナビゲーションメニューを開ける", () => { cy.visit("/"); //

    画面上に表示されていないボタンをクリックするためにforceが必要 cy.findByRole("button", { name: /MENU/i }).click({ force: true }); cy.findByRole("dialog", { name: /MENU/i }).should("have.attr", "open"); }); it("アンケート:氏名は任意要素", () => { cy.visit("/"); cy.findByRole("textbox", { name: /氏名/i }).should( "not.have.attr", "required" ); }); →a11yの改善によって、テストコードからも コンテンツにアクセスしやすくなった
  67. まとめ:今日は以下のことを学びました • アクセシビリティの ◦ 定義:access + ability ◦ 重要性 ▪

    アクセスできない / しにくい人を減らすため ▪ SEO対策のため ▪ さまざまなデバイスに対応するため ▪ UX改善のため ▪ etc…… ◦ 基準・ガイドライン:WCAG 2.2 ◦ 改善・検証方法:コードを書いて学んだ 186
  68. 187 The power of the Web is in its universality.

    Access by everyone regardless of disability is an essential aspect. Webの優れている点は、その普遍性にあります。 障がいの有無によらず誰でもアクセスできることが、Webの本質的な側面です。 Tim Berners-Lee, W3C Director and inventor of the World Wide Web →誰でも使えるWebを作っていきましょう!
  69. 参考文献 • Web Content Accessibility Guidelines (WCAG) 2.1 • デザイニングWebアクセシビリティ

    - アクセシブルな設計やコンテンツ制作のア プローチ • Form Design Patterns - シンプルでインクルーシブなフォーム制作実践ガイド • ウェブアクセシビリティ導入ガイドブック、デジタル庁 188