ユーザーのITリテラシーに配慮するのはアクセシビリティなのか

主に2つの答えがあります。

A. WCAGの考えではユーザーが適切な支援技術を利用することも含めてアクセシビリティであり、支援技術の入手やアクセシビリティ機能の利用に必要なITリテラシーを持たない人はアクセシビリティの対象ではない。（WCAG偏重派）
B. うるせえ！！　なるべく多様な人に情報を届ける、それがおもてなしの心ってヤツだろうが！！（アクセシビリティはみんなの心にあるよ派）

筆者には、Aのようにアクセシビリティの範疇からITリテラシーを外すのはやや極端な考え方であるように思えます。しかし、アクセシビリティに詳しい方でもAのような考え方をしているのを見かけます。

この記事では、WCAGやその関連文書を読みながら、この問いについて考察していきます。

今回WCAGとして参照するのはWeb Content Accessibility Guidelines (WCAG) 2.1です。この記事で引用している文は、特記のない限りこの文書からの引用です。日本語訳は筆者によるものですが、用語等についてWAICによる日本語訳を参考にしている場合があります。

WCAGとは？

改めて説明すると、 Web Content Accessibility Guidelines (WCAG) とは、その名が示す通り、Webで提供されるコンテンツのアクセシビリティについてのガイドライン集です。これはW3Cにより定義されており、RecommendationですからW3Cが制定するWeb関係の仕様（CSSなど）と同様のプロセスを経て制定されたことになります。

Web Content Accessibility Guidelines (WCAG) 2.1 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.

（訳）Web Content Accessibility Guidelines (WCAG) 2.1は、Webコンテンツを障害のある人々に対してよりアクセシブルにする方法を定義しています。アクセシビリティは広範な種類の障害を対象としており、視覚、聴覚、身体、発話、認識、言語、学習および神経の障害が含まれます。このガイドラインは広い範囲の問題をカバーしているものの、障害の種類、程度、そして組み合わせを全てカバーすることができているわけではありません。このガイドラインに従うWebコンテンツは、加齢により能力が変化している高齢者にもとってより使いやすいものとなり、さらに、それ以外の一般の利用者にとっても使いやすさが向上することが多いでしょう。

このように、WCAGに従うことで、広範な種類の障害を持つ人々を主な対象としてWebコンテンツの利用可能性を向上することができます。さらに、高齢者やその他一般の人にとっても使いやすさを向上させるという副次的な効果があります。

また、今回の問いに関する記述としては以下の記述が重要です。

Web accessibility depends not only on accessible content but also on accessible Web browsers and other user agents. Authoring tools also have an important role in Web accessibility.

（訳）Webアクセシビリティはコンテンツがアクセシブルであることのみに依存しているのではなく、アクセシブルなWebブラウザやその他のユーザーエージェントにも依存しています。また、制作ツールもWebアクセシビリティにおいて重要な役割を持ちます。

ここでWebブラウザ（及びユーザーエージェント）が言及されています。つまり、Webブラウザもアクセシビリティを構成する要素であり、ユーザーが適切なユーザーエージェントを使用することによってWebアクセシビリティが成立するという考え方が見て取れます。実際、関連文書Essential Components of Web Accessibilityにおいてはさらに踏み込んで次のように言及されています。

It is essential that several different components of web development and interaction work together in order for the web to be accessible to people with disabilities. These components include:

• content - the information in a web page or web application, including:
  • natural information such as text, images, and sounds
  • code or markup that defines structure, presentation, etc.
• web browsers, media players, and other “user agents”
• assistive technology, in some cases - screen readers, alternative keyboards, switches, scanning software, etc.
• users’ knowledge, experiences, and in some cases, adaptive strategies using the web
• developers - designers, coders, authors, etc., including developers with disabilities and users who contribute content
• authoring tools - software that creates websites
• evaluation tools - web accessibility evaluation tools, HTML validators, CSS validators, etc.

