ウェブアクセシビリティを意識したマークアップとは

こんにちは。田村です。

今年はウェブアクセシビリティを意識したプロジェクトに何度か関わらせていただく機会がありました。

自分ではある程度対応できているつもりでしたが、特に後半のプロジェクトで、今までは機械的にチェックする基準のみ対応していたなあと気づかされました。

例えば、スクリーンリーダーで自然に読み上げる対応というところまではできていませんでした。
個人的に、ウェブアクセシビリティ対応にグッと踏み込めた年となりました。

今後のためにも、ウェブアクセシビリティを意識したマークアップの心構えやポイントについて、まとめていきたいと思います。

ここで登場するウェブアクセシビリティとは、障害を持つユーザーも含めて、全ての人がウェブサイトやアプリケーションを容易に使用できるようにすることです。
ウェブアクセシビリティを担保することで障害を持つユーザーをサポートするだけでなく、高齢者や一時的な障害を持つユーザーなど、幅広い層にサービスを届けることができます。
本記事では、ウェブアクセシビリティを意識したマークアップの進め方に焦点を当てます。

ウェブアクセシビリティを意識したマークアップの進め方

HTMLのバリデーションと文書構造の意味づけ

まずはHTMLの文法が正しいことが重要です。W3Cのバリデータを利用してマークアップの正確さを確認しましょう。また、リンク切れもないように確認しましょう。
https://validator.w3.org/

次に、文法にエラーが無いからといって問題が無いということではありません。
見出しやランドマークを用いて、視覚障害者が簡単にページ内を移動できるようにする必要があります。
文書構造が正しく意味づけされているか確認しましょう。

ただし、ランドマークの使いすぎには注意が必要です。
タブ操作2〜3 回くらいでmainに移動できることを心がけてください。

• 見出しのみ表示する
  HeadingsMap（Chrome拡張）
• ランドマークを表示する
  Landmark Navigation via Keyboard or Pop-up（Chrome拡張）

複雑なコンポーネントや新しくコンポーネントを実装する場合、
APG（ARIA Authoring Practices Guide） パターンやW3Cのデザインシステムのコンポーネントなど参考にするとよいでしょう。
Patterns | APG | WAI | W3C
Components - W3C Design System
Components | U.S. Web Design System (USWDS)

アクセシビリティツリーを意識する

制作時は、アクセシビリティツリーを意識すると良いです。
アクセシビリティツリーとは、HTML要素のアクセシビリティに関連する情報を提供してくれるもので、Google ChromeのChrome DevToolsで有効化できます。

Accessibility tree (アクセシビリティツリー)

HTMLの構造上の読み上げを意識する

ウェブページの内容を読み上げる場合、スクリーンリーダーを使用します。
スクリーンリーダーとは、テキストを音声に変換して視覚障害者に読み上げるソフトウェアです。

スクリーンリーダーによって自然な順序で読み上げられるよう、HTMLの構造や順序に配慮することが大切です。

例えば、ニュースサイトで記事へのリンクを表示する場合、「日付」よりも「見出し」の方が重要な情報である場合が多いです。
そうするとスクリーンリーダーユーザーにとっては、「見出し」を先に読み上げる方が良さそうです。

具体的には、HTMLでは「見出し」を「日付」より先に配置し、CSSを使って視覚的には「日付」が「見出し」より先に表示されるように調整すると良いでしょう。

また、日付の表記にも注意しましょう。
例えば「2024年01月01日」より「2024年1月1日」のように、より自然な表現を心がけると、スクリーンリーダーでも読み上げがスムーズになります。

フォーカス移動を意識する

ウェブページの内容をキーボードでフォーカス移動できることも重要なことです。
特に、PCとスマートフォンで異なるHTMLを使用する場合、キーボードを使用するユーザーが迷子にならないよう、注意を払いましょう。

具体的には、画面上に表示されていない要素（たとえば、スマートフォン表示時には見えない部分）にフォーカスが移動しないようにします。

WAI-ARIAは慎重に

WAI-ARIAは、ウェブコンテンツやウェブアプリケーションをさまざまな人々がアクセスしやすくするための技術です。
ただし、不要なaria属性の使用はスクリーンリーダーの読み上げを冗長にするため、慎重な使用が必要です。
基本的には、正しくHTMLを使用し、必要な場合のみWAI-ARIAを検討しましょう。

WAI-ARIAの基本

aria-labelの読み上げを意識する

aria属性を利用する必要がある場合は、さまざまなユーザーがいることを意識しましょう。
できるだけ多くの人にとって理解しやすい言葉にします。

例えば、「aria-label="ページネーション"」というランドマーク名では伝わらないかもしれません。
「aria-label="ページ切り替え"」など伝わりやすい呼び名を心がけましょう。

画像の代替テキスト

画像の代替テキストは、視覚的な情報をテキストベースで伝えるため、内容を伝えるのが難しいですが、重要な要素になります。

代替テキストに「〇〇の画像です。」のように「画像です。」という説明は不要です。
「です・ます」口調でなくても問題ありません。簡潔に伝えることを意識します。
画像に文字が含まれている場合は、同じ文字をなるべくHTMLの本文でも伝えるようにしましょう。
本文に含まれていない場合は、代替テキストで伝えるようにします。
写真の場合は、「〇〇写真」という形で、写真であることを伝えましょう。

