初めに

記事を書いた人について

2022年3月からフロントエンドエンジニアとして働き始めました。
2024年6月現在、約2年ほどフロントエンドエンジニアとしての実務経験を積んでいます。

この記事について

上記の通り、約2年実務経験を積み、そろそろアクセシビリティについてしっかり学ばなければならないと感じました。
自分と同じようなフロントエンドエンジニアとしてアクセシビリティを学び始める方に向けて、自分が学んだことを以下の3つの記事に分けて公開します。

フロントエンドエンジニアのWeb開発アクセシビリティ入門①｜HTML
フロントエンドエンジニアのWeb開発アクセシビリティ入門②｜CSS/JavaScript（この記事）
フロントエンドエンジニアのWeb開発アクセシビリティ入門③｜WAI-ARIA（公開予定）

なお、この記事は主に以下のページを自分なりにわかりやすくした内容です。

CSS

正しい意味付け

標準的なテキスト

以下の点を考慮しましょう。

文章を読みやすくするために、フォントサイズや行の高さ、文字間隔などは分別のあるものを選ぶ
見出しと本文が区別できるようにする
テキストの色と背景色のコントラストが十分である色の組み合わせを選ぶ

See the Pen 標準的なテキスト by msuzuna (@msuzuna) on CodePen.

WCAG2.2 達成基準 1.4.12 テキストの間隔にて以下の達成基準が記載されています。

行の間隔 (行送り) をフォントサイズの少なくとも 1.5 倍に設定する
段落に続く間隔をフォントサイズの少なくとも 2 倍に設定する
文字の間隔 (字送り) をフォントサイズの少なくとも 0.12 倍に設定する
単語の間隔をフォントサイズの少なくとも 0.16 倍に設定する

強調したテキスト

強調したテキストには<em>や<strong>タグを利用しましょう。
習慣的に、太字や斜体で書かれているテキストを強調と認識しやすいです。

<em>なんと<em>無料で</em></em>利用できます。

<strong>ここからは有料です。</strong>

<em>タグは入れ子にすることで強調の度合いを示すことができる
<strong>タグは注意事項等、ユーザに必ず伝えたいテキストをマークアップするのに適している

略語

<abbr>タグを使うと良いでしょう。
略語に対するスタイル付けの慣習は、点線の下線で実装することです。
title属性に略していない言葉を設定することで、マウスをホバーさせると略していない言葉をツールチップとして表示できます。

See the Pen <abbr>タグ by msuzuna (@msuzuna) on CodePen.

リンク

リンクについてWeb開発者で自由にスタイリングできますが、標準的なスタイル付けに則る方がユーザにリンクであることを認識してもらいやすいです。
標準的なリンクの慣習は以下の通りです。

下線が引かれている
標準のテキストとは異なる色で表示されている（デフォルトは青）
訪問済みの場合はさらに別の色で表示されている（デフォルトは紫）
アクティブになっている場合はさらに別の色で表示されている（デフォルトは赤）
リンクにマウスオーバーすると、マウスポインターがポインターアイコンに変化する
フォーカスが当たったり、アクティブ化されるとハイライトされる

フォーム要素

フォーム要素はフロントエンドエンジニアのWeb開発アクセシビリティ入門①｜HTML UIコントロールの章で記述している通り、フォーカスが当たっていることがわかるスタイルがブラウザの既定で設定されています。
Web開発者は既定のスタイルを上書きできますが、期待されるような視覚的なフィードバックを大きく逸脱したり、完全に取り除いてしまったりすべきではありません。

テーブル

テーブルの見出しを目立つようにしたり、異なる行同士が見分けやすいようにシマウマ的な配色を使うと良いでしょう。
HTMLで留意すべき点はフロントエンドエンジニアのWeb開発アクセシビリティ入門①｜HTML アクセシブルなデータ表に記述しています。

See the Pen CSS-テーブル by msuzuna (@msuzuna) on CodePen.

色とそのコントラスト

テキストと背景色が十分に差があることを確認しましょう。
また、案内を色だけに頼らないようにしましょう。