（訳）障害を持つ人にとってWebがアクセシブルであるためには、Web開発及びインタラクションにおける複数の要素による協力が不可欠です。これには以下のような要素が含まれます。

• コンテンツ - WebページやWebアプリケーションに以下のような形態で含まれる情報。
  • テキスト、画像、音声のような非人工的な情報。
  • 構造や見た目を定義するコードやマークアップ。
• Webブラウザ、メディアプレイヤー及びその他のユーザーエージェント
• 支援技術が必要な場合もある（スクリーンリーダー、代替キーボード、スイッチ、スキャンソフトなど）
• ユーザーの知識や経験、そして時折、Webに適応するための戦略
• 開発者（デザイナー、コーダー、コンテンツ制作者など）。障害のある開発者を含む
• 制作ツール - Webサイトを制作するソフトウェア
• 評価ツール - Webアクセシビリティを評価するための、HTMLバリデーター、CSSバリデーターといったツール

着目すべきなのは、ユーザーエージェントに加えて「ユーザーの知識」までWebアクセシビリティの概念に巻き込んでいることです。Webが多様なユーザーにとってアクセシブルであるという目標を達成するためには、そのための知識（そして場合によっては適切な戦略）がユーザーの側にも必要だということです。このことを考えると、Webがアクセシブルであるというゴールを達成するためには、ユーザーのITリテラシーに対しても配慮し、必要な知識が得られるように補助するのが適切に思われます。

そもそもアクセシビリティってなに？

またもやW3Cによる関連文書Introduction to Web Accessibilityから引用します。

Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can:

• perceive, understand, navigate, and interact with the Web
• contribute to the Web

（訳）Webアクセシビリティとは、障害を持つ人が使えるように、ウェブサイト、ツール、そして技術が設計・開発されていることを指します。より具体的に言えば、これらの人々が次の行為をできることです。

• Webを知覚し、理解し、ナビゲートする。
• Webに寄与する。

W3Cによる定義では、Webのアクセシビリティはコンテンツや技術の様態を指すものであり、障害を持つ人が“使える”ことが定義とされています。そのように整備された技術を使う主体は当然ながら障害を持つ人々当人です。この考え方は、上述の、ユーザーの側にも知識が必要という考え方と符合します。

具体例

以上のように、WCAGの定義において、Webアクセシビリティは障害を持つ人々が適切な知識を持ち適切な技術を使うことで成り立つものです。このことを、WCAG内のより具体的な記述からも見出してみましょう。

達成基準 1.4.8 Visual Representationでは次のように定められています。ちなみに、レベルAAAはWCAG 2.1で定められる最も高度なレベルです。

(Level AAA)

For the visual presentation of blocks of text, a mechanism is available to achieve the following:

• Foreground and background colors can be selected by the user.
• Width is no more than 80 characters or glyphs (40 if CJK).
• Text is not justified (aligned to both the left and the right margins).
• Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.
• Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.

（訳）
（レベルAAA）
テキストのブロックが視覚的に提示される場合、以下の状態を可能にするメカニズムが利用可能である。

• ユーザーが文字色と背景色を選択できる。
• 横幅が80文字以内である（CJKの場合は40文字以内）。
• テキストが均等割り付けではない（両端揃えされていない）。
• 行間は、段落中では最低1.5行ある。段落間の空白は行間の1.5倍以上である。
• 文字サイズが、支援技術なしで200パーセントまで拡大できる。さらに、フルスクリーンにした場合、その拡大したテキストの各行を横スクロールなしで読むことができる。

ちなみに「テキストのブロック」は文1つよりも長いテキストのことであると定義されています。

最後の要件では、おそらく視力の低いユーザーへの対応として、文字サイズの拡大に関する要件が定められています。これを見ると、「えっ、レベルAAAを達成するにはWebサイトに文字拡大機能を実装しないとだめなの？」と思われるかもしれません。それでも構いませんが、必ずしもそうとも限りません。

