持続可能なアクセシビリティ開発

by azukiazusa

Slide 1

Slide 1 text

持続可能なアクセシビリティ開発 azukiazusa

Slide 2

Slide 2 text

持続可能なアクセシビリティとは？誰が書いても80%の要件を満たす状態を目指す

Slide 3

Slide 3 text

アジェンダ 1. 前提条件: チーム構成とAIによる状況の変化 2. AI が書くコードのアクセシビリティについて 3. 持続可能なアクセシビリティ開発のためのアプローチ 4. まとめ

Slide 4

Slide 4 text

Slide 5

Slide 5 text

前提：チーム構成

Slide 6

Slide 6 text

共有しているコンポーネントでは、すべての変更をコードレビューで確認するのは困難

Slide 7

Slide 7 text

● デザイナーが AI を使ってコードを書き、Pull Request を作成している ● 一般的に AI で生成されたコードは一見正しく動作するように見えても、エッジケースやエラー処理が不十分なことが多い ● AI が生成したコードはプロフェッショナルな開発者によるコードレビューが必要なことは、よく知られている生成 AI の普及による開発体制の変化

Slide 8

Slide 8 text

Slide 9

Slide 9 text

AI 時代のアクセシビリティ開発生成AI時代のWebアプリケーションアクセシビリティ改善 - やまのく（yamanoku） ● Human or LLM? A Comparative Study on Accessible Code Generation Capability という論文が紹介されている ○ LLM はアクセシブルなコードを書けるか？

Slide 10

Slide 10 text

LLM はアクセシブルなコードを書けるか？ ● 人間が書いたコードよりも LLM が生成したコードの方がアクセシビリティ要件を満たしている割合が高かった ● しかし複雑なアクセシビリティ要件、得に WAI-ARIA にまつわる実装を行わせると、LLM は誤った実装を行うことが多かった

Slide 11

Slide 11 text

よくある間違い不要な aria-label で情報を上書き

Slide 12

Slide 12 text

フィードバックループの欠如 TypeScript のエラー → コンパイル時に検出できる

Slide 13

Slide 13 text

フィードバックループの欠如誤った WAI-ARIA の使用 → コンパイルエラーが発生せず、ランタイムでも検出されないスクリーンリーダーを触って初めて誤りに気づく ● LLM は「実装・フィードバック・修正」のサイクルを繰り返すが、アクセシビリティ要件に関してはフィードバックが得られにくい

Slide 14

Slide 14 text

ここまでの話をまとめると ● AI が生成したコードはアクセシビリティ要件を満たしていないことがある ● アクセシブルにコードを保つには、プロフェッショナルによるレビューが不可欠 ● しかし、共有コンポーネントの変更をすべてコードレビューで確認するのは困難

Slide 15

Slide 15 text

誰が書いても80%の要件を満たす状態を目指す

Slide 16

Slide 16 text

持続可能なアクセシビリティ開発のための取り組み

Slide 17

Slide 17 text

解決策 (1)：コンポーネントライブラリ ● 標準的な UI コンポーネントをまとまった形で提供する ● WCAG に準拠したアクセシビリティ対応を集中管理 ● コンポーネントを利用する開発者はアクセシビリティの実装の詳細を理解していなくても、アクセシブルな UI を実装できる

Slide 18

Slide 18 text

タブコンポーネントの例 → role="tablist"や aria-selected, キーボード操作の実装はコンポーネント内で完結

Slide 19

Slide 19 text

● ヘッドレス UI ライブラリを使うのがおすすめ ○ Headless UI ○ Radix UI ○ Ark UI ○ React Aria ● スタイルがなく、機能のみが提供されている ● プロダクトのデザインに合わせた形でラップして提供コンポーネントライブラリの実装

Slide 20

Slide 20 text

AIとの好循環 AIは既存のコードベースを調査してからコードを生成 ↓ 既に使われているコンポーネントがあれば AIも同じパターンを生成 ↓ アクセシビリティ要件を満たしやすくなる

Slide 21

Slide 21 text

ドキュメント整備コンポーネントライブラリを作って終わりではなく、使い方をドキュメント化し、チームをまたいで周知徹底する ● Storybook でコンポーネントを一覧化 ● デザイナーとも共有し Figma のコンポーネントのと揃える ● デザインシステムと AI の連携も今後の課題 ○ すでに取り組まれている方がいればぜひ教えてください

Slide 22

Slide 22 text

解決策 (2)：ガードレール Linter やテストを導入し、LLM にフィードバックする ● React: eslint-plugin-jsx-a11y  ● Vue.js: eslint-plugin-vuejs-accessibility  ● Svelte: svelte-check  ● HTML: markup-lint 

Slide 23

Slide 23 text

E2Eテストでの検証 @axe-core/playwright 

Slide 24

Slide 24 text

まとめ ● LLM は基本的なアクセシビリティ要件を満たすコードを生成できるが、複雑な要件では誤りを犯しやすい ● 持続可能なアクセシビリティ開発とは、誰がコードを書いても一定水準のアクセシビリティ要件を満たすコードが生成される環境を構築すること ● LLM が WAI-ARIA を誤用しないようにするためには、コンポーネントライブラリでの集中管理を行ったり、Linter やテストをガードレールとして導入することが有効