以前のエントリで書いたように、2021年10月から某大学の通信学部で司書コースを受講していましたが、司書資格取得に必要な科目の単位をこの6月に全て取得し、司書コースを無事修了することができました（修了証が届くのはこれからですが）。

私が受講した通信制の大学では、レポートの提出から試験まで全ての工程をオンラインで行うことができたので、大変助かりました（スクリーニングが必要な科目は録画された動画の配信で受講）。オンラインで完結できなければ、修了できなかったと思います。

司書資格取得に必要な科目は、図書館法施行規則で規定されているとおりですが、全体的に図書館に関する業務を薄く広く学ぶという感じであったため、前のエントリで書いたとおり、「一気に平たく学び直す」という私の目的はとりあえず満たせたかなという気はします。10月から3月の間は読む本も図書館に関係するものになるべく集中させました(特にJLA図書館実践シリーズは結構読みました)。興味ベースや担当した業務ではこれまで接点のなかった領域についても、はるべきアンテナができたというか、情報や知識を放り込む箱のようなものが頭の中にある程度はできたと思います。特に学校図書館や地域資料について、今後もアンテナはっていこうという気になったのが、司書コースを受講した最も大きな成果かもしれません（地域資料は、司書コースでの学びに加えて、蛭田廣一さんのJLA図書館実践シリーズでの一連の著作を読んだことが特に大きかったかも）。

司書コースを受講した動機の1つに日本目録規則2018年版(NCR2018)を学ぶというのがありました。受講した司書コースの情報資源組織論では、日本目録規則1987年改訂3版(NCR1987)をベースにしたものだったので、その点は残念でしたが、各出版社が出版している情報資源組織論のテキストでは、すでにNCR2018に対応しているものを出していたので、樹村房のテキスト、JLAのテキストを購入して、並行してNCR2018も勉強しました。NCR1987とNCR2018の違いを比較しながら学んだことは、NCR2018の理解度を上げたことに繋がったと思うので、結果としてよかったように思います。

地元の公共図書館には、参考資料を借りたり、所蔵がない資料も他の図書館から取り寄せていただいたりと大変お世話になりました。司書コースを受講しつつ、利用者としてサービスを改めてじっくり観察したり、図書館年報を読んで、普段利用している地元の図書館がいろいろな分野でサービスを充実させていることがわかり、これも私にとっては大きな発見でした（遅いと言われそうですが）。

いずれにしても、当初の予定どおり、司書資格を予定通り1年で取ることができたのはよかったです。。現時点でその成果をどのように活かせるかわかりませんが、活かせるように精進したいと思います。現在、担当としている業務はNCR2018を前提としているものなので、NCR2018を読むリテラシーがついた点はさっそく活かせている（ような気はする）。

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

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

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

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

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