また、代替テキストは、画像が配置されている前後の文脈で内容がかわる場合があります。
画像の機能や目的に応じて代替テキストを調整することが大事です。

フォーム

フォーム機能はブラウザが提供する標準的なバリデーション機能を利用するように心がけてください。

ブラウザの標準機能だけでは不十分でブラウザ標準の機能を利用しない場合、aria-invalidやaria-requiredなどのWAI-ARIA属性を利用して、バリデーションの状態や必須フィールドを明示するようにします。
また、スクリーンリーダーではplaceholderのテキストも読み上げられるため、「〇〇を記入してください」など冗長にならないように注意が必要です。

テキストとカラー

テキストとカラーはデザインの初期段階で決定されることが多いですが、ウェブアクセシビリティに準拠したコントラストを確保することが重要です。
ウェブアクセシビリティに準拠した色のコントラストを確保するためには、Contrast Checkerなどのツールを利用するとよいでしょう。

また、ユーザーがページのテキストを拡大して表示する場合にも、テキストが読みやすくなるように意識しましょう。

達成基準 1.4.4 の失敗例 － 視覚的にレンダリングされたテキストを 200% まで拡大するときに、テキスト、画像又はコントロールが、切り取られたり、端が欠けたり、又は覆い隠されたりする

アクセシビリティの確認 - ツールを利用

axe DevTools

ある程度、ウェブページの形ができてきたらページ全体のチェックを意識します。
axe DevToolsを利用することで、ページ全体または特定のセクションに対してアクセシビリティ評価を行うことができます。
有料版を利用するとより高機能なチェックが可能です。

axe-core DevTools
axe DevToolsを用いたチェック実施方法の例（freee）

miChecker

総務省が無償公開しているアクセシビリティチェックツールです。
ダウンロードすると「手順書」の中にマニュアルが同封されています。
アクセシビリティ試験の手順も確認することもできます。

みんなのアクセシビリティ評価ツール：miChecker (エムアイチェッカー)Ver.3.0（総務省）

アクセシビリティの確認 - 目視、操作

スクリーンリーダー

ウェブアクセシビリティを確認する場合はスクリーンリーダー（読み上げソフト）の使用が必要です。
NVDA、PC-Talker などのスクリーンリーダーを利用します。

機械的に問題なくても読み上げに違和感がある場合があります。
スクリーンリーダーを使用して読み上げを調整することでコンテンツの聞き取りやすさをかなり向上させることができます。

しかし、「ウェブアクセシビリティ規格の達成基準に対応すること」と「スクリーンリーダーの読み上げに対応すること」は必ずしも同一ではありません。
読み上げ対応を優先しすぎると、場合によっては規格の達成基準から外れてしまう可能性があります。基本的には、ウェブアクセシビリティ規格の基準内での対応を心掛けることが望ましいでしょう。
最終的には、プロジェクトの性質に応じて適切な対応を行うようにしましょう。

基本的に、ウェブページに存在する全ての要素は読み上げ対象となります。
そのため、表示されている情報と同じものが、読み上げによっても正確に情報が提供されることが重要です。

以下の点に注意して調整しましょう。

• 表示されているコンテンツは、正しく読み上げられていますか？
• 読み上げられる内容に冗長な部分はありませんか？
• 読み上げられる順序は適切ですか？
• キーボード操作は適切に機能していますか？

NVDAはWindowsで利用できるオープンソースのスクリーンリーダーです。
PC-Talkerは有料の製品ですが開発者向けに音声出力機能が無いクリエイター版 PC-Talkerを利用させてもらうことができます。
また、スマートフォンは「iOS VoiceOver」「Android TalkBack」を利用します。

NVDAを用いたチェック実施方法の例（freee）
NVDAチートシート
PC-Talker マニュアル
iOS VoiceOverを用いたチェック実施方法の例（freee）
Android TalkBackを用いたチェック実施方法の例（freee）

キーボード操作

正しくフォーカスリングが表示されることやタブで迷子になることがないかを確認します。
標準ブラウザとスクリーンリーダーでは操作が違うのでどちらも確認するようにしましょう。

:focus-visible
キーボード操作によるチェック実施方法の例（freee）

その他リンク

ウェブアクセシビリティに関する理解を深めるためには、以下の記事を一通りご覧になることをお勧めします。

アクセシビリティ サポーテッド（AS）情報
JIS X 8341-3:2016 達成基準 早見表（レベルA & AA）
ウェブアクセシビリティ導入ガイドブック（デジタル庁）
freeeアクセシビリティー・ガイドライン
みんなの公共サイト運用ガイドラインの全体像と、公的機関に求める取組（総務省動画チャンネル）
アクセシビリティBlog（ミツエーリンクス）
Webアクセシビリティに向き合う理由

まとめ

ウェブアクセシビリティ対応を進める中で、私自身を含め、しばしば「ランドマーク」や「WAI-ARIA」の使用が多くなりがちですので注意が必要です。

たとえば「aria-label」や「title」を必要以上に使うと、スクリーンリーダーでの読み上げが冗長になってしまうことがあります。

新しいパーツを作成する際には、まず自分でスクリーンリーダーを使用して読み上げを確認してみましょう。
経験を積むことで、徐々にコツが掴めるようになり、ウェブアクセシビリティの対応を予測しやすくなると思います。