アクセシビリティBlog

Webサイトのアクセシビリティを高めるための方法や国内外の関連情報など、さまざまな角度からWebアクセシビリティに関する話題をご提供します。

当Blogの更新情報は、Twitter経由でも配信しています。興味のある方はぜひ、@mlca11yをフォローしてください。

発音に関する2つのW3C技術草案文書について

アクセシビリティ・エンジニア 中村（直）

少し前の話ですが、Two First Public Working Drafts for Pronunciationというタイトルで発音に関する2つのW3C文書がFirst Public Working Draft（最初の公開草案）として発行されたことがアナウンスされました。

いずれも3月10日付けであり、Accessible Platform Architectures Working Groupから発行されているものです。

1つめの文書はExplainer: Improving Spoken Presentation on the Webというもので、テキスト音声合成（Text-To-Speech、TTS）にHTMLを正確に発音させるためのメカニズムの提案をしています。

この文書の中では、2つの技術的なアプローチを提案しています。そのうちの1つはインラインSSMLであり、もう1つはSSMLの属性ベースモデルです。言葉にするよりも、例示されているサンプルコードを見た方が早いでしょう。

the population of <speak><say-as interpret-as="digits">90274</say-as></speak> <!-- インラインSSML -->
the population of <span data-ssml='{"say-as" : {"interpret-as":"digits"}}'>90274</span> <!-- SSMLの属性ベースモデル -->

前者はSSMLを直接HTMLに埋め込むアプローチで、後者はHTMLのカスタムデータ属性を用いて、そこにJSONを埋め込むアプローチとしています。今のところ、HTMLはSSMLを直接埋め込むことを許可していませんので、構文上違反にならないのは後者となります。

ここでSSMLについて補足しておきますと、SSMLはSpeech Synthesis Markup Languageの略称で、音声合成アプリケーション用XMLベースのマークアップ言語です。2010年にSSML 1.1がW3C勧告として発行されており、音声合成マークアップ言語（SSML）バージョン1.1として上綱秀治氏が翻訳を公開しています。SSMLに関しては、Webからは少し離れますが、Amazon AlexaやGoogle Homeの開発者であればなじみがあるかもしれません。両社からSSMLに関する公式のリファレンスが用意されています。

もう1つの文書はPronunciation Gap Analysis and Use Casesというもので、これまでの発音に関連する技術仕様の歴史、発音にまつわるコア要件の列挙、技術的なアプローチのユースケース、ギャップ分析といったものが含まれているものです。

技術的なアプローチには、Explainer: Improving Spoken Presentation on the Webで触れているものと似たアプローチや、HTMLのカスタム要素、JSON-LD、HTMLのルビ要素といったものが挙げられています。

ギャップ分析としては、HTML、WAI-ARIA、PLS、CSS Speech、SSMLと言った技術について触れられています。なお、PLSはPronunciation Lexicon Specificationの略称で、2008年にW3C勧告として発行されているものです。こちらについても、発音辞書仕様（PLS）バージョン1.0として上綱氏が翻訳を公開しています。

ギャップ分析として挙げられているものを眺めてみると、SSMLが必要とされるコア要素をすべてカバーしていますが、SSML以外の技術を組み合わせると、概ねコア要素をカバーすることができるとも読めます。どのアプローチが取られるのかは、これから議論が始まるものと考えられますが、くしくもこれらの2つの文書と同日にCSS Speech ModuleがCandidate Recommendation（勧告候補）としてステータスを変更して再発行されたりと、発音方面ににわかに動きが見られます。

最後に、どちらの文書も、TOEFLやTOEICといった試験を開発・運営を行っていることで知られるEducational Testing Service所属のエディターが携わっているのが興味深いところではあります。また、後者の文書はエディターの中にPearsonが見え、教育分野がこの分野に興味があることがうかがえます。今後どのように議論が進んでいくのか、またWCAG 2.0 達成基準 3.1.6 発音とどのように関係していくのか、個人的には興味深いところであります。

パーマリンク

WAICサイトでWCAG 2.1解説書が公開されました

アクセシビリティ・エンジニア 中村（直）

WAIC（ウェブアクセシビリティ基盤委員会）のサイトで、WCAG 2.1の理解に欠くことのできない、Understanding WCAG 2.1の翻訳であるWCAG 2.1解説書が公開されました。

