こんにちは。Backlogチームの中川です。
本記事では、Backlogが最近おこなっているスクリーンリーダー向けアクセシビリティ改善の取り組みを元に、明日から、いや、今開いてる画面からでも始められるアクセシビリティ改善についてご紹介します。
ちなみに、スクリーンリーダーって何？という方のために簡単にご説明しますと、スクリーンリーダーとは、視覚障がいを持つ方がPCを操作するのに使用する音声読み上げソフトです。無料で代表的なものは、Windows では NVDA、Mac では標準搭載されている VoiceOver などがあります。Backlogの改善では主にNVDAを使用して確認作業を行っています。
すぐにでも始められる作業コストが少ない改善
見出しをちゃんとマークアップする
スクリーンリーダーではコンテンツ間を移動するのに、見出しを手がかりにすることが多いので、見た目の文字サイズではなく文書構造や前の見出しとのコンテキストからh1〜h6の適切な見出しレベルをつけましょう。
また、レイアウトなどで関係性が成立していて見出しが不要なところであっても、読み上げ専用の隠し見出しを置くことでスクリーンリーダー利用者にはコンテンツ理解のサポートになることがあります。
入力フォームはラベルと関連付ける
for, ID属性での関連付けがないと、例えば下の画像のようなテキストエリアにフォーカスがあたっても「エディット 複数行」としか読み上げられません。
フォームの各要素がラベルと関連付けできているか確認してみましょう。
ボタンは button type=”button” にする
改善前の Backlog をスクリーンリーダーで操作すると「ボイドレイ リンク」という謎の読み上げが大量にされていました。これは a要素でテキストコンテンツがないと href属性が読み上げられるというスクリーンリーダーの仕様によりjavascript:void(0);を読み上げていたためです。
<a href="javascript:void(0);"> SVGアイコンのみ </a>
ボタンは buttonタグでマークアップし、アイコンや画像のみの場合はわかりやすいテキストコンテンツがちゃんと置いてあるか確認しましょう。
また、下の画像のようにボタンを a要素 ならまだしも、span や div など特に意味のないタグでマークアップしてしまい、CSSで見た目をボタンのように見せている箇所では、スクリーンリーダーでその存在に気づくことができないうえに、キーボードでフォーカスが当てられません。
ちなみに、この「ファイルを選択…」ボタンが spanタグでマークアップされていたのは、ファイルアップロードなどで使用する type=”file” 型の input要素がCSSで見た目を変更できないためで、ボタンの見た目になる class を指定した span タグでラップすることでボタンっぽく見せていました。
こういったフォーム要素、特にチェックボックスやラジオボタン、セレクトボックスなどは、CSSで見た目をカスタマイズすることも多いので、やむおえず span や div要素でマークアップする場合は、ちゃんとフォーカスがあてられてキーボードで操作可能かどうか、今一度確認してみましょう。
リンクテキストは飛び先がわかるようにする
よくある「詳細はこちら」ではリンク先がわからないので、飛び先のわかる文言にしましょう。とはいえ、スペース的に領域が限られている場合などは aria-label属性を使うと見た目的には影響がなくレイアウトに気を使わなくてもよいので、シュッとしたサイトなどではおすすめです。
<a href="mentenounce.html" aria-label="メンテナンスの詳細はこちら（別窓で開く）" target="_blank">詳細はこちら</a>
もしくは関連する見出しなどが近くにある場合は、aria-labelledby属性で関連付けするとそれ専用の言語リソースを用意しなくてもとりあえずの対応にはなるので、多言語サイトでさくっと対応するには良いかもしれません。
<h2 id="headline">メンテナンス情報</h2> <p> Backlogのメンテナンス情報をお知らせしています。 <a href="mentenounce.html" aria-labelledby="headline">詳しくはこちら</a> </p>
読み上げは「詳しくはこちら メンテナンス情報 リンク」、「詳しくはこちら」だけよりもはるかに親切になりました。
フォーカススタイルをちゃんと出す
ページ内のすべてのコンテンツにキーボードでアクセスできるようになっていることはアクセシビリティ対応の基本ですが、outline: none;でフォーカスインジケータを消すだけ消して、特にフォーカススタイルを用意していないと、フォーカスがどこにあるのかまったくわからなくなってしまいます。
Backlogのアクセシビリティ改善を始めるにあたって、さてキーボードで操作してみるか！と思ってやってみたらフォーカスの場所がぜんぜんわからなくて、実はこれがまず最初にやったことでした（汗）。
改善前、グローバルメニューをTABキーで移動しているがフォーカスが迷子
outline: none;した場合はフォーカスが当たったときのスタイルも忘れず用意しましょう。
また、スクリーンリーダー利用者だけでなく弱視のユーザーの方々も考慮すると、そもそも outline: none;でフォーカスインジケータを消さない、もしくはデフォルトの見た目以上にコントラストが確保されたフォーカスのスタイルを設定するのが良いでしょう。
よくわからない tabindex は一旦 “0” にする
このGIF画像は tabindex 修正前の課題追加画面です。TABキーによるフォーカス移動で意味のわからない順序で移動しています。これは、各要素に意図しない tabindex が指定されているのが原因です。 度重なるコードの修正によって、元々考えられて設定されていた tabindex があちこちに移動した上に、結果不要と判断されて消されたり消されなかったりしていました。こういったもう誰にも正解がわからない tabindex は、一旦 リセットするという意味で値をすべて “0 ” にすると、とりあえずはHTMLの構造順に動くようになります。
読み上げテキストをわかりやすくする
HTML的にはテキストコンテンツもあって読み上げ対応できていそうなところも、実際にスクリーンリーダーで読み上げてみると、いまいち意味が伝わりにくくなっていることもあります。
プロジェクトホームのサイドカラムにあるプロジェクト全課題の状態を可視化したもの
<a href="省略" title="『未対応』の課題を検索します">
未対応<span>53</span>
</a>
読み上げ内容は「未対応 53 リンク 『未対応』の課題を検索します」、検索ボタンなのかリンクなのか、なんの数字なのかわかりにくいです。
<a href="省略" aria-label="未対応53件の課題一覧">
未対応<span>53</span>
</a>
こうすることで、読み上げ内容は「未対応53件の課題一覧 リンク」、未対応の課題53件の一覧に飛ぶリンク、ということがわかりやすくなりました。
けっこうコストかかるけどやったほうがいい改善
対応しておかないとスクリーンリーダー利用者には使えない可能性も出てくる重要なポイントではあるけど、影響範囲や作業の難易度もあり、それなりにコストがかかる改善を紹介します。まだ Backlogでも対応しきれてないです（汗）。
モーダルダイアログのフォーカスコントロール
ダイアログを開くボタンを押してモーダルダイアログが開いたあとフォーカスをボタンからダイアログ自体に移動してあげましょう。そうしないと、キーボードでダイアログの中を操作できなかったり、ダイアログが出ていることに気づかず操作を続けてしまうことがあります。
また、ダイアログ内にフォーカスが移ったあとは閉じるまでその中を周回でき、かつ閉じたあとは、元のボタンにフォーカスが戻っているようになっていれば、100点満点です。
エラーメッセージをわかりやすくする
「エラーで送信できません」だけでは何をどう修正すればよいかわからないので、そのフォーム全体のエラー件数や箇所を明示した上で、該当箇所にフォーカスがあたるとエラー内容と修正方法が読み上げられるようにしましょう。
<div id="error" aria-live="assertive"><!--エラー発生後すぐに読み上げられるメッセージ、件数や箇所--></div> <form id="form"> <input id="input" type="text" aria-describedby="errorMsg"> <div id="errorMsg"><!-- #inputにフォーカスが当たると読み上げられるエラー内容と修正方法 --></div> <button type="submit">登録する</button> </form>
Backlogの課題追加画面では、元々表示していた「件名は必ず入力してください」というエラーに aria-live属性をつけてすぐに読み上げるように、件名の input要素には aria-invalid属性をつけてエラー該当箇所を明示しています。以前は読み上げすらされていなかったので、この2つの対応だけでもかなり効果のある改善になったかと思います。
一番コストがかかるのは、JavaScriptによって動的にDOMが生成されたり操作できる箇所
前述したモーダルダイアログやバリデーションエラー、それ以外にもドロップダウンメニュー、タブコンテンツ、スライドコンテンツなど、Webアプリケーションやサイトには複雑なUI操作が必要な箇所がたくさんあると思いますが、それらをスクリーンリーダーに対応するためには、通常のマウスやトラックパッドでの操作だけではなく、キーボードでも操作できるようにしたり、状況に応じてフォーカスを適切な場所に移動、もしくは変なところにいかないように操作を限定するような実装が必要になります。
また、JavaScript/CSSによって複雑に変化するようなUIは、特に意味のない div や span タグでマークアップにせざるをえない場面もあるので、role属性で意味付けしたり、UIの状態や更新内容を知らせるための aria属性を付けて、さらにそれを動的に付け替えたりなど、かなり作業コストがかかってきます。
ただ、こういったWAI-ARIAを使った対応は、どこまで対応できていれば実際にスクリーンリーダーを利用されているユーザーさんにとって嬉しいのかわからないことも多いので、いきなり無理をしてベストプラクティス通りの完璧な状態を目指すよりは、ユーザーさんからのフィードバックをいただきながら徐々に微調整を加えて改善していくのが良いのかなと思います。
まとめ
アクセシビリティ対応と聞くと、最初からある程度方針を決めていろいろ考慮しておかないと、リリース後や運用段階から対応するのはかなり大変そう、というふうに思ってしまいがちですが、実際にやってみると簡単なマークアップやテキストの修正だけでも大幅に改善されます。
Backlogのアクセシビリティ対応もまだまだできていないところがたくさんありますが（特に前述したコスト高なところ）、去年末あたりから少しずつ改善＆リリースして、元々「スクリーンリーダーで使えない！」というところから「ちょっとは使えるかも」ぐらいには改善しているのかなと思えるような、嬉しい声をちらほらいただけるようになってきました。
なにより、今回のアクセシビリティ改善の取り組みを通じて、HTMLやCSS、JavaScriptに関わる自分の仕事をあらためて見つめ直すとても良い機会にもなりました。今後も少しでもたくさんの方に利用していただけるよう改善を続けていきます。
アクセシビリティ対応しないとなぁ、と漠然と思っているみなさんは、とりあえず今開いてる画面でvoid(0);を検索にかけてみることからはじめてみましょう！
