「Webアプリケーションアクセシビリティ──今日から始める現場からの改善」を読んだ

「Webアプリケーションアクセシビリティ──今日から始める現場からの改善」を 2,023 年 11 月 11 日に読んだ。

目次

• メモ
  • p44
  • アクセシビリティオーバーレイは必要か？ p52
  • p79
  • [事例1の改善] そもそもカスタムコンポーネントを利用すべきか検討する p168
  • [事例2の改善] アクセシビリティが配慮されたカスタムコンポーネントサンプルを参照する p168
  • チェックポイント p195
  • Webページ独自の文字サイズ変更機能は必須ではない p198
  • チェックポイント p203
  • [事例1の改善] 行を適切な長さに抑える p204
  • [事例2の改善] 行の間隔・段落の間隔を広くする p204
  • [事例6の改善] 文字画像は最低限の使用にとどめる p206
  • [事例1] ページの言語が指定されていない p207
  • [事例2] ページがランドマークで適切に分割されていない p257
  • スキップリンクは必須ではない p265
  • 非表示にした画像をすべての環境で閲覧・操作不能にする p298
  • カルーセルが必要不可欠か見なおす p301
  • p375
  • アクセシビリティ書籍の輪読会を実施する p395
  • チェックしやすい環境を整える p413
  • 8.6 アンチパターンと対策 4 ―― ユーザーの要求ではない動作 p476
  • 予想外のモーダルダイアログ p480
  • 複雑性の移動 p502
  • モードレスネス p502

メモ

p44

ブラウザのリーダーモードを使うと、Webページからメインコンテンツ部分だけを取り出し、ブラウザ側が用意したスタイルを適用して読めます。
この解析にはHTMLの構造が使われています。

Pocket 、 Instapaper などを使うと、今見ているWebページをクリップして保存しておき、あとで読めます。
このとき、ページのスタイルを自分の読みやすい形に変えられます。
さらに Onenote Web Clipper では、ページの一部だけを取り出して保存できます。

Webページを電子書籍化するサービスを使い、EPUBという形式に変換したうえで電子書籍リーダーで読めます。
EPUBの中身はHTMLなので、電子書籍リーダー側の支援技術を使って読み上げなどもできます。
コンテンツを外部サービスが取得し、加工することで、新たな意味を与えられます。
たとえばカーリルは、日本全国の図書館の蔵書情報を読み取ったうえで、横断検索を可能にしています。
蔵書情報がHTMLで公開されているからです。
同様の横断検索サイトはECの分野でもあります。

https://getpocket.com/ja/
https://www.instapaper.com/
https://www.onenote.com/Clipper?omkt=ja-JP
https://calil.jp/

アクセシビリティオーバーレイは必要か？ p52

アクセシビリティ関連の訴訟が増える中、アクセシビリティオーバーレイというツールが注目されています。
WebサイトにJavaScriptコードを追記するだけで、表示方法を変更できるオプションを追加したり、多くのアクセシビリティ課題を自動で修復したりします。

ツール提供側も「WCAGに対応できる」「訴訟リスクを下げられる」とうたっているため、これに頼る動きもあります。
中には大きな資金調達を実施しているツールもあります。

しかし、こうしたオーバーレイは以下のような問題を引き起こすと「Overlay Fact Sheet」は主張します。

・支援技術が必要な場合、ユーザーは自身の環境のカスタマイズにより対応しているため、特定のサイトだけでアクセシビリティオプションがあっても意味が薄い
・自動修復の精度が低く、逆に情報取得を妨げるノイズを生んだり、サイトの操作体系を破壊してしまったりするケースがある
・支援技術の利用有無の検出や、オーバーレイのカスタマイズにより、障害者であることや内容が運営側に送信されるため、プライバシー侵害にあたる可能性がある

Fact Sheet は、こうしたオーバーレイへの障害当事者による見解や、オーバーレイの廃止に賛同する専門家の署名などをまとめています。
また UsableNet の「A RECORD-BREAKING YEAR FOR ADA DIGITAL ACCESSIBILITY LAWSUITS」では、オーバーレイを適用しているサイトにも訴訟は多数起きており、訴訟リスクを低減できないと指摘しています。

そもそも、こうしたオーバーレイでは問題を見かけ上減らすことができても問題がない状態にはできないので、WCAGには適合できません。
そういう製品でWCAG適合をうたうのは不誠実です。

筆者としては、オーバーレイというアプローチそのものを否定するわけではありません。
たとえば、支援技術を用いるほどではない軽度な障害があるユーザーからすれば、表示変更オプションによってアクセシビリティが高まる可能性はあります。
しかし、不誠実なメッセージで売り込んだり、かえってアクセシビリティを下げたりするようなオーバーレイ製品には大きな問題があると考えます。

オーバーレイによる対応はWebアクセシビリティのごく一部でしかなく、かつ土台でもありません。
Webの特性を理解したうえで、マシンリーダビリティとヒューマンリーダビリティを高めるように改善していくことが、結局はWebにアクセスできる権利を守ることにつながる道なのです。

