CBT (Computer-Based Testing)における QTI コンテンツの位置づけと WCAG JIS の影響について

[murata2makoto]

本 issue は、日本の学校教育で用いられている CBT（Computer Based Testing）におけるQTI コンテンツの位置づけを示し、そのアクセシビリティにWCAG JIS の改定がどんな影響を与えるかを整理する。

1. 日本の学校教育における CBT と QTI

日本の小学校・中学校教育における CBT (特に文部科学省のMEXCBT）では、1EdTech（旧 IMS Global）が策定した QTI（Question and Test Interoperability）が、問題・テストの記述形式として用いられている。

QTI は次のような特徴を持つ。

• QTI は HTML 仕様ではない
• QTI はXMLに基づく言語であり、問題文や設問の構造と意味を記述する
• 実行時には、ブラウザ上で Web 技術（HTML / CSS / JavaScript 等）によりレンダリングされる

2. WCAG JIS 改定が日本の学校教育におけるCBT に与える影響

QTI コンテンツは HTML 文書ではないが、ブラウザ上で提供・操作されるウェブコンテンツであり、WCAGの適用範囲にある。すでに、日本の CBT のアクセシビリティの評価や議論の際にWCAG 2.x が参照されているのが実情である。（例：TAO Testing によるアクセシビリティに関する解説を参照。)

小学校・中学校教育においてアクセシビリティは極めて重要であり、これを考慮しないCBT 運用は、障害者差別解消法等との関係で問題となる可能性がある。

3. 縦書きとルビについて

小学校・中学校教育で用いるCBTでは、縦書き・ルビは必須の機能である。制定中の WCAG JIS が 縦書きおよびルビのアクセシビリティに対処しない場合、こうしたCBTにおいて、縦書きとルビに関するアクセシビリティ基準が存在しないことになる。

QTI 独自のアクセシビリティ基準を設けてそこで縦書きおよびルビに対処するという選択肢も理論上は考えられるが、WCAG は HTML に特化した仕様ではなく、QTI にも当然適用できるはずの仕様である。

備考: EPUBの場合もQTIと同様の事情が存在する。さらに言えば、EPUBとQTIで、縦書きおよびルビに関する別仕様を作ると仕様に統一性がなくなり、さらには実装コストの増加にもつながりかねない。

[MakotoUeki]

@murata2makoto

制定中の WCAG JIS が 縦書きおよびルビのアクセシビリティに対処しない場合

どのような場合がこれに該当するのか、具体例をいくつか挙げていただくことは可能でしょうか？

[momdo]

参考情報として、ウェブアクセシビリティを含む情報アクセシビリティは一般に障害者差別解消法の「環境の整備」に位置づけられており、「環境の整備」は努力義務でしかなく、国内でコンテンツがWCAG等を満たしていない状態がただちに法令違反になるわけではありません。

(4)環境の整備との関係
法第5条においては，個別の場面において，個々の障害者に対して行われる合理的配慮を的確に行うための不特定多数の障害者を主な対象として行われる事前的改善措置（施設や設備のバリアフリー化，意思表示やコミュニケーションを支援するためのサービス・介助者等の人的支援，障害者による円滑な情報の取得・利用・発信のための情報アクセシビリティの向上等をいう。以下同じ。）を，環境の整備として事業者の努力義務としていること。

文部科学省所管事業分野における障害を理由とする差別の解消の推進に関する対応指針の策定についてより

[murata2makoto]

WCAG 等の仕様が法律から直接参照されているわけではない以上、それを満たさない状態が直ちに法令違反になるわけではない、という点はそのとおりです。一方で、アクセシブルでない CBT を学校が生徒に課すことは、条件次第では十分に違法となり得ます。

私は、WCAG JIS がそのような事態を未然に回避するための実効的な指針として機能することを願っています。WCAG JIS は、産業標準化法第1条にいう「公共の福祉の増進に寄与すること」を目的として策定される標準のはずだからです。

[murata2makoto]

@murata2makoto

制定中の WCAG JIS が 縦書きおよびルビのアクセシビリティに対処しない場合

