DHS Trusted Tester Certification 備忘録
はじめに
先日 DHS Trusted Tester Certification を取得しました。本記事は、取得するまでの経過をメモしたものとなります。
DHS Trusted Tester とは
ここでは DHS Trusted Tester について、簡単にではありますが説明します。より詳しい説明をしてくださってる方がいますので、興味を持たれた方はそちらも参照ください。
本資格について
DHS[1]（アメリカ合衆国国土安全保障省）が提供するアクセシビリティに関する資格で、Trusted Tester とは DHS が作成したテストプロセスに則りテストできる証明となります。
Trusted Tester にはソフトウェアやドキュメント、モバイルアプリといった分野もありますが、本資格は "DHS Trusted Tester for Web on Windows" とあるように Web コンテンツが対象となります。
テストは手動で行われ、リハビリテーション法第508条改正（Section 508）の基準に則り、Web コンテンツがアクセシブルであるかを判定します。
テスト結果は最終的には適合性レポート（ACR[2]）にまとめられますが、Trusted Tester の認定を受けている場合、認定時に発行された合格者番号をつけることでテスト結果に信頼性を持たせることができるようになります。
リハビリテーション法第508条改正について
以前書いた記事でも取り上げましたが、米国ではリハビリテーション法第508条改正という連邦法により、連邦政府で提供されるウェブサイトについて WCAG2.0 レベルAA での準拠が義務付けられています。
508条の規格に準拠できているかを確認するためのベースラインが設けられています。主に下記の事項について、項目ごとに整理されています。
- どういったコンテンツが対象か
- 何故そうでなければならないか
- テストの手順と結果
テスト手法の画一化から資格としての認定まで
上記のテストでは、HTMLタグについてるARIA を確認したり、フォントと背景色からコントラスト比を計算したりしなければなりません。そうなるとそれを検査するテスターは、Web 技術に習熟した人材しかなれないことになります。
また人によってテスト手順や結果が異なるのも避けなければなりません。検査する人に関係なく、同じ手順で同じ結果になるのが、テスター側に求められる役割です。
そこで DHS は、共通したテスト手法（テストプロセス）と、そのためのテストツール（ANDIなど）を設けました。テストツールにより、テスターは DevTool で HTMLマークアップ文を見る必要がなくなり、ブラウザ上でテストを進めることができるようになりました。また機械的に判別できる部分は警告として出力してくれる自動チェック機能も搭載されています。
そして上記のための教育プログラムを作り、このプログラムを完了できた人を Trusted Tester として認定するようになっています。
試験及び学習コースについて
試験含む学習コースは、下記サイトから登録し進めることができます。
なお学習プロセス中は使いませんが、実際に運用する際には SCRT[3]を使ってテスト結果一覧を適合性レポートとして作成するようになるのだそうです。
（試験合格後、SCRT のユーザーガイドが証明書と一緒に送られてきます）
学習後の振り返り
ここでは試験を受けた後の時点から、学習内容をQ&A形式で振り返っていきます。
何をするの？
ここでは資格認定までの流れを逆に辿ることで、何が必要なのかを考えていきます。認定までは、大きく分けて 6 つのプロセスがあります。
⑥最終試験
最終試験は、最新のテストプロセスに則り、テストできるかが求められます。
試験問題は 100 問あり、85% 以上の正答率が必要です。
各問題は、（基本的には）それぞれにテストページとテスト ID がランダムに割り振られ、受験者はそれにしたがってページをテストすることになります。そしてその判定（Pass, Fail, Does Not Apply, Not Tested）を選択肢から選んで解答する流れとなります。
試験結果は得点と合否判定のみ表示されます。また試験できる回数は 3 回までという制限があります（制限に達した場合はヘルプデスクに連絡する必要があるとか）。
⑤模擬試験
前述の最終試験が 3 回という制限があるため、まずは模擬試験を受験し合格する必要があります。
こちらは、ほぼ本番と同じ条件の試験で、本番と違って制限なく受験が可能です。
④Trusted Tester トレーニング（Web用）
前述の試験は、最新のテストプロセスに則りテストするものです。ここではそのための詳細を学習していくことになります。
全 20 のトピックに含まれているテスト ID 毎に、下記の内容を学習していくことになります。
- テスト対象となるコンテンツが何か
- テスト方法（テストツールとなる ANDI 等を使い、どうテストしていくか）
- 評価方法（上記のテストから、どういった条件で判定を下すか）
- 各評価のサンプル（テストの際に注目すべき点や、何故その判定になるのか、といった一連の流れを図解を挟んで説明）
③Trusted Tester テストツール
前述のトレーニングでは、テストツールを用いたアクセシビリティ検査を行っていきます。そのためここでは、テストツールの紹介やインストール方法についての説明がなされます。
②第508条基準（Web用）
前述までのトレーニングは、テストという個別具体的な内容でした。これらテストは「様々な障害を抱えた人が、Webコンテンツにアクセスできるか」を検証するためのもので、その土台となるのは WCAG 2.0 です。
そのためここでは WCAG 2.0 と第508条基準の関係性を説明し、後半からは WCAG 2.0 レベル AA までの達成基準を対象に様々な視点で説明がされます。
- どういった障害を持つ人が影響を受けるのか
- 各 ICT 分野（ウェブ、ソフトウェア、モバイルなど）でどのような対応が必要なのか
- 各種事例（適合 不適合それぞれで、何故そう考えるのか）
①第508条について
一番最初となるここでは、前述までの内容の土台となる「そもそも 第508条（改正リハビリテーション法第508条）とは何で、どうして重要なのか」について学習していくことになります。
- その目的や重要性
- 障害の定義や、対象範囲（例：ICT にはどこまで含まれるか）
- 機能的評価基準（Functional Performance Criteria）
必要な環境は？
試験の性質上ほぼ必須となるのは、Windows のデスクトップ環境です。個人的に必要と感じたのは、翻訳を挟みながら進めていくための 2 画面構成です。
テストツールについては、ANDI というブラウザ上で動作するものを使うことになります。
またコントラスト比の検査用として、CCA（Colour Contrast Analyser）という無償ソフトを使います。
デスクトップ環境がほぼ必須
確か、最終試験で画面解像度 1920x1080 の環境が求められます。
試験外ならノートパソコンでも問題ないかもしれませんが、個人的には最初からデスクトップ環境でやったほうがいいと考えています。
ただでさえ英語を翻訳しながらというペナルティを抱えている都合上、画面は見やすいほうが負担が少ないですし、キー操作も多用するので大きなキーボードがあったほうが楽になります。
OSはWindowsがほぼ必須となる
一応 Mac や Linux 系でもできなくはないと思うのですが、はじめにで掲載している画像に "Trusted Tester for Web on Windows" とあるように、受講は Windows を前提としています。
トレーニングのページでも下記のように、「サイトとコースは Windows を想定し それ以外はサポート外です」と書かれています。
IMPORTANT! This site and courses can be accessed using the following OS's and browsers (the versions listed or newer are preferred). Other operating systems and browsers are unsupported on this system.
OS's:
- Microsoft Windows 11
Browsers:
- Microsoft Edge
- Mozilla Firefox
- Google Chrome
本試験でも「この問題はWindowsの解像度◯◯でテストしてください」という但し書きがついたりします。他の OS でもできなくはないとは思うのですが、恐らく問題なく動作できるかの検証は行ってないのだと思います。
テストツールに関しても、ANDI がブラウザ間で挙動が若干異なったり、調べた範囲ですと CCA（Colour Contrast Analyser）[4]の安定動作が Windows のみらしかったりと、特段の事情がなければ Windows を利用して受講するのが無難だと思われます。
画面は、できれば2画面構成が望ましい
個人的に必要だと感じたのは、2画面構成です。翻訳しながらの作業となるので、片方を翻訳ソフトやサイトに使い、もう片方でコースや試験を進めていました。
「ブラウザの翻訳機能を使って、直接翻訳すればいいのでは？」と思われるかもですが、後述の「翻訳精度について」で記していますがオススメはしません。
英語スキルがあって翻訳が不要な方でしたら、1画面でも問題ないと思います。
（試験時に使う最新のテストプロセスを PC 上で閲覧する場合は、2画面の方が楽だとは思いますが）
英語スキルは必須？
基本的に翻訳に頼って進められるのですが、個人的な感想としては、少なくとも高校レベルはあったほうがいいと感じました。
私の場合、全体の 9 割方は翻訳を通して学習や試験を行いました。言い換えれば、残る 1 割の部分については翻訳を使わず英語のままで進めた ことになります。どういった場面でそうしたのかについて、ここで説明をしていきます。
翻訳精度について
基本的には意味が通じるように翻訳してくれるのですが、たまに「？」となる場面がありました。なので、基本的には 講習と翻訳の 2 画面構成にして、わからなくなった時に原文を見比べられる状況にした方がいいと思われます。
表現のブレ
例えば、講習内でよく出てくる単語の 1 つに "Standard" というものがあります。講習内においては「基準」と訳しておけば大体意味が通るのですが、翻訳に渡す文脈によっては「標準」だったり「規格」と訳されることがあります。
これら「基準」「標準」「規格」といった表現のブレを こちら側で「あぁ、ここはこういうことを言ってるんだな」と斟酌してあげる必要があります。
文章の省略
試験問題を訳す際、解く側の視点としては「問題文を正確に訳してほしい」というのがあります。ですが翻訳側は選択肢に繰り返しの表現があった場合、意図的に一部を省略してしまう場面が何度か見られました。
翻訳された選択肢を見て「なにか変だ」と感じた時に、すぐに原文を確認できるようにしておく必要があります。
その他微妙なニュアンス
その他、微妙なニュアンスが必要な場面で、原文を確認する場面がありました。
微妙なニュアンス例
〜 labels such as "Find" and "Search".
翻訳「検索と検索といったラベル」
上記の文は テスト ID 9.C「一貫した識別（同じ機能を果たすコンポーネントにおいて、その名前や説明は一貫したものでなければならない）」で取り上げた例のため、ここでは「探す」と「検索する」といった表現のブレを表現するのが適当でしょうか。
〜 an option to review, confirm, and correct information 〜
翻訳：「確認、確認、修正する」
「見直し、確認、修正する」あたりが適当でしょうか。
Which of the following examples would NOT meet Success Criteria ◯◯ ?
翻訳：次の例のうち、成功基準◯◯に該当しないものはどれでしょう？
該当しない、ではなく「適合しない」が適当でしょうか。例えば "meet criteria" で「基準を満たす」といった意味合いになります。
動画関係
ANDI 機能の解説など、一部の場面で動画による解説があります。字幕は表示されるのですが、英語のみです。
またテストプロセスの中にはメディア（音声や映像、同期メディアなど）に関するテストも含まれ、そこでは下記の事象を判断しなければなりません。
- 音声や映像メディアに対し、トランスクリプトが含まれているか（健常者がそのメディアから受け取れる情報源と同等のものとして文字化できているか）
- 同期メディアのキャプションは適切か（話者の識別など聴覚から受け取れる情報源をきちんと文字化できているか）
- 同期メディアの音声解説は適切か（視覚から受け取れる情報源をきちんとオーディオトラックで説明できているか）
字幕自体は表示されるので、やろうと思えば手打ちで文字起こしして翻訳に通すこともできるでしょう。また、スマートフォンのマイクを使って翻訳アプリで通す方法もアリかもしれません。
ですが時間はかかるので、できるならリスニングで聞き取るのがいいでしょう。幸いなことに、ANDI 解説ビデオなどは ゆっくりはっきりした言い方をしてくれますし、メディアプレイヤーで再生速度も調整できます。
Language機能のテスト
テスト ID 11.A や 11.B では、言語サブタグの検証があります。ID 11.A はページ全体の、11.B はページ内の一部が対象となり、lang 属性が適正かを検査します。
- 必要な箇所に割り振られているか
- IANA のサブタグレジストリの情報と一致しているか
ここではテストページに対し、「このページが何語で書かれているか」や「ページの一部に別言語が使われていないか」を目視で検査する必要があります。
ですので少なくとも、書かれている内容が英語かそれ以外（スペイン語やイタリア語など）かを見分けられる必要があります。
本番試験
試験ではテストページを使って実際にテストしていくことになりますが、このテストページ自体を翻訳することは推奨しません。
例えばLanguage機能のテストで翻訳機能を使ってしまうと、目視での検査が不可能になります。他のテスト ID に関しても、テストにどういった影響があるかがわからないため、テストページは英語のままで表示しておく必要があります。
また個人的には、試験分量に対して負担が大きいと考えています。
試験は 100 問あり、問題文の翻訳だけを行っても解き終わるのに 3 時間前後かかると考えられます。ここにテストページも翻訳していくとなると、試験そのものの負担を考えても集中力が持つかどうかとなってくるでしょう。
試験はどんな感じ？
最終試験で述べた通り、認定を受けるための試験は下記のようになっています。
- 100問の内、85％以上の正答率が必要
- 各設問は、ランダムに割り振られたテストページとテスト ID から適切な判定を選ぶ
- テストに使うのは、テストプロセスとテストツール（ANDI, CCA）
- 試験結果は、点数と合否のみ教えられる
- 3回という受験回数の制限
試験時の感想
単純に正答を断言できる問題は、あまりない
「これどっちにもとれるんじゃ？」という、疑心暗鬼になる問題が結構あったのを覚えてます。
やってることを端的に言えば「テストプロセスに従ってテストして、その判定を答える」というだけです。なので テストプロセス文書と ANDI と CCA があれば、理屈で言えば合格できることになります。
ただ実際には、テストプロセスの文面だけで断定できる問題というのはあまり出てきません。テストページがかなり微妙なラインをついてきたりするので、各テスト ID 間のつながりや、テストの意図といった深い部分まで学べていないと、正答を絞ることが難しく感じるかもしれません。
肉体的・精神的な負担について
100問のテストなので、私は 1 回あたり 3 時間前後かけてました。なので肉体面や精神面でも負担が結構あった覚えがあります。
私の場合は翻訳を挟みつつという状況がまずあるので、問題文と訳文で変なことになっていないかの確認も必要になってきます。テストプロセスは訳したものを印刷して手元に用意してたので、参照するのには苦労はしませんでした。
これから考えている方へ
知っておくと役立つ知識
WCAG に関しては、コース内でも説明を受けるのですが、事前に知っておくとスムーズに進むかもしれません。
HTML, CSS, JavaScript, ARIA 関係は基礎を知っておくだけでも役立つと思います。サーバーサイドまでは必要ありません。
title や lang といった属性、iframe や frame タグ、ARIAに関する内容などをテストしていくことになります。テスト手法の画一化から資格としての認定までで「そのあたりをテストツールで自動判定して〜」という話をしましたが、それでも自分で知っていることはプラスになります。試験の際「ここはこうだから、この選択肢はありえない。だからこっちが正解」と何問かはここの知識に助けられたと思います。
HTML と ARIA に関して、私が参考にした書籍を下記に挙げておきます。試験にはここまでの知識は必要ないのですが、一読するだけでもだいぶ役立つはずです。
試験前でやっておいた方がいいこと
各トピックの「段階的実技試験（Incremental Practical Exam）」を解き直すことをオススメします。
この試験、再試行するたびに別のバリエーションのテストページが提供されテストすることになります。
本試験では試験結果後に正誤は教えてもらえません。一方でこの試験は何度でも受験でき、正誤も教えてくれます。
なのでここで「どんな状況だったら FAIL で、こうなれば PASS になる」という感覚を養っておいたほうが、本番での自信につながると思います。
おわりに
参考文献
ここでは、受講するまでに調べた文献等を掲載しております。
Discussion