アクセシビリティ Advent Calendar 2021 15日目の記事です。

今回は、アクセシビリティ検証目的のユーザー検証について書こうと思います。

アクセシビリティ検証目的に限らず、 ウェブサイトについて、ユーザーに実際に触ってもらって検証して課題を洗い出すことはよくされています。ウェブサイトのターゲットとして想定するユーザーに実際に触ってもらい、つまづいたり、使い辛かったり、あるいは全く利用できなかい箇所があった場合に原因を特定し、それを技術的要件に落とし込むという流れになります。ユーザーは技術者ではないので、ウェブサイトに用いられるウェブ技術に詳しいケースは多くありません。どこで躓いたのか、どうして自分が使えなかったのかを説明できても、原因まで説明することはなかなか難しいケースが多いと思います。それでも、コンテンツ×ブラウザの組み合わせで検証を行う場合は、開発者側も自身が普段からウェブをこの組み合わせで利用するので、ユーザーのつまづきを開発者側が確認することで、原因の特定から技術的要件に落とし込むところまで、ある程度はできるのだろうと思います。

しかし、アクセシビリティ検証目的でユーザー検証をする場合は、障害当事者であるユーザーが用いる支援技術を用いて検証するため、コンテンツ×ブラウザ×支援技術のアウトプットを検証することになります。この場合も、ユーザー側にどこで躓いたか、どうして使えなかった等の説明を技術的な側面から説明を求めることが難しいのは同様ですが、ユーザーが利用できない場面に立ち会った開発者側は、ウェブサイトに用いられたウェブ技術には詳しくても、支援技術の仕様までを十分に理解していない場合、問題の所在がコンテンツ（ウェブサイト）側にあるのか、支援技術の仕様によるものなのか、原因の仕分けがそもそも難しいため、技術的な要件まで落とし込むことが難しいことがあるのかなと思うことがあります。ユーザー側も自身が使用する支援技術を熟知している方もまれにいると思いますが、多くの場合は支援技術の機能の基本的な部分しか使いこなせず、支援技術の仕様を理解して説明できるケースは多くないと思います。支援技術が要素に加わる分、ユーザー側の「使えない」「困った」を技術的要件に「翻訳」することが難しい。

ウェブ技術と支援技術の仕様を熟知し、ユーザー側の「使えない」「困った」を技術的要件に「翻訳」できる者がユーザーの検証に立ち会い、障害当事者であるユーザーと開発者側の間を繋ぐ役割を果たせるとよいのかもしれません。しかし、一言で「支援技術」といっても、いろいろな技術があるので、多数ある支援技術の仕様を全て熟知することも簡単ではなく、支援技術の開発会社に問い合わせて仕様を確認するという方法と組み合わせる必要があるのかな、とかつらつら考えている今日このごろです。