1年以上前になりますが、新卒研修について振り返りつつ、アクセシブルな資料を提供する方法の一例をまとめた記事を当Blogで公開しました（新卒研修とアクセシビリティ）。その中で、PowerPointでアクセシブルなスライドを作成できる一方、個人的な経験ではあるものの、PowerPointで作成されたスライドは読みづらいと感じることが多いとお伝えしました。

私はこれまで、PowerPointで作成されたスライドは、スライドをビジュアル的に発表することを念頭に作られていることから、スクリーンリーダーである程度読みづらいものとなってしまうことについては諦めていました。

しかし、PowerPointのアクセシビリティに関して追加で調べたところ、アクセシブルなスライドの作成や共有に関してより詳細に書かれたページを見つけました（WebAIM: PowerPoint Accessibility）。こちらのページでは、Web上でのスライドの共有には、Microsoft Officeが必要なことや、ファイルサイズの削減、スライドの切り替えやすさという観点から、PowerPoint形式（pptx）ではなくPDF形式での共有を推奨しています。また、PowerPointで適切にアクセシビリティに関する設定を行い、PDFファイルに変換することで、タグ付けされたPDFファイルを作成できるともありました。

実際にこのページの情報を参考にアクセシブルなスライドからPDFファイルを作成したところ、Acrobat ReaderとNVDAの組み合わせでPDFが構造化されていることを確認でき、見出しやテーブルといった要素間やテーブル内を移動するコマンドを利用することができました。

そこで、今回から2回にわたりPowerPointを使用し、スクリーンリーダーで効率的に閲覧可能なPDFファイルを作成する方法について説明します。1回目となる本記事では、PowerPointでのアクセシブルなスライドの作成方法についてお伝えします。

PowerPointのアクセシビリティ

PowerPointのアクセシビリティについては、以前の記事でも紹介したとおり、Microsoftもサポート記事を公開しています（障碍のある方に対する、PowerPoint プレゼンテーションのアクセシビリティを高める - Office サポート）。

冒頭に示したWebAIMのページにも、アクセシビリティに関する設定項目が記載されています。それぞれの記事には、文字サイズや色の設定など、見た目に影響する項目も記載されていました。ただ、私は全盲で日常的にスクリーンリーダーを利用しているため、本記事ではスクリーンリーダーユーザーの目線からアクセシブルなスライドの作成手順を説明したいと考えました。そこで、今回はWebAIMに記載されているスクリーンリーダーでの読み上げに影響が及ぶと考えられた以下5項目をピックアップしました。また、スライドの作成や閲覧には、PowerPoint for Office 365 MSO（16.0.13127.21668）を利用しました。

• タイトルプレースホルダーに一意のスライドタイトルを設定
• 画像や図形への代替テキストの追加
• リンクへの説明の追加
• テーブルにタイトル行が設定されていることを確認
• 読み上げ順を設定

具体的な手順

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

それぞれのスライドが区別できるよう、各スライドには異なるタイトルを設定します。[ホーム]タブの[スライド]グループにある[レイアウト]を選択すると表示される一覧から、タイトルと書かれたものを選択します。[タイトル]テキストボックスに入力された文字がスライドタイトルとして認識されます。

当然ではあるのですが、他の種類のテキストボックスにテキストを入力し、フォントを太くするなど、視覚的なレイアウトの変更を行ってもタイトルとしては認識されません。

タイトルは、スライドを切り替えたり、スライド一覧を表示させたときに読み上げられます。タイトルが設定されていない場合、スライド番号のみが読み上げられ、スライドの内容をすぐに判断することができません。

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

画像や図形の内容をスクリーンリーダーユーザーが把握できるよう、代替テキストを追加します。設定する画像や図形を選択し、右クリックメニュー（キーボードではアプリケーションキーを押すことで表示）から[代替テキストの編集]を選択し、設定したい代替テキストを入力します。画像や図形がレイアウト目的など、スライドの内容と直接関係のない装飾用として使用されている場合、[装飾用にする]のチェックをオンにします。

