Topics

Host 1: 普段私たちが何気なくクリックしたりスワイプしたりしているウェブサイトやアプリ。でももしマウスが使えなかったら。あるいは画面の情報が見えなかったら。もしかしたら複雑な情報がちょっと理解しにくいなんてこともありますよね。そういうもしもの状況にいる人たちにとって、このデジタルの世界がどう見えているのか。今日はですね、その想像力と、えー、技術を結びつけるウェブアクセシビリティの世界。その中でも特に専門知識の体系に光を当てていきたいと思います。

Host 1: 今回取り上げるのは国際アクセシビリティ専門家協会IAAPが定めたウェブアクセシビリティスペシャリストボディオブナレッジ、まあ通称WAS BOKですね。バージョン2.3、2024年10月版というかなり新しい最新の知識体系です。これからこの、まあちょっとボリュームのある文書なんですけど、そのエッセンスをぎゅっと抽出していきます。

Host 1: あなたがもしWASを目指している方。あるいはこの分野の必須スキルとか知識をこう効率よく知りたいなと思っているなら、まさにぴったりの時間になるかなと。なぜこの知識が今これほど大事なのか、その核心の部分に一緒に迫っていきましょう。さて、専門家の方を招きしています。早速この知識の海、一緒に探っていきましょうか。

Host 2: はい、よろしくお願いします。あの、このWAS BOKなんですが、これはウェブアクセシビリティの分野で、だいたい3年から5年くらいの職務経験がある、ま中級レベルの専門家をイメージして作られています。大事なのは、単にこう最新のコードが書けるっていうことだけじゃなくて、アクセシビリティ上の問題をちゃんと特定して、それをどう修正していくか。そのための技術的な理解と実践力、そしてその背景にある原則、これを深く分かっているかという点が問われます。

Host 1: なるほど。単なる技術だけじゃないと。ではまず、一番大きな割合、試験全体の40%を占めるというアクセシブルなウェブソリューションの作成。これは文字通りアクセシブルなものをこう作るための知識という理解でいいですか。

Host 2: ええ、その通りです。ここでの核は、やはり国際的なガイドライン、特にWCAGですね。「Web Content Accessibility Guidelines」。これを深く理解して実際の開発に適用できるかという能力です。BOKではバージョン2.0、2.1、そして、ええと、最新の2.2の内容がカバーされています。それに加えて、リッチなインターフェースを作るためのWAI-ARIAですとか、開発ツール自体のアクセシビリティを定めるATAG、あとはヨーロッパの公的調達基準であるEN 301 549。こういった関連する仕様への理解も求められますね。

Host 1: ああ、WCAG。よく聞きますけど、有名なPOUR原則っていうのがありますよね。これって具体的にはどういう考え方なんでしょう?なんかただの標語じゃないんですよね。

Host 2: ええ、全く違いますね。POUR原則。 Perceivable（知覚可能）、Operable（操作可能）、Understandable（理解可能）、Robust（堅牢） これらはアクセシビリティ設計のまさに根本となる考え方です。 知覚可能というのは、情報がユーザーの感覚、ま、主に視覚とか聴覚ですけど、それで捉えられること。操作可能は、例えばキーボードだけでも、あるいは他の支援技術を使っても、ちゃんと全部の機能が使えること。理解可能は、情報の意味とか、どう操作すればいいかが分かりやすいこと。そして堅牢は、将来の技術とか、いろんなブラウザ、あるいは支援技術 (AT)、アシスティブテクノロジー、これでちゃんと解釈される互換性があるっていうことです。これらは設計のあらゆる場面で「この機能って本当にPOUR満たしてるかな」って立ち返るべき問いかけなんですよ。

Host 1: なるほど、なるほど。設計の哲学みたいなものなんですね。技術的なところで言うと、BOKにはJavaScriptの話も出てきますよね。アクセシビリティの専門家になるにはプログラミングスキルってどのくらい必要になるんでしょうか?

Host 2: ああ、そこは結構誤解されやすいかもしれないですね。必ずしもそのバリバリのプログラマーである必要はないんです。ただ、JavaScriptがアクセシビリティにどう影響するか、その原理を理解しておくことが、これは不可欠です。例えば、プログレッシブエンハンスメントっていう考え方があります。これは JavaScriptが動かない環境でも基本的なコンテンツとか機能は使えるようにしておいて、JavaScriptはあくまで付加価値として提供しましょうっていう設計思想ですね。

Host 1: はいはい。

