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

Webアクセシビリティ入門

Avatar for Recruit Recruit PRO
August 10, 2023

 Webアクセシビリティ入門

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

Avatar for Recruit

Recruit PRO

August 10, 2023
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フロントエンドの設計や実装 • 好きなもの:アクセシビリティ ◦ 勉強したり ▪ 本 / ガイドラインを読む*1 ◦ チームに布教したり ▪ レビュー / テスト整備 / ドキュメント作成 • よろしくお願いします 4 *1:失敗例で学ぶアクセシビリティ(WCAG 2.1) フローリングの アイコンが私
  3. 定義 • accessibility = access + ability • accessibility =

    アクセス + できること(またはその程度のこと) • a11yと略される ◦ aとyの間に文字が11個あるから 7 参考:ウェブアクセシビリティ導入ガイドブック, デジタル庁, 2022。以降の出典ではタイトルだけ記載
  4. 重要性:なぜa11yを改善すべきなのか? • 代表的なものをピックアップして紹介します ◦ アクセスできない / しにくい人を減らすため ◦ SEO対策のため ◦

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

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

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

    陽の光が眩しくて画面の色を認識しづらい ◦ 高齢になり、最近目が悪くなってきた ▪ →コントラストが強く、文字が大きいほうが良い ◦ 電車が揺れてスマホでポインティングが難しい ▪ →ボタンが大きめだとうれしい ◦ 一時的に腕を怪我していてマウスが使えない ◦ マウスを使うだけのスペースが無い、またはマウスを忘れてきた ◦ 単純にキーボード操作が好き(例:エンジニアなど、つまり僕) ▪ →キーボードで操作できると良い 12
  8. さまざまなデバイスに対応するため • a11yの基準を守っていると、特殊なデバイスにも対応できる場合がある • 達成基準 2.5.5 ターゲットのサイズ:ボタンやリンクなど、ポインタのターゲットが一定より も大きいこと ◦ →ポインティングが普通より難しいデバイスに対応

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

    *2 • 例2:alt属性 ◦ SEO:「画像に alt 属性を指定」することで「ユーザーが目的のコンテンツを見つけやすくな る」*3 ◦ a11y:「利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たすテキ ストによる代替が提供されている」*4 ▪ 非テキストコンテンツ:画像など ▪ テキストによる代替:alt属性など 14 *1:最適なタイトルリンクを出しやすくするためのベストプラクティス, Google。*2:WCAG 達成基準 2.4.2 ページタイトル, W3C。*3:Google 画像検索 SEO ベストプラクティス, Google。*4:WCAG 達成基準 1.1.1 非テキストコンテンツ, W3C
  10. UXの例(1/5):アクセスしやすい • 例:「私」は、自宅のプリンター(型番:PRT-12345-67)が壊れてしまったので解決策を探 したい • 私はまず、検索エンジンで「PRT-12345-67 説明書」を調べた • 「取扱説明書 |

    マニュアル | PRT-12345-67 - 製造会社」というタイトルのサイトが真っ先 にヒットした • 目的に合致するページが見つかったので、それにアクセスした 19
  11. UXの例(2/5):アクセスしやすい • title要素が適切でない例 ◦ 「新しいドキュメント」というtitle ▪ 何のページかわからない ◦ 「PRT-12345-67 -

    製造会社」というページが複数ある ▪ どれにアクセスすればいいかわからない ▪ 目的のページにたどり着くまで時間がかかる • →今回はtitle要素が具体的でわかりやすかったため、アクセスしやすかった 20
  12. Web a11yの全体像 • W3Cによれば、以下の全てのコンポーネントが連携して動作することが重要 31 出典:Essential Components of Web Accessibility

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

    支援技術 例:スクリーンリーダー、点字ディスプレイ、そ の他の特別な入力 / 出力装置…
  14. WCAGの歴史:WCAG 2.0 • 2008-12-11勧告 ◦ 1.0の勧告から約8.5年 • 構造を刷新 • より現代的なWebの環境に対応

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

    • 標準化 ◦ ISO/IEC 40500:2012と互換 ◦ JIS X 8341-3:2016と互換 ▪ →「やさしい(8341)」の語呂合わせらしいです 45
  16. WCAGの歴史:WCAG 3.0(作成中) • 完成はあと数年後 ◦ リポジトリのコミットを見る限り、2018-04頃から作成に取り掛かっていた様子*1 ▪ WCAG 2.1勧告のちょっと前 •

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

    操作可能 ◦ 理解可能 ◦ 堅牢 • 今回の場合だと、「知覚可能」を見れば良さそう 51 *1:以降は、WCAG 2.1の場合の話で、他のバージョンには当てはまらない場合があります
  18. • 55 • レベルA:基準の分類。より優先して満たすべき重要な基準は A。次にAA、AAAと続 く。 • 適合レベル ◦ レベルAに適合:全てのレベルAの基準を満たすこと。「このサイトは

    WCAG 2.1 レベルAに適合している」などと言う ◦ レベルAAに適合:AA以下の基準(レベルA、AA)を満たすこと ◦ レベルAAAに適合:AAA以下の基準(レベルA、AA、AAA、つまり全て)を満た すこと。最も難しく、a11yが高いWebコンテンツだとみなされる
  19. コントラスト(AA) • テキスト*1 ◦ ⭕サイズの大きなテキストに3:1以上のコントラスト比がある ▪ サイズの大きなテキスト*2 • 英語の場合:約24px以上の通常の文字、または約18.6px以上の太字 •

    日本語の場合:約29px以上の通常の文字、または約24px以上の太字 ◦ ⭕そうでないテキストに4.5:1以上のコントラスト比がある • 非テキスト:以下について、隣接する色に3:1以上のコントラスト比がある*3 ◦ ⭕ユーザーインターフェースコンポーネント*4、およびその状態の特定 ◦ ⭕コンテンツを理解するのに必要なグラフィック 69 *1:達成基準 1.4.3 コントラスト (最低限)、*2:サイズの大きなテキスト、*3:達成基準 1.4.11 非テキストのコントラスト、*4:単一のコントロールとして利用者が知覚するもの。テキストボックスやラジオボタンが含まれる 1.4.3、1.4.11
  20. 改善例:コントラスト(2/4) • H2のスタイルを修正する 75 参考:テキスト (及び文字画像) とその背景の間に、少なくとも 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);
  21. クイズ:色の使用(回答例) • リンクであることを色だけで伝えている ◦ 周囲のテキストと十分なコントラストも無い • フォームの必須要素を色だけで伝えている 81 参考:達成基準 1.4.1

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

    - text-decoration: none; - } diff src/styles/nav.scss font-size: 3rem; - text-decoration: none; span { diff src/styles/works.scss a { position: relative; - text-decoration: none; diff src/styles/service.scss display: block; padding: 10px 50px 10px 20px; max-width: 500px; - text-decoration: none;
  23. ターゲットのサイズ • ⭕ポインタ入力のターゲットのサイズが44 × 44px以上である • ただし以下のような場合は例外 ◦ 同じ機能の大きいボタンがある ◦

    インラインである:リンク、文中のボタンなど ◦ ブラウザが提供する機能をそのまま使っている 85 2.5.5
  24. 改善例:リフロー、ターゲットのサイズ • min-widthを削除する • ボタンを大きくする 87 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;
  25. コラム:どんな人がキーボードでWebを閲覧する? • ぼく(特に障がいなし) ◦ できるだけキーボードから手を離したくないと思ったとき ◦ うまくポインティングできないとき ▪ 例)ノートPCのトラックパッドの精度が悪い ▪

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

    不可能:div, span, p, h1など • 次のフォーカス可能な要素にフォーカス:tabまたはoption + tab • 前のフォーカス可能な要素にフォーカス:shift + tabまたはoption + shift + tab • リンクに遷移する:フォーカスを当ててenter • ボタンを押す:フォーカスを当ててspace • チェックボックスを切り替える:フォーカスを当ててspace • ラジオボタンを切り替える:フォーカスを当てて上下左右キー • テキストエリアに入力する:フォーカスを当てて、そのまま文字を入力する • 前 / 次のページに移動:alt + 左右キー 90
  27. トレーニング:キーボードで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:そのページ内にあるラジオボタンを操作してみてください 91
  28. 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) • 可視性の良いフォーカスインジケータを独自に実装する 97
  29. 改善例:キーボード操作(1/12) • ラジオボタンの現状 103 label { input[type="radio"] { display: none;

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

    ペして使う*1 ◦ WCAGが提供するvisually-hiddenスタイルの例 104 *1:Visually-Hiddenによる実装は理論的には正しいですが、支援技術によっては動作しない場合があるかもしれません。そのため、ターゲットとする技術を使って実際にテストし、動作しない場合は別の実装を行うこともできます。詳しくは「改善例:キーボード操作 (補足)」のスライドを参照してください。
  31. 改善例:キーボード操作(3/12) 105 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> 以降ほかのラジオボタンも同様
  32. 改善例:キーボード操作(6/12) • ナビゲーションメニューの開閉ボタンに関しても同じように修正する 108 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; + } + }
  33. 改善例:キーボード操作(11/12) • Dialog要素を使ってナビゲーションメニューを実装してみる 113 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(); });
  34. コラム:どんな人がスクリーンリーダーでWebを閲覧する? • 盲目(79.5% • ロービジョン・視覚障がい(21.9% • 他にも ◦ 認知障がい・学習障がい(3.2% ◦

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

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

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

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

    2.4.9 の失敗例 - リンクテキストを具体的なテキストに変更するメカニズムなしで、「ここをクリック」又は「続きを読む」などの不明確なリンクを使用している
  39. 改善例:リンクの目的(1/2) • フッターの「こちら」リンク 135 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> を参照してください 参考:リンクの目的を説明したリンクテキストを提供する
  40. 改善例:リンクの目的(2/2) • サービス内のリンクテキストにalt属性の不適切な値が含まれてしまう問題 • VOのリンク一覧に表示されている文字列は、リンクのアクセシブルネーム ◦ アクセシブルネーム:ユーザーがWebコンテンツの一部を識別するための文字列 • ある要素のアクセシブルネームは、その子要素から以下の規則で計算される ◦

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

    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 属性又はテキストによる代替を省略している
  42. 改善例:適切なAlt属性 • サービスのリンク内にあるアイコン画像:Alt属性が不適切 ◦ 「right_arrow」と読み上げられても困る • これは純粋な装飾画像なので無視したい ◦ alt=””と書く ◦

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

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

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

    の失敗例 - コンテンツにおける関係を表さない方法で、構造的なマークアップを使用している、達成基準 1.3.1 の失敗例 - 情報を伝えるために、適切なマークアップ又はテキストを用いずに、テキストの提示の変化を使用している
  46. 改善例:適切な見出し • 「先月のアンケート結果」見出し ◦ 見出し要素ではなくspanにスタイルを当てたものだった ◦ したがってVOの見出し一覧に現れなかった 146 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 要素を使用する
  47. 改善例:適切な見出し • 「 注意:お電話のかけ間違いが多くなっております。〜〜」見出し ◦ 文章を強調するためにh3要素を使っていた ◦ strong要素を使うように修正する 147 diff

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

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

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

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

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

    name="name" autocomplete="name" /> - <input name="tal" required="required" /> + <input name="tal" required="required" autocomplete="tel" />
  53. 改善例:アニメーションの抑制 • ヒーローヘッダーの背景動画:停止させるコントロールを作る 159 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(); +});
  54. 改善例:アニメーションの抑制 • ヒーローヘッダーの背景動画:停止させるコントロールを作る 160 diff src/styles/hero.scss + button { +

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

    { + @keyframes appear { + 100% { + opacity: 1; + clip-path: inset(-1em); + transform: translateX(0); + } + } +} diff src/styles/works.scss &.is-displayed { animation: appear 0.5s both ease; } + @media (prefers-reduced-motion) { + opacity: 1; + } 参考:モーションの防止に CSS reduce-motion クエリを使用する
  56. 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社) 165 *1:axe-coreのREADMEより
  57. 自動チェックツールだけでは十分でない • 例:Alt属性 ◦ ツールは「Alt属性が設定されていない」ことを検出できる ◦ しかし、「Alt属性にどのような値を設定すればいいか」はわからない ▪ 装飾画像なら:空文字 ▪

    文字列を含むなら:その文字列 ▪ etc…… ◦ →「その画像がどのような意図を持つか」は人間にしかわからない • (余裕があれば)badブランチをチェックアウトして、自動チェックツールを実行してみま しょう ◦ 今日見てきた問題点はすべて検出されましたか? • 自動チェックと手動チェックを組み合わせるのが大事 166
  58. a11yをテストコードでも活用する • 現状のテストコード 168 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"); });
  59. a11yをテストコードでも活用する • ロールやアクセシブルネームを使った書き方に変えてみる 169 - 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構造に依 存するよりも堅牢に
  60. a11yをテストコードでも活用する • 改善後 170 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の改善によって、テストコードからも コンテンツにアクセスしやすくなったといえる
  61. まとめ:今日は以下のことを学びました • アクセシビリティの ◦ 定義:access + ability ◦ 重要性 ▪

    アクセスできない / しにくい人を減らすため ▪ SEO対策のため ▪ さまざまなデバイスに対応するため ▪ UX改善のため ▪ etc…… ◦ 基準・ガイドライン:WCAG 2.1 ◦ 改善・検証方法:コードを書いて学んだ 173
  62. 174 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を作っていきましょう!
  63. 参考文献 • Web Content Accessibility Guidelines (WCAG) 2.1 • デザイニングWebアクセシビリティ

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