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勧告となり仕様の策定が完了することになります。

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

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

まずWCAG 2.1については編集上の軽微な修正にとどまります。訳注としてWAICが提供する翻訳文書のライセンスが（関連文書を含め）明示されるようになっています。二次利用の条件が明記されたことによって、安心して活用できるようになったのではないかと思います。

WCAG 2.1解説書については、表紙こそ2019年3月版のままですが、ほとんどのページ、具体的には達成基準 1.4.11: 非テキストのコントラストを理解すると達成基準 2.5.3: 名前 (name) のラベルを理解する以外のすべてのページが2020年12月版をもとにした翻訳に更新されています。今年に入って更新されている原文により近い解説書が提供されている状況になっていると言えるでしょう。

WCAG 2.1 達成方法集については、未翻訳だったHで始まるHTMLに関する達成方法集の全部と、（WAICのお知らせにはありませんが）Cで始まるCSSに関する達成方法集の全部が翻訳されています。達成方法集の全体のボリュームが大きいために未翻訳のページが相当数残っているものの、引き続き未翻訳のページについて翻訳が進められていくことでしょう。

最後に翻訳に誤りを見つけた、翻訳の協力をしたいという場合の連絡先についてWAICのお知らせに記載されています。詳細についてはWCAG 2.1 および関連文書 更新のお知らせを参照ください。

今月9日に、日本視覚障害者ICTネットワーク (JBICT.Net)による第1回支援技術利用状況調査報告書が公開されました。

日本において、もっぱら視覚に障害がある人を対象に、どのような環境でWebを見ているのか？がわかる最新の調査結果と言え、この調査結果だけでも大変興味深いものであります。

本記事では比較対象として、この手の日本の調査として新潟大学の渡辺先生が中心に継続的に行われている調査で、最新のものである視覚障害者のICT機器利用状況調査2017、グローバルを対象にして定期的に調査を行っているWebAIMの調査で、今年の結果であるScreen Reader User Survey #9 Results（WebAIMが9回目のスクリーンリーダー調査の結果を公開もあわせて参照ください）と、必要に応じて2017年の結果であるScreen Reader User Survey #7 Resultsを取り上げつつ、調査結果について簡単に見ていきたいと思います。

以下わかりやすさのため、各調査については「第1回支援技術利用状況調査報告書」をJBICT.Net、「視覚障害者のICT機器利用状況調査2017」を新潟大、「Screen Reader User Survey #9 Results」をWebAIM（「Screen Reader User Survey #7 Results」も参照するときはWebAIM 2017などと年を付けて区別）とそれぞれ呼ぶことにします。

調査規模

有効回答数はそれぞれ次のとおりです。

JBICT.Netの調査は、新潟大のものと同規模のものと言って差し支えない回答者数になっています。月並みな言葉ではありますが、すごいですね。

年齢構成

JBICT.Netや新潟大の年齢区分が20代、30代…というような区分になっているのに対し、WebAIMの区分が20歳以下、21～40歳、41歳～60歳、61歳以上という区分になっているため厳密な比較にはなりませんが、そこに目を瞑って大まかに年齢構成を比較すると以下のようになります。

JBICT.netの年齢構成は、新潟大のものと大きな違いがないものになっています。日本の調査は40代+50代が多いのが特徴と言えます。

PCで使用するスクリーンリーダー

2021年のJBICT.Netと2017年の新潟大を比較すると、NVDAの利用率が倍増してます。

なお、上記の表には記載していませんがナレーターと回答している人がJBICT.Netでは35.2%にも上っているのは特筆すべき点でしょう。なお、新潟大の調査ではナレーターはスクリーンリーダーとしてカウントされていません。また、ユーザーは3人にすぎなかったと報告されています。いずれにせよNVDA以上に利用率が伸びていることになります。

一方WebAIMでは、2021年の9回目とあわせて、2017年に行われた7回目もあわせてみてみますと、

