年末に【独自】障害者配慮、民間も義務化へ...スロープ設置や手話対応 : 社会 : ニュース : 読売新聞オンラインという報道を目にした方も中にはいるかと思いますが、障害者差別解消法でこれまで民間では努力義務であった「合理的配慮」が義務化される公算が出てきました。

実際に、昨年12月に開催された第53回障害者政策委員会の議事次第での資料8 障害者差別解消法の改正に盛り込む事項（案）では、「事業者による合理的配慮の提供を義務化」が挙げられていることが確認できます。

ここでWebアクセシビリティと「合理的配慮」にはどのような関係があるのかおさらいをしてみたいと思います。総務省が公開しているみんなの公共サイト運用ガイドライン（2016年版）では、「障害者差別解消法を踏まえて求められる対応」として、以下のような記述があります。

2.2.2. 障害者差別解消法を踏まえて求められる対応

障害者差別解消法を踏まえて求められるウェブアクセシビリティに関する主な対応は以下のとおりです。

（中略）

(2) 合理的配慮の提供

障害者等から、各団体のホームページ等のウェブアクセシビリティに関して改善の要望があった場合には、障害者差別解消法に基づき対応を行う必要があります。

なお、公的機関が取組の対象から除外しているページなどがある場合も、障害者が実際にウェブアクセシビリティの問題に直面し、障壁の除去の要望を申し出た場合に、その実施に伴う負担が過重でないときは、障害者差別解消法に基づき合理的配慮の提供が求められます。

改善の要望に対して、ホームページ等の改善を即座に行うことが困難な場合等は、要望した当事者と必要に応じて協議を行うことなどにより要望の内容を確認し、ホームページ以外の方法で情報を提供するなどの対処も含めて、できる限りの最善の対応を行うことが必要です。

改善の要望があった箇所の改善等の対応を行うとともに、同じような問題が各団体のホームページ等の他の箇所でも生じないように、ホームページ等の全体の改善計画へ反映することが求められます。

現行法では行政が義務、民間が努力義務でありますから、仮に法改正されて義務化されると、行政と同様の対応が求められることになります。なお、Webアクセシビリティについては以下にあるように「環境の整備」という位置づけと解釈されており、これに関しては現行法で行政も民間も努力義務となっています。

(1) 環境の整備

ウェブアクセシビリティを含む情報アクセシビリティは、合理的配慮を的確に行うための環境の整備として位置づけられており、各団体においては、事前的改善措置として計画的に推進することが求められます。

ところで、みんなの公共サイト運用ガイドラインはあくまで公的機関を対象にしたガイドラインに当たります。民間では、行政とは異なりより多彩なWebサイトの構成が考えられます。何が「合理的配慮」に当たるのかについては、これを機に改めて確認する必要があると個人的に感じているところです。また、公共サイトに限らないガイドラインについても、必要とされてくるのかもしれないと個人的に思った次第です。

とはいえ、コロナ禍にあり特定地域に緊急事態宣言が行われていること、オリンピック・パラリンピックが開催予定であること、また今年は衆議院の任期満了の年であり総選挙を控えていることなどから、すんなりと法改正の審議が行われるのかについて、政治的に不透明ではあるでしょう。

毎年恒例となっているgihyo.jpの新春特別企画に、当社アクセシビリティ・エンジニアの中村直樹さんが「2021年のWebアクセシビリティ」という記事を昨年に続き寄稿しました。W3C/WAIの策定するガイドライン、Web Content Accessibility Guidelines（WCAG）を中心に、WAI-ARIAやリモート会議にも言及しつつ、今年のWebアクセシビリティ界隈の動向について短期的な予測をまとめています。

......という紹介、宣伝だけで終わらせるのも味気ないので、個人的な感想を記したいと思います。まずは、今年勧告が予定されているWCAG 2.2について。本稿執筆時点では、Accessibility Guidelines Working Group Project Planには記載していたスケジュールをTimelines/ - WCAG WGに移動したと記されているのですが、そこからリンクをたどった先にあるWCAG 2.2 Timeline - WCAG WGを見ますと、今年7月に勧告予定のようです。

勧告時期はさておき、押さえておくべきポイントは、WCAG 2.1と比べ最大9つの達成基準が新規追加され、また既存の達成基準の1つがレベルAAからレベルAに適合レベルを変更される（かもしれない）点です。達成基準が増え、ガイドラインが充実するのは素晴らしいと思ういっぽう、達成基準を満たすために必要なコストが、WCAGのバージョンとともに右肩上がりとなりかねない点を少しばかり心配してもいます。