設定された代替テキストは、スライド一覧で画像にフォーカスが当たったときに読み上げられます。装飾用に設定された画像は、無視され読み上げられません。

リンクへの説明の追加

リンク先の内容を素早く把握できるようにするため、リンクに説明を追加します。リンクを選択し右クリックメニューから[リンクの編集]（新規でリンクを追加する場合は[リンク]）を選択します。[アドレス]にリンク先のアドレス、[表示文字列]にリンクの説明を入力します。

設定したリンクの説明は、リンクにフォーカスが当たったときに読み上げられます。説明が設定されていない場合、リンク先のURLがそのまま読み上げられ、リンク先の内容の把握に時間がかかったり、読み飛ばす手間がかかったりします。

とはいえ、URLの情報も併記するのが望ましいと考えられる状況もあるかと思います。そのような際には、例えばリンクの直前にリンク先を表す説明を記載し、リンクにURLを記載するなど、隣接した場所にリンクの説明とURLを記載することで、最小限の操作でリンク先に関する情報を確認できるようになります。

テーブルにタイトル行が設定されていることを確認

スクリーンリーダーの読み上げによってテーブルの行と列の関連付けを行えるようにするため、タイトル行（テーブル見出し）が設定されていることを確認します。テーブルを選択し、[テーブルデザイン]タブの、[タイトル行]のチェックが入っていることを確認します。なお、テーブルは[挿入]タブの[表]を選択し、行と列を指定することで作成できます。

なお、現状NVDAではPowerPointで設定したテーブルのタイトル行を認識せず、テーブル内を移動するためのコマンドについても使用できません。この問題について調べると、過去には本家版のNVDAのGitHubに同様の問題に関し報告が挙げられていたようです（Reporting Tables in Microsoft Powerpoint · Issue #5350 · nvaccess/nvda · GitHub）。とはいえ、例えばナレーターではタイトル行を認識しますし、タイトル行の設定はPDFへ変換した際にも影響するため、設定の確認は行いましょう。

読み上げ順を設定

視覚的な表示順序と読み上げの順序を一致させるため、読み上げ順序の確認を行います。[ホーム]タブの[図形描画]グループにある[配置]から、[オブジェクトの選択と表示]を選択し、適切な読み上げ順序に設定します。通常、PowerPointでは、何も設定しない場合、要素が追加された順に読み上げ順序が設定されています。

順序が適切に設定されていないと、必要以上に内容をさかのぼったり、読み飛ばす必要が生じるため、内容の把握に時間がかかってしまいます。

まとめ

上記の設定を行うことで、アクセシブルなスライドを作成することができます。

テーブルに関するもの以外のすべての設定項目がPowerPointとNVDAでの読み上げに影響します。中でも、タイトルと読み上げ順の設定は重要だと考えています。タイトル情報が設定されていることで、特定のスライドを探すときなどに、スライドの内容をより早く把握することができますし、読み上げ順が正しく設定されていることで、発表者とのレイアウトに関する認識が一致し、発表内容をスムーズに把握できます。

ただ、設定を行ったとしても、スライドを切り替えた際に、場合によってはフォーカスを先頭へ移動させる必要があったり、スライドのアニメーションを飛ばすために複数回Enterキーを押す必要があるなど、PowerPointのUIの問題により閲覧効率は大きく変化しません。2本目の記事では、作成したスライドをPDFへ変換する方法について説明します。

W3Cからアナウンスがあるように、ARIA in HTML仕様（参考日本語訳）が勧告候補（Candidate Recommendation）になりました（W3C Invites Implementations of ARIA in HTML）。

ARIA in HTMLは、WAI-ARIAをHTMLで使用するにあたっての適合要件を定めるものです。

ご存じの方も多いとは思いますが、内容に関して具体的な例を通して簡単に見てみましょう。

例えばmain要素の場合、3章のテーブルをたどっていくと、2列目の暗黙のARIAセマンティクス（Implicit ARIA semantics）としてrole=mainが規定されていることがわかります。これは、HTML Standardのmain要素の冒頭の要素定義で、Accessibility considerationsのFor authorsのリンクからもたどることができます。