という結果になっています。日本は言うまでもなく日本語環境であるため、PC-TalkerやJAWSというものが単純比較できないわけですが、JAWSやNVDAがほぼ横ばいの利用率になっているのに対して、ナレーターの利用率が上昇しています。NVDAやナレーターに注目すれば、JBICT.Netの結果はWebAIMの利用率にかなり近いものになっていると言うことができます。

PCで使用するブラウザー

ざっくりとブラウザーのシェアを並べてみます。まずは日本から。比較のためにstatcounterからのデスクトップブラウザーシェアも掲載しておきます。

続いて世界について。

NetReaderという日本独特の閲覧環境は脇に置いて、支援技術ユーザーのブラウザーの傾向としては、新潟大とJBICT.net、WebAIMの2017/2021ともに、2017年ではIEがかなりのシェアを占めていたものの、2021年では相当のシェアを落としています。支援技術のユーザーか否かにかかわらず、こうして数値を見るとChromeの躍進は凄まじいものがあります。また、Edgeについても一定シェアが見られ、IEを置き換える一翼を担っているように見えます。なお、本記事ではEdge Legacyと現在のEdgeを一括りにしてEdgeとしています。

Microsoftが伝えているように、IEデスクトップアプリは2022年6月15日にサポートが終了します。Webサイトでサービスを提供する側は、支援技術を利用しているか否かにかかわらず、PCでIEを利用しない環境に移行してもらうように促していくことになるのかなと思います。

モバイルのプラットフォーム

JBICT.netの結果はiPhoneとAndroid両方という回答があったため、ここでは幅として表記しました。iPhone（iOS系）が優勢なのは傾向として変化していないようです。StatCounterの結果は表として記載しませんが、世界全体ではAndroidがシェアとして優勢なのに対し、日本はiPhoneが優勢なのは知られた話ですが、支援技術ユーザー対象ですと、地域問わずiPhone優勢になるのは改めて興味深いところです。

まとめ

日本のPCでのスクリーンリーダーの利用率として、PC-Talkerが不動の一位であることを再確認できたわけですが、その一方で、ナレーターやNVDAを挙げるユーザーが相当数にのぼっているのは注目すべきポイントでしょう。

Windows環境でWebサイトの開発をすることを考えると、無料で入手できるNVDAでの検証が真っ先に思い浮かぶところですが、NVDAですと実ユーザー数が少ないために開発環境と乖離しているのではないかという懸念が付きまとってきました。一定のユーザーが相当数いるということであれば、実ユーザー環境と同じ環境でサイトを見ていることになるわけですから、この使用率は開発側としてはある種の安心感を得ることができたのではないかと思います（もっともPC-Talkerについても、2019年末からクリエイター版 PC-Talker Neo Plusが入手できる状況にはなっていますが）。

支援技術ユーザーのモバイル環境については、iPhoneが優位なのは変わらずの傾向でした。VoiceOverさえオンにすれば実ユーザーと同じスクリーンリーダー環境になるのはモバイルならではと言えるでしょう。

ユーザーの閲覧環境は時間とともに移り変わっていくわけですが、それはそれとしてWeb制作としては、WCAG 2.0/2.1だけでなく、HTML StandardやWAI-ARIAなどのWeb標準に沿った品質の高いWebサイトを作っていくことで、スクリーンリーダー等（この記事では取り上げていませんが、支援技術として点字デバイスも存在します）の支援技術のユーザーにも情報が伝わるWebサイトというものが引き続き求められていくのではないかと考える次第です。

先だってお知らせに掲載した「TCシンポジウム2021 On the Web」に登壇する件ですが、いよいよ1週間後となりました。事務局の方から伺ったお話では、既に多くのお申し込みをいただいているとのことですが、改めて本Blogにてお知らせさせていただきます。

イベント

TCシンポジウム2021 On the Web（8月オンラインライブ配信）

登壇セッション タイトル

パネルディスカッション「使用情報におけるアクセシブルデザインを考える」

日時

2021年8月26日（木）10:00～12:15

コーディネーター