この記事はミツエーリンクス Advent Calendar 2020 - Adventarの22日目の記事です。

主に弱視のユーザーが利用するハイコントラストモード（コントラストの高い色の組み合わせで画面を表示するモード）において、Webコンテンツのスタイル変更を可能にするメディアクエリーとして、古くから-ms-high-contrastが知られています。ベンダー接頭辞からおわかりのように、Web標準ではなくMicrosoftの独自実装ですが、値にはactive / black-on-white / white-on-blackの3種類が用意されており（none値はEdge 18で廃止）、それぞれの用途は以下のコードサンプルでコメントに記した通りです。

@media (-ms-high-contrast: active) {
  /* ハイコントラストモード向けのスタイル */
}
@media (-ms-high-contrast: black-on-white) {
  /* 白地に黒のハイコントラストモードに特化したスタイル */
}
@media (-ms-high-contrast: white-on-black) {
  /* 黒地に白のハイコントラストモードに特化したスタイル */
}

この記事はミツエーリンクス Advent Calendar 2020 - Adventarの13日目の記事です。

2019年からSection 508の適合テストプロセス（Trusted Tester）の有志によるオンライン勉強会に参加しており、現在はウェブアクセシビリティ基盤委員会（WAIC）の作業部会3（試験）のTrusted Testerについての調査・研究プロジェクトで活動させていただいています。今年のアドベントカレンダーは、Trusted Testerについてご紹介したいと思います。

Section 508

まず、Trusted Testerの前提となるSection 508について触れておきましょう。アクセシビリティ対応に関わる担当者の方であれば、一度は耳にしたことがあるキーワードかと思います。
Section 508とはリハビリテーション法第508条（Section 508 of the Rehabilitation Act）と呼ばれる、米国のアクセシビリティ関連の法律です。連邦政府機関が開発・調達・維持・利用する情報通信技術におけるアクセシビリティ確保を求める内容で、Webサイトだけでなく、ハードウェアやアプリケーション、情報通信技術を利用するためのサポート用ドキュメント類など広く対象としています。確保を求める項目についての技術基準も提示されており、Webサイトだけでなく、ソフトウェアおよびnon-WebコンテンツなどについてWCAG 2.0への適合が求められます。 （参考リンク：Comparison Table of WCAG 2.0 to Existing 508 Standards）

しかし、技術基準が提示されているとはいえ、WCAGと同様に特定の対象に依拠しないよう抽象的な記述ではあります。 そのため技術基準の解釈が人によって異なることで、結果、基準を満たしているかどうかの判断も差異が生まれる可能性があります。チェック対象の実装や情報構造によって判断結果が一律にはなり得ない面をもともと含んでいることを前提とした上でも、この揺らぎは少ないほうが好ましいことに変わりありません。

Section 508では、対象とする情報通信技術への適合についてのテストツールや方法をTest for Accessibilityで公開しています。Webに関しては、Trusted Tester and ICT Testing Baselineに詳細があります。

Trusted Testerとは？

Trusted Testerとは、Section 508のアクセシビリティ要件を満たすためのテスト基準に準じたテストプロセスです。
アクセシビリティ要件を満たすためのテスト基準がSection 508 ICT Testing Baseline、テストプロセスがTrusted Testerであり、ツールによる自動チェックではなく、人間によるマニュアルチェックを前提としています。Section 508専用ですが、Section 508への適合のチェックにTrusted Testerを用いなければならない、というルールはありません。

前述した通り、マニュアルチェックでは判断結果の揺れが生じやすくなります。Trusted Testerでは、チェックの対象だけでなく、チェック手順と作業を具体的に指定し、すべての作業の結果がTRUE（真）であればそのテストプロセスは PASS（合格）とする、といったように判断基準のパターンを指定することで、この揺れを減らすようになっています。同様に、チェックの際に用いるツールもTrusted Tester用に開発されたANDIというブラウザのアドオンとColor Contrast Analyzer（以下CCA）のみとされています。また、HTMLやCSSなどのソースコードを直接テスト担当者が確認して問題を指摘するといった個別の判断を求めることはほとんどせず、あくまでもANDIとCCAで検出できる対象と範囲によるチェックにとどめるなど、マニュアルチェックによる判断の揺れ（属人性）を減らすために割り切った手法を取っていると感じました。その反面、本来人間によるチェックで対応するはずの、ツールが対応できない内容のチェックが残ったままになるというマイナス面も生じています。