また、テーブルの3列目ではroleなし（No role）とあり、暗黙のARIAセマンティクスを上書きしてはならないことを意味します。

言いかえれば、main要素はWAI-ARIAのmainロールを持っており、role属性でmain以外の値を記載できないことなります。さらに、暗黙のARIAセマンティクスと同じroleを設定すべきではないことが規定されています。このことは、通常main要素でrole属性を使用しないということになります。

さらにARIA in HTMLでは、2章でコード例を交えてARIAの誤った使い方について記載されています。これらの例は基本的にNu Html Checkerでチェックを行ったときにエラーまたは警告として報告されるものであります。前述のmainに関しても、main要素にmainロールという例が記載されています。ARIAの使用時には特別な理由がない限り、このような例を避けるのがよいでしょう。

最後にWAI-ARIAの関連リソースとしては、Using ARIAやWAI-ARIA Authoring Practicesなどが別に存在しており、HTML in ARIAでもこれら文書に関するリンクとごく簡単な説明がされています。WAI-ARIAに関する情報が分散しており把握しづらいところではありますが、要点を押さえておきたいところです。

今年の5月に当Blogで公開した記事、「WebAIMが9回目のスクリーンリーダーに関する調査を開始」で触れた調査の結果が公開されました（WebAIM: Screen Reader User Survey #9 Results）。

有効回答数は1568件と、2019年に行われた前回の調査と比べ増加しました。回答者の地域については、前回と同様過半数が北米からのものとなっていましたが、アジア地域からの回答も8.2%含まれていました。

調査結果の中で特に印象的だったのが、デスクトップ/ラップトップで最も利用しているスクリーンリーダーとして、JAWSを挙げる人が再びNVDAを抜きトップとなったことです。JAWSの利用率については、これまで減少傾向が続いていましたが、ここにきて再び増加しました。ただし、利用率は地域により大きく違っており、北米やオーストラリアではJAWSの利用率が最も高くなった一方、ヨーロッパやアジアなどではNVDAの利用率がJAWSを上回っています。

スクリーンリーダーとともに利用されるブラウザについては、Chromeがトップとなったのは前回と同様ですが、Microsoft Edgeの利用率が大きく増加し、2番目に多く利用されるブラウザとなりました。これは、Microsoft EdgeがChromiumベースのものへと更新され、Chromeに近い操作感で利用できるようになったことが影響しているのではと考えられます。

モバイルデバイスの利用状況には、それほど大きな変化はありませんでした。モバイルデバイスでスクリーンリーダーを利用するユーザーは引き続き増加しており、プラットフォーム別にみると、iOSの利用率が最も高くなり、Androidの利用率がわずかに減少しました。

また、Webページ上で情報を探す方法としては、前回と比較するとわずかに減少したものの、見出しの一覧を確認するユーザーが最も多くなりました。さらに、見出しレベルが有用であると回答したユーザーが8割を超えており、適切な見出しの設定の重要さを改めて感じました。

ドキュメントのアクセシビリティについての回答も興味深いものとなっていました。EPUB、PDF、Word、その他の中から、最もアクセシブルなドキュメントフォーマットを問う質問では、Wordが最もアクセシブルなフォーマットであると回答した人が7割弱となりました。Wordの機能で見出しやリスト、表などを設定した文書をスクリーンリーダーで閲覧すると、Webページに近い感覚で文章を閲覧できるので、個人的にもWord文書は比較的アクセシブルであると感じています。しかし、見出しやリストなどが適切に設定されておらず、スペースなどでレイアウトの調整が行われているものなど、読みづらさを感じるWord文書を見かけることも多くあります。今後は、Webページのアクセシビリティとともに、ドキュメントのアクセシビリティのさらなる改善にも携わっていきたいです。

最後に、利用しているメールクライアントについては、59%の人がOutlookもしくはOutlook.comと回答していました。今回のアンケートの選択肢には存在しませんでしたが、Thunderbirdを使用しているという回答者が一定数いたとのことです。

