こんにちは、freeeの自称「アクセシビリティーおじさん」の中根といいます。 freeeで働き始めて間もなく2年くらいになりますが、このブログには初めて投稿します。
今日は、4月30日にVer. 202004.0を一般公開したfreeeアクセシビリティー・ガイドラインをご紹介しようということで出てきました。 (このバージョンが一般公開した最初のバージョンです。)
そもそもアクセシビリティーって?
「アクセシビリティー (accessibility)」という言葉については、いくつかの公式な定義があるはずですが、僕は分かりやすく、
誰でも、ほぼ同じコストで、ほぼ同じようにサービスや情報を利用できる
そういう状態を「アクセシブルな状態」、「アクセシビリティーが高い状態」としています。
「誰でも」というのは、文字通り、年齢、性別、利用環境、障害の有無、その他様々な社会的属性などの違いに関係なく、誰でも使えることを目指そうということです。
そして「コスト」というのは、利用料金などの経済的コストに限らず、所要時間、身体的負荷、精神的ストレスなど、様々なものを含みます。
つまり、
状況が異なっているユーザーであっても、追加の経済的な負担なく、同じような時間で、同じくらいの簡単さでサービスや情報を利用できる状態
これがアクセシビリティーが高い状態だと考えています。
そもそもなぜfreeeでアクセシビリティー?
freeeのミッションは、
スモールビジネスを、世界の主役に。
です。そしてfreeeのビジョンは
アイデアやパッションやスキルがあればだれでも、 ビジネスを強くスマートに育てられるプラットフォーム
です。
「だれでも」と言うことを目指すのであれば、利用環境の違い、社会的属性の違い、障害の有無、などなどいろいろな違いを超えて、だれでも使えるようにすることを目指す必要があります。 特に障害があるユーザーについて、使えない人がなるべく生まれないようにする方法の1つが、アクセシビリティーが高いプロダクトやサイトを作る、ということです。
どうすればアクセシビリティーは向上する?
アクセシビリティーを向上させることにつながる具体的な実装手法は数多くあり、そういった手法を知り、使うことが直接的にアクセシビリティーの向上につながります。 が、こういった具体的な実装手法の多くは、技術の進歩に伴って変わるものです。 ですから、どういうユーザーにとって、どういう状況がアクセスの障壁になり得るのか、ということをよく理解することが必要です。
こういったことがまとめられていて、国際的にも広く普及している基準として、W3Cが策定したWeb Content Accessibility Guidelines (WCAG)があります。
WCAGは、Version 2.0がそのまま国際標準 (ISO/IEC 40500:2012)およびJIS規格 (JIS X 8341-3:2016) になっていますが、最新版はVersion 2.1です。
WCAG 2.1には、Success Criterion (SC、達成基準) と呼ばれる、アクセシビリティーが高いWebコンテンツ製作に必要な事項を示す項目が、合計78項目含まれています。 これらのSCをすべて理解して実践すれば、当然アクセシビリティーが高いプロダクトやサイトを作ることができるのですが……。
なぜfreee独自のガイドライン?
ところがWCAGのSCを実際に読んでみると、SCにもよりますが、難解なものが多いのです。 英語が苦手な人は、英語だから分かりづらいのだろうと思うかもしれませんが、日本語訳を読んでみてもやはり難解なのです。
例えば、SC 1.1.1の冒頭には以下のように書かれています:
利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たすテキストによる代替が提供されている。
「非テキストコンテンツ」とか「テキストによる代替」とか、なんだか分かりづらくありませんか?
ちなみにWCAGでは、これらが用語として定義されていて、それぞれ次のようになっています:
非テキストコンテンツ: プログラムによる解釈が可能な文字の並びではないコンテンツ、又は文字の並びが自然言語においても何をも表現していないコンテンツ。
注記: これには、 (文字による図画である) ASCII アート、顔文字、 (文字を置き換える) リートスピーク、文字を表現している画像が含まれる。
テキストによる代替: 非テキストコンテンツとプログラムで関連付けられるテキスト。又は非テキストコンテンツとプログラムで関連付けられるテキストから参照されるテキスト。プログラムで関連付けられたテキストとは、その場所を、非テキストコンテンツからプログラムによる解釈が可能なテキストである。
チャートの画像があり、その直後の段落にテキストによる説明がある。チャートに対する短いテキストによる代替で後に説明があることを示している。
そしてここに出てくる、「プログラムによる解釈が可能」、「自然言語」、「ASCIIアート」、「テキスト」もそれぞれ用語として定義されています。
用語の定義を読むと益々分からない気持ちが増してきませんか?
このSCが求めていることはいくつかあるのですが、代表的なものとしては、「画像に説明を付けましょう」、つまりimg要素にalt属性を付けましょうというものです。
このように、WCAGが難解な原因は、この基準がHTMLやCSSといった特定の技術以外にも適用できるように、なるべく抽象的に書かれているためです。 長く使うことができる基準にするために、これはそれなりに重要なことですが、結果として随分と分かりづらいものになってしまっています。 そして開発の現場では、現在使われているHTML/CSS/JavaScriptなどの技術において、具体的になにをすべきかという情報が必要です。
そこで、freeeのプロダクト開発やサイト製作の現場で使える情報を提供することを目的に、WCAG 2.1に基づいたfreee独自のアクセシビリティー・ガイドラインを作ることにしました。
ガイドライン策定のために行ったこと
ガイドライン作りに当たって、以下のことをしました。
- SCごとのプライオリティーの見直し
- 各SCを満たすためにやるべきことの例のリスト作り
- 各SCが対象とするコンテンツの種類の整理 (= SCのカテゴリー分け)
- SCの意図の明示
プライオリティーの見直し
WCAGでは、各SCにA (高優先度) から AAA (低優先度) の3段階のプライオリティーが付けられています。 プライオリティーがAのSCは、満たさないと致命的なアクセシビリティーの問題を引き起こすもの、AAのSCはそこまで重大な問題にはならないものの多くのユーザーに影響するもの、AAAのSCはできれば満たした方がいいもの、といったような位置づけです。
このプライオリティー付けの中には、WCAGが策定された当時の状況を踏まえると現実的なものであると思われるものの、今では前提が変わったと言えそうなものがあったり、freeeのプロダクトの性質を考えるとWCAGが示すプライオリティーよりも優先度を上げた方が良さそうなものがあったりします。 そこで、まずは各SCのプライオリティーを見直しました。
その結果、いくつかのSCに関してはプライオリティーを上げることになりました。
見直し後のSCのリストで、プライオリティーがAとAAのもの (= AAA以外) を取り出して、freee独自のアクセシビリティー・ガイドラインの基礎とすることにしました。
そして、AやAAという表記が分かりづらいという意見もあったため、Aを [MUST] 、AAを [SHOULD] としました。
やるべきことを示す
こうして抜き出したSCについて、では具体的にどんなことをやるべきなのかということを書き出してみる作業をしました。
例えば先に挙げたSC 1.1.1の場合、当初作ったメモには以下のようにあります:
- テキストによる短い説明を付ける
- img要素のalt属性
- svg要素のalt属性
- aria-label属性
- aria-labelledby属性
- テキストによる詳細な説明
- 画像の側に詳細な説明を記す
- 詳細な説明があるページへのリンクをお置く
- svg要素のdesc要素を使う
- 純粋な装飾目的の場合は無視されるようにする
- img/svg要素のalt属性に空文字列 ("""") を指定する
- aria-hidden属性を使って当該要素を隠蔽する
- マルチメディア・コンテンツについて、そのコンテンツの存在を認知して識別できる説明を提供
- aria-label属性を使う
といった感じです。
SCのカテゴリー分け
さて、実際にガイドラインを活用する場面を考えてみましょう。
単にSCとそれが意図する「やるべきこと」が並んでいるリストがある場合、開発中のプロダクトやサイトがそのSCを満たしているのか、SCごとに確認していくというような使い方になりそうです。 WCAGや同等のISO/IEC標準、JIS規格を満たしているかどうかの確認という場合はそのような手順になるかと思いますが、これは多くの場合、開発が概ね完了した後にやることで、開発中にやるようなことではない場合がほとんどだと思います。
では開発中にはどんな風にガイドラインを活用することになるのか、「画像を使うときの注意点ってなんだっけ?」とか、「動画張り付けるのってどうなんだっけ?」とか、そういう疑問を解決しながらアクセシビリティーを確保していく、ということになるのではないかと考えました。
そこで、「画像に関するガイドライン」、「動画に関するガイドライン」などといったカテゴリーを作り、そのカテゴリーに関連するSCをまとめるような形で整理してみることにしました。 その結果、現時点では、以下の12カテゴリーに分類しています:
- マークアップ全般
- ページ全体
- ログイン・セッション
- 入力ディバイス
- テキスト
- 画像化されたテキスト
- 画像
- アイコン
- リンク
- フォーム
- 動的コンテンツ
- マルチメディア・コンテンツ
SCの意図の明示
ここまで整理すれば、どんなときになにをすべきか、ということはだいたい分かりそうです。 ただ、それが誰にとってのどういう障壁をなくすことにつながるかということを理解せずにとり組むと、せっかくの作業が的外れな結果につながってしまうこともありそうです。 それに、せっかくアクセシビリティー向上に取り組むなら、具体的にどういう人に役立つのかをイメージできる方がfreeeのビジョンとも結びついて良さそうです。
そこで、各SCについて、どういう人のどういう問題の軽減につながるものなのかという事を書き加えてみることにしました。
上記SC 1.1.1の場合は
- 視覚障害者が画像の存在を認知し、内容を理解できるようにする。
さらに、より詳しい背景や、スクリーン・リーダーなどの支援技術に関する情報などを提供することで、そのガイドラインの意図が理解できるようにしています。
ガイドラインの構成
このような作業をしたうえで、上記のカテゴリーごとにガイドラインをまとめました。
上記の内容と重なる部分もありますが、各ガイドラインは、以下の項目から構成されています:
- 優先度: [MUST]または[SHOULD]
- ガイドライン本文
- ガイドラインの意図
- チェック内容: そのガイドラインを満たしているかどうかの確認方法
- チェック対象: チェック内容で挙げたチェックを実施するタイミングなどに応じて、以下のように分類しています
- 機能: 主に仕様を決める時点で確認すべき項目
- ビジュアル: 視覚的なデザイン、ワーディングなど、主にUXの設計段階で確認すべき項目
- 挙動: 実際に操作してみたときの挙動で判断できる項目
- マークアップ: マークアップやコーディングを確認しなければ判断が難しい項目
- 参考情報
- 対応するWCAGの達成基準
今後の予定
freeeでは、既存プロダクトのアクセシビリティー改善と、新規プロダクトのアクセシビリティー確保の取り組みを加速すべく、このガイドラインを作っています。 今後、既存プロダクトのアクセシビリティー改善や新規開発案件でのアクセシビリティー確保のために積極的に活用していく予定です。
今回の一般公開は、ガイドラインについて触れた記事が掲載されたWEB+DB PRESS Vol 116の発売に合わせたようなところがあり、まだ詰め切れていない部分もあります。 まずはそういった部分について、検討を進める予定です。
また、参考情報についてはさらに充実させていく予定です。
さらに、現在社内向けに「チェック内容」をまとめたチェックリストのような資料を作っていますが、これも何らかの形で一般公開する予定です。
こういった変更を加えて、随時更新版を公開しますのでご活用ください。
ご意見など
ご意見やご指摘につきましては、GitHubリポジトリーのIssuesやPull Requestからお願いします。
