デジタル庁サイトの気になるアクセシビリティ実装

導入

デジタル庁サイトを見ていて
気になったアクセシビリティに関する実装をまとめてみました。

デジタル庁サイト

①SVGアイコンには role="img"

リンクの矢印アイコンやフッターのSNSアイコンなどはインラインSVG要素で実装されています。

SVGアイコンのラッパー要素には role=”img” をつけ、
アイコン自体に意味がない場合は aria-hidden=”true” をつけています。

アイコンに意味があるときは aria-label で指定。

SVG and role="img"

MDNの role=”img” 項目でも
インラインのSVG要素には role="img" を指定して全ての子ノードが読み上げられないようにすることが推奨されています。

SVG and role="img"

If you are using embedded SVG images in your page, it is a good idea to set role="img" on the outer <svg> element and give it a label. This will cause screen readers to just consider it as a single entity and describe it using the label, rather than trying to read out all the child nodes:

ページ内に SVG 画像を埋め込んで使用する場合、外側の <svg> 要素に role=“img” を設定し、ラベルを与えるのがよいでしょう。こうすることで、スクリーン・リーダーは子ノードすべてを読み上げようとするのではなく、それをただ一つの実体とみなし、ラベルを使って記述するようになります

SVGとtitle要素

デジタル庁のSVGアイコンでは使われていないですが
他にもSVGには代替テキスト用の <title> 要素があります。

スクリーンリーダーの組み合わせによっては読み上げられないことがあるみたいなので
aria-labelledby で紐づけておいた方がいいです。

こちらはホバーした時にツールチップが表示されるので
視覚的に補足が必要な場合はこちらのやり方がいいかも。

See the Pen Untitled by rhrh__8 (@Right-88) on CodePen.

※ホバーするとツールチップが表示されます

②詳細リンクがテキストで不十分な場合は補足

詳細ページへのリンクボタンにはaria-label属性で補足をして
読み上げでもなんのリンクかが理解できるようにしています。


↑「一覧を見る」だけだと何の一覧ページかわからないので補足

WCAG 「達成基準2.4.4: リンクの目的」

WCAG の 「達成基準2.4.4: リンクの目的」 でもこのように言われています。

• リンクテキストは可能な限り意味を持たせ、追加のコンテキストなしでリンクの目的を特定できるようにすべき
• リンクの目的は、リンクテキスト自体か、リンクに関連付けられたテキストで説明されるべき
• 同じ宛先のリンクには一貫したテキストを使用し、異なる目的や宛先を持つリンクには異なるテキストを使用することがベストプラクティス

③ヘッダーロゴとh1

ページごとにヘッダーロゴのアウトラインを変更していました。

• トップページ
  トップページはヘッダーロゴが h1 。
  

• 下層ページ
  下層ページではヘッダーロゴはただのリンクになり
  ページタイトルが h1 になっていました。
  

またロゴは画像なので読み上げ用の不可視テキスト「ホーム」が追加されています。

h1 はページの主要なトピックを説明するものなので
会社のロゴに巻きつけるのは良くないですが
トップページに関しては「デジタル庁」のロゴがトップセクションの見出しになるのがたしかに自然ですね..

④パンくずリスト

• 親の nav 要素に aria-label=”現在位置” を設定
• リストはulではなくol を使用
• 現在のページには aria-current=”page”
• 項目間の > アイコンには aria-label=”の中の”
  パンくずリストにはaria-label="現在位置"をつけて

aria-current=”page”

aria-current 属性はコンテナや関連する要素の集合内の現在の項目を表し、
page は「現在のページ」を表します。

⑤アンカーリンクのスムーススクロール

アンカーのスムーススクロールはCSSの scroll-behavior: smooth で実装されています。

CSS

html {
    scroll-behavior: smooth;
}

scroll-behavior: smoothとデメリット

scroll-behavior は
CSSだけでアンカーのスムーススクロールが実装できるプロパティです。

ほぼノーコストでスムーススクロールが実装できますが
以下のようなデメリットがあります。

• デバイスのアニメーション軽減設定に関係なくアニメーションしてしまう
• 外部ページからのリンク、ページ内検索も全てスムーススクロールされるので無効化したいときは別途調整が必要
• Tabによるキーボード操作も全てスムーススクロールされ、連打した時にはページが遅れてスクロールするような形になる

個人的には、一度実装したスムーススクロールは
他の案件でも使い回しができてそこまでコストは変わらないので
JSが無効な環境でスムーススクロールを実装したい時などに使用するのがいい気がします。

CSS

/* スクリプトが無効の時 */
@media (scripting: none) {
  html {
    scroll-behavior: smooth;
  }
}

アニメーションが必要ないユーザーのための設定

またデジタル庁の scroll-behavior は
CSSの prefers-reduced-motion メディアクエリを使用して
アニメーション軽減の設定をしていないユーザーのみに適用されるようにしています。

CSS

@media (prefers-reduced-motion: no-preference) {
    html {
        scroll-behavior: smooth;
    }
}

prefers-reduced-motionは
ユーザーがシステムで設定しているモーション軽減機能を検知します。
MDNにも載っているように基本的にどの機種でもこの設定はついています。

Windows 10: 設定 > 簡単操作 > ディスプレイ > アニメーションを表示する
Windows 7: コントロールパネル > コンピューターの簡単操作センター > コンピューターでの作業に集中しやすくします > 必要のないアニメーションは無効にします (可能な場合)
macOS: システム設定 > アクセシビリティ > 表示 > 動きの抑制
iOS: 設定 > 一般 > アクセシビリティ > 視覚効果を減らす
Android 9 以上: 設定 > ユーザー補助 > アニメーションの削除
Firefox では about:config: 数値型の設定項目 ui.prefersReducedMotion を追加し、値を 1 とします。この設定の変更は直ちに効果が現れます。

WCAG __「達成基準2.3.3: インタラクションによるアニメーション」

WCAG の 「達成基準2.3.3: インタラクションによるアニメーション」 でもモーションのアクセシビリティについてこのように言われています。

インタラクションによって引き起こされるモーション・アニメーションは、機能性や伝達される情報にとって不可欠なものでない限り、無効にすることができる。

おわり

デジタル庁は「誰一人取り残されない、人に優しいデジタル化を。」の実現を目指し
デザインシステムにおいても アクセシビリティを最優先事項
にして構築するほどアクセシビリティに力を入れています。

サイトを眺めているだけでも勉強になりますね...
デザインシステムと合わせて今後も注目していきたいです✨
　　

参考