なぜなら、「メカニズム」についてWCAGに次のように書かれているからです。

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.

（訳）メカニズムはコンテンツ内で提供されても構いませんし、プラットフォームやユーザーエージェント、支援技術に依存して提供されても構いません。

なお、「依存して」 (relied upon) の意味は次のように定義されています。

the content would not conform if that technology is turned off or is not supported

（訳）その技術が無効化されているかサポートされていない場合、コンテンツが基準を満たさないこと。

つまり、文字拡大機能のような要件は、Webサイト側で提供するという選択肢の他に、ユーザーにそのような機能を持つユーザーエージェントを使ってもらうという選択肢もあるのです。例えば、Google Chromeであればデフォルトのフォントサイズを拡大する機能が備わっているので、ユーザーにGoogle Chromeを使ってもらえばこの要件はクリアできます。後半の要件も、コーナーケースを除けばブラウザの普通のレイアウトエンジンで満たせます。

ただし、ではこの要件はサイト制作者にとって実質無意味なのかというと、そうでもありません。デフォルトフォントサイズの変更は要するにCSSでいう 1rem が大きくなる機能なので、CSSで px 等を用いて文字サイズを指定している場合はGoogle Chromeによるデフォルトフォントサイズの変更を打ち消してしまいます。つまり、pxで文字サイズ指定されているテキストは文字サイズ変更可能の要件を満たしていないことになりますから、この要件を満たすためには、CSSでpxなどを使わずにブラウザのデフォルト文字サイズを尊重したスタイリングにすることが必要です。

……と思いきや、必ずしもそうではありません。なぜならFirefoxでは「スタイルシートを使用しない」機能をツールバーから簡単に利用可能であり、この機能を利用してスタイルシートを無効化すればpx指定されたテキストだろうとユーザーが好きな大きさのフォントで読むことができるからです。つまり、ユーザーにFirefoxを使ってもらえば、WebサイトのCSSでどんな文字サイズの指定をしようとこの要件に関しては問題ないことになります。ただし、この場合は、スタイルシートが無効化されていてもちゃんと読めるようなHTMLが書かれていないと要件を満たさないことになります。

このように、一見文字サイズに関する単純な要件に見えても、その実情は非常に複雑です。しかし、Webブラウザ等の機能に頼ってアクセシビリティ基準を満たせるのは、コンテンツ制作側としては嬉しいですね。

支援技術って？

ところで、この要件を見ると「支援技術なしで」とあります。上の話は、Google ChromeやFirefoxは支援技術ではない（一般のユーザーエージェントである）という前提に基づいています。上の要件を正確に理解するには「支援技術」の定義を知る必要がありますね。WCAGには以下の定義が書かれています。

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents

（訳）ユーザーエージェントとして利用できる、あるいは主流のユーザーエージェントと一緒に利用することができるハードウェアまたはソフトウェアであって、主流なユーザーエージェントから提供されるものを超えるような、障害を持つユーザーに必要な機能を提供するもの。

一文が長くてちょっと理解しにくいですが、要するに「主流なユーザーエージェント」を超えてアクセシビリティに特化した機能を提供するものが支援技術です。何か曖昧だなとお思いかもしれませんが、それは実際その通りで、次のように補足されています。

The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles.

（訳）主流なユーザーエージェントと支援技術の区別は絶対的なものではありません。多くの主流なユーザーエージェントが、障害者をサポートする機能を搭載しています。基本的な違いは、主流なユーザーエージェントが障害を持つ持たないに関わらず広く多様な対象に対して提供されている一方、支援技術は特定の障害を持つ狭い範囲のユーザーを対象としている点にあります。支援技術は対象ユーザーにより特化して、より適切な支援を提供します。主流なユーザーエージェントは、支援技術にとって重要な機能を提供している場合があります。例えば、プログラムオブジェクトからWebコンテンツを取り出したり、マークアップをパースして識別可能な状態にして提供したりです。

