実践アクセシビリティ in Angularアプリケーション

Transcript

1. 実践アクセシビリティ in Angularアプリケーション 2020.11.04 Kaori Shirahama @ng-japan OnAir #28
2. 自己紹介 • しらはま かおり（@9v9Shira） • フロントエンド エンジニア at 株式会社トレタ • 普段はAngularでWebアプリ作ってる • アクセシビリティやっていきたい
3. 自分たちのプロジェクトの現状 • これから改善を入れていく状態 • キャッチアップしつつ、徐々に実践中
4. 今日の話 • これから改善していきたい方向け • 熟練者の方はより良い方法などあれば教えてください！
5. 今日の話 • 話すこと • 実装、テスト面 • 話さないこと • アクセシビリティとは何か • アクセシビリティはなぜ重要か etc…
6. アクセシビリティ 気にしてますか？
7. どんな風に 取り組んでますか？
8. 取り組みのフロー
9. アクセシビリ ティ に関して知る チーム・組織で 認識を合わせる 実践する テストする 修正する 取り組みフロー 1 2 3 4 5
10. アクセシビリ ティ に関して知る チーム・組織で 認識を合わせる 実践する テストする 修正する 取り組みフロー 1 2 3 4 5 今日はここの話
11. アクセシビリ ティ に関して知る チーム・組織で 認識を合わせる 実践する テストする 修正する 1 2 3 4 5
12. 何に気をつけるべきか？ ・アクセシビリティの方針を決める ・要件定義 ・コンテンツの設計 ・ビジュアルデザイン ・実装 ・テスト
13. 何に気をつけるべきか？ ・アクセシビリティの方針を決める ・要件定義 ・コンテンツの設計 ・ビジュアルデザイン ・実装 ・テスト エンジニアが取り組みやすい このへんのイメトレをしてみた
14. 参考：https://angular.jp/guide/accessibility アクセシビリティガイドライン
15. 実装で気をつけること • ネイティブ要素を使う • ネイティブ要素が使えない場合、aria属性、role属性 を使う • Angular Materialを活用する • ルーティングのフォーカスの制御をする
16. 実装で気をつけること • ネイティブ要素を使う • ネイティブ要素が使えない場合、aria属性、role属性 を使う • Angular Materialを活用する • ルーティングのフォーカスの制御をする
17. ネイティブ要素を使う • メリット • ブラウザがアクセシビリティを担保してくれる • 支援技術でも問題なく使える
18. 実装で気をつけること • ネイティブ要素を使う • ネイティブ要素が使えない場合、aria属性、role属性 を使う • Angular Materialを活用する • ルーティングのフォーカスの制御をする
19. role属性・aria属性を使う • ネイティブ要素が使えない場合、role属性・aria属性を使う • role属性 • コンテンツの役割を明示する • aria属性 • 状態や性質を明示する • キーボード操作は自前実装
20. 実装で気をつけること • ネイティブ要素を使う • ネイティブ要素が使えない場合、aria属性、role属性 を使う • Angular Materialを活用する • ルーティングのフォーカスの制御をする
21. Angular Material を活用する • Angular Material • https://material.angular.io/ • Angular Materialの実装を参考にする • Angular Materialのa11yパッケージを利用する • https://material.angular.io/cdk/a11y/overview • 例）Focus Trap ダイアログ内でフォーカスを循環させたい場合など利用
22. Focus Trap の sample • ng add @angular/material (@angular/cdk だけでもOK) • A11yModuleをインポート (app.module.tsに追加)
23. 実装で気をつけること • ネイティブ要素を使う • ネイティブ要素が使えない場合、aria属性、role属性 を使う • Angular Materialを活用する • ルーティングのフォーカスの制御をする
24. ルーティングのフォーカスを制御する • SPAの場合、リンクをクリックしてもハードリフレッシュは 行われない（=フォーカスの位置が変わらない） • 支援技術ユーザーに新しいコンテンツがページに追加された ことが伝わらない • 参考 • https://web.dev/managed-focus/? utm_source=lighthouse&utm_medium=cli • https://web.dev/managed-focus/? utm_source=lighthouse&utm_medium=cli
25. クリックしても フォーカスの位置が変わらない
26. • RouterサービスのNavigationEndイベントで制御 • フォーカスを当てたい要素に tabindex=-1 を付与 （デフォルトでフォーカスが当たらない場合） ルーティングのフォーカスを制御する
27. 実装で気をつけること • ネイティブ要素を使う • ネイティブ要素が使えない場合、aria属性、role属性 を使う • Angular Materialを活用する • ルーティングのフォーカスの制御をする
28. アクセシビリ ティ に関して知る チーム・組織で 認識を合わせる 実践する テストする 修正する 1 2 3 4 5
29. TSLintにルールを追加する • linterのような静的チェックツールを利用する • https://web.dev/accessible-angular-with- codelyzer/ • https://medium.com/ngconf/new-accessibility- rules-in-codelyzer-v5-0-0-85eec1d3e9bb
30. tslint.json
31. TSLintは10こしか ルールがない
32. もっと自動チェック 増やしたい
33. 何でチェックする？
34. axe • オープンソースのアクセシビリティ検証ライブラリー • axeのエンジンはaxe-core • https://github.com/dequelabs/axe-core • Deque Systems社が開発している • https://www.deque.com/axe/ 業界標準！
35. axe • オープンソースのアクセシビリティ検証ライブラリー • axeのエンジンはaxe-core • https://github.com/dequelabs/axe-core • Deque Systems社が開発している • https://www.deque.com/axe/ 業界標準！ アクセ！ アックス やで
36. axe • ブラウザー拡張 • Chrome • https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/ lhdoppojpmngadmnindnejefpokejbdd • Firefox • https://addons.mozilla.org/ja/firefox/addon/axe-devtools/ • 日本語で使える • 92ルールチェックしてくれる • https://github.com/dequelabs/axe-core/blob/develop/doc/rule- descriptions.md
37. axe
38. axe
39. lighthouse • lighthouse • https://github.com/GoogleChrome/lighthouse/ • lighthouseでは42ルールのチェックができる • https://web.dev/lighthouse-accessibility/ • https://web.dev/accessibility-scoring/ • アクセシビリティ監査のエンジンはaxe-core • https://www.deque.com/blog/google-selects- deques-axe-chrome-devtools/
40. lighthouseの利用方法 • Chrome dev tools • Chrome 拡張機能 • Node CLI • Nodeモジュールの使用 • lighthouse ci • https://github.com/GoogleChrome/lighthouse-ci
42. lighthouseでチェックできない項目 • 詳細 • https://web.dev/lighthouse-accessibility/#additional-items- to-manually-check • 例 • タブ順序は論理的か • インタラクティブなコントロールはキーボードフォーカス可能か • ユーザーのフォーカスは、ページ追加された新しいコンテンツに 向けられるか • etc…
43. 手動チェックはどうする？ • 手動チェックをするタイミングは？ • エンジニアが都度チェックする？ • QAのチェック項目に追加する？ みんな どうしてるんだろう？
44. axe と lighthouse の比較 • axe • アクセシビリティだけチェックしたい • ブラウザ拡張は日本語で使える • CLI、CIツールなど一部有料 • lighthouseよりチェックのルールが多い • lighthouse • アクセシビリティ以外もチェックしたい • CLI、CIツールが無料
45. アクセシビリ ティ に関して知る チーム・組織で 認識を合わせる 実践する テストする 修正する 1 2 3 4 5
46. TSLintのエラー • 3/10 ルールでエラーがでた • エラー数は全部で65件 • エラーがなかった7ルールは追加 • エラーが出た物に関しては修正方針と工数見積もり • これから修正していく ルールを追加して チェックしてみた
47. いっぱいエラーが出た場合 どこから修正する？
48. 修正フロー チェックしてエラーが出たものは全てissueにする 知覚不能なエラーを修正する 次は操作不能なエラーを修正する
49. まとめ
50. 1STEPずつ完璧にして進んでいくのは 現実的ではない アクセシビリ ティ に関して知る チーム・組織で 認識を合わせる 実践する テストする 修正する 1 2 3 4 5
51. できることから取り組もう
52. 少しの改善を 積み重ねて 品質を 上げていこう アクセシビリ ティ に関して知る 実践する テストする 修正する チーム・組織で 認識を合わせる
53. ありがとうございました！