STORES Advent Calendar 2022 の 24日目の記事です。
こんにちは。業務委託で STORES の開発をしている @inouetakuya です。
昨年のアドベントカレンダーでも アクセシビリティについての記事 を投稿し、そのなかで、
hey もアクセシビリティの取り組みはまだ始まったばかりで、目標としている「普段の開発に定着させる」というところまでの道のりは遠いですが、2022年も前に進めていく所存です。
と書きました。
今回は続編として、今年 2022年に、アクセシビリティを普段の開発に定着させるために行った取り組みを紹介します。
2021年のおさらい - 学習と実践
2022年のスタート地点がどのような感じだったかをお伝えするために、2021年の取り組みにも触れておきます。
2021年は STORES にとってアクセシビリティ元年とも呼べる年で、アクセシビリティに関する取り組みが本格化した年でした。
- 学習
- 実践
という 2つのフェーズを経験しました。
学習
アクセシビリティとは何ぞや、どこに課題があって、どう対応すれば良いのかをチームで学習しました。
具体的には、
などを行いました。
実践
- freee 社のアクセシビリティガイドラインを採用
- freee 社のアクセシビリティチェックリストを用いて、STORES の各ページに対してチェックリストを用いてアクセシビリティチェックを行い、GitHub に Issue を立てまくる
- 立てられた Issue をひたすら解決していく
をフロントエンドエンジニアチームの全員で行いました。
このあたりの詳しい内容は freee 社のアクセシビリティガイドラインとチェックリストを丸ごと導入した - STORES Product Blog で紹介しています。
2022年は定着フェーズ
さて、2022年は、これまでアクセシビリティについて培ってきたことを普段の開発に定着させる年でした。
アクセシビリティのことを特にがんばって意識しなくても、自然とアクセシブルなプロダクトを開発できるようになることを目指し、いくつかの取り組みを行いました。
以下、順に見ていきます。
アクセシビリティチェックの自動化
アクセシビリティを普段の開発に定着させるにあたって、アクセシビリティチェックが自動で行われる仕組みづくりを行いました。
具体的には ESLint のプラグインである vue-a11y/eslint-plugin-vuejs-accessibility を導入しました。
これは例えば img タグに alt 属性が記述されているかなど静的チェックするもので、CI 実行時に自動チェックを行っています。
工夫したこと - 漸進的な適用
vue-a11y/eslint-plugin-vuejs-accessibility の全てのルールを適用すると膨大な数のエラーが検出されました。
それら全てを解決していると導入までに時間がかかってしまうことが懸念されたため、まずは一部のルールのみを適用し、徐々に適用するルールを増やしていくという方法を採りました。
導入時にエラーが出たルールについては、ルール毎に対応する Issue を作成し、それらを解決するプルリクエストを別途作成することで導入を進めています。
例えば「ESLint ルール vuejs-accessibility/aria-role を適用する」というタイトルの Issue などを 20個作成しましたが、2022年12月現在では、残すところあと 6 Issue となっています。
GitHub プルリクエストのテンプレートにアクセシビリティチェック項目を追加
アクセシビリティの観点から重要だが、ESLint での自動チェックでは難しい事柄などもあります。それらについては、GitHub プルリクエストのテンプレートにチェック項目を設けることで対応しました。
チェック項目は freee 社のアクセシビリティチェックリストの中から、特に STORES の開発として重要なものをピックアップし、開発時にチェックしやすいかたちに編集したものにしました。
あわせて各チェック項目への対応方法をまとめた社内ドキュメントも作成しました。
工夫したこと - 漸進的な適用
ここでも漸進的な適用を意識し、最初から欲張って項目数が多くならないよう配慮しました。
最初は厳選した 5項目から開始して、頃合いを見計らって 2項目を追加するなどしました。また、チーム内に根付いたものについてはチェック項目から除外するなどして、より効率的なチェックが行えるようにしています。
アクセシビリティチェック項目例
参考までに最初に設定したチェック項目は下記です。
## アクセシビリティチェック <!-- チェック項目が OK または対象外のときにチェックを入れてください --> - [ ] 以下の項目が適切なタグ要素を用いてセマンティックに記述されていること - [ ] 見出し - [ ] リンクとボタン - [ ] スクリーン・リーダーでフォーム・コントロールとラベルの関連付けが分かるような読み上げがされる - [ ] スクリーン・リーダーが、表を適切に認識していて、表中のセルも適切に認識している - [ ] リンク、ボタン、フォーム・コントロールがキーボードでフォーカス移動でき、フォーカスリングが表示されること。また、操作手順に即した自然な順序でフォーカスが移動すること - [ ] ページ/画面、また複数の状態を持つ場合のコンポーネントはスクリーン・リーダー利用時にもその状態が分かるようになっており、変化した時も含めて結果が伝えられる チェック項目への対応方法が分からないときは？ -> アクセシビリティチェックリスト補足 （社内ドキュメントの URL）
2022年12月現在では下記。
### アクセシビリティチェック <!-- チェック項目が OK または対象外のときにチェックを入れてください --> - [ ] スクリーン・リーダーが、表を適切に認識していて、表中のセルも適切に認識している - [ ] ページ/画面、また複数の状態を持つ場合のコンポーネントはスクリーン・リーダー利用時にもその状態が分かるようになっており、変化した時も含めて結果が伝えられる - [ ] 情報や機能性を持つ画像の説明、役割をもつアイコンの説明がスクリーン・リーダーで読み上げられること、またそれらを持たない画像、アイコンについては読み上げられないこと - [ ] ページ上のすべてのコンテンツが、ARIAランドマークによって示される適切な領域に配置され、スクリーン・リーダーのARIAランドマークで示される領域間ジャンプ機能で本文の開始位置を見つけることができる チェック項目への対応方法が分からないときは？ -> アクセシビリティチェックリスト補足 （社内ドキュメントの URL）
未知の問題への対応方法の確立
2022年は未知の問題への対応するための知見もチーム内に蓄積されてきました。
以前は WCAG や WCAG 解説書 を読んでもどのように対応したらよいか分からない問題に遭遇することが多々ありましたが、「〇〇については〇〇を参考にすればよい」といったような知見が蓄積され、それらがチーム内の会話やプルリクエストのレビュー等でやり取りされるようになりました。
例えば、アクセシビリティについて法整備が進んでいる米国のサイトを参考にする機会が多く、ネットショップの文脈だと ウォルマート や Shopify など、ネットショップに限定しない汎用的なコンポーネントは U.S. Web Design System (USWDS) などを参考にすることが多いです。
社外への情報発信
さらに、社内での取り組みや蓄積された知見を社外へ情報発信する機会もありました。
12月15日に行われた 事例に学ぶ、ウェブアクセシビリティ〜フロントエンド最前線〜 では、STORES のアクセシビリティを引っ張ってきた @kskymst1 が登壇し、これまでに行ってきた取り組みや、これからアクセシビリティをはじめるにはどうしたらよいか？などをお話しました。
今後の課題
このように 2022年は普段の開発にアクセシビリティを定着させるためにいくつかの取り組みを行ってきましたが、今後の課題には以下のようなものがあります。
自動チェックできる範囲が限定的
現時点では自動で行っているアクセシビリティチェックが ESLint のみであり、チェックできている範囲が限定的です。
E2E を用いたアクセシビリティチェックを行うなど、自動チェックできる範囲を広げていくことを検討しています。
既存機能、既存コンポーネントのカイゼン
新規に開発する機能やコンポーネントについては、アクセシビリティを意識した開発を行えるようになりましたが、既存の機能やコンポーネントについてはアクセシビリティが担保されていないものがまだまだあります。
プラットフォームとしての体験の統一
STORES はお店のデジタルを支えるプラットフォームとして、ネットショップ以外にも様々なサービスを展開しています。
まずはネットショップを開発するチームが先行してアクセシビリティのカイゼンに取り組んだかたちですが、この動きをプラットフォーム全体に広げていく必要があります。
おわりに
アクセシビリティを普段の開発に定着させるために行ったこと、いわば STORES のアクセシビリティにおける 2022年の現在地ともいうべき内容を紹介しました。
今後も引き続きカイゼンを進めていき、取り組みを発信していきたいと考えています。
2023年もどうぞよろしくお願いします。