Host 2: あとは、クリック操作を例に取ると、意味のないdivタグなんかにonclickをつけるんじゃなくて、本来インタラクティブな要素であるボタンを使いましょうとか、そういうデバイス非依存のイベント処理の理解。さらに、画面の一部が動的に変わったときに、それをスクリーンリーダーみたいなATにどう伝えるか。これARIA live regionっていうんですけど。あと、複雑なウェブアプリ、SPAとかでのフォーカス制御。それから要素の状態変化、例えば開いたり閉じたり、それをプログラム的にどう伝えるか、ARIA属性の更新とか。こういったコンセプトの理解がすごく重要になります。だから自分でコードが書けなくても、開発者の方に的確な指示とかレビューができる、そのレベルの知識は求められるということです。

Host 1: ふーむ。最近のウェブって本当見た目も動きも凝ったカスタムコンポーネントが多いですよね。なんかタブの切り替えとかカレンダーを選ぶやつとか。標準のHTMLだけじゃちょっと表現しきれないものも。こういうのはどうやってアクセシブルにするんですか?

Host 2: ええ、そこで活躍するのがWAI-ARIA、「Accessible Rich Internet Applications」なんです。これはHTML だけだと足りない意味 (セマンティクス)って言いますが、それとか状態を特別な属性を使って補うための仕様なんです。カスタムで作ったコンポーネントに「これはタブパネルですよ」とか、「これは今選ばれてますよ」みたいな情報を付け足せるわけです。

Host 1: へえー。

Host 2: ただしですね、BOKがすごく強調しているのはARIAの5つのルールっていうのがあって、

Host 1: あ、ルールがあるんですね。

Host 2: ええ。特に最初のルール、「可能な限りネイティブHTML要素を使う」っていうのが重要なんです。つまり、ARIAはまあ最後の手段であって、使いすぎは良くないですよと。安易にARIAを使う前に標準の HTML でできないかまず考えましょうということなんです。

Host 1: なるほど。

Host 2: それと、ARIAを使う場合でもARIA Authoring Practices Guide (APG)っていう実践的なデザインパターンのガイドラインがあるんですけど、これもコピペすればOKってものでは全然なくて、あくまで参考。BOKも指摘してますけど、実際にいろんな環境でちゃんと動くかテストする、これが絶対に欠かせません。

Host 1: なるほど。作るという領域で私が特に面白いなと思ったのが、その多様なユーザーさんが実際にどうウェブを使っているか、その具体的な戦略を知ることもこの領域に含まれてるって点なんです。ここもう少し詳しく聞かせてもらえますか?

Host 2: ええ、これは非常に重要なパートですね。アクセシビリティって抽象的なルールだけじゃなくて、やっぱり具体的な人間の経験に基づいていますから。BOKではいくつかのユーザーグループとその利用戦略をあげています。 例えば、視覚に頼らないユーザーさん。彼らはスクリーンリーダー、JAWSとかNVDA、VoiceOverなんかが代表的ですけど、そういったATを使って画面の情報を音声で読み上げさせます。

Host 1: はい。

Host 2: 操作は主にキーボードですね。Tabキーで要素を移動したり、矢印キーで細かく動かしたり、ショートカットキーを使ったり。あと見出しのレベルとかランドマーク、ヘッダーとかナビゲーションとかメインコンテンツの領域とかARIAで定義できるんですけど、そういのを頼りにページ全体の構造を把握して効率よく移動するんです。コンテンツは基本的にDOM (ドキュメントオブジェクトモデル)、つまりコード上の順番で直線的に読み上げられるので、見た目のレイアウトも大事ですけど、コードの順序が論理的になってるかっていうのがすごく重要になりますね。

Host 1: へえ、コードの順番が。

Host 2: ええ。それからロービジョン (弱視) のユーザーさんは、画面の拡大機能、OSとかブラウザの機能とか専用ソフトとかですね。あとは色のコントラストを高くする設計 (ハイコントラストモード)とか、そういうのを利用します。拡大したときに今フォーカスが当たってる要素がちゃんと画面の中に「見え続ける」か、これフォーカスの追随って言いますけど、これが操作性にすごく影響します。拡大とスクリーンリーダーを両方使う方もいらっしゃいますね。

Host 1: うんうん。

Host 2: それから読字に困難があるユーザーさん、例えばディスレクシアの方とかは、テキストの読み上げソフト (TTS: Text-to-Speech)、これを使ったり、あとは文字のフォントとかサイズ、色、行間なんかをご自身が読みやすいようにカスタマイズできる機能、これを求めます。だからテキストが画像の一部になってたりすると、こういう支援が受けられなくなっちゃうんですよ。見た目が同じでも本物のテキストであること、これが決定的に重要です。

