PDFの技術コミュニティであるPDF Associationが、先月にPDF techniques for accessibility: a new modelという記事を出しているのを見かけました。

ある程度WCAG 2に通じている方であれば、WCAG 2.0達成方法集（原文はTechniques for WCAG 2.0）をご存じのことかと思います。 この中には、PDFの達成方法が23ほど存在しています。しかし、この「PDFの達成方法」は、WCAG 2.0が公開された2008年からマイナーな更新こそありましたが、Techniques for WCAG 2.2となった現在でも本質的な変更はなく、古い情報のままとなっています。

この問題に対して、PDF Associationは今年中に36の"Fundamental" Techniquesを公開する予定としています。さらに、2024年にはさまざまなPDFコンテンツをカバーする"Use case" Techniquesを公開するとしています。現在、160を超えるTechniquesの候補を開発しているとのことです。

現時点ではPDF Accessibility Techniques - Example PASS & FAILとして、PASSとFAILが1つずつ例示されています。例の中では、ベンダー中立な説明、サンプルPDFファイル、Techniques for WCAG 2をモデルにした検証手順、対応するWCAG 2.2の達成基準、該当するMatterhorn Protocolのチェックポイントが提供されており、アクセシブルなPDFの作成に関するさまざまな情報が詰まっていることがわかります。

この新しいPDF techniquesにより、ISO 14289-1 (PDF/UA-1)に適合するようなPDFのタグ付けや、PDFのタグのチェックする方法に関して学習することができるようになると思われます。アクセシブルなPDFを作成するための情報が乏しい中、信頼できる情報源（PDF Associationは、PDF規格を策定するISO/TC 171/SC 2のリエゾンです）によるわかりやすい情報提供がなされることは非常に有意義だと考えます。

W3Cからアナウンスされたように、WCAG 2.2が2023年10月5日付けで勧告（Recommendation）となりました。 WCAG 2.1の最初の勧告が2018年ですから、そこから5年が経って達成基準（Success Criterion）が追加されたことになります。

WCAG 2.1の勧告について「最初の」とわざわざ言っているのは、WCAG 2.1が先月に更新されたことによります（W3Cのアナウンス）。 WCAG 2.1の更新の内容はもっぱらエラッタの適用ですが（WCAG 2.1のChange Logも参照）、その中でも達成基準4.1.1について注記が追加されたのが目立った変更点と言えます。

この追記は、端的にはWCAG 2.2では達成基準 4.1.1が削除されているように、達成基準 4.1.1についての評価は別の達成基準で行うようにするという内容です。

さて、WCAG 2.2の話に戻りますと、前回の勧告案（Proposed Recommendation）から今回の勧告での変更点としては、達成基準1.4.12 Text Spacingに注記が加えられています。ちなみに前回のアクセシビリティBlogでWCAG 2.2の勧告案が発行、8月にも勧告へという記事を執筆しましたが、勧告の発行が遅れたのはこの注記周りの作業によるものです。

WCAG 2.1と2.2の技術的な変更点、言いかえるとどのような達成基準が増えているのかについては、What's New in WCAG 2.2を参照してください。

ところで、WCAG 2.2の日本語訳についてどうなるのか気にされている読者もいるかと思われます。筆者が委員として参加しているウェブアクセシビリティ基盤委員会（WAIC）の翻訳作業部会では、まずは更新されたWCAG 2.1の翻訳に着手し、WCAG 2.1の日本語訳の更新が終わった後に、WCAG 2.2の翻訳に取り組む予定です。

また、ISOの動きに関しては、10月3日で行われたAG WGの電話会議の議事録によれば、

16 oct is deadline for ISO submission, and we will work out what goes into ISO version.

月内にもISOに対してWCAG 2.2を提出するようです（これはW3Cスタッフであり、ISOのリエゾン（連絡）も担当しているKevin White氏の発言です）。

ISOがW3Cから提出されたWCAG 2.2受理すれば、ISOの規格策定プロセスに従って今後作業が進んでいくものと思われます。今後のJIS改定については、ISOの規格策定状況をにらみながら、WAIC内部で検討されていくことになると見込んでいます。