どのような場合がこれに該当するのか、具体例をいくつか挙げていただくことは可能でしょうか？

縦書きがすべて画像になっているということが現実に起こっています。

追伸: 守秘義務のためご説明できないことが多々あります。ご容赦ください。

[MakotoUeki]

@murata2makoto
年の瀬に早速レスポンスをいただき、ありがとうございます。

縦書きがすべて画像になっているということが現実に起こっています。

実際にどのような画像になっているのか次第ではありますが、以下のような問題点は既存の達成基準でカバーされていると考えます。

• 1.4.5 文字画像：テキストで表現可能な文字を画像にしていないか？
• 1.1.1 非テキストコンテンツ：テキストでは表現できずに画像にしているなら、適切な代替テキストが提供されているかどうか？

他に、WCAG 2.2の達成基準でカバーできていない問題点の具体例があれば、ご教示いただけますと幸いです。
※レスポンスは、年明けの仕事始め以降で大丈夫です。

[momdo]

縦書きがすべて画像になっているということが現実に起こっています。

植木さんが挙げられた達成基準のほかに、達成基準1.3.2「意味のあるシーケンス」に抵触するかもしれません。

WCAG 2の「テクニック集」F32の例3のような状況が当てはまりそうです。

[murata2makoto]

ご指摘のとおり、縦書きが画像化されている場合には、1.4.5（文字画像）や 1.1.1（非テキストコンテンツ）などの WCAG 2.x 達成基準に違反しているでしょう。

しかし、私が問題にしているのは、それらが既存の達成基準に違反しているかどうかではありません。縦書きの CBT 問題をアクセシブルに作るにはどうすればよいのか、その設計指針や判断基準が WCAG 2.2に存在しないことを問題視しています。

現状では、

• アクセシビリティを考慮せずに作られた縦書き CBT 問題が実際に存在し

• それらは結果として WCAG 2.x の達成基準に違反している可能性が高い

• しかし「縦書き CBT 問題はどう作るべきか」「どのような実装が期待されるのか」という前向きなガイドラインが存在しない

という状況にあります。

ガイドラインが存在しない以上、

• 作成者側に「縦書き CBT 問題もアクセシブルに作るべきだ」という社会的・制度的な圧力がかかりにくく

• 実際にアクセシブルに作ろうとしても、何を拠り所に設計すればよいのか分からない

という問題が生じます。

私が「制定中の WCAG JIS が縦書きおよびルビのアクセシビリティに対処しない場合」と述べたのは、縦書きやルビを前提としたコンテンツについて、アクセシブルな実装の指針が示されないまま WCAG JIS が成立する場合を指しています。

個々の不適切な実装を既存の達成基準で「違反」と評価できることと、縦書き・ルビを含む日本の教育用 CBT を、どうすれば最初からアクセシブルに設計できるのかを示すこととは、別の問題だと考えています。

[bakera]

特定の実装をアクセシブルに作るための設計指針は、WCAG本体ではなくテクニック集 (Techniques) に入るものかと存じます。
WAICではテクニック集の翻訳と公開も行なっています。
https://waic.jp/translations/WCAG22/Techniques/
(現状では未訳部分もありますが、JIS改正の作業が一段落したタイミングで急ピッチで進めたいと思っています。)

Techniques は随時更新・追加されており、WCAG本体に新しい達成基準を追加することに比べれば容易に追加できるように見受けられます。GitHubでの議論もある程度活発で、新規追加の提案なども行われているようです。
https://github.com/w3c/wcag/issues?q=is%3Aissue%20state%3Aopen%20label%3ATechniques

本家側の Techniques にCBTをアクセシブルにするテクニックが追加されれば、WAICが公開している日本語訳にも (すぐにというわけにはいかないと思いますが) 反映されます。CBTをアクセシブルにするテクニックをまとめて、本家側の Techniques への追加を提案する、という方法が良いのではないかと思います。

[MakotoUeki]

@murata2makoto

• それらは結果として WCAG 2.x の達成基準に違反している可能性が高い
• しかし「縦書き CBT 問題はどう作るべきか」「どのような実装が期待されるのか」という前向きなガイドラインが存在しない