WAICのニュースページもあわせて参照ください。

WCAG 2.1解説書の特長としては、とくにWCAG 2.0から新規に追加された達成基準の解説について、（WCAG 2.0から存在する）従来の達成基準の解説と比較すると、画像による説明が比較的多い点が挙げられます。達成基準 1.4.11: 非テキストのコントラストを理解するは画像を多用して解説が行われています。

なお、今回WAICサイトで公開された解説書の原文の日付は、解説書の訳注にも記されているように、2019年3月時点にW3Cのサイト上で公開されていたものです。そのため、W3Cで公開されている最新のUnderstanding WCAG 2.1とは異なる場合があります。

その一方で、WAICで翻訳文書の管理を担当している翻訳ワーキンググループ（通称：WG4）では、翻訳作業に協力していただける作業協力者を募集しています。WG4では現在、WCAG 2.1達成方法集の翻訳作業に取り組んでいますが、この翻訳作業を加速させたいという意志をお持ちの方は、作業協力者として手を挙げてみてはいかがでしょうか。

パーマリンク

WCAG 2.2の最初の公開作業草案が発行されました

アクセシビリティ・エンジニア 中村（直）

WCAG 2.1の後続となる、Web Content Accessibility Guidelines (WCAG) 2.2のFirst Public Working Draft（最初の公開作業草案）が2020年2月27日付けで発行されました。

この作業草案でのWCAG 2.1からの追加の達成基準は、New Features in WCAG 2.2にまとめられています。リンク先にあるとおり、現段階では2.4.11 Focus Visible (Enhanced)のみが加わっています。これは、あらかじめWCAG 2.2の策定作業を行っているAccessibility Guidelines Working Groupである程度議論した上で達成基準の文言をEditor's Draftに加えるという方針で策定が進められているために、結果として現時点で加えられているものが1つのみになっている、という状況になります。

では、新たに加わった達成基準はどのようなものでしょうか。WCAGに通じている方なら見覚えがあるかもしれませんが、WCAG 2.1にある（もちろんWCAG 2.0にもある）、達成基準 2.4.7 フォーカスの可視化（原仕様書名：Focus Visible）の強化版と銘打たれたものとなっています。そして、リンク先のWCAG 2.2の草案をご覧になった方は既にお気づきでしょうが、この達成基準2.4.11 Focus Visible (Enhanced)はレベルAAという扱いになっています。それに伴い、WCAG 2.2のこの草案の2.4.7 Focus VisibleはレベルAに変更がされています。

達成基準2.4.11の現在の文言は次のようになっています。

When a User Interface Component displays a visible keyboard focus, all of the following are true:

  • Minimum area: The focus indication area is greater than or equal to the longest side of the bounding rectangle of the focused control, times 2 CSS pixels.
  • Focus contrast: Color changes used to indicate focus have at least a 3:1 contrast ratio with the colors changed from the unfocused control.
  • Contrast or thickness: The focus indication area has a 3:1 contrast ratio against all adjacent colors for the minimum area or greater, or has a thickness of at least 2 CSS pixels.

NOTE A focus indicator that is larger than the minimum area may have parts that do not meet the 3:1 contrast ratio, as long as an area equal to the minimum does meet the contrast ratio.

この達成基準の日本語訳については、Website Usability InfoさんがWCAG 2.2 では「フォーカスの可視化」のビジュアル要件が規定されるかもという記事で試訳を公開されているのであわせて参照ください。

まだWCAG 2.2の作成プロセスの初期段階でもあるので、内容の詳細には立ち入りませんが、ロービジョンなどの障害のあるユーザーでも、フォーカスが当たっていることを認識できるようにするのがこの達成基準の意図であるとUnderStanding WCAG 2.2とされる文書ではうたっています（WCAG 2.2からリンクが張られている文書ですが、URLから見てもUnderStanding WCAG 2.1のように見えます）。

この新しい達成基準の適合レベルが最終的にどのような位置づけになるにせよ、現状ではブラウザーのデフォルトCSSでもって、この提案された達成基準を満たすことができないと思われますので、この達成基準を満たすためにはCSSに手を加える必要があるのがネックと言ったところでしょうか。特別な対応をせずともこの達成基準が満たせる状態になっている世界だと嬉しいかもしれない、というのが現時点での筆者の所感です。