Host 1: ああ、なるほど。画像の中の文字はダメなんですね。

Host 2: そういうことです。あと認知とか学習に特性のあるユーザーさんも本当に多様で、シンプルで一貫したデザインとか、次どうなるか予測しやすいナビゲーション、専門用語を避けた分かりやすい言葉遣い、注意が散漫になりがちな自動再生コンテンツの制御とか、そういうのが助けになりますね。これは特定の AT と言うよりはユニバーサルデザインに近い考え方かもしれません。

Host 1: はい。

Host 2: それから肢体不自由とかでマウス操作が難しいユーザーさんは、キーボード操作が中心になります。なので、フォーカスが今どこにあるかが目で見てはっきり分かること、そしてTabキーで移動する順番が論理的であること、これが不可欠です。メインコンテンツへスキップみたいなリンクがあると、毎回ヘッダーとかをTabで一生懸命辿る手間が省けるので有効ですね。入力方法も音声認識とか、視線入力、あとスイッチコントロール、ボタン一つで操作するような、そういう多様なATがあります。

Host 1: ふむふむ。

Host 2: 最後は聴覚に障害のあるユーザーさんには、動画についてるキャプション (字幕)ですね。それとか音声だけのコンテンツについてるトランスクリプト (文字起こし)、これが必須になります。手話が第一言語のユーザーさんには優しい言葉遣いとか視覚的な情報 (図とかアイコン)とかも理解を助けることがありますね。

Host 1: なるほど。いやあ、こうやって多様な使い方を具体的に聞くと、初めてWCAGの達成基準が、ああ、だからこれが必要なんだなって腑に落ちる感じがしますね。単なるチェックリストじゃなくなるというか。 では、作る知識を固めた上で、次にこれも同じくらい重要で試験の40%を占める既存のものの穴を見つけるスキル、つまりウェブソリューションにおけるアクセシビリティ問題の特定について見ていきましょうか。

Host 2: はい。ここですね、まずいろんな利用環境での相互運用性の問題、これを発見する能力が問われます。例えば、あるブラウザとスクリーンリーダーの組み合わせだと問題ないんだけど、別の組み合わせだと動かないとか、挙動が違うとかそういうケースです。BOKではテストすべき代表的な組み合わせ例なんか示唆されています。WindowsならJAWSとChrome、NVDAとFirefoxとか、macOSならVoiceOverとSafari みたいな。まあ、全てを網羅するのは現実的じゃないんですけど、主要な組み合わせで検証することが重要ですね。

Host 1: なるほど。で、問題らしきものを見つけたとしますよね。それが本当にそのWCAGとかの基準に照らして違反なのか、それとも、まあ単にちょっと使いにくいねっていう点なのか。どう判断すればいいんでしょう?結構線引きが難しそうな気もするんですが。

Host 2: ああ、それは良い質問ですね。まずプロジェクトとしてどこまでのレベルを目指すのか、目標適合レベル、通常はAですけど、これをはっきりさせます。それからWCAGには5つの適合要件っていうルールがあって、これを理解する必要があります。例えば、適合はページ単位で評価しますよとか、購入手続きみたいな一連のプロセスは全体通して適合しないとだめですよとか、適合のために依存する技術はアクセシビリティサポーテブルじゃないといけませんよとか、そういうルールです。

Host 1: はいはい。

Host 2: 評価作業そのものはWCAG-EMという方法論があるんですけど、それに従ってサイト全体から代表的なページを選んで体系的に進めます。そして見つかった問題点をWCAGのどの達成基準 (Success Criterion)に違反するのかを正確にマッピングするスキル。これが非常に重要です。このマッピングができないと開発者の方に修正をお願いするときに根拠を示せないんですね。「なんとなく使いにくい」じゃなくて、「達成基準のX.X.Xに違反しているので修正してください」と具体的に指摘できる、これが専門家には求められます。

Host 1: うんうん、具体性が大事だと。問題特定にはツールも使うと思うんですけど、なんか自動チェックツールだけで十分ってわけにはやっぱりいかないんですよね。

Host 2: まさにおっしゃる通りです。axeとかWAVE、Lighthouseみたいな自動テストツールはすごく便利で、特に開発プロセスの早い段階、例えばコード書いた直後にチェックするとか、そういう使い方で効果を発揮します。画像にalt属性がないとか、フォーム要素にラベルがないとか、そういう明らかなコードレベルのエラーは検出できるんです。