https://techcrunch.com/2021/02/10/accessibility-overlay-startup-accessibe-closes-28m-series-a/
https://overlayfactsheet.com/
https://blog.usablenet.com/a-record-breaking-year-for-ada-digital-accessibility-lawsuits

p79

tabindex 属性の値に1以上を設定すると、HTMLの記述順に関係なくタブシーケンスにおける順序を変更できます。
tabindex属性の値が1以上の値が設定されている要素が複数存在すると、tabindexの値が小さい順に優先されます。

ただしタブシーケンスの順序を変更すると、多くの場合で視覚的な表示順とフォーカスする順序が異なり、フォーカス位置を見失ってしまうなど操作を困難にします。
tabindex 属性には原則として、 0 または -1 の値のみ使用してください。

また非インタラクティブ要素をキーボードで操作できるようにするには、フォーカスを受け取れるようにするだけでは不十分な場合がほとんどです。
button 要素のようなインタラクティブ要素は、自身がフォーカスを受け取っているときにキーボードの Enter キーが押されれば、クリックイベントが発火します。
しかし非インタラクティブ要素にはそのような振る舞いがありません。
tabindex 属性や WAI-ARIA の role 属性を付与していても、振る舞いが追加されることはありません。

[事例1の改善] そもそもカスタムコンポーネントを利用すべきか検討する p168

カスタムコンポーネントは、そもそも利用すべきか検討することが重要です。
アクセシビリティの高いカスタムコンポーネントを実現するにはデザイン実装ともに大きなコストをかける必要があるからです。
高いコストを支払ってカスタムコンポーネントを実装することが、コストパフォーマンスに見合うかどうかを検証してみましょう。

カスタムコンポーネントを避ける方法を考えてみましょう。
実現しようとしているコンポーネントをHTML標準のフォームコントロールで置き換えられないか検討してみましょう。
HTML 標準のフォームコントロールであっても、ビジュアルデザインが許容できるのであれば、HTML標準のフォームコントロールを利用することでコストを大幅に削減できます。
また、複雑なコンポーネントをシンプルなコンポーネントに置き換えられないか検討してみましょう。
たとえば、複雑なコンポーネントをいくつかのシンプルなコンポーネントに分割できないか考えてみましょう。
カスタムコンポーネントを避けることができれば、アクセシビリティを高めるコストを節約でき、アクセシビリティを向上させるべき別の箇所に注力できるはずです。

[事例2の改善] アクセシビリティが配慮されたカスタムコンポーネントサンプルを参照する p168

カスタムコンポーネントを設計しようとするときには、まず最初にアクセシビリティが配慮されたカスタムコンポーネントサンプルを参照するとよいでしょう。
HTML ・ WAI-ARIA ・キーボード操作・支援技術のサポートなどをゼロから検討するには大きなコストがかかります。
カスタムコンポーネントサンプルを参照することで検討コストを削減できます。

最もよく参照されるカスタムコンポーネントサンプルのひとつは「ARIA Authoring Practices Guide (APG)」です。
この文書では、 WAI-ARIA を利用してさまざまなカスタムコンポーネントを実装する方法がパターンとして解説されています (図3-5-1)。

https://www.w3.org/WAI/ARIA/apg/

チェックポイント p195

文字の大きさを拡大したときに意図したデザインになっているかどうかは、ヒューリスティックなチェックで確認する必要があります。

WCAG 2.1 では達成基準 1.4.4 「テキストのサイズ変更」において、Webページのコンテンツ・機能を損なうことなく、支援技術なしで200%まで文字をサイズ変更できるようにすることを求めています。
なお、文字を拡大する方法を複数提供することは必須ではありません。
いずれかの方法で文字が拡大できれば、達成基準を満たすことになります。

ヒューリスティックなチェック (デザイン時)
・ブラウザのズーム機能で200%まで拡大したときの表示方法を検討する
・ブラウザの文字サイズ変更機能で文字の大きさを2倍にしたときの表示方法を検討する

ヒューリスティックなチェック (実装時)
・ viewport に user-scalable=no や maximum-scale=1.0 を指定しない
・フォントサイズやフォントサイズに応じて変化するサイズには相対単位を指定する
・ブラウザのズーム機能を利用して200%までズームしたときに、文字が見切れたり重なったりしていないか確認する
・ブラウザの文字サイズ変更機能で文字の大きさを2倍にしたときに、文字が見切れたり重なったりしていないか確認する

Webページ独自の文字サイズ変更機能は必須ではない p198

ブラウザやOSの設定とは別に、 Web ページに独自の文字サイズ変更機能が設けられている場合があります。
Web ページ独自の文字サイズ変更機能は目立ちやすいため、しばしば Web アクセシビリティの確保をアピールするために導入されるケースがあります。