もう１つの留意点としては、Section 508専用のため、Section 508独自のチェック内容が含まれていること、そしてWCAGの達成基準について一歩踏み込んだ独自のチェック基準を加えている箇所があることです。

こうしたことから、Trusted TesterのチェックはWCAG 2.0 AAに対する最低限の担保としてとらえるほうがよいと思われます。

次に、最新ドキュメント（Trusted Tester Conformance Test Process - Version 5 - updated Aug 16 2019）の内容を参照してもう少し具体的に見てみましょう。

構成

Trusted Testerは、20個のSection 508 Conformance Tests（以下、「Section 508適合テスト」とします）によって構成されており、WCAGの構成とは大きく異なっています。WCAGでは、解消すべき問題を軸として、4つの原則と複数のガイドラインによって達成基準を分類していますが、Trusted Testerでは、チェックする操作や対象コンテンツにあわせて分類しているためです。
基本、Section 508適合テストの実施はナンバリング通りでなくてよい（テスト対象ごとに調整してよい）のですが、1.から4.まではWCAG 2.0 適合要件 5. 非干渉に関わるので、はじめに実施することを推奨されています。

Section 508 Conformance Tests

1. Conforming Alternate Version and Non-Interference
2. Auto-Playing and Auto-Updating Content
3. Flashing
4. Keyboard Access and Focus
5. Forms
6. Links and Buttons
7. Images
8. Adjustable Time Limits
9. Repetitive Content
10. Content Structure
11. Language
12. Page Titles, Frames, and iFrames
13. Sensory Characteristics and Contrast
14. Tables
15. CSS Content and Positioning
16. Pre-Recorded Audio-Only, Video-Only, and Animations
17. Synchronized Media
18. Resize Text
19. Multiple Ways
20. Parsing

Section 508 適合テストは単数あるいは複数のテストプロセスで出来ています。"2. Auto-Playing and Auto-Updating Content" であれば、

• Auto-Playing Audio
• Moving, Blinking, and Scrolling Content
• Auto-Updating Information
• Notification of Automatic Content Changes

の4つのテストプロセスが存在します。
このテストプロセスごとにテストを実施し、合格（PASS）・不合格（FAIL）・該当なし（DOES NOT APPLY、以下DNA）を判定していく仕組みです。

テストプロセス

個々のテストプロセスは以下のような構成です。

• チェック対象
  • 対象の識別
  • テストプロセス名・テストID
    • 適用性
      • 条件
    • テストの実施手順
      • 具体的な手順の指定
    • 判定結果
      • 具体的な判断の指定

引き続き、"2. Auto-Playing and Auto-Updating Content"を見てみます。

2.Auto-Playing and Auto-Updating Content

• Auto-Playing Audio
  • Identify contents
    • Identify audio content that automatically plays (without user activation) for more than 3 seconds.
      • Content of this type includes alerts, sounds, and music.
    • If there is no such content, the result for the following test ID(s) is DOES NOT APPLY: 2.A.
  • Check 1.4.2-audio-control (TestID : 2.A)
    • Applicability
      • This Test Condition DOES NOT APPLY (DNA) if there is no audio content that plays automatically for more than 3 seconds.
    • How to Test
      1. Determine if there is a mechanism within the first three elements encountered for the user to pauseor stop the audio or to control the volume of only the auto-playing audio.
         a. The browser should already have been configured to disable auto-play. (See the Test ToolInstallation and Configuration Guide for instructions.)
      2. Activate the mechanism.
      3. Following this test process, test the mechanism for all applicable Test Conditions.
    • Evaluate Results
      • If ALL of the following are TRUE, then the content PASSES:
        1. There is a mechanism that can pause or stop the audio or control the volume of only the auto-playing audio, AND
        2. The mechanism is within the first three elements encountered by the user, AND
        3. The mechanism passes all applicable Test Conditions in this test process.

どのようなものを対象としているか（Identify Contents）や、その対象が本テスト適用対象となるか（Applicability）は、通常のアクセシビリティチェックでの内容とそうかわりはないのではと思います。 一方、How To Testでは、機能があるかどうかや、その機能が使えるかどうかについて、普段チェック担当者が無意識に1ステップで確認している事項を、明示的に複数のステップを設けて確認するようにしていることがわかります。

また、How to Testの1.では、WCAGの達成基準に独自のチェック内容が加えられています。

達成基準 1.4.2 音声の制御では、

