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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 ● Web アプリケーションエンジニア ● Web フロントエンドが得意 ● https://azukiazusa.dev ● 趣味 ○ 読書 ○ 麻雀 ○ ポーカー azukiazusa

Slide 3

Slide 3 text

ソフトウェア開発でアクセシビリティに取り組むためには？

Slide 4

Slide 4 text

まずは個人の小さな改善から始める ● プロジェクト外の時間を使い、小さな改善から進めて、成果をアピールする ○ onclick がついてる要素をにする ○ 要素の alt 属性を設定する ○ フォーカスリングが表示されるようにする ● 画面をキーボードのみで操作できるか試してみるとよい ● 数行の小さなコードの修正でも、大きな改善となる

Slide 5

Slide 5 text

個人の取り組みだけでは限界がある ● コンストラクト比や UI 設計の問題はデザイナーを巻き込む必要がある ● 大きなチームだと、一人ですべての機能のコードをレビューするのは難しい ● 自分がチームを異動した後でも、アクセシブルな開発が進められるようにしたい

Slide 6

Slide 6 text

アクセシビリティを高めていくには、チームの協力が不可欠

Slide 7

Slide 7 text

アクセシビリティに興味を持つ人を増やしていく

Slide 8

Slide 8 text

● 改善をアピールすると、興味を持つ人が増えたり、アクセシビリティの話題が徐々に増えていく ● 改善をアピールするには、スプリントレビューの時間が効果的 ○ キーボードだけで操作できるようになった様子をデモするなど個人の活動からチームに広げる

Slide 9

Slide 9 text

開発チーム全体でアクセシビリティを意識する状態が望ましい

Slide 10

Slide 10 text

とはいえ... ● WCAG *1や解説書を読んで理解し実践する、といったことを開発チーム全体に求めるのは難しい *1 ウェブアクセシビリティに関する世界的な基準にもなっているガイドライン

Slide 11

Slide 11 text

特に意識せずともアクセシビリティを保てるようにする

Slide 12

Slide 12 text

チーム開発でアクセシビリティを保つ施策 1. 機械的な方法でコードをチェックする 2. デザインシステムを整備する

Slide 13

Slide 13 text

機械的な方法でチェックする ● ESLint や Markuplint といったリンターにより、静的にアクセシビリティに問題があるコードをチェック ● @axe-core/playwright でブラウザを立ち上げてテストを実行する ● CI/CD に組み込むことで、アクセシビリティを担保できる

Slide 14

Slide 14 text

ESLint ● alt 属性のない要素や、間違った aria-* 属性を使っている箇所を検出してくれる ● 即座にフィードバックを得ることができる ● なぜ検出されたエラーを修正する必要があるのか、といった会話からアクセシビリティへの興味を広げられることもあった

Slide 15

Slide 15 text

それぞれのフレームワークに対応したプラグイン ● React → eslint-plugin-jsx-a11y ● Vue.js → eslint-plugin-vuejs-accessibility ● Angular → @angular/eslint ● Svelte → コンパイラが警告してくれる

Slide 16

Slide 16 text

Markuplint ● HTML Standard や WAI-ARIA などの仕様を踏まえた上でHTML の構文エラーを検出してくれる ○ 許可されていない子要素 ■ の子要素にインタラクティブな要素は許可されていない ○ 要素にアクセシブルな名前が必要

Slide 17

Slide 17 text

● axe-core はアクセシビリティ検証ツールのコアエンジンで、様々なツールと連携できる ○ Chrome の Devtools など ● @axe-core/playwright はブラウザを立ち上げて自動テストを実行する @axe-core/playwright

Slide 18

Slide 18 text

● 静的な解析では検証できない問題を検出できる ○ コンストラクト比 ● ページ全体の単位でチェックできる ○ id 属性の重複 ○ 見出し要素のスキップがないか @axe-core/playwright

Slide 19

Slide 19 text

● 機械的なチェックですべての問題に取り組めるわけではない ○ 画像の代替テキスト設定されていないことはわかるが、が適切な文章かどうかまではわからない ● よりアクセシビリティを高めたいのであれば、実際に支援技術を使ってテストするといった人の手によるチェックが不可欠機械的なチェックの注意点

Slide 20

Slide 20 text

デザインシステムの整備

Slide 21

Slide 21 text

● デザインに関することを体系化・構造化したもの ○ デザイン原則 ○ スタイルガイド ○ コンポーネントライブラリ ● プロダクトのデザインの一貫性を保つための、ドキュメントや部品・ガイドラインから構成されているデザインシステムとは

Slide 22

Slide 22 text

● 色の組み合わせとコンストラクト比・フォントサイズをあらかじめ定義しておく ● アクセシビリティが考慮されたコンポーネントライブラリを使い回すデザインシステムとアクセシビリティの関係

Slide 23

Slide 23 text

● タブやモーダルといった複雑な UI は、アクセシビリティ上求められていることが多い ○ 適切な role, aria-* 属性を設定し、キーボード操作を提供する ● ``、`` のような形で使えようにすることで、実装の詳細を隠蔽できるコンポーネントライブラリ

Slide 24

Slide 24 text

あなたの脳は同時に 7 つのことしか記憶できません。コードベースのアーキテクチャーを設計するときは、これを考慮に入れるのが良い考えです。短期記憶はチャンクで数える。それぞれの項目が長期記憶にあるもっと大きな情報を示すラベルになりえるからである。抽象化とは無関係なことを排除し、本質的なことを増幅するものである [60]。

Slide 25

Slide 25 text

● 画面を実装しているときに、各 UI パーツのアクセシビリティの詳細な実装を頭の隅においておける ○ コンポーネントを使っていればアクセシブルに ● role や aria-* 属性がコンポーネントの外に漏れないようなインターフェースが望ましいコンポーネントライブラリによるアクセシビリティ実装の抽象化

Slide 26

Slide 26 text

● ヘッドレス UI ライブラリを使うのがおすすめ ○ Headless UI ○ Radix UI ○ Ark UI ○ React Aria コンポーネントライブラリの実装

Slide 27

Slide 27 text

● 想定された使い方がされない・そもそも認知されておらず使ってもらえない ● ドキュメントを整備して使いやすい状態を保つ ● 定期的に周知を行うコンポーネント仕様のドキュメント化

Slide 28

Slide 28 text

公開されているデザインシステムを参考にしよう

Slide 29

Slide 29 text

デジタル庁

Slide 30

Slide 30 text

SmartHR

Slide 31

Slide 31 text

freee “vibes”

Slide 32

Slide 32 text

● はじめは個人の活動から始めて、徐々にアクセシビリティに興味を持ってもらう ● 普段の開発でアクセシビリティを保てるような施策を紹介した ○ 機械的なコードのチェック ○ デザインシステムの整備まとめ