調査結果の詳細については、英語ではありますが、WebAIM: Screen Reader User Survey #9 Resultsからぜひご覧ください。

いまさらながらですが、今年の4月に公開されていたW3C Strategic Highlights April 2021（W3C公式訳2021/04 W3C活動概要）を読み返していたのですが、その中のウェブアクセシビリティのセクションにMaking Audio and Video Media Accessible（音声・映像メディアをアクセシブルにする）というW3C WAI (Web Accessibility Initiative)のページが参照されており、中身が興味深いものであったのでごく簡単に紹介してみたいと思います。

Making Audio and Video Media Accessible自体は全部で8つのセクションで構成されているわけですが、特に音声・映像コンテンツの性質上、作成する前からアクセシビリティを考慮することが肝要になってきます。ではそもそもの話として、WCAG 2.1ではどういった達成基準があるのか？ということがPlanning Audio and Video Mediaで説明されています。WCAG 2.1を認識している方はご存じかと思いますが、ガイドライン1.2 時間依存メディアとして、実に9つの達成基準が存在します。注意深く読めばどの達成基準がどういった音声・映像メディアに当てはまるのかがわかるのですが、内容が似ている記述もあり、WCAG 2.1（と解説書）だけでは混乱しやすいものになっています。このPlanning Audio and Video Mediaでは、メディアが収録済かライブか、音声のみか映像のみか音声付きの映像か、といった観点からトランスクリプト（書き起こし）、キャプション（字幕）、音声解説、手話の4つのアクセシビリティの機能との関係性が改めて整理し直されています。

これら4つのアクセシビリティの機能はそれぞれのセクションで詳しい説明が行われていますが、音声・映像コンテンツを制作するに当たってどういったことを考慮すればよいのか？ということがAudio Content and Video Contentで説明されています。ここではWCAG 2.1には直接書かれないような「録音するに当たっては高品質な音声を作成する」「話し手はゆっくりはっきり話す」といった一般的事項、あるいは「発作を引き起こさないようにする（達成基準 2.3.1 3 回の閃光、又は閾値以下」といったWCAG 2.1のガイドライン1.2ではないものの関連する達成基準などがまとめられています。

また、Transcribing Audio to TextではDIYとして外部に依頼することなく自前でテキストに書き起こす場合に、書き起こすポイントにも触れてられています。さらにMedia Playersでは再生するプレーヤーの紹介があります。もちろんイントロダクションとしてのUser Experiences and Benefits to Organizationsではユーザー体験とビジネス上のメリットにも触れられており、アクセシビリティに考慮した音声・映像メディアを制作する側にとっても、またアクセシビリティ対応がなされているかチェックする側にとっても、至れり尽くせりなリソースである言っても過言ではないと思います。

最後に、Making Audio and Video Media Accessible自体は英語のリソースではありますが、難解な内容ではないことも手伝って、機械翻訳を使うことでそれなりに意味がわかるものになっているという印象です。Translating WAI ResourcesというページでW3C WAIのリソースに関する翻訳方法についてアナウンスをしています。ボランティアとして翻訳活動に興味がある、という方はチャレンジしてみてはいかがでしょうか。

執筆時点ではW3Cから公式のアナウンスは出ていませんが、W3C Accessibility Guidelines (WCAG) 3.0のWorking Draft（作業草案）が2021年6月8日付けで更新されました。（前回の草案についてはW3C Accessibility Guidelines (WCAG) 3.0の初期公開作業草案が発行されましたを参照ください）

この草案にはChange logのセクションが存在するのですが、なぜか内容が空のままというやや理解に苦しむ状況になっています。その一方でW3C WAIにあるWCAG 3 Introductionのページには、今回の草案更新による変更点が簡単に説明されています。

The Working Draft published on 8 June 2021 has minor changes: editorial fixes, extended Acknowledgements section, and information moved from the introduction to a separate informative document: Explainer for W3C Accessibility Guidelines (WCAG) 3.0.

