あけましておめでとうございます。株式会社ミツエーリンクスの中村直樹です。昨年と同じく、2023年のWebアクセシビリティに関連する出来事を振り返りつつ、2024年のWebアクセシビリティの展望について俯瞰していきたいと思います。

WCAG 2.2の勧告とWCAG 2.1の更新

長らく待ちわびていたWCAG 2.2について、2023年10月5日付けでようやくW3C勧告（Recommendation）となりました（日本語訳はまだありません。詳細は後述の「臨時WGの活動状況」を参照⁠）⁠。また、これと連動する形でWCAG 2.1（日本語訳）の勧告も改めて発行されました。

今回のWCAG 2.1の更新では、達成基準4.1.1構文解析に注記が設けられています。これにより、WCAG 2.2で削除された達成基準4.1.1の扱いについて連続性が保たれるようになっています。WCAG 2.1からの変更点は、公式の情報としてWhat's New in WCAG 2.2にまとめられていますが、ここではWCAG 2.2で新たに加わった達成基準（Success Criterion）のうち、個人的に目を惹いた2つについて詳しく見てみましょう。

3.3.8 Accessible Authentication (Minimum)

認知に関する障害がある人の中には、パズルを解く、ユーザー名とパスワードを思い出す、ワンタイムパスコードを再入力するなどが困難な場合があります。パズルを解くなどをWCAG 2.2では用語集でcognitive function testとして定義していますが、そのようなcognitive function testを、ログイン認証のどのステップでも原則として要求しないことをこの達成基準では求めています。

Understanding Success Criterion 3.3.8: Accessible Authentication (Minimum)では、WebAuthnについて言及されていますが、これは「パスキー」のほうが馴染みがあるでしょうか。昨年末にITmedia Mobileにおいてドコモが「パスキー」を導入してフィッシング被害報告が0件に　パスワードレス認証の効果という記事が掲載され、この中で「2023年がパスキーの年と言っても過言ではない」と触れられているように、パスワード不要の認証方法としてのパスキーの認知が広がりつつあります。セキュリティの観点だけでなく、アクセシビリティの観点からも注目すべき技術といえるでしょう。

2.5.8 Target Size (Minimum)

WCAG 2.1では、レベルAAAとして達成基準 2.5.5 ターゲットのサイズがあり、これは44×44 CSSピクセル以上のターゲットのサイズを求めるものです。WCAG 2.2では、レベルAAの2.5.8として、24×24 CSSピクセル以上のサイズを原則として求めています。

具体的にはどのような場合にこの達成基準を満たすのかどうかについては、Understanding Success Criterion 2.5.8: Target Size (Minimum)で詳細に説明されていますので、こちらを参照するのがよいでしょう。

さて、機械的なチェックツールの第一候補として、ブラウザー拡張axe DevToolsを思い浮かべる読者も少なくないと思われます。axe DevToolsのエンジンであるaxe-coreは、GitHubレポジトリにある説明によると、この達成基準のルールは既に存在するものの、執筆時点ではデフォルトで無効になっているようです。どの時点で有効になるかはわかりませんが、将来的にはある程度、自動的にチェックできるようになるものと思われます。

Adrian Roselli氏のBlog記事24×24 Pixel Cursor Bookmarkletでは、ブックマークレットや関連するチェックツールについてまとめられています。手動でチェックするのに必要なツールはここから入手できるでしょう。

WCAG 3.0

W3C Accessibility Guidelines (WCAG) 3.0については、2023年7月に草案が更新されたものの、昨年に技術的な大きな動きはありませんでした。

2023年11月に更新されたAccessibility Guidelines Working Group CharterからWCAG 3 Timelineというスケジュールが記載されたページに飛べます。これによれば、今年の1～3月にguidelinesを、7月～9月にconformance model(s)を更新する予定になっており、それぞれのタイミングでより具体的なものが見えてくるのではないかと思われます。もっとも、これは楽観的なスケジュールですから、終わってみれば今年も対外的には大きな動きはなかった、ということになる可能性もありえます。