パーマリンク

「一部準拠」というWebアクセシビリティの対応度の位置づけについて

アクセシビリティ・エンジニア 中村（直）

筆者はウェブアクセシビリティ基盤委員会（WAIC）に参加させていただいているのですが、そのWAICのSlackで、あるコメントをきっかけに先日ちょっとした議論が沸き起こりました。

そのきっかけとなったコメントの概要は、次のようなものでした。

  • あるWebサイトでJIS X 8341-3:2016に基づく試験結果が公表されているのを見かけた。
  • 試験結果には、達成基準ごとの試験結果が記載されている。
  • レベルAのある達成基準に対して、不適合という結果が記載されている。
  • レベルAの達成基準で不適合のものがあるため、当然レベルAには準拠しないが、そのサイトでは「満たしている適合レベル」として、「JIS X 8341-3:2016の適合レベルAAに一部準拠」と記載されている。
  • このサイトの記載はおかしいと思うが、WAICの公表している文書では明文化されていないのでは。

WAICではウェブコンテンツの JIS X 8341-3:2016 対応度表記ガイドラインという文書を公表しており、「準拠」「一部準拠」「配慮」という表記をこの文書で定めています。この文書の「3.2. JIS X 8341-3:2016 に一部準拠」では、

目標とした適合レベルに該当する達成基準を全て満たしていない場合、今後の対応方針を示すことで「JIS X 8341-3:2016に一部準拠」と表記することができる。

とだけ書かれているので、一見前出のウェブサイトの「レベルAAに一部準拠」はもっともらしく見えます。しかし一方で、（JIS X 8341-3:2016と技術的に同等な）WCAG 2.0の適合要件には次のように記載されています。

適合要件 ウェブページが WCAG 2.0 に適合するためには、以下に挙げるすべての適合要件を満たしていなければならない:

1 適合レベル: 以下に挙げる適合レベルの一つを完全に満たしていること。

  • レベル A:レベル A (適合の最低レベル) で適合するには、ウェブページがレベル A 達成基準のすべてを満たすか、又は適合している代替版を提供する。
  • レベル AA:レベル AA で適合するには、ウェブページはレベル A 及びレベル AA 達成基準のすべてを満たすか、又はレベル AA に適合している代替版を提供する。
  • レベル AAA:レベル AAA で適合するには、ウェブページがレベル A、レベル AA、及びレベル AAA 達成基準のすべてを満たすか、又はレベル AAA に適合している代替版を提供する。

つまり、WCAG 2.0でレベルAAに適合であるための条件としては、レベルAの達成基準をすべて満たした上で、基本的にはレベルAAの達成基準をすべて満たさなければならない、ということになります。これは言い換えると、上位レベルを満たしていると言うためには、下位レベルを満たしていることが条件である、というのがJIS X 8341-3の根本にあることになります。このことから、レベルAの達成基準を満たしていないにもかかわらず、レベルAAに一部準拠と前出のWebサイトで表記するのはおかしいのでは、という最初のSlackでのコメントにつながります。

Slack上でのやりとりが進む中で、総務省の公表している「みんなの公共サイト運用ガイドライン（2016年版）」の5.3.5. 適合レベルと対応度の設定 (3) 対応度には次のような記載がなされているという指摘がありました。

  • レベル A に準拠：レベル A の全ての達成基準を満たす。
  • レベル AA に準拠：レベル A、レベル AA の全ての達成基準を満たす。
  • レベル A に一部準拠：レベル A の達成基準を一部満たしていない。
  • レベル AA に一部準拠：レベル A の全ての達成基準を満たす。しかし、レベル AAの達成基準を一部満たしていない。
  • レベル AAA に一部準拠：レベル A、レベル AA の全ての達成基準を満たす。しかし、レベル AAA の達成基準を一部満たしていない。

みんなの公共サイト運用ガイドラインにのっとるならば、少なくともレベルAの達成基準を全部満たさなければ、レベルAAに一部準拠とは名乗れないということになります。このことは、「JIS X 8341-3:2016 対応度表記ガイドライン」からすぐに読み取れるものではありませんから、対応度表記ガイドラインに誤解がないように加筆するのが必要ではないだろうか、という話につながっていきました。実際筆者もそのように感じていますし、この対応度表記ガイドラインの管理を担当するWAICワーキンググループのメンバーの方も、WAIC内の議論・意見集約を通して、より明確な記載にしていきたいという趣旨のコメントをされています。

