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

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

WAICによるWCAG 2.2日本語訳が公開

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

WAICのニュースのとおり、WCAG 2.2日本語訳が公開されました。

WCAG 2.2はどういったものなのか...というのは当Blogで折に触れて紹介してきましたので改めての説明はしませんが、WCAG 2.2の中ではWCAG 2.1 との比較のセクションで説明されています。

さて、WCAG 2.2を理解するのにあたって必携ともいえるUnderstanding WCAG 2.2については、現在、筆者も所属しているWAICの翻訳ワーキンググループで翻訳の着手が行われたところです。WCAG 2.1と同様に、「WCAG 2.2解説書」として今後公開されていく見込みです。

「WCAG 2.2解説書」がいつ頃公開されるのかについては今のところ、はっきりとしたスケジュールはありません。ただし、WAICのお知らせをたどっていくと、WCAG 2.1の翻訳を公開したのが2019年6月WCAG 2.1解説書を公開したのが2020年3月という実績があります。WCAG 2.1では9カ月かかっていたことから、年内に公開されるかもしれない、という予想は立てられそうです。

一方で、たとえばWCAG 2.2で新たに加わった達成基準について先行して翻訳・公開するというような手段をとることによって、「WCAG 2.2解説書」を前倒しで公開できないかというような検討も翻訳ワーキンググループではされています。筆者個人としても「解説書」を切望するところではあり、なるべく早くに公開できるように翻訳作業に取り組んでいきたいと思う次第です。

セミナー「改正障害者差別解消法とWebアクセシビリティ」の録画を公開

エグゼクティブ・フェロー 木達

あらかじめセミナーレポートで予告していましたが、本日付けで発行したニュースリリースにありますように、1月18日に開催したセミナー「改正障害者差別解消法とWebアクセシビリティ」の録画を公開しました。

ミツエーリンクスでは通例、セミナー開催後に実施するアンケートにご回答いただいた皆様に限り、期間限定でセミナー録画を振り返り視聴していただく機会をご提供しています。

本セミナーについては、2024年4月1日に施行が迫る改正障害者差別解消法への興味・関心の高まりを受け、特別にその録画(質疑応答を除く約40分)を公開するものです。

セミナー「改正障害者差別解消法とWebアクセシビリティ」2024年1月18日開催

セミナーのなかで紹介しているWebページへのリンクを、セミナーアジェンダに沿って以下に提供いたします:

  1. 障害者差別解消法とは
    1. 障害者の権利に関する条約(略称:障害者権利条約)|外務省
    2. 障害を理由とする差別の解消の推進 - 内閣府
    3. 合理的配慮等具体例データ集(合理的配慮サーチ):障害者制度改革担当室 - 内閣府
    4. 障害者の差別解消に向けた理解促進ポータルサイト
  2. 改正障害者差別解消法のポイント
  3. 障害者差別解消法とWebアクセシビリティ
  4. Web担当者の皆様へ
    1. アクセシビリティ オーバーレイに対する見解 | コラム | ミツエーリンクス
    2. 「TechFeed Experts Night#1」に登壇 | イベント・講演 | ミツエーリンクス
    3. 続・障害者差別解消法の改正とWebアクセシビリティ | コラム | ミツエーリンクス
  5. 関連サービスのご紹介
    1. アクセシビリティ ソリューション | ソリューション | ミツエーリンクス
    2. Webアクセシビリティ コンサルティング | アクセシビリティ | ミツエーリンクス
    3. アクセシビリティ社内教育支援 | アクセシビリティ | ミツエーリンクス
    4. ウェブコンテンツ・アクセシビリティ・ガイドライン(WCAG)2.2への標準対応の開始について | ミツエーリンクス
    5. Webアクセシビリティ入門セミナー 2024 | セミナー | ミツエーリンクス

Interop 2024に見るアクセシビリティ

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

フロントエンドBlogにInterop 2024がスタートという記事が先日掲載されましたが、ここでは重点分野として加わったアクセシビリティに関して深掘りしてみたいと思います。

アクセシビリティに関しては、WebKitが詳細に、Bocoupが端的に、Mozillaが軽く触れています。もちろんInterop 2024のREADMEにも記載されていますが、これらをまとめ直してみるとおおよそ次のようになります。