1.4.2 音声の制御: ウェブページ上にある音声が自動的に再生され、3秒より長く続く場合、その音声を一時停止又は停止するメカニズム、もしくはシステム全体の音量レベルに影響を与えずに音量レベルを調整できるメカニズムが利用できる。 (レベル A)

のように規定されています。
しかし、

1. Determine if there is a mechanism within the first three elements encountered for the user to pause or stop the audio or to control the volume of only the auto-playing audio.

では、「ユーザーが出会う最初の3つの要素以内で」という条件が加えられています。これは、3秒以内に音声が一時停止、停止、または音量の調整の機能が利用できる、と判断する条件が、テスト担当者によって異なる場合があるために、Trusted Testerのテストプロセス独自の指定を行ったものと考えられます。

なお、達成基準に適合するには「3秒以内に止められるようにする」「3秒以内に音量をユーザーの意図する大きさへ調整することができる」以外に「自動再生しないようにする」という判断も可能ですが、実装に対しての提案はこのテストプロセスに含みません。また、テスト結果のレポートの作成もTrusted Testerの作業手順には含まれていません。テスト対象のサイトに対する総合的判断も別のプロセスで対応するものとしてTrusted Testerの作業手順からは切り出されています。

テスト担当者への教育

Trusted Testerには教育プログラムが用意されているのも特色の1つと言ってよいと思います。前述のようにWCAGに独自のチェック基準を設けている項目もありますが、基本的にはWCAG 2.0 AAに適合することを求めるものですので、Trusted Testerの教育プログラムはWCAG 2.0 AAを理解する教育プログラムの1つであると考えてよいと思います。 プログラムについて注意が必要なのは、一部、Section 508の基準への適合を求める項目があることと、Trusted Testerを前提とした説明なので達成基準そのものを説明する内容ではないということです。そのため、WCAGをこれから学ぶ人にはあまり向きません。アクセシビリティチェックの経験があり、WCAGにある程度親しんでいる人向きと言えるでしょう。
適合テストごとに理解度チェックテストがあり、通してすべて受講し試験を受けることでCertificateも発行されます（先日私も受講し、試験に合格しました。受講内容に沿ったテストなので難易度は高くありませんが、合格するとやはり嬉しいものですね）。
英語のみですが、オンラインかつ無料で提供されていますので、興味のある方は気軽に試してみていただければと思います。

最後に

駆け足でのご紹介でしたがいかがでしたでしょうか。世界各国では、米国のように法制度の整備と技術基準とをあわせて運用するなど、より効果的なアクセシビリティ対応を目指してさまざまな取り組みがすすめられています。 いずれ何かの機会に、Trusted Testerでの実際のチェック結果や、他国のアクセシビリティ対応の取り組みについて、さらにご紹介できればと思います。

この記事はミツエーリンクス Advent Calendar 2020 - Adventarの10日目の記事です。

こんにちは。アクセシビリティ・エンジニアの大塚です。

突然ですが、この記事をご覧になっている方の中には、FacebookやInstagramを利用されている方も多くいらっしゃるかと思います。そして、投稿する際に、文章に加え、画像をアップロードすることも多々あるでしょう。ところで、FacebookやInstagramに投稿される画像には、自動的に画像の説明（代替テキスト）が設定されることをご存じでしょうか。

少し私自身について補足しますと、私は視覚に障害があり、日常的にスクリーンリーダーを利用しています。各種スクリーンリーダーでFacebookやInstagramにアクセスすると、画像の説明として自動生成されたテキストが読み上げられます。そのため、自動生成された説明は、画像に関する情報を得るための重要な手掛かりの1つとなっています。

今回は、FacebookやInstagramで利用できる自動代替テキスト機能の紹介と、個人的な今後への期待をまとめたいと思います。なお、下記に示すように、FacebookやInstagramでは、手動で代替テキストを設定することもできます。高機能化が進んでいるとはいえ、現在の自動代替テキストの現状を踏まえると、やはり可能な限り手動で適切な代替テキストを記載する必要があると考えています。それを前提に、記事をお読みいただければと思います。

• Facebook上の写真の代替テキストを編集するにはどうすればよいですか。 | Facebookヘルプセンター | Facebook
• Instagramの写真の代替テキストを編集するには、どうすればよいですか。 | Instagramヘルプセンター

自動代替テキストとは

自動代替テキストは、FacebookやInstagramで利用できる機能で、画像認識技術を利用して生成された説明が、アップロードされた画像の代替テキストとして設定されます。利用するための設定などは特に必要ありません。

