ガイドライン4.1 互換性の概要
ゆみこ：こんにちは。チャコウェブラジオは、株式会社Cyber Catsが運営するチャコウェブのスタッフが、
ウェブアクセシビリティを実践したい制作者やウェブ担当者に向けて、ゆっくりじっくり解説していくポッドキャストです。
進行を担当するゆみこです。よろしくお願いします。
みあ：みあです。よろしくお願いします。
ゆみこ：本日のテーマは、WCAG 2.0 解説シリーズPart22「『ガイドライン4.1 互換性』とその達成基準」です。
みあ：前回までに、WCAGの4つの原則のうち「知覚可能」「操作可能」「理解可能」の3つに関わるガイドライン・達成基準を解説しました。
今回は最後の原則である「堅牢」ついてやっていきたいと思います。
なお、「堅牢」に関するガイドラインは1つのみなので、今回がWCAG 2.0 解説シリーズの最終回となります。
ゆみこ：ついに、この解説シリーズも最後ですね。今回もよろしくお願いします。
みあ：はい、お願いします。
今回紹介するのは、ガイドライン4.1「互換性」です。
WCAG 2.0 解説書には、「現在及び将来の、支援技術を含むユーザエージェントとの互換性を最大化すること」とあります。
簡単に言うと、制作したウェブコンテンツが現在だけでなく将来的にも支援技術などで利用できるように、ウェブコンテンツとユーザーエージェントの間で互換性を保とう、というものです。
ゆみこ：ウェブコンテンツが長期的にユーザーエージェントで利用できるように、互換性を確保するためのガイドラインなんですね。
みあ：はい、そうなんです。互換性を保つためには大切なことが2つあります。
1つ目は、ウェブコンテンツを作るとき、支援技術の動作を妨げたり、使いにくくしてしまうようなマークアップやコードの書き方をしないことです。
2つ目は、支援技術が情報を認識してやり取りできるように、標準的な方法でウェブコンテンツの情報を公開することです。
ゆみこ：なるほど、この2つが重要なんですね。支援技術の動作を妨げたり、使いにくくしてしまうようなマークアップをしないというのが大切なのは理解できます。
もう1つの、標準的な方法でコンテンツの情報を公開する必要があるのはどうしてでしょうか。
みあ：それは、支援技術が新しい技術にスムーズに対応していけるようにするためなんです。
ウェブに関する技術は日々急速に変化していて、支援技術の開発者がこの変化についていくのは本当に難しいものです。
だからこそ、支援技術が新しい技術にスムーズに対応できるよう、標準的な方法でコンテンツの情報を公開し、ソフトウェアなどと情報をやり取りできる状態を確保しておくことが重要なんです。
ゆみこ：うーん、なるほど。標準的な方法で情報を公開することで、ソフトウェアなどと円滑に情報がやり取りできるんですね。
そしてそれが、支援技術が新しい技術にスムーズに対応できることにつながるんですね。
達成基準の具体的な解説
みあ：はい、その通りです。
ゆみこ：それでは、具体的な達成基準について教えてください。
みあ：はい。まず最初の達成基準は、4.1.1「構文解析」です。
解説書には「マークアップ言語を用いて実装されているコンテンツにおいては、要素には完全な開始タグ及び終了タグがあり、要素は仕様に準じて入れ子になっていて、要素には重複した属性がなく、どのIDも一意的である。
ただし、仕様で認められているものを除く」と書かれています。
これは、マークアップ言語を用いてウェブコンテンツを制作する際には、開始タグ、終了タグを必ずつける。要素の使い方は仕様通りにする。
1つの要素に同じ属性を付けたり、同じIDがひとつのウェブページに複数回出てこないようする、というように、適切なマークアップを行いましょうという達成基準です。
適合レベルはAです。
ゆみこ：マークアップにおけるさまざまなルールを守る必要がある、ということですね。どうしてそうする必要があるんでしょうか?
みあ：それは、ブラウザや支援技術などのユーザーエージェントで、ウェブコンテンツが正しく理解・表示されるようにするためです。
タグの閉じ忘れがあったり、属性の書き方が間違っていたりすると、ブラウザは、ブラウザや支援技術がコンテンツを正しく理解できません。
ユーザーエージェントによっては、自動的に修正してくれるものもありますが、修正の仕方はそれぞれで異なります。
そのため、ブラウザごとに違う表示になったり、場合によってはまったく表示されない可能性があるんです。
ゆみこ：うーん、同じコンテンツなのに、ブラウザごとに表示がバラバラだったり、表示されなかったり、それはとっても困りますね。
みあ：そうですよね。ですから、仕様に沿った適切なマークアップをすることが重要になります。
ゆみこ：仕様に沿ったマークアップとはどのようなものでしょうか？
みあ：ポイントは3つです。
1つ目は、「仕様にない方法は使わない」です。
HTMLでは、使えるタグや属性が決められていて、このようなものはブラウザや支援技術が正しく処理できるようになっています。
しかし、仕様にない方法を使うと、一部のブラウザでは表示できても、他のブラウザや支援技術では正しく動かないことがあります。
また、支援技術の中には新しい技術への対応に時間がかかるものもあり、アクセシビリティの問題が起こる可能性があります。
そのため、HTMLの仕様にない使い方は避けるべきです。
2つ目は、「HTMLの適切な使い方を守る」です。
HTMLの仕様では、要素をどのように使うべきかが決められています。
いわゆる、セマンティックHTMLです。
しかし、中には見た目を調整するために本来の意味と異なる使い方をしている場合があります。
そうすると、支援技術が正しく情報を読み取ることができない可能性があります。
そのため、HTMLの各要素は、決められた意味通りに使うことが大切です。
3つ目は、「正しく解析できるようマークアップする」です。
ブラウザや支援技術がHTMLを正しく処理するには、タグの開始・終了、属性の書き方、要素の入れ子のルールなどを守る必要があります。
このようなHTMLのルールに従ってコーディングすることで、どの環境でも正しく表示・動作するコンテンツを作ることができます。
ゆみこ：なるほど、とにかく適切な使い方が重要になってくるんですね。
ただ、これらをすべて目視でチェックするのは大変ですよね。何かいい方法はありませんか?
みあ：目視でのチェックが必要な場合もあるので、すべてを網羅できるわけではありませんが、W3Cのバリデーターを使用するのがおすすめです。
タグの閉じ忘れや構文エラーを見つけるのにとても役立ちます。
ゆみこ：そうなんですね。これは積極的に活用していきたいですね。
みあ：続いては、達成基準4.1.2「名前（name）・役割（role）及び値（value）」です。
互換性の必要性
みあ：解説書を確認すると、「すべてのユーザインタフェースコンポーネント（フォームを構成する要素、リンク、スクリプトが生成するコンポーネントを含むがこれに限定されない）
では、名前（name）及び役割（role）は、プログラムによる解釈が可能である。
又、状態、プロパティ、利用者が設定可能な値はプログラムによる設定が可能である。
そして、支援技術を含むユーザエージェントが、これらの項目に対する変更通知を利用できる。」と記述されています。
少し簡単な表現にすると、
・フォームの要素やリンクといったユーザーインターフェースコンポーネントは、名前や役割をプログラムで理解できるようにする必要がある
・さらに、状態や値はプログラムで変更できるようにする必要がある
・そして、ブラウザや支援技術などのユーザーエージェントで、その変更が確認できる必要がある
といった感じです。こちらも、適合レベルはAです。
ゆみこ：うーん、ちょっと難しい内容ですね。
この達成基準は、たしか第37回の最後に少しだけ出てきましたよね。
整理すると、ボタンやリンクなどの名前や役割をプログラムがちゃんと理解できるようにしたり、
プログラムによって状態や値を変更できるようにする必要があるんですね。
そして、何か変更があったときには、支援技術にもその変化が伝わるようにしておくということでしょうか？
みあ：はい、そのような理解で良いと思います。
ユーザーインターフェースコンポーネントがあったとして、
その役割や今の状態が支援技術に伝わらないと、
支援技術を使っているユーザーは困ってしまう可能性が高いんです。
なぜなら、それが何のリンクやボタンなのか分からなかったり、
チェックボックスが選択されているのかどうかを知ることができないからです。
ゆみこ：なるほど。確かに役割や状態がわからないと、
ウェブサイト自体が使えない可能性がありますよね。
だから、支援技術がこういった情報を正確に把握してユーザーに伝えるために、
この基準を満たす必要があるんですね。
達成基準の適合方法
ゆみこ：それでは、この達成基準に適合させるにはどうしたら良いのでしょうか？
みあ：はい。実は、HTMLのボタンやリンクなどの標準的なコントロールを使う場合は、
この基準を簡単に満たせます。
ボタン部分にはbutton要素、リンク部分にはa要素といったように、
適切に要素を使用するだけで、この達成基準に適合できるんです。
ゆみこ：うん、セマンティックHTMLでのマークアップということですね。
みあ：はい、その通りです。
ただし、独自にボタンやチェックボックスを作る場合は、追加の対応が必要になります。
例えば、div要素やa要素を使って、ボタンのようなものを設置しているウェブコンテンツの場合ですね。
ゆみこ：button要素ではなくdiv要素やa要素でマークアップして、
CSSでボタンのような見た目にしているといった感じのものですね。
みあ：はい、そうです。
そのような場合は、標準のボタンと同じようにフォーカスできるようにしたり、
支援技術にボタンだと伝わるように追加で対応をする必要があります。
そうしないと、キーボードで操作できなかったり、支援技術にボタンだと認識されなかったりするんですね。
ゆみこ：そうなんですね。
そう考えると、標準のコントロールを使用するのが手っ取り早そうですね。
みあ：そうですね。特別な理由がない限り、標準的なHTMLのコントロールを使用するのが、
この達成基準を満たす最も簡単な方法だと思います。
ゆみこ：はい。本日のテーマは、WCAG 2.0 解説シリーズPart22「『ガイドライン4.1 互換性』とその達成基準」でした。
WCAG 2.0 解説シリーズは今回で最後となります。
お聞きいただきありがとうございました。
感想をいただけるととっても嬉しいです。
ハッシュタグ「チャコウェブラジオ」をつけて、ぜひSNS、X（旧Twitter）で投稿してください。
また、概要欄にメールフォームリンクをご用意しています。
ウェブアクセシビリティに対応したい方、チャコウェブにお仕事を依頼したい方やご相談がある方は、お気軽にメッセージをお寄せください。
次回からは別の話題を取り上げていきますので、お楽しみに！
