Blog
ウェブアクセシビリティ対応を効果的に!実施前に知っておきたい設計の考え方
ウェブアクセシビリティの対応として必要なこと
株式会社デパートのブログでもいくつかの記事でウェブアクセシビリティに関して紹介をしていますが、ウェブアクセシビリティの対応として、どこまでのことが必要なのかを改めてまとめてみたいと思います。
その他の関連記事
アクセシビリティとは?Webサイトにおける重要性とおさえるべきポイントを解説
【2024年4月義務化?】ウェブアクセシビリティ 対応しないと発生するリスクや対策のポイントを紹介
Webデザイナー向け!アクセシビリティへの取り組みとデザインポイントの解説
ウェブアクセシビリティ対応!UI実装として必要な基本的なポイントまとめ
ウェブアクセシビリティの対応のポイント
ポイント1 代替テキスト・音声のテキスト表示の導入
ポイント2 テキストのフォントやカラーへの配慮
ポイント3 様々な環境における操作性の実現
ポイント4 集中しやすい画面デザインの設計
ポイント5 一目でわかる構成の実現
上記のうち、1、2、3に関しては、Webサイトとしての基本的な要件と言えると思います。
そして4、5に関しては、Webサイトのコンテンツ内容や、種別によって差異がある部分も含まれます。
UIや機能的な部分では達成しなければならない一定の基準があり、機械的に対応できる部分も少なくありませんし、そういった部分はテストツールでも検証が可能です。
逆に、レイアウトやページの要素の組み合わせ自体は機械的な判断が難しい部分があります。
数値や設定だけではわからない、使いやすさ、見やすさなど、ユーザビリティに近い領域では設定上は問題がなくても、コンテンツや要素の組み合わせによっては使いづらいものになる場合もあります。
Webサイトとしてのアクセシビリティ対応の種類
前述したその他の記事でも紹介していますが、ウェブアクセシビリティ対応は大まかに下記の種類があります。
これらの対応項目に関して、実際の対応ではどちらも機械的、人が目検での確認をしていく必要がありますが、「確認のしやすさ」をわかりやすくするため表で表してみました。
項目 | 機械的な対応 | 人が目検で対応 |
---|---|---|
フォントの使用と設定 | ◯ | ◯ |
カラー・コントラスト比設定 | ◎ | △ |
HTMLマークアップ | ◎ | △ |
ブラウザ補助機能を利用できる設定 | ◯ | ◯ |
ナビゲーション設計 | △ | ◎ |
インタラクション設定 | △ | ◎ |
アニメーション・演出 | △ | ◎ |
※AIや高度なテストツールを使用する場合には対応できるものもあると思います。
※目検での確認で◯になっていないものは専門知識があれば可能です。
機械的にできるウェブアクセシビリティ対応
機械的に対応をする場合には、そもそも最初から対応がしやすい、またはあらかじめWebサイトを作っていくツールとして対応されているものを使用することをおすすめします。
アクセシビリティ対応UIキットを用意する
株式会社デパートではよく使用するUIのアクセシビリティ対応を研究し、社内スニペットツールとして使用できるようにしています。
CSS・UIフレームワーク
BootstrapやMaterial-UIなどの定番CSSフレームワークや、TailwindCSSベースのshadcn/uiなどのモダンなUIフレームワークでは、使うだけでアクセシビリティ対応がされたUIで実装ができます。
各種フレームワークのサイトで説明がありますので、より自身の求める内容にマッチしたものを選んでも良いと思います。
Bootstrapのアクセシビリティページ
https://getbootstrap.jp/docs/5.3/getting-started/accessibility/
Material-UIのアクセシビリティページ
https://mui.com/base-ui/getting-started/accessibility/
shadcn/uiのベースになっているRadixのアクセシビリティページ
https://www.radix-ui.com/primitives/docs/overview/accessibility
確認してみました:shadcn/uiを使って株式会社デパートオフィシャルサイトのデータを表示させたサンプル
いくつか未対応部分があるようですが、概ねアクセシビリティの設定ができています。
人の目検や内容に沿って行うウェブアクセシビリティ対応
機械的な対応では十分ではない部分に関して、実装や確認のポイントと、便利なツールの紹介をしたいと思います。
ナビゲーション設計
ナビゲーションのガイドラインとしてはWCAG 2.1を見てもさまざまな要件があり、機械的に対応できる部分もあります。
ナビゲーション可能: ガイドライン 2.4 を理解する
https://waic.jp/translations/WCAG21/Understanding/navigable.html
しかし、サイト全体の設計として複数のページへの適用を考える必要もあります。
どのページにおいても、ナビゲーションの出現順序やレイアウトが一貫していると、スクリーン・リーダーのユーザーの場合、必ずしも毎回同じ内容を読み上げさせる必要がなくなります。
加えて、ページへの動線を複数提供することと、そのページがサイト構造においてどこに位置しているのかを明示することをが推奨されています。
また、サイト内検索を設置することで、特定のコンテンツをすばやく簡単に見つけることができるため、アクセシビリティを向上させることができます。
そういった設計部分では人が関わる必要があります。
インタラクション設定
インタラクション設定は、ユーザーがWebサイトを利用する際の操作方法や体験を改善するためにも重要なものですし、キーボードやマウス以外の操作に関しても考慮する必要があります。
基本的な対応は機械的に判定もできますが、それが正しく内容に沿った挙動をするのか、より良く一貫したものであるか、という点に関して機械的に判断をするのは難しい部分があります。
Webサイトで行われる主なイベント(ユーザーの行動)
- クリックイベント
- マウスオーバーイベント
- フォーカスイベント
- キーボードイベント
- サブミットイベント
- ロードイベント
- スクロールイベント
- タッチイベント
- リサイズイベント
主に上記の行動をユーザーが行いますが、フォーカス時のインタラクションは入力エリアにフォーカスした時の他に、UIによってはマウスオーバーと同じ挙動を設定をした方が良い場合もあります。
また、ゲームパッドなどでは十字キーでの操作に関しても配慮をする必要があるかもしれません。
正しく意図した挙動をしているか、という点では人が関わる必要があります。
アニメーション・演出
アニメーションや演出に関しては、過度に動き続けるものや発光に関して、時間や回数がアクセシビリティの要件として定められていますし、カルーセルスライダーなどは停止や再生を行える必要があります。
機械的な判定も可能だと思いますが、正しい数値設定でフェード切り替えのコンテンツがあったとして、それがアクセシビリティとして正しくコンテンツを参照できる状態であるか、必ず操作ができる状態にあるか、そして変化があり通知をした方が良いものに関して、ARIA属性などで正しく通知ができているか、そういった複合的な対応に関して適切な状態を判断するのは人が関わる必要があります。
また、アニメーションに関してはデバイス側でオフにすることが可能です。
WCAGの達成基準AAAでは、CSSアニメーションも基本的にはオフできるように設定しなければならないですが、UXの観点からも必ずアニメーションが必要なのかは検討すべきだと思います。
スクロールアニメーションやパララックスなどは目を引く演出ですが、コンテンツやWebサイトの性質的に情報へのアクセスを阻害する可能性があるかもしれません。
まとめ
ウェブアクセシビリティの対応としてさまざまな項目がありますが、機械的に対応できる部分に関しては、あらかじめ対応できるツールを使用することで対応自体への負荷を減らすことができると思います。
しかし、それだけでは足りない対応に関しては専門的な知識を持った技術者が必要なケースがありますし、Webサイト運営側の考えと構築時のポイントを合わせて設計をする必要があります。
株式会社デパートではウェブアクセシビリティへ深い知見と対応実績を持つエンジニアが在籍し、ご要望に応じてアクセシビリティの達成基準に準拠したWebサイト制作を行っています。
企業としての取り組み内容からのご相談も可能ですので、お気軽にご相談ください。
Webマーケティング、Web制作に関することなら
|