Ateam Tech Blog

エイチームのエンジニアたちによるテックブログ

アクセシビリティ始めました

自己紹介

こんにちは!

エイチームライフデザインでハナユメというサービスの開発を行っている @shamokit_y2323です。

Hatena Blogに記事を投稿するのは初めてです。よろしくお願いします。

Svelteとねことアクセシビリティがすきです。

一組でも多くのカップルに"理想の結婚式"のきっかけを

ハナユメでは「一組でも多くのカップルに"理想の結婚式"のきっかけを」という理念を掲げています。

さて、「一組でも多くのカップルに」ハナユメというサービスを届けるため、何ができるでしょうか?

私は、今までアプローチできていなかったユーザーにも価値を届けられるという点でアクセシビリティの向上がこれを達成するのにぴったりだと考えました。 (もともとアクセシビリティに関心があったので、キタキタコレコレ!という気持ちでした。)

問題点の洗い出し

じゃあやっていくぞということになりましたが、いきなり全てのページに対して対応を行うとデグレが怖いですし、ページ単位、具体的にいうとハナユメのコア機能である検索ページで改善を進めることにしました。

アクセシビリティを高めるためにまず現状の問題点を確認しようということでざっと洗い出してみたところ、 以下のような項目が見つかりました。

  • ボタンがaタグで実装されており、スクリーンリーダーで「リンク」と読み上げられてしまう
  • アコーディオンがdivで実装されており、キーボードで操作できない(特にナビゲーションメニュー)
  • メインコンテンツがmainタグで囲まれておらず、メインコンテンツにスキップできない
  • タブがキーボード操作できない、スクリーンリーダーの読み上げでタブだとわからない
  • モーダルがフォーカストラップされておらずモーダルの外にフォーカスが移ってしまう
  • 画像に適切なaltが入っていない
  • ボタンにラベルが付いておらず、なんのボタンなのかわからない
  • 読ませたいテキストのコントラスト比が低い
  • ナビゲーションや検索などのコンテンツにランドマークから辿り着けない

問題は山積みで、特にナビゲーションメニューがキーボード操作できないのは致命的でした。

この状態ではロービジョンの方やスクリーンリーダーユーザーの方などがコンテンツを正しく認識できないので、「一組でも多くのカップルに」価値を届けることができません。

改善していく

正しいタグ、属性を使う

まずは 正しいタグ、属性を使う をやりました。 例えばaタグをbuttonタグに置き換える、altがないimgタグにaltをつける、メインコンテンツをmainで囲む などです。

JS+aria

次にアコーディオン、タブ、モーダルなど、aria属性やJSが必要な部分のマークアップを改善していきました。 詳しくはW3CのPatternsページをご確認ください。

特にナビゲーションメニューがキーボード操作できないのは致命的だったので優先して対応を進めました。

ここまでやるといったんスクリーンリーダーでそのコンテンツが開閉可能か、タブなのか、モーダルなのかがわかるようになり、キーボードでの操作も容易になりました。

また、この辺までは見た目に影響がないのでエンジニア手動で進めることができました。

デザイナさんに協力いただく

エンジニアだけで全部できたら楽なのですが、そういうわけにもいきません。 色や見た目を勝手に変更しておきました!はちょっとまずいですよね…

ということでデザイナさんに「コントラスト比が低い部分があるんですけど…」と相談して、読ませたい部分だけどコントラスト比が低い部分の色を変更していただきました。 ここはブランドのイメージなどもあるのでスムーズに進まないかもしれないと思っていましたが、予想に反してスムーズにことが進んだので正直ラッキーでした。

コントラスト比が上がったことで、SEO周りの計測結果も良くなりLighthouseの点数も上がるなどいいことづくしでした。

非同期取得

検索条件を変更した時に件数がわかるUIがあるのですが、取得された件数を通知できていませんでした。

件数は検索ボタンのテキストに含めていたのでそこにフォーカスを当てれば件数がわかるようにはなっていたのですが、 条件を変更するたびにいちいちボタンにフォーカスするのは面倒です。

そこで、ARIA ライブリージョンを使って何件取得しましたよ〜という情報を支援技術に通知するように変更したことで、耳を使って操作しているユーザーにもハッピーな実装になりました。

この辺までの対応で、一旦スクリーンリーダーでの操作がほぼ問題なくなり、かつLighthouseの点数も十分満足できる点数に上がりました。

アクセシビリティの勉強会を開く

関心のあるメンバーを集めて、以下2冊の輪読会を始めました。

  • 見えにくい、読みにくい「困った!」を解決するデザイン
  • Webアプリケーションアクセシビリティ

今は大体毎回5人くらいは集まってくださっており、 Google Documentにコメントを書いて意見や情報を交換しています。 特にQiitaチームとハナユメチームからの参加が多く、会社を超えたコミュニケーションの場にもなっているので嬉しいです。

アクセシビリティはデザイナとエンジニアの間の糊付けになると思っていますが、 その他の部署や会社にまで話が広がっているのでそういう面でもポテンシャルが高いと感じています。

今年で一旦この2冊の輪読会が終わる予定で、来年はWCAGをみんなで読んでいこうと思っています。

Lintで縛る

この辺は記事にまとめているのでみてみてください。

qiita.com

チーム全員アクセシビリティに強い人!というのは難しいですし、全員全ての知識を持っているわけでもないのでLintで縛るのは重要です。

音声コントロール

ここからはこれから改善予定です。

qiita.com

スクリーンリーダーへの対応だけを気にしているとaria-labelを使ってしまいがちです。 こちらの記事にまとめていますが、例えばボタンに「カウントアップする」と書いてあってaria-labelに「カウントアップ」と書いてしまっている場合、音声コントロールで「カウントアップする クリック」と言ってもボタンをクリックできません。

まずはできるところから改善していく というスタンスで進めていたため、この辺はまだちゃんと対応できていません。 来年からこの辺も改善していく予定です。

まとめ

ということで、アクセシビリティを改善していっていますよ という記事でした。

Webはもともとアクセシブルですから、実装する人間のスキル不足で品質の低いアプリケーションを世に送り出してしまわないように しなければなりません。

残念なことに、今世の中にはそういう面でアクセシビリティの改善の余地が多く残っているアプリケーションがたくさんあります。 アクセシビリティの重要性が広まることで、誰にでもやさしいサイト、アプリケーションが増えていくことを願っています。

またハナユメに関してもまだまだ全然対応が進んでいません。 「一組でも多くのカップルに"理想の結婚式"のきっかけを」届けるためにこれからのアクセシビリティの改善には力を入れていきます。