これによれば、今回の変更点はマイナーな編集上の変更とのことです。実際に前回の草案と差分を筆者が調べたところ、前回の草案にあったセクションの一部がExplainer for W3C Accessibility Guidelines (WCAG) 3.0（以下Explainer）に移動した点がもっとも大きな変更となっていました。つまるところ、WCAG 3.0自身の文章量は減っていることになります。

さて、このExplainerの目的についてですが、Status of This Documentのセクションに以下の記載があるように、

It is not normative (informative) and is not expected to become a W3C Recommendation. It provides background on W3C Accessibility Guidelines (WCAG) 3.0.

WCAG 3.0の背景情報を提供する位置付けになっています。このExplainerの内容については、筆者も斜め読み程度しかできていませんが、単純にWCAG 3.0から移動したものもあれば、Requirements for WCAG 3.0由来の文章も混じっているようです。いずれにせよ、WCAG 3.0の背景と現時点でのWCAG 3.0の枠組みを理解するためのまとまった文書であるということは言えそうです。

1999年にW3C勧告となったWeb Content Accessibility Guidelines 1.0（参考日本語訳）について、2021年5月18日付けでSuperseded Recommendationのステータスとなり、廃止扱いになりました。

WCAG 2.0の基礎となったWCAG 1.0がどのようなものであったのか、簡単に振り返ってみますと、14のガイドラインで構成されており、各ガイドラインはチェックポイントを持ち、3つの優先度に分類されていました。

• 優先度1：Web開発者が満たさなければならないもの（must）
• 優先度2：Web開発者が満たすべきもの（should）
• 優先度3：Web開発者が取り組んでもよいもの（may）

しかしながら、WCAG 1.0に対していくつかの問題が指摘されることになります。

• 優先度について、優先度1さえ取り組めばよいといった誤解を招いている
• ガイドラインの中にはHTMLに依存するものがある
• 一部のチェックポイントは"Until user agents ..."という、ユーザーエージェント（支援技術を含むWebブラウザー）の成熟を待つような記述がある
  • WCAG 1.0自体がWebの技術変化に対応できていない
• 非英語圏の事情を必ずしもくみ取れておらず、国際化の観点を欠いている

このような欠点を克服すべく、さまざまな議論を重ねた上でWCAG 1.0の次世代として策定されたガイドラインが、2008年にW3C勧告となったWCAG 2.0ということになります。

WCAG 1.0を読み返してみると、20年以上前に策定されたものであるため当然内容は陳腐化しているわけですが、WCAG 2.0にはないシンプルさがあるなと改めて感じている次第です。

W3Cからアナウンスされているように、2021年5月13日付けのWCAG 2.2 Working Draft（作業草案）が更新されました。（前回の記事もあわせて参照ください）

前回からの大きな変更点としては、WCAG 2.2で追加されたほぼ半数の達成基準（Success Criterion; SC）の名称が変更されている点です。名称が変更された達成基準は次のとおりです（「→」の前後は変更前と変更後になります）。

• SC 2.4.13 Fixed Reference Points→Page Break Navigation
• SC 2.5.7 Dragging→Dragging Movements
• SC 2.5.8 Pointer Target Spacing→Target Size (Minimum)
• SC 3.2.6 Findable Help→Consistent Help
• SC 3.2.7 Hidden Controls→Visible Controls

また、SC 2.5.8の名称変更とともに、SC 2.5.5 Target SizeがTarget Size (Enhanced) に変更されています。SC 2.5.5がEnhancedであり、SC 2.5.8がMinimumとなっているのはWCAG 2.1から既存の番号を変更しないため、一見奇妙ですが番号順と逆転していることになります。

各達成基準の内容ですが、差分を取ってみたところ、WCAG 2.2で追加された9つの達成基準すべてに大幅な変更が入っていることを確認しています。まだ変更後の内容の詳細を読み込めていませんが、実質的に別物と思ったほうがよいのかもしれないというのが個人的な感触です。

このドラフトについては6月11日までレビューコメントを受け付けているとのことですので、何か気づいたことがあればGitHub w3c/wcagにコメントを送ってみてはいかがでしょうか。