2021-12-01

やさにちウォッチのルビ(ruby - ふりがな)のスタイル (改訂版)

この記事はアクセシビリティ Advent Calendar 2021 別ウィンドウで開きますの第1日目の記事です。
この記事は PowerCMS X Advent Calendar 2021 別ウィンドウで開きますの第1日目の記事です。
この記事はやさしい日本語 Advent Calendar 2021 別ウィンドウで開きますの第10日目の記事です。

※ Advent Calendar用に新規記事の作成も考えましたが、ルビをフル活用したウェブコンテンツに関する実装ノウハウとして纏まっているほうが後の役に立ちそうだったので大幅に加筆して、改訂版としました。

「やさにちウォッチ」別ウィンドウで開きますは私たち(アルファサード株式会社) 別ウィンドウで開きますが運営する「やさしい日本語の情報をやさしい日本語で発信する」オウンドメディアです。すべての漢字にふりがな(ruby)を付けており、文章を分かち書きする機能も提供しています。

また、PowerCMS X / PowerCMSにはエディタにルビを振る機能を付けていて、Webサイトに自動でルビをつける Webサービス「伝えるウェブ別ウィンドウで開きます」を運営しています。そこで、やさにちウォッチのルビやデザインの実装はどうなっているのかを記事にまとめてみました。

※ 尚、画面下部 (ソースの末尾) のセレクタからこのページにルビを付けることができます。

「やさしい日本語」について初見の人はやさしい日本語 (言語) - Wikipedia 別ウィンドウで開きますなどを参考にしてみてください。

やさしい日本語（やさしいにほんご）とは、簡易な表現を用いる、文の構造を簡単にする、漢字にふりがなを振るなどして、子どもや日本語に不慣れな外国人にもわかりやすくした日本語である。

やさしい日本語 (言語) - Wikipedia 別ウィンドウで開きます

尚、ウェブアクセシビリティ・WCAG2.0(JIS X8341-3:2016) 別ウィンドウで開きますの文脈において、やさしい日本語とルビの提供については「ガイドライン 3.1 読みやすさ: テキストのコンテンツを読みやすく理解可能にすること」別ウィンドウで開きますと関連するものであると私は解釈しています。

3.1.5 読解レベル: 固有名詞や題名を取り除いた状態で、テキストが<前期中等教育レベルを超えた読解力を必要とする場合は、補足コンテンツ又は前期中等教育レベルを超えた読解力を必要としない版が利用できる。 (レベル AAA)

3.1.6 発音: 文脈において、発音が分からないと単語の意味が不明瞭になる場合、その単語の明確な発音を特定するメカニズムが利用できる。 (レベル AAA)

Web Content Accessibility Guidelines (WCAG) 2.0 (日本語訳) 別ウィンドウで開きます

今年(2021年)の10月に「ルビ」に関するいくつかのニュースが出ていました。

上記のウェビナーでも取り上げられていたいくつかの課題について、すべて現状で解決できるわけではありませんが、ある程度のことは現状でもフォントの選択やCSSの工夫によって解決できます(尚、この記事についてはEPUBではなく、Webの話です)。

課題と解決したい問題

フォントの選択 (12月1日追記)
親文字(rb要素)とルビ(rt要素)が近すぎるなどで読みにくい問題
ルビが小さすぎて読みにくい問題
行を折り返した時にルビが上の行と近すぎるとどちらに対するルビなのかがわかりにくい問題
スクリーンリーダーなどでの読み上げが不自然になる問題
flexを利用して横並びにしている要素のbaselineが揃わない問題 (12月1日追記)
リンクの下線が途中で切れる問題 (12月1日追記)
モノルビが良いかグループルビが良いか問題 (12月1日追記)
バッジやボタンの見た目が揃わない・不要な隙間ができる問題 (12月1日追記)
フォーカスがガタつく問題 (12月1日追記)
Amazon Polly 別ウィンドウで開きますのSSMLの subタグで読み上げが不自然になる問題 (12月1日追記)

フォントの選択 (12月1日追記)

やさしい日本語は、日本語に不慣れな外国人向け、と思われていますが、必ずしもそれだけではありません。

