アクセシビリティについての出版界への要請と対策
慶應義塾大学特任教授(Advanced Publishing Laboratory) / JEPA CTO
村田 真

自己紹介
• XMLを制定したW3C XML WGメンバー• OOXMLのISO/IECにおける委員長• XMLスキーマ言語RELAX NGの共同策定者• EPUB 3制定時の国際化リーダ• EPUB 3.2の共同提案者• APLのアクセシビリティWGリーダ• 詳しくはWikipediaの記事を参照

ストーリー

国内外の状況

出版社への要請

出版社は疲弊する？

救い国内外の状況: 条約と法律• 障害者権利条約（2006）• マラケシュ条約（2013）

国連

立法 ヨーロッパ • 欧州アクセシビリティ法(2019)

アメリカ
日本

• 障害を持つアメリカ人法(1990)• リハビリテーション法(1973)• 読書バリアフリー法(2019)

視覚障害者等の読書環境の整備の推進に係る関係者協議会(文部科学省及び厚生労働省)

読めなくて困っている人がいる• 本が読めない・読み難い状
況とその原因(APL)出版社への要請:
押し寄せるさまざまの難題• フルテキストを提供してほしい• DRMをはずしてほしい• スクリーンリーダで読み上げられるようにしてほしい• 点字で• 大活字本で• 録音して…

出版社は疲弊する?
• 特殊解を繰り返すと作業コストが膨大になる• 権利を守りたい救い• ボーンアクセシブルの思想: EPUBで最初からアクセシブルに作る• そもそもEPUBは普通の本をアクセシブルにするために作られた• DAISY（アクセシブルな情報システム）
コンソーシアムがEPUB制定に参加した• 特殊解はできるだけ避ける

リスク？オーバーヘッド？

リスクではなくチャンスと思え日本でも、高齢者が電子書籍を読んでいる

EPUBをどう使うかが問題
種類

EPUBの種類

アクセシビリ 対策
ティの有無

文芸書

リフローEPUB

だいたいあり 改善すべき点は多いが分かっている複雑なレイアウトをもつ実用書
や雑誌

画像固定レイアウト ない
EPUB?

マンガ

画像固定レイアウト ないEPUB?

ナビゲーション

リフロー
EPUB作成において改善すべき点

文書における目次

自動分かち書き
外字を避ける

可能なコンテンツ

問題の回避

作成

ルビのアクセシビ

画像への説明リティ

テキストの付与どうアクセシブルなのかを書誌情報で明示する

EPUB以外の対策:
書誌情報利点• 利用者にとって探しやすくなる• 利用者が読めないものを売買せずに済む• どこまでアクセシブルなのか出版社が意識するようになる

EPUB Accessibility(ISO/IEC規格)の書誌情報についての具体的な作業項目

JIS化

ONIXメタデータのアクセシビリティ
対応機能の整備

アクセシビリティ
検証ツール(SMARTとACE)の検討• ルビのメタデータ• 分かち書きのメタデータ

• 書誌情報と出版物のアクセシビリティ要件を規定する
• 経緯