Host 1: ええ。

Host 2: ただ、限界も多い。例えば、altテキストが設定されていても、その内容がちゃんと画像と合ってるかみたいな意味的な妥当性は判断できません。キーボードで操作したときの順番が論理的かとか、色のコントラストは基準値はクリアしてるけど、デザイン的にちょっと見分けにくいよねみたいな問題も自動では見つけられない。時には誤検知、問題ないのにエラーって言われちゃうこともありますしね。なので、自動ツールはあくまで補助と考えるべきですね。

Host 1: なるほど、補助ですか。

Host 2: ええ。そこで不可欠になるのが、やっぱり手動での検証、特に支援技術 (AT) を使ったテストです。キーボードだけで全ての操作ができるか、マウスを一切使わずに試してみる。スクリーンリーダーで読み上げたときに、要素の名前、例えば検索ボタンとか、役割、ボタンとか、現在の値、チェックボックスチェック済みとか、状態の変化、アコーディオン展開済みとか、そういうのがちゃんと伝わるか。画面を 200%とか 400%に拡大したときに、文字が重なっちゃったり、画面の外にはみ出したりしないか。Windows のハイコントラストモードみたいな強制的に配色を変えるモードで情報が消えちゃったり、読みにくくなったりしないか。こういう地味な検証が必要になってきます。ただ、注意点としては、普段ATを使ってないテスターが、ネイティブユーザーの体験を完全にシミュレートするっていうのはなかなか難しいという点は理解を置いておくべきかなと。目的はあくまで適合性の確認であって、深いユーザビリティテストとは少し違うんです。

Host 1: ああ、適合性とユーザビリティ、なるほど。技術的に基準は満たしてるんだけど、実際には使いにくいっていうケースもまああるわけですね。

Host 2: そうなんですよ。WCAGの適合っていうのはあくまで最低限のラインであってゴールじゃないんです。例えば、キーボード操作は可能ですと。これは適合。でも目的のボタンにたどり着くのにTabキーを50回も押さないといけない。これは明らかにユーザビリティが低いですよね。

Host 1: それは辛いですね。

Host 2: ええ。BOKでもWCAGの達成基準には直接は含まれてないけれど、認知障害のあるユーザーさんに配慮した方がいい推奨事項、W3Cが出してる「Making Content Usable for People with Cognitive and Learning Disabilities」っていう文書があるんですが、そういうのに言及したり、あとは実際の障害当事者の方に協力してもらってユーザビリティテストを行うことの重要性、これも指摘しています。適合性のその先にある本当の使いやすさ、これを追求する視点が大切ですね。

Host 1: ふむ。では最後の領域ですね。試験の20%を占めるウェブソリューションにおける問題の修正にに進みましょうか。これは見つけた問題をどう直すか、その戦略にかかわる部分ですね。

Host 2: はい。まさに問題解決能力が問われる領域です。アクセシビリティの探索なんかでたくさんの問題が見つかったとしても、ま、リソース、時間とか予算、人手ですね、これは限られています。全てを一度に修正するっていうのはなかなかできません。そこで重要になってくるのが問題の優先順位付けです。

Host 1: 優先順位付けですか。どういう観点で優先度を決めるんでしょう?単純に簡単なものからってわけではなさそうですね。

Host 2: ええ、そうですね。いくつか重要な観点があります。BOKが示唆しているのは、まずユーザーへの影響度。特にユーザーさんが主要なタスク、例えば商品の購入とか、情報の検索、申請手続きとか、そういうのを完了できなくなっちゃうようなブロッカーとなる問題。これはもう最優先です。キーボードで操作できないボタンとか、代替テキストがない画像リンク、代替手段がないCAPTCHAなんかは典型例ですね。

Host 1: ああ、それは困りますね。

Host 2: 次に修正の容易さ。少ない労力で修正できる、いわゆるローエフォートな問題。これは早く改善の効果が出せるので、優先度を上げることもあります。それから問題の発生頻度。サイト共通のテンプレートとかコンポーネントに原因がある問題は、一箇所直せば広範囲に影響するので、これも優先度は高くなりますね。もちろん主要なコンテンツとかタスクに関わる問題、アクセス数が多いページの問題も重要です。あとは法的リスクも考慮すべきですね。

Host 1: なるほど。いろいろな角度があるんですね。それで、修正の方針を提案する際にはどんな能力が求められますか?

