Webサービスのアクセシビリティについて 考慮すべきポイントを挙げてく
WebサービスやWebサイトを開発するうえで最低限おさえておきたいアクセシビリティのポイントを雑多に挙げてく。ある程度のボリュームになったら記事にする予定。
自分はアクセシビリティについて、まだ見落としてるポイントや分かっていない部分が多くあると思うので、気軽に意見してください。
「こういうのもあるよ」みたいなコメント大歓迎です。
imgタグにはalt属性を指定する
スクリーンリーダーでWebページを読む人が「画像の部分が何を表しているのか」が分かるように、alt属性を指定する。例えば「Zenn」というロゴ画像を表示している場合には、次のように指定する。
<img src="/logo.png" alt="Zenn" />
ただし、装飾や見栄えのために表示する画像など、意味を持たない画像であればaltを空にする。
<img src="/flower.png" alt="" />
「SEOのためにも全画像にaltを指定するべき」という人もいるが、個人的に意味を持たない画像にはaltは指定しない派。
なおalt
をまったく指定しないと、一部のスクリーンリーダーが画像のsrcをそのまま読み上げてしまうことがあるのでalt=""
のように空にする。
altの考え方についてはウェブアクセシビリティ事例集がとても分かりやすい。
SVGに aria-label を指定する
<svg>
では<img>
のようにalt
属性を指定することができない。代わりにaria-label
属性でsvgの意味を説明する。
<!-- 色々と省略 -->
<svg ... aria-label="Twitterのアイコン">...</svg>
スクリーンリーダーなどではaria-label
に指定したテキストを読み上げてくれる。
合わせて role="img" も
また、画像として使う場合はrole="img"
を指定する。これによりスクリーンリーダーはSVGを1つの画像とみなしてくれる。
<!-- 色々と省略 -->
<svg ... role="img" aria-label="SVG画像の説明">...</svg>
以下、MDNのARIA: img ロールから引用
ページに埋め込み SVG 画像を使用している場合は、外側の
<svg>
要素でrole="img"
を設定し、ラベルを付けることをお勧めします。 これにより、スクリーンリーダーは全ての子ノードを読み出すのではなく、単一の実体とみなし、ラベルを使用して説明します。
SVG は <title>
が代替テキストにあたるのでそちらに記載するのがベターです
<title>
だと一部のスクリーンリーダーが対応していないのでaria-label
の方が好ましいという理解をしています。
参考にした記事:Text Links: Best Practices for Screen Readers
可能なら両方書くのが良いのかな
SVGをボタンとして使う場合は<svg>
を<button>
で囲み、<button>
に対してaria-label
を指定する。
例えばYouTubeのヘッダーにはアイコンが並んでいるが、アイコン周りのHTMLはざっくりと以下のような構造になっている。
<button aria-label="作成"><svg>...</svg></button>
<button aria-label="YouTube アプリ"><svg>...</svg></button>
<button aria-label="通知"><svg>...</svg></button>
<button>
にaria-label
を指定した場合はSVGにはaria-label
は不要。
前述の img 要素の alt 属性もそうですが,この辺をちゃんとしないと W3C のバリデータに怒られます。自ブログサイトではページごとにリンクを張り付けて時々チェックしたりします。
なるほど、W3Cのバリデータ良いですね
テキストを余計に点滅させたり動かしたりしない
これについてはアクセシビリティガイドライン(PDF)の説明がとても納得できる。
点滅したり、変化・移動したりする⽂字や画像は原則として使⽤しない。やむを得ず使⽤
する場合は、個数や⼤きさ、点滅・変化・移動の時間を最⼩限度に留めたうえ、以下のよ
うな配慮をする。
利⽤者がそれらを⼀時停⽌、停⽌または⾮表⽰にすることができるようにする。またはそ
れらの動きが⾃動的に停⽌する仕組みを取り⼊れる。
激しい点滅や急激な⾊の変化は利⽤者の健康を害する恐れがあるので、閃光は 1 秒間に
2 回以下とし、同じ系統の⾊調を⽤いる。
横スクロールが必要ないよう、表や画像の⼤きさについて留意する。やむを得ず使⽤する
場合は、個数や⼤きさを最⼩限度に留めたうえ、横スクロールが必要だとわかる仕様にす
る。
横スクロールときどき使うのでグサッとくる。
配色のコントラストに注意する
色盲の方が内容を把握できるように、コントラストに問題がないか確認する。High Contrast
というChrome拡張機能を使うと、Webページをグレースケールで表示できるのでチェックするのに便利。
配色チェックツールは他にもありそう。誰か知ってたら教えて
Chrome 83からインスペクタの Rendering タブで視覚エミュレーション機能が付くようになったので
こちらから配色チェックするのもできそうです
お、知らなかった…!
色覚障害の場合はコントラストよりも色の組み合わせが重要だったりします。模様をつけて区別するのもありだと思います。以下の記事が結構参考になりました。
一方,弱視の人の場合はコントラストが重要だったりします。私も軽い弱視傾向なので(年を取ったら傾向が強まりましたw)ダークテーマ画面でコントラスト強めにしてたりします。
なるほどー、すごい勉強になります。いらすとや、すごいな…!!
もうひとつ必見なページがありました。
言われれば「なるほど」と思うのですが,指摘されないと気づかないことは多そうです。
ブーメラン刺さりまくってるけど、だからこそ整理しておく必要がある・・・・・・・!(吐血しながら)
<div>
でボタンをつくって押下(onClick)させる際、キーボード操作(エンターキー、スペースキー)の操作も考慮しないといけないので <button>
だとそうした考慮が要らないので良いですね
仰る通りですね。
前から気になってるんですが、押下可能なリストメニューの場合もul使っていいんでしょうか?(知見じゃなくて質問ですいません。)
<li>
要素の中に<a>
や<button>
を入れれば問題ないと思います。
<ul>
<li><a href="~">Foo</a></li>
<li><button>Bar</button></li>
</ul>
端的、ボタン的に(デザインというか設計というかを)やってしまうと here症候群化してしまいますもんね。
ネタ切れ。思いついたら書く。
雑に過去やった限りでの自分のアクセシビリティ対応を書いてみる
- ダイアログ表示中はキー操作による移動がダイアログの外にいかないようにすること
- ダイアログUIでのaria-labelledbyなどの利用
- タブ切り替えのようなUIでのキーバインディング
- タブのUIでのaria-controlsやaria-labelledbyの利用
- 何かの通知の際にAlert Roleを使用するなど
MacだとVoiceOverを利用してみて実際にサイトを操作中にどう読み上げられるのか試してみるのも有効
タブのUIでaria-controls
やaria-labelledby
を使用するの良いな。MDNに詳しく書かれてる。
「Macで Voice Over 試してみる」たしかに!やるべきだ!
以下の2つの記事がとても参考になる。前者はアクセシビリティの考え方の部分で、後者はWebでハマりがちなボタン周りのフォーカスについて。