LINEヤフーにおけるこれからのアクセシビリティというスライドで「WCAGはハードルが高い」という文言を見かけました。どうしてハードルが高い、言いかえるならば難しいとされるのか、その難しさはどこから来るのかをちょっと深掘りしてみようと思います。 WCAGという言葉について、改めて見ておきましょう。WCAGはもっぱら、Web Content Accessibility Guidelines（ウェブコンテンツアクセシビリティガイドライン）というW3Cの発行する技術文書を指すわけですけども、現時点でよく参照されるのがウェブアクセシビリティ基盤委員会（WAIC）が公開している日本語訳のWCAG 2.1でしょう。ちなみに本家のW3Cは、WAICが現時点で公開しているWCAG 2.1の改訂版を今年9月に公開し、さらにバージョンの進んだWCAG 2.2を先月に発行したばかりだったりします。 WCAG 2

まえがき W3C（とWHATWG）からの公式なアナウンスはまだ確認していませんが、何度目かに結成されるW3C HTML WorkingのDraft Charterと、このCharterから辿れるDRAFT Memorandum of Understanding Between W3C and WHATWG（Memorandumは日本語で覚書などと訳されるので、ここでも覚書と呼びます）がブログエントリーのタイトルのソースになります。もっとも、今確認できる覚書もドラフトですから、変更があるかもしれません。しかしながらURLで観測できるわけですから、大筋でW3CとWHATWGとの間で合意が取れているのではないかと推測します。あとは、覚書だけでなくCharterもドラフトということになっていますが、以下の文章では面倒なので省略します。最後にお約束ですが、このブログエントリーは「だいたいあってる」感

さよならレガシーエンコーディング。 文字エンコーディング宣言が存在するかどうかにかかわらず、文書のエンコードに使用される実際の文字エンコーディングはUTF-8でなければならない。 4.2.5.5 文書の文字エンコーディングを指定する - HTML Standard 日本語訳 Require utf-8 when specifying character encoding by sideshowbarker · Pull Request #3091 · whatwg/htmlにより、HTMLで使用できるエンコーディングはUTF-8のみとなりました。これにより、古いHTMLでは許容されていた、Shift_JIS、ISO-2022-JP、EUC-JP、UTF16LEといった文字エンコーディングは適合するHTMLではなくなりました。すでにNu Html CheckerでUTF-8以外の文字エンコー