WCAG2.2 達成基準 1.4.3 コントラスト (最低限)にて4.5:1 のコントラスト比を確保することが達成基準として記載されています。

ものごとを隠す

タブUIのように、すべてのコンテンツを一度に表示させないことが要求される場合があります。
以下の例では、opacity: 0;とopacity: 1;を切り替えることでタブを実現しています。

See the Pen タブUI by msuzuna (@msuzuna) on CodePen.

上記例のように、opacityでタブコンテンツを切り替える場合はスクリーンリーダーにはあまり影響がありません。
visibility: hidden;やdisplay: none;はスクリーンリーダーがコンテンツを読み取れなくなってしまうので、しかるべき理由がない場合は使わないようにしましょう。
（上記のコードはあくまで例のために実装しており、タブの実装として最適なコードではありません。）

ユーザがスタイルを上書きできることを受け入れる

視覚障害のあるユーザはすべての訪問先Webサイトでテキストを大きくしたいかもしれません。また、色覚障害のあるユーザはすべてのWebサイトを見やすい高コントラストの色に変更したいかもしれません。このようにユーザによってスタイルが変更された場合でも、うまく機能するように柔軟なものにしておくとよいでしょう。

WCAG2.2 達成基準 1.4.8 視覚的提示において以下の内容が達成基準として記載されています。

テキストは、支援技術なしで 200％までサイズ変更できる
利用者が、前景色と背景色を選択できる

JavaScript

複雑な機能をアクセシブルにするのは簡単ではありません。そのような場合でも、以下の点は配慮できると良いでしょう。

マウスを使わないユーザが利用できるようにキーボードコントロールを実装する
色覚障害者が利用できるように、十分なコントラスがある色を使用する

過度のJavaScriptにともなう問題

JavaScriptによってHTML/CSSを生成するWebサイトはさまざまなアクセシビリティの問題や付随するその他の問題が発生します。そのため、JavaScriptによってHTML/CSSを生成するような実装は避けた方が良いでしょう。

ひかえめに保つこと

Webページの基本的な機能はJavaScriptなしで動作するのが理想的です。以下のようにブラウザ内蔵の機能を使用するのが望ましいでしょう。

クライアント側のフォーム検査を提供すること
キーボードのみのユーザにとって操作可能な、HTMLの<video>用のカスタムコントロールを提供すること

フォームの実装は以下の点を考慮するとアクセシビリティを向上させることができます。

クライアント側の検証によって、エラーをユーザに即時フィードバックする
エラーが存在する時にだけエラーを表示させる

WCAG2.2 達成基準 3.3.1 エラーの特定において「入力エラーが自動的に検出された場合は、エラーとなっている箇所が特定され、そのエラーが利用者にテキストで説明される。」ことが達成基準として記載されています。

JavaScriptのアクセシビリティのその他の問題

マウス特有のイベント

ユーザとの対話的動作のほとんどはイベントハンドラーを利用してクライアント側のJavaScriptで実装されます。
mouseoverやmouseout、dblclickなどのマウス特有のイベントはキーボードコントロールのようなマウス操作以外の仕組みを利用しているとアクセシブルではなくなってしまいます。

これらの問題を軽減するために、他の手段によってアクティブにできる類似イベントと二重化するのが良いでしょう。focusとblurはキーボードのユーザに対するアクセシビリティを提供してくれます。

まとめ

この記事ではCSS、JavaScriptそれぞれに対してアクセシビリティ観点で考慮すべきことをまとめました。

フロントエンドエンジニアのWeb開発アクセシビリティ入門①｜HTMLは以下の記事にまとめています。

アクセシビリティ入門③｜WAI-ARIAはこれから記事にまとめる予定です。

参考サイト

本記事を執筆するに当たって勉強したものは以下の通りです。

MDN-CSS と JavaScript のアクセシビリティのベストプラクティス：https://developer.mozilla.org/ja/docs/Learn/Accessibility/CSS_and_JavaScript
WCAG2.2：https://waic.jp/translations/WCAG22/