しかし、Webページ独自の文字サイズ変更機能は Web アクセシビリティの確保に必須ではありません。
今まで解説したとおり、文字の大きさはブラウザやOSの設定で変更できるため、Webページ独自の文字サイズ変更機能は文字を拡大する唯一の手段ではありません。
またロービジョンのユーザーなど、日常的に拡大を必要とするユーザーの多くは、ブラウザ・OS支援技術の機能を使って文字を拡大します。
Web ページ独自の文字サイズ変更機能は使用頻度が高いとはいえず、実装コストに見合わない可能性があります。

もちろん、ブラウザの操作に慣れていないユーザーの中には、ブラウザのズーム機能などを知らないユーザーもいます。
こうしたユーザーにとっては Web ページで視認しやすい位置に独自の文字サイズ変更機能を提供することは有用だと考えられます。
とはいえ、独自の文字サイズ変更機能を提供する前に、まずはブラウザに搭載されている機能の存在や使い方をユーザーに十分説明したほうがよいでしょう。

ユーザーがブラウザの機能を使って文字の大きさを変更できるようにしたうえで、さらに必要があればWebページ独自の文字サイズ変更機能の提供を検討するとよいでしょう。

チェックポイント p203

ヒューリスティックなチェック (デザイン時)
・行の幅が80字を超えないようにする (全角文字の場合は40字)
・行送りを1.5文字以上にする
・段落の間隔を行送りの1.5倍以上にする
・テキストブロックを両端揃えしない
・文字の間隔を調整するために空白文字を使わない
・ユーザーがテキストの間隔を変更してもコンテンツを閲覧・操作できるようにする
・折り返しのあるテキストブロックの高さは可変にする
・折り返しのない1行のテキストブロックは幅を可変にするか十分な幅をとる
・文字画像を使用しない (ロゴやバナーなど文字画像が必要不可欠な場合を除く)

ヒューリスティックなチェック (実装時)
・行が適切な幅で折り返すように width プロパティや max-width プロパティを指定する
・ line-height プロパティに1.5以上を指定する
・テキストブロックに text-align: justify を指定しない
・文字の間隔を調整するために letter-spacing プロパティを使う
・ height プロパティや max-height プロパティを指定して折り返しのあるテキストブロックの高さを固定しない

[事例1の改善] 行を適切な長さに抑える p204

行は適切な箇所で折り返すようにし、1行を短くしましょう。
WCAG 2.1 では達成基準 1.4.8 「視覚的提示」において、幅が80字を超えない (全角文字の場合は40字を超えない) ことを求めています。
一方で、行があまりにも短いと逆に読みにくくなってしまいます。
このため、行の幅は80文字付近 (全角の場合は40文字付近) にするとよいでしょう。

chなどの相対単位を用いることで、文字サイズに追従して行の幅が変更されます。

良い例: 行の最大幅をおおよそ半角80文字分に設定する
P { max-width: 80ch; }

[事例2の改善] 行の間隔・段落の間隔を広くする p204

行の間隔・段落の間隔はともに広く取りましょう。
WCAG 2.1 では達成基準 1.4.8 「視覚的提示」において、行送りを少なくとも1.5文字分にすること・段落の間隔を少なくとも行送りの1.5倍以上にすることを求めています。

ただし、行送りをあまりにも広く取りすぎるとユーザーが次の行を見失う原因になります。
行送りは文字サイズの1.5倍 ~ 2倍程度におさめるようにしましょう。

line-height プロパティを設定して行の高さを変更することで、行送りを変更できます。

良い例: 行の高さをフォントサイズの1.5倍、段落の間隔をフォントサイズの2倍に設定する
p { line-height: 1.5; font-size: 1rem; }
p + p { margin-top: 2rem; }

[事例6の改善] 文字画像は最低限の使用にとどめる p206

文字画像はできるだけ使わないようにしましょう。
特にHTML使って文字画像を再現できる場合は、文字画像を利用するのは控えましょう。
また、フォントを再現したい場合であっても、文字画像は慎重に検討しましょう。
利用したいフォントがWeフォントとして提供されていれば、文字画像を使わずに済みます。

ロゴやバナーなどでどうしても文字画像を使わざるを得ない場合は、 SVG 形式にすることを検討しましょう。
SVG 形式の文字画像は文字色を変更でき、拡大時にジャギーが表示されないため、PNG形式やJPEG形式に比べてユーザーがカスタマイズする余地が増えるためです。

[事例1] ページの言語が指定されていない p207

ライティングを詳しく検討する前にまず確認しておきたいのは、テキストが適切な言語でブラウザや支援技術に認識されるかどうかです。
ブラウザや支援技術に意図している言語とは異なる言語として認識されてしまう場合があります。
典型的な事例は、ページのテキストが日本語で書かれているにもかかわらず、 html 要素に lang="en" が指定されている場合です。
スクリーンリーダーは正しい発音でテキストを読み上げない場合があります。
特に iOS Voice Over では、ユーザーが自分で言語を切り替えない限り、日本語のテキストがすべて読み上げられなくなってしまいます。

