Zenn
YAMAP テックブログPublicationへの投稿
🔰

はじめてのアクセシビリティ改善活動

Izumi
2023/12/09に公開
CSS
HTML
#
accessibility
#
a11y
tech

はじめに

この記事は YAMAP エンジニア Advent Calender 2023 8 日目の記事です。
https://qiita.com/advent-calendar/2023/yamap-engineers

こんにちは。今年の 9 月に YAMAP のフロントエンドエンジニアとして入社した Izumi です！
新規サービスの開発に携わっています。
入社してから、フロントエンドチームを中心に「アクセシビリティやっていき会」という勉強会が１年以上継続して行われていることを知りました。
それまで、アクセシビリティという言葉や、なぜ必要なのかはなんとなく知っていましたが、実際に何から手をつけたらいいか分からない状態でした。

そこで、アクセシビリティ初心者向けのウェビナーに出たり、「アクセシビリティやっていき会」で質問会を設けたりして、私の携わるサービスでどこから改善できそうかを探っていきました。（入社時には初期リリースに必要な画面や機能がほぼ出来上がっている状態で、私が引き継ぐ形でした。）

本記事が私と同じように「アクセシビリティの重要性は分かったけど、何から手をつけたらいいかわからない...!」という方の一助になればいいなと思います。

何から始めたか

アクセシビリティ対応と一言でいっても範囲が広いのでどこから手をつけていいのか分からない、というのがアクセシビリティ初心者のあるあるだと思います。

たとえば、W3C(World Wide Web Consortium: 各種技術の標準化を推進するために設立された非営利団体)のサブグループWAI(Web Accessibility Initiative)が策定する WCAG(Web Accessibility Guideline) というガイドラインがあり、「WCAG2.0 への適合を理解する」によると適合レベルが以下のように分かれています。

レベル A:レベル A (適合の最低レベル) で適合するには、ウェブページがレベル A 達成基準のすべてを満たすか、又は適合している代替版を提供する。
レベル AA:レベル AA で適合するには、ウェブページはレベル A 及びレベル AA 達成基準のすべてを満たすか、又はレベル AA に適合している代替版を提供する。
レベル AAA:レベル AAA で適合するには、ウェブページがレベル A、レベル AA、及びレベル AAA 達成基準のすべてを満たすか、又はレベル AAA に適合している代替版を提供する。

基本的には企業などの団体が作成するコンテンツではレベル AA の達成が求められます。[1]
具体的な対応としてはfreee さんのアクセシビリティー・ガイドラインがわかりやすいのですが、
これをいきなり達成しようとするのもなかなかハードルが高いように思えました。

そこで、私が参加した『Web アプリケーションアクセシビリティ――今日から始める現場からの改善』解説ウェビナーでスピーカーの伊原さんが「いきなりレベル AA の達成を目指さなくても、できることから始めれば良い。たとえば、キーボード操作で目的が達成できるようにするなど。」ということをおっしゃっていました。
「アクセシビリティ対応何したらいいか分からない」というのは「誰にとってのどんな問題を解決するのかが分からない」というのが少なからずあり、自分ごと化できない原因となっていたように思えます。
「キーボード操作できるようにする」というのは個別具体的で、自分にとっても使いやすくなるという点でとてもいいなと思いました。私自身もたまにキーボード操作をするのと、新規サービスの特性上フォームを多く扱うというのもありました。

実際に行ったこと

まず、キーボード操作は（自分以外でも）どのような方が利用するのかを調べたところ、大きく分けて３種類のユーザーがいるようでした。[2]

  • スクリーンリーダーを利用する人。スクリーンリーダーを使うのは目が見えない人が使うものだと思っていましたが、弱視であったり認知障害(失読症・ディスクレシア)の方も Web コンテンツを理解するためにスクリーンリーダーを利用し、そのほどんどをキーボードで操作するとのことでした。
  • マウス操作が難しい人。口棒のようなものを使ってキーボードを操作したり、キーボードの代替となるようなスイッチを使います。一時的にマウスが壊れるなどといった状況も当てはまると思います。（私自身も過去に経験があります）
  • パワーユーザー。これは開発者など、キーボード操作になれていてフォーム入力の際に各フィールドをクリックするよりもタブで移動するのを好む人たちです。

次に開発中の新規サービスの画面をどこまでキーボード操作(タブ移動)できるか試してみました。
(サービスローンチ前のためマスクをしています 🙏)
対応前: タブ移動をするとバリデーションエラーによってのみどこにフォーカスされてたかがわかる...
Before: タブ移動をするとバリデーションエラーによってのみどこにフォーカスされてたかがわかる...