この記述からは、Google ChromeやFirefoxといったブラウザは「主流なユーザーエージェント」のほうに属すのであって支援技術ではないと判断できますね。一方、スクリーンリーダーや点字ディスプレイといったものが支援技術に相当すると考えられます。

先ほどの「文字サイズが、支援技術なしで200パーセントまで拡大できる。」という要件は、支援技術を使わずに普通のウェブブラウザの機能を使うユーザーであっても、ブラウザの機能を使ってフォントサイズを拡大できることが要求されていることが分かります（最初に述べたとおり、選択肢としてWebサイトに機能を実装しても構いませんが）。

そう考えると、この要件はコンテンツ制作者だけに向けられたものだけでなく、ユーザーエージェントに対しても向けられたメッセージであると解釈できます。「ブラウザはフォントサイズ2倍にできる機能くらい搭載しとけよ！」ということです。実際、ユーザーエージェント開発者向けのガイドラインであるUAAG 2.0にはテキストサイズを設定可能にすべき旨の記述があります。

Accessibility-supported

WCAGに準拠するための要件として、accessibility-supportedという概念に関連するものがあります。

Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported. (See Understanding accessibility support.)

（訳）達成基準を満たすために、accessibility-supportedな技術の使用法にのみ依存している。accessibility-supportedではない方法で提供されている情報や機能は、accessibility-supportedな方法でも利用可能になっている。

上の方で「要件を満たすためにユーザーエージェントや支援技術の機能に依存してもよい」と解説しましたが、正確には技術を「accessibility-supportedな使用法」で使用している必要があります。accessibility-supportedという言葉の意味は、次のように定義されています。

supported by users' assistive technologies as well as the accessibility features in browsers and other user agents

（訳）ユーザーが使用する支援技術や、ブラウザやその他のユーザーエージェントのアクセシビリティ機能によってサポートされている

ここでは、「技術」という用語はHTML, CSS, JavaScriptなどの粒度で「技術」を指しています。つまり、HTMLやCSSを「accessibility-supportedな使用法」で使用しなければ、達成基準を満たしたと見なされません。

この話題の具体例としては、inertが挙げられます。HTMLのinert属性は、指定された領域がユーザーの操作を無効化するようになる機能です。例えばページングのUIを実装しており、今開かれていないページがDOM上には残っていてちょっと画面に見えているがユーザーから操作されたくないという場合、その部分にinert属性をつけておけば、そこにキーボードフォーカスが行ってしまったりすることを簡単に防ぐことができます。

この機能は昔からHTML仕様書に存在していた一方で、実際にブラウザサポートが進んだのはかなり最近です。つまり以前は、HTML仕様書にはしっかりと記載されている（＝正しいHTMLの使い方である）一方で、実際のユーザーエージェントではサポートされていなかったのです。このとき、inertは「accessibility-supportedなHTMLの使用法」ではありませんでした。コンテンツ制作者が「HTML仕様書に書かれた通りinert付けたから正しい！　これはアクセシブルだ！」と主張したとしても、WCAG的には「うるせえ！　そんなブラウザサポートが無い機能なんかアクセシブルじゃねえよ！」と言いたいわけです。その根拠となるのがaccessibility-supportedの概念です。

最近はinertのブラウザサポートが進んでブラウザがinertを解釈できるようになったため（Firefoxは記事執筆時点でまだNightlyですが）、inertは晴れて「accessibility-supportedなHTML機能」になったのです。このように、accessibility-supportedというのは、ユーザーが利用するユーザーエージェントや支援技術の実情をアクセシビリティ要件に反映し、仕様書に書かれた机上の空論よりも優位に立たせるための便利な概念です。あるWebコンテンツがアクセシブルかどうかの基準も、ユーザーエージェントの進化にあわせて変化するものです。

Accessibility-supportedの定義

