こんにちは。エンジニアの中島です。 2022年 4月からアクセシビリティ推進グループ（以下推進グループ）に在籍しています。
この組織は新設されたばかりで、まだ出来て半年の組織になります。 そのため、部署の目指すべきゴールイメージや、それを図るための指標といったものを作るところから始めることになりました。
本記事はそういったところについて共有させていただこうと思います。
立ち上げにあたっての話については以前同グループの嶌田が投稿した記事があるのでそちらをご参照ください。
部署の目指すべきゴールイメージと行動軸
推進グループ内で話し合った結果、アクセシビリティの推進活動の先のゴールイメージは「LIFULLのすべてのプロダクトがアクセシブルになっている状態」としました。
そしてそれを実現するために、「プロダクトに対する直接的な品質改善活動」と「新しい負債の発生を低減させるための文化醸成」の二本軸で活動していくことに決めました。
プロダクトに対する直接的な品質改善活動
直接的な品質改善活動は単純明快でサイトをアクセシビリティレビューし、検出された問題を自分たちで直接修正してプロダクト品質を改善していく作業です。
推進グループは開発経験の豊富なエンジニア二名(うち一人は勤続年数も長い)で構成されているため、直接的な修正が自部署内のリソースで行えるようになっています。
新しい負債の発生を低減させるための文化醸成
文化醸成はアクセシビリティの勉強会やガイドライン策定、プロジェクトの個別フォローなどによって社内の開発者のアクセシビリティに対する理解を促す取り組みになります。
こちらはヒューマンリソースの少ない推進グループだけでは厳しいものがあるので、有志で構成されたアクセシビリティを推進するワーキンググループと連携を取りながら進めるといったことで足りないリソースを補いながら進めています。
指標化
業務活動の軸が決まり、次にその活動の成果を測る指標について決めることにしました。
プロダクトに対する直接的な品質改善活動の指標化
プロダクト自体にアクセシビリティレビューを行い、スコア化し、そのスコアの推移を見ることでアクセシビリティの品質の改善度合いを図ることにしました。
スコア化というとLighthouseが真っ先に思い浮かぶわけですが、Lighthouseのアクセシビリティスコアにはマニュアルテストを追加で行うことが求められていることをご存知でしょうか？
マニュアルテスト
Lighthouseで検出可能なアクセシビリティの指摘点はカラーコントラストや適切なロールやステートが指定されているかといった感じで、読み込み時のHTMLやCSSから計算可能な部分に限られます。
それだけでも十分ありがたいのですが、例えばダイアログを開いた時のフォーカス位置やページの読み込みと同時に再生される動画コンテンツなど、動きを伴う問題点を検出することは現時点ではできません。
またボタンをフォーカス可能な<button>で実装されているかどうかについてもそれがそもそもボタンなのかどうかLighthouseが理解することができないため検出できません。
しかし、サイトにはたくさんのボタンや動きを伴うUIが多く存在しており、Lighthouseで高得点を得ていたとしてもそういった部分で致命的な問題があると、実質的には"操作不能"であるといったこともしばしばありえるわけです。
こういったものをフォローするためにLighthouseは追加でマニュアル(手動)テストを推奨しています。
計算が自動で出来ず、ヒューマンリソースを割く必要があるということはメンバー二人の推進グループではかなり苦しいところではありますが、クォータに一度という間隔を空けてでもこれは検出する必要があると考え、Lighthouseによる自動テストに加え、マニュアルテストを加えてスコアリングすることにしました。
スコアリング
ところでそもそもLighthouseのアクセシビリティのスコアリングはどのように算出されるかをご存知でしょうか。
Lighthouseはアクセシビリティの各観点をまとめ、それの重要度に応じて重みを設定しています。
この定義をもとに、各項目を検査して問題が検出されなかった場合(Passした場合)、その重みを足し上げていきます。
この時の値をすべての重みの和で割ってあげた数字に100をかけると0~100点までのスコアが算出できるというようになっています。
つまり、マニュアルテストにも重みを設定し、この計算に加えてあげることで自動テストとマニュアルテストをすべて通したスコアが算出できるわけです。
我々はこれをスコアリングの方法として採用し計測することにしました。
加えたマニュアルテスト項目とその重み
スコアリングの方法が決まったところで、マニュアルテストに含める項目をどうするかをまた話し合いました。
その結果、Lighthouseで推奨されているマニュアルテストに加え、オリジナルのマニュアルテストを含めた以下のテストで運用することに決めました。
Lighthouseの推奨するマニュアルテスト
| 項目 | 重み | 項目説明 |
|---|---|---|
| logical-tab-order | 3 | ページ内のタブ順序が論理的に正しい順になっていること |
| focusable-controls | 10 | すべてのカスタムコントロールがキーボードフォーカス可能で、フォーカスインジケータが表示されていることを手動で確認します。 フォーカスが当たる順番は、DOMの順番に従うようにする必要があります。 |
| interactive-element-affordance | 10 | リンクやボタンなどのインタラクティブな要素は、その状態を示し、非インタラクティブな要素と区別できるようにする必要があります。 インタラクティブな要素がその目的と状態を示しているかどうかを確認するために、視覚テストとスクリーンリーダーによるテストの両方を使用します。 |
| managed-focus | 10 | 新しいコンテンツがページに追加されるたびに、ユーザーのフォーカスがそのコンテンツに向けられ、アクションを起こすことができるようにします。 |
| focus-traps | 10 | キーボードのフォーカスが特定のページ要素に固定されたり、引っかかったりしないようにすること。 ユーザーは、キーボードのみを使用してすべてのページ要素に移動できるようにする必要があります。 |
| custom-control-roles | 10 | すべてのカスタムコントロールが適切なRoleを持ち、そのプロパティと状態を与える必要なARIA属性があることを確認します。 例えば、カスタムのチェックボックスは、その状態を適切に伝えるために role="checkbox" と aria-checked="true|false" が必要です。 |
| visual-order-follows-dom | 3 | スクリーンリーダーやその他の支援技術は、DOM順でページをナビゲートします。情報の流れは理にかなっていなければなりません。 |
| offscreen-content-hidden | 3 | スクリーンリーダーやその他の支援技術には、ページの関連する部分のみが表示されるようにすること。 たとえば、画面外にあるコンテンツや単なる表示上のコンテンツは、支援技術から見えないようにする必要があります。 (≒非表示コンテンツがvisibility:hidden;/display:none;で適切に隠されていること) |
| use-landmarks | 3 | HTML5のmain、nav、asideなどの要素は、スクリーンリーダーやその他の支援技術がジャンプできるランドマーク、つまりページ上の特別な領域として機能します。 ランドマーク要素を使用することにより、支援技術の利用者のサイトでのナビゲーション体験を劇的に向上させることができます。 |
推進グループで追加したマニュアルテスト
| 項目 | 重み | 項目説明 |
|---|---|---|
| original | 10 | ホバーで表示されるコンテンツがタッチでも使えること また、キーボードアクセスが可能であること(フォーカスできる＋フォーカスが見える＋Enterやスペースに反応する) 対象となるホバーコンテンツがない場合は重みを0とする |
| original | 10 | 動画キャプションが設定されていること video要素のkind=captionsで検出できないケース(Youtubeなど) 対象となる動画がない場合は重みを0とする |
| original | 10 | 点滅やスクロールを伴うコンテンツがない |
| original | 10 | 自動更新されるコンテンツがない |
| original | 10 | フォーカスやフォームの値変更でページ内容の書き換え、ページ遷移、ポップアップの表示がされていない |
| original | 10 | フォームバリデーション等のエラーのフィードバックを適切に行う 対象となるフォーム等がない場合は重みを0とする |
新しい負債の発生を低減させるための文化醸成の指標化
次に文化醸成の度合いの指標化です。
こちらは単純に定性調査をとることにしました。
各組織の組織長に、おもにフロント領域に携わった開発者を抽出してもらい、その方々になるべく回答負荷が少なくなるように作った簡単なアンケートにクォータに一度回答してもらいスコア化しています。
以下は実際になげてるアンケートの項目です
| 質問内容 | 回答項目 | 重み | 補足 |
|---|---|---|---|
| プロダクト開発においてフロントエンド関連業務を行いましたか？ 文言修正やリンク先修正レベルのみであれば「いいえ」でご回答ください。 | はい、いいえ | 0 | 誤抽出された開発者の除外 |
| 企画やデザインに対してアクセシビリティ観点でチェックやフィードバックを行ったか | 1. まったくやらなかった ... 5. とてもよくやった | 25 | - |
| フロントエンド関連業務を通してアクセシビリティを考慮した実装をしたか | 1.まったくやらなかった ... 5.とてもよくやった | 25 | - |
| フロントエンド関連業務を通して開発メンバーへのレビューや育成等でアクセシビリティ観点で適切な指導をしたか | 1.まったくやらなかった ... 5.とてもよくやった | 25 | - |
| アクセシビリティ推進G(あるいは推進WG)との連携でアクセシビリティ設計への知見は深まりましたか | 1.まったく深まらなかった ... 5.とてもよく深まった | 25 | - |
対象職種はフロントエンドエンジニアとしています。
アクセシビリティは企画・デザイナー・エンジニアが一体となって考えるものであることは重々承知した上で、フォローアップするスコープをリソース的に狭める必要があったため、三職種への喚起をフロントエンドエンジニアの責務と定義してここでは回答職種を絞ることにしました。
(これに関しては運用経過を見て方針を変えるかもしれません)
運用してどうか
部署立ち上げから半年色々と試行錯誤してここまできましたが、今のところ活動の成果は目に見えるものとして現れており定量・定性両方のスコアにそこそこの改善が見られています。
マニュアルテストはヒューマンリソースの限られた推進グループとしては運用破綻するかどうか気にしていたところではありますが、だいたい1サイトをテストしきるのに1.5~2人日程度であり、現実的なラインであることがわかってきて安心しているところです (工数的な観点でサイトとページを絞って運用しています)
定性調査の結果はただの定点観測としてだけでなく、そこの回答内容をみて回答してくれた開発者と直接連携をとるきっかけとしてもうまくワークしています。
開発者全員と連携をとるのはひどく難しいように感じますが、弊社程度の規模であればフロントエンドエンジニアが数十人程度なので非力なりにもマンパワーで連携をとることが可能でした。
一度連携をとって知識をつけた開発者が開発リーダーとして現場のメンバーにレビューしたりしてくれることも実際散見されるので初期コストをおしまず投資することへのモチベーションにつながっています。
最後に
それぞれのスコアが改善して、その改善結果が実際的な使いやすさにつながっているかを検証する仕組みをつくることが次の我々の課題です。
これからもLIFULLプロダクトのアクセシビリティ向上のために尽力していこうと思います。
LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。
