a11y | 1人design system advent calender 10日目
10日目はアクセシビリティ（A11y）について。
アクセシビリティは、どのようなユーザに対しても十分な利便性が保たれてるかどうかを計るもので、デザインシステムにおいて重要な要素の1つ。多くのデザインシステムでは、アクセシビリティに関してガイドラインを用意していたり、カラーパレットで触れたようにコントラストが一定の基準を満たしているかをチェックするよう配慮している。 何かしらの身体的な制限があるユーザはどこのサービスの利用者にも一定数いると考えられるだろうし、アクセシビリティへの配慮が結果的にSEOに繋がることも少なくないと思うので、デザインシステムにおいて一定の基準を設けておくのが望ましい。
アクセシビリティの項目
以下に、考慮すべきアクセシビリティの項目を実際のデザインシステム（Lightning Design SystemやCarbon Design System）のアクセシビリティに関する記述からあげていってみる。
- 標準に準拠したマークアップ
- セマンティックであることとW3Cの標準に沿った
ARIA roleの利用
- セマンティックであることとW3Cの標準に沿った
- キーボードナビゲーション
- マウスによる操作が行えないケースなどを考慮して、キーボード操作をサポート
- カラー
- 色が識別できないケースを考慮して、色だけで情報を伝えることをしない
- 可読性を考慮したコントラスト
- 代替テキスト
- スクリーンリーダーや何かしらの事情で画像が表示できないケースを考慮して、有用な代替テキストを用意
- WAI-ARIA
- フォーム
- フォームの操作、選択、誤操作を防止するようにケアする
コンポーネントのベースパターン
上記のようなアクセシビリティについて配慮していくとして、どのようにデザインシステムにおいて取り込むのか。Lightning Design SystemではAccessibility Patternsとして18のパターンを用意して、それらをUIコンポーネントのベースパターンとして利用する形をとっている。
Accessibility can seem complicated, but you can make accessible web apps with semantic markup and 18 principle patterns. These patterns form the basis of the Lightning Design System Components and are a companion to the accessibility documentation available on each component page.
全部が全部そうではないかもしれないけど、個別のコンポーネントでそれぞれアクセシビリティの配慮をして基準が考え方がばらばらになるより、土台となるパターンを用意しておいて、それらを継承、拡張していく考え方でUIコンポーネントを構成していく方が効率的なはずなので、基本的にはこの考え方と同じようなアプローチで問題ないように思う。
11日目はVoice & Toneについて書く。