それはそれとして、「一部準拠」を明確にうたっているWebサイトというのもあまり多くはないというのが筆者個人の雑感ではあります。Webアクセシビリティの対応を目指す上で、「準拠」が一つの目標になってくると思いますが、部分的な対応となる「一部準拠」はあまりよくない印象を抱いている向きもあるのでは、というようなSlackでのコメントもありました。そもそも「一部準拠」というラベル付けでよいのかどうかというのは議論の余地がありそうです。また、JIS X 8341-3の普及を促すというWAICの活動目的の視点からも、「一部準拠」をうまくWebサイトで活用していただくため方策が求められているのかもしれません。

パーマリンク

Axe更新情報：DequeがAxe-core 3.5をリリース！

チーフアクセシビリティエンジニア 黒澤

（この記事は、2020年2月11日に公開された記事「Axe Updates: Deque releases axe-core 3.5!」の日本語訳です。Deque Systems社の許諾を得て、お届けしています。翻訳の正確性は保証いたしかねますので、必要に応じ原文を参照ください。）

  • 訳注1：コード例は原文のままです（明確な脱字は補っています）。
  • 訳注2：外部リンクのほとんどは英語のページにリンクしています。

Axe-core 3.5には4つの新しいルール、いくつかのバグ修正、そして新しい翻訳が含まれています。ですが、最もエキサイティングな変更はコントラストのテスト機能がはるかに高速に、より正確になったことです。

高速なコントラストのテスト

色のコントラストを正確にテストすることは、アクセシビリティの機械テストでもっとも難しいことの1つです。私たち（訳注：Deque Systems、以下同じ）はAxe-core 3.5でコントラストのテスト機能を一新しました。新しいテスト機能は巨大なページで、はるかに高速に動きます。とはいえ、ちょっとしたトレードオフもあり、小さなテストでは若干遅くなる場合があります。

新しいコントラストのテスト機能の利点の2つ目は、これまでの機能に比べてエラーが起きにくくなったことです。この新しいテスト方法では、私たちはコントラストに関する13個の偽陽性（訳注：false positive、問題ではないものを誤って問題として識別してしまうこと）を閉じており、「偽陽性はバグ」というAxe-coreにおけるコミットメントを強化しています。お気づきの偽陽性を報告いただけましたら、私たちは問題を調査し解決していきます。

Axe-core 3.5の新しいルール

ルール1：svg-img-alt

SVGの要素がimg、graphics-document、graphics-symbolロールを持っている場合に、アクセシブルなテキストを持っていることを確認します。

テストが失敗する例

<svg xmlns="http://www.w3.org/2000/svg" role="img">
<circle cx="50" cy="50" r="40" stroke="green" stroke-width="4" fill="yellow"></circle>
</svg>

テストが通過する例

<svg xmlns="http://www.w3.org/2000/svg" role="img">
<title>1 circle</title>
<circle cx="50" cy="50" r="40" fill="yellow"></circle>
</svg>

ルール2：identical-links-same-purpose

同じアクセシブルな名前を持っているリンクが同様の目的を持っていることを確認します。

人によるレビューが必要な例

<a href="https://www.deque.com/">Deque Systems</a>
<a href="https://www.deque.com/">Home</a>

テストが通過する例

<a href="https://www.deque.com/">Deque Systems</a>
<a href="https://www.deque.com/">Deque Systems</a>

ルール3: landmark-no-duplicate-main

文書がmainランドマークを2つ以上持っていないことを確認します。このルールは、エラー報告内容をより良くするためにlandmark-one-mainから分離されました。このルールは新しい問題を報告しません（訳注：これまでlandmark-one-mainとして報告されてきた内容が報告されます）。

テストが失敗する例

<main>Main 1</main>
<main>Main 2</main>

テストが通過する例

<main>Main 1</main>

ルール4：no-autoplay-audio（実験的）