アクセシビリティは、既にInterop 2023では調査分野として取り上げられていました。以前のアクセシビリティBlogの記事ARIAを取り巻く2つの自動テストでも触れていましたが、Appleのアクセシビリティチームが主導して、執筆現在では1300を超えるアクセシビリティテストが作成されており、Interop 2024では重点分野としても組み込まれるに至っています。

細かくは3つの領域が挙げられています。1つ目は、アクセシブルな名前と説明の計算(accname)です。わかりやすい例としては、<label>で計算される名前でしょうか。より詳しくはARIA APGにあるAccessible name calculationを参照してもらえればと思いますが、この名前の計算結果がすべてのブラウザーで同じように得られるように取り組んでいくとのことです。

2つ目は、計算されたロールです。HTML-AAM仕様、もう少し大ざっぱにいえばARIA in HTML仕様のとおりにHTMLの要素が提供されるときに計算されたロールを持っているかどうかについて、1つ目と同様に取り組んでいくようです(例としてwpt/html-aam/rolesのテストが挙げられます)。

最後の3つ目は、display: contentsが挙げられています。おそらくCSSグリッド(あるいはフレックスボックス)と組み合わされることが多いと思われるCSSプロパティの値ですが(具体例はMDNのグリッドレイアウトと他のレイアウト方法との関係 - グリッドと display: contentsがわかりやすいでしょう)、display: contentsによって直接の子要素が削除されると、アクセシビリティツリーからすべての子孫が削除されてしまうというバグがブラウザーに存在しています(これは仕様とは異なる挙動です)。その結果、視覚的には表示されているものの、スクリーンリーダーでは読み上げられないという問題が発生します。これに関するテストを作成することで、相互運用性を高める布石にするとのことです。

個人的には、アクセシブルな説明(aria-describedby属性であったりtitle属性であったり)の整備や、<dl>(そして<dt><dd>)のロールの計算の議論が加速するのかどうかといったあたりが気になるところではあり、Interop 2024を通して相互運用性が高まることに期待したいところです。

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

エグゼクティブ・フェロー 木達

月日がたつのは早いもので、1月の最終日を迎えましたが、年初に当社アクセシビリティ・エンジニアの(そして本Blogの著者の一人としておなじみの)中村 直樹がgihyo.jpに寄稿させていただいた「2024年のWebアクセシビリティ」は、皆様すでにお読みいただけたでしょうか?

見出しだけ抜き出しますと、以下のような構成で2023年のWebアクセシビリティに関連する出来事を振り返りつつ、2024年のWebアクセシビリティを展望しています。まだ読んでいなかった!!という方は、ぜひこの機会にチェックしてみてください。

  1. WCAG 2.2の勧告とWCAG 2.1の更新
  2. WCAG 3.0
  3. JIS改正の動向について
  4. 情報アクセシビリティ自己評価様式​
  5. 改正障害者差別解消法の施行とガイドライン
  6. PDFのアクセシビリティ

最初の話題として取り上げられているWCAG 2.2については、2.1に対して追加された9つの達成基準のうち、2つのみをピックアップし掘り下げています。「JIS改正の動向について」のなかで触れられているように、ウェブアクセシビリティ基盤委員会(WAIC)が目下、WCAG 2.2の翻訳を進めているとのこと。早期の公開を期待したいと思います(実を言うと私も委員会活動には参加しているものの、作業部会4(翻訳)には所属しておらず......)。

記事は、2カ月後に改正法の施行が迫った障害者差別解消法にも触れています(「改正障害者差別解消法の施行とガイドライン」)。文中にあります、ウェブアクセシビリティを含む情報アクセシビリティは「環境の整備」であり、法的な位置付けが改正法によって変化することはないという点は、しっかり認識しておきたいポイントです。余談ですが、私が先日講師を務めたセミナー「改正障害者差別解消法とWebアクセシビリティ」の録画の公開を現在準備中です。