JIS改正の動向について

JIS X 8341-3:2016の原案作成団体は、ウェブアクセシビリティ基盤委員会（WAIC）です。実際のJISの改正自体は原案作成委員会を立ち上げ、その中で改正の審議を行うのですが、WAICではその原案作成委員会の立ち上げに向け、臨時のワーキンググループ（以下、臨時WG）を設けて検討を進めている最中です。筆者はこの臨時WGの主査として、原案作成委員会が始動した際に円滑に議論ができるよう、準備活動を進めています。

臨時WGで合意した大きな方針としては、WCAG 2.2をJISにする方向性が固まっています。ただし、どういった枠組みでJIS化するのかは定まっていません。

枠組みが定まっていない一番の要因は、W3CがISO/IEC JTC 1に対して、WCAG 2.2のPAS (Public Available Specification、公開仕様書) submissionをまだ行っていないことにあります（日本産業標準調査会（JISC）のISO/IEC規格の開発手順も参照⁠）⁠。W3Cは、JTC 1のPAS Submitterという地位にあります（W3C PAS FAQも参照⁠）⁠。これは端的に言えば、W3CはW3C勧告をJTC 1に申請すれば、ISO/IECのプロセスでそのW3C勧告をDIS（国際規格原案）として審議できるというもので、一種のファストトラック（Fast-track）です。

W3CがPAS submissionを行っていれば、WCAG 2.2がDISというISO/IECプロセス上の文書ステータスとなって、JISを策定する側として話が整理しやすいのですが、前述のようにまだ申請されていません。PASについては昨年10月が申請の締め切りだったものの、W3Cがこれに間に合わせることができず、次回の4月の申請を目指していると聞いています。つまり、ISO/IECのプロセスにWCAG 2.2が上がってくるのは、早くても今年4月ということになります。

ところで、JIS X 8341-3:2016は、日本規格協会（JSA）のJIS原案作成公募制度を利用したものですが、今回の改定も同様に公募制度を利用して原案作成を行う予定です。言いかえると、改正JISは公募のスケジュールに左右されるわけですが、W3Cが将来にWCAG 2.2をPAS submissionしているのかが現時点で不確定であり、このことがさらにスケジュールを不透明にしています。

このような複雑な状況ではありますが、どのようにJIS化できるのかについては、JSAと相談をしている最中であり、引き続きWAIC内部で検討を行っていく予定です。

臨時WGの活動状況

臨時WGでは、JSAとのJIS化の相談をする一方で、改正予定のJISの内容についても検討を行っているところです。

規格本体に関しては、前述のようにWCAG 2.2とすることで合意がなされていますが、WCAG 2.2日本語訳のブラッシュアップが必要という認識がされています。

WAICでは、記事の冒頭にも述べたように、現時点ではWCAG 2.2日本語訳の公開には至っていません。その一方で、昨年12月にWCAG 2.1の日本語訳を更新したところです（WCAG 2.1 および関連文書 更新のお知らせ⁠）⁠。これは、既存のWCAG 2.1の更新内容と、WCAG 2.2の更新内容が一部重複しているため、WCAG 2.1の更新を取り込んだ上で、WCAG 2.2の日本語訳の作成を行ったほうがよいと判断したことによります。

WCAG 2.2の翻訳作業は常設のWAIC翻訳ワーキンググループで行われている最中ですが、こちらと臨時WGが協調あるいは分担してWCAG 2.2日本語訳のブラッシュアップを行っていく予定です。

また、JIS X 8341-3:2016の附属書JA/JBの取り扱いについても、臨時WG内で議論を進めているところです。一つの大きな関心事項としては、附属書JBとJIS X 8341-3:2016 試験実施ガイドラインが分断されている状況を打開できないかというものがあります。JIS X 8341-3:2016の附属書JBに記載された試験を実施するにあたっては、事実上「試験実施ガイドライン」と一体と見なされていますが、過去の経緯もあって別れてしまっている状況です。