ろう(あ)者(聴覚障害者) : 参考リンク - ろうと手話 ――やさしい日本語がひらく未来 (筑摩選書) 別ウィンドウで開きます
ディスレクシア(読み書き困難) : 参考リンク - ディスレクシア入門---「読み書きのLD」の子どもたちを支援する別ウィンドウで開きます
知的障害者 : 参考リンク - ことばのバリアフリー――情報保障とコミュニケーションの障害学別ウィンドウで開きます
視覚障害者・弱視 : 参考リンク : 「ひらがな」で話す技術 ※ 別ウィンドウで開きます
中学生以下の子供 : 参考リンク - NEWS WEB EASY は外国人だけのもの? 別ウィンドウで開きます
そして、日本に住む外国人や、日本語を学ぶ外国人、外国人観光客

※ 参考リンクに挙げた書籍『「ひらがな」で話す技術』には障害者に関する話は出てきませんが、「音」で聞いてわかりやすい話し方、という点でスクリーンリーダーなどでWebサイトを「聴いている」人向けの文章の書き方の参考になると思います。
※ もし、それぞれの当事者の方で「やさにちウォッチ別ウィンドウで開きます」の情報が得にくい、見にくい、などありましたら、お気軽にご指摘・ご連絡いただければと思います。

さて、フォントの選択にあたって考えたのは ディスレクシア(読み書き困難) のユーザーのことです。参考リンクに挙げた「ディスクレシア入門」別ウィンドウで開きますでは、以下のようにあります。

音読・読解用のテキストのフォントは教科書体を使うことが多く、24ポイント程度の大きさで、表記は横書き、分かち書きにし、ふりがなを振ります。

第7章読み書きに難しさがある子供の事例と指導の実際 (2) 小学校高学年別ウィンドウで開きます

ユーザーが好きなフォントで閲覧できる、というのが最終的な正解になるわけですが、いずれにしてもフォントの選択は重要と考えました。特にディスレクシアの人や弱視の人にとってはやさしい日本語であるだけではだめで(一文・一記事を短くする、というのはいずれのケースにも有用ではありますが)、やさしい日本語＋フォントの選択、行間、ルビのレイアウトを含めたデザイン全般が読みやすさ・伝わりやすさにとって大切です。

UDフォントが良い、ということも最近では良く言われるようになりました。ただ、色々調べてみると、フォントのわかりやすさについては個々人で差異があるらしく、正解は1つではないということもわかります。

フォントはゴシック (sans-serif) としました。UDフォントも検討しましたが、以下の2つの理由から「Noto Sans JP 別ウィンドウで開きます」を選択しました。

1つめは、本文とルビの距離です。後述の通り最終的には CSSで調整していくことになるのですが、ご存知? の通りルビのCSSは現段階では一筋縄ではいかず、画像は「line-height: 2」、rtに対して「font-size: 70%」を指定したときの Firefoxでの表示です。Noto Sans JPのほうが「アキ」が広く読みやすくなっています(Safari、Chrome、Edgeなどでは行間指定だけでは駄目で、調整方法は後述します)。※12月2日追記 : Firefoxの場合、rt要素に対する margin-bottomが効きますので、それで調整可能です。

UD新ゴとNoto Sans JPのルビと本文の距離の比較

もう一点気になったのは、ひらがなの「さ」「ち」などの違いが Noto Sans JPのほうがわかりやすいと感じたからです(Noto Sans JPでは「さ」の画数が3、「ち」の画数が2、一方でUD新ゴでは共に画数が2で似通って見える)。英語圏(に限らないでしょうが)ではディスクレシアの人は「b」「d」などの見分けがつきにくい傾向がある、ということも言われています(まったくの余談ですが、俳優のトム・クルーズさんがディスレクシアであること別ウィンドウで開きますを公表しています)。

トム・クルーズ自身は、アルファベットの「b」と「d」の見分けがつかず、読み書きができなかったという。これを克服するまで、母親やアシスタントが台本を読んでそれを聞き、セリフを暗記して映画撮影にのぞんでいた。欧米では1960年代以降、この識字障害の認知が広まり、その出現率はなんと人口の1割程度ともいわれる。

トム・クルーズ、最大のミッションは「ディスレクシア（識字障害）」の克服だった? (2015年8月18日) - エキサイトニュース別ウィンドウで開きます

「さ」と「ち」だけに固執するわけではないのですが、サイトのタイトルが「やさにちウォッチ」ですので、否が応でも気になってしまいました。

UD新ゴでの「さ」と「ち」(両方とも画数が2) — UD新ゴでの「さ」と「ち」の比較
(正確には非対称であることがわかるが、
ともに画数が「2」で見分けにくく感じる)