W3Cの年次総会に当たるTPAC 2023が9月11日から15日にかけて開催されました。アクセシビリティに関係するワーキンググループも活発にミーティングが行われましたが、ブレイクアウトセッションとして、WAI-ARIAに関係する自動テストのセッションが目を惹きました。2つのセッションについて簡単に触れたいと思います。

1つは、Cross-Browser Automated Accessibility Testing in WPT Interop 2023 and Beyondというセッションです（議事録）。

Interop 2023では、Investigation Efforts（調査の取り組み）として、Accessibility Testingが挙げられています。（Interopとは何なのかについては、フロントエンドBlogのInterop 2023がスタートをご覧ください。）

実際の議論についてはAccessibility Testing Investigation for WPT Interop 2023というGitHubレポジトリで行われており、現在WPTでARIAを含む、約600のアクセシビリティに関する自動テストが行われています（自動テストの結果）。

このセッションでは、これまでの作業の概要（該当issue）の報告や、テストの改善提案（該当issue例）の議論が行われました。

もう1つは、AT-Driver: Get Involvedというセッションです（スライド）。

AT-Driverの話に入る前に、ARIA-ATについて触れておきます。正式名称はARIA and Assistive Technology Community GroupというW3Cのコミュニティーグループです。

How Gaps in Assistive Technology Interoperability Hinder Inclusionという文書によれば、ATつまり支援技術（とくにスクリーンリーダー）は相互運用性に欠ける側面があります。

2つのスクリーンリーダー（SR1とSR2とします）を使って、あるアプリケーションを操作したときに、SR1では

Your Folders Tree View Inbox selected one of ten level one

と話される一方で、SR2では、

Your Folders Table

としか話されないとします。このように、スクリーンリーダーによって出力が異なる状況であれば、相互運用性に欠ける可能性があるということになります。

読み上げ対象箇所にARIAを用いたセマンティクスが提供されたとして、その箇所のセマンティクスがスクリーンリーダーに同じように伝わっているのか（これはSR1とSR2でまったく同じ読み上げがなされるようにするわけではないことに注意してください）について、自動テストを行うというのがARIA-ATの目標となっています。これにより、支援技術の相互運用性のギャップの解消が期待できます。

テストの結果については、ARIA-ATのTest Reportsで一覧することができます。また、ARIA Authoring Practices Guide (APG)のデザインパターンからも結果を見ることができます（例としてModal Dialog）。W3C Blogに4月に投稿されたAnswering "What ARIA can I use?"も参考になるでしょう。

前置きが長くなりましたが、この自動テストを行うにあたって利用されるAT Driverについてセッションで情報共有がされたようです。スライドによればAT-Driverは、

• プログラムによる発話の監視
• キーボード操作のシミュレーション
• 支援技術の設定の変更

といったものが行えるとあります。

このように、ARIA方面で自動テストがホットな話題になっており、標準化や互換性の向上に向けた大きな動きが見て取れ、注視していきたいと思う次第です。

当Blogでは、2019年にWebにおける数式と数式の読み上げを取り巻く環境についてという記事を公開しています。こちらには、記事公開時点でのMathMLの現状や、スクリーンリーダーでの数式の読み上げ方がまとめられています。では、記事の公開から4年近くたつ現在では状況は変化しているのでしょうか。

Web上で数式を表現する方法として、MathMLというものがあり、現状Chrome、Firefox、Safariなどの主要なデスクトップ / モバイル向けのブラウザが対応しています（MathMLの詳細や対応状況についてはMathML | MDNを参照ください）。このほか、MathMLに対応していない環境で数式を表示させるための方法として、MathJaxというJavaScriptライブラリを利用する方法もあります。では、これらの方法で表された数式は、スクリーンリーダーでどのように読み上げられるのでしょうか。