JISが国際規格との一致規格であることを踏まえると、附属書からは削除して、WAICのガイドラインとして一本化するのはどうかという考え方があります。その一方で、後述する「情報アクセシビリティ自己評価様式​」を踏まえると、附属書から削除してしまってよいのかという考え方もあります。附属書の扱いに関しては、臨時WG内でさまざまな観点から議論を行っていく予定です。

情報アクセシビリティ自己評価様式​

2023年4月に第5次障害者基本計画が開始しました。その中では、情報アクセシビリティ自己評価様式の普及促進が謳われています。

製品やサービスを自己評価する既存の枠組みとしては、欧米ではVPAT (Voluntary Product Accessibility Template)が知られています。VPATは、米国リハビリテーション法508条という、障害のある人が情報技術にアクセスできることを求める法律にどの程度準拠できているのかを示すものです。特にソフトウェアに関して大雑把に捉えるなら、技術的にはWCAG 2をどの程度満たせているかを報告する文書であると捉えればよいかと思います。

米国や欧州では、VPATが企業から提供されることによって、製品やサービスが障害者にとってアクセシブルであるかどうかを購入者や利用者が判断できるようにする仕組みになっています。このVPATのような仕組みについて、技術基準をJIS X 8341シリーズとして日本にも取り入れようとしているのが「情報アクセシビリティ自己評価様式」になります。

WAICでは、昨年2月に「障害者基本計画（第５次）案に関する意見募集について」へのパブリックコメントを提出しました。この中では、コメント提出当時に議論されていた自己評価様式について、技術面、運用面で欧米と同様なものになるのかはっきりしないという懸念を示しています。技術面に関しては、関係者を集めた会議体にWAICも参加して、議論が行われている途上であり、その中で懸念点について解消されていくと思われます。

既存のVPATとの互換性について心配される面があるものの、自己評価様式の仕組み自体はアクセシビリティの取り組みを加速させるものです。将来的には政府調達に用いられる可能性もあると考えられます。未知数ではありますが、今後どのように議論が進んでいくのか見守りたいところです。

改正障害者差別解消法の施行とガイドライン

いよいよこの4月から、民間企業の「合理的配慮」が義務化される改正障害者差別解消法が施行されることになります。既に2023年には障害を理由とする差別の解消の推進に関する基本方針が示されており、これに基づく対応指針が改正法の施行までに各省庁から提示されていく運びになっています。

ウェブアクセシビリティを含む情報アクセシビリティは「環境の整備」であり、法的な位置付けが改正法によって変化することはないですが、基本方針では「合理的配慮と環境の整備」として次の例が示されています。

オンラインでの申込手続が必要な場合に、手続を行うためのウェブサイトが障害者にとって利用しづらいものとなっていることから、手続に際しての支援を求める申出があった場合に、求めに応じて電話や電子メールでの対応を行う（合理的配慮の提供）とともに、以後、障害者がオンライン申込みの際に不便を感じることのないよう、ウェブサイトの改良を行う（環境の整備⁠）⁠。

このように合理的配慮の事前準備として、ウェブサイトの改良、つまりアクセシビリティの向上に取り組むことが示されるようになり、ウェブアクセシビリティの注目度合いが高まりつつあります。

しかしその一方で、民間企業がウェブアクセシビリティにどのように取り組んでいけばよいのかというガイドラインは存在しません。従来から公的機関向けにはみんなの公共サイト運用ガイドラインがあるわけですが、法改正により公的機関と民間事業者の法的義務に違いがなくなった一方で、民間事業者向けにはそのようなガイドラインが存在しないという現状は、少々歪な状態にあるといえます。