Nato Sans JPでの「さ」と「ち」の比較(「さ」の画数が3、「ち」の画数が2) — Nato Sand JPでの「さ」と「ち」の比較
(違いがより明確)

繰り返しになりますが、読みやすいフォントは人によって違うため、これが正解、というものはありません。今後は「ふりがな」や「わかちがき」選択ボタンと同様に書体を選択できるようにする仕組みなどを検討しようと思います(行間調整なども可能にできれば良いのではないかとも考えています)。

※12月15日追記 : UDデジタル教科書体を切り替えて選択できすようにしました。

親文字(rb要素)とルビ(rt要素)が近すぎるなどで読みにくい問題

前項でも触れましたが、ブラウザのルビの実装で一番やっかいなのがこの問題です。基本的には、行間を開けることで適度な距離が空き、読みさすさが向上します。(12月1日追記) Firefoxでは rt要素のmargin-bottomが効きます。ただし、フォント(やブラウザ)によって結果が異なります。以下の例はすべて「Noto Sans JP」での実例です。 (追記ここまで)

ruby {
    line-height: 2.8em;
}
rt {
    margin-bottom: .33rem; 
}

ところが、Chromeなどのブラウザでは相変わらず近いままです。CSSで位置調整をしようとしてもブラウザによってCSSの適用結果が異なり、一部のブラウザでは位置調整のための指定をしても効いてくれません。Firefoxでは適度な距離が開くのですが、Chrome / Edge / Safariなどでは近いままです。

CSSのプロパティtransformを利用する

Chrome / Edge / Safariでは rt 要素に transformプロパティを指定することでルビの位置を変えることができます。ルビが小さすぎて読めない問題もあわせて解決するために、以下のようにしました。ただし、Chrome / Edgeと Safari では、距離の空き方が微妙に違います(Chrome / Edgeのほうが距離が近い)。

rt {
    transform: translateY(-.06rem);
    font-size: 70%;
}

ルビの色を変更する

「色」が情報のまとまりを識別する助けになるという人もいることがわかりました。そこで、rt要素の色を濃い赤色に変更することにしました。もっと思い切って色を変えればみやすさが向上されるというような人もあると思いますが、逆にコントラスト比が足りなくて色覚異常の人や弱視の人の読みやすさの妨げになってはいけないので、その落とし所が難しいところです。また、バッジやボタン、フッターの中では濃い色に対して明るい色を指定していますから、そこは文字色は白として差は付きません。

rt {
    color: #8d213d;
}
.badge rt {
    color: white !important;
}
.btn rt {
    color: white !important;
}
.foot-menu-item rt {
    color: white !important;
}

参考リンク : ディスレクシアとマルチメディアDAISY －当事者そして教育者の立場から別ウィンドウで開きます

私としては最初から熟語で表記されて、色を変えてふりがながあるとわかりやすいタイプです。つまり、色が一緒だと、最初に、素材と素地の見分けが苦手といいましたが、「害」は文字としてどこまでがまとまりなのか、わかりません。たけかんむりの新種かなとルビを見て思ったりするので、色が違うと、ここがルビ、ここが文字だとわかるのです。

ディスレクシアとマルチメディアDAISY －当事者そして教育者の立場から別ウィンドウで開きます

行を折り返した時にルビが上の行と近すぎるとどちらに対するルビなのかがわかりにくい問題

どういうことかというと、transformプロパティで距離を開けすぎると、行間が足りなければ上の行と被ってしまったり、被らないまでも上の行に極端に近くなって、いったいどちらのテキストに対するルビなのかがわかりにくくなってしまうのです。

この件についてやっかいなのは、iOSのSafari (どちらが正しいかは別として) などで、行間を開けたバランスと、ルビの距離のバランスが悪く、距離を開けすぎると上の行と近くなってしまい、その対策で行間を開けすぎると他のブラウザで行間が空きすぎてしまいます。

この問題に対しては(本当はやりたくなかったのですが)「transformプロパティはSafariにあわせて指定、Chrome / Edge はJavaScript (jQuery)で調整」としました。

var userAgent = window.navigator.userAgent;
if ( userAgent.indexOf('Chrome') != -1 ) {
  $('rt').css('transform', 'translateY(-.4rem)');
}

スクリーンリーダーなどでの読み上げが不自然になる問題