ところで、それでは自分専用のinertを解釈できるブラウザを作れば、「inertを解釈できるユーザーエージェントがあるからaccessibility-supportedだ！」と主張できたのでしょうか？　実はそうでもありません。そのことを理解するために、accessibility-supportedの具体的な定義を見てみましょう。

To qualify as an accessibility-supported use of a Web content technology (or feature of a technology), both 1 and 2 must be satisfied for a Web content technology (or feature):

1 The way that the Web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users' assistive technology in the human language(s) of the content,

AND

2 The Web content technology must have accessibility-supported user agents that are available to users. This means that at least one of the following four statements is true:

（訳）accessibility-supportedなWebコンテンツ技術（または機能）の利用法として認められるためには、その技術（または機能）が次の1と2の両方を満たす必要があります。

1 そのWebコンテンツ技術の使用法が、ユーザーの支援技術によってサポートされている。 これは、使用されている技術とユーザーが使用する支援技術との相互運用性が、そのコンテンツの使用言語においてテストされていることを意味する。

かつ

2 そのWebコンテンツ技術が、ユーザーが利用可能なaccessibility-supportedなユーザーエージェントを備えている。 これは、次の4つの条件のうち少なくとも1つが満たされていることを意味する。

2の条件はさらに4つに細分化されています。

1 The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS);

OR

2 The technology is supported in a widely-distributed plug-in that is also accessibility supported;

OR

3 The content is available in a closed environment, such as a university or corporate network, where the user agent required by the technology and used by the organization is also accessibility supported;

OR

4 The user agent(s) that support the technology are accessibility supported and are available for download or purchase in a way that:

• does not cost a person with a disability any more than a person without a disability and
• is as easy to find and obtain for a person with a disability as it is for a person without disabilities.

（訳）
1 その技術が、広く流通しており、かつaccessibility-supportedなユーザーエージェントによってサポートされている。（例えばHTMLやCSS）

または

2 その技術が、広く流通しており、かつaccessibility-supportedなプラグインによってサポートされている。

または

3 コンテンツが大学や会社のようなクローズドな環境に存在するものであって、その組織で使用されているユーザーエージェントがaccessibility-supportedである。

または

4 その技術をサポートするユーザーエージェントがaccessibility-supportedであって、かつ次のような方法でダウンロードまたは購入可能である。

• 入手の際に、障害のある人が障害のない人に比べて不利にならない。かつ
• 障害のある人にとっても、障害のない人と同じくらい簡単に見つけ出して入手することができる。

ざっと読むと、「広く流通しているユーザーエージェント」によってサポートされることが求められています（2の1）。さもなくば、障害のある人に不利にならない形で配布されている（2の4）必要があります。自分専用のユーザーエージェントはおそらくこれらの条件を満たさないでしょう。インターネットで配布すれば2の4の条件は満たせるかもしれません。

しかし、筆者としてはこの定義はあまり真に受けないほうがよいと思います。なぜなら、定義中に出てくる「accessibility-supportedなユーザーエージェント」の意味が定義されていない上に、そもそもaccessibility-supportedの定義の中でaccessibility-supportedという言葉が出てくる循環定義になっているからです。この定義だと、多分最小不動点を取るとaccessibility-supportedな技術は存在しないことになります。

Accessibility-supportedの幅

ここまでを振り返ると、WCAGが定めるWebアクセシビリティの要件というのは、ユーザーエージェント等も巻き込んで定義されるものであって、ユーザーがユーザーエージェント等の機能を使いこなすこともWebアクセシビリティに参画するために必要であることが分かります。

例えば、音声読み上げを必要とするユーザーであれば、音声読み上げをしてくれる支援技術を入手し利用しなければいけません。おそらく、必要な支援技術を十分簡単に手に入れられなければaccessibility-supportedではないのでしょう。なお、簡単というのは無料という意味ではないので注意してください。有料の支援技術であっても「手に入れられる」の範囲に含まれます。

