サマーインターンサイトのアクセシビリティ対応の裏話 - Cybozu Inside Out

こんにちは、デザイングループ所属の小林です。サイボウズのサービスや製品に関するアクセシビリティ対応をしています。

先日、サイボウズはサマーインターンのWebサイトを公開しました。このサイト、実はWebアクセシビリティについて、さまざまな配慮をしながらデザインやマークアップを行なっています。今回はその制作裏話をしようと思います。

サイボウズサマーインターンWebサイトの表紙

なぜアクセシビリティ対応？

サイボウズでは、アクセシビリティを「ユーザがチームにアクセスできる能力」と定義してアクセシビリティの取り組みを進めています。

理想的には、サイボウズが制作しているすべてのWebサイトや製品、サービスについてアクセシビリティの配慮が行われることが望ましいですが、いきなり規模の大きい既存のWebサイトのアクセシビリティを改善するのは大きなコストがかかります。また、デザイナーやエンジニアのアクセシビリティに関するスキルも、一朝一夕に身につくものではありません。

そこで、まずは規模が小さく新規に作成するページについて、少しずつアクセシビリティに考慮することで、今後のサイトの改善のヒントを得ながら、一人ひとりのスキルを高めていこうということになりました。サマーインターンサイトは、１ページのみ、かつ新規につくるページだったので、目的に合致していました。

制作体制

サマーインターンサイトは、数名のデザイナーが人事やメンターと一緒に制作しました。制作中の成果物に対して、自分がアクセシビリティの観点から数回レビューを行い、各デザイナーに問題点や改善方法をフィードバックしました。

アクセシビリティレビュー

今回、アクセシビリティについては、以下のような観点を考慮して、チェックや改善を行いました。

色のコントラスト比

ロービジョンのユーザや、屋外で日光があたる環境などでは、コントラスト比の低い色同士を区別することが難しい場合があります。アクセシビリティの国際基準であるWeb Content Accessibility Guideline 2.0(WCAG 2.0)には、文字色と背景色のコントラスト比を一定値以上にせよ、という基準があります。

もともと「エントリー」ボタンについては、WCAG2.0の基準を満たしていませんでした。また、ボタンにマウスホバーをしたときには、コントラスト比がさらに低くなるデザインになっていました。デザイナーに相談し、マウスホバーする前後どちらでも、コントラスト比の基準を満たすように色を修正しました。

以下の画像は、修正前のエントリーボタンです：

修正前のエントリーボタン

以下の画像は、修正後のエントリーボタンです：

キーボードによる操作

マウスを使うことが難しいユーザにとっては、代替手段として、キーボードでマウスと同等の操作ができることが重要です。

当初のデザインでは、キーボード操作したときのインジケータがCSSで消されており、キーボードでどこを操作したのかがわからない状態だったので、インジケータを復活させました。

以下の画像は、Chromeでページ内のテキストリンクにキーボードフォーカスしたときの様子です。ここにはブラウザデフォルトのインジケータが表示されるデザインにしています。Chromeでは水色のインジケータが表示されます： Chromeでテキストリンクにキーボードフォーカスした様子

また、「募集要項」のボタンをクリックした時に表示されるダイアログは、当初LeanModalというライブラリを使って実装していましたが、 LeanModalはキーボード操作の対応が不十分で、ダイアログの裏側の要素にフォーカスすることができてしまっていました。これではマウスで操作できない部分をキーボードで操作できてしまいます。

キーボード操作に対応しているライブラリを探したところ、BootstrapのModalが対応できていたので、ライブラリを変更し、ダイアログを開いているときには、ダイアログの裏側にフォーカスがあたらないようにしました。

ダイアログのマークアップ

BootstrapのModalに関する文書には、アクセシビリティに関するポイントがまとめられています。この文書には、ダイアログのマークアップについて、以下のように記載されています:

role="dialog"をつける
aria-labelledby="..."に、ダイアログのタイトル部分のIDを指定する
aria-describedby="..."に、ダイアログのボディ部分のIDを指定する

これらの属性をつけることで、ダイアログを開いた時に、スクリーンリーダーが、ダイアログのタイトルやボディを読み上げます。デザイナーにマークアップの意味を説明し、各属性を追加しました。

画像の代替テキスト

当初、メンターの画像にはalt属性を使った代替テキストとしてメンターの名前がついていました。この指定方法でも大きな問題はありませんが、スクリーンリーダーなどで読み上げた際には、メンターの名前が二重で読み上げられることになります。今回は読み上げの冗長さを解消するため、画像のalt属性には空文字を指定するようにしました。

メンターの紹介のスクリーンショット。メンターの画像の下にメンターの名前、所属、FacebookとTwitterのリンクが書かれている。

アイコンフォント

「メンター」セクションのFacebookとTwitterのアイコンには、Font Awesomeが使われています。これらのアイコンは当初、以下のようにマークアップされていました。

<a href="..." target="_blank">
  <i class="fa fa-facebook-official fa-lg" aria-hidden="true"></i>
</a>

この実装では、アイコンにラベルがついていないため、スクリーンリーダーなどでアイコンを読み上げようとしても、読み上げが行われません。

Font AwesomeのAccessibilityに関するページには、aria-labelを使ってラベルをつけるように指示されています。これをデザイナーに伝え、アイコンフォントにはラベルをつけるようにしました。

<a href="..." target="_blank" aria-label="facebook">
  <i class="fa fa-facebook-official fa-lg" aria-hidden="true"></i>
</a>

レビューの効果

自動チェックツールによるエラーが0個に！

今回は、aXeというアクセシビリティ自動チェックツール(Chrome拡張)を導入し、上記に挙げた以外にも、様々なデザインやマークアップの修正を行いました。最終的に、aXeによるアクセシビリティエラーや警告の検出数を0個にすることができました。

aXeの自動テストでエラーが0個になった状態をChromeの開発コンソールで確認する様子。

デザイナーのスキルアップ

デザイナーのスキルも向上しました。例えば、「概要」の会社の「場所」につけられた地図アイコンは、 Font Awesomeで実装しましたが、デザイナー自ら、aria-labelをつけてくれるようになりました。

<a href="https://cybozu.co.jp/company/access/#tokyo" target="_blank" aria-label="地図">
  <i class="fa fa-map-marker fa-lg" aria-hidden="true"></i>
</a>

デザイナーに修正をお願いするときのポイント

できるだけ公式情報を参照する

デザイナーに修正をお願いするときは、個人のブログやTipの紹介等のページを参照することはできるだけ避けました。個人のブログなどで紹介されている技術情報の中には、アクセシビリティに配慮されていないものがあったり、一部の障がいや環境のみを取り上げて解説している場合があるためです。また、場当たり的な内容を伝えているという印象を与えかねないことも懸念のひとつでした。

代わりに、W3Cの提供しているページや、Font Awesome、Bootstrapの公式サイトを参照するようにし、標準的な対応であることを強調しました。この方法は、スキルアップを望んでいるデザイナーからも好評でした。

デザイナーとのやりとり。デザイナー「小林大輔さんのアクセシビリティの話はホント勉強になるなぁ。今まで作ったサイトも見直そーっと」と書かれている。