悪い例: 日本語で書かれたページの言語に英語が指定されている
<html lang="en">

[事例2] ページがランドマークで適切に分割されていない p257

HTMLにはページ全体を大まかな領域に分割する「ランドマーク」の役割を持つ要素があります。
たとえば main 要素、 header 要素、 footer 要素、 nav 要素、 aside 要素などがこれにあたります (図4-9-1)。

ランドマークを適切に利用することで、特にスクリーンリーダーユーザーにとってさまざまな利点があります。
多くのスクリーンリーダーがサポートしているランドマークに関する挙動を以下に示します。

・スクリーンリーダーはランドマークに差しかかると、たどり着いたランドマークの種類を読み上げる。ランドマークの内から外に出たときには、外に出たことを読み上げる
・スクリーンリーダーはショートカットキーを押すことで次のランドマークにすばやくジャンプできる (本書ではこの機能を「ランドマークジャンプ」と呼ぶ)
・スクリーンリーダーはランドマークをリスト形式で表示できる。リストからランドマークを選択することで、選択したランドマークにすばやくジャンプできる

ランドマークが適切にマークアップされていないと、スクリーンリーダーユーザーはページの領域を把握しづらかったり、必要な領域にすばやくたどり着きづらかったりします。

スキップリンクは必須ではない p265

ユーザーが必要な領域にたどり着きやすくする方法として「スキップリンク」を設ける方法があります。
たとえばGoogleの検索結果画面では、ページ先頭で Tab キーを押すと「メインコンテンツにスキップ」というリンクが表示され、リンクをクリックすることで検索結果にフォーカスします (図4-9-a)。
特にキーボードユーザーにとっては領域にアクセスする選択肢を増やすことにつながります。
第2回支援技術利用状況調査報告書では、回答者の 38.06% が「よく使う」、 41.30% が「時々使う」と回答しています。

ただし、スキップリンクはアクセシビリティの確保に必須ではありません。
見出しやランドマークを利用する方法を使えば、スクリーンリーダーのユーザーは必要な領域にすばやくジャンプできます。
キーボードユーザーもブラウザの拡張機能などを利用すれば必要な領域へジャンプできます。
スキップリンクは、見出しやランドマークを利用する方法を実践したうえで、さらに必要があれば検討するとよいでしょう。

非表示にした画像をすべての環境で閲覧・操作不能にする p298

カルーセルでは領域外にはみ出した画像を overflow: hidden などを使って非表示にしている実装が多く見られます (図 5-3-3)。
overflow: hidden を使った実装が利用される理由は、アニメーションしながら領域外へ移動する画像を表現しやすいからです。

overflow: hidden による非表示
overflow: hidden を使って非表示にした画像は、スクリーンリーダーに認識されてしまうことに注意しましょう。
スクリーンリーダーに画像が認識されてしまう理由は、 overflow: hidden は画面上の表示に影響するだけで、アクセシビリティオブジェクトモデルに影響を与えないからです。
スクリーンリーダーは、overflow: hidden で非表示になった画像も含めて、すべての画像を読み上げてしまいます。
これでは画像を前後に切り替えるボタンや特定の画像に直接ジャンプできるボタンの意味がなくなってしまいます。

さらに overflow: hidden で非表示にした画像がリンクである場合、スクリーンリーダーを使っていなくても、キーボード操作で画像にフォーカスできてしまいます。
画面に表示されていない箇所にフォーカスすると、ユーザーはフォーカスを見失ってしまう恐れがあります。

display: none や visibility: hidden による非表示
overflow: hidden で非表示にした画像は、すべての環境で閲覧・操作できないようにしましょう。
もし領域外にはみ出した画像を完全に非表示にできるなら、 display: none や visibility: hidden を使いましょう。
これらのCSSを使うことでアクセシビリティオブジェクトモデルから画像を削除できます。
スクリーンリーダーは領域外にはみ出した画像を読み上げなくなります。
またキーボード操作でもフォーカスできなくなります。

良い例: はみ出た画像を非表示にする (display: none を使った場合)
<ul>
	<li style="display: none">
		<a href="/page1">
			<img src="slidel.png" alt="...">
		</a>
	</li>
	<li style="display: none">
		<a href="/page2">
			<img src="slide2.png" alt="...">
		</a>
	</li>
	<li>
		<a href="/page3">
			<img src="slide3.png" alt="..."> <!-- 現在表示されている画像 -->
		</a>
	</li>
	<li style="display: none">
		<a href="/page4">
			<img src="slide4.png" alt="...">
		</a>
	</li>
	<li style="display: none">
		<a href="/page5">
			<img src="slide5.png" alt="...">
		</a>
	</li>
</ul>