坂本 貴史（（株）ドッツ）

パネリスト

• 長崎 正道（（株）リコー）
• 木達 一仁（（株）ミツエーリンクス）

セッションの趣旨

昨今、社会全体でDX（デジタルトランスフォーメーション）が加速し、これまで以上にアクセシビリティーが求められるようになってきた。5月28には「障害者差別解消法改正法」が国会で可決、成立し、これまで国や自治体のみだった配慮の義務付けが、民間事業者にも義務化されることとなった。加えて、今企業に求められている「SDGs」の普遍的な価値観は「だれひとり取り残さない」だ。そのミッションは、取扱説明書をはじめとする使用情報にも求められている。

これまでTCシンポでは、ユーザーの満足度を上げるユーザビリティーについて、何度も議論されてきた。ユーザビリティーが低い製品はユーザーに選ばれないだけであるが、アクセシビリティーの確保はやらなければいけない義務なのだ。

「アクセシブルデザイン」とは、誰もが簡単に使えるように配慮され、利用する人を選ばないデザインである。使用情報をアクセスしやすい形でユーザーに適切に届け、利用されるようにするために必要な要素だ。

そこで本セッションでは、アクセシビリティーについての知見を深め、アクセシブルな使用情報を提供するために考慮すべきポイントと、実現するために何をどう進めていけばよいかを掴む場にしたい。

形式

ウェビナー（Zoom）

参加費

有料（金額はTCシンポジウム2021 8月開催（On the Web 専用）申込書をご確認ください）

イベントの詳細、また参加のお申し込みにつきましては、TCシンポジウム2021 On the Webのサイトをご覧ください。皆様からのお申し込み、お待ちしております！

（この記事は、2021年8月4日に公開された記事「Deque's Axe-Core Surpasses 250 Million Downloads」の日本語訳です。Deque Systems社の許諾を得て、お届けしています。翻訳の正確性は保証いたしかねますので、必要に応じ原文を参照ください。）

ダウンロード数の増加率は、Dequeおよびデジタルアクセシビリティ業界全体の勢いの顕れ

デジタルアクセシビリティのリーダーとして信頼されているDeque Systems社（以下「Deque」）は、オープンソースのアクセシビリティ・ルールライブラリーであるaxe-coreのダウンロード数が2億5000万を突破したことを発表しました。あらゆる組織でアクセシビリティのツールをより幅広く利用可能にしてきたことにより、axe-coreのダウンロード数におけるこのマイルストーンは、すべての人にデジタルにおける平等を提供するというDequeの目標と、デジタルアクセシビリティ業界全体の成長に向けた大きな進展を意味します。

axe-coreは、世界で最も人気のあるアクセシビリティ検証のためのライブラリーであり、MicrosoftやGoogleをはじめとする世界中の主要な開発/検証チームで使用されています。npm-statによればaxe-coreは現在、1日あたり平均で約100万ダウンロードされていますが、昨年の同時期は1日平均約30万ダウンロードでした。このダウンロード数の増加は、Dequeの企業としての目覚ましい成長を示すとともに、デジタルアクセシビリティの実践に対する一般的な関心の高まりを示すものです。

Dequeの創業者兼CEOであるPreety Kumar氏は、次のように述べています。「axe-coreのダウンロード数の急増が示すとおり、当社が勢いづいているのは喜ばしいことですが、それ以上に、デジタルアクセシビリティが開発者から相応の注目を浴び始めていることを心強く感じます。axe-coreの利用の拡大は、多くの組織で銀の弾丸など存在しないことが理解されていることを示します。アクセシビリティに関する技術的負債は早期に、そして頻繁に検証することで回避できます。axe-coreを使った自動テストは、開発者とテスターに影響をもたらす最も効率的でインパクトのある方法です。」

