カテゴリー: アクセシビリティ

JIS X 23761:2022（EPUBアクセシビリティ）が制定

kzakza

EPUBのアクセシビリティ要件をまとめたJIS X 23761:2022がISO/IEC 23761:2021に対応する規格として8月22日に制定されました。

JIS X 23761:2022は、 上のJSAサイトで購入できるほか、閲覧のみであれば、日本産業標準調査会（JISC）で可能です（なぜ日本規格協会のHPでは部分的にしか見られないのか・・）。

JIS X 23761は、2017年に策定されたIDPFのEPUB Accessibility 1.0 に由来しています。このEPUB Accessibility 1.0がベースとなり、国際規格としてISO/IEC 23761:2021が制定され、それが今回JIS化されたという経緯があります。このEPUB Accessibility 1.0が、

このEPUBが誰にとってアクセシブルなのか（誰にとってアクセシブルではないのか）をメタデータとして情報を提供して、ユーザーが実際に利用する前にはっきりわかるようにせよ

というスタンスをとり、アクセシビリティメタデータの提供、特にアクセスモードの提供を必須としたことは、当時から深く同意できることだったので、機会があれば触れて紹介していました。そのEPUB Accessibilityが今回、JIS化まで至ったことは感慨深いです。

他でもすでに紹介もされていますが、JIS X 23761の主な内容は以下のとおりです。

  1. だれにとってアクセシブルなのか、そして、どのようなアクセシビリティの機能を有するのかをメタデータとして提供することを必須とすること。
  2. EPUB出版物がアクセシブルであることの要件
    • ページナビゲーション、メディアオーバーレイズなどのEPUB特有の部分について、要件を制定。それ以外のウェブコンテンツに共通する大部分はWCAG2.0(JIS X 8341-3) に則るとしている（WCAG 2.0レベルA（JIS X 8341-3）が必須、WCAG 2.0レベルAA（JIS X 8341-3）が推奨）　
  3. 規格本体には含まれないが、附属書として、日本語固有の事情（ルビ、わかち書き、読み上げの問題）が整理されている。

対応するISO/IEC 23761:2021に同等性において、一致する（identical）規格であるため、JIS X 23761に対応することで、ISO/IEC 23761:2021にも対応することにもなります。

JIS X 23761本体は抽象的な要件制定にとどめていますので、具体的な実装方法は関連文書に位置付けられているW3Cの達成方法集”EPUB Accessibility Techniques”を参照する必要があります。

ISO規格が元になっているため、JISはISO制定当時のTechniques 1.0を参照するように促していますが、附属書で若干言及もされているTechniques 1.1を参照する方が今となってはよいかもしれません。

今後の課題は、いよいよJIS X 23761の普及です。以下、私見ですが・・

JIS X 23761は、EPUB Accessibility Techniquesを参照する必要がある上、アクセシビリティの大部分をWCAG 2.0に委ねているため、WCAG 2.0とその関連文書も参照する必要もあり、参照しなければならない文書が多岐にわたります。例えば、WACGのレベルAへの準拠が必須ということから、画像に対して代替テキストの提供が求められるということを理解する必要があります。制作されるEPUBのほとんどが内製ではなく、外注によって制作されていると思いますが、（おそらくWeb技術などにあまり精通していない方が多いであろう）外注する側の出版社の担当者が、どのように仕様にかいて制作会社に発注すれば、JIS X 23761に対応したEPUBができるのかは、整理が必要かもしれません。

JIS X 23761は、EPUBというコンテンツを対象とした規格ですが、出版社がこの仕様に則ってEPUBというコンテンツをよりアクセシブルするだけは十分ではありません。JIS X 23761の「9.　配信」でも言及されていますが、そのEPUBとユーザーの間を繋ぐ書店が、アクセシビリティメタデータに対応し、ユーザーが自分にとって使い易いコンテンツを容易に発見できるようしていくこと、そして、支援技術を阻害しない形でデジタル著作権管理を適用させるなどの注意が払われることで、初めてJIS X 23761が活かせるのだと思います。

課題をいくつか書いてしまいましたが、JISの制定まで至ったからこそ、次の課題に臨めるようになりました。大きな一歩前進だと思います（お疲れ様でした！）。今後のJIS X 23761の普及でアクセシブルな読書環境が大きく拡大することを祈ります。

関連エントリ

アクセシビリティ検証目的のウェブサイトのユーザー検証について

kzakza

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

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

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

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

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

BookshareのAlexaスキルのベータ版が公開

kzakza

おそらく2021年1月ごろだと思いますが、BookshareがアマゾンのスマートスピーカーAlexaのアプリ（Alexaスキル）のベータ版を公開しています。正式版の公開は2021年秋ごろを予定しているとのこと。

　以前からBookshareのアレクサ対応については、ユーザーから要望も挙がっていてたようで、対応を検討しているような回答(“Alexa capabilities are coming very soon”)を2018年にはしていたそうてす。
　そこから、3年は経過していますが、Booshareの既存のAPI ver1.0では、認証系で必要らしいOAuth 2.0への対応ができていなかったことが対応に時間を要した原因でしょうか。以前から公開されていたAPI ver2.0のベータ版では、OAuth2.0への対応も組み込まれていたので、ver2.0で対応するのだろうと思っていましたが、OAuth2.0の部分だけ、どうやら先行してver1.0に組み込んで正式リリースしたみたいです（たぶん）。

関連エントリ