この機能は、まず2016年にFacebookで利用できるようになり、当初は英語の説明が生成されていました（Under the hood: Building accessibility tools for the visually impaired on Facebook - Facebook Engineering）。その後、2018年にInstagramでもFacebookと同じ技術を利用した自動代替テキスト機能が利用できるようになりました（Instagramのアクセシビリティを向上する取り組み | Instagram Blog）。その際に日本語にも対応し、Facebook、Instagramそれぞれで日本語による画像の説明が利用できるようになりました。

それでは、実際どのような説明が生成されるのでしょうか。自動代替テキストが日本語で利用できるようになった当初は、画像に含まれているであろう要素を比較的大ざっぱに読み上げていました。例えば、複数人で記念撮影を行った写真では、「画像に含まれている可能性があるもの：屋外、1人以上」などと読み上げていました。なんとなく画像の内容をイメージできるでしょうか。しかし、屋外で撮影されたことがわかっても、例えばどの程度の人がいるのかはわかりません。

現在では、説明される項目もより詳細になり、写真によっては表情や英語のテキストなどを読み上げるようになりつつあります。例えば、先ほど挙げたような複数人が写る写真については、「画像に含まれている可能性があるもの：3人、スマイル、屋外」などと読み上げます。また、ミツエーリンクスのInstagramに掲載されたテックラウンジについて紹介する投稿の写真には、「画像に含まれている可能性があるもの:『IW1/ Mitsue Tech Lounge vol.89』というテキスト」（原文ママ）という説明がつけられています。なお、2020年12月1日現在、スクリーンリーダーを有効にして上記のページを開くと、画像の説明として「テキスト」とだけ読み上げられる場合があります。ミツエーリンクスのInstagramのプロフィールページから該当の投稿を確認すると、テキスト情報が読み上げられます。

自動代替テキストの課題

機能の向上が進む自動代替テキストですが、説明の精度や日本語のテキスト認識など、まだ課題があるようにも思います。

まず説明の精度については、現状でも説明が大ざっぱで、画像について想像しづらいことがあります。例えば、肉料理や魚料理などといった食べ物の画像にはどれもほぼ例外なく「食べ物」という説明が設定されます。また、テキスト認識については、英語のテキストは比較的認識されますが、日本語については多くの場合「テキスト」とだけ認識され、内容を把握することはできません。

今後への期待

そんな自動代替テキスト機能に、個人的に今後期待していることをいくつか挙げてみたいと思います。

まず、画像についての説明がより詳細なものになってほしいと感じます。例えば、人が写る画像に含まれる長袖、半袖といった服の形状に関する情報や、風景を写した画像に含まれる色に関する情報が認識されると、より画像を楽しめるようになるのではと思います。

また、上記でも触れましたが、日本語のテキスト情報の読み上げにも期待したいところです。これについては、最近一度だけ日本語のテキスト情報が含まれた画像の説明をFacebookで読んだことがあるので、現在機能改善が進められているのかもしれません。

まとめ

自動代替テキスト機能が導入される以前に、FacebookやInstagramにアップロードされた画像に関する情報を得るためには、画像情報を読み上げるアプリで読み取るなど、追加の手順を踏む必要がありました。しかし、自動代替テキスト機能によって、画像情報を得るための手順が少なくなり、画像の説明を得るためのハードルが低くなりました。また、サービス開始当初と比べ、説明される項目もかなり増え、特にテキスト情報の読み上げには感動しました。

現在でも説明の不足を感じる場面はありますが、上記に示したように改良が進められており、今後のさらなる改善に期待したいです。

この記事はミツエーリンクス Advent Calendar 2020 - Adventarの9日目の記事です。

WCAGとは

本記事は、Web Content Accessibility Guidelines（以下「WCAG」）を一度読んでから、その難解さに心が折れた、もしくは、今なお折れ続けている方にお贈りします。Webアクセシビリティ品質を向上/改善するための手引き（ガイドライン）となるWCAGですが、本記事をお読みの皆さまは、WCAGの難解さに一度や二度は挫折したことのある方がいらっしゃるかなと思います。私はWCAGで初めてアクセシビリティに触れたので、13回ほど折れました。アクセシビリティの向上/改善を始めるにあたって、まず立ちはだかるのがWCAGを理解することの難しさだと思います。その書きっぷりがイイ感じに頭に入ってこないようになっているからです（個人の感想です）。そんなWCAGに心を折られた方に向けて、WCAGを理解するうえで個人的に役立ったなと思う方法を、今回の記事を通して3つご紹介できればと思います。