aria-hidden="true" による非表示
display: none や visibility: hidden を使うことが難しい場合は、 aria-hidden="true" を付けることでアクセシビリティオブジェクトモデルから画像を削除できます。
スクリーンリーダーは画像を読み上げなくなります。
さらに画像がリンクである場合は、キーボードでもフォーカスできないようにする必要があります。
tabindex="-1" を付けると、キーボードで画像にフォーカスすることを防げます

良い例: はみ出た画像を非表示にする (aria-hidden="true" と tabindex="-1" を使った場合)
<ul>
	<li aria-hidden="true">
		<a href="/page1" tabindex="-1">
			<img src="slide1.png" alt="...">
		</a>
	</li>
	<li aria-hidden="true">
		<a href="/page2" tabindex="-1">
			<img src="slide2.png" alt="...">
		</a>
	</li>
	<li>
		<a href="/page3">
			<img src="slide3.png" alt="...">  <!-- 現在表示されている画像 -->
		</a>
	</li>
	<li aria-hidden="true">
		<a href="/page4" tabindex="-1">
			<img src="slide4.png" alt="...">
		</a>
	</li>
	<li aria-hidden="true">
		<a href="/page5" tabindex="-1">
			<img src="slide5.png" alt="...">
		</a>
	</li>
</ul>

カルーセルが必要不可欠か見なおす p301

ここまでカルーセルのアクセシビリティを高める方法を解説しました。
解説したとおり、カルーセルはアクセシビリティについて考慮しなければならない観点が多い UI です。
ここまでの考慮をして導入することは、果たして本当に必要なのでしょうか。

カルーセルについて費用対効果を慎重に検討すべきという意見は多くあります。
たとえば Erik Runyon 氏はカルーセルの有効性に関する調査を行っています。
この調査によると、カルーセルをクリックするのはサイト訪問者の1.07%しかおらず、その中で1枚目以外のスライドをクリックしたのは、どのサイトにおいても20%以下であることがわかっています。
この調査結果は Web サイトやカルーセル自体のコンテンツに依存しているため、一概にカルーセルの効果を否定するものではありません。
しかし、カルーセルを設置してもほぼクリックされない可能性があることは考慮しておくべきでしょう。

https://erikrunyon.com/2013/01/carousel-interaction-stats/

p375

そこでカラーパレットを用いアプリケーション内で利用する色に一貫性を持たせ、さらに色の数を抑制します。
またカラーパレットで定義している色をどう組み合わるとコントラスト比を満たせるのかをパレットとともに示し、デザイナーの指針とすることができます。

たとえば Contrast Grid というサービスを使用すると、パレットにある色のコントラスト一覧表 (図6-3-1) を簡単に生成できます。
パレットの定義と合わせてこうした表を作り、その範囲内で文字色や背景色を選べば、コントラストの問題は起きにくくなります。

ブランドや組織を象徴する色の明度が高く、背景色によく使用する白色とのコントラスト比が低い場合、パレットの定義に苦戦するでしょう。
その場合はブランドカラー自体を変えるのも選択肢の一つですが、これはかなり強気の選択になってしまいます。
現実的には、ロゴなどはもとの色のままにしつつ、 UI には少し明度を抑えた色を使用するなどの工夫をすることになるでしょう。

https://contrast-grid.eightshapes.com

アクセシビリティ書籍の輪読会を実施する p395

始めやすい活動のひとつが「アクセシビリティ書籍の輪読会」です (図7-3-1)。

書籍は以下をお勧めします。

・本書
まさにそのような用途のために本書は作られました

・『デザイニング Web アクセシビリティ』
Web サイトの要件定義、情報設計、デザインを主なテーマとして、どういった作りだとどんな問題が起きるのか、それをどう解決したらよいかを解説

・『見えにくい、読みにくい 「困った！」を解決するデザイン』
よくあるデザインの問題に対し、6人のペルソナが困る点と、改善例を解説。
色・文字・ことば・図解・ UI という観点で、印刷物と Web を分け隔てなく扱っている

・『インクルーシブ HTML + CSS & JavaScript』
WebサイトやWebサービスに欠かせない構成要素に対し、HTMLやWAI-ARIAの存在を前提としたうえでどう設計するかをパターンごとに解説

・『Form Design Patterns』
WebアプリケーションのUIの大部分を占めるフォームについて、アクセシブルかつ使いやすくするためのプラクティスを解説。
ユーザビリティ向上の観点でも目を通す価値が大いにある

太田伊原力也著 『デザイニング Webアクセシビリティーアクセシブルな設計やコンテンツ制作のアプローチ』 ボーンデジタル、2015年
間嶋沙知著 『見えにくい、読みにくい「困った！」を解決するデザイン』 マイナビ、2022年
ヘイドン ピカリング著/太田良典、伊原力也監訳 『インクルーシブ HTML + CSS & JavaScript――多様なユーザーニーズに応えるフロントエンドデザインパターン』 ボーンデジタル、2017年
アダム・シルヴァー著/土屋一彦監訳 『Form Design Patterns──シンプルでインクルーシブなフォーム制作実践ガイド』 ボーンデジタル、2019年

