W3Cからアナウンスがあるように、2021年3月2日付けでWAI-ARIA 1.2のCandidate Recommendation（勧告候補）が公開されました。（参考日本語訳）

今回のCandidate Recommendationとしての公開は、前回のWorking Draft（作業草案）の公開が2019年12月のことでしたから、おおよそ1年ぶりの更新となります。（前回のWorking Draftについては2019年末に更新されたWAI-ARIA 1.2についても参照ください）

直近のWorking Draftからの変更点については、Change Log（変更点）のセクションに記載されていますが、特に新しいロールなどが追加されているものではなく、もっぱら既存機能の明確化となっています。

今後の動向ですが、WAI-ARIAの策定作業を行っているARIA Working Groupの最近の議事録を眺めた限りでは、WAI-ARIA 1.3やWAI-ARIA 1.4という話が出てきています。（2月18日の議事録、2月25日の議事録）

ARIA 1.3や1.4という話自体はARIA Working Group Road Mapにも話が出てきており既定路線ではありますが、現在のRoad Mapは筆者の記憶が正しければ2018年に出されたものであり、若干古いものであることに注意は必要です。いずれにせよ、WAI-ARIA 1.2としてはW3C Recommendation（勧告）にむけての作業が粛々と行われていき、後続の仕様で新機能の追加が行われていくと見てよいでしょう。

先日（1月27日）、筑波技術大学で、「視覚障害者が社会で働くということについて」というテーマで講演させていただきました。

筑波技術大学は、視覚障害・聴覚障害を持つ学生が学ぶ大学で、私も昨年度、同大学の情報システム学科を卒業しました。

講演は、修学基礎B（情報対象）という情報システム学科1年生向けの講義の一環として行いました。修学基礎Bは、学科での学習方法や障害補償機器について、さらに将来のキャリアデザインについて考えるきっかけを作ることを目的とした講義です（参考までに、筑波技術大学のシラバスもご覧ください）。なお、新型コロナウイルス対策のため講演はオンラインで開催されました。

講演では、なぜWebアクセシビリティに興味を持ったのか、就職活動中に感じたこと、現在行っている業務などについてお話ししました。

参加した学生や先生からは、体感的に特にアクセシブルでないサイトの多い業種はあるのか、どういった企業で視覚障害者がアクセシビリティに関する仕事に携われるのかといった質問をいただきました。

参加した学生の中には、入学後一度も大学へ行くことができていないという学生もおり、私が在学していた時とは学習環境が大きく変わっていることを改めて実感しました。そのような状況下で、私の大学生活や就職活動に関する話が、後輩の皆さんにとってどの程度参考になったのか不安ではあるのですが、今後の学生生活やキャリアについて考える材料の1つとしてもらえていれば幸いです。

また、「アクセシビリティに興味がある」と話していた学生がいたことも印象に残っています。今回の講演が、後輩たちがWebを含めたアクセシビリティの改善などにかかわる現場で活躍する1つのきっかけになればと思いました。

Web Content Accessibility Guidelines (WCAG) 2.0とそのマイナーバージョンの後続として開発されている、W3C Accessibility Guidelines (WCAG) 3.0がFirst Public Working Draft（初期公開作業草案）として発行されました。

元の言葉はWeb ContentからW3Cに変更されているものの、略称は同じWCAGになっているのは、WCAGという語がWebアクセシビリティを取り巻く世界ではよく知られている証左と捉えることもできそうです。

そんなWCAG 3.0ですが、Abstract（概要）には以下の1文が記載されています。

W3C Accessibility Guidelines 3.0 is a successor to Web Content Accessibility Guidelines 2.2 [WCAG22] and previous versions, but does not deprecate these versions.

WCAG 2.2（そして2.1や2.0）を廃止するものではないとされているところがまずキーポイントと言えるでしょう。W3Cの技術仕様は新しいものが古いものを置き換えるのがよくあるパターンかと思いますが、このように前のバージョンを廃止しないと明記されているのは珍しいのではないかと思います。またWCAG 2.X（2.0～2.2のこと）とWCAG 3.0との関係性については、

While there is a lot of overlap between WCAG 2.X and WCAG 3.0, WCAG 3.0 includes additional tests and different scoring mechanisms. As a result, WCAG 3.0 is not backwards compatible with WCAG 2.X.

とされています。WCAG 2.XとWCAG 3.0は多くが重複するというのは、例えば、WCAG 3.0の7章にGuidelinesがあり、7.1としてText alternativesが挙げられていますが、これはWCAG 2.Xの1.1 Text Alternativesとまったく同じセクションのタイトルです。WCAG 3.0の7.1節のEditor's Noteでは、

We selected the Text Alternatives guideline to illustrate how WCAG 2.2 success criteria can be moved to WCAG 3.0 with minimal changes.

とあるとおり、WCAG 2.Xの達成基準1.1.1とほぼ同等のものと捉えて差し支えないでしょう。その一方で、WCAG 3.0はスコアリングメカニズム（採点の仕組み）を持つとされています。WCAG 2.Xでは、大規模なサイトでたった1つでも画像の代替テキストの不備があれば、それは即WCAG 2.Xに適合しないことを意味することになるわけです。しかしながら、WCAG 3.0では一定のスコアを獲得すれば、ざっくばらんに言うと合格することになります。なんと素晴らしいことでしょうか......！