1つ目：デザイニングWebアクセシビリティ

WCAGが理解できるようになる方法の1つ目は、株式会社ボーンデジタルから発売されているデザイニングWebアクセシビリティを読むというものです。よくあるアクセシビリティの問題が非常に多くの例を用いて紹介されており、アクセシビリティという言葉に馴染みのない方でも理解やすい内容となっています。これからアクセシビリティ向上/改善をしていこうという方には、ぜひとも読んでいただきたい一冊になります。一方で、1点注意すべきは、この書籍は「WCAG 2.0」をもとにして書かれており、2020年12月現在で勧告されているのは「WCAG 2.1」となっているため、必ずしも最新の情報が記載されているわけではないということです。とはいえ、最初のステップとして理解をしていくには、非常に価値のある書籍になります。

2つ目：チェックツールを使い実際のWebサイトで発生している問題を把握する

WCAGが理解できるようになる方法の2つ目として、チェックツールを使い実際のWebサイトでどのような問題が発生しているのかを把握する方法をご紹介します。皆さまは、WCAG 2.1の達成基準がいくつ存在するかご存知でしょうか。実は、WCAG 2.1の達成基準は78個もあります。一方で、WCAGを理解するときに、この78個もの達成基準を1つ1つ暗記して覚えることが必要かというと、そうではありません。（暗記することができれば、それはそれで凄いことですが）達成基準の1つ1つを完璧に覚えることよりも、実際にWebサイト上で発生している問題を通してユーザーへの影響などの理解を深めていくことが、WCAGを知るうえで重要となります。

問題を把握するためのツール「axe」

Webサイトで発生しているアクセシビリティの問題を把握する方法はいくつかありますが、この記事では「WCAG 2.1」をもとにした複数の達成基準ごとに問題を把握できるaxeをご紹介します。axeは、Chromeの拡張機能としてインストールすることができ、インストール後は開発者ツールの中から使用できます。

「分析する」というボタンを押すと、自動的にアクセシビリティの問題を検出しレポートしてくれます。

レポートでは、問題の影響度合いや、達成基準ごとに問題がどれくらい発生しているのか、どのような問題なのかを説明したり、問題となっているソースを示していたりと、アクセシビリティの問題がかなり詳細に把握できるようになっています。実際に運用しているWebサイトや普段からよく使うWebサイトで発生しているアクセシビリティの問題であれば、それがどのような問題なのかをイメージしやすくなると思います。

3つ目：WCAG 2.1 解説書を読む

WCAGが理解できるようになる方法の最後にご紹介するのは、意外と知られていない（と個人的に思っている）WCAG 2.1 解説書を読むことです。少し理解が難しいWCAG 2.1の達成基準に遭遇した場合は、この文書を読むことをおすすめします。私は、この解説書に何度も救われました。WCAG 2.1解説書とは、ウェブアクセシビリティ基盤委員会（WAIC）がUnderstanding WCAG 2.1のドラフトを翻訳し公開している文書のことです。WCAG 2.1解説書に記載されている内容は下記になります。

• WCAG 2.1 に書かれている達成基準
• その達成基準の意図
• メリット (その達成基準が、どのように障害のある利用者の役に立つのか)
• 事例
• 関連リソース
• その達成基準の十分な達成方法及び達成方法の組み合わせ
• この達成基準の失敗例
• その達成基準を満たすための要求を超えているが、一部のあるいはすべてのコンテンツをさらにアクセシブルにするために用いることのできる参考達成方法。参考達成方法を使用することで、宣言する適合レベルに影響を及ぼすことはない。
• この達成基準における重要な用語 (WCAG 2.1 の用語集から引用)

この内容を見ただけでも、WCAG 2.1解説書の凄さがお分かりいただけると思います。WCAG 2.1を見てもよくわからなかったという方にとっては、まさに感動を覚えるほどの内容が記載されています。個人的に助かった内容としては「達成基準の意図」です。下記に「達成基準の意図」の例を1つ挙げます。

達成基準の意図の例

WCAG 2.1から追加された達成基準に2.1.4 文字キーのショートカットというものがあります。この達成基準の内容は下記になります。

文字 (大文字と小文字を含む)、句読点、数字、又は記号のみを使用したキーボードショートカットがコンテンツに実装されている場合、少なくとも次のいずれかを満たしている:

• 解除
  • ショートカットを解除するメカニズムが利用できる