そうなると、とても高価な機材が必要だったとしてもaccessibility-supportedなのかという疑問が発生しますね。これについては、W3Cは具体的なジャッジをしないようにしています。関連文書Understanding Conformanceには、accessibility-supportedか否かの判断は環境や言語にも左右される難しい問題だとした上で、次のように書かれています。

In many cases, the cost of assistive technologies is too high for users who need it. Also, the capabilities of free or low cost AT is often so poor today that Web content cannot be realistically restricted to this lowest (or even middle) common denominator.

（訳）多くの場合、支援技術のコストは、それを必要とするユーザーにとってあまりに高額です。また、現在の無料あるいは安価な支援技術はとても機能が劣るため、そのような支援技術全てにサポートされている範囲にWebコンテンツを制限するのは現実的に不可能です。それどころか、中堅レベルの支援技術に限定したとしても、それは変わりません。

つまり、支援技術はコストがとてもかかり、無料もしくは格安の支援技術は機能が十分ではないと述べられています。つまり、無料や安い支援技術にもサポートされていないとaccessibility-supportedではないとしてしまうと、WCAGへの準拠が非現実的なレベルで困難になってしまうということです。Webの実情に合わせるのであれば、むしろある程度のコストがかかる支援技術の使用がユーザーに求められることになります。Webアクセシビリティの界隈では読み上げの動作テストにMacのVoiceOverがよく使われていますが、Macに何十万円か課金すればVoiceOverが無料で付いてくるのは実はとてもお得なのかもしれません。

ユーザーのITリテラシーの差

やっとこの記事の本題に入ります。インターネット上にはさまざまなユーザーがおり、IT技術をどれくらい使いこなせるのかにも個人差があります。この記事で例に用いてきたテキストサイズ変更の例についても、WCAGガイドラインでは、ユーザーがユーザーエージェントの機能を用いて文字を拡大できるのあればガイドライン準拠であるとしています。

しかし、実際に、大きなテキストを必要とするユーザーが全て文字を拡大する機能を知っているでしょうか。特に、最近はスマートフォンを持つ高齢者も増えてきていますが、iPhoneが持つアクセシビリティメニューを開いたことがある人はその中でどれくらいいるのでしょうか。おそらく、知らずに頑張って小さな文字を読もうとするか、あるいは諦めてしまう人もいるのではないでしょうか。

このように、Webがより多くの人に開かれるにつれて、WCAGガイドラインに適合しているにも関わらず、ユーザー側の知識不足によってアクセシビリティを享受できない状況が発生してしまうように思います。

IT以外の例としても、少し古いですが総務省の資料によれば「そのため、点字を身に付ける機会を逃す場合が多く、点字の識字率は視覚障がい者の約10%と、少ないのが現状である」とされており、点字というアクセシブルな方法があるからといっても必ずしもそれを必要とする万人に利用されないことが分かります。

必要な努力の違いがあるにせよ、ちょっと小さい文字が読みにくいという人が、慣れないWeb検索や慣れない設定変更をするというのも少なくはない努力でしょう。それを乗り越えて必要なアクセシビリティサポートにたどり着けるかどうかには疑問があります。

ITリテラシーの差に配慮するのはアクセシビリティか

以上のことを考えると、ITリテラシーに乏しい人は、たとえWCAGに適合するサイトであってもアクセシビリティの恩恵を受けられない可能性があります。しかし、そのような人々からのニーズを無視できないサービスであれば、そのような人々が使いやすく感じて離脱しないような工夫をするでしょう。例えば、最初から文字を大きくしておくとかです。

しかし、WCAGには最初から文字を大きくしておくことで達成される達成基準はありません（文字を大きくすることでコントラストの要件が緩和される場合はありますが）。つまり、文字サイズを変更できることは明確にアクセシビリティである一方、文字サイズを最初から大きくしておくことは必ずしもアクセシビリティではないのです（WCAG 2.1の達成基準においては、という枕詞が付きますが）。

