別にAcrobatがなくてもPDFタグが見れることに気づいたので、ウェブアクセシビリティ導入ハンドブックをもうちょっと覗いてみた。

(メモ)「ウェブアクセシビリティ導入ガイドブック」は自身がアクセシビリティ規格を満たしているわけではないの続き?ですたぶん。

で、タイトルの件ですが、AcrobatがないとPDFタグを見れない…と思ってた時期が私にもありました。

「PDF-XChange Editor」軽快で多機能なPDFビューワー - 窓の杜

まさか、窓の杜に置かれているソフトにあったとは…。窓の杜曰くビューワーですけども、ソフトウェア名のEditorのほうが実態に近しいと思います。口でいうよりかは見たほうが早いでしょう、ということではいドーン。

PDF-XChande Editorのスクリーンショット
ウェブアクセシビリティ導入ハンドブック(2024年3月29日発行版)をPDF-XChande Editorで閲覧している様子。読み上げ順序を表示させつつ、PDFタグやプロパティも見ることができる。Adobe Acrobatと何ら遜色がないといえよう。

もちろん、自動のアクセシビリティチェックも行えます。

PDF-XChande Editorのスクリーンショット
自動アクセシビリティチェックのダイアログと、チェック結果を表示している様子。悲しいかなアクセシビリティチェックに失敗しているという…。

さておき、せっかくなのでハンドブックの中身をもうちょっと覗いてみましょう。先ほどのスクリーンショットのページ(ノンブルPage 9)に戻って、まず、このページの最初のタグに注目してみましょう。

<L>
  <LI>
    <Lbl>
      <P>
        Text: "●目が見えなくても情報が伝わる・操作できること"

どうやらリストとしてタグ付けされていますが、リストエレメント(List Elements)については、PDF 1.7規格の14.8.4.3.3 List Elementsに記されています*1。Table 336 - Standard strucure types for list elementsには、次の4つが示されています。(ざっくりと抜き出してみましょう)

  • L
    • (List) [...] Its immdiate children should be an optional caption [...] followed by one or more list items (structure type LI).
  • LI
    • (List item) [...] Its children may be one or more labels, listbodies, or both (structure type Lbl or LBody).
  • Lbl
    • (Label) A name or number that distinguishes a given item from others in the same list or other group of like items.
  • LBody
    • (List body) The descriptive content pf a list items. [...]

とまあこんな感じで、PDF 1.7規格ではLエレメントの子にLIエレメントを1つ以上持つべきである(should)としか書かれてないわけですね、すごい。なお、WCAG 2.1達成方法集PDF21: PDF 文書内のリストにリストタグを使用するにも似たようなことしか書いていません。

  • L - リストタグ (一つ以上の LI タグを含む)
  • LI - リスト項目タグ。リスト項目タグには、Lbl タグと LBody タグを含めることができる
  • Lbl - リスト項目ラベル。項目番号や行頭文字などの識別情報を含む
  • LBody - リスト項目本体。リスト項目コンテンツを含む。ネストされたリストの場合には、追加のリストタグツリーを含むことがある

自動アクセシビリティチェックで、Lエレメントの子にLIエレメントがないとエラーとして返すわけですから、おそらくISO 14289-1:2014 (PDF/UA-1)規格でshouldではなくshall扱いにしていると思われるものの、あいにくと自分の目で確かめてはいません。

ただし、セマンティックにリスト構造を扱うのであれば、たとえば次のようになっている必要があるでしょう。

<L>
  <LI>
    <Lbl>
      Text: "●"
    <LBody>
      Text: "目が見えなくても情報が伝わる・操作できること"

PDF associationが発行しているTagged PDF Best Practice Guide: Syntax4.2.5 <L> (List), <LI> (List Item), <LBody> (List Body)でもそのように記述されています。WCAG 2の観点では、達成基準1.3.1の問題としてよい…のかもしれません。

続いて、ページ中ほどのおなじみの次の文ですが、これは明らかに英語です。

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

が、英語として設定されていません。