チェックしやすい環境を整える p413

チェックでは、いくつかのチェッカーや支援技術を使います。
用意できるものは先に用意しましょう。
多くの人が参加しやすくなります。
以下のものを用意します。

アクセシビリティチェッカーをインストールできるようにする
アクセシビリティチェックでは axe DevTools などを使います。
コントラストチェッカーも併用します。
アクセシビリティチェッカーを社内で使用するのに許可が必要な場合は、使用許可をとります。

Windows環境を用意し、スクリーンリーダーを実行できるようにする
提供するWebアプリケーションにスクリーンリーダーでアクセスできる環境を用意しておきます。
第2回支援技術利用状況調査報告書によれば、日本の視覚障害者においては9割以上がWindowsユーザーです。

アクセシビリティの改善結果がアクセシビリティサポーテッドであるかを確認するには、 PC-Talker や NVDA がインストールされたWindows環境が必要です。
実機の用意が難しい場合は、クラウド経由でWindowsを利用できるサービスに契約し、インスタンスにスクリーンリーダーをインストールすることもできます。

スマートフォンの実機検証環境を用意する
もうひとつ欠かせないのがスマートフォンやタブレットの実機です。
OS のアクセシビリティオプションを設定するとどういう表示になるか、日光の下だとどう見えるか。
実機でないと確認できないことも多々あるからです。
iOS Voice Over や Android TalkBack といったスクリーンリーダーは、実機のタッチスクリーンを通して使うことではじめてその操作感が理解できます。
型落ちしたものでかまわないので、コスト的に折り合いがつく実機を、ある程度の台数そろえましょう。

https://www.deque.com/axe/devtools/ 。
freee アクセシビリティー・ガイドラインの参考情報に使い方が解説されている。
https://a11y-guidelines.freee.co.jp/explanations/axe.html

https://jbict.net/survey/at-survey-02

8.6 アンチパターンと対策 4 ―― ユーザーの要求ではない動作 p476

アプリケーションに潜む、さまざまな「予想外の動き」
これまでの章でも触れてきたとおり、アプリケーションでは、ユーザーが明示的にアクションしていないのに自動的に動作する UI が用いられることがあります。

・ユーザーの操作を伴わずに自動で動く
・マウスオーバーだけで要素が追加表示される
・キーボードフォーカスが自動で移動する
・変化した結果が画面にとどまらずに消滅する

ユーザー側のやりたいことと、アプリケーション側の自動的な動作が一致していた場合は「親切だな」と感じられるかもしれません。
もしそれが一致していなかった場合も、一般的な操作が行える状況であれば、アプリケーションが利用できなくなるような事態にはならないでしょう。

しかし、操作に時間がかかったり、画面が一望できなかったりする場合には、こうしたUIはアプリケーションの利用を困難にします。
何が起きているかわからなくなったり、想定外の状況への対処が大きな負担になったりするからです。

ここでは、これまでの章では扱ってこなかった、しかしWebアプリケーションではよく見かける、以下の4点の「予想外の動き」について詳しく考察します。

・スクロールスナップ
・無限スクロール
・予想外のモーダルダイアログ
・新規タブ

スクロールスナップ

アンチパターン
スクロールはあくまで対象を選んだり見つけたりするための行為であり、ユーザーはアプリケーションに対して決定を伝えていません。
しかし、そのスクロール操作を「みなし決定」として扱うことで、操作の手数を減らし、負担を軽減しようとするUIパターンがあります。

スクロールスナップとは、ユーザーが一定の量をスクロールすると、次のコンテンツまで自動でスクロールしたり、
コンテンツがちょうど収まる位置でスクロールが「スナップ」したりするUIを指します (図8-6-1)。
スクロールハイジャック、 Scrolljacking とも呼ばれます。

なぜアンチパターンか？
ブラウザウィンドウが大きく、コンテンツが一望できる環境ではさして問題にはならず、演出を受け入れられるかもしれません。
しかし画面を拡大していたり、スクロール操作に手間がかかったりする状況では、こうした挙動は閲覧や操作を困難にします。
画面解像度、ブラウザのズームや文字サイズ拡大、 OS の画面拡大機能といった状況のかけ合わせや、ユーザーの視野などにより、最適な表示位置は無限のパターンがあります。
しかしスナップが起きると、途中でスクロールを止めて読もうとしても移動してしまう、スナップした位置ではコンテンツが見切れてしまって読めないといった事態を引き起こします。

対策
代替手段がないため、スクロールスナップの採用は避けるべきです。

無限スクロール

アンチパターン
スクロール操作を「みなし決定」として扱う UI パターンのもうひとつの代表例に、無限スクロールがあります (図8-6-2)。
ページ最下部までスクロールすると次のコンテンツを自動的に読み込むものです。

