ISO/IEC Guide 71:2014という文書があります。

これは、JIS Z8071:2017としても存在しており、JISのタイトルは「規格におけるアクセシビリティ配慮のための指針」（Guide for addressing accessibility in standards）というものです。

2.19
アクセシブルデザイン（accessible design）
多様な状況において，システムを容易に使用できるユーザーを最大限まで増やすために，多様なユーザーに焦点を当てた設計。

注記1 アクセシブルデザインは，次によって達成される。
a) 修正・改造することなく，ほとんどの人が利用できるようにシステムを設計する。
b) システムをユーザーに合わせて改造できるように設計する（改造可能な操作部などの提供）。
c) インターフェースを標準化し，福祉機器及び支援機器との互換性をもたせる。

注記2 ユニバーサルデザイン，アクセシブルデザイン，デザイン・フォー・オール，バリアフリーデザイン，インクルーシブデザイン，トランスジェネレーショナルデザインなどの用語は，同じ意味で互換的に使用される場合が多い。

ここではアクセシブルという言葉ですが、Webアクセシビリティの説明の文脈で、「ユーザーを最大限まで増やす」というのはあまり聞かない言い回しかと思います。それでも、個人的には言われてみればなるほどと腑に落ちる説明の仕方だと思いました。

注記1をWebアクセシビリティに当てはめることを考えますと、やはり、Web標準に従うことで、互換性を持たせることが根本にあるといえるでしょう。その上で、Webサイトとしては、個々の事情をもったユーザーがカスタマイズできる素地を備えるようにすると解釈できそうです。

また、注記2も興味深いところです。ユニバーサル、アクセシブル、バリアフリー、インクルーシブと似たような言葉があるわけですが、要するに同じ意味と言い切ってしまうのも、わかりやすさを優先した説明としてはありでしょう。（それはそれとして、似た言葉が複数あるというのも複雑な状況ではあると言えますが...。）

Webに関する技術文書として、筆者はW3Cの文書に接することが多いですが、こうしてWebから離れた文書に当たってみることで異なる見方ができると改めて思った次第です。

昨年末のことにはなりますが、無料・オープンソースで利用できるスクリーンリーダーNVDA日本語版のバージョン2021.3jpがリリースされました。

いくつかの機能追加やバグ修正が行われているのですが、今回はChromeでのテーブルの見出しセルの読み上げの改善について簡単に触れたいと思います。そのほかの更新情報については、NVDA 2021.3jpのリリースノートをご覧ください。なお、2021.3jpのリリース後に点字ディスプレイに関連した修正が行われたため、現行の最新バージョンは2021.3.1jpとなります。

NVDAをはじめとする多くのスクリーンリーダーは、テーブルにテーブル見出し（<th>要素）が記載されていると、データセル（<td>要素）の内容を読み上げさせたときに、対応する見出しセルの内容を併せて読み上げます。そのため、テーブルの行と列の対応関係を比較的容易に把握できます。

以前のバージョンのNVDAでは、テーブルの見出しセルの内容を読み上げさせたとき、列の名前を誤って二度読み上げていました。例えば、Tables with two headers • Tables • WAI Web Accessibility TutorialsのExample 1の見出しセルを読み上げさせると、「Monday 2列 Monday」と読み上げていました。

この問題が最新版のNVDAでは改善され、「2列 Monday」と読み上げるようになりました。

スクリーンリーダーを使いWebページを閲覧する際、同じ情報が何度も重複して読み上げられてしまうと、目的の情報を得るために必要以上に時間がかかってしまいます。ただし、以前のバージョンでも内容が重複して読み上げられるのは、見出しセルが記載された列を読み上げたときに限られており、データセルを読み上げさせたときに併せて読み上げられる見出しセルの内容については、正しく一度だけ読み上げられます。

今回はNVDAの直近の更新情報の中から、ブラウザーでの読み上げに影響する項目を取り上げました。NVDAは活発に更新が行われており、Webサイトを効率よく快適に閲覧できるようにするための機能追加や改善も行われています。スクリーンリーダーのユーザーとして、本年はNVDAをはじめとするスクリーンリーダーの動向や周辺情報を定期的に取り上げていきたいと思います。

WAIC（ウェブアクセシビリティ基盤委員会）から告知されているように、WCAG 2.1解説書と達成方法集がそれぞれ更新されています（WCAG 2.1 関連文書 更新のお知らせ）。

前回9月の更新（WCAG 2.1と解説書、達成方法集の更新について（2021年9月）も参照ください）からの更新内容について簡単に触れてみます。

