帰ってくるHTML Ruby（rb/rtc）要素

fantasaiのツイートをたまたま見かけて知ったわけだけど、ここに来てHTML/CSS Ruby方面が一気に加速していると。

CSS Rubyについては、2020年になって6年ぶりにドラフトが更新され、この3月にも更新がされた。CSSでは何がどうなった、というのはここでは触れない。Change logを追ってもらえればと。

で、HTMLはというと、CSS Rubyのドラフト更新と時を同じくして、Restore the rb and rtc elements and update ruby content model accordingly - whatwg/html#6478のPRが出ている。このPRによるビルドのコピーが読みやすいかなと。

PRの骨子としては、古いW3C HTML 5.1をインポートしつつ、本文と例をガラッと変えてセマンティクスをより良く説明するものにした、とのこと。まだ精読はしていないものの、確かにHTML5で見かけなかったものが見えている気がする。いつにマージされるかはわかんないけれども、めちゃくちゃ遠くはないんじゃないか、というのが個人的な展望。

で、ここまでは前振りというか、上記はまあどうとでもなると思っているので脇に置いて、じゃあWAI-ARIA、HTML-AAMはどうなるのよというのが自分の一番の関心事ではあり。ruby周りに関しては、HTML-AAM（ARIA in HTMLでもよい）を読んでもらえばわかるとおり、今のところデフォルトのロールはない。

w3c/aria#74では、

We don't have consensus on rp , rt and ruby

More details as to what these could map to would be helpful.

という具合に（2018年時点だけれども）、ARIA WGでのコンセンサスが取れていない。

Dupeなissueとしてw3c/aria#488があって、これは[Role Parity] HTML 5.1 Rubyというまさしくそれなissueがあるものの、w3c/aria#529とDupeでは？という話が持ち上がり、#529はaudio/video要素の話になっているんだけども、いやいやそうじゃないでしょう…。

とまあこんな調子なので果たしてARIA 1.3で本当に何か入るのか？というのが怪しいのだけれども、アクセシビリティの観点からはWCAG 2.0 Understanding SC 3.1.6 Pronunciation（日本語訳：達成基準 3.1.6 を理解する）にrubyはクリティカルに効いてくるものなので、WAI-ARIAとしていい感じにしておきたいというのはあるよねと。

ちなみに現時点でのrtの実装は、Firefox+NVDAで読んでくれるけども、Chrome+NVDAでは読んでくれない、といったところ。次の例なんかはルビを読んでくれるかどうかがわかりやすいと思う。

東南たつみの方角

<!-- 現在のHTML Standardの例を改変 -->
<ruby>東南<rt>たつみ</rt></ruby>の方角

WAI-ARIAの観点からはマッピングされたroleがないと始まらないわけで、その上で必要なaria-*プロパティを与えるのが筋になってくるかなと。プロパティについては例えば日本語に限って言えばrtやrtcがリテラルに「読み」そのものなのか、あるいは「説明」なのか「異なる読み」なのか…みたいなところを分類して、適切なセマンティクスを与えられるようにする…というところからかしら。

なんか名詞があるとして、例えばこんな感じで？（現時点でそんなrole値とかaria-*属性はなく、あくまでブレストレベルのものです。試しに書いてみたものの、もしかして熟語ルビなのかモノルビなのかなどのセマンティクスを与える方が先だったりして。）

<!-- PRのHTMLの例から -->
<ruby role="ruby">
  <rb role="rubybase">旧<rb role="rubybase">金<rb role="rubybase">山
  <rt role="rubytext">jiù<rt role="rubytext">jīn<rt role="rubytext">shān
  <rtc role="rubytextcontainer" aria-phoneme="translate" lang="en">San Francisco
</ruby>

<!-- 支援技術は文脈でわかるんだろうか -->
<ruby role="ruby">
  <rb role="rubybase">放出</rb>
  <rtc role="rubytextcontainer" aria-phoneme="literal" lang="ja-Hira">はなてん</rtc>
</ruby>

<!-- 現行HTML改 -->
<ruby role="ruby">
  <rb role="rubybase">境界面</rb>
  <rtc role="rubytextcontainer" aria-phoneme="description" lang="ja-Kata">インターフェース</rtc>
</ruby>

…いちいちaria-*プロパティとしていちいち属性値を当てていくの、文章の一部でちょこっとならいいけど、大量になるとオーサリングが面倒なことになるのはもはや宿命か。

話は変わって、個人的にはrtc要素で夢が広がっていくのでは？と思ってたり。前述したrtc要素の例（そのもの）をもう一度書くと、

<ruby>
  <rb>旧<rb>金<rb>山
  <rt>jiù<rt>jīn<rt>shān
  <rtc>San Francisco
</ruby>

という具合に、rtcには別の言語を突っ込んでいるのだけれども、これが発音情報でもいいよね…？という発想はどうだろうと。