該当する達成基準がある場合は、太田さん（@bakera)さんもおっしゃっている通り、その達成基準を満たすことができる方法（Sufficient teachnique）として新規追加の提案をAGWGに行うのがよいかと思います。

WCAGの達成基準（normative)は、既存の特定の技術に依存することなく、将来の新技術を含むあらゆる技術にも適用できるように、コンテンツがどうあるべきかを定めています。そのため、書きっぷりも抽象度が高くなっています。

そこで、各達成基準を念頭に、どう作るべき、どのような実装が期待されるのかについては、具体的なテクニック（informative）として代表的なものが文書化されています。

• G（General）：あらゆる技術に適用可能
  • 例：G94: Providing short text alternative for non-text content that serves the same purpose and presents the same information as the non-text content
• H（HTML）：HTML特有のテクニック
  • 例：H37: Using alt attributes on img elements
• PDF（PDF）：PDF特有のテクニック
  • 例：PDF1: Applying text alternatives to images with the Alt entry in PDF documents

TPACでも話題に上がったルビを例に挙げれば、「1.3.1 情報及び関係性」の達成基準に対して、例えば「ルビと元の文字との関係性を示すためにruby要素を用いる（Using ruby elements to associate ruby text with base text)」というようなHTML向けのテクニックを新たに追加することが可能です。HTML以外の技術でも、実装方法が存在するなら同様に対処可能です。テクニックの新規追加は、随時誰でもAGWGに提案できます。
※逆に、よくある悪い例を失敗例（Failure = informative）として追加することも可能ではあります。

もともと、WCAG 2.ｘは、抽象度の高いWCAGを常にup to dateに保っていくために、各達成基準（normative）を満たすことができる具体的な方法（テクニック：Sufficient techniques）はinformativeにして随時追加・更新可能にしてある次第です。ただし、既存の文書化されたテクニックは、全ての方法を網羅できているわけではありません。

改めまして、明らかにアクセシビリティの問題として存在するが、(1) WCAG 2.2にはその問題に該当する達成基準がない、あるいは (2) 基準の数値等を日本語向けに変更すべきである、という事例があればご教示いただけましたら幸いです。
※年明けの仕事始め以降で大丈夫です。

[murata2makoto]

年内に概略だけお返事します。

ルビについてはfailure techniqueで対処しようという議論がTPACであったのはご存じの通りで、以下のissueがすでに上がっています。これの結論をWCAG JISではどう取り込むべきでしょうかね？

w3c/wcag#4746

言語依存の振舞いについてregistryを使うと言う話が出たのもご存じだと思います。その後、Kevinはこの方向を断念しました。仕切り直しになったWCAG3 subgroupで話し合われる可能性はありますが見通しはたっていません。

詳細はまた来年にしましょう。良いお年を。

[MakotoUeki]

@murata2makoto

ルビについてはfailure techniqueで対処しようという議論がTPACであったのはご存じの通りで、以下のissueがすでに上がっています。これの結論をWCAG JISではどう取り込むべきでしょうかね？

ルビに限らず、Sufficient technique あるいは Common failure に追加があれば、WAICで順次翻訳していくと思いますが、TechniqueやFailureで解決できるレベルの事項に関しては、いずれにしてもInformativeなのでJIS改定には影響しない話だと考えます。

言語依存の振舞いについて

WCAGでの対応を優先するなら、現状ではおそらくWCAG3でということになるので、AGWGで年明けから次のフェーズに入っていくサブグループに参加されることをお奨めします。今回のJIS改定に関しては、当然間に合わないでしょう。

もしそれと並行して、JIS X 8341-3の改定版（Normative）でも何らかの対処が必要だというお考えであれば、まずは具体的な問題点の共有と対処法のご提案が急がれているという認識でおります。

ともかく、来年引き続き議論してまいりましょう。良いお年をお迎えください。

[momdo]

関連issue：

