手を動かして始めるアクセシビリティ改善

Hatena Engineer Seminar #25 アクセシビリティ編
https://hatena.connpass.com/event/283800/

Google Slide: https://docs.google.com/presentation/d/1etZBl-yKEEffqGYODdj4hIhPZXKNS8XOGraTUkevno0/edit?usp=sharing

Transcript

1. 手を動かして始める アクセシビリティ改善 id:Pasta-K / @pastak 2023/06/06 Hatena Engineer Seminer #25 アクセシビリティ編 1
2. About me • id:Pasta-K • mackerel チーム Webアプリケーションエン ジニア(パートタイム) ◦ 主にフロントエンド周りのあれこれを担当 2
3. PR: Helpfeel Tech Hour vol.3 「アクセシビリティを始めたい！編」 僕が所属しているもう1つの会社でもオフラインで アクセシビリティの話をする会をやります！ 2023年6月16日(金)東京 銀座で開催！ 3 https://nota.connpass.com/event/284361/
4. このトークで話すこと ここまでのトークではチームでのアクセシビリ ティの改善の進め方や取り組みについて紹介し ました。 このトークでは、手の動かしはじめ方につい て、mackerelチームの開発合宿などで取り組ん だ実例を交えつつお話します。 4
5. 手を動かして改善を始める • 啓発のために実際に手を動かして、改善の様 子を見せたい • 気持ちが高まったので、とにかく改善できる ところからやってみたい 5
6. どこから手をつけ始めれば良いか • 動的解析 ◦ 実際のウェブページにブラウザでアクセスして問題点 を発見する • 静的解析 ◦ ESLintのeslint-plugin-jsx-a11yなどを利用してコー ドから問題点を発見する 6
7. 動的解析: ウェブページを色んな方法で 触ってみる • キーボード操作のみで • 画面を暗くして読み上げソフトと共に • ブラウザの翻訳機能を介して 7
8. • キーボード操作のみで • 画面を暗くして読み上げソフトと共に • ブラウザの翻訳機能を介して • スマートフォンを回転させて見る • タブレット端末で 8 動的解析: ウェブページを色んな方法で 触ってみる
9. • キーボード操作のみで • 画面を暗くして読み上げソフトと共に • ブラウザの翻訳機能を介して • スマートフォンを回転させて見る • タブレット端末で 9 動的解析: ウェブページを色んな方法で 触ってみる
10. 動作確認: ウェブページを色んな方法で 触ってみる • キーボード操作のみで • 画面を暗くして読み上げソフトと共に • ブラウザの翻訳機能を介して • スマートフォンを回転させて見る • タブレット端末で 10
11. 「アクセシビリティ」は 特別なことではない • 色んなユーザーが色んな使い方をすることを 想定してウェブページを触ってみる • そうしたユースケースに対して適切なアクセ ス方法を提供する • 結果的にアクセシビリティと呼ばれる観点の 向上に繋がる 11
12. 色んなユーザーの例 • マウスが壊れて、キーボード を使うしかなくなった • 骨折して腕が一時的に使えな くなった • スマートフォンの画面が割れ て液晶が映らなくなった • 視力が低い・見えない 12 • イヤホンを忘れて、音声を再 生できない • 日本語を理解できない • 小さい字が読めない • ギガを使いすぎて通信制限に あった • 色覚特性を有している
13. あらゆる人に利用可能で快適な ウェブサービスを目指す • これ自体は何も特別なことではないはず • SaaSやBtoCどんなパターンでもエンドユー ザーの中で「利用困難」な人が居ると、我々 のサービスが選択されなくなってしまう ◦ 操作性が悪いなどで使い辛いだけなら、利用はできる ▪ ユーザーの操作性を凝ることよりも重要なのでは？ 13
14. 14 閑話休題 アクセシビリティ改善にどこから手をつけるかに話題を戻しましょう
15. では、どこから手をつけ始めるか • 動的解析 ◦ 実際のウェブページにブラウザでアクセスして問題点 を発見する (今日の発表はこのアプローチに注目) • 静的解析 ◦ ESLintのeslint-plugin-jsx-a11yなどを利用してコー ドから問題点を発見する 15
16. よくあるパターンに当てはめてみる • Tabキーでフォーカスの様子がどうなるか • VoiceOverで読み上げの様子がどうなるか • 文字やUIなどの色のコントラストはどうか 16
17. よくあるパターンに当てはめてみる • Tabキーでフォーカスの様子がどうなるか • VoiceOverで読み上げの様子がどうなるか • 文字やUIなどの色のコントラストはどうか 17
18. Tabキーを押すとどうなるか 素朴にTabキーを連打して、フォーカスの様子を 観察してみる 18
19. 素朴にTabキーを連打すると 気付くことの例 • どこにフォーカスが当たっているか不明 • フォーカスの当たる順番が予想に反する • そもそもフォーカス出来ない要素がある • 主要な操作要素にたどり着くまでが遠い 19
20. 素朴にTabキーを連打すると 気付くことの例 • どこにフォーカスが当たっているか不明 • フォーカスの当たる順番が予想に反する • そもそもフォーカス出来ない要素がある • 主要な操作要素にたどり着くまでが遠い 20
21. フォーカスリング • フォーカスの可視化(*)をして、キーボード フォーカスを 持っている要素を利用者が認識しやすくするためのアプ ローチの1つ • フォーカス可能な要素にはブラウザ標準でフォーカスリ ングが表示されるようになっているが、 CSS で outline: none; を指定していて、非表示に なっていることもしばしば。 21 ※ 達成基準 2.4.7: フォーカスの可視化を理解する https://waic.jp/translations/WCAG21/Understanding/focus-visible.html
22. フォーカスリングを復活させる • 消滅してしまっている場合は、:focus や :focus-visible などを利用して、 outline: auto;を適用するようにする。 • 見た目の良さの観点で消されていることも多い が、どう表示するか・何故表示するかという観点 で色や見せ方について再考出来ると良い 22
23. 素朴にTabキーを連打すると 気付くことの例 • どこにフォーカスが当たっているか不明 • フォーカスの当たる順番が予想に反する • そもそもフォーカス出来ない要素がある • 主要な操作要素にたどり着くまでが遠い 23
24. フォーカスの当たる順番を 可視化する Firefox開発者ツールのアクセシビリティ機能や Chromeの拡張機能(taba11y(*))で可視化して みる 24 ※ https://chrome.google.com/webstore/detail/taba11y/aocppmckdocdjkphmofnklcjhdidgmga
25. フォーカスを可視化した例 25
26. tabIndexの値を調整する • tabIndex属性に-1 or 0以外の値を設定しない ようにする • ESLintのjsx-a11y/tabindex-no-positive で 検出するなどして、tabIndexが1より大きい ものを削除して、DOMツリー順になるように ◦ mackerel開発合宿での最強の値は10001でした 26
27. tabIndexの値を調整する • DOMツリー順と見た目が異なる場合は、ここ で調整などが発生するかもしれないが、 mackerelの場合はそういったことがなかった ので、サクサクと変更できた 27
28. 素朴にTabキーを連打すると 気付くことの例 • どこにフォーカスが当たっているか不明 • フォーカスの当たる順番が予想に反する • そもそもフォーカス出来ない要素がある • 主要な操作要素にたどり着くまでが遠い 28
29. クリック可能な要素をフォーカス可能に • そもそもとして、onClickなどのハンドラー を設定する際には、基本的には<button>を 使うようにすることで解消する ◦ リンクがある場合は<a>を利用する • jsx-a11y/no-noninteractive-element-to-i nteractive-roleで検出できる 29
30. <button>のデフォルトCSSを 無効化 <button>が使われていないと き、その原因は見た目に起因 していることが多い。 <button>のブラウザのデフォ ルトCSSを無効に出来るクラ スなどを用意することで脱出 を容易に出来る 30
31. 素朴にTabキーを連打すると 気付くことの例 • どこにフォーカスが当たっているか不明 • フォーカスの当たる順番が予想に反する • そもそもフォーカス出来ない要素がある • 主要な操作要素にたどり着くまでが遠い 31
32. 主要な操作要素までの距離が遠い • ヘッダーやサイドバーの要素の数だけTab キーを押さないとメイン部分にフォーカスが 移行しない 32
33. スキップリンクの活用例: Github Tabキーでフォーカスを操作し始めると、最初に 「Skip to content」と書かれた要素にフォーカ スする（「スキップリンク」と呼ばれる） 33
34. スキップリンクを実装する • 素朴にやるなら、メインコンテンツの始まる 要素に id="start-of-content" を付与し て、Skip to Content要素を <a href=”#start-of-content”>と すれば良い 34
35. Mackerel開発合宿での事例 • URLのhash部分を使って画面の 切り替えを実装している画面が あった • どうするかディスカッションをし て、JavaScriptで最初にフォーカ ス可能な要素にフォーカスするの が良いんじゃないかということに 35
36. ランドマークロールを利用する • スクリーンリーダーのユーザーなどがウェブ ページの重要な領域などを確認したり、それ らに素早く到達するための構造化の方法 • 暗黙のロールを持つタグやrole属性を用いて 表現できる 36
37. ランドマークロールと それらに対応するHTML要素 main <main> navigation <nav> region <section> search <search> (*) 37 基本的にはランドマークロールを持つHTMLタグを使えば良 い(右側)が、role属性を付与すること(左側)でも同様の情報 を付与できる banner <header> complementary <aside> contentinfo <footer> form <form> ※ 2023/06/01時点では<search>をサポートしているブラウザはない
38. ランドマークロールと スキップリンク • 読み上げソフトのランドマークロールを扱う 機能などを使えばスキップリンクは不要？ • 2022年の支援技術利用状況調査報告書(*)で はスキップリンクを「よく使う」「時々使 う」と答えた人はほぼ80% 38 ※ https://jbict.net/survey/at-survey-02
39. 動的解析についての補足 • axeやlighthouseなどのツールを利用するこ とでこれらの検出は自動化出来たりもします ◦ まずは自分の手で触ってみて、違和感への感覚を得る 39
40. 40 まとめ
41. まずは出来ることから始める • ブラウザでウェブサイトにアクセスして発見 する ◦ キーボードを用いてフォーカスを移して操作可能か ◦ 色のコントラストは適切か ◦ 読み上げは可能か ▪ <img>のalt属性や各種labelなどは適切か 41
42. まずは出来ることから始める • ESLintなどで静的に発見する ◦ 動的に発見したものを潰せる設定を入れる ◦ 全部有効にしてみてリスト化してみる ▪ その後、ルールを1つずつ有効にする ◦ 関心のあるルール / (サービスとしての)重要度の高い ルールから有効にしてみる 42
43. まずは出来ることから始める • アクセシビリティ改善は0 or 100ではない • 改善できることがあるならそれはチャンスで しかない • 少しずつでも改善して成果を出すことが周り を巻き込むことやウェブサービスを利用でき る人を増やすことに必ず繋がる 43
44. 手を動かして改善する • ウェブサービスを提供する上で、手を動かなさい ことにはウェブサービスのアクセシビリティが改 善されることはない • サービスの重要なところはUIが複雑だったりし て、いきなり取り掛かるのは難しいことも多い ◦ 気負いすぎずに、まずは改善できるところから徐々に取り 組んでいくで良いのではないかと思います ◦ まずは取り組むハードルを下げて関わる人を増やす 44
45. Thanks for your listening • 是非、まずは出来ることからアクセシビリ ティ改善を始めてみてください • 今日紹介したような一歩から始めて、こつこ つと少しずつの積み重ねでウェブサービスの アクセシビリティの改善を続けていきます 45