• 再割り当て
  • 一つ以上の非印字文字 (例えば Ctrl や Alt など) を使用するようにショートカットを再割り当てするメカニズムが利用できる
• フォーカス中にのみ有効化
  • ユーザインタフェース コンポーネントのキーボードショートカットは、そのコンポーネントがフォーカスをもっているときのみ有効になる。

この内容を見て、達成基準の意図や実現方法、発生しうる問題などが理解できる方は、すでに一定以上の知識をお持ちだと思います。ある程度の知識や知見が無ければ、内容を理解することは難しいと思います。一方で、この達成基準の解説書「達成基準 2.1.4: 文字キーのショートカットを理解する」を見てみると、とても分かりやすい例示とともに解説されています。ここでは、個人的にわかりやすいと感じた箇所を2つ引用して紹介します。

1つ目です。下記の箇所では「音声入力の利用者や誤ってキーを押す傾向にあるキーボード利用者」という例を挙げることで、どのようなユーザーに影響があるのかがイメージしやすくなっています。

• 意図
  • 文字キーのショートカットは、多くのキーボード利用者にはうまく機能するが、(入力手段がひとつずつの文字列である) 音声入力の利用者や、誤ってキーを押す傾向にあるキーボード利用者にとっては不適切かつ、いら立たしい。その結果、利用者は単一の文字キー又は二つ以上の連続した文字キーで構成されたショートカットを解除又は再設定できるようにしなければならない。

続いて2つ目です。下記の箇所では、音声入力の利用者が単一キーのショートカットが有効になっているときに「Hey Kim」と話しかけられた状況を想定しています。この状況で、文字キーのショートカットを無効にすることができなければ、意図しないショートカットが機能してしまうという問題が例示されています。

単一文字キーをコントロールとして用いるのは多くのキーボード利用者にとって適切かつ効率的かもしれないが、音声入力の利用者にとって単一キーのショートカットは悲惨なものである。これは、単一キーのみがコマンドを実行するために使用されると、カーソルフォーカスが誤った位置にあると、発話された単語が単一キーコマンドの連発となる可能性があるためである。

例えば、移動 ("k")、アーカイブ ("y")、メッセージをミュート ("m") する一般的なキーボードショートカットを使用しているウェブメールアプリケーションの主ウィンドウ内にカーソルフォーカスがあり、他の人がオフィスに入室して "Hey Kim" と言ったのを音声入力の利用者のマイクが拾った場合、「y」は現在のメッセージをアーカイブする。「k」はひとつ下の会話に移動し、「m」はメッセージ又はスレッドをミュートする。

ここで紹介したように、WCAG 2.1 解説書が達成基準を理解するのに役立つ理由の1つとしては、ユーザーのイメージや、実際にどのような問題が起こるのかが想像しやすくなることにあると思います。この文書の存在を知らなかったという方は、ぜひWCAG 2.1 解説書へアクセスしてみてください。理解が難しかった問題や達成基準が非常にわかりやすく解説されているはずです。

まとめ

今回の記事では、簡単ではありますがWCAGが理解できるようになる方法を3つご紹介しました。アクセシビリティを向上/改善したいけれど、WCAGが難しくて理解ができないという方の一助となれれば幸いです。

この記事はミツエーリンクス Advent Calendar 2020 - Adventarの6日目の記事です。

先月のCNET Japanの選挙のアクセシビリティーを改善するテクノロジー、その道のりは長いという記事の中で次のような文が目に入りました。

問題があるのは、選挙関連のサイトだけではない。ウェブのアクセシビリティーに取り組んでいるaccessiBeのレポートによると、同社が分析した米国のウェブサイトの98％は、完全なアクセシビリティーを提供していないという。

このレポートにざっと目を通したのですが、どういったページを対象にしているのかがはっきりとは書かれていないのでなんともいえない面はあります（1000万以上のWebページで、うち85％がアメリカとカナダ、残り15％がヨーロッパとアジアという文言は見えます）。また、チェックした手法について事細かに書かれているわけではないため、再現するのは難しそうです。それはさておき、Webアクセシビリティの遵守度合いについてはまだまだなサイトが多数である、というのがこのレポートの主張ではあるでしょう。

ところで、日本企業のWebサイトのアクセシビリティ対応の現状はどうなっているのでしょうか？　少なくとも、筆者はまとまったレポートを目にした記憶がありません。そこで、似たようなかたちでざっくりと現状を探ってみようというのがこの記事の趣旨です。