なぜアンチパターンか？
無限スクロールに対して、書籍『インクルーシブ HTML+CSS & JavaScript』は「さまざまな操作方法に対してストレスに満ちた体験をもたらす結果になりがちです」と述べています。
その理由は以下です。

・レイアウト上の問題を起こす
・下端に行くとコンテンツが追加されるので、フッタにアクセスできなくなる
・キーボード操作で無限スクロールエリアのあとにある要素 (たとえば右サイドバー) にアクセスできなくなる。
Tab キーを押し続けても次のコンテンツが読み込まれてしまうため

・実装上のケア不足により問題を起こす
・無限スクロールしたあとにページ遷移し、ブラウザで「戻る」を実施した際に、もとの状態が再現されない
スクロールした状態に対するURLがないと、ブックマークや共有ができない。
また検索エンジンのクローラーもアクセスできない
・スクリーンリーダー利用時には、適切に通知しなければ次のコンテンツが自動的に読み込まれたことに気付けない
・コンテンツが追加され続けて画面のパフォーマンスが低下する。
スクロールや表示が重くなる

・ページネーションの利点が得られない
・ページネーションが提供する「続きを見るために何をすればよいかわかる」
「見終わるまでどのくらいの時間がかかるか予測できる」といった情報が、無限スクロールでは得られない
・ページネーションであれば可能な「途中をスキップできる」「一度通過した範囲を指定して再び見に行ける」といったことが無限スクロールではできない
・ブラウザのスクロールバーが使いにくくなる
スクロールバーを持って下にドラッグすると次のコンテンツが追加され、バーが勝手に上に移動し、かつ短くなってしまう

対策
上記の問題にすべて対処できるケースでは採用を検討してもよいでしょう。
たとえば Twitter や Facebook 、 Instagram などはこうした判断に至っているものと思われます。
レイアウトと実装が課題をクリアでき、コンテンツのの性質としてザッピングが目的なのでページネーションによるスキップや再表示は不要であり、むしろ無限スクロールによる没入感のほうが重要だと考えられるからです。

逆にいえば、こうした状況でない限りは無限スクロールの採用は避け、「もっと見る」ボタンで読み込む、ページネーションを使うといった判断を行うべきです。

予想外のモーダルダイアログ p480

アンチパターン
事前に出現を予測しにくい「予想外のモーダルダイアログ」は数多くあります。
代表例は、告知や訴求のためのダイアログです。
たとえば以下のようなものです。

・ログイン時に計画メンテナンスの日時を伝えてくるダイアログ
・ログイン時に特に重要でない「重要なお知らせ」を伝えてくるダイアログ
・コンテンツを見ようとするとモバイルアプリケーションへ誘導してくるダイアログ (図8-6-3)
・機能を利用しようとすると有料プランを訴求してくるダイアログ
・宣伝を行うために通知の許可を要求してくるダイアログ
・ユーザー登録に対する感謝を伝えてくるダイアログ
・ユーザー登録後にメールマガジンへの登録も要求してくるダイアログ
・画面を開いたときにタスクの概要を伝えてくるダイアログ
・画面を開いたときに使い方ガイドの存在を伝えてくるダイアログ
・画面遷移すると一定の条件で宣伝を挟んでくるダイアログ
・スクロールすると一定の条件で宣伝を挟んでくるダイアログ
・機能利用後に友達に勧めることを要求してくるダイアログ
・機能利用後にSNSでシェアすることを要求してくるダイアログ
・ゲーミフィケーションの一環で実績解除を伝えてくるダイアログ
・ユーザーが実施した一連の作業の完了を労うダイアログ
・退会時に継続メリットを訴えたり、もとに戻せないことを強調したりして引き止めようとするダイアログ

これらがなぜ予想できないかというと、サービス提供側が、ビジネス上の都合で「ここに注目してほしい」「この機能を使ってほしい」と考えた結果として出現するダイアログだからです。
したがって、ユーザーが自身のアクションの結果として推定できるタイミングではなく、サービス提供側の論理とタイミングで出現します。

なぜアンチパターンか？
8.3節「アンチパターンと対策 1 ―― 1 画面に多くの状態を持つ」で述べたとおり、モーダルダイアログは混乱を生みやすく操作の負担が生じやすい UI です。
ユーザー側が予想できないタイミングでモーダルダイアログが出現することで、混乱や負担はさらに増幅します。
こうしたダイアログが連続して出現すると、利用を取りやめる原因にすらなり得ます。

対策
モーダルダイアログは、ほかの作業をすべて止めさせてダイアログ内に注目を集める UI です。
そのため高い認知率や申し込み率を出す可能性があり、それらの指標を上昇させる施策としては魅力的な選択でしょう。
しかし、そうした指標の改善のために不満や混乱が生じる恐れがある手法を使うのは、良いデザインの態度とはいえません。

施策の背景を理解したうえで、まず告知や訴求自体が本当にユーザーにとっての利益になるのかを議論すべきでしょう。