『The Automated Accessibility Coverage Report』によれば、自動テストがアクセシビリティ全体の20～30％しかカバーしないと広く信じられているのと対照的に、axe-coreを使用した自動テストでは、初回の検証においてすべての問題のうち57.38％を完全な精度（バグは除く）で検出できます。アクセシビリティ検証により自動的なアプローチを取り入れることで、企業はWebをより優れた、よりインクルーシブな場とするための変化を起こすことができます。

例えば、継続的テストソリューションを提供するSauce Labs社は、最近Dequeと提携し、同社の顧客が自動的なアクセシビリティ検証を品質プロセスに容易に統合できるようにしました。axe-coreは同社の「Accessibility Score」を強化し、ソフトウェア開発プロセスのあらゆるレベルにおいてテスターと開発者の双方に対しアクセシビリティへの気づきを与えます。

Sauce Labs社の技術戦略責任者であるMarcus Merrell氏は、次のように述べています。「Dequeのaxe-coreをSauce Labs Continuous Testing Cloudに統合したことで、お客様はアクセシビリティ検証を自動化し、アクセシビリティ上の問題をより明確に把握できるようになりました。Sauce Labsでは、ソフトウェアは障害者を含む誰にとっても同じように使いやすくあるべきだと考えています。私たちは、Dequeが開発チームや検証チームにデジタルアクセシビリティを最優先事項とするよう導くさまに感銘を受け、また同社をパートナーとして誇りに思っています。」

Dequeはまた、今年初めて開催されたaxe-conカンファレンスにおいても、デジタルアクセシビリティへの関心の高まりを実感しました。axe-conでは世界中のアクセシビリティコミュニティが一堂に会し、7,600以上の組織から17,000人以上の参加者が、誰にとってもよりアクセシブルな体験を生み出すためのアイデアを共有しました。Dequeは2022年3月15日から17日にかけて、第2回となるaxe-conを開催の予定です。

より堅牢で効率的かつ正確なアクセシビリティを必要とされるのでしたら、オープンソースのaxe-coreルールライブラリーを採用したDequeの検証ツール群をぜひチェックしてください（訳註：ミツエーリンクスでは、Dequeのツール群のうち、axe Monitorをインターフェースのみ独自に日本語化した上で提供しています。詳細はアクセシビリティチェックツール（axe Monitor）をご覧ください）。

PowerPointを使用し、スクリーンリーダーで効率的に閲覧可能なPDFファイルを作成する方法について、前回の記事ではPowerPointでのアクセシブルなスライドの作成方法をお伝えしました。2本目となる本記事では、PowerPointで作成したファイルをPDFファイルに変換・出力する方法について説明します。また、私が実際に出力したファイルをスクリーンリーダーで閲覧して気づいた点と、PowerPointからPDFファイルを作成するメリットやデメリットについても併せてお伝えします。

スクリーンリーダーで閲覧可能なPDFファイルとアクセシブルなPDF

そもそも、アクセシブルなPDFとはどのようなものでしょうか。Adobe Acrobat でのアクセシブルな PDF の作成にあるように、

• 画像への代替テキストの追加
• 見出し、段落、テーブルなどに適切なタグを設定
• フォームへのラベル付け

といった設定を行うことで、アクセシブルなPDFファイルを作成することができます。また、画像の代替テキストや文書構造を示すタグは、PDFを作成する前にWordやPowerPointでもととなる文書の画像に代替テキストを設定したり、アウトラインを作成することでも追加できます。

上記の記事に書かれているように、PDFをアクセシブルにするためには、Adobe Acrobatを用いてさまざまな調整を行うことが必要です。しかし、今回はMicrosoft Officeを必要最小限の環境として、スクリーンリーダーで内容を確認するという観点から、どの程度アクセシビリティを考慮したPDFファイルを作成できるのかを検証したいと考えました。そのため、Microsoft Officeの標準機能を利用してPDFを作成しました。なお、今回のPDFの作成に使用したPowerPointのバージョンは、PowerPoint for Office 365 MSO （16.0.13801.20772）となります。

したがって、今回作成するPDFは、アクセシビリティを考慮したものの、WCAGの達成基準すべてを考慮したアクセシブルなPDFではないことにご注意ください。

