テキストのサイズ変更やリフロー、400%拡大にまつわる話

公開

アクセシビリティ Advent Calendar 2022の5日目です。今年は個人では「axe-coreを利用したアクセシビリティチェックのレポートCSVに達成基準などの情報を加えてみた」や「axe-coreのRule DescriptionsやACT-Rulesを読み、スプレッドシートに詳細をまとめてみた」、業務では「PowerCMS Xにaxe-coreを活用したアクセシビリティ検証機能・PDF内にある画像の代替テキスト表示機能を実装」などを手掛けました。また、大規模なサイトのコーディングも担当しました。

生じた疑問

JIS X 8341 3:2016の適合レベルAA準拠を目標とするWebサイトのコーディングを担当しました。作業過程で「達成基準 1.4.4 テキストのサイズ変更」について確認するためにiPhone 12 ProのSafariにおいてテキストサイズの拡大を行い表示チェックをしました。結果、コンテンツ又は機能が損なわれないことが分かったのですが(達成方法 G179)、テキストサイズを2倍にすると2カラムで表示している箇所の各カラム幅(コンテナ幅)が狭く5文字ぐらいしか表示されないために「もしかすると見づらいのでは? 1カラムにならないかな?」と疑問を感じました。
iPhone 12 ProのSafariで改善前のCSSによる200%拡大表示。2カラム表示で1カラム1行5文字程度表示されている

アドベントカレンダーにエントリーし記事の検討始めてから気付いたのですが、これはアクセシビリティというよりユーザビリティの問題かもしれません。

よりよい感じにカラム数を変化させる

PC版とスマホ版のデザインが上がってきてそれを基にコーディングするのがよくあるケースでしょうか。私のプロジェクトでもそうでした。スマホ版デザインで2カラム、PC版デザインで3カラムとなっていたのでまず2カラムのスタイルを書き、ビューポートが広い端末に向けてメディアクエリで3カラムになるスタイルを書きました。

.c-index {
  display: flex;
  flex-wrap: wrap;
  gap: 2em 5.49%;
}

.c-index__item {
  flex-basis: 47.255%;
}

.c-index__item::before {
  display: block;
  content: "\200B"; /* add zero-width space https://gerardkcohen.me/writing/2017/voiceover-list-style-type.html */
  width: 0;
  height: 0;
}

@media screen and (min-width: 48em) {
  .c-index__item {
    flex-basis: 29.673%;
  }
}

上記コードだと最小カラム数が2カラムになってしまうので、1カラムになるスタイルから書き始め、メディアクエリで2カラム・3カラムのスタイルを書けば良かったのか、と考えました。デザインデータにはない領域にも目を向ける必要がありますね。

.c-index {
  display: flex;
  flex-wrap: wrap;
  gap: 2em 5.49%;
}

.c-index__item {
  flex-basis: 100%;
}

.c-index__item::before {
  display: block;
  content: "\200B"; /* add zero-width space https://gerardkcohen.me/writing/2017/voiceover-list-style-type.html */
  width: 0;
  height: 0;
}

@media screen and (min-width: 20em) {
  .c-index__item {
    flex-basis: 47.255%;
  }
}

@media screen and (min-width: 48em) {
  .c-index__item {
    flex-basis: 29.673%;
  }
}

改善後のCSSを基にブラウザで表示を確認すると、テキストサイズを2倍にした時1カラムで表示されるようになりました。
iPhone 12 ProのSafariで改善後のCSSによる200%拡大表示。1カラム表示となり1行11文字程度表示されている

あとで気付いたのは、iPhoneユーザーガイドでは「テキストの拡大」とありますが余白が2倍になっているのでテキストだけの拡大ではなく画面全体が200%ズームしているのかと気付きました。SafariのWebインスペクタでbody要素を確認すると195pxであることが分かります。(100%時は390px) AndroidのChromeではテキストのみ拡大されるのでリフローされませんでした。 iPhoneのSafariでサンプルページを表示し、Mac版SafariのWebインスペクタでbody要素の幅を調査した画面

達成基準 1.4.10 リフロー

ここまでは達成基準 1.4.4を基にしたユーザビリティの話のようでしたが、WCAG 2.1だと「達成基準 1.4.10 リフロー」があることを知りました。(WCAG 2.1の理解不足ですね…。)WCAG 2.1 解説書を読み進めると、ここまでに記述した「よりよい感じにコンテンツをリフローさせる」という話題が関係するように感じますし、CSSは「達成方法 C31 コンテンツをリフローするために CSS Flexbox を使用する」に該当するのかと考えました。C31の検証手順に従って改善後のCSSを400%拡大で表示を確認すると、100%表示で3カラムになるコンテンツは400%拡大で2カラムにリフローされコンテンツが横スクロールなしで利用できることが確認できました。
Chromeでウインドウを1280px×1024pxに設定し400%で表示している画面。開発者ツールの機能によりビューポートは320px×256pxであることが表示されている。

iPhone 12 Proでは最高でも300%の倍率になりますが、リフローされて全てのコンテンツが横スクロールなしで利用できました。(「320CSSピクセルに相当」ではないけれど)

まとめ

  • 達成基準 1.4.10: リフローを知ることができた
  • デザインを基にCSSを細かく検討して記述することがアクセシビリティ向上にも役立つと考えた
    • 上手くリフローすれば400%拡大時でもコンテンツを損なわず横スクロールなしで閲覧できることが確認できた

でもやはり達成基準 1.4.10 リフローの話を持ち出したのはちょっとこじつけっぽいかな、すみません。

おまけ:ヤクルト1000チャレンジ

2日目のsaimari@Relic Inc.さんの記事を拝見し、「実装ポイント③」のサンプルを僕なりに書いてみました。確かに今年は拡大についていろいろ考えさせられた年でした。デザインをきちんと再現できるCSS、FLOCSS等で破綻しにくいCSSを書き、さらに拡大にも対応するというのはなかなかハードですね。

テキストがあるボックスの右上に絶対配置で絵文字を配置し、ブラウザを200%拡大にして表示した画面