みんなの公共サイト運用ガイドライン（2016年版）は、JIS X 8341-3の2016年の改正に合わせて更新された経緯があります。次期JIS改正に合わせてみんなの公共サイト運用ガイドラインも更新されることが予想されますが、その際には民間事業者も参照できるようなガイドラインへの改定、あるいは民間事業者向けの新たなガイドラインの策定が望まれるところです。

PDFのアクセシビリティ

PDFのアクセシビリティに関して、PDF/UA-1 (ISO 14289-1)という国際規格があるのですが、これとは別にPDF/UA-2 (ISO 14289-2)という規格の策定が進んでいます。2024年1月時点でUnder publicationの状態にあり、まもなくIS（国際規格）として発行される見込みです。

PDF/UA-2は、Normative Reference（引用規格）としてDPub ARIA（Digital Publishing WAI-ARIA Module）仕様（参考日本語訳）が挙げられています（DIS（国際規格原案）から確認できます⁠）⁠。DPub ARIAというのはおおざっぱには、WAI-ARIAの電子書籍向けの拡張です。付録や脚注などがDPubロールとして定義され、意味を付与できるようになります。

これは、PDFの規格がWAI-ARIAを取り込んだとも解釈できます。WAI-ARIAはもともと、HTMLやSVGのようなマークアップ言語のセマンティックスを拡張するために策定されたものです。非マークアップ言語であるPDFが、マークアップ言語のWAI-ARIAを取り込むという事態は当初想定していなかったはずであり、WAI-ARIAのポテンシャルに驚かされているところです。

さて、HTMLでは、HTML-AAM（HTML Accessibility API Mappings）仕様によって、HTMLの要素とWAI-ARIAのロール、そしてOSのアクセシビリティAPIのマッピングがなされています。これのPDF版にあたる、PDFのタグとARIAロールのマッピング作業について進められているようです。実際に、ISOのリエゾン組織としてPDFの規格策定に参画しているPDF Associationでは、Bridging PDF and Web Accessibilityという記事の中でマッピング作業の一部がExcelで公開されています。

W3CとPDF Associationとの間で著作権をはじめとする権利関係をどう扱うのかという問題はありますが、法的な問題さえ解決すれば、「⁠PDF-AAM」仕様がW3Cのサイトで公開される日が来るのかもしれません。

また、PDF Associationでは、昨年10月にPDF techniques for accessibility: a new modelという記事を公開しています。

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

この状況に対して、PDF Associationが独自のTechniquesを公開する予定としています。オリジナルのTechniques for WCAG 2.0は、特定のアプリケーションに基づく説明でしたが、PDF AssociationによるTechniquesは、ベンダー中立な説明を提供するとのことです。アクセシブルなPDFを作成するための情報が乏しい中、信頼できる情報源によるわかりやすい情報提供がなされることは非常に有意義だといえるでしょう。

ところで、官公庁では、比較的ウェブアクセシビリティに積極的に取り組んでいると思われる組織であっても、PDFファイルをそもそもの対象外としているサイトが見受けられます。例えば、福岡市は可能な限り代替情報の提供に努めるとしていますが、PDFを対象外としています。内閣府も同様に対象外です。ただし、アクセシビリティ方針制定後に内閣府で作成するPDFデータについては、準拠に努めるとして前向きな姿勢を見せています。

デジタル庁では、PDFを試験対象ページから除外しているようです（※記事末尾に追記あり⁠）⁠。ただ、

ウェブページ及びPDF文書を作成する際のフローや各種ガイドライン、アクセシビリティ確認体制の整備などを進めてまいります。

と記載されています。特に官公庁では大量のMS WordやPowerPointが生成され、その大多数はPDFとして公開されている状況にあると考えられます。PDFについては、HTMLでも同じ内容を代替として提供する方法はあり、みんなの公共サイト運用ガイドラインでもそのことに言及していますが、PDFの全部をHTMLにするのは限界があると考えます。また、PDFを取り巻く環境も変化しています。上記引用にあるように、PDF文書を作成する際のガイドラインをデジタル庁から発行することに大いに期待したいところです。