PowerPointによるPDFの具体的な作成方法

PowerPointをはじめとしたMicrosoft Office製品で作成したファイルからPDFファイルを作成する方法については、いくつかの方法があります（ASCII.jp：Officeに複数あるPDF出力機能はどれがベストか？なども参照ください）。

今回は、[ファイル]タブの[エクスポート]から、[PDF/XPSドキュメントの作成]、さらにその中の[PDF/XPSの作成]を選択し、PDFファイルを作成します（[ファイル]タブに[エクスポート]が表示されていない場合は、[その他]から[エクスポート]を選択します）。作成時には、ファイル名などを入力するダイアログで、[最適化]の設定が[標準 (オンライン発行および印刷)]に設定されていることを確認して発行します。この設定を行わないと、PDFのタグ付けが行われません。

なお、前提としてPDFの作成元のPowerPointのスライドは、前回の記事で紹介したアクセシビリティに関する設定を行っているものとします。

作成したPDFファイルの閲覧環境について

PDFファイルの具体的な読み上げ方について説明する前に、今回閲覧を行った環境について触れておきます。事前にいくつかのスクリーンリーダーやブラウザを組み合わせて確認したところ、組み合わせによってはタグの一部が正しく解釈されませんでした。その中でも、NVDAとAdobe Acrobat Readerの組み合わせが、少なくとも今回作成したファイルについてタグを最も正確に解釈して読み上げていると考えられました。そのため、今回はNVDAとAdobe Acrobat Readerを使い閲覧を行いました。

以下で、前回の記事で設定した項目がスクリーンリーダーを用いたPDFファイルの閲覧にどのような影響を与えるのかを説明します。

また参考として、WCAG 2.0の達成基準（リンク先はWCAG 2.0 解説書）とどのように関係するのかについて示しつつ、PDF の達成方法 | WCAG 2.0 達成方法集に記載されている達成方法との対応についても示しました。

タイトルプレースホルダーに一意のスライドタイトルを設定

[タイトル]テキストボックスに入力された文字は、PDFの見出しとして設定されます。NVDAの見出しを移動するためのコマンドを使用することで、スライド間をスムーズに移動できます。

• 達成基準 1.3.1 情報及び関係性
• 達成基準 2.4.1 ブロックスキップ
• PDF9: PDF 文書内のコンテンツを見出しタグでマークアップすることによって見出しを作成する

画像や図形への代替テキストの追加

画像や図形にフォーカスを当てると、代替テキストに入力された文字を読み上げます。装飾用に設定された画像については、無視され読み上げられません。

• 達成基準 1.1.1 非テキストコンテンツ
• PDF1: PDF 文書の Alt エントリによって画像にテキストによる代替を適用する
• PDF4: PDF 文書の Artifact タグによって装飾的な画像を隠す

リンクテキストの設定

リンクにフォーカスが当たると、PowerPointで[表示文字列]に入力された文字を読み上げます。

• 達成基準 1.3.1 情報及び関係性
• 達成基準 2.1.1 キーボード
• 達成基準 2.4.4 リンクの目的 (コンテキスト内)
• PDF11: PDF 文書内で Link アノテーションと /Link 構造要素を使用してリンクとリンクテキストを提供する

テーブルにはテーブル見出しを設定する

NVDAの設定でテーブルの行と列の見出しの読み上げを有効にした状態でテーブルにフォーカスを移動すると、テーブルのどの行を閲覧しても見出し行の内容を確認できます。また、テーブル内を移動するためのコマンドも利用できます。

• 達成基準 1.3.1 情報及び関係性
• PDF6: PDF 文書でテーブルのマークアップにテーブル要素を使用する

読み上げ順を変更する

PowerPointで設定された順序で内容を読み上げます。

• 達成基準 1.3.2 意味のある順序
• 達成基準 2.1.1 キーボード
• 達成基準 2.4.3 フォーカス順序
• PDF3: PDF 文書で正しいタブ順序と読み上げ順序を確保する