この問題については、このサイトの立ち上げ時から意識していて、画面の先頭付近に「ふりがな」「わかちがき」ボタンを付けておき、ON/OFFできるようにしています(Cookieをセットして状態を保てるようにしています)。JavaScriptで body にhide--furiganaクラスを追加して、display :none しているだけです。VoiceOverで意図した読み上げにされることを確認しました。とはいえ、あくまでも rt要素を隠しているだけなので、rt要素に異なる読みのふりがなを指定していても読み上げには反映されません。この件については、ブラウザやスクリーンリーダーの実装を待つことになりますが(VoiceOver + Chromeではrubyを無視して親文字を読み上げます)、この後に触れている Amazon Polly 別ウィンドウで開きますのSSMLなどをうまく活用すれば解決できるかもしれません。

ふりがなと分かち書きのON/OFFボタン

body.hide--furigana rt {
    display: none !important;
}
body.hide--furigana ruby {
   line-height: 1.5 !important;
}

※ ruby要素だけに line-height 指定をすると、ルビを含まない行の行間が不自然になるので、実際はルビが使われる部分を囲っているブロックに line-heightを設定しています。

最終的なルビのスタイルについては、サイトをぜひご覧ください。また、お気づきの点などがあればお気軽にご指摘・お問い合わせください別ウィンドウで開きます。(12月1日追記) Twitterで「ルビを動的に消した時に現在読んでいる箇所を見失う」という指摘をいただきました。この件は現時点で未解決です。(追記ここまで)

やさにちウォッチ - やさしい日本語のニュースをやさしい日本語で別ウィンドウで開きます

flexを利用して横並びにしている要素のbaselineが揃わない問題

(この画像はやさにちウォッチではなくPowerCMS Xの製品サイト) ルビを付けることによって、flaxで要素を横並びにしている部分のベースラインが合わないのも気持ち悪く感じます。これについては、align-items: flex-end; を指定することでベースラインがきれいに揃います(画像の中で商標の表示部分のフォントのウェイトが揃っていないのもついでに修正しました)。

flexでリストのli要素を横並びにしている(baselineが合わない)

#footer ul {
    display: flex;
    flex-wrap: wrap;
    align-items: flex-end;
}

(同じく画像はPowerCMS Xの製品サイト) ルビを付けることで、チェックボックスとテキストのベースラインが合わない件も同様の指定で揃えることができました(この checkboxはBootstrap4固有のデザインで、新しいバージョンではチェックボックスに position: relative; 指定で解決しました)。

リンクの下線が途中で切れる問題

この問題は結局解決できず(<rb>タグの幅の分しか下線が付かないブラウザの仕様で<rb>より<rt>の幅が広いと隙間が空く)なのですが、グローバルナビなど固定部分については text-decorationを消して border-bottomを指定するということで対応させました。text-decoration-skip-ink が近いのかな、と思いましたが、以下の指定では下線は繋がってくれませんでした。

text-decoration-skip-ink: none;

モノルビが良いかグループルビが良いか問題

この画像は「多文化共生」というテキストに対するルビを付けたときの比較です。両方ともグループルビですが、左側は「多文化」と「共生」にそれぞれルビを付けています、右側は「多文化共生」全体にルビを付けています。左はオリジナルのテキストがふりがなの文字数のせいで均等にならないことが気持ち悪く思います。気持ち悪い、というのは好みの問題もあるでしょうが、人によっては文字間隔がバラバラであることが読みにくさに繋がるかも知れません。

やさにちウォッチでは、形態素解析を利用してふりがなを自動で付けているため、「多文化共生」を辞書に登録することによって文字間隔が均等になりました。

もちろん、モノルビや細かい単位でルビを振ることのメリット「漢字と対応するルビが一致するため、漢字の読み方を知ることができる」については失われますが、読みやすさを優先しました。

ただ、やりすぎると副作用があります。以下の例は長いテキスト( 福岡出入国在留管理局 )に対してグループルビを指定した結果、スマートフォンなど画面幅の狭い環境で rtタグ内のふりがなが途中で改行されてしまった例です。とても読みづらくなります。

「福岡出入国在留管理局」全体にルビを付けると画面幅が狭い時にふりがなが2行になる(最後の「ょく」が次の行になってしまっている)

バッジやボタンの見た目が揃わない・不要な隙間ができる問題