EPUB
Accessibility
仕様• IDPFで作られた(Recommended Specification)• W3CにはMember Submissionとして提出されただけ(3.2から参照はされている）• ISO/IECで国際規格化中（なおEPUB 3.0.1は2020年そうそうにISO/IEC国際規格として出版予定）• JIS化？
• EPUBの特定のバージョンに依存しない

商用EPUBリーダのアクセシビリティは改善すべき点が大きい

EPUB以外の対策:
電子書籍リーダや電子書店

電子書店も同様

DRMによってアクセシブルなEPUBリーダを排除しない
スクリーンリーダにテキストを渡すことを許容できないか自動分かち書き(CSS)

普通の表示

読字障害向けの表示

ルビの表示(1)• 表示形1: まぜ書き

• 表示形2: すべて漢字• 表示形3: すべて平仮名ルビの表示(2)• 表示形4: まぜ書きにルビ• 表示形5: すべて漢字でパラルビ• 表示形6: すべて漢字に総ルビ

ルビの表示(3)• 表示形7: 色のついたルビ• 表示形8: 弱視向けのルビ

盲人は、スクロールバーではなく、ナビゲー

目次問題: アクセシビリティにとっては致命的ション文書に頼って文書を拾い読みする。

既存のものは仕方がないが今後はどうする？
• 目次とナビゲーション文書を別に作る？
• ナビゲーション文書を拡張して、表示のときの出現順段落序と、ナビゲーション順序を別に指定できるようにす段落る？

章
本章

段落

• EPUBリーダでの対処方法を標準化する？

出版社のみなさん、アクセシビリティへの取り組みを一緒に検討しましょう

備えあれば憂いなし2025年から欧州アクセシビリティ法により欧州で発行が義務付けられる電子書籍のアクセシビリティの要件(kzakza)

読書バリアフリー法について（厚生労働省）

参考資料

視覚障害者等の読書環境の整備の推進に係る関係者協議会（文部科学省）本が読めない・読み難い状況とその原因(APL)WebとEPUBの組版からフォントへの要請自己紹介（続き）
副会長（一社）文字情報技術促進協議会
フォント関連仕様調
情報処理学会規格調
査会SC34専門委員会
委員長

査部会部会長理由1: EPUBリーダの実装がCSS

Writing Modes及びUAX#50と合っ

縦書きのときの文字横転はUAX#50の通りに動かないのはなぜ？ていないから（実装を直せばよい）

理由2: Adobe-Japan1フォントは、CSS Writing Modes及びUAX#50と合っていないから

ブラウザで

Wordで• 縦書きのとき、規格表のコードチャート通りに表示しようとしても、CSSはvertというOpenTypeの機能を必ず呼び出す。

• AJ1では、Double Vertical Lineは必ず=になるようにvertが設定されている（MS明朝
では設定されていない）。

DoubleVerticalLineの挙動• 横転（sideways)を指定するともちろん横倒しになり、正立(upright)を指定してもvertのせいで期待通りにならない。

• AJ1では、Wavy Dashにはvertが設定されていない（MS明朝では設定されている）。

Wavy Dashの挙動• したがって、この文字を(UAX#50のデフォルトに従って）正立(upright)で表示さると、期待通りにならない。横転（sideways)を指定すれば期待通りになるが面倒。

UAX#50ではvertがあることを前提としているがAJ1でvertがないもの

Unicode文字

U+3030〰

U+ff01

CID(AJ17)

UniJISX02132004UTF32-H

JIS

12218

N！

642

U+ff1b；U+ff1f？

vert

UAX#50

SVO

X0213

Tr

Tr

N

X0213

Tu

Tu

640

N

X0213

Tr

Tr

641

N

X0213

Tu

U

UAX#50ではvertがないことを前提としているがAJ1ではvertがあるもの

Unicode文
字

CID(AJ17 )UniJISX02132004UTF32-H

JIS

U+2016

‖666

N

X0213

U+2702✂12176

N

vert

UAX#50

SVO

7895

U

U

12178

U

U

他にも疑わしい文字はいくつか• UAX#50でRだが、AJ1でvertがあるもの
Unicode文字

CID(AJ1-7)

UniJISX02132004-UTF32-H

JIS

vert

UAX#50

SVO

U+00b0°

707 N

X0213

8269 RU

U+2010‐662 N

X0213

7893 RR

U+2015―661 N

X0213

7892 RR

U+2025

‥

669 N

X0213

7898 RR

U+2026

…

668 N

X0213

7897 RR

U+2032

′

708 N

X0213

8273 RU

U+2033″

709 N

X0213

8283 RU

U+2190←737 N

X0213

738 R

U

U+2191↑738 N

X0213

736 R

U

U+2192

→

736 N

X0213

739 R

U

U+2193↓739 N

X0213

737 R

U

U+21c4⇄8310 N

X0213

8311 RU

U+21e6⇦8013 N

X0213

8012 RU

U+21e7⇧8012 N

X0213

8014 RU

U+21e8⇨8014 N

X0213

8011 RU

U+21e9⇩8011 N

X0213

8013 RU

U+2500─

7479 N

X0213

7481 RR

U+2501━7480 N

X0213

7482 RR

原因の一つ:UAX#50とAdobe-Japan1のvert設定とが不整合• AJ1フォントを直せば期待通りに動くが、既存の文書に影響が出るかもしれない。
• 文字情報技術促進協議会で対策を検討中。

国際規格OpenTypeを担当するJoint WorkingGroupの新設• OpenTypeはSC29(画像と音声）で担当してきた。 SC29は文書処理に興味を持たない。
• 国内SC29専門委員会はこの件にまったく関与しない。
• SC34(文書処理）とのJoint Working Groupで担当するように調整中。

これから必要な協力体制• 出版社• フォントベンダー• EPUBリーダ開発会社• 文字情報技術推進協議会• Font JWG• APL