このスコアリングメカニズムという言葉だけで飛びつきたくなるところではありますが、ではどうやってスコア付けするのでしょうか。その詳細については6章のScoringに示されており、スコアを付けるに当たっては、5章のTesting（テスト）に示されています。

細かい話については飛ばしますが、具体的に代替テキストであればどうテストするのかについては、Methodと呼ばれるWCAG 2.X達成方法集（Techniques）に似たものでテストを行っていくとあります。これもまた深くは立ち入りませんが、点数を付けるとするならば、まずはimg要素の全部の数を数え上げて、各img要素に適切なalt属性値がついているかどうかの判断をしていく、というのは容易に想像がつくところではあるでしょう。（しっかりと目を通していませんが、そのようなことが実際のMethodでは書かれていると認識しています。）

もちろん、画像はimg要素のみで実装されるものではありません。svg要素で直書きすることもあるでしょうし、CSSを用いて背景画像を挿入することも考えられます。それ以外にも画像に相当するものをWebページに挿入する方法もあるかと思いますが、ともかく画像全体のうち、何パーセントが適切な代替テキストを持っているかが判明したとします。そのパーセンテージでもって、（これもまた途中を飛ばしますが）スコアを算出する、というのが大まかな流れです。スコアは0、1、2、3、4の5段階評価になっています。

さてここまで、代替テキストに限った話をしてきたわけですが、WCAG 2.Xになじみのあるみなさんは、他にも達成基準が存在することをご存じかと思います。達成基準（success criteria）に類似するものをWCAG 3.0ではOutcomesと呼んでいますが、この達成基準相当のOutcomesはスコアを持っているわけです。このスコアを平均して一定以上の数値（現段階では3.5とされている）になってはじめて、Bronzeと呼ばれる適合レベル（WCAG 2.Xで例えて言うところのレベルAのようなもの）を満たすことになります。もちろん、レベルAAやレベルAAAに対応するようなレベルもWCAG 3.0ではあって、それぞれSilver、Goldと名付けられています。

ではWCAG 3.0 BronzeはWCAG 2.XのレベルAに相当するものかと言うと、そういう話にはなっておらず、1.1のAbout WCAG 3.0では、

Content that conforms to WCAG 2.2 A & AA is expected to meet most of the minimum conformance level of this new standard but ...

という具合に、WCAG 3.0 BronzeはWCAG 2.2のレベルAAに相当するように設計されていることになります。本腰を入れてWCAG 2.Xに取り組んでいるサイトであれば、WCAG 3.0のBronzeになっていると宣言することができるかもしれませんが、これから取り組み始めるサイトにとっては、ハードルが高いのではないか、と感じています。

最後に、初期公開作業草案は、W3Cの勧告プロセスの中で勧告になることがゴールであるとすると、まだスタートラインに立ったに過ぎません。WCAG 3.0 Outcomesの上位概念になるGuidelinesのEditor's Noteにあるとおり、

These are early drafts of guidelines included to serve as initial examples.

まだWCAG 3.0のガイドラインはサンプルとして5つ挙げられているに過ぎず、単にWCAG 3.0が全体としてどのような構造になるのかを示しているに過ぎません。

そして、W3C文書に限らず、このような技術文書全般に言えることですが、議論していくにつれ、内容が初期段階と大幅に書き換わっているということも珍しくありません。ですから、遠くない将来にWCAG 3.0が勧告になったときにこの文書を読み返すと、まるで内容が違うということは多いにあり得ます。

筆者もWCAG 3.0を読み始めたばかりですので、そもそもWCAG 3.0作業草案の理解が間違っているところがあるかもしれません。なお、ここまで言及してこなかったのですが、WCAG 3.0はWCAG 2.Xと比較して、かなりわかりやすい英語で書かれています。その結果、機械翻訳にかけても、日本語として自然な翻訳結果を得ることができます。正確なところは、機械翻訳を片手にWCAG 3.0を読み進めていただくのがよいのかなと思っています。

ここまでラフにかつかいつまんでWCAG 3.0を説明してきました（そして、WCAG 3.0の全体を説明できているわけでもありません。WCAG 2.X Understandingに相当する概念にまったく触れていないのです）が、WCAG 2.Xと大胆に構造を変更していることがおわかりのことかと思います。WCAG 2.Xと比較して大規模な変更が行われるわけですから、当然WCAG 3.0が勧告になるには多くの時間が掛かることになります。現時点でWCAG 3.0を策定するAccessibility Guideline Working Groupによる勧告までの予定スケジュールは確認できないのですが、個人的な予想をここであえてするならば、次のオリンピックイヤーとなる（このコロナ禍にあって、オリンピックがどうなるのかは非常に不透明になっていますが）、2024年が勧告の最速の年になってくるかと思われます。あるいは、2025年の大阪万博が予定通り開催された時点になっても、まだWCAG 3.0は勧告の見込みが立っていないこともあるでしょう。

いずれにしても、たとえWCAG 3.0が勧告となったとしても、冒頭でも記載したとおり、WCAG 2.Xは依然として有効であると明言されています。長期的にはWCAG 3.0に移行することがあると思われますが、ガイドラインという意味では短期的にはWCAG 2.2の勧告を控えています。ですから、まずはWCAG 2.2の最終形態として、WCAG 2.1からどのような達成基準が追加されるのかというところが当面のフォーカスになってくると個人的には考えています。

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

実際に、昨年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での実際のチェック結果や、他国のアクセシビリティ対応の取り組みについて、さらにご紹介できればと思います。