ユーザのためだけじゃない！エンジニアも嬉しいアクセシビリティ改善のための自動テスト

開発プロセスの中でWebアクセシビリティの改善を最後に持ってくると、時間的な制約で十分に改善の時間が確保できないことがあります。
フロントエンドの開発中にテストを実装することを通じてアクセシビリティを改善する方法の紹介しています。
Playwrightというテストフレームワークを利用し、テストできる実装をすることがどのようにユーザの価値につながるかを例示し、テストがアクセシビリティの改善に繋げる方法や、マシンリーダビリティという概念に触れテストとアクセシビリティの接点を紹介します。
最後にテストを通すことだけに集中することの危険性に触れ、シンプルな実装こそ良いという結論でまとめます。

このスライドは Design Dontaku vol.4 で発表した LT に利用したものを一部修正してアップロードしています。

Transcript

1. ユーザのためだけじゃない！ エンジニアも嬉しいアクセシビリティ改善のための自動テスト 2024年9月12日 Design Dontaku vol 4 株式会社マネーフォワード 樫福智哉
2. 自己紹介 カシフクトモヤ 樫福智哉 𝕏: @cashfooooou 株式会社マネーフォワード “マネーフォワードクラウド経費”を作ってます 最近、ウクレレの練習を始めました 自撮り
3. デザイン面、実装面のアクセシビリティ アクセシビリティはデザインと実装の両輪で向上する デザイン 実装 • コントラスト • フォント • 配置 • キーボード操作 • 支援技術 • ユーザ設定の反映 （フォントサイズ、ダークテーマ）
4. アクセシビリティ改善は二の次？ 実装が終わったあとにアクセシビリティの改善をしようとすると難しい すでに機能が完成している（ように感じる）ので、リリースされてしまう Tabキーでフォーカスできないから 直してほしいんだけど リリースが迫ってるので無理です マウスでなら問題なく使えますよ！ div を使って実装されたボタン
5. アクセシビリティ改善は工程の後ろに回したくない 開発プロセスの終わりに予定を組むと、その通りには実施されない リリース デザイン 実装 アクセシビリティ改善 QAプロセス 予定 リリース 現実
6. アクセシビリティ改善は開発プロセスのもっと前に組み込める 改善は「しなきゃいけないもの」から「した方がやりやすい」になる アクセシビリティ改善をもっと前へ！ リリース デザイン 実装 アクセシビリティ改善 QAプロセス これまで リリース デザイン アクセシビリティの 高い実装 これから QAプロセス
7. アクセシビリティを使った自動テスト フロントエンドのテストツールはアクセシビリティを活用するものが多い • Testing Library • Playwright 導入が楽な Playwright の活用方法を中心に紹介
8. Playwright の紹介 • End to End (E2E) テストのツール • ユーザの動作を再現しページが正しく動作していることをテストする
9. Playwright の紹介 • End to End (E2E) テストのツール • ユーザの動作を再現しページが正しく動作していることをテストする 該当のページにアクセスして
10. Playwright の紹介 • End to End (E2E) テストのツール • ユーザの動作を再現しページが正しく動作していることをテストする 「送信」という名前のボタンを見つ けてクリックし
11. Playwright の紹介 • End to End (E2E) テストのツール • ユーザの動作を再現しページが正しく動作していることをテストする 「送信しました」と表示される ことを確認する
12. テストがアクセシビリティ改善につながる理由 “いい実装” をしないとテストが通らない （例）buttonタグを使うとテストで要素にアクセスできる ❌ ✅
13. “いい実装” をするとアクセシビリティが高くなる ブラウザは “いい実装” をするといい機能を提供するように作られてる テストがアクセシビリティ改善につながる理由 • Tabキーでフォーカスできる • Enter/Space キーで実行できる • disabled 属性だけで非活性にできる • 支援技術が「ボタンである」と解釈できる • どれもできない
14. テストがアクセシビリティ改善につながる理由 div タグを使って 実装できなくはないが... (React での実装) • 自前実装をテストするのが大変 • 全てのブラウザで動作するか　　確 認するのは不可能 • 想定してない使い方があるかも
15. テストがアクセシビリティ改善につながる理由 • “いい実装” をしないとテストが通らない • “いい実装” をするとアクセシビリティが高くなる 　　テストを実装することで “いい実装” を強制させられる 　　その結果、アクセシビリティが高くなる
16. 正しいマークアップはコンピュータが正しく解釈できる（マシンリーダブル ） いい実装はマシンリーダブル ✅ いい実装 いい解釈 アクセシブルな いい機能 人が理解しやすい いいテスト
17. 正しいマークアップを使うには • Markuplint や eslint-plugin-jsx-a11y に機械的に解決できることは任せる • MDN を参照する
18. やりすぎには注意 テストを通すためにユーザが価値を感じづらい実装は本末転倒 • role属性を付与してロールを書き換える ◦ type属性の活用や他のタグで代替できないか確認 • aria-disabled属性で非活性にする ◦ disabled属性で代替できないか確認 ブラウザで実際の動作を確認してみる よくわからない場合は “短い実装” を目指すといいかも
19. まとめ • テストを導入すると正しいマークアップをしたくなる • マシンリーダブルな実装はアクセシビリティも高い傾向にある • 無理にがんばりすぎず、簡潔でわかりやすい実装を心がける