はじめまして。フロントエンドエンジニアの内田です。
最近福岡では日中30℃を超える気温でぐったりです。アイスがとろけております。
さて突然ですが、この記事をご覧になっている皆様はアクセシビリティについて悩んだ事はありますでしょうか？
Wizでは残念な事にWebアクセシビリティに対して、まだまだ高水準な品質を維持出来ていないのが現状です。
アクセシビリティとは
どのような環境にいても人々が平等にアクセス可能で、全てのコンテンツや機能が利用できる状態の指標です。
また、似た言葉としてユーザビリティがあります。
ユーザビリティとは
ユーザビリティは、ユーザーにとっての使いやすさを表す概念です。
ここで言う使いやすさとは、ユーザーがストレスを感じない操作性、わかりやすい導線設計を施し、成約に至るまでに必要な労力の少なさなどを指します。
今回はアクセシビリティについてお話させていただきます。
Webアクセシビリティにおいて意識する必要のある代表的なハンディキャップ例としては下記が挙げられます。
■全盲
全盲の方は画面上の文字を音声で読み上げるスクリーンリーダーや点字で表示する点字ディスプレイなどを利用して読み取っていますので画像とテキストの位置関係やどんな画像が表示されているのかが明確に把握できるような工夫をしなければいけません。
■ロービジョン
視力が低下している方や視野が狭くなっている場合（視野狭窄）、視野の真ん中が見えない場合（中心暗点）などの弱視の方を指します。
Webページを利用する際、ロービジョンのユーザーは次のような使い方をしている為、サイズ感やコントラストなどの視覚的表現、視覚以外の方法で情報取得ができる対応が必要になります。
- 画面拡大ソフトやOSに標準で搭載されている機能を用いて画面表示を拡大する
- 画面の色を反転する
- OSやブラウザの設定によって、文字サイズを変更する
■色覚多様性
色の見え方は人によって異なり、その割合は日本人の男性で５％、女性で0.2％と言われています。
よく言われる例だと正常と異常の状態を赤と緑の色だけで表現しているUI等は区別が難しくなります。対応方法としては下記のような配色を目指すべきでしょう。
- 赤と緑は見えづらいので青やオレンジを使う
- 色に頼らない、色数を増やさない
- コントラストを強くしすぎない
■上肢障害
手や腕に障害がある場合はマウスやトラックパッドなどが利用困難でありホバーやドラッグ＆ドロップが難しかったりするのでトラックボールを利用するパターンが多いようです。 なので、クリックポイントを近くしすぎるとトラックボールのほんの僅かな動きで通り過ぎてしまったりするので、リンクやアイコンなどのクリックできる位置をある程度余白をつけて配置する等の配慮が必要です。
■聴覚障害
近年では動画をコンテンツに含んでいる場合がありますが、その動画内で情報説明したりする場合には手話通訳をつけたり、字幕情報を付与したりして併用することが望ましいとされています。
例えば、動画の中で問い合わせ先などを示す場合には、問い合わせ電話番号などを音声だけで伝えず、視覚、聴覚の両方で具体的な情報を提供する必要があります。
また、最近では警告音の見える化などの対応もAppleでは配慮されています。 www.apple.com
ですが、これら全てを意識してエンジニアが対応していくのは困難です。
そこで、W3Cが標準化しているWCAGガイドラインを参照して全世界のエンジニアはこのガイドラインに準じて対応していく事になっているのですが、 このWCAGは正直何書いてるのか把握しづらく、「で？どうしたらいいの？」といった気持ちになる上、達成基準が設けられておりA (最低レベル)、AA、AAA (最高レベル)という基準があり、正直AAAに対応するにはかなりきびしい道のりです...
ではどうするか？
これらの問題を対応しなければいけない事はわかってはいるのですが、全ての項目を一つ一つ把握しつつDevToolsのLighthouseを実行して目視でチェックしていくのは非効率で地獄です。
そこで、弊社では一部メディアにてWebアクセシビリティー検証フレームワークであるacot-a11y/acotを導入してみました。
導入手順
acot 自体は puppeteer ではなく puppeteer-core へ依存するため、別途インストールが必要な構成となっています。
$ npm i --save-dev @acot/cli puppeteer
インストールが完了したら、以下のコマンドを実行する事で設定ファイルの構築を行うことができます。
$ npx acot init
すると下記のようにコンソール内にて対話形式で設定を進めていくと、acot.config.jsという設定ファイルが生成されます。カンタン！！！
✔ What is the origin for the audit target? · http://localhost:3000 ✔ What kind of server do you want to connect to? · command ✔ What is the command to start the server? · npm run dev ✔ Do you want to use the config recommended by acot? · no / yes ✔ Which runner do you want to use? · default ✔ Which format do you prefer for the config file? · javascript ✔ Which is the npm client used to install the dependent packages? · npm
■acot.config.js
module.exports = { extends: ['@acot'], connection: { command: 'npm run dev', }, origin: 'http://localhost:3000', paths: ['/'], };
では早速実行してみましょう！！
$ npx acot run
すると下記のようなサマリーが表示されました。
エラーの数が絶望的ですね。まぁこれは開発途中のものなのでご愛嬌。
さくっとErrorをPassできそうなものとしては@acot/wcag/img-has-nameあたりですかね。
ログを追うと
✖ img element or img role MUST has name. @acot/wcag/img-has-name ├─ <img src="/_next/image?url=%2Fimg%xxxxxxxxxx.png&w=1920&q=75" decoding="async" style="visibility: visible;… ├─ at ".contentsBox--keyVisual__img > div > img" └─ see https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html
と表示されており、おそらく画像に対してalt属性による代替テキストの設置、またはロールを付与し忘れるといった基本的な箇所が抜け落ちていたようです。
尚、このときのLighthouseによるアクセシビリティの数値としては87でした。
では対象箇所をさくっと修正して再度実行してみます。
お！@acot/wcag/img-has-nameが見事Passになりました！🙌🏼
ちなみにLighthouseで再度計測してみたところ指し示した値としては94！！たったこれだけで爆上がり！！
今回は単体ページでのチェックとなりましたが、acotのrunnerにsitemapのパスを指定することで複数ページに渡ってチェックしてくれる事も可能です。 ですが、おそらく数百のページを対象としたメディアサイトの場合は相当処理が重くなるかと思いますので要注意です。
module.exports = { runner: { uses: '@acot/sitemap', with: { source: 'http://localhost:3000/sitemap.xml', }, }, };
現段階の実行タイミングとしてはプレコミット時等のアクションを検知したオート実行ではなく任意のタイミングで実行する運用方法で対応しています。
まとめ
まだまだアクセシビリティについてはやらなければいけない事が山積みの状況ではありますがこのように一歩一歩着実にPassしていく事で本当のWebの世界というものが広がっていくような気がしてきます。
全世界のなるべく多くのユーザーに正しくわかりやすい情報を伝えていく事が自身の喜びでありWizの目標の１つです。
最後に
Wizではエンジニアとして一緒に働く仲間を絶賛募集しております。
ご興味のある方、是非ご覧下さい..！！