• EPUBとHTMLの関係、EPUB Accessibility仕様とWCAGの関係について（背景説明） #1902
• WCAG 3 と WCAG 2.3の実現可能性について（背景説明） #1911
• 学術情報流通基盤（J-STAGE）における JATS ベース日本語縦書き学術論文（背景説明） #1922
• 学習者用デジタル教科書における縦書き（背景説明） #1923
• WCAG JISをIDTとして制定することがW3Cに与えるメッセージ #1934
• 規格本文を否定する注はJIS規格に入れられない #1940

[MakotoUeki]

言語依存の振舞いについてregistryを使うと言う話が出たのもご存じだと思います。その後、Kevinはこの方向を断念しました。

Kevinは断念はしていないと思われ、昨夜のAGWGミーティングで以下のスライドを資料として、Registryを採用するアイデアについてKevinから説明があり、活発な意見交換が行われました。
https://docs.google.com/presentation/d/1qeMPo8a9bQ9yBvk0Ph4YJ15hjyYD3wE61KHcMHtkUJA/edit?slide=id.p#slide=id.p

その議論でもやはり感じたのですが、具体的な事例がないと共通の問題意識を醸成しにくいように思います。昨年末にもこちらのスレッドで以下のお願いをさせていただきましたが、事例をいくつかご教示いただくことは可能でしょうか？

改めまして、明らかにアクセシビリティの問題として存在するが、(1) WCAG 2.2にはその問題に該当する達成基準がない、あるいは (2) 基準の数値等を日本語向けに変更すべきである、という事例があればご教示いただけましたら幸いです。

例えば、挙げていただくそれぞれの問題に対して、以下のような解決策を何らかご提示いただけると大変助かります。

• WCAG 2.2の達成基準にある数値を日本語向けにこのように変更するとよい
• WCAG 2.2の達成基準をこのように改善するとよい
• このような新しい基準が必要である

話が少し逸れるかもしれませんが、W3CのGitHubでのIssueも拝読しました。私自身不勉強なもので十分に理解できておらず、やはり具体的な問題点の事例があると問題意識の共有と理解が進みそうです。

• Ambiguity of the term "character" and its impact on internationalization and testability #546
• Ambiguity of the term "word" and its impact on internationalization and testability #547

事例をご共有いただくことが、JIS改定はもちろん、W3CのAGWGにおけるWCAG 2.2での対応およびWCAG 3の検討において不可欠であると感じている次第です。お手数をおかけしますが、まずは問題となる事例だけでも結構ですので、ご教示いただけますと大変ありがたいです。よろしくお願い申し上げます。

[murata2makoto]

ご指摘ありがとうございます。いただいたご質問について、現時点でお答えできる範囲を以下に整理します。

1. “character”について

“character”の定義は、Unicodeや書記体系との関係を含むため、簡潔に説明することが難しい論点です。文章による要約よりも、具体例を伴う解説の方が理解しやすいと考えています。

そのため、まずは文字情報技術促進協議会によるビデオチュートリアルをご参照ください。日本語に関する範囲に限定した説明が行われています。

その上で、必要に応じて、私のこれまでのコメントで参照している資料をご覧いただければと思います。

2. 詳細な事例提示についての立場

まず、WCAGの翻訳作業において、長年にわたり多くの関係者が継続的に努力を重ねてこられたことについては、高く評価されるべきものであると考えています。その労力や誠実さを否定する意図は一切ありません。

一方で、現状の原案作成プロセスにおいては、より詳細な技術論点をこの場で提示することは適切ではないと判断しています。JIS規格の議論および原案作成においては、国際的な標準化プロセスと同様に、公開性が担保されていることが不可欠だからです。

今回のJIS原案作成はCSBスキームに基づいて行われていますが、CSBスキームでは、原案作成プロセスに関して、

当該原案によって直接的および実質的に影響を受けるすべての人々に対して、原案作成への参加機会が認められていること

が要件として定められています。当該原案によって直接的および実質的に影響を受ける立場にあるにもかかわらず、私自身が原案作成委員会への参加を認められていないことから、この要件は満たされていないと判断しています。

詳細については、以下の資料をご参照ください。

https://webdesk.jsa.or.jp/pdf/dev/md_1785.pdf