概要
この記事はアクセシブルなSvelteコンポーネントを作るために何をしたらいいかを考える記事です。
前提
チームの中には
「大事なのはわかるけど何していいか わからんのよね」
という人も結構いるのではないでしょうか？
（もしかしたらこの記事を読んでいるあなたもそうかも？）
この記事では「そもそもアクセシビリティに精通している人は少ない」という前提で、アクセシビリティをやっていくヒントになるような考えを書いています。
UIコンポーネントライブラリに頼るのはやめよう
知識がない状態で「アクセシビリティにバッチリ対応している」と謳っているライブラリを使うのはやめましょう。
使わないよりマシかもしれませんが、信じて疑わないのは危険です。
名前は出しませんが、有名なライブラリでもイマイチな実装は多かったり対応が甘かったりするものも多いです。
このライブラリ入れてるから大丈夫だよね になるとスキルは向上しません。
できているつもりになるのが一番危険です。
正しいHTMLタグを使って正しくマークアップしよう
とにかくLintで縛りましょう。
- A11y周りのLintを入れる
- とにかくLintを入れましょう！後述します
- Markuplintを導入する
- 後述します
-
axe DevToolsでチェックする
- いれましょう。変更を加えるたびに実行して確認しましょう
-
Nu Html CheckerでHTMLをチェックする
- 後述します
A11y周りのLintを入れる
eslint-plugin-jsx-a11y
Svelteをお使いの皆さん、安心してください。
https://svelte.jp/docs/accessibility-warnings デフォルトでSvelteの構文に合わせたものが入っています。
エラーを無視しないようにしましょう。
lintが落ちたらマージできないようにCI/CDを組んでおくとこれだけで最低限の品質は担保できるでしょう。
Storybookを使っている人
storybook-addon-a11y
Svelteでも使えます。入れましょう。
Storybookはデザイナさんもみることが多いと思いますが、エラーが出ているのが見える状態にしておくとアクセシビリティ周りの問題に気づくきっかけになります。
なんかエラー出たんですがどう修正したらいいですか？というコミュニケーションが発生したら最高です。
みんなで学んで対応していきましょう。
実際やっちゃったミスはどこかに貯めておいてチームメンバーが増えた時や年末などにみんなで確認するのもいいかもしれませんね。
Markuplintを導入する
Markuplintを導入しましょう。
npx markuplint --init でinstallすると初めに設定を聞いてくれるので楽です。
入れてなかったら今すぐ入れましょう。
チームにアクセシビリティに詳しい人がいてレビューで弾いてくれるとしても入れましょう。
全ての知識を持っている人は存在しません。レビューも人がやっているので漏れます。
ulやliをコンポーネント化している場合はプリテンダーの設定を作っておくとさらにGoodです。
Nu Html Checker
上に書いたライブラリを入れたりしていればほぼ不要かもしれませんが、HTMLに詳しくない人がマークアップをやっている場合はソースを全部コピってチェックする癖をつけると何がダメなのかわかるようになってくるのでおすすめです。
ここまでのまとめ
とにかくLintで縛りましょう。
書籍で学習するのもいいですが、先にLintを入れてしまいましょう。まずはそこからです。
Lintに入れてしまえば自分以外のチームメンバーが作ったコンポーネントの実装も縛ることができます。
他の人を巻き込みましょう。
キーボード操作
macを使っている人が多いと思うので、一度作成したコンポーネントがキーボードで操作できるか試してみましょう。
意外とできてないことが多いです。
ここはエンジニアのお仕事ですね。責任を持ってやりましょう。
スクリーンリーダーでの読み上げを確認する
とりあえず目を瞑って作成したコンポーネントの読み上げが操作するのに十分か確認しましょう。
読み上げられるテキストが不十分すぎて訳分からんことも多いです。
そうなったらもっと上流で作業している人とコミュニケーションをとりましょう。
まずはデザイナーさんと話すのがおすすめです。
音声コントロール
音声コントロールで操作できるか試してみましょう。
- キーボード操作
- 音声コントロール
この二つは手軽に着手できますが、aria-labelを間違って使ってしまっていて音声コントロールできなかった というのをやってしまいがちです。
過去の私です。
これに関しては最初からできなくてもひとまず良いのかなぁと思っています。
ちょっとずつ改善していきましょう。
この記事も読んでみてください。
いいねして…
レビューのチェックリストにアクセシビリティの項目を入れよう
- 誰か一人がわかっている
- 誰か一人だけやろうとしている
この辺は避けましょう。
みんなでやろうと決めてチームで合意をとったほうがいいです。
また、最初から完璧を目指すのはやめましょう。
タブやアコーディオンなどのJSが必要なコンポーネントの実装
このページを確認しながら実装します。
この記事は「アクセシブルなSvelteコンポーネントを作るために」というタイトルになっていますが、
コンポーネントを作らないほうが自由度が高くLintの恩恵も受けやすいのでいいかもしれません。
コンポーネント化する場合は前述したMarkuplintでそのコンポーネントがどのHTMLタグに対応するのか書いておくとよいでしょう。
Melt UIでは例えばアコーディオンなら
<button use:melt={$trigger('item-1')}>Is it accessible?</button>
このように、正しいHTMLタグに対してアクセシビリティ上必要なHTML属性だけ渡すような仕組みになっています。
これならコンポーネントが複雑になりすぎないしLint周りの設定もあまり書かなくていいので良さそうです。
まとめ
- UIコンポーネントライブラリに頼らない
- とにかくLintで縛る
- チームメンバーと一緒にやる
- 最初から完璧を目指さずできるところからやっていく
アクセシビリティはUI/UXを高め、プロダクトの品質を上げる手段の一つです。
スキル差がある人でも一定の品質を担保できるようにLintで縛り、できるだけいろんな人を巻き込み、ちょっとずつできることから始めましょう。