この分け方は本当に正しいのか？　文字を大きくする方法を知らない人のために最初から文字を大きくしておくのはアクセシビリティではないのか？　というのがこの記事のタイトルの問いです。

ただし、これはアクセシビリティではない（あるいは、少なくともアクセシビリティの達成方法としてベストではない）という考え方も理解できます。なぜなら、ユーザーによって適切な文字サイズは異なるので、ユーザーが自身に適した文字サイズに変更できる方がより多様なユーザーに対応できるからです。

それなら最初から文字を大きくしておいて必要なユーザーが文字を小さくすれば良いような気もしますが、それはWCAGでは特に考慮されておらず、文字を2倍に拡大できるという達成基準はある一方で縮小に関して具体的な基準は定められていません。まあ、文字が大きすぎても一度に得られる情報量が少なくなる程度で、情報の取得が不可能になるわけではないので、文字が大きすぎてもアクセシビリティの観点からは問題ではないのだと理解できます（あまりに大きくしすぎると 1.4.10 Reflow に引っかかる可能性がありますが）。情報を効率よく取得できるという意味での使いやすさは、アクセシビリティの範疇からは外れています。

各論から一般論に話を戻しますが、WCAGのスタンスでは、ユーザーも主体的に必要な支援技術等を利用してウェブに利用するのがWebアクセシビリティのゴールです。そして、WCAG 2.1の達成基準には、その輪に入れない人をサポートするものは含まれていません。これに閉世界仮説を適用することで、冒頭のAの回答になります。

A. WCAGの考えではユーザーが適切な支援技術を利用することも含めてアクセシビリティであり、支援技術の入手やアクセシビリティ機能の利用に必要なITリテラシーを持たない人はアクセシビリティの対象ではない。（WCAG偏重派）

知識・知能とアクセシビリティ

ITリテラシーというのは、ある種の知識です。そして、人々の間には当然に知識の差があります。このことについて、WCAGではどう考えているのでしょうか。実は、それに関連する達成基準もあります。以下の基準はどちらもレベルAAAの基準です。

Success Criterion 3.1.3 Unusual Words

A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon.

（訳）達成基準3.1.3 珍しい言葉

慣用句や専門用語のような、珍しい、または特殊な使われ方の単語やフレーズについては、その意味を確認するためのメカニズムが利用可能である。

Success Criterion 3.1.5 Reading Level

When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.

（訳）達成基準3.1.5 読解レベル

テキストが前期中等教育のレベル（日本でいう中学校レベル）を超える読解能力を必要とする場合は、補足コンテンツや、高い読解能力を必要としないバージョンが提供されている。（ただし固有名詞は除く）

つまり、レベルAAAを満たすためには、慣用句や専門用語についても説明を提供し、用語を知らなくても意味が分かるようにする必要があります。これについては、ユーザーエージェントに支援技術として辞書アプリ的なものが備え付けられていれば要件を満たせる可能性が高いでしょう。

さらに、中学校レベルを超える読解能力を要求する文章については中学校レベルの能力でも理解できるようにサポートする必要があります。こちらは現状だとコンテンツ提供者側で対応してあげる必要がありそうです。

このように、知識レベルや読解能力については、中学校レベルの読解能力を持っていればWebから適切に情報を得られる、ということを担保する営みはWCAGの基準ではアクセシビリティの範疇となります。

このことから、能力が足りない（中学校レベルの能力を有している人を足りない評するべきかは分かりませんが）ことに対する配慮もれっきとしたアクセシビリティです。また、（WCAGでは）アクセシビリティのプライマリなサポート対象は障害者であるとされていますが、中学校レベルの読解能力を有する人を知能面で障害者というのはあまりに無理があるので、達成基準3.1.5は障害者に限らず多様なユーザーに情報が届くようにするという意味合いが大きいと解することができます。