手の込んだ発音情報を盛るのであれば、Speech Synthesis Markup Language (SSML) Version 1.1（日本語訳：音声合成マークアップ言語（SSML）バージョン1.1）という合成音声のためのマークアップ言語があり、これをHTMLで借用できないかと。

3.1.10 phoneme要素あたりがたぶん求めているもの最も近しく、そのまま埋め込むのにカスタム要素として扱ってしまえば、構文としては何の問題もない。

<ruby>
  <rb>トマト</rb>
  <rtc>
    <ssml-phoneme alphabet="ipa" ph="t&#x259;mei&#x325;&#x27E;ou&#x325;">tomato</phoneme>
  </rtc>
</ruby>

…とここまで書いて、そういえばどこかで似たような話を見かけたなと思ったら、Two First Public Working Drafts for Pronunciationとかあったよね。あと、総務省の電子書籍アクセシビリティガイドラインが斜め上っぽいとかいうのも大昔に書いてたよね…？さっぱり忘れてた。

まあこれに関してはもっと込み入った実装がないとどうマークアップしようがどうしようもないけども。NVDA方面では@24motzさんのSSMLがまとまっているか。

ブラウザーネイティブだと、QiitaのWebページでブラウザの音声合成機能を使おう - Web Speech API Speech Synthesisとかが詳しいか。WICG/speech-api#37とかがそう？（どっちにせよなんもわからん）。

…まあ、SSML方面とかはどうなるのかまるでわかんないですけども、SSMLよりかはARIAのマッピングむずかしくなさそうかなとか。

とりとめもないんですけどこのあたりで。

(メモ)障害を理由とする差別の解消の推進に関する法律の一部を改正する法律案

第204回 通常国会 - 内閣府

障害を理由とする差別の解消の推進に関する法律の一部を改正する法律案の概要

経緯

障害を理由とする差別の解消の推進に関する法律（平成25年法律第65号。以下「障害者差別解消法」という。）附則第７条においては、施行（平成28年４月）後３年を経過した場合に事業者による合理的配慮の在り方その他の施行状況について所要の見直しを行う旨規定されている。このため、障害者政策委員会において議論が行われ、令和２年６月に意見書が取りまとめられている。この意見書等を踏まえ、以下の措置を講ずる。

概要

２．事業者による社会的障壁の除去の実施に係る必要かつ合理的な配慮の提供の義務化

事業者による社会的障壁（障害がある者にとって日常生活又は社会生活を営む上で障壁となるような社会における事物、制度、慣行、観念その他一切のもの）の除去の実施に係る必要かつ合理的な配慮の提供について、現行の努力義務から義務へと改める。

法律案及び理由

第八条第二項中「するように努めなければ」を「しなければ」に改める。

参考（現行法）：平成二十五年法律第六十五号 障害を理由とする差別の解消の推進に関する法律

（事業者における障害を理由とする差別の禁止）

第八条　事業者は、その事業を行うに当たり、障害を理由として障害者でない者と不当な差別的取扱いをすることにより、障害者の権利利益を侵害してはならない。

２　事業者は、その事業を行うに当たり、障害者から現に社会的障壁の除去を必要としている旨の意思の表明があった場合において、その実施に伴う負担が過重でないときは、障害者の権利利益を侵害することとならないよう、当該障害者の性別、年齢及び障害の状態に応じて、社会的障壁の除去の実施について必要かつ合理的な配慮をするように努めなければならない。

附則 この法律は、公布の日から起算して三年を超えない範囲内において政令で定める日から施行する。

ピンポイントでしか書いてないけれども、改正案としてはこれを含めて5項目ある（この記事はあくまでメモでかつ抜粋なので省略している）

関連：第53回 障害者政策委員会

令和2年（2020年）12月14日（月）開催。

デジタル庁関連の質疑応答

○竹下委員　日視連の竹下です。

まず、１点目が、内閣府に質問です。

菅首相は、デジタル庁をつくり、デジタル化を促進するとおっしゃっています。

そうであれば、障害者施策の中で、このデジタル化がどういう形で位置付けられるのか。

例えば基本計画の中で、アクセシビリティを含めたデジタル化を伴う障害者の位置付けというもの、あるいはデジタル庁ができたときに、例えばで言いますと、ユニバーサルデザイン化あるいは障害者対策というものは想定されているかどうかについて教えてください。これが１点目です。

（以下略）


○衣笠参事官　まず、竹下委員から、デジタル化の推進の中で障害者がどう位置付けられているかということなのですけれど、今、政府全体での進め方や内容につきましては、別途、内閣官房等を中心に検討中ということでありますので、そちらに情報共有させていただき、必要に応じて連携して対応していきたいと考えております。

（以下略）

さすがに何も考えてない…ということはない模様。今後の議論を見守りたいところ。

合理的配慮に関する議論

〇関川専門委員　大阪府立大学の関川と申します。

（中略）