今回は、NVDAとChrome、PC-TalkerとChrome / NetReaderで、先日公開された当社のコラム「数学的トピックスからみた今のAIができないこと、そしてその未来」に書かれている数式をMathMLで表したもの、MathJaxで表したものとして、それぞれ読み上げさせました。

NVDAとChrome

NVDAとChromeでは、それぞれ数式の読み上げ方に違いがみられました。以下は、MathMLで書かれた数式を読み上げさせた際のスピーチビューアの出力です。なお、NVDAでのMathMLの読み上げにはMathPlayerのインストールが必要です。

マーダヴァ-ライプニッツ級数（Σを使わない表記）: 1 minus 1 third plus 1 fifth minus 1 seventh plus 1 ninth minus dot dot dot equals pi over 4

マーダヴァ-ライプニッツ級数（Σを使った表記）: the sum from n equals 0 to infinity of the fraction with numerator open paren negative 1 close paren to the n power and denominator 2 n plus 1 equals pi over 4

ラマヌジャンのπの公式: 1 over pi equals the fraction with numerator 2 the square root of 2 and denominator 99 squared the sum from n equals 0 to infinity of the fraction with numerator 4 n factorial times open paren 1103 plus 26390 n close paren and denominator open paren 4 to the n power 99 to the n power n factorial close paren to the fourth power

このようにMathMLで表した数式を読み上げさせると、デフォルトでは数式や記号を英語として読み上げます。また、読み上げ速度の設定にかかわらず、一部分の読み上げ速度が遅くなってしまいます。数式を日本語で読み上げさせる場合、NVDAの設定を変更する必要があり、NVDAの[設定]の中の[日本語設定]から、[数式を英語で読み上げる]をオフにします。以下は設定変更後に数式を読み上げさせた際のスピーチビューアの出力です。

マーダヴァ-ライプニッツ級数（Σを使わない表記）: 1 マイナス 3 分の 1 プラス 5 分の 1 マイナス 7 分の 1 プラス 9 分の 1 マイナス math axis ellipsis イコール 4 分の パイ

マーダヴァ-ライプニッツ級数（Σを使った表記）: サム エヌ イコール 0 から 無限大 まで 分数 2 エヌ プラス 1 オーバー カッコ マイナス 1 カッコ閉じ の エヌ 乗 分数終了 イコール 4 分の パイ

ラマヌジャンのπの公式: パイ 分の 1 イコール 分数 99 の 2 乗 オーバー 2 square root 2 分数終了 サム エヌ イコール 0 から 無限大 まで 分数 カッコ 4 の エヌ 乗 99 の エヌ 乗 エヌ 感嘆符 カッコ閉じ の 4 乗 オーバー カッコ 4 エヌ カッコ閉じ 感嘆符 times カッコ 1103 プラス 26390 エヌ カッコ閉じ 分数終了

MathJaxについては、デフォルトではMathMLと同じように読み上げました。一方で、MathJaxには、コンテキストメニューから有効にできるアクセシビリティ拡張が標準で含まれており、有効にしたところ、NVDAの設定にかかわらず数式を英語で読み上げました。さらに、無効時の英語読みとは異なった読み上げ方となりました。以下、それぞれの数式を読み上げさせた際のスピーチビューアの出力です。

マーダヴァ-ライプニッツ級数（Σを使わない表記）: 1 minus one third plus one fifth minus one seventh plus one ninth minus midline horizontal ellipsis equals StartFraction pi Over 4 EndFraction

マーダヴァ-ライプニッツ級数（Σを使った表記）: sigma summation Underscript n equals 0 Overscript normal infinity Endscripts StartFraction left parenthesis negative 1 right parenthesis Superscript n Baseline Over 2 n plus 1 EndFraction equals StartFraction pi Over 4 EndFraction

ラマヌジャンのπの公式: StartFraction 1 Over pi EndFraction equals StartFraction 2 StartRoot 2 EndRoot Over 99 squared EndFraction sigma summation Underscript n equals 0 Overscript normal infinity Endscripts StartFraction left parenthesis 4 n right parenthesis factorial left parenthesis 1103 plus 26390 n right parenthesis Over left parenthesis 4 Superscript n Baseline 99 Superscript n Baseline n factorial right parenthesis Superscript 4 Baseline EndFraction