そうなると、読解力が中学校レベルである（高校レベル以上ではない）人はWCAGによって明示的にサポートされる一方で、ITリテラシーに乏しい例えば高齢者などはWCAGからサポートされないことになります。この達成基準は「実際のWebコンテンツから情報を得るための能力」にフォーカスしており「アクセシブルなWebに参画するための能力」はまた別物と言えるかもしれませんが、筆者個人的にはそこに絶対的な境目は見いだせなそうに思います。

アクセシビリティの範囲とは

上のような議論をすると、Aの牙城がちょっと崩れた感じがしますね。WCAGの達成基準が「アクセシブルなWebに参画する」というプロセスそのものまで救済の手を伸ばさないのは、客観的な確固たる理由があるというより、単にそこに線を引いただけというように筆者には感じられます。

実際に、どこまでを範囲に含むのかは場合や組織の方針によるはずです。例えばデジタル庁ではWebアクセシビリティについて次のように考えています。

デジタル庁では、「誰一人取り残さない、人にやさしいデジタル社会の実現」を目指しています。そのためには、障害のある人やご高齢の方などを含むすべての方が、ウェブで提供されている情報やサービスをスムーズに利用できることが不可欠です。

こちらの定義では「ご高齢の方」とあるので、WCAGよりも高齢者への配慮により高いプライオリティを与えていることが分かります（ただし、ここで参照されているアクセシビリティの規格はJIS X 8341-3:2016でありこれはWCAG 2.0の一致規格となっているので、実際にデジタル庁がWCAGを超えるような高齢者サポートを提供しようとしているわけではありません）。

記事冒頭で定義したこちらの意見を「WCAG偏重派」としたのは、ITリテラシーへの配慮を含んでいないのはあくまでWCAGにおける現状であって、必ずしもアクセシビリティ一般に言えるものではないだろうという考えからです。「偏重派」というのはWCAGに書かれている内容の外に目を向けていないことを表します。

A. WCAGの考えではユーザーが適切な支援技術を利用することも含めてアクセシビリティであり、支援技術の入手やアクセシビリティ機能の利用に必要なITリテラシーを持たない人はアクセシビリティの対象ではない。（WCAG偏重派）

まとめ

WCAGでは、Webアクセシビリティに参画するためにはユーザーも適切な知識が必要であるとしています。その一方で、専門用語に対する知識や読解能力の多様性については、明示的にアクセシビリティの対象としています。そうなると、WCAGにITリテラシーを欠く人に配慮する達成基準が含まれていないことは、必然的な基準があるというよりは単にそこに線を引いただけのように感じられます。

デジタル庁のように「誰一人取り残さない」ことを目標としているのであれば、ITリテラシーを欠き文字の大きさの変え方が分からない人もサポートするのがより望ましいのは言うまでもありません。それは、WCAGの考え方を借りれば必ずしもコンテンツ制作者によって解決されるものではないかもしれません。例えばWebコンテンツ内に文字の大きさの変え方の案内を書くのでもいいし、デジタル庁が全世帯にiPhoneおよびAndroidでの文字のサイズの変え方を教える冊子を配ってもいいし、あるいはITリテラシーのない人が適切な助言を受けられるような社会を作るのでもよいでしょう。

アクセシビリティはWCAGの考えではコンテンツ制作者やユーザーエージェントの開発者、そしてユーザーまでを参画者として巻き込む概念でしたが、そこに新たに「社会そのもの」を巻き込むことによって、ITリテラシーへの配慮ということも達成できるのかもしれません。それくらいアクセシビリティというのは多様、広範な概念です。

もはや、あなたがより多様な相手に情報を届けたいと思い、そのためにできることをしたのならばそれはアクセシビリティなのではないでしょうか。これがBの考え方ですね。

B. うるせえ！！　なるべく多様な人に情報を届ける、それがおもてなしの心ってヤツだろうが！！（アクセシビリティはみんなの心にあるよ派）

以上です。