freeeアクセシビリティー・ガイドラインVer. 202008.0を公開しました

こんにちは、freeeのアクセシビリティーおじさん、中根です。以前CAO（Chief Accessibility Ojisan）を名乗ろうと思って名刺にも入れようとしたんですが、「説明コストが高すぎる」という冷静かつ的確な一言で断念したことがあります。

さて、今回もfreeeアクセシビリティー・ガイドラインの更新情報をお届けします。

中心は「チェック内容」の見直し

8月21日に公開したVer. 202008.0の更新内容の中心は、各ガイドラインに対応できているかどうかを確認するための「チェック内容」に関する見直しです。前回のリリースまでの作業で、ガイドライン本文の内容が基本的に固まり、追加しようと思っていた参考情報も概ね追加できたことから、各ガイドラインについてのチェックを効率的に進めるための方法を検討した結果が、今回のリリースです。

以下、少し詳しく紹介します。

チェック内容の整理

まず、すべてのチェック内容について、それぞれどのガイドラインと対応しているのかという情報と併せてリストを作りました。

このリストを眺めると、同じチェック内容が複数のガイドラインに対応しているような場合がいくつか目に付きます。そのため、実際にチェックを実施してみると、複数のガイドラインについてまとめてチェックできる場合が少なからずあることに気づきました。（正確には、分かっていたことではあるのですが、予想以上に非効率的だなと感じました。）

そこで、なるべく効率的にチェック作業を進められるように、作業内容が似通っているチェックを1つにまとめることにしました。その結果、元々は1つのチェック内容には1つのガイドラインが対応しているという状態のリストだったものが、1つのチェック内容に複数のガイドラインが対応している状態のリストになりました。

例えば、これまでコントラストに関するチェックは、テキスト、画像内のテキスト、画像化されたテキストなど複数の対象に関して別の項目が存在している状態でしたが、今回の変更ではこれを1つの項目にまとめています。

チェック対象の見直し

次に、各チェック内容について、開発のどの段階で行うものかという視点で見直し、結果として「チェック対象」を変更しました。

これまでは、機能、ビジュアル、挙動、マークアップという4つのチェック対象を示していましたが、今回の変更では以下の3種類に変更しています。

デザイン：主に仕様を決める時点や設計段階で確認すべき項目
コード：マークアップやコーディングを確認しなければ判断が難しく、主に実装時に確認すべき項目
プロダクト：実際に操作してみたときの挙動で判断でき、主に実装後に確認する項目

これはあくまでもfreee社内での開発の状況に即して考えているものなので、開発体制によってはより細かい分類が必要だったり、逆にこのような分類が不要だったりすることもあると思います。 freeeの開発体制においては、対象が「デザイン」のチェックは設計段階でUX担当者が実施し、「コード」のチェックは実装時にエンジニアが実施し、「プロダクト」のチェックは実装物のテスト段階で品質保証の担当者が実施することを想定しています。

このような前提に基づいて各チェック内容の対象を見直した結果、チェック対象を増やすことになったものが複数あります。そして、チェック対象や開発工程に応じて、より適切な表現に修正した項目もあります。

例えば、画像の説明の提供：画像に関する過不足のない説明をテキストで提供する。

というガイドラインについて、これまでのチェック内容は以下のようになっていました：

マークアップ：画像に関する簡潔で過不足ない説明が alt 属性や aria-label 属性で付加されている。かつ

マークアップ：短いテキストでは充分に説明できない場合には、 aria-describedby 属性を使うなどして、詳細な説明が提供されている。

今回の変更で、このガイドラインのチェック内容は以下のようになりました：

デザイン

画像に関する簡潔で過不足ない説明（alt属性値）が、設計資料で明示されている。かつ

短いテキストでは充分に説明できない場合には、詳細な説明のテキストが設計資料で明示されている。

コード

画像に関する簡潔で過不足ない説明が alt 属性や aria-label 属性で付加されている。かつ

詳細な説明が必要な場合には、その説明が当該の画像の直前または直後に表示されている、または aria-describedby 属性で関連付けられている。

プロダクト

画像の説明が適切に読み上げられる。

これまでは実装時に適切にマークアップされていることを確認すれば良いというような書きぶりになっていたのに対して、変更後は設計時、実装時、動作確認時にそれぞれ確認するような形になっています。上の例の場合、もし動作確認時にスクリーン・リーダーで画像の内容が読み上げられなければ、実装時に適切なマークアップがされていない可能性、さらには設計時に適切な説明が考えられていない可能性があるということになります。

チェック内容をまとめた新たな章を追加

以上のような見直しや整理を、手元ではGoogleスプレッドシート上で行いました。（そして今後の改善も）スプレッドシート上でまとめることで、作業もしやすいですし、実際にチェックを行う場合にもチェック・リストとして活用しやすいという利点があります。

いずれこのスプレッドシートを一般公開する方向でも考えてはいるのですが、まずはこの内容をガイドラインの1章としてまとめることにしました。そうして追加されたのが、アクセシビリティー・チェック・リストです。ぜひ一度見てみてください。

ちなみに、今後のメンテナンスを効率的にするために、このスプレッドシートの内容を取得してJSONに変換するGoogle Apps Script、そのJSONを処理してSphinxのソースとして使えるようにするPythonスクリプトを作りました。これらのスクリプトで作ったファイルが、ソース・リポジトリーの source/checks/inc 以下にあるファイル群です。（なおスクリプトはプログラミング・センスのなさにあふれたものなので公開しません……。）