WCAG 2.1 解説書については、前回の更新で積み残していた達成基準 1.4.11: 非テキストのコントラストを理解すると達成基準 2.5.3: 名前 (name) のラベルを理解するの更新により、すべてのページが2020年12月版をもとにした翻訳となりました。これにより、表紙の日付も2020年12月版となっています。

なお、原文にあたるUnderstanding WCAG 2.1の執筆時点の日付については2021年7月版とあります。原文の日付と差異があることに注意が必要です。

WCAG 2.1 達成方法集については、未翻訳だったFailures（失敗例）、SCR（クライアントスクリプト）に関する達成方法集の全部が翻訳されています。General（一般的なもの）が未翻訳の達成方法として50ほど残っていますが、全体の半分以上は翻訳済みであり、翻訳物として実用に耐えうる水準に近づいたといえるのではないでしょうか。引き続き未翻訳のページについて翻訳が進められていくでしょう。

最後に、WAICでは翻訳に誤りの報告や、翻訳の協力を募っています。詳細についてはWCAG 2.1 関連文書 更新のお知らせを参照してください。

12月第2週に、Webアクセシビリティに関連する4つのW3C文書が発行されました。簡単に内容に触れてみたいと思います。

はじめに、12月9日付けでARIA in HTML（参考日本語訳）仕様がW3C Recommendationとなりました（ARIA in HTML is a W3C Recommendation）。

10月の勧告案から実質的な文書の変更はありません。ARIA in HTMLの詳細については過去のブログ記事（ARIA in HTML仕様が勧告案に）を参照してください。

続いて、12月8日付けでAccessible Rich Internet Applications (WAI-ARIA) 1.2（参考日本語訳）がCandidate Recommendation Draftとして発行されています。

前回からの主要な変更点は次のとおりです。

• 実装を反映したIDLおよび列挙属性のセクションの改訂
• 誤って追加されたIDLセクションのariaDescriptionの削除
• プライバシーとセキュリティに関する考慮事項のセクションの追加
• アクセシブルな名前の禁止の定義の明確化

ロールやaria属性は追加されていません。前回（今年3月）の勧告候補からat risk（不安定）とマークされている機能はいくつか減ったもののまだ残っています。at riskの機能がなくなるまでは次のステータスに進めませんから、文書が安定するのにはまだ時間がかかるでしょう。

最後に12月7日付けでW3C Accessibility Guidelines (WCAG) 3.0がWorking Draft として、Explainer for W3C Accessibility Guidelines (WCAG) 3.0がGroup Draft Noteとして発行されました。

WCAG 3.0については、3.6 Error preventionと6.2 User Generated Contentが追加されたことが大きな変更点といったところでしょうか。項目こそ追加されたものの、議論のための叩き台であると思われ、内容を評価するには時期尚早といえるでしょう。

Explainer for WCAG 3.0については、概ねWCAG 3.0のFirst Public Working DraftからWCAG 3.0の背景などといった周辺情報が独立した文書になっており、目新しい内容は存在しないという理解です。

先月に日本DAISYコンソーシアム技術委員会から「Open Letter to Browser Vendors, W3C, and WHATWG: Towards Accessible Ruby」という公開書簡が提出されました。

この書簡ではアクセシブルなHTML ruby（プログラミング言語のRubyと紛らわしいためにこう記しています）の現状についていくつか取り上げられています。

これに関連して、今年のTPACでA role for indicating whether a given ruby represents phoneticsといったissueについてARIA Working Groupで議論されました。さらにこれらの延長で、Internationalization Working GroupにてText to Speech of Electronic Documents Containing Ruby: User Requirementsという文書がEditor's Draftとしてまとめられています。

アクセシブルなHTML rubyという話は興味深いところではありますが、ここでは内容の詳細には触れず、https://www.w3.org/TR/にあるW3C文書のおさらいをしてみようと思います。前述のURLで"ruby"で検索すると、5つの文書がヒットします。

