チームで開発する際にアクセシビリティを保つ施策

この発表はすでにアクセシビリティに興味を持っていて、ソフトウェア開発の現場にアクセシビリティを取り入れたい人を対象としています。

開発チーム全体でアクセシビリティに意識を持つ状態が理想ですが、全員が詳細な実装を行うのは実際には難しいでしょう。そこで、特に意識をせずともある程度のアクセシビリティを保つ状態にするための施策について紹介いたします。

Transcript

1. チームで開発する際に アクセシビリティを保つ施策 azukiazusa
2. 自己紹介 • Web アプリケーションエンジニア • Web フロントエンドが得意 • https://azukiazusa.dev • 趣味 ◦ 読書 ◦ 麻雀 ◦ ポーカー azukiazusa
3. ソフトウェア開発でアクセシビリティに 取り組むためには？
4. まずは個人の小さな改善から始める • プロジェクト外の時間を使い、小さな改善から進めて、 成果をアピールする ◦ onclick がついてる要素を <button> にする ◦ <img> 要素の alt 属性を設定する ◦ フォーカスリングが表示されるようにする • 画面をキーボードのみで操作できるか試してみるとよい • 数行の小さなコードの修正でも、大きな改善となる
5. 個人の取り組みだけでは限界がある • コンストラクト比や UI 設計の問題はデザイナーを巻き込 む必要がある • 大きなチームだと、一人ですべての機能のコードをレ ビューするのは難しい • 自分がチームを異動した後でも、アクセシブルな開発が 進められるようにしたい
6. アクセシビリティを高めていくには、 チームの協力が不可欠
7. アクセシビリティに興味を持つ人を増や していく
8. • 改善をアピールすると、興味を持つ人が増えたり、アク セシビリティの話題が徐々に増えていく • 改善をアピールするには、スプリントレビューの時間が 効果的 ◦ キーボードだけで操作できるようになった様子をデモ するなど 個人の活動からチームに広げる
9. 開発チーム全体でアクセシビリティを 意識する状態が望ましい
10. とはいえ... • WCAG *1や解説書を読んで理解し実践する、といったこ とを開発チーム全体に求めるのは難しい *1 ウェブアクセシビリティに関する世界的な基準にもなっているガイドライン
11. 特に意識せずとも アクセシビリティを保てるようにする
12. チーム開発でアクセシビリティを保つ施 策 1. 機械的な方法でコードをチェックする 2. デザインシステムを整備する
13. 機械的な方法でチェックする • ESLint や Markuplint といったリンターにより、静的に アクセシビリティに問題があるコードをチェック • @axe-core/playwright でブラウザを立ち上げてテストを 実行する • CI/CD に組み込むことで、アクセシビリティを担保でき る
14. ESLint • alt 属性のない <img> 要素や、間違った aria-* 属性を 使っている箇所を検出してくれる • 即座にフィードバックを得ることができる • なぜ検出されたエラーを修正する必要があるのか、と いった会話からアクセシビリティへの興味を広げられる こともあった
15. それぞれのフレームワークに対応したプ ラグイン • React → eslint-plugin-jsx-a11y • Vue.js → eslint-plugin-vuejs-accessibility • Angular → @angular/eslint • Svelte → コンパイラが警告してくれる
16. Markuplint • HTML Standard や WAI-ARIA などの仕様を踏まえた上 でHTML の構文エラーを検出してくれる ◦ 許可されていない子要素 ▪ <button> の子要素にインタラクティブな要素は 許可されていない ◦ 要素にアクセシブルな名前が必要
17. • axe-core はアクセシビリティ検証ツールのコアエンジン で、様々なツールと連携できる ◦ Chrome の Devtools など • @axe-core/playwright はブラウザを立ち上げて自動テス トを実行する @axe-core/playwright
18. • 静的な解析では検証できない問題を検出できる ◦ コンストラクト比 • ページ全体の単位でチェックできる ◦ id 属性の重複 ◦ 見出し要素のスキップがないか @axe-core/playwright
19. • 機械的なチェックですべての問題に取り組めるわけでは ない ◦ 画像の代替テキスト設定されていないことはわかる が、が適切な文章かどうかまではわからない • よりアクセシビリティを高めたいのであれば、実際に支 援技術を使ってテストするといった人の手によるチェッ クが不可欠 機械的なチェックの注意点
20. デザインシステムの整備
21. • デザインに関することを体系化・構造化したもの ◦ デザイン原則 ◦ スタイルガイド ◦ コンポーネントライブラリ • プロダクトのデザインの一貫性を保つための、ドキュメ ントや部品・ガイドラインから構成されている デザインシステムとは
22. • 色の組み合わせとコンストラクト比・フォントサイズを あらかじめ定義しておく • アクセシビリティが考慮されたコンポーネントライブラ リを使い回す デザインシステムとアクセシビリティの 関係
23. • タブやモーダルといった複雑な UI は、アクセシビリティ 上求められていることが多い ◦ 適切な role, aria-* 属性を設定し、キーボード操作を 提供する • `<Tab>`、`<Modal>` のような形で使えようにすること で、実装の詳細を隠蔽できる コンポーネントライブラリ
24. あなたの脳は同時に 7 つのことしか記憶で きません。コードベースのアーキテク チャーを設計するときは、これを考慮に入 れるのが良い考えです。 短期記憶はチャンクで数える。それぞれの 項目が長期記憶にあるもっと大きな情報を 示すラベルになりえるからである 。 抽象化とは無関係なことを排除し、本質的 なことを増幅するものである [60]。
25. • 画面を実装しているときに、各 UI パーツのアクセシビリ ティの詳細な実装を頭の隅においておける ◦ コンポーネントを使っていればアクセシブルに • role や aria-* 属性がコンポーネントの外に漏れないよう なインターフェースが望ましい コンポーネントライブラリによるアクセ シビリティ実装の抽象化
26. • ヘッドレス UI ライブラリを使うのがおすすめ ◦ Headless UI ◦ Radix UI ◦ Ark UI ◦ React Aria コンポーネントライブラリの実装
27. • 想定された使い方がされない・そもそも認知されておら ず使ってもらえない • ドキュメントを整備して使いやすい状態を保つ • 定期的に周知を行う コンポーネント仕様のドキュメント化
28. 公開されているデザインシステム を参考にしよう
29. デジタル庁
30. SmartHR
31. freee “vibes”
32. • はじめは個人の活動から始めて、徐々にアクセシビリティ に興味を持ってもらう • 普段の開発でアクセシビリティを保てるような施策を紹介 した ◦ 機械的なコードのチェック ◦ デザインシステムの整備 まとめ