Host 2: ここではですね、理想的な解決策と現実的な制約、例えば古いシステムを使っているとか、予算が限られているとか、そういうのを考慮した上での十分によい (Good Enough) 解決策。これをちゃんと区別して状況に応じた最適な修正戦略、これが求められますね。時にはその場しのぎの修正じゃなくて根本的なデザインとかアーキテクチャの変更が必要だと判断して、それを説得力を持って提言することも必要になります。そして何より開発チームに対して、問題の価値、問題の内容、つまりなぜ、誰にとって問題なのか。そして具体的な修正方法、コード例を示すのも有効ですけど、これを明確に、かつ建設的に伝えるコミュニケーション能力。これが不可欠です。単にダメ出しをするんじゃなくて、解決に向けて一緒に協力していこうという姿勢が大事ですね。

Host 1: 確かにコミュニケーション、大事ですね。ところで、BOKには調達プロセスっていう言葉も出てきましたが、これはどういう文脈の話なんでしょうか?

Host 2: ああ、これはですね、組織が外部から新しいICT製品とかサービス、例えばソフトウェアとか、業務用システム、ウェブサイトの制作委託とかそういうものを購入したり導入したりする際にですね、その製品とかサービス自体のアクセシビリティを契約する前の段階でちゃんと要件として組み込んで検証しましょうと いうことです。

Host 1: はい。

Host 2: いくら自社で頑張ってウェブサイトを作っても、導入した外部のシステムがアクセシブルじゃなかったら意味がないですからね。専門家としては入札の仕様書に適切なアクセシビリティ要件を盛り込むのを手伝ったり、ベンダーさんから提出されるアクセシビリティの適合状況報告書、ACR (Accessibility Conformance Report)って言いますけど、多くの場合VPAT (Voluntary Product Accessibility Template)っていうテンプレートで作られますが、その内容をレビューして評価したり、実際に製品をテストしたり、契約内容にアクセシビリティを守る義務をちゃんと明記するように助言したりします。このVPATにも準拠している基準、例えばアメリカのSection 508とか、EUのEN 301549、WCAGとかによっていくつか形式があって、その読み解き方も知識として必要になりますね。

Host 1: なるほど。買うときにもアクセシビリティが関わってくると。いやあ、ウェブアクセシビリティスペシャリストの知識体系、WAS BOKの主要な領域見てきました。作る、見つける、直す、そして組織として買う際にも関わる。非常に広範で、技術的な深さももちろん求められる一方で、常に使う人への視点が中心にある、すごく人間中心の分野なんだなっていうことが改めてよく分かりました。

Host 2: まさにおっしゃる通りですね。多様なユーザーさんのニーズとか利用戦略を理解して、WCAGとかARIAみたいな標準仕様を文脈に応じて適切に適用する能力。自動化ツールと手動検証、そして支援技術を使ったテストを効果的に組み合わせて、見つけた問題の影響度を評価して優先順位をつけて、具体的な解決策をチームに伝達する、その実践力。そしてこの分野は技術も標準も常に進化しているので、継続的に学び続けられる姿勢も、ええ、不可欠ですね。

Host 1: では最後に、このBOKの内容を踏まえて、今日この話を聞いてくださったリスナーの皆さんに何かこう考えるヒントというか、問いかけのようなものはありますでしょうか?

Host 2: そうですね。あの、このBOKにまとめられている知識というのは言ってみれば地図のようなものだと思うんです。それ自体はすごく重要なんですけど、本当に価値を発揮するのは、その地図を手にして、そして共感というコンパスを持って実際のデジタルの世界を歩いて、改善していく、その実践の中にあるのかなと。今回触れた様々な技術的な側面、例えばARIAの役割とか、状態がどう伝わるかとか、多様なユーザーさんがどうやってナビゲーションしているかとか、そういうことを知った上で、あなたが普段使っているウェブサイトとかアプリをもう一度改めて見つめ直してみたときに、何か新しい発見ってあるでしょうか?そしてさらに一歩進んで、単にWCAGのチェックリストを埋めるっていう適合を超えてですね、これらのアクセシビリティの原則が、障害の有無にかかわらず、全ての人のために、より使いやすく、より公平で、より豊かなデジタル体験を創造するためにどう生かせるんだろうか。そんな視点で考えてみていただけると、この分野が持ってる可能性っていうのがさらに広がっていくんじゃないでしょうか?

Host 1: 適合の先にあるより良い体験。うーん。深く、そしてなんだか前向きになれる問いですね。今日はIAAPのWAS知識体系を非常に分かりやすく、そして深く掘り下げていただき、本当にありがとうございました。