• Ruby Annotation：HTML rubyに関する最も古い文書であり、2001年にXHTMLのモジュールとして定義されたW3C勧告です。ただし、ご存じのとおりXHTML 1.xはSuperseded Recommendationとして廃止されており、Ruby Annotationが現在も実効性のあるW3C勧告なのかは疑わしいと考えます。
• W3C HTML Ruby Markup Extensions：Working Group Noteとして、2014年に発行された文書です。これは当時策定中だったW3C HTML 5.0に対して特にrtc要素を追加することを意図しており、（結局HTML Standardに取り込まれていないものの、）W3C HTML 5.1には取り込まれたため、現状ではメンテナンスされていない文書であるという認識です。
• Use Cases & Exploratory Approaches for Ruby Markup：Working Group Noteとして2013年に発行されたものです。これはRuby Annotationと策定途上のW3C HTML Ruby Markup ExtensionsとW3C HTML 5.0の比較を行ったものですが、これもメンテナンスされていない認識です。
• Rules for Simple Placement of Japanese Ruby：Working Group Noteとして2020年に発行されています。jlreq（Requirements for Japanese Text Layout、日本語組版処理の要件）の拡張を試みているものと思われますが、jlreqからはこの文書が参照されていません。ただし、後述のCSS ruby仕様からは参照されています。
• CSS Ruby Annotation Layout Module Level 1：Working Draftとして策定中のスタイルシート仕様です。

このようにマークアップとしてのHTML ruby関連のW3C文書は整理されているとは言いがたい状況です。HTML ruby関連についてW3C文書として発行するのであれば、現状のHTML Standardに対しての関係性の明確化を行ってもらいたいところです。

また、冒頭のEditor's Draftは、この記事の執筆時点で現状のHTML Standardを参照せずに、XHTML2を参照するといういびつな文書になっていますから、その点でも何らかのHTML rubyに関するW3C文書が求められるのかもしれません。

また、読み上げという意味では以前に本Blogで発音に関する2つのW3C技術草案文書についてとして以前に少し書きましたが、APA (Accessible Platform Architectures) Working GroupのPronunciation Task Forceから、文書がいくつか発行されています。

これとは別に、EPUB 3 Text-to-Speech Enhancements 1.0という文書がEPUB 3 Working Groupから発行されています。これらの読み上げに関連する文書についてもEditor's Draftでは言及できていません。

もっとも、アクセシブルなHTML rubyに関する議論は始まったばかりであり、文書が整備されるのはこれからという認識です。読み上げと言う観点ではいくつかのWorking Groupが興味・関心を既に示しているわけですから、関連するWorking Groupを巻き込んでの議論が期待されるところです。

9月末から10月にかけて、Accessible Platform Architectures（APA）Working Groupが3つの初期公開作業草案（First Public Working Draft）を発行しています。3つの草案がどのようなものなのか、簡単に見ていきたいと思います。

1つ目は、Synchronization Accessibility User Requirementsです。Synchronizationという言葉のとおり、マルチメディアの同期についてのアクセシビリティのユーザーニーズと要件についてまとめています。例えば、映像に対するキャプションの速度に関する研究調査を取り上げています。

2つ目は、Natural Language Interface Accessibility User Requirementsです。自然言語インターフェイスについてのアクセシビリティのユーザーニーズ、要件、およびシナリオについてまとめています。自然言語インターフェイスの典型例として、

• 音声でコミュニケーションをするように設計された音声エージェント
• ユーザーからの自然言語リクエストを処理するWebアプリケーションに含まれるチャットボット
• 電話を介してユーザーと対話し、音声またはキーパッド入力を受け入れ、音声出力を生成する対話型音声応答（IVR）システム

の3つを挙げ、これらのアクセシビリティについて取り上げています。

最後の3つ目は、Accessibility of Remote Meetingsです。その名のとおり、リモート会議のアクセシビリティについてまとめていますが、例えばZoomやMicrosoft Teams、Cisco WebExのようなソフトウェアでリモート会議を行うとして、アクセシビリティが満たされるかどうかは次の3つの要素に依存することになります。

• リモート会議プラットフォームのアクセシビリティ
• 会議中に共有されるコンテンツのアクセシビリティ
• リモート会議が行われているときのホスト参加者のアクセシビリティ認識

この3つをどのようにすれば満たすことができるのかのガイダンスと、既存のWCAG 2.1をはじめとするガイドライン文書との関係性を提供しています。

以上、3つの草案の概要について見てみました。特に1つ目と2つ目の草案については、調査研究が進むにつれ、今後のガイドライン仕様の開発に何らかの影響を与えることがあるのかもしれません。

W3Cからアナウンスがあるとおり、ARIA in HTML仕様（参考日本語訳）が勧告案（Proposed Recommendation）となりました（Call for Review: ARIA in HTML is a W3C Proposed Recommendation）。

この仕様の位置付けについては、ARIA in HTML仕様が勧告候補にで記載したとおりですのでそちらもあわせて参照ください。

7月の勧告候補から、この9月30日付けの勧告案までに大きな変更点はありません。技術的な変更点はないため、仕様の内容としては確定したと捉えて差し支えないと言えます。早ければ11月初頭にはW3C勧告となり仕様の策定が完了することになります。