アクセシビリティを担保したいと思い、Storybookのプラグインを使って最終確認できるようにしようと思い色々調べた結果を書き留めます。
本来デザイン作成時にはアクセシビリティを担保してないと、コードに落とし込んだ後にわかっても遅いよね？
という話はありつつ、リリース前に気がつけるための最終チェック機能としての役割を持たせたい意図で導入を決めました。
はじめに自戒：アクセシビリティの認識が甘かった
導入したいと考えた当初はなんのアクセシビリティを担保したいのか？は全く考えられておらず全てのアクセシビリティの指標を一括りにしてしまっていました…。
Storybookにはアドオンは万能ではないのであくまでも最終チェックの機構だと認識いただいた上で検討を進めてもらえると良いと考えます。
@storybook/addon-a11yはどんなアドオンなのか？
Deque Systemsが提供するアクセシビリティ検証エンジンであるAxeのAPIが使用されており、「WCAG2.1（Web Content Accessibility Guidelines）とSection 508」を準拠し、成果物がアクセシブルであることをStorybook上で確認することができるStorybookの拡張機能です。
何がチェックできるのか？
アドオンがチュックしてくれる項目は下記の通りです。
- Color Contrast
- Keyboard Accessibility
- Labeling
- ARIA
- HTML Validity
- Landmark Roles
Color Contrast
視力や色覚異常のユーザーでも確認できるように表示要素のコントラストをチェックします。
後に詳しくしますが、Storybookのアドオンでは色覚異常を持ったユーザーを全てをカバーすることができないそうです。
Keyboard Accessibility
ページがキーボードのみで完全に操作可能かをチェックします。
Labeling
すべてのインタラクティブ要素（ボタン、リンク、フォーム入力フィールドなど）が適切にラベル付けされているかチェックします。
ARIA
ページが適切にARIA属性を使用しているかをチェックします。
HTML Validity
マークアップの正当性をチェックします。
Landmark Roles
ページに主要部分(ランドマーク)が適切にロールを持っているかをチェックします。
全ての項目がオールグリーンになる必要はないかと思っています。
やりすぎるとデザインの制限が強くなったり、テストに時間がかかったり事業の成長スピードを遅くしてしまうリスクがあると考えるからです。
全てのユーザーにとってアクセシブルであることが望ましいのは間違いないのですが、どこまで対応するのかを事業の状況やチームの状況に合わせて決定し、都度見直すことが大切だと考えております。
色覚異常があるユーザー全てを担保できるチェックはできない
先ほど少し触れましたが、Storybookのアドオンでは色覚異常を持った全てのユーザーをカバーすることはできないそうです…。
具体的には、T型やA型に分類される色覚以上を持つユーザーをカバーすることはアドオンでは困難だということです。
T型とA型ってなに？
色覚異常は複数の型で分類されています。
詳しくは割愛しますが、参考サイトのリンクを添付しますのでご確認ください。
人の目の網膜には光を感じる錐体には、L（赤）、M（緑）、S（青）の3種類あります。
その中の一部錐体がなかったり、感度が別の錐体と似かよることで色が識別できなくなることを色覚異常と表現されます。
赤色が見えずらい人、緑色が見づらい人を型で分類しています。
アクセシビリティの議論では「T型とA型」までカバーすべきか？が争点になると思います。
というのもT型とA型は数が少ないため、P型とD型でほとんどの色覚異常の人をカバーすることが可能だとされているためです。
サイトの性質にもよりますが、チームで議論してステイクホルダーと決定を擦り合わせておけると良いと思います。
色覚異常のユーザーを全てカバーしたい場合の対策
それでも色覚異常をもった全ての人に対応したいと考えた場合は、ツールの併用を検討します。
Storybookのアドオンだけでは無理なのためです。
- 色覚シミュレーションツール
- ウェブサイトが色覚異常のユーザーにどのように表示されるかシミュレートすることができます
- 例えば、Chromeの拡張機能には「Toptal ColorBlind」
- 色覚互換性ツール
- 色の組み合わせが色覚異常のユーザーにとって適切かどうかを検証します
- Color OracleやSim Daltonismなど
色覚に配慮したデザインにすることも有効だと知りました。
例えば、色と一緒にパターンやテクスチャを使う、テキストラベルを使うなどの方法を採用するなどです！
まとめ
アクセシビリティもどんな項目をどのレベルまで対応するかによって考えないといけないことがたくさんあるのだと知りました。
アクセシビリティを突きつめてサイトを作成することでアクセシビリティは良くなりますが、その分デザインの幅が狭まることも事実です。
アクセシビリティに限らず、見れる人の範囲を拡大すればするほど開発コストやその後の運用コストもかかるのでいい塩梅のラインをチームで設定して開発できるのが望ましいと感じました。