最後の話題として取り上げられている「PDFのアクセシビリティ」については、私自身初めて知る内容も多く、勉強になりました。関連して、昨年12月の「アドビ、「PDFファイルのアクセシビリティに関する調査」の結果を発表」を合わせてお読みいただくと一層、興味深いかと思います。私の実体験として、Adobe Acrobatを用いたPDFファイルのアクセシビリティ向上はそこそこ手間がかかる認識なのですが、アドビ社の調査結果を拝見しますと、思っていたよりアクセシビリティ機能は利用されている印象を受けました。

WAI-ARIA 1.3の初回公開作業草案が発行

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

個人的にはもっと先になるのではと思っていたのですが、W3Cのニュースにあるように、WAI-ARIA 1.3のFirst Public Working Draft(初回公開作業草案)が発行されました。

さっそくですが、WAI-ARIA 1.2からの変更点を眺めていきましょう。

Change LogMajor feature in this releaseのセクションでは、commentmarksuggestionという3つのロールが追加されたことがわかります。また、aria-*属性はaria-braillelabelaria-brailleroledescriptionaria-descriptionという3つが追加されているのがわかります。さらに、aria-details属性が複数の要素と関連付けることが可能になったとあります。

追加された3つのロールは、ARIA annotationsと呼ばれる、編集提案やコメントのためのロールです。詳細については、MDNのARIA annotationsが詳しいです。

aria-braillelabelaria-brailleroledescriptionはそれぞれ、aria-labelaria-roledescriptionの点字バージョンの属性です。aria-descriptionは、aria-labelのアクセシブルな説明(accsecible description)バージョンの属性です。WAI-ARIA 1.2ではaria-labelledbyaria-describedby、そしてaria-labelが既に定義されていたわけですが、今回の更新でaria-descriptionが定義されるようになりました。aria-descriptionがこれまでなかったのはいわれてみると不思議ではあります。