<video>と<audio>が、音声を停止したりミュートする方法を提供せずに、3秒を超えて音声を自動再生しないことを確かめます。このルールは実験的でアーリーアダプター向けの拡張機能axe coconutで利用可能です。Axe-core APIを使って実験的なルールを実行する場合は、runOnlyオプションに"experimental"タグを指定してください。

テストが失敗する例

<audio src="path/to/audio/duration20s.mp3" autoplay></audio>

テストが通過する例

<video src="path/to/video/duration20s.mp4" autoplay controls></video>

非推奨のテンプレート言語

翻訳とカスタムルールにこれまで使用してきたテンプレート言語は非推奨になりました。新しいテンプレートフォーマットを使うことで、Axe-coreはより厳格なContent Security Policyのもとで実行できるようになります。これまで使用してきたフォーマットは次のメジャーリリースでは利用できなくなります。カスタムルールや翻訳者は半年以内に新しいテンプレート言語へアップグレードすることを強く奨めます。詳しい情報はメッセージテンプレートのドキュメントをご覧ください。

非推奨のルール

aria-dpub-role-fallbackとlayout-tableルールは非推奨になり、以前のリリースで追加されたルールに置き換えられています。今回これらのルールは標準で無効になり、次のメジャーリリースでは利用できなくなります。

その他の変更

  • 新しいデンマーク語の翻訳：Daniel FreilingとMarianne Gulstad Pedersenの貢献に感謝します
  • td-has-headersのパフォーマンス向上
  • regionとlandmark-*ルールはページ全体を1個の問題として報告するのではなく個々の要素ごとに問題を報告するようになりました
  • meta-viewportはWCAG 2.0の不適合ではなくベストプラクティス（best-practice）となりました
  • role属性に関するいくつかのルールにおけるエラーメッセージの改善

全ての変更点の一覧はAxe-coreの変更履歴をご覧ください。

Deque製品での展開

Axe-core 3.5リリース版はWorldSpace Attest、Assure、Comply、axe Proでまもなく利用可能になる予定です。

パーマリンク

2019年末に更新されたWAI-ARIA 1.2について

アクセシビリティ・エンジニア 中村（直）

旧聞ではありますが、技術評論社様に寄稿した2020年のWebアクセシビリティでも取り上げたように、WAI-ARIA 1.2（参考日本語訳）が前のWorking Draft（作業草案）からちょうど1年後の日付（2019年12月18日付け）で更新されていました。ここでは変更点について見ていきたいと思います。

まず、ARIA仕様の中身そのものの変更ではありませんが、参考文献に挙げられているHTMLの参照先がHTML Living Standardに差し替えられています。WHATWGとW3Cとの合意（参考：昨年5月のW3C News）を受けての変更ですが、合意が着実に履行されているのだなと感じました。

さて、中身についてですが、前回のWorking Draft（作業草案）からの変更点は、Substantive changes since the last public working draftというセクションにまとめられています。しかし、1年ぶりの更新と言うこともあって、かなりの量になっています。

ところで、このWorking DraftのStatus of This Document（この文書の位置づけ）では、次のような文が記載されています。

Feature development for this version is complete, and this is a wide review draft published to obtain feedback before finalization of the spec.

ARIA 1.2の開発は完了していて、フィードバックを受け付けるためのWorking Draftだとうたっていると言えるでしょう。Status of This Documentの続きには、特にフィードバックが欲しいとされるARIA 1.1からの新規・変更機能が列挙されていますので、ここではそれらの機能を順に見ていきたいと思います。新規のロールとしては、

  • blockquote
  • caption
  • code
  • deletion
  • insertion
  • meter
  • paragraph
  • subscript
  • superscript
  • time
  • generic

が挙げられています。最後のgenericロールは、ユーザーエージェント実装者向けのロールとされているので特殊な立ち位置ですが、それ以外はすべて、HTML仕様の要素に新たに対応するロールを追加したものです。なお、これらの新しいロールはすでに存在しているHTMLの要素でこと足りるわけですから、Web制作の現場においてまず使うことはありません。

話が少し脇道にそれますが、上に挙げたロールの中には、timeロールが見えます。これはHTMLのtime要素に対応するロールでありますが、ロールtimeには次のような注があります。

At the present time, there are no WAI-ARIA properties corresponding to the datetime attribute supported on <time> in [HTML]. The addition of this property will be considered for ARIA version 1.3.