この問題も未解決ではありますが、こういうもの、と割り切ることにしています。やさにちウオッチでは、記事に付けたタグやカテゴリをバッジ ( 角丸の四角 ) のデザインで並べています。以下の例は「イベント」「長崎県」ですが、長崎県のほうにだけふりがなが振られていてイベントの方はバッジの上部に隙間が空いています。テキストのベースラインが揃うようにしていますが、並んだタグにすべてふりがながないようなケースだと、気持ち悪いデザインに見えてしまいます。

漢字とふりがなの距離を縮めてオリジナルテキストが上下中央にくるようにすれば違和感は減ると思われますが、漢字とふりがなの距離を縮めてしまっては元の目的である読みやすさが失われてしまい本末転倒です。

バッジ「イベント」「長崎県」が横に並ぶ時、イベントにはふりがなが振られないため隙間が開く

フォーカスがガタつく問題

この問題も今のところ未解決です。tabキーでフォーカス移動した時に、aタグの中にルビがあるとフォーカス・インジケータがガタガタになります。

もちろん、フォーカスが当たらないことと比べればきちんと当たって「見える」ことが大切ですし、そこがクリックできる領域なのだから仕方ないじゃん、とも思うのですが、クライアントワークでは「見苦しいからフォーカスがあたらないようにして欲しい」とか、ありがちな気もします。

トップページなどのインデックスページの場合は、クリックできる領域を思い切ってウイジェットのパネル? 全体にしてしまうことで解消できるかと思いますが、記事の本文などではそうもいかず、ここについては現状そのままにしてあります。

tabキーでフォーカス移動した時に、ルビがあるとフォーカス・インジケータがガタガタになる

Amazon Polly のSSML

ふりがなのスタイルとは少し違う話になりますが「伝えるウェブ」で提供している、ウェブページ読み上げには Amazon Polly 別ウィンドウで開きますを利用しています。辞書に登録されている語が読み上げるテキストに含まれている時、SSMLで読み方を渡せるようにしています(設定でOn/Offを指定できる)。SSMLとは「Speech Synthesis Markup Language」の略で、日本語に訳すと「音声合成マークアップ言語」となります。

Speech Synthesis Markup Language (SSML) Version 1.1 別ウィンドウで開きます

「やさにちウォッチ」では各記事を読み上げたMP3ファイルを添付しており、ふりがなを反映して発信側の意図した読み上げ音声を提供しています。Webサイトに読み上げボタンを付けることや音声ファイルを用意することに対して批判的な論調もありますが、今日(2021年12月1日)現在、WCAG2.0(JIS X8341-3:2016)の「3.1.6 発音」別ウィンドウで開きますの実現方法が実質ないように思える(違っていたらご指摘ください)現状では、過渡期の対応として一定の意味はあるのではないかというのが私の考えです。

サポートされている SSML タグ - Amazon Polly 別ウィンドウで開きます

※ 上記のドキュメントのページですが、日本語の読み上げの最適化 ( phonemeタグの使い方など ) についての情報が不足しています。以下のページが参考になります。

Amazon Polly を使用した日本語テキスト読み上げの最適化 | Amazon Web Services ブログ別ウィンドウで開きます

Pollyは非常に自然なイントネーションで上手く日本語のテキストを読み上げてくれます。ただ、以下のような渡し方だと、登録した辞書と読み上げ方は完全に一致するものの、読み上げのイントネーションは非常に不自然になります(11月17日追記 : subではなく、phonemeを使うと不自然さは回避できます)。(12月1日追記 : phoneme を使うと確かにイントネーションの不自然さは解消されますが、Amazon Pollyが持っている辞書と一致しないものは正しく音声化されません。いわゆる当て字(例 : 「七音（どれみ）」など)です。)

イントネーションをあわせて指定しなければならないのですが、Pollyが解釈したオリジナルの漢字の読み方とわたされたひらがなが一致する場合はオリジナルのテキストを利用するなどしてくれるようになると、指定も煩雑ではなくなり、品質も上がることが期待されます(12月1日追記 : phoneme type="ruby"がこれにあたるようです)。

subタグを利用して読み方を指定する例 (イントネーションや単語の区切りが不自然になる)

<speak xml:lang="ja-JP">
<prosody rate="default" pitch="default">
<sub alias="つたえるうぇぶ">伝えるウェブ</sub>は「やさしい<sub alias="にほんご">日本語</sub>」での<sub alias="じょうほう">情報</sub><sub alias="はっしん">発信</sub>を<sub alias="しえん">支援</sub>します。
</prosody></speak>