PDF-XChande Editorのスクリーンショット
英語テキストのタグのプロパティ。言語は「既定」とされており、英語にはなっていない。

PDF 1.7規格14.9.2 Natural Language SpecificationPDF19: PDF 文書内で Lang エントリを使用して節や句の言語を指定する、ベストプラクティスの5.5.1 Langにいろいろとあります。WCAG 2の観点では、達成基準3.1.2の問題としてよい…と思われます。

まとめ?

とまあ、こんな感じでPDFを無料のソフトで詳細に調べることができます。デジタル庁におかれましては、正面切ってPDFを改修するという泥沼*2よりもむしろ、後日公開予定としているHTML版をさったと公開してしまったほうがよいのではないか、と思ったり思わなかったりするところです。

*1:PDFの規格は無料で閲覧することができます。現在はAcrobat SDKから、ISO 32000-1:2008(PDF 1.7)のコピーを入手できます。

*2:かける労力の割には、スクリーンリーダーのアクセシビリティが向上するわけではないと思われ…

Re: HTMLのルート要素ではcolorとbackground-colorをセットで指定すべき

ちょっと間が空いて、亀リプっぽくなっちゃいましたけど、HTML のルート要素では color と background-color をセットで指定すべきというお話について。

昔からブラウザには配色設定があり、テキスト色と背景色をユーザーが任意に指定できます。

……という話は Web アクセシビリティとフェイルセーフの記事に以前書いたのでその詳細は省略しますが、WCAG 2.2 達成方法集の F24(W3C) において達成基準 1.4.3(レベルAA)などの失敗事例として掲載されているにも関わらず、このことは世間ではなぜか認知が薄いようです。

認知も薄いというか、私も言われるまで気づかなかったあたり、まあそういうことなんじゃないかなと*1。……という話だけはあまりにもアレなので、ざっくりとですが、ほんのちょっと深掘りしてみましょう。

WCAG 2.1 達成方法集のF24のタイトルは、「達成基準 1.4.3、1.4.6 及び 1.4.8 の失敗例 - 背景色を指定せずに前景色を指定する (又は、前景色を指定せずに背景色を指定する)」というものです。

皆さんご存じのとおりかと思いますが、あらためてWCAG 2の達成基準 1.4.3のコア部分に触れておくと、

達成基準 1.4.3 コントラスト (最低限)
テキスト及び文字画像の視覚的提示に、少なくとも 4.5:1 のコントラスト比がある。

とあります。ここで、「コントラスト比 (contrast ratio)」というのはWCAG 2の用語集にあり*2注記4に注目しましょう。

注記 4

背景色は、テキストが通常の使用においてレンダリングされるときに背景となるコンテンツの色として指定された色である。テキストの色は指定されているが背景色が指定されていない場合、利用者のデフォルトの背景色は未知であり、コントラストが十分かどうかを評価することができないため、失敗例となる。同じ理由で、背景色が指定されているがテキストの色が指定されていない場合も失敗例となる。*3

つまり、Techniques for WCAG 2.2のF24は、“注記4をそのまま持ってきた”ということになります。言いかえると、WCAG 2の規定ではないわけですね。

この注記4に関して、w3c/wcagのレポジトリに、Note 4 in definition "contrast ratio" still relevant (1.4.3, 1.4.6, 1.4.11)?#876というissueが立てられています。このissueで結論が出ているわけでもないですが、issueを立てた@JAWS-testのコメントが参考になるかと思いますので、要所をざっくり訳しながら見てみましょう。

JAWS-test commented on Aug 28, 2019

「用語:コントラスト比」にある注記4が達成基準1.4.3、1.4.6、1.4.11に今でも関連しているかどうかを議論して確認し、この注記を廃止することを提案する。

