こんにちは、サイボウズでQAエンジニアをしている仙波です！みなさんのチームでは、アクセシビリティテスト、やっていますか？
最近、私が所属しているkintoneの開発チームでは、QAがアクセシビリティテストを担当するようになりました。今回はその経験について記事を書いたので、これからアクセシビリティテストを導入しようと思っている、または既にやっているけど他社はどうやっているのか気になる、という方の参考になれば幸いです！
背景と経緯
今までは？
「担当するように」と書きましたが、今まで全くアクセシビリティテストをしていなかったわけではありません。サイボウズには、kintone Design System（以下「kDS」）チームという、kintoneのユーザー体験を最高にすることをミッションに掲げているチームがあります。そのチーム内にアクセシビリティの有識者がいるため、kDSチームが作ったガイドラインにのっとって開発を行い、kDSチームがコードレビューをして、さらに自動ツールでチェックし、QAが「キーボードのみでの操作が可能か」や、「読み上げがされるか」のテストをしていました。
ただ、どのタスクに対してテストをするのか、どういった観点でどこまでテストするのかなどはそれぞれの開発チームに任されており、品質にはばらつきがありました。
*前提として、kintoneの開発チームは複数あり、その中にPGやQAなどが在籍、kDSチームは開発チーム外に在籍しています
*kintone Design Systemチームについて：ユーザー体験を最高にするkintone Design Systemsをつくってます - Cybozu Inside Out | サイボウズエンジニアのブログ
きっかけ
そこからより多くの、チーム間でばらつきのない観点でテストをするようになったのは、kDSチームの取り組みがあったからでした。kDSチームは昨年秋に、kintoneのアクセシビリティ品質を向上させるため、外部の評価機関へkintone全体のアクセシビリティテストを依頼しました。そのテスト結果では、kintoneでどの問題が頻出しているかが定量的に示されていました。
その課題については、kDSチームから各チームのQAへも共有されました。そして、「kDSチームのメンバーのみで各開発チームのアクセシビリティテストを全て担当するのは難しい」、「頻出する問題に着目した一律の観点で、チームごとに差が無く問題を検出できるようにしたい」、「各チームで試験を行うことで、アクセシビリティに興味関心のあるメンバーを社内に増やしたい」などの理由から、以降の開発時に、該当の観点について開発チーム内でテストをしてほしいと依頼されました。
担当することが決まってから
その後、各開発チームのQAと、kDSチームのメンバーが集まって、実際にテストをするための準備が行われました。具体的には、kDSチームから新しいテスト観点についての説明、各観点に対するテストツールや手順の説明を受け、みんなでそれらの文書化をしました。
テストする観点
このときに定めた観点は以下の5つです。実施の際に特別なツールを使う場合は一緒に記載しています。
- キーボードのみで、マウスと同等に操作ができるか
- スクリーンリーダーで、表示されているテキストと非テキストコンテンツ（アイコンやテキストエリア）の役割がすべて読み上げられるか
- ツール：WindowsはNVDA、Macは標準搭載のVoice Over
- ブラウザのズーム倍率やフォントサイズを変えた状態で閲覧・操作できるか
- モノクロ表示でもカラーと同様に情報が伝わるか
- 自動チェックツールで深刻度の高い問題が検出されないか
- ツール：axe DevTools
また、この観点や手順については、外部評価機関の指摘はもちろん、Web Content Accessibility Guidelines (WCAG) や、freee株式会社のfreeeアクセシビリティー・ガイドラインも参考にしています。
*参考リンク：
NVDA日本語版 ダウンロードと説明
axe DevTools - Web Accessibility Testing - Chrome Web Store
Web Content Accessibility Guidelines (WCAG) 2.2 (日本語訳)
freeeアクセシビリティー・ガイドライン — freeeアクセシビリティー・ガイドライン Ver. 202409.0-RELEASE+5.1.0
実際にやってみて難しかったところ
スクリーンリーダーの使い方
一番印象に残っているのは、スクリーンリーダーでの試験です。私はアクセシビリティテストをやるために初めてスクリーンリーダーを使ったため、使い方に慣れておらず、戸惑うことが多かったです。
*スクリーンリーダーは、音声や点字で画面に表示されている情報を操作ユーザーに伝えてくれるソフトウェアです。今回のテストでは、音声読み上げ機能を使って読み上げ内容の確認を行いました。
私にとっては、絶え間なく流れる説明音声に慣れるところが最初の難関でした。ソフトの立ち上げ時から音の洪水が始まり、何を読み上げているのかわからないまま意識がその音に集中してしまい、いつもやっている簡単なPC操作もぎこちなくなる始末でした。少し経って慣れてくると、「マウスポインターを動かすから絶えず読み上げが発生するのだ」と気付き、できるだけキーボード操作にするというコツを掴みました。（そんな小さなことをコツだなんて、と思われるかもしれませんが、急に一方的な機械音声を浴びると人は結構焦ります。NVDAやVoiceOverは無料で使えるので、未体験の方はぜひ使ってみてください！）
また、フルリモートのため不具合はいつも文章やスクリーンショットで共有しているのですが、NVDAで不具合を見つけた時の共有方法には悩みました。
最初の数回は聞こえた通りに自力で文字起こしをして、内容をエンジニアに共有していましたが、すぐにその非効率なやり方に辛くなりました。加えて、VoiceOverではデフォルトでテキスト表示機能がされていたため、NVDAにも類似機能がついているのでは？と思い調べてみました。するとNVDAにも「スピーチビューアー」という、読み上げた内容を同時にテキスト表示してくれる機能があることがわかりました！以降はそこからコピペして、効率的に不具合の報告ができるようになりました。めでたしめでたし。
*ちなみにこの機能について、freee株式会社のガイドラインには「最低限知っておきたいこと」として記載があります。資料にはきちんと最後まで目を通すことも大切ですね。
「モノクロ表示で情報が伝わるか」の判断
他には、「モノクロ表示でもカラーと同様に情報が伝わるか」という観点にも難しさがありました。自分が既にカラー表示で見たことがある、つまり役割を知っているパーツが、モノクロ表示でも「その役割を持っているとわかるかどうか」を判断しないといけないのです。
これにはかなり頭を悩ませましたが、kDSチームにアドバイスを仰いだところ、「色以外の手がかり（配置、意匠、文言など）から役割が一目でわかるか」「他社のアプリで同じような場所にあるパーツと同じ役割になっているか」という判断基準を教えてもらい、それからは比較的楽に判断ができるようになりました。
まとめ
このように、アクセシビリティテストのやり始めは、慣れが必要な箇所も多く大変です。しかし、次はこのブログを読んでくれた方が挑戦して、新しい気づきを発信、またそれを読んだ方が……と繋がっていくと嬉しいなと思っています。そんな風に、他のテストと同様、知識やコツがたくさん蓄積され、よりよいテストのやり方が発見されたり、近い将来に世の中のすべての製品でアクセシビリティテストをやるのが当たり前になったりすると良いなと思います。