タイトルにも記載したとおり、測定に当たってはGoogleのLighthouseを用いることにしました。LighthouseはオープンソースでWebの診断を自動で行うツールで、Webの品質向上に役立つツールです。Lighthouse全般がどういったものなのかについては、GoogleによるWebサイトパフォーマンス測定ツール「Lighthouse」入門 | さくらのナレッジなどを参照ください。また、LighthouseのWebアクセシビリティの診断については、Dequeのaxeを採用しています。axeに関する説明は、アクセシビリティBlogの記事GoogleがChromeのデベロッパーツールにDequeのaxeを採用も参照ください。

Lighthouseを採用したのは、0から100までの1刻みのスコアをはじき出すという理由のためです。もちろん、スコアが100だからといってアクセシビリティが完璧というわけではない（あくまで機械でテスト可能な項目をすべてパスしただけである点に十分注意する必要がある）のですが、ツールによる計測により、ツールの使用者の恣意性が紛れ込まないという意味では十分ではないかと考えました。

なお、Lighthouseを実際に動作させるに当たっては、lighthouse-batchで一括で処理しています。

対象とする日本企業については、東京証券取引所の第一部に上場している企業から、東証株価指数のTOPIX 500に指定されている企業500社を選定することにしました。これは、東証一部の時価総額、流動性の高い上位500社となります（公式のPDFによる説明）。上場企業の中でどの企業が対象となるのかはTOPIX（東証株価指数） | 日本取引所グループから区分情報を入手できます。

対象とする企業サイトのURLについては、Wikipediaの各企業のページに記載されているURLを基本としました。つまり、各企業のサイトのトップページです。

こうして計測した結果のグラフと数値テーブルは以下のとおりです（実データもアップロードしてありますので、ご興味のある方はあわせて参照ください）。

Lighthouseで何らかのスコア減点対象が見つかったサイトは、500サイト中487サイトに上ります。accessiBeのレポート風にいってしまえば、日本のTOPIX500トップページの97％は、Lighthouseの機械的チェックにより、Webアクセシビリティに何らかの問題がある、ということができるでしょう。手法が違うため、単純には比較できませんが、Lighthouseで機械チェックをしただけで似たような数字をたたき出してくるあたりは、現状としてはこういうものなんだ、と筆者としては額面通り捉えているところではあります。

しかし一方で、グラフを見てもらえるとわかるとおり、多くのサイトは70台～90台に収まっています。これらのサイトにどれほどの差があるのかまでは確認していませんが、単純にChromeのブラウザ開発者ツールでスコアを出したときに、90～100のスコアであれば、緑色で表示されます。90以上のスコアのページをしきい値とするならば、166サイト、全体の33％は一定のWebアクセシビリティの配慮がなされていると考えることもできそうです。また、スコアが50を切るような相対的に問題が多数あると考えられるページは8サイトにとどまっているのも印象的ではあります。

なお、先月の当社木達によるアクセシビリティBlogの記事Web広告研究会が第8回Webグランプリ アクセシビリティ賞を発表にあるうち、優秀賞に選ばれている2つのページがこの記事の調査対象URLでもあったのですが、どちらのサイトもLighthouseでスコアは100を示していました。この賞のニュースリリースでは審査基準が公表されており、

• 参加全61サイトを対象に、Webアクセシビリティチェックツール2種を用い、スコア上位20サイトを選出。
• 二次審査にてWebアクセシビリティ専門家5名が８サイトずつ（１サイトにつき２人の専門家）の審査を行い、順位スコアから上位５サイトを選出。
• 最終審査にて実際にさまざまな障碍を持つ有識者7人が5サイトをストレスなく情報を取得できるかを基準に審査を行い、順位スコアからグランプリを決定いたしました。

となっています。このような賞を取れるサイトは、Lighthouseでスコア100に近いものを出せることが1つの条件になってくるということはいえそうです。

ということで、ごく簡単にですが、TOPIX500対象企業のWebサイトのトップページをLighthouseのスコアで評価してみました。Lighthouseのスコア90をボーダーとすると、500サイトのトップページのうち、1/3のページは一定のWebアクセシビリティの配慮がなされていると考えられます。裏を返せば、2/3のページはWebアクセシビリティとして一定以上の問題を抱えており、改善の余地があるということができるでしょう。今回は単にスコアの分布を示したに過ぎませんが、例えばどういったサイトが高いスコアを出す傾向にあるのかなど、さらなる分析の余地はあるかもしれません。