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

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

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

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

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

司書資格の取得を目指して10月から某大学の通信学部で司書コースを受講することになりました。

今の図書館に勤務して相当の期間が経っていますが、この歳になってようやくその気に（いつか取るかなと思っていたら）。いいんです。

長く勤務していると、自分が担当している業務に関係する分野は実務レベルでは詳しくなったりしますが、理論的なところで、体系的な知識にかけていたり、関心の濃淡でほとんど触れない分野もあったりと、「図書館」というものに対して、関心と理解にどうもムラがある、また、実務から離れてしまうと、そこで得た知識も雲散霧消してしまうだろうと感じてもいたので、どこかで一気に平たく学び直す必要はあるだろうと感じていたのでした。

特に書誌・メタデータのところはだましだまし、必要に応じて文献を読むという感じで済ませてしまっていたので（整理部門にいたことはありましたが、自分の図書館の中では使う目録規則関係も含めて少し特殊なところにいたと思う）、情報資源組織論はじっくり学びなおしたいと思っていました。特に日本目録規則の2018 年版を読んでみて「よくわかんねー」となったのが大きい。「よくわかんねー」はつらい。

「図書館に勤務しているけど、「司書」でないんです」的な説明しなければならないこともあるのですが、そういう分かりづらい説明を特に図書館関係者以外の人に対してすることが思いの外煩わしいことなので、それの解消も些末ながら１つ動機でしょうか。

1年でなんとか必要な単位を取得できるようにがんばります。