欧州のアクセシビリティ規格であるEN 301 549 v4.1.1が9月2日付けで正式に公開されました。規格の内容はETSIのサイトで閲覧可能（PDF）です。これは、欧州のアクセシビリティ基準における大きな節目になりますが、3つのタイムラインの第一段階に過ぎません。
第二段階は、EN 301 549 v4.1.1がEU官報（Official Journal of the European Union, OJEU）で掲載されることです。EU官報に掲載されるまでは、EU指令の要求事項を満たしているとみなされる、適合の推定（presumption of conformity）は得られません。EU官報には11月末頃に掲載される見込みです。
第三段階は、EN 301 549 v4.1.1がEU加盟国の国内法で参照されることです。加盟国はいつ遵守を期待するかを定義します。
EN 301 549 v4.1.1への準備は今すぐ始めるべきです。主な理由は次の3つです。
EN 301 549 v4.1.1における最大の変更点は、WCAG 2.2レベルAAの採用です。次の6つの達成基準（リンク先はウェブアクセシビリティ基盤委員会が提供する日本語訳）が追加されました。
「WCAG 2.2レベルAAに適合すること」と「EN 301 549 v4.1.1に適合すること」は同じではありません。EN 301 549にはWCAG以外の要求事項も含まれており、特に通信機能に関する要件が強化されています。
Clause 6（リアルタイム通信）の大幅な改定がされています。主な変更点としては、次の3つです。
コンタクトセンター、ビデオ会議、通話・メッセージング製品などへの影響が大きく、大規模な改修が必要になる可能性があります。
一言でまとめますと、欧州アクセシビリティ指令（EAA）対応の基準としてEN 301 549がv4.1.1に改定され、Web分野ではWCAG 2.2 AAが正式に取り込まれました。欧州市場を対象とする組織は、今すぐ移行計画を立てるべきです。
]]>みんなの公共サイト運用ガイドライン改定に関する研究会のページでは、これまでに開催された会議での配布資料を閲覧することができます。
8月24日開催の配布資料1-1開催要綱（案）では、
８．研究会の成果 研究会での議論を踏まえ令和９年３月を目途に運用ガイドラインの改定を行い、翌年度以降必要な周知啓発を実施する。
とあり、来年（2027年）3月には、新しいみんなの公共サイト運用ガイドラインが公開される見込みです。
資料1-2ガイドラインの改定方針（案）ではさまざまな情報がありますが、大きな方針としては「従来のPDF版のみの形式から、PDF版とHTML版での提供へ変更」されることでしょうか。もっとも、個人的にはあまり分割するイメージが湧かないのですが...。
また、章立て案では「デジタル庁などの資料との使い分けについて」という節が設けられ、ウェブアクセシビリティ導入ガイドブックとの連携も意識されるようになると思われます。内容が整理されることによって、ガイドラインの読みやすさの向上が期待されるところです。
最後に、この研究会には、ウェブアクセシビリティ基盤委員会（WAIC）委員長が有識者として参加しています。WAICを通じてみんなの公共サイト運用ガイドラインの改定に関して意見を述べる機会もあるのではないかと思っているところです。
]]>外国語の中でも、英語は日本語のWebサイトや文書にも頻繁に登場します。今回は、そんな英語を例に、主要なスクリーンリーダーでの音声エンジンの自動切り替えの設定方法と、実際に使ううえでの考え方について紹介します。
NVDAでは、設定の「音声」カテゴリーにある「サポートされている場合自動的に言語を切り替える」をチェックすると、テキストの言語に応じて音声エンジンが切り替わります。なお、切り替え先となる英語の音声エンジンがWindowsにインストールされている必要がありますが、音声エンジンをWindows OneCoreにしている場合、通常は英語の音声エンジンも利用できます。
PC-Talkerでは、英語音声エンジンが標準で搭載されており、設定の「英語音声の設定」で「なめらか読みに英語音声を使用する」をチェックすると、英文や英単語が英語音声で読み上げられます。
iOSのVoiceOverでは、設定 > アクセシビリティ > VoiceOver > 発話サポートから「言語を検出」をオンにすることで、言語に応じて音声エンジンを切り替えられます。切り替え先の言語は、同画面の「ローターの声を追加」から追加しておく必要があり、日本語と英語の両方がある状態にする必要があります。なお、ローターの「言語」から、メインで読み上げる言語を切り替えることもできます。
TalkBackでは、設定 > ユーザー補助 > TalkBack > 設定 > テキスト読み上げの設定 > 設定 > 言語の検出 から、「オフ」「弱」「強」のいずれかを選択でき、「オフ」以外にすることで言語に応じて音声が切り替わります。切り替え先の言語は、「テキスト読み上げの設定」の「言語」から追加しておく必要があります。また、読み上げコントロールの「音声の言語」から、メインで読み上げる言語を切り替えることもできます。
音声エンジンの自動切り替えは、テキストの文字種や、テキストに含まれる言語情報などに基づいて行われます。Webページの場合、参照されるのはHTMLのlang属性です。そのため、設定を有効にしていても、コンテンツ側で言語が指定されていなければ切り替わりません。
なお、私自身は状況によって音声エンジンを使い分けています。ソースコードを確認する際は、記号や英数字の読み上げになじみのある日本語の音声エンジンを使い、長文の英文を読む際は、自然な発音で聞き取りやすい英語の音声エンジンを使っています。自動切り替えは便利な機能ですが、読み上げる内容によっては、あえて切り替えずに読んだ方が理解しやすい場合もあります。
音声エンジンの自動切り替えは、外国語のテキストをスムーズに理解するうえで重要な機能です。ただし、特にWebページ内のテキストについては、ユーザー側の設定だけで完結するものではありません。コンテンツ側で言語が適切に指定されていることも、正しく音声を切り替えるための重要な要素となります。
]]>1つ目は、WCAG 2.2の編集的なエラッタ（正誤表）が発行される見込みというものです。8月17日の投稿で合意形成がなされたことが書かれています。
実際のエラッタの内容については、GitHubのSummer 2026 errata for WCAG 2.1 / 2.2というプルリクエストで確認が可能です。 エラッタの数としては全部で6つあり、そのうち日本語のレベルで変更が入りそうなものは次の2つでしょうか（もちろん編集的な修正になります）。
2つ目は、達成基準 2.4.11/2.4.12の「Focus Not Obscured」（隠されないフォーカス）を「Focused Component Not Obscured」に改名しようという提案です。（7月13日の投稿）
実際のGitHubでの議論はRename Focus Not Obscured SCs to Focused Component Not Obscured #5183で行われています。個人的には変えるとなると日本語としてどう訳すものか...と考えてしまうところですが、さておき、この変更が取り入れられるのであれば、WCAG 2.3が発行されることになるのかもしれません。
3つ目は、WCAG 2のエラッタと更新に関するオンライン会議での議論です。（6月30日の議事録）
この会議では、2つの決議が採択されました。翻訳してみるとこんな感じでしょうか。
ということで、WCAG 2.3があり得ることが示唆されています。WCAG 3との兼ね合いでワーキンググループがどこまでWCAG 2に注力するのかという懸念がありますが、ワーキンググループがWCAG 2.3を視野に入れてメンテナンスするのかどうか、今後も注視していきたいと思います。
]]>改めて本Blogでも周知させていただきますと、私は『「誰でも使える」は「AIにも使える」 人間と機械の両方に読まれるためのアクセシビリティツリー』と題したセッションで、アクセシビリティに関する講演を行います。
大変ありがたいことに、現時点ですでに200名を超える方々に参加登録をいただいています。是非この機会に、アクセシビリティツリーや機械可読性への理解を深めていただけますと幸いです。
AI による検索体験が普及し、主要なWebブラウザがAI機能を搭載、またAIエージェントがWeb上でのユーザーの目的達成を支援する機会が増えつつある昨今。AIエージェントやAI検索が活用できるよう設計・実装するAI対応が、Webコンテンツに求められつつあります。
障害者や高齢者を含む、あらゆるユーザーにとっての利用しやすさを意味するアクセシビリティの向上は、このAI対応に通ずる側面があり、その中心的役割を果たすのが、Webブラウザが構築するアクセシビリティツリーです。
本セッションでは、アクセシビリティツリーとは何か、WebコンテンツにおけるAI対応とアクセシビリティ向上の共通点を紹介し、「誰でも使える」ことで「AIにも使える」Webサイトを構築・運用するためのヒント、AI時代にWebアクセシビリティに取り組む意義をお伝えします。
参加のお申し込みについては生成AI × マーケティング フォーラム 2026のページをご覧ください。
]]>Axe-coreとは、本アクセシビリティBlogの1つ前の記事『Axe-coreの日本語訳の更新』でも紹介しているように、Webページのアクセシビリティ上の問題を検出するためのオープンソースの検査エンジンです。Axe-coreは今や、Google ChromeのDevToolsをはじめ、さまざまなツール/ソフトウェアで利用されています。
Kumar氏は、50億という数字について以下のように記しています。
I am elated to share that Axe-core has just surpassed 5 billion downloads! It's a remarkable number, made all the more so by the fact that it was only a year ago that we were announcing 3 billion Axe-core downloads.
Axe-coreのダウンロード数が50億を突破したことを、大変嬉しく思います。これは驚くべき数字ですが、30億に達したことを発表したのがわずか1年前であることを考えると、その意義はさらに大きなものと言えます。
ダウンロード数について、私は2021年8月に『Deque社のaxe-coreが2億5000万ダウンロードを突破』という記事を公開していましたが、着実に数の増加ペースは上がってきているように感じます。またKumar氏は、Blog記事を以下の言葉で締めくくっています。
ultimately, it's not really about the number of downloads after all. It's the energy behind those downloads. That's what we're celebrating today. Because every time someone downloads Axe-core because they want to make something accessible, that's one more step toward achieving our mission of digital equality.
結局のところ、重要なのはダウンロード数ではありません。重要なのは、そのダウンロードの背景にあるエネルギーです。それこそは私たちが今日、祝いたい対象です。なぜなら、「アクセシビリティを高めたい」という思いから誰かがAxe-coreをダウンロードするたび、それはデジタル平等という私たちのミッションの実現に向けた、新たな一歩となるからです。
50億という数字にはインパクトがありますが、数字は数字でしかありません。個々のダウンロードの動機に多少の違いはあるにせよ、そこには確かにデジタルアクセシビリティの改善に向けた想いがあると信じます。Axe-coreの開発と普及に携わってこられた皆様に深く感謝しつつ、今後ますますの進化を期待したいと思います。
]]>「Axe Monitor」に同梱されているAxe-coreは、Deque社が開発するオープンソースのアクセシビリティ検証ライブラリで、世界中で広く利用されています。
これまでも、当社はAxe-coreの検証結果メッセージの日本語翻訳や、Axe DevToolsの日本語化、Axe Monitorの日本語化と提供など、日本語環境でAxe製品を活用しやすくするための取り組みを続けてきました。
直近では、Axe-coreの更新に伴い新たに追加され、英語のままとなっていた一部のルールの説明やメッセージについて、日本語訳を作成し、Deque社に提供しました。今回の翻訳は、今後のAxe-coreの更新で反映される予定です。たとえば、「ARIA tab nodes must have an accessible name」というメッセージを以下のように翻訳しました。
ARIA tabノードにはアクセシブルな名前がなければなりません
これは、画面上のタブ型UIに、スクリーンリーダーで読み上げられる名前が付いているかを確認する項目です。名前がないと、スクリーンリーダーの利用者には、UIの構造が適切に伝わらなくなってしまいます。こうした一つひとつのメッセージを、日本語で自然に伝わるように訳していきました。
Axe-coreの検証結果メッセージは、Axe DevToolsやAxe MonitorなどのAxe製品群全体で利用されるため、今回の更新は日本語環境のユーザー全体の利便性向上につながります。
今後もDeque社と連携しながら、翻訳の改善を継続していきます。
]]>私たちは渋谷を中心にアクセシビリティの勉強会をするグループです。アクセシビリティについて、定期的にゆるく、ときに真面目に学んだり、悩みを共有したり相談したりする場所を目指しています。
というものです。
登壇のきっかけは、X（旧Twitter）でたまたま見かけたというもので、そのときは何かを人前で発表したいという思いがあって、発表することだけ決めて申込みをしました。
LTの内容としては、マニアックなものでも構わないということでしたので、WCAG 3.0をお題にすることにしました。WCAG 3.0は、次世代のアクセシビリティガイドラインとして現在策定が行われているものです。WCAG 3.0自体の最近の動きはそこまで大きなものはないという認識ではありますが、WCAG 3.0のおさらいとごく簡単なこれまでの歩み、足元ではどうなっているのかというようなことを話しました。詳しくは、ドクセルのスライドをご覧ください。
対面で話すのは何年ぶりになるのか記憶が定かではないですが、いずれにせよ久々に人前で発表した気がします。勉強会にリアルで参加するのも久々ではあり、新鮮な気分で過ごしました。
ちなみにLT後のWCAG 3.0に関連する動きとしては、WCAG 3.0を策定しているAG WGのCharter（憲章）にFormal Objection（正式異議申し立て）が出されたようです（該当のGitHub issueのコメント）。おそらくWCAG 3.0の策定計画についての申し立てが行われたのではないかと思われます。申し立てについてどのような結論が出るのか、動向を見守りたいと思います。
]]>SDNYというのは、ニューヨーク南部地区連邦地方裁判所のことを指します。知財高裁のページによれば、
ニューヨークにある4つの連邦地方裁判所の1つで，南部地区には，ウォール街等を含む金融センターを管轄するため，米国で最も影響力があり活発な連邦地方裁判所の1つといわれています。
とされています。SDNYは他の連邦地方裁判所と比べて非常に多くのADA（アメリカ障害者法）訴訟が行われるために判例が洗練され、他の裁判所でも引用されるとのことで、Webアクセシビリティ訴訟でも影響力を持つとされています。
元の記事のメッセージとしては、
というものです。少し細かく見ていきましょう。
ケース1として取り上げられている判決は、altテキストの欠落、予告なしのポップアップ、マウス操作のみのイベント要件、リンク切れなどの障壁のためにメガネやサングラスを扱うMoscotのWebサイトでサングラスを購入できなかったと主張する盲目の原告が提起したADA集団訴訟を棄却したというものです。
この訴状は典型的な連続原告訴訟であり、
されるというものでした。
Moscotは2023年5月から、デジタルアクセシビリティ企業であるLevel Accessと提携していました。苦情を受け取った後、MoscotはLevel Accessに対し、原告が主張するすべての障壁について調査を依頼しました。その調査の結果、主張された障壁のいずれも、スクリーンリーダー利用者がサングラスを購入することを実際に妨げるものではありませんでした。軽微な問題が1件特定され、直ちに修正されました。Moscotは、Level Accessの監査報告書と契約書を添え、eコマース担当ディレクターによる詳細な陳述書を提出し、これらすべてを説明しました。原告はこれに対し何ら反論を提出しませんでした。
裁判所は「問題はすでに完全に解消されている」と判断し棄却しました。継続的で、証拠付きのWebアクセシビリティ対応が法的なリスクへの備えになり得るといえます。
ケース2としては、中小企業がaccessiBeのオーバーレイ製品（accessWidget）について、「48時間でWCAGに準拠」「訴訟から保護」という宣伝を信じ購入したものの、実際には訴訟され、支援も限定的だったことについての裁判です。
裁判のポイントとしては、利用規約によるaccessiBeの免責は多く認められたものの、「WCAG準拠を実現できる」という契約違反は存続していると認定されました。アクセシビリティオーバーレイの法的リスクが高いことを改めて示すものといえます。
まとめますと、専門家との継続的なWebアクセシビリティへの取り組み、監査や改善の記録、そして長期的な運用といった、実質的なWebアクセシビリティへの投資は法的なリスクへの備えになり得るといえます。しかし、アクセシビリティオーバーレイのようなツールに依存することは不十分な対策であり、法的リスクを抱えているといえます。しっかりとWebアクセシビリティに取り組んでいるかどうかが、アメリカの裁判で重視されるようになってきているといえるでしょう。
]]>前回の発行が2024年1月のことでしたから、実に2年半ぶりの更新となります。主要な更新内容としては、
sectionheaderおよびaria-sectionfooterロールの追加aria-hidden=trueの使用の禁止となります。文章量としてはそこまで大きな更新ではないといえるでしょう。それぞれ見てみますと、
sectionheaderおよびaria-sectionfooterロールはそれぞれ、セクショニングコンテンツ（たとえばsection要素）内で、header要素やfooter要素を置いたときに対応するロールとなります。
aria-Notify APIについては、ライブリージョンのように、支援技術に通知を送ることができるAPIです。MDNのDocument: ariaNotify() methodが参考になるでしょう。
文書のルート要素でのaria-hidden=trueの使用の禁止は文字どおり、html要素やbody要素での使用を禁止するものです。今ではaria-hidden="false"がaria-hidden="undefined"の同義語となり、aria-hidden="false"を用いて特定の子孫の領域だけ支援技術に表示されるようにする、というような手法が仕様上使えなくなったことに注目できるでしょう。
ほかの変更点としては、dialogロールの定義が更新されているのが目に付きました。すべての更新点についてはこの文書の位置付けのセクションで確認することができます。
しかし、記号が一般的な用法で利用されていれば、それ自体が問題になることはほとんどありません。また、記号が読み上げられないケースの多くはスクリーンリーダーの設定によるものであり、設定変更によって解消できる場合があります。
そこで今回は、主要なスクリーンリーダーで記号の読み上げ設定を変更する方法や、スクリーンリーダーごとの読み上げ方の違いについてご紹介します。
NVDAでは、音声設定の「句読点/記号レベル」から変更でき、以下の4段階から選択できます。各記号には「最低読み上げレベル」が設定されており、上位のレベルほど読み上げられる記号が増えていきます。なお、下位レベルで読み上げられる記号は、上位レベルでも引き続き読み上げられます。
デフォルトでは「一部読み上げ」となっており、たとえば括弧やカンマ、引用符などは読み上げられませんが、これらは「ほとんど読み上げ」以上にすることで読み上げられるようになります。
PC-Talkerでは、「なめらか読み」の設定から、句点・括弧・記号について、それぞれ読み上げの有無を設定できます。
デフォルトでは、句点・括弧・記号のいずれも読み上げる設定となっています。そのため、設定を変更しない限り、一般的な記号が読み飛ばされることはほとんどありません。
VoiceOverでは、設定 > アクセシビリティ > VoiceOver > 詳細度 > 句読点と記号 から設定を変更できます。「現在有効な句読点グループ」を選択し、「すべて」「一部」「なし」の3段階で切り替えられるほか、独自のカスタムグループを作成することもできます。
デフォルトでは「一部」となっており、この状態ではコロンや括弧などの記号は読み上げられません。「すべて」に変更すると、これらの記号も読み上げられるようになります。
TalkBackでは、設定 > ユーザー補助 > TalkBack > 設定 > 読み上げの詳細設定 > 句読点と記号を読み上げる から設定を変更でき、「すべて」「ほとんど」「一部」の3段階で切り替えられます。「一部」は「&」などごく一部の記号のみ、「ほとんど」は括弧・コロン・アスタリスクなどよく使われる記号、「すべて」は一般的でない記号も含めたすべての記号を読み上げます。
デフォルトでは「一部」となっており、この状態では括弧やコロンなどは読み上げられませんが、「ほとんど」以上にすることで読み上げられるようになります。
このように、記号の読み上げの多くはスクリーンリーダーの設定で調整できます。今回取り上げた中では、PC-Talkerを除き、デフォルトでは一部の記号を読み上げない設定になっています。正確な理由は定かではありませんが、スクリーンリーダー利用者の立場から見ると、重要な本文の読み上げに集中しやすくするための設定に感じられます。いずれにしても、記号が読み上げられない可能性だけを理由に、記号の使用を過度に避ける必要はないと考えています。
]]>特筆すべきは、JIS X 8341-3改正を見据えて、ガイドラインを含む達成基準の名称と本文の内容について、日本語訳を大幅に見直したことです。見直しの際には、予定している改正JISとの内容の違いがなるべく小さくなるよう、JISの規格票の様式を定めたJIS Z 8301を可能な範囲で反映させるようにしています。
変更前のWCAG 2.2の日本語訳と変更後のものを見比べてみますと、代表的なガイドラインの名称の変更については、
などが挙げられます。また、代表的な達成基準の名称の変更については、
などが挙げられます。見慣れた達成基準の名称に多数の変更が入っているあたりは、慣れが必要そうです。
見直し作業自体は、JIS改正の準備を行っているWG6内のサブグループで2023年末から行っていたもので、およそ2年半でここまで漕ぎつけることができました。振り返ってみると、2年かかっていたという事実に衝撃を覚えていますが、サブグループでの議論はときには1つの達成基準の名前で1時間行ったりするなど、活発な議論を行った記憶が蘇ってきます。
本文の内容の変更については、枚挙にいとまがないのでここでは取り上げません。変更の内容について詳細を知りたいという方は、GitHubのリリースに列挙されていますので、そちらを当たっていただければと思います。
是非、新しいWCAG 2.2日本語訳をご覧ください。
]]>今回のイベントのきっかけは、アクセシビリティ事業部のメンバーが普段なかなか社内でアクセシビリティ関連のイベントがないことを踏まえて、GAADを機会に社内でアクセシビリティについて話す場を設けたかったというものと、イベントを通して「アクセシビリティ事業部のメンバーの雰囲気」を伝えたかったというものです。
「学園」と銘打っているのは先生と生徒役を設けたことにちなんでいます。内容としてはQ&A形式の座談会としました。
座談会のメンバーとしては、4月に中途採用で入社された1名が生徒役、アクセシビリティBlogで執筆をしている大塚ともう1名が先輩役、不肖筆者が先生役で、アクセシビリティ事業部の計4名で執り行いました。
座談会のお題としては、次のものを用意しました。
これらは、新入社員でも参加できるよう、アクセシビリティ初心者を意識したものとしました。
社内向けのイベントですので詳細は差し控えますが、イベントの雰囲気としては、Teamsのチャットでのコメントがそれなりの頻度で入ってきて、和やかに進行していたと思います。
筆者の感想としては、事業部のメンバーと気楽にWebアクセシビリティと周辺の話ができ、楽しむことができたのがよかったと思います。Webアクセシビリティについて考えるよい一日になったのではないかと思います。
]]>昨年はGAADに合わせて「GAAD2025から考える、視覚障害者が実感するWebアクセシビリティの現在地」というコラムを書きましたが、今年は新入社員研修の一環で4月に実施したスクリーンリーダーの操作体験について、Blogで紹介します。
操作体験は、アクセシビリティと品質管理を扱う研修の後半で、1時間ほど実施しました。またスクリーンリーダーには、Windows向けのNVDAを使用しました。
まず、スクリーンリーダーの概要や起動方法を説明し、参加者にも実際にNVDAを起動していただきました。
その後、Webサイトの基本的な閲覧方法を紹介し、見出し構造や代替テキストに問題のあるサンプルページを一緒に閲覧しながら、アクセシビリティ上の問題がスクリーンリーダーの利用者にどのような影響を及ぼすのかを体験していただきました。サンプルページには、意図的にアクセシビリティ上の問題が仕込まれた「駒瑠市」を利用させていただきました。
操作体験のなかで、スクリーンリーダーの操作手順や読み上げの仕組みといった技術的な内容を分かりやすく伝えることを、私は意識しました。視覚障害者がWebを利用することの難しさに焦点を当ててしまうと、アクセシビリティをはじめとするWebが満たすべき品質の理解という、研修本来の目的からずれてしまうためです。
もちろん啓発的な視点も重要ですが、今回の操作体験では、技術的な観点からアクセシビリティを理解してもらうことを優先しました。講義後のアンケートでも、スクリーンリーダーの機能や動作、マークアップ時の注意点に関するコメントが多く、狙いに沿った理解が得られたと感じました。
この操作体験は昨年から実施しており、今年で2回目となります。来年度は未定ですが、実施の運びとなれば内容をさらに改善し、より効果的な研修にしたい考えです。
]]>Web Accessibility Perspectives Videosは、Webアクセシビリティの向上が、障害者にとって必要不可欠であり、同時にすべてのユーザーにとって有益であることを伝える10本の動画です。いずれの動画も1分前後と短く、英語がわからずとも内容を理解しやすい構成となっています。以下に、私が個人的にオススメする3本をピックアップしてご紹介します。
キーボードだけで操作できるようUIを設計・実装することで、どのようなユーザーや利用状況がカバーされ得るかを、3人の登場人物を通じて表現している動画です。セミナー等で最も頻繁に私が紹介している1本。
文字のフォントやサイズなどをカスタマイズできることの重要性を訴求した動画です。初っぱなに流れる、パンの焼き具合（焦げ具合？）の好みは人それぞれ、という比喩が面白いと思います。
リンクやボタンといった操作対象のサイズに関する動画です。簡単ではないことの例えとして「針の穴を通す」という言葉がありますが、まさにその様子を冒頭で表現しているのが秀逸というか、わかりやすいと感じました。
Web Accessibility Perspectives Videosを見たことがなかったという方は、ぜひ上記以外の7本の動画も、今年のGAADを機にご覧になっていただけたらと思います。
]]>