phonemeタグを利用して自然な読み上げを実現する例

<speak xml:lang="ja-JP">
<prosody rate="default" pitch="default">
<phoneme type="ruby" ph="なんば">難波</phoneme>の次の駅は<phoneme type="ruby" ph="にっぽんばし">日本橋</phoneme>です。
</prosody></speak>

スクリーンリーダーでベタ書き? のひらがなを読み上げさせてみる

脱線ついでに、スクリーンリーダー ( MacのVoiceOver ) にベタ書きのひらがなのみのテキストを読み上げさせてみました。

やさしいにほんご

実際にやってみるとわかりますが、「やさしいに」「ほんご」というように、不自然なところで切れてしまいます。これは、辞書が「にほんご」という単語を持たないからだと思われます ( 以下は MeCab + IPA 辞書での形態素解析の結果 )。

$ mecab
やさしいにほんご
やさしい	形容詞,自立,*,*,形容詞・イ段,基本形,やさしい,ヤサシイ,ヤサシイ
に	助詞,格助詞,一般,*,*,*,に,ニ,ニ
ほん	動詞,自立,*,*,五段・ラ行,未然特殊,ほる,ホン,ホン
ご	接頭詞,名詞接続,*,*,*,*,ご,ゴ,ゴ
EOS

何が言いたいかというと、単にルビのある部分をひらがなに直して読み上げるようにするだけでは駄目だということです。Pollyの phonemeタグのような仕組みが必要だと思います。Pollyでは、Pollyが認識する発音と phonemeタグで指定した「よみ」が一致する場合のみ、それを使う、という方法でこの問題を解決しているようです。

Amazon Polly を使用した日本語テキスト読み上げの最適化 | Amazon Web Services ブログ別ウィンドウで開きます

振り仮名が Amazon Polly が認識する発音の1 つと一致しない場合は、うまく機能しません。たとえば「海（やま）」のように、「海」という漢字に対して「やま」という振り仮名を当てても振り仮名としては認識されません。これは、たとえば「七音（どれみ）」のように、標準的ではない文字の読み方をする人名の場合に当てはまります。

Amazon Polly を使用した日本語テキスト読み上げの最適化 | Amazon Web Services ブログ別ウィンドウで開きます

解決されていない問題

CSSやJavaScriptによる「ハック」のようなもので、将来のブラウザの実装や対応状況によって結果が変わってしまうといういわゆる「堅牢性・互換性」に問題があるのは別にして、解決されていない問題としては以下のようなものがあります。

ブラウザ内のテキスト検索 (ふりがなボタンでルビを削除しても検索されません)
設定でルビを非表示にすれば、読み上げは不自然にはならないものの、指定したルビが読み上げに反映されない
モノルビ、グループルビ問題、熟語問題、改行問題
リンクの下線が途中で切れる問題
バッジのデザインやフォーカスがガタつくなど、デザイン上の制約問題

検索エンジン・SEO問題

その他に、Googleなどの検索エンジン問題があると思われます。ルビを付けることが SEOに悪影響があるかもしれないとなると、そもそも Webにおけるルビの普及を妨げる要因になりかねません。この問題については今後も調査を続けたいと思います。

尚、やさにちウォッチのサイト内検索では、ふりがなを削除した上でインデックスを作成し、さらに、ひらがなのみのテキストもインデックスするようにしています。また、表記揺れにも対応させており、「西日本」でも「にしにほん」でも「にしにっぽん」でも検索できるようになっています。

このあたりの技術的な解説については以下の記事をぜひご覧ください。

やさにちウォッチの舞台裏〜やさしい日本語のオウンドメディア構築事例〜別ウィンドウで開きます

まとめ

ブラウザやスクリーンリーダーにおけるHTMLの ruby に対する実装は現状 (2021年12月現在) ではまだまだ課題が多い
フォントの選択、CSSの line-height, transform プロパティなどの調整である程度の読みやすさは確保できる
Amazon Pollyの SSML は rubyの音声読み上げに対する解決のヒントになるかもしれない

※ AWS、Amazon Pollyは、AWS の米国およびその他の国における登録商標です。
※ 「新ゴ」「UDデジタル教科書体」は、株式会社モリサワの登録商標です。
※ NotoはGoogle Incの商標です。

カテゴリー：サイト制作全般

投稿者：Junnama Noda