time要素のdatetime属性に対応したWAI-ARIAのプロパティは、ARIA 1.2には存在しない旨が記載されています。これは、ARIAの観点からロールで特定の時刻や日付を表すことが現時点ではできる一方で、それがどのような日付なのか、あるいは時刻なのかといったことが表現できない、ということになります。datetime属性に対応したWAI-ARIAのプロパティはARIA 1.3で追加される予定とのことですので、しばらく時間がかかりそうです。

プロパティに触れたところで、グローバルなステートおよびプロパティについても触れられています。aria-disabledおよびaria-invalidの2つステートと、aria-errormessageおよびaria-haspopupの2つのプロパティがグローバルなステートおよびプロパティから削除されていることが記載されています。グローバルなステートおよびプロパティではなくなるということは、特定のロールとの組み合わせのみで使用できるように変更されたことを意味します。

また、aria-expandedステートとcomboboxロールに大幅な変更がされていることも記載されています。詳細については、仕様を参照ください。最後に、ARIA IDLセクションが挙げられています。（フロントエンドBlogのあのWAI-ARIAがIDL属性として実装される！？も参照ください）

Status of This Documentに列挙されている内容は以上になります。今回のWorking Draftに対するフィードバックについては、具体的なフィードバック期間の記載がありませんが、もし仕様に何か思うところがあれば、W3C ARIAのGitHubリポジトリーにコメントしてみてはいかがでしょうか。

パーマリンク

2020年のWebアクセシビリティ

取締役 木達

gihyo.jpの新春特別企画の一環で、「2020年のWebアクセシビリティ」という記事を、当社アクセシビリティ・エンジニアの中村直樹さんが寄稿しました。昨年まで6年連続で同企画に寄稿してきた黒澤さん（同じく当社アクセシビリティ・エンジニア）に代わっての寄稿となります。是非ご一読いただければと思いますが、内容の紹介がてら記事中の見出しを以下に列挙します。

  • Web Content Accessibility Guidelines（WCAG）2.2
  • WAI-ARIA 1.2
  • Webブラウザーのビルトイン機能
  • 国内支援技術の動向
  • 国交省ガイドライン

少しばかり個人的な感想を書かせていただきますと、同記事で私がまず気になったのが、WCAG 2.2に関する言及です。

新規の達成基準の候補については，Potential WCAG 2.2 SCsというタイトルのGoogleスプレッドシートに挙げられており，17の達成基準の候補が挙げられています。WCAG 2.0からWCAG 2.1では達成基準が17増えたわけですから，最大で同規模の分量となることが見込まれます。

達成基準のさらなる充実（追加）は、ユーザーや利用状況の多様性に対し私たちWeb制作者が理解を深め、Webコンテンツをよりアクセシブルにするうえで大変喜ばしいことです。しかしそのいっぽう、新たな達成基準の検証方法をどうするか、検証にかかる時間的・金銭的コストとどう向き合うかなど、悩ましい側面があるのも事実。

その辺りはユーザーエージェントや支援技術、そして検証ツールの進化と歩調を合わせながら、現実的な対応を模索し続けたいところです。誤解を恐れずに言うなら、ガイドラインはガイドラインに過ぎません。WCAGにどこまでどう従うかは、利用する私たちの側に委ねられているのですから。

またWAI-ARIAについては、バージョン1.2の勧告に向けた状況が、記事で紹介されていました。WAI-ARIAは、高度で複雑なWebアプリケーションにとっては特に必要不可欠な存在となって久しく、その充実もまたWCAG同様、Web制作者にとってありがたいもの。ですが、個人的にはMarco Zehe氏が先月お書きになった記事「Call to action: HTML needs more native rich widgets - Marco's Accessibility Blog」の

We should move away from the "ARIA will fix it" mentality and put more effort into "Let's give web authors more accessibility out of the box for richer components", so those sad figures of 97% of inaccessible sites will hopefully drop to a much more satisfactory number in the next five years.

というくだりに賛同します。WAI-ARIAに頼ることなく、ネイティブなHTML要素で必要な実装が実現できればそれに越したことはないわけで......道のりは容易ではないでしょうが、（WAI-ARIAのみならず）HTML仕様の今後の充実にも期待し、また可能な範囲で協力もしていけたらと思いました。

パーマリンク