PowerPointからアクセシブルなPDFファイルを作成するメリット・デメリット

PowerPointからのPDFファイルの作成について、以前紹介したマークダウンからの作成方法とも比較しながらメリットやデメリットを説明します。

まずは、作成者側のメリットとして晴眼者の方であれば、レイアウトの調整などを通常のPowerPoint作成の要領で行うことができます。以前に紹介したマークダウンのスライド作成では、マークダウンからスライドを生成しないとどのように表示されるかがわからず細かい調整が難しい、というコメントが新卒研修のスライド作成者からありました。そもそも、マークダウン記法そのものになじみのない方も多くいらっしゃるかと思います。

また、スクリーンリーダーを利用する閲覧者は、Adobe Acrobat ReaderとNVDAを組み合わせることで、適切に構造化された資料を閲覧することができます。そのため、スライドの切り替えやテーブルの確認をプレーンHTMLのようにスムーズに行うことができます。

一方デメリットとしては、PowerPointでアクセシブルなスライドを作成するための項目がそれぞればらばらの場所にあり、設定のための操作が煩雑になってしまいます。また、上述したように適切に閲覧できる環境も限られてしまいます。

まとめ

PowerPointでアクセシビリティに関する設定を行って作成されたスライドから、アクセシブルなPDFファイルを作成できました。また、Acrobat ReaderとNVDAという限られた組み合わせではあるものの、作成したスライドをWebページを閲覧するような感覚でスムーズに閲覧することもできました。

しかし、前述したようにスクリーンリーダーで効率よく閲覧できる環境は限られており、より多くの環境での効率的な閲覧を実現するためには、現状ではマークダウンからのスライド資料の作成を検討したほうが良いのではと感じます。PowerPointでスライドを作成する場合は閲覧者に対し、事前に適切に閲覧できる環境について周知する必要があるでしょう。

作成や閲覧を行うユーザーの状況に応じて、適切な方法を選択することが重要です。

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

今回の更新により、未翻訳であったWAI-ARIAに関する達成方法の全部と、HTMLの達成方法の一部が日本語訳になっています。WCAG 2.1 達成方法集の全体を見渡してみますと未翻訳の箇所のほうが多い状態ですが、逐次日本語訳の更新がされていくと思います。

なお、WCAG関連文書を翻訳しているWAICのワーキンググループでは、翻訳作業に協力できる方を募集しています。前述のWAICによるお知らせのページに詳細が記載されていますので、興味がある方は一読してみてはいかがでしょうか。

ところで、WAICでのリリースでは言及されていませんが、WCAG 2.1 解説書についても、更新が行われています。解説書については、原文が2019年3月から2020年12月のものに、部分的に更新がされています。

解説書の更新に関しては、基本的には、WCAG 2.0からあった達成基準についての解説に対する編集的な変更にとどまっていますが、2点取り上げたいと思います。

1点目は、解説書からFlashの達成方法へのリンクがすべて削除されています。周知のこととは思いますが、Adobe Flash Playerのサポートは終了しています。これにともない、達成方法集の原文にあたるTechniques for WCAG 2.1でもFlashに関する達成方法も存在しないためにこういった状況になっています。

2点目は、解説書の2020年12月版への部分的な更新に伴って、Understanding ACT Rulesというページが増えています（現時点では原文のまま掲載されています）。これは、以前のWCAG 2.1解説書には存在しなかったものです。ちなみに、ACTというのはAccessibility Conformance Testingの略称で、ACT Rulesにごく簡単に触れますと、WCAGなどのアクセシビリティ標準へのWebコンテンツの適合性をテストするためのルールを文書化するというものです（W3CのAccessibility Conformance Testing (ACT) Overviewも参考になります）。

ACTについて、筆者はその存在を認識していたものの、内容を理解するまでは至ってはいないというのが実情です。しかしながら、WCAG 2.1解説書でこうして言及されているわけですから、ひととおり内容を理解する必要があると改めて感じている次第です。