アクセシビリティ向上で「すべての人が使える製品」を目指す 障害当事者と協力して進めた改善プロセスとは

アクセシビリティ向上で「すべての人が使える製品」を目指す 障害当事者と協力して進めた改善プロセスとは
  • このエントリーをはてなブックマークに追加

 株式会社SmartHRで、SmartHRのプロダクトを誰もが使えるようにすることをミッションとしたデザイン組織「プログレッシブデザイングループ」、通称「プログレ」が、今まで培ってきた知見をもとに、デザインを活用したアクセシビリティ向上の取り組みを解説します。最終回となる第4回は「障害当事者と協力して進めた改善プロセス」についてです。

 本連載の第1回から第3回では、SmartHRがアクセシビリティ向上のために実施している取り組みについて紹介しました。最終回となる今回は、仕組みを活用して向上したアクセシビリティ品質をさらに高めるために、障害当事者と協力して進めた改善プロセスや、その過程で浮かび上がった新たな課題についてお伝えします。

「すべての人が使える製品」を実現するために、ガイドラインを超える

 アクセシビリティについて改めておさらいしてみましょう。アクセシビリティは、サービスなどを誰もが円滑に利用できる度合いを表す言葉です。つまり、アクセシビリティが高いほど、サービスを円滑に利用できるユーザーが多くなります。逆に、アクセシビリティが低いほど、サービスを利用できないユーザーが多くなります。

 アクセシビリティはすべての人の利用に影響する品質です。そのなかでも、障害のあるユーザーの利用は、ウェブアクセシビリティの度合いに大きく影響を受けます。W3Cによるアクセシビリティのガイドライン、Web Content Accessibility Guidelines(WCAG)の概要には次のように書かれています。

このガイドラインに従うことで、全盲又はロービジョン、ろう又は難聴、運動制限、発話困難、光感受性発作及びこれらの組合せ、並びに学習障害及び認知限界への一部の適応を含んだ、様々な障害のある人に対して、コンテンツをアクセシブルにすることができる。しかし、これらの障害のある人に対するあらゆる利用者のニーズに対処するものではない。

(出典:WCAG 2.1 ウェブアクセシビリティ基盤委員会による日本語訳

 WCAGに従うことで「様々な障害のある人に対して、コンテンツをアクセシブルにすることができる。」とありますが、その次の文では「あらゆる利用者のニーズに対処するものではない。」と記載されています。言い換えると、「WCAGに従うことでコンテンツはアクセシブルになるが、それだけで利用者のニーズをまかなうことができるわけではない」ということです。

 SmartHRは、WCAGに準拠することをひとつの目標に掲げ、アクセシビリティ向上を進めています。WCAGに従って開発することで「利用できる」状態になる人は、一体どのくらいいるのでしょうか。そして対処できないニーズとは、どんなものでしょうか。すべての人が利用できる製品を実現するためには、障害当事者と直接関わり、WCAGでは対処できないニーズについて知っていくことが重要だと考えました。そこでSmartHRでは、障害当事者を巻き込みながら、高いアクセシビリティを必要とするユーザーは実際にどのように利用するのかを深掘りする取り組みを進めています。

アクセシビリティテスターの取り組み

 SmartHRには、製品のアクセシビリティ品質のチェックを行う「アクセシビリティテスタープロジェクト」があります。アクセシビリティテスターと呼ばれるプロジェクトのメンバーは、全員が障害当事者です。障害当事者が、それぞれの特性にもとづき製品のテストを行い、WCAGなどのガイドラインを用いた検証では見逃してしまうような、個別のユーザー特性による問題を発見していきます。

 現在、プロジェクトには視覚障害(弱視)のあるメンバーと、上肢障害のあるアクセシビリティテスター(以下、テスター)が所属しています。このプロジェクトのアクセシビリティテストは、テスターが日常生活で利用しているスクリーンリーダーなどの支援技術を使い、できるだけ普段の利用状況に近い環境で行います。実際のユーザーの利用状況をもとに作成したシナリオに沿ってSmartHRの各機能を操作し、使いにくかった点や使えなかった点を洗い出していきます。

 実際に行ったテストでは、弱視のテスターがWindowsのハイコントラストモードと拡大鏡を使ってSmartHRの入社手続き機能を利用し、問題なく利用できるかを検証しました。このケースでは、対象を拡大しながら、目への負担を減らした状態でも利用可能であるかを確認しました。

デスクトップパソコンで拡大鏡を利用してフォームを表示しているスクリーンショット。ファイルを選択というボタンにマウスをのせ、拡大している。
拡大鏡を利用したテストの様子

 このテストにより、次の問題点が見つかりました。

  • 文字が小さく読みにくい点が多数ある
  • ページ内にスクロール可能な箇所があると、ページ内を探索する難易度が上がる
  • 画面の右側にあるボタンを見つけにくい

 そして上肢障害のテスターが行ったテストでは、iOSのAssistiveTouchを活用しながら、限られた手の器用さでSmartHRの入社手続き機能をスムーズに利用できるかをチェックしました。

iPhoneで表示した入社手続きフォームのスクリーンショット。
iPhoneのAssistiveTouchを利用したテストの様子

 その結果、見つかった問題点は次のとおりです。

  • アイコンのみのボタンやリンクなどは、操作箇所が小さく押すのが難しい
  • カレンダー式UIでの日付選択において、前月以前の日付を選択するには、年と月を変更し表示するカレンダーを切り替える必要があるため、数字を入力して日付を指定するUIと比較して、必要な操作が多く手間がかかる
  • 縦にも横にもスクロール可能な領域では、意図した方向にスクロールするのが難しい

 このように、テストで見つかった問題点は、開発チームと共有し、協力しながら改善を進めています。

 さらに、各テスターの特性を活かした製品テストに加えて、さまざまな支援技術がSmartHR上で問題なく動作できるかどうかもテストしています。現在は、次の支援技術を用いたテストを行っているところです。

  • スクリーンリーダー(NVDA・PC-Talker・ナレーター・iOS VoiceOver)
  • 拡大鏡(Windows 11)
  • 色反転機能(Windows 11)

 テスターはこのプロジェクトに参画するまで、アクセシビリティに関する知識や製品テストの経験がほとんどありませんでした。しかしプロジェクトを通して、自身の特性にもとづく製品テストを進めながら、アクセシビリティや支援技術に関する知識を身につけています。その結果、より多くの支援技術を検証する発展的なテストが可能になりました。

※この続きは、会員の方のみお読みいただけます(登録無料)。