その他の変更点としては、Substantive changes since ARIA 1.2のセクションで実に95もの項目が挙げられており、数が多すぎてわかりにくいのですが、パッと目に付いた変更点を挙げてみますと、

  • imageロールがimgロールの同義語として導入されました。ARIAロールのほとんどが省略されていない単語からできており、誤ってimageを指定する可能性があります。imageを指定した場合でもimgロールに解釈されるようになります。(#1370
  • Required Owned ElementsをAllowed Accessibility Child Rolesに、Required Context RoleをRequired Accessibility Parent Roleに変更しています。大雑把ではありますが親子関係を連想しやすくなったといえます。(#1454
  • aria-levelに関する注記が追加されています。HTMLが見出しレベル6までであることから、6までは問題なくサポートされる一方で、ほとんどの実装はレベル9までサポートしていることに言及しています。これはMS Wordが見出しレベル9まで設定できたと記憶しており、そのことが関係すると理解しています。(#1873
  • Change Logになぜか記載がされていないのですが、aria-rowindextext属性とaria-colindextextが追加されています。(#994)これは、スプレッドシートのようにA列、B列というような情報の設定を可能にします。
  • こちらもChange Logに記載はされていませんが、単語mayが整理されています。(#1901)RFC 2119キーワードではない箇所で紛らわしいことから、mightやcanに置き換えがされています。

目に付いたものをざっくりと挙げてみましたが、細かな箇所の変更も多数見て取れ、差分を取ってじっくり見てみるのがよいのかもしれません。

「WCAG 2.2 解説セミナー」でお寄せいただいたご質問への回答

エグゼクティブ・フェロー 木達

去る12月14日、オンラインで開催したWCAG 2.2 解説セミナーには、大変多くの方々にご参加いただきました。この場を借りて厚く御礼申し上げます。また、質疑応答の時間ではすべてのご質問に回答することができず、申し訳ございませんでした。

本記事では、参加をお申し込みいただいた際に寄せられた質問(ただしセミナー時間中に回答できたものは除く)や、開催後にアンケートへのご回答を通じてお寄せいただいた質問への回答を、掲載させていただきます。WCAG 2.2とは関連性の低いご質問にもお答えしておりますが、回答にご満足・ご納得いただけない場合には、ぜひお気軽にお問い合わせをいただければ幸いです。

アクセシビリティは何をどこまでやればよいのか

一律の正解はございません。個人的には最低限、WCAG2で適合レベルAの達成基準を満たすよう取り組んでいただきたいと思いますが、アクセシビリティ品質をそれ以上どこまで求めるかは取り扱う製品やサービス、組織の規模や成熟度、市場環境などを総合的に勘案のうえ定義する必要があるかと思います。ご相談いただければ当社のコンサルティングサービスのご提供が可能です。私は、目指すべきアクセシビリティ品質の高低よりむしろ、取り組みの継続性こそ大切ではないかと思います。セキュリティと同じく、Webサイトを運営し続ける限り、常にコンテンツのアクセシビリティ確保に取り組んでいただく必要があると、ご理解いただけたら幸いです。

ウェブアクセシビリティは今後も継続的に取り組む課題という認識。組織の体制として、専任を設けた方が良いのか?どのような体制が望ましいのか。

組織の規模が大きいようであれば、専任の方がいらっしゃったほうが、取り組みを推進しやすいと思います。そして、規模がそれほど大きくなく専任担当者の設置が難しい場合、兼任であっても誰かしら組織内で「わかりやすい」旗振り役がいらっしゃったほうが、望ましいと私は考えます。専任であれ兼任であれ、大切なのは組織内でWebサイトにかかわるすべての担当者の方々と調整や分業できるよう、連携のための横串をしっかり通すことだと思います。そうした組織横断的な横串組織を構成することが、体制的には望ましいと考えます。

来年法改正に向けた優先課題、企業の取り組みについての進め方を知りたい。

ご質問は、いわゆる障害者差別解消法についてのものと理解します。本セミナーはWCAG 2.2のご紹介に特化した、時間の比較的短いセミナーですので、改正障害者差別解消法への言及は控えさせていただきました。年明け、1月18日にそれに特化したセミナーを開催しますので、よろしければそちらへの参加をご検討いただければと思います。あわせて、コラム「続・障害者差別解消法の改正とWebアクセシビリティ」をお読みいただけますと幸いです。

3.3.8や3.3.9の代替手段というのは、ICTを用いた代替手段以外(例えば電話や対面など)でもよいのでしょうか?(すべてオンラインで解決しなくてもよいのか、ということが知りたいです)

WCAGはあくまでWebコンテンツのアクセシビリティについてのガイドラインであり、達成基準3.3.8や3.3.9で言及されている代替手段とは、オンラインで実現可能な代替手段と認識しています。もちろん、Web以外の媒体を介した手段を提供できれば、そのほうが総じて望ましいとは思いますが(障害者差別解消法でいうところの「合理的配慮」に相当し得ます)、その存在が当該達成基準の適合・不適合の判断には影響しない認識です。

支援技術がブラウザと協調するものが多くなってきている中、「フォーカス外観の調整」は支援ツールでもあるでしょうし、「冗長な入力」はブラウザに保存機能がありますが、サイト側で独自対応することは、アクセシビリティ・オーバーレイにならないのでしょうか?

アクセシビリティ オーバーレイについては、コラム「アクセシビリティ オーバーレイに対する見解」で紹介したように、サードパーティのスクリプトを読み込むことで画面表示のカスタマイズなどを行うUIを提供するもの、という認識です。コンテンツを提供する側が主体的にアクセシビリティを高める施策とは、基本的に異なります。

EAA(欧州アクセシビリティ法)ですが、WCAG 2.2のAAに準拠していれば問題ないと考えて大丈夫でしょうか?EU各国の法整備は、まだまだこれからだと思いますが。

何をもってして「問題ない」とするかは、判断の難しいところかと思います。しかし、2025年にはEN 301 549規格が更新、WCAG 2.2が組み込まれることが予想されています。従い、断言はいたしかねますが、今から(WCAG 2.1ではなく)WCAG 2.2に基づく対応を検討することは、有意義かつ有効ではないでしょうか。Web Accessibility Directive -- Standards and harmonisation | Shaping Europe's digital futureを参照いただいて、今後の方針をご検討いただけたらと思います。

2.4.11隠されないフォーカスについて。満たしている参考になるサイトがあれば、教えていただきたいです。またアクセシビリティ対策で素晴らしいサイトも知りたいです。

基本的にスティッキーヘッダーやスティッキーフッター、ダイアログといった、コンテンツの一部を覆い隠してしまう可能性のあるUIがページ中に存在しないページであれば、達成基準2.4.11に適合しているはずです。アクセシビリティ対策で素晴らしいサイトにつきましては、具体的な例示はご容赦願えればと思います。

今後アクセシビリティ対応への重要性が増してくると思いますが、アクセシビリティエンジニアの育成・教育プログラムやアクセシビリティエンジニア認定制度のようなサービスについては、提供のご予定はないでしょうか?

当社独自に、というかたちでは、お書きいただいているようなサービスを提供する予定はございません。しかし、アクセシビリティ社内教育支援の一環として、個別に人材育成や教育をご支援することは可能です。もし具体的なニーズなりお困りごとがございましたら、ぜひお気軽にご相談ください

3.3.7を達成するには具体的にどのような技術が必要となりますでしょうか?

達成基準3.3.7に適合するためには、ユーザーが一度入力した情報について、(同達成基準において例外としているケースを除き)再入力が必要とならないよう、サービス提供側で適切に保存・管理のうえ、活用できるようにする必要があります。Understanding Success Criterion 3.3.7: Redundant Entryや、G221: Provide data from a previous step in a processをぜひご覧ください。

線形化(一本の線)とはどのようなページになりますでしょうか?

ご質問は、達成基準3.2.6(一貫したヘルプ)に関するものと認識します。私の説明が言葉足らずで申し訳ございませんでしたが、HTMLソースに記載された順にコンテンツが並んだ状態を「線形化」と呼んでいます。線形化した状態の並びは、HTMLソースを読み解かずとも、WebブラウザでCSSを無効化することで視覚的に確認が可能です。また、合成音声でコンテンツを読み上げるスクリーンリーダーを使いますと、線形化した状態でコンテンツを聞くことができます。

アクセシビリティガイドラインを無視したコンテンツの法的措置や社会的な制裁等が有ればご教示頂きたいと存じます。

日本では、Webアクセシビリティの不足そのものを罰するような法律は存在しない認識でおり、社会的な制裁についても同様です。しかし、来年4月1日の改正障害者差別解消法の施行に伴い、例えばWebアクセシビリティの不足に関し合理的配慮を提供しなかった事業者が、指導や勧告を受ける可能性はあります。また、その合理的配慮の提供義務違反が広く報道されるなどすれば、それが社会的な制裁につながる可能性もあるかと思います。

WCAG 2.1勧告(2023年版)の日本語訳の更新

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

WAIC(ウェブアクセシビリティ基盤委員会)からアナウンスされたように、2023年に更新されたWCAG 2.1勧告の日本語訳が公開されました。

筆者も参加しているWAICの翻訳ワーキンググループでは、今後にWCAG 2.2日本語訳を公開していくにあたり、翻訳精度の向上を目的に、漸次的に日本語訳の見直しを行っています。それに伴い、WAICの過去のお知らせ(2023年3月2023年8月)にもあるように、WCAG 2.1日本語訳の当初の公開からいくつかの達成基準について翻訳が修正されています。そのうち、以下の達成基準の名称が変更されています。

  • 達成基準1.3.2の名称"Meaningful Sequence"を「意味のある順序」から「意味のあるシーケンス」に
  • 達成基準2.5.3の名称"Label in Name"を「名前 (name) のラベル」から「ラベルを含む名前 (name)」に
  • 達成基準2.5.6の名称"Concurrent Input Mechanisms"を「入力メカニズム非依存」から「入力メカニズムの共存」に
  • 達成基準3.3.4および3.3.6の"Error Prevention"を「エラー回避」から「誤り防止」に

WCAG 2.2日本語訳については、今回公開されたWCAG 2.1の日本語訳での変更を取り込みつつ、既に翻訳作業に着手しているところです。個人的な希望としては、来年の早い時期にはWCAG 2.2の日本語訳の公開にこぎつけたいと思っているところです。

最後に、WAICでは翻訳文書に関するフィードバックを常時受け付けています。お気付きの点がありましたらGoogleフォーム翻訳に関するお問い合わせにご連絡いただければと思います。