今回の差別解消法改正の意義ですけれども、合理的配慮提供の義務化は、改めて法の存在を社会に向けて周知し、差別的取扱い並びに合理的配慮について、それぞれの皆さん方が参画しながら社会規範として高めていくために、周知啓発する格好の機会、このチャンスを逃してはいけないと考えております。

来年度、仮に法改正が成立しましたならば、国・地方自治体は、施行に向けて、現行法の枠組みの中で積極的に準備を進めるべきだと思っています。

この委員会の審議を通じて、改正する、しないに関わらず、差別解消に向けて、国、自治体、事業者が取り組むべき課題というものは多数あると認識しています。

仮に法律改正３年後に施行するということであれば、それまでのプロセス、ロードマップを具体的に示すべきだと思います。そうしなければ多くの方から賛同いただけないのではないかと考えます。

それに関しまして、２点お願いしたいことがございます。

１点は、事業者側の御意見にもありましたとおり、合理的配慮の義務の存否、判断基準について、具体的にお示しをして周知啓発を図る必要があると思います。義務化に伴う不安とか困りごとを解消する努力を、この３年に向けたロードマップの中で具体的に位置付けて積極的に推進していくべきではないでしょうか。

ちなみに、合理的配慮の好事例を平成29年でまとめておりますが、バージョンアップが必要だと思います。ここでは障害種別に応じた合理的配慮についてまとめておりますが、事業者側の立場から、見やすいもの、必要な情報が得やすい内容に変えていく必要があると思います。

（以下略）


〇玉木委員

（中略）まず、２番目にある相談体制の拡充ということでいくと、今まで言っていたように、拡充というのは広げ過ぎるということではなくて、やはりきちんとワンストップで受け止めるということを前提に拡充、強化するという意味で使っていただいた方がいいかということ。

それから、実は今年、差別に遭いまして、差別の相談を西宮にしたのです。どういうことかというと、公立病院で、私は人間ドックを受けようとしたら、エレベーターがないからお断りと言われて、結局、その病院では「今後考えます」で終わってしまったのです。

それでいくと、３番目の相談に乗る人の人材の確保のところで、どこまで相談を受け止めて、協議、調整ができるか、あっせんができるかというぐらいの、かなりの力量が必要となってくるので、そこら辺は、ちょっと強く推していただきたいということが１つ。

（以下略）


〇平川委員　ありがとうございます。

以前に、合理的配慮という言葉について、委員長からも誤解を招くのではないかという話がございまして、そのとき玉木委員からも話し合いの場を義務化するという話もあったと思うのですが、先ほどの玉木委員のお話を聞くと、病院に行ったときに、車椅子の方はエレベーターがないから健康診断が受けられないという話がありましたが、病院側からすると、やはりそれも病院の理屈ではあるのかなと思いまして、その辺、このウェブの会議で時間がない中で申し訳ないですけれども、どんな形で解決するのか、いい例だと思いましたので、そういうものを含めて議論ができないかと。例えば、病院側として、どちらか相談するような場所がすぐ見つかればいいのですけれども、私は玉木委員が大好きなので、玉木委員に味方をしたくなるのですけれども、でも病院ではエレベーターを付けるのかという議論になってしまいますので、その辺、当たり前の常識というのはお互い多少違っている中で、どのような形でやっていくかということの具体化が見えない限りは、事業者側の不安というのは消えないのかなと思うので、その辺を事業者側の相談窓口も是非作っていただきたいと思います。


○石川委員長　ありがとうございました。

まず、平川委員からの問題提起に対しましてですけれども、先ほど関川専門委員からも御指摘があったように、この辺りのところを前もって完全に合理的配慮の範囲を明確化するというのは、恐らく原理的に不可能だけれども、考え方ですとか、おおよその相場感という言葉が適当かどうか分かりませんけれども、合理的配慮はこういったようなもののことを言うのであって、一方、こういうものは合理的配慮だとは言わないだろう。

つまり、網羅的なホワイトリストも、網羅的なブラックリストも出せないけれども、この辺はホワイトリスト、この辺はそうでないというリストという形で示すことは必要であるし、ある程度は可能なのではないかと思っています。

先ほどの玉木委員の事例について、今日議論するというのは時間的に無理なのですが、確かに良い例で、これを合理的配慮の不提供と見るか、あるいは、これはやむを得ないこととして、つまり環境整備がまだ整っていないということによって、やむを得なくそれは断っているのだとするのか、この辺りのところが、要するに合理的配慮をめぐっての１つの考え方を、建設的な対話を通してすり合わせて調整していくということが必要になってくると思いますので、そういったことも含めて、基本方針の中に、今ある程度の考え方のガイドラインになるようなことも入れていけると良いかなと思っています。

何が合理的配慮で何が合理的配慮ではないのか、ウェブサイトというところにフォーカスを当てて何か出てくるのかもしれないし、出てこないかもしれない（出てきてくれないと困る）。