はじめに

　2022年はユーザビリティやユーザエクスペリエンス（UX）の評価について再び考えることになった年でした。きっかけは生体データを評価に使えないかという話題からでした。現状の課題を解決する新たな評価方法を検討するうえでユーザビリティやUXのことを調査したり、意識したりすることが増えました。そんな中で「アクセシビリティ」という言葉も割と良く耳にしました。そこで今回はそのアクセシビリティの評価についてちょっと調べてみたいと思います。

ISO/IEC 25010の品質モデル

　アクセシビリティは以前から聞く言葉でしたし、最近より大事になってきているのかなぐらいの感覚でいました。また、ISO/IEC 25010の品質モデルにも確か含まれていたと記憶があり、久しぶりに眺めてみました。結果、やはり使用性（Usability）の副特性のひとつとしてアクセシビリティ（accessibility）がありました。そこでの定義としては以下になっています。

製品又はシステムが、明示された利用状況において、明示された目標を達成するために、幅広い範囲の心身特性及び能力の人々によって使用できる度合い。

　ニーズとしては以下のようです。

Webのページ上などで広報をする場合、その情報をできるだけ多くの人にまんべんなく伝えたい。

社会的な要請により、アクセシビリティの規格を満たしたい。

　確かに、社会的な要請という側面はニーズとして強くなっている気がします。

　品質測定量として以下が例として示されています。

視覚障害にしぼってアクセシビリティの測定を課題とした場合、測定する品質特徴の例として次のものがある。
Webサイト利用タスク準拠 Webアクセシビリティチェックリスト
a) 表示速度
b) 概要の理解
c) 完全なアクセス
d) 利用者による操作
e) 本文の読みやすさ
f) 適切な音声読み上げ
g) コンテンツの視認性

　何を確認するのかは、使用性にある他の副特性に比べて明確な印象です。品質モデルなので、どう確認するのかまでは紹介されていないというところでしょうか。

参考：つながる世界のソフトウェア品質ガイド p.172

ISTQB Usability Testingシラバス

　次にISTQBのUsability Testingシラバスを調べてみます。ここにもアクセシビリティについて書かれていました。このシラバスの中では評価のタイプ（種類）の一つとしてアクセシビリティを位置づけています。

Type of evaluation	Key objective
Usability evaluation	- Evaluate the direct interaction between users and the software product.
User experience evaluation	- Evaluate the services received prior to the use of the software product. - Evaluate the direct interaction between users and the software product. - Evaluate the services received after the use of the software product.
Accessibility evaluation	- Evaluate the direct interaction between users and the software product, focusing on understanding problems related to accessibility barriers, rather than general efficiency or satisfaction.

　確かに、ユーザビリティと評価の狙いが異なりますし、評価のやり方も評価に必要なスキルも異なってくるので、別の評価タイプとしておくのも良さそうな気がします。

その他、アクセシビリティテストで着目する点として以下を記載しています。

Use of a think aloud technique to understand the test participant’s thoughts and vocabulary during accessibility testing

Focus on understanding mistakes related to accessibility barriers, rather than on efficiency or satisfaction

Use tasks that concentrate on specific areas of concern for potential accessibility problems, rather than on general software product usage

　思考発話法(think aloud technique)を使うのは少し意外でした。なんとなく難しそうな印象です。

　その他、関連するアクセシビリティの規格、ガイドラインを考慮する必要があるということで以下を記載しています。

ISO 9241-171 – Guidance on software accessibility

The Web Content Accessibility Guidelines (WCAG)

　評価のプロセスとか参照する規格などは参考になります。アクセシビリティは、規格、ガイドラインに基づいて評価することが可能であるのが、ユーザビリティにおける主観評価とは異なる点なのかもしれません。

　　参考：ISTQB Usability Testingシラバス

規格やツール

　調べてみるとアクセシビリティに関する規格やツールはいろいろ見つかります。例えば、JISでも以下がありました。

JIS X 8341-3:2016 高齢者・障害者等配慮設計指針―情報通信における機器，ソフトウェア及びサービス―第３部：ウェブコンテンツ

JIS X 8341-7:2011 高齢者・障害者等配慮設計指針―情報通信における機器，ソフトウェア及びサービス―第７部：アクセシビリティ設定

　ツールについてはWebのアクセシビリティ評価ツールとして以下に纏まっていました。ちなみに、A11YでAccessibilityということみたいです。

　　Web Accessibility Evaluation Tools List

　日本だと以下のツールがあるようです。

　　WAIV
　　miChecker

ウェブアクセシビリティ導入ガイドブック

　アクセシビリティ初心者の私にとっては、先日デジタル庁がリリースしたウェブアクセシビリティ導入ガイドブックが分かりやすかったです。

　　参考：ウェブアクセシビリティ導入ガイドブック

　２章の「ウェブアクセシビリティの試験を行う」ではチェックツールの機械チェックに頼り切らないことが注意点として記載されていました。『ツールで機械的に確認できるのは達成基準の 2割から 3割程度にとどまります。』とあり、ユーザビリティの中でも自動化しやすいと考えていたアクセシビリティでもツール化するにはまだまだ課題はあるのだなと思いました。

　４章の「ウェブアクセシビリティの実践プロセス」では具体的な話もあり参考になります。ワイヤーフレームの段階でテストや洗い出しの検討をしておくことや、スクリーンリーダーの検証項目のこと等が記述されていました。機能的な側面としてスクリーンリーダーのテストはしたことがありましたが、以下のような点までは確認できていなかったので確かに必要だなと感じました。

全体の構造が、逐次読み上げ・操作をスクリーンリーダーで行った際に理解しやすいものになっているか

スクリーンリーダーで操作不能になる箇所の洗い出しと対応方針の確定

　６章の付録では、先ほどの規格、ガイドライン、チェックツールなども紹介されていました。試験実施ガイドラインというのもあるようです。

　　IS X 8341-3:2016 試験実施ガイドライン

おわりに

　アクセシビリティの評価についてちょっと調べてみました。アクセシビリティ評価における課題を把握し、それを解決するための手段を検討するには、まずはしっかりアクセシビリティを理解する必要があるので、引き続き学んでいこうと思います。アクセシビリティはより注目されてくると予想できますので。そう言えば、先日受験したUX検定基礎でもアクセシビリティについて何問か出題されていました。