キーボード操作のアクセシビリティが不十分だとどれだけイライラさせられるかが分かるゲームというのをチームのメンバーに教えてもらいましたが、これに近いものがありますね...

今回の場合、大きく２つの問題があることがわかりました。

  1. フォーカスが当たっても、当たっていることが分からない要素がある
  2. そもそもフォーカスが当たらない要素がある

それぞれ詳しくみていきます。

1. フォーカスが当たっても、当たっていることが分からない要素がある 🤔

ブラウザではフォーカスされた要素にフォーカスインジケータと呼ばれる枠線が表示されるのが標準の機能としてあります。
Chrome だと以下のような青い枠線ですね。
focus indicator

上述の GIF の通り、これがなぜか表示されていませんでした。
:focus(:focus-visible)擬似クラスによって上書きできることを知っていましたが、コードを見てもそのような形跡がなく...
フロントエンドチームのメンバーに調査を手伝っていただき、犯人は reset css のライブラリthe-new-css-resetであることが分かりました。
よくよく見るとREADMEにはきちんと:focus(:focus-visible)に対する注意書きがありました 😇

To keep your website accessible, don't forget to take care of the :focus states.

README を読むまで知らなかったんですが、revertを設定することでブラウザのデフォルトスタイルに戻せるとのことでした。

    ':focus-visible': {
      outline: 'revert',
    },

reset css を使っている方は一度チェックしてみてもいいかもしれませんね。

ただ、これだけだと独自で実装されたコンポーネントにフォーカスインジケータが表示されないことがあります。
今回の場合はラジオボタンがそうでした。（実装方法にもよりますが）以下のようにすることでフォーカスインジケータを表示できました。

    ':focus-visible + label': {
      outline: '2px #4078e3 solid',
    },

フォーカスインジケータは必ずしもデフォルトに合わせる必要はありませんが、今回は Chrome のデフォルトに近い色にしました。
オリジナルのフォーカスインジケータをスタイリングする場合はコントラスト比に気をつけた方がよいとのことです。
WCAG 2.1 SC 1.4.11 Non-Text Contrastでは、フォーカスインジケーターと背景とのコントラスト比を少なくとも 3:1にすることを要求しています。

上記の色をコントラストチェッカーで計測したところ 4.1 でしたので基準は満たせていそうでした。

2. そもそもフォーカスが当たらない要素がある 🤔

元々の要素を非表示にして:before擬似要素などでスタイリングする、というのは独自コンポーネントを作る際によくやる手法ですよね。
今回はそれがdisplay: noneによって実装されていたのが原因でした。
display: none または visibility: hiddenすると、アクセシビリティツリーから削除されるため、フォーカスができなくなってしまいます。
なので、今回のようなフォーカス可能であるべきコンポーネントに対してはopacity: 0で見えなくする必要がありました。

-    display: 'none',
+    opacity: '0',
+    position: 'absolute', // レイアウトに影響ないようにする

以上の対応でひとまずキーボード操作ができるようになりました。

対応後: フォーカス位置がわかるようになりました
After: 必要な要素にフォーカスでき、それが視認できる 🎉

おわりに

今回行った対応としては決して大きいものではありませんが、キーボードのみで操作するユーザーにとってはほぼ不可能だったことが可能になったという点で大きな成果だと思います。
また、こんな小さい対応で記事にしていいかな、、という気持ちもありましたが、あえて記事にすることで「アクセシビリティ対応始めたいけど、なにからやったらいいか分からない！」という方の参考になれば幸いです。
アクセシビリティを学べば学ぶほど、知らないことやできていないことを知ることになります...😨
しかし、できることからコツコツと、というのがアクセシビリティ改善の基本スタンスだと思います。
直近ではフォーム画面をキーボード操作で可能にするだけでなく、スクリーンリーダーでも破綻しないような作りにしていく予定です。

継続的に改善や実装を行っていき、一人でも多くのユーザーに使っていただけるよう頑張ります 💪！

We are hiring

現在、株式会社ヤマップではアウトドア好きなエンジニアを絶賛募集中です！
アクセシビリティに興味のある方もぜひ！

https://www.wantedly.com/companies/yamap/projects

脚注

  1. Web Content Accessibility Guidelines (WCAG) ↩︎

  2. Accessible Focus Indicators: Who Needs Focus Indicators, Anyway? ↩︎

GitHubで編集を提案
YAMAP テックブログ
YAMAP テックブログPublication

国内 No.1 登山アプリ（2021年8月 登山アプリ利用者数調査 [App Ape調べ]）「YAMAP」を提供する株式会社ヤマップのテックブログです。

Discussion