それでも必要だと判断される場合には、 8.3 節「アンチパターンと対策 1 ―― 1 画面に多くの状態を持つ」で述べたような、
混乱や操作負荷が少なく、ユーザーをモードに閉じ込めないような、ほかの方法でのアプローチを提案していくのがデザイナーの努めです。

新規タブ

アンチパターン
Webアプリケーションならではの議題としては、リンクやボタンのクリック時に新しくブラウザのタブを開くことの是非があります。
長年の間、論争の的になっています。

サービス提供側の思いとしては、新規タブを開くほうがもとのタブが維持され滞在時間が延びる、比較検討しやすくなることで申し込み率が上昇する、別のサイトやサービスに移動するときには慣例的にタブを分けておきたいといったものがあります。

ユーザー側からも、自動で開かれて便利だという意見があります。
これは Amazon が検索結果一覧から詳細への遷移を新規タブにしていたり、 Facebook や Twitter などが投稿内のリンクを新規タブで開くよう設定していることも関係していると感じます。
サービス提供側が当たり前のように実施しており、ユーザーはその挙動に慣れていくことで、自身の使い方が変化しているのです。

なぜアンチパターンか？
一方で、操作に時間がかかったり、画面が一望できなかったりするユーザーからすると、以下のデメリットがあります。

・視野が狭いときは新規タブが開かれたことがわからず混乱する。気付いたときには大量の新規タブが開かれていて、もとの文脈に戻れないことがある
・ PC の主要ブラウザ (Chrome、 Edge、 Firefox) では、新しく開かれたほうのタブでブラウザの「戻る」を押しても機能せず、戻れない。そのため新規タブが開いたことを見落とすと混乱する
・大量にタブが開かれると認知負荷が高まる。タブごとのサイズも小さくなるため、どこに何があるのかを見失う
・自身の意思で開いていないタブを閉じに行かねばならないので、操作の負担が増える

また、新規タブが開く設計にするとユーザーの選択肢が狭まるという、より根本的な課題もあります。

通常のリンクであれば、ユーザーが自分の意思で「同じタブで開く」か「新規タブで開く」かを選択できます。
しかし、提供側が新規タブが開くように設計していると、そのリンクを同じタブで開くことはできなくなります (図8-6-4)。

対策
結局のところはサービス提供側のポリシーの問題だといえます。
「ユーザーに選択肢を提供する」というアクセシビリティの考え方をベースにするならば、サービス側の都合で新規タブを開くようにするのはお勧めできません。
どうしても必要なケースに絞り、その際も新規タブが開くことは明示しておくべきでしょう。

複雑性の移動 p502

システム側に複雑性を移動し、極限まで入力を減らします。
具体的なアプローチについては 8.8 節「アンチパターンと対策 6 ―― 入力が多く手間とる」をご覧ください。

特に、本節の「シングルカラム優先」や「1画面に1トピック」を維持しながらアプリケーションとして成立させるには、入力を極限まで減らす必要があります。

これはアプリケーションの設計の根幹に関わることであり、実行しにくいものです。
しかし、革新のチャンスでもあります。
制限がある利用状況を「シンプル化のフレームワーク」と捉えることで、複雑性の移動を試みる機会が得られます。

モードレスネス p502

データの編集やアクションの実行において、確認・報告のモーダルダイアログや通知はできるだけ避けます。
考え方と対策は 8.7 節「アンチパターンと対策 5 ―― 確認や報告が多い」で述べたとおりです。

これはモードを減らしていく、モードレスネスに向かう取り組みであり、モードレス・ユーザーインタフェース実現の取り組みの一部です。
ソシオメディアのブログ記事「モードレス・ユーザーインターフェース」は、「モードが無くなる (減る) と、一般的に次のような利点があります」として以下のように説明します。

・ユーザーインターフェースが示す機能や情報が、ユーザーにとってより分かりやすく意味のあるものになる
・ユーザーが自分なりの方法で作業を進めることができ、システムの利用が促進される
・ユーザーがより良くシステムをコントロールできるようになり、学習効果が高まる
・システム全体で操作のステップが減り、ユーザーの作業効率が高まる
・必要なコントロールや画面数が減り、実装やメンテナンスのコストが下がる
・ユーザーインターフェースの構成がプログラムやデータの構成とより緊密になり、設計がシンプルになる
・これらを総合して、ユーザーと開発者の両方が、より創造的、生産的になる

そして、実現方法として5つの原則を示しています。

・ユーザーが扱う対象オブジェクトを画面に表示する
・直接操作が可能で、かつ可逆的にする
・「名詞→動詞」の順序で操作できるようにする
・モードを解除するためだけの手続きを設けない
・オブジェクトの状態をリアルタイムに表示に反映する 

この点は、後述の「Column 原理とモバイルデバイス向け設計との符合」でも解説します。

モードレスネスについては上野学氏によるブログ「Modeless and Modal」を参照ください。
https://modelessdesign.com/modelessandmodal/

https://www.sociomedia.co.jp/3950