理由:

  • テキストに色が定義されていないような方法(https://waic.jp/translations/WCAG21/Techniques/general/G148)で達成基準1.4.8(1番目の項目:「利用者が、前景色と背景色を選択できる」)を満たすページを私は知らないため、(注記4の問題を引き起こす)この達成方法が視覚に障害のある人に使用される可能性は低い。
  • 今日、ほとんどの人が使用しているブラウザーでは、色を一切設定できない(たとえば、Chrome)。https://waic.jp/translations/WCAG21/Techniques/general/G156IE7について言及しているが、誰が持っているだろう?(IEFirefoxでは今でも動作する)
  • ほとんどの視覚に障害のある人は、自分のユーザースタイルやハイコントラストモードを使っていると思う。どちらの方法でも、注記4の問題は発生しない。
  • 多くの人にとって、注記4は理解しにくい。特に、その直前の注記3「もし背景色の指定がない場合は、背景色には白を想定する。」と組み合わせると、なおさら理解できなくなる。
  • 私の国のアクセシビリティテスターを対象に調査したところ、注記4について知っている人はほとんどおらず、この注記が満たされているかどうかをテストする人もいないことがわかった。私自身がこの注記を見つけてテストに含めるのに何年もかかった。注記4に違反するページはいくつかあるが、多くはない。

注記4が今でも適切であるならば、私はWCAG 3.0において、これを達成基準に直接含め、解説書の中に隠さないように提案する。

mraccess77 commented on Aug 28, 2019

F24があるが。

JAWS-test commented on Aug 28, 2019 (2)

@mraccess77

F24があるが。

F24をよく知っており、いつもこれを使って注記4が実際に何を意味するのかを私は説明している。
しかし、注記4はもはや最新ではないと思う。

  • モバイルデバイスでは一切機能しない(私の見解)
  • デスクトップデバイスではChromeでは機能しないが、Chromeは高いシェアだ

そんなわけで、注記4とこれに関連する失敗例や達成方法がまだ必要かどうかについて、議論を始めたかった。 すべての色を変更せずにテキストの色を変更できるというアイデアが気に入っている(ハイコントラストモードの場合と同様に)。しかし、G148は不適当に思える。G175か、新しい達成方法がよいだろう。

JAWS-test commented on Sep 19, 2019

@Myndexが何を言っているのかわからんが、ブラウザーで色を決定するとき、次の順序が適用されるものと仮定するhttps://www.w3.org/TR/css3-cascade/#cascading-origins

1. OSのハイコントラストモード(Chromeでは、まだサポートされていない*4)、プラグインによる色フィルター、Zoomtextのような拡大鏡の色フィルター
2. ユーザースタイル(ブラウザーのユーザーによる定義)
3. ウェブ制作者のCSS
4. ブラウザーかOSの色設定

この順序は!importantがなければ正しい。

そういうわけで、「コントラスト比」の定義の注記4は、(上記のリストの)1〜3には関係ない。注記4は、ブラウザーの色設定(4)の順位が最も低いため、その場合にのみ関連することになる。前景色のみが制作者のCSSで定義され(3)、背景色がブラウザーで定義されている場合(4)に、コンテンツが認識できなくなる可能性がある。

Chromeでは、CSSで指定されていない色を変更する方法を私は知らない(1と2は、制作者のCSSを上書きするため問題ないので除く)。IEFirefoxでこの可能性を知っているだけで、CSSで色を指定していないページが存在しないため、この選択肢を利用するユーザーはいないと思う。
(以下略)

…ということで、実際にFirefoxの配色設定を「テキスト色を白、背景色を黒」に設定し、さらに「システムの配色を使用する」をオフにしたうえで、Windows 10でハイコントラストモードを適用してみて、どうなるのかを見てみましょう。

Firefoxの配色設定画面
元記事と同じ設定を意図したFirefoxの配色設定で、背景色を黒、テキストを白に設定している様子。

デジタル庁のトップページ
前述のFirefoxの設定で、Windows 10のハイコントラストをオン(配色テーマは「ハイコントラスト 黒」)にして、デジタル庁のトップページ(www.digital.go.jp)にアクセスした様子。背景色が黒、テキストが白となり、本文テキストを読む分には支障はない。ただし、リンクテキストはFirefoxの配色設定を引き継いでいるようで、コントラストが低くなってしまう問題がある。

「システムの配色を使用する」をオンにした状態も見てみましょう。

デジタル庁のトップページ
Firefoxの配色設定で「システムの配色を使用する」をオンにした状態。リンクテキストは黄色で表示され、読みにくさは解消されている。

都合のよい想像として、別にブラウザーだけのコントラストをいじくり回したいわけではなく、デバイス全体の設定を変更したいでしょうから、Windowsであればハイコントラストモードをオンにするというシナリオは自然なものではないか…とは思います。

issueには続きのコメントがあるので、それもついでに見てみましょう。

JAWS-test commented on Sep 20, 2019

仮に注記4を存続させるとするなら、下記を追加することを提案する:

  • これが適用される要素について注意する(リンク及びテキストだけ、又は標準の前景色と背景色を持つボタンも対象とするため、ブラウザーの色調整の影響を受けない。ボタンは、標準色が削除された場合にのみ影響を受ける。例:color:inheritbackground-color:transparent)。
  • 前景色と背景色が指定されておらず、テキストがグラフィック又はボーダー上にある場合にも違反が発生する可能性があることに注意する(つまり、背景色はCSSプロパティbackground-colorだけでなく、テキストの実際の背景を参照すべきである)。
  • 達成基準1.4.11の場合、これは透明な背景を持つグラフィックにも適用されることに注意する。

JAWS-test commented on Oct 6, 2019

注記6

WCAG に適合しているか判断する場合は、典型的な提示において隣接するであろうと制作者が想定するコンテンツで指定された色の組み合わせについて評価しなければならない。制作者は、ユーザエージェントによる色の変更などのように通常とは異なる提示を考慮する必要はない。ただし、それが制作者のコードによって起こる場合は除く。*5

私の意見では、注記4で説明されている問題は、ユーザーがユーザーエージェントの色を除外した場合にのみ発生するため、注記4と矛盾する。注記6は、ユーザーによって行われなかったユーザーエージェントに加えられた変更のみを言及するように修正されるべきかもしれない。

こんな感じで、注記4を存続させた場合の修正案が提案されていたり、注記6と比較しても注記4が怪しいのでは…ということが述べられています。

まとめ?

とりとめもないのですが、以下のような感じでしょうか。

  • HTMLのルート要素ではcolorbackground-colorをセットで指定すべき、という考え方自体は積極的に否定するものでもない
    • ただし、元記事の参照している達成方法F24の泉源となる、WCAG 2のコントラストの注記4自身に疑義がある
    • 注記は規定ではなく、WCAG 2達成方法集(Techniques for WCAG 2)も参考情報に過ぎないことに留意したい
  • OSのハイコントラストモードや(ここでは触れていないが)ユーザーCSSという選択肢もあるわけで、ブラウザーの配色設定が第一候補になるのか…?という疑問はある
  • 最近では、ダークモードの制御も可能であり、そういう方面から考えた方が有意義かもしれない

そんなこんなで、特定のブラウザーの配色設定を背景としたアクセシビリティのために前景色と背景色をセットで設定しましょうというよりかはむしろ、ユーザビリティのためにハイコントラストモードやダークモードという選択肢を考慮したページの配色の観点から、前景色と背景色をセットで設定しましょうとする方が説得力が増すのではないか…と思いましたがどんなもんでしょうか。

*1:本当にそれでいいのかというツッコミは脇に置いて

*2:コントラスト比の定義は本題とはあまり関係なので脇に置く

*3:「失敗例」とあるのは実は「失敗」と訳すべきなのかもしれない?

*4:訳注:Chrome でユーザー補助の拡張機能を使用するで「Windows パソコンで Chrome の最新バージョンを使用している場合、Chrome の色設定はパソコンの設定に合わせて自動的に調整されます。」とある。実際、Windows10のハイコントラストモードを反映していた

*5:それはそれとして、ここのauthorはコンテンツ制作者と訳すべきか?