このように、英語として読み上げていることには変わりないのですが、記号の読み方に違いがみられました。また、いずれの組み合わせについても、数式にフォーカスを移動した状態で[enter]キーを押すことで、部分ごとに読み上げるなど、より詳細に数式を確認することができます。

PC-TalkerとChrome / NetReader

PC-TalkerとChromeの組み合わせでは、MathPlayerのインストールの有無にかかわらずMathMLで表された数式を読み上げました。以下は、PC-Talkerでの読み上げの書き起こしです。

マーダヴァ-ライプニッツ級数（Σを使わない表記）: 1 マイナス 1 3 プラス 1 5 マイナス 1 7 プラス 1 9 マイナス テンテンテン イコール 4

マーダヴァ-ライプニッツ級数（Σを使った表記）: シグマ イコール 0 ムゲンダイ カッコ - 1 カッコトジ 2 プラス 1 イコール 4

ラマヌジャンのπの公式: 1 イコール 2 2 9 9 2 シグマ イコール 0 ムゲンダイ カッコ 4 カッコトジ カンタンフ カッコ 1103 プラス 26390 カッコトジ カッコ 4 9 9 カンタンフ カッコトジ 4

このように、数式や記号は日本語として読み上げられたものの、一部の記号は読み上げられませんでした。また、数式を一度には読み上げず、一つの数式を確認するために何度も矢印キーを押す必要がありました。

一方、PC-TalkerとNetReaderの組み合わせでは、どちらの数式についてもデフォルトの閲覧モードでは読み飛ばしてしまいました。Chromiumモードへと切り替えることで読み上げさせることはできるものの、読み上げ方はChromeとの組み合わせの時と変わりませんでした。そのため、一部の記号を読み上げなかったり、数式を一度に読み上げなかったりしました。また、いずれの組み合わせについても部分ごとに数式を確認するといったことは行えませんでした。

冒頭に紹介した記事が書かれた2019年と比較すると、MathMLがより多くのブラウザでサポートされるようになり、ブラウザ上で手軽に数式が表示できる環境が整いつつあります。また、数式の読み上げについても、特にNVDAを利用することで詳細に読み上げさせることができました。

ただ、現状数式を読み上げさせるためにはMathPlayerのインストールが必要であり、さらに日本語で数式を読み上げさせるためにはNVDAの設定を変更する必要があることから、若干のハードルを感じたというのが個人的な印象です。さらに、PC-Talkerでの数式の読み上げについてはどのブラウザとの組み合わせについても課題がみられました。

現状、特に複雑な数式を多くのスクリーンリーダーとブラウザの組み合わせで読み上げさせる場合、MathMLとMathJaxそれぞれでの数式の記載を検討すると良いのではないでしょうか。また、それほど複雑ではないものの、より多くの人が必要としているような数式については、確実に読み上げさせることができるプレーンテキストでの記載も検討すると良いでしょう。

今年3月、TechFeed Experts Night#14 〜 絶対役立つ！最先端のCSS総ざらいにおいて「State of CSS 2022に見るアクセシビリティ関連機能」と題したライトニングトークを行いました。

使用したスライドや録画は「TechFeed Experts Night#14」に登壇でご覧になれますが、そのなかで発表したアクセシビリティ関連機能の認知度の低さは、以下のランキングの通りでした。括弧内の数値は、「聞いたことがない（Never heard of it）」と回答した人の割合です。

1. 第1位：forced-colors（91.2%）
2. 第2位：color-contrast()（73%）
3. 第3位：prefers-contrast（66.9%）
4. 第4位：color-scheme（60.8%）
5. 第5位：prefers-reduced-data（60.3%）
6. 第6位：:focus-visible（37%）
7. 第7位：prefers-reduced-motion（30.6%）
8. 第8位：prefers-color-scheme（27.2%）

先日、State of CSS 2023の結果が公開されましたので、同様に2023年版で取り上げられたアクセシビリティ機能につき認知度の低さランキングを作ってみました（括弧内の数値は「聞いたことがない」人の割合）。

1. 第1位：forced-colors（84.6%、前回から6.6%改善）
2. 第2位：prefers-reduced-data（56.3%、前回から4%改善）
3. 第3位：prefers-contrast（52.7%、前回から14.2%改善）
4. 第4位：color-scheme（41.6%、前回から19.2%改善）
5. 第5位：:focus-visible（30.1%、前回から6.9%改善）
6. 第6位：prefers-reduced-motion（27.7%、前回から2.9%改善）
7. 第7位：prefers-color-scheme（19.8%、前回から7.4%改善）

2022年版の結果と比べ、順位に目立った変化はなかったものの、すべての機能において認知度は改善されているようです。とりわけ、prefers-contrastとcolor-schemeの2つが、ほかと比べ認知度が顕著に上がっているのが興味深いです。

なお、State of CSS 2023のサイトでSara Soueidan氏が2023年の一押しに選んだcolor-contrast()改めcontrast-color()ですが、調査項目からは外されています。理由は明記されていませんが、State of CSS 2023 Questions Feedback · Issue #84 · Devographics/surveysでのやり取りから、経緯は把握できます。仕様に書かれている通り「Not Ready For Implementation」、実装には時期尚早というステータスですし、妥当な判断だと思いました。

先月の話になりますが、WCAG 3.0の作業草案（Working Draft）が更新されていました。

2021年6月にWCAG 3.0の草案が更新でも書いているのを思い出しましたが、相変わらずChange logのセクションは見出しのみ存在していて、内容は空という状況が続いています。何がどう変わったのか、しっかりと記録してもらいたいところです。 さて、1つ前の草案から実際にはどう変わったのかですが、少なくとも表面上は章の構成自体が大幅に変更されています。また、一見すると、進展はないように見える箇所もあります。例えば、前の草案では3章にあったGuidelinesではいくつかの例が示されていましたが、今回の草案では2章にあるGuidelinesでは、見出しのみになっています。その意味では、前進したというよりかはむしろ後退したようにも捉えられます。

ところで、このGuidelinesの章には、見出し付近に「Placeholder」というステータスが付与されています。このステータスについては、1.2 Section status levelsで5つの段階で言及されています。「Placeholder」については5つのうち、最初の段階のもので、以下のように記載されています。

Placeholder: This content is temporary. It showcases the type of content or section to expect here. All of this is expected to be replaced. No feedback is needed on placeholder content.

これは簡単に言ってしまえば、仮置きという状態とのことです。今回の草案でのGuidelinesは、いわば「イメージ」であって、具体的には一切決まっていないと捉えることができます。前回までの草案では、Guidelinesの中身を記載してみたものの、具体的な記述がかえって混乱を招くと判断されたのでしょうか。もしかしたら、WCAG2でいう達成基準について、具体的なものを想像しながらWCAG 3.0を考えていく、ということを現段階であまりしてほしくないのかもしれません。いずれにせよ、何も決まっていないわけですから、そのような捉え方をしないのがよいのでしょう。

ステータスについては、今回の草案で3番目の「Developing」とされるものがもっとも進んだものであり、3.3 Outcomes and methodsと3.4 Assertions and proceduresという2つの節に付与されています。

この2つの節について説明されているのが、3.2 Approaches to conformanceという節です（3.2節には何もステータスが付与されていないようですが、3章には2番目のステータスにあたる「Exploratory」が付与されています）。具体的には以下のように書かれています。

There are two main approaches to evaluating accessibility that are promising. There are also detailed ideas that support these approaches. The two main approaches are:

• Outcomes with tests: Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline. Outcomes are addressed in Section 3.3.1 Outcomes. Tests are addressed in Section 3.3.2 Testing Outcomes.
• Assertions and procedures: Assertions are attributable statements by a person or organization that they followed a procedure to improve accessibility. Assertions are addressed in Section 3.4.1 Assertions.

3.3節の「Outcomes」はこれまでのWCAG 3.0の草案にも出てきましたが、ここではGuidelineで決められたものを満たしているかどうかについて、アクセシビリティのチェックをする人が確実に検証可能なもの、というように定めています。

一方で、3.4節の「Assertions」は、これまでのWCAG 3.0の草案にはなかったものです。これは、アクセシビリティを向上させるために、ある手順（例えばユーザビリティテスト）を行ったという表明となります。

「Assertions」については、3.4.2 Using assertionsを斜め読みする限りでは、あるGuidelineに対して許可される場合に、testの代わりにAssertionを利用できるというようなアプローチを想定しているようです。

上記の引用箇所の直後には、

There are additional ideas that support these two approaches and can be used or combined in many different ways.

とあり、2つをサポートする追加のアイデアとして、

• 3.5 Conformance levels
• 3.6 Issue severity
• 3.7 Adjectival ratings
• 3.9 Pre-assessment checks

が挙げられています。果たしてConformance levelsが「追加のアイデア」という位置付けでよいのかどうかが謎ですが、いずれにせよそのように記載されています。また、上記の追加のアイデアのリストから、なぜか3.8 Percentagesが飛ばされていますが、ここではあまり深く考えないことにします。

このように若干の進展があるものの、前回の草案の発行が2021年12月であり、1年半以上の期間が開いての更新となると、あまりよいペースには見えません。WCAG 3.0の具体的な姿が見えてくるのはまだまだ先のことだと思われます。

もっとも、当Blogで逐次お伝えしているとおり、WCAG 2.2の策定が並行して行われています。WCAG 2.2に関しては先月の記事で「8月にも勧告へ」と書きましたが、残念ながら現時点では勧告には至っていません。WCAG 3.0の進展については、ガイドラインの策定を行っているワーキンググループがWCAG 3.0に注力できるのかどうか次第といったところでしょう。

なお、現時点でのWCAG 3 Introductionに掲げられているTimelineでは、

We plan to publish updated drafts every 3-6 months.

とされてはいます。次の草案について、長い間隔が置かれずに更新される可能性に期待することにしましょう。

昨日オンラインで開催したWeb担当者のためのピンポイント講座、改正障害者差別解消法とWebアクセシビリティには大変多くの方々にご参加いただきました。この場を借りて厚く御礼申し上げます。また、質疑応答の時間ではすべてのご質問に回答することができず、申し訳ございませんでした。

本記事では、開催後にアンケートへのご回答を通じてお寄せいただいたものを含め、いただいたご質問にお答えさせていただきます（セミナーの時間中に回答できたものについては割愛しております、あらかじめご了承ください）。字数の兼ね合いから、回答にご満足・ご納得いただけない場合もあるかと思いますが、その場合には是非お気軽にお問い合わせをいただければ幸いです。

アクセシビリティに対する意識の高さを鑑みると、日本国内サイトよりグローバルサイトを優先的に着手すべきでしょうか？

おっしゃる通り、そのような考え方で優先順位を定義することには、一定の合理性があると考えます。しかし、最終的にどのサイトで優先的にアクセシビリティ向上に取り組むべきかについては、単に法制化の度合いのみならず、実際のユーザーの利用状況（サイトへのアクセス数やユーザーから寄せられる「使えない」「使いにくい」といった声の多寡など）や、ビジネス戦略なども総合的に勘案すべきかと思います。

環境の整備についても今後義務化は予想されますでしょうか。

将来的に、環境の整備が努力義務ではなく法的義務となる可能性はゼロではないと私は思いますし、またそうなって欲しいと個人的に期待もしています。といいますのも、セミナーでご紹介したとおり2020年版のDAREにおいて日本のデジタルアクセシビリティはかなり劣っていましたし、行政機関や公共性の高いサービスを提供する事業者においては特に、事業そのものと環境の整備が不可分と考えるからです。