Azure PortalなどにみるWebアクセシビリティ

Azure PortalなどにみるWebアクセシビリティ
Global Azure 2026 @ Tokyo
https://jazug.connpass.com/event/386399/

Transcript

1. Azure PortalなどにみるWebアクセシビリティ FutureOne株式会社 草場 友光 Global Azure 2026 @ Tokyo
2. 自己紹介 • .NETラボ勉強会を主宰 • 2022/08-2026 Microsoft MVP (Developer Technologies) • tomo_kusaba • ドラクエ大好き ドラクエ10のプレイ時間→ 1キャラ目：2676時間 2キャラ目：918時間 3キャラ目：792時間 4キャラ目：190時間(配信用)
3. 注意 • 個人の見解・解釈が多分に入っています。 • 見解の相違・事実誤認などありましたらご指摘ください。
4. 今日の目的 • Webアクセシビリティへの関心が世界的に高まる中、クラウド サービスのポータル画面もその例外ではありません。 • 今回は、Microsoftが提供するAzure Portalの中でも代表的 な画面をいくつか調査してみました。
5. あなたのサービスは、 ある日あなたが色を 識別できなくなったとしても 不自由なく使えますか？
6. あなたのサービスは、 ある日あなたが目が 見えなくなったとしても 不自由なく使えますか？
7. 地球上のすべての個人と すべての組織が より多くのことを達成できるようにする。
8. きっと、Azure Portalも アクセシビリティに優れた 実装となっているに違いない！
9. アクセシビリティに ついて学びましょう
11. アクセシビリティとは？ • 誰もが自由に何かの目的を達成できるような状態のことを指す。 • 特に情報システムにおいては何らかのハンディキャップを持った 方でも不自由なく情報にアクセスできるような状態を指す。 • 2024年4月障害者差別解消法によって民間企業においても合 理的配慮の提供が求められています。
12. いま享受している「普通」は突然変わる • けが・病気による不調でPCやスマートフォンの操作が困難になる。 • 加齢による視力低下・まぶしさで液晶画面が見えにくくなる。コン トラストの低いUIが視認できなくなる。 • 寒い冬で一時的にスマートフォンの細かい操作が困難になる。
13. 皆さんの開発中のWebサービスについて • けがや病気による不調の時でも不自由なく使うことができるだろ うか？ • 加齢による視力低下・まぶしさで液晶画面が見にくい状況下でも UIは視認できるだろうか？ • 寒い冬のかじかんだ手でも誤った入力することなく使うことがで きるだろうか？
14. アクセシビリティの根幹 • 情報や機能への「別ルート」を確保するということ • 視覚に頼れないとき →スクリーンリーダー • 聴覚に頼れないとき →字幕・文字情報 • マウス操作が困難なとき →キーボード操作のみで完結 • 一つの手段が使えないときに別の手段がある状態を作る
15. アクセシビリティは誰のためのものか？ • すべての人のため！ • 高いコントラストは直射日光下の視認性の悪い状況下でも読める状況を 作り出す。 • 効率を求めるときキーボードから手を放さずに操作できることがうれし い • PC・スマートフォン・タブレットなど様々なデバイスで使うときレスポンシ ブデザインがうれしい！ • 疲れ目の時ダークモードがうれしい！
16. Webアクセシビリティの国際標準 • WCAG(Web Content Accessibility Guidelines) 現在は2.1が広く採用され2.2への移行が進んでいる。 現在、3.0策定中。 レベルA(最低限)、AA(推奨)、AAA（最高）の3段階があり多くの 法規制はAAを基準にしています。 • 日本ではJIS X 8341-3がWCAG 2.0と整合しており公共機 関や大企業での対応基準として参照されます。
17. WCAG 2.2の全体像 • 4つの原則 原則 説明 知覚可能 情報とUIコンポーネントがユーザーに知覚可能な方法で提示されなければならないとい う原則です。視覚・聴覚に頼らなくてもコンテンツを把握できる代替手段を提供すること が求められます。 操作可能 UIコンポーネントとナビゲーションが操作可能でなければならないという原則です。キー ボードのみでの操作や、十分な操作時間の確保、発作を引き起こさないコンテンツ設計な どが含まれます。 理解可能 情報とUIの操作が理解可能でなければならないという原則です。読みやすいテキスト、予 測可能なページ動作、入力を支援する機能などが該当します。 堅牢 コンテンツが支援技術を含む多様なユーザーエージェントによって確実に解釈できるほど 堅牢でなければならないという原則です。
18. 知覚可能ー音声 • 外国語の映画を字幕でストーリを追う • 騒がしい居酒屋でテキストでやりとり • 電車内で動画を字幕をONにして視聴 • 音声情報を別のチャンネルに変換して情報を伝える行為
19. 知覚可能ー視覚 • 牛乳パックの切り欠きを指で触って開け口を判断する • スマートフォンの読み上げ機能で画面の内容を耳で聞く • 信号機の音響装置で青信号を音で知る • 点字ブロックの凹凸を足裏で感じて道順をたどる • 視覚情報を別のチャンネル（音声・触覚・物理形状など）に変換して情報 を伝える行為
20. 操作可能 • 利き手を骨折して反対の手でキーボードだけで操作する • 指先を怪我してタッチ操作の代わりに音声コマンドで操作する • マウスが壊れてTabキーとEnterキーだけでフォームを送信する • 視線入力装置で画面上のボタンを選択する • 入力手段が制限されても、別の操作方法で同じ機能を使える行為
21. 理解可能 • 初めて来た土地で乗換案内アプリの案内どおりに目的の駅にたどり着く • 外国語のWebサイトをブラウザの翻訳機能で読んで内容を把握する • エラー画面に表示された「〇〇を入力してください」の指示に従って修正する • やさしい日本語に書き換えられた行政文書で手続きを理解する • 読んで分かる、動きに迷わない、間違えてもやり直せる――その3つが揃っ て「理解できる」と言える
22. 堅牢 • 世界共通の楽譜でどの国の演奏家にも同じ曲が再現される • ISO規格の非常口マークがどの国のどの建物でも同じ意味で伝わる • 電子書籍がスマートフォンでもタブレットでもPCでも同じ内容で読める • QRコードがどのメーカーのスマートフォンでも同じ情報を読み取れる • 人が読み取っている意味を、支援技術を含むあらゆるソフトウェアにも同じ ように解釈させる行為
23. アクセシビリティがない世界を 想像してみてください • コントラストが低く読み取ることができない文字 • 何を言っているかわからない外国語でしゃべっている字幕もない 動画 • 「エラーが起きました」とだけ書かれた次に何をしていいのかわか らないエラーメッセージ • 次に何が起きるかわからない理解不能なUI
24. UI・UXとアクセシビリティとの違い 項目 UX UI アクセシビリティ 主な対象 体験全体 画面操作や見た目・構造 多様なユーザー 目的 心地よく使える体験 分かりやすく操作しやす い 誰でも使える 視点 感情・満足度 デザイン・操作性 利用可用性 関係性 UIを含む概念 UXの一部 UI・UXの品質を支える基盤 UI/UXは「使いやすさ・体験の質」を高める設計 アクセシビリティは「誰もが使えるようにする」設計
25. WCAG 2．2の全体像(ガイドライン レベルA)1 達成基準 概要 1.1.1 非テキストコンテンツ すべての非テキストコンテンツにテキストの代替を提供する 1.2.1 音声のみ・映像のみ（収録済み） 収録済みの音声・映像のみのメディアに代替を提供する 1.2.2 キャプション（収録済み） 収録済み音声コンテンツにキャプションを提供する 1.2.3 音声解説またはメディアの代替（収録済み） 収録済み映像に音声解説またはメディアの代替を提供する 1.3.1 情報および関係性 表示で伝達される情報・構造・関係性をプログラム的に決定可能にする 1.3.2 意味のある順序 コンテンツの正しい読み上げ順序をプログラム的に決定可能にする 1.3.3 感覚的な特徴 指示が形状・色・サイズ・位置・音のみに依存しない 1.4.1 色の使用 色だけを情報伝達の唯一の視覚的手段としない 1.4.2 音声の制御 自動再生される音声を停止・一時停止・音量調整可能にする 2.1.1 キーボード すべての機能をキーボードで操作可能にする
26. WCAG 2．2の全体像(ガイドライン レベルA)2 達成基準 概要 2.1.2 キーボードトラップなし キーボードフォーカスが特定のコンポーネントから移動できなくならない 2.1.4 文字キーのショートカット 文字のみのキーボードショートカットを無効化・再割り当て可能にする 2.2.1 タイミング調整可能 時間制限がある場合にユーザーが調整可能にする 2.2.2 一時停止・停止・非表示 動き・点滅・スクロール・自動更新するコンテンツを制御可能にする 2.3.1 3回の閃光またはしきい値以下 1秒間に3回を超える閃光を含むコンテンツを含まない 2.4.1 ブロックスキップ 繰り返されるコンテンツブロックをスキップする手段を提供する 2.4.2 ページタイトル Webページにトピックや目的を説明するタイトルを設定する 2.4.3 フォーカス順序 フォーカス可能なコンポーネントが意味と操作性を保つ順序でフォーカスを受 け取る 2.4.4 リンクの目的（コンテキスト内） リンクテキストまたはその文脈からリンクの目的が判断可能にする 2.5.1 ポインタジェスチャ マルチポイント・パスベースのジェスチャを単一ポインタでも操作可能にする
27. WCAG 2．2の全体像(ガイドライン レベルA)3 達成基準 概要 2.5.2 ポインタのキャンセル 単一ポインタ操作のダウンイベントで即座に機能を実行しない 2.5.3 ラベルとアクセシブルネーム UIコンポーネントの視覚的ラベルがアクセシブルネームに含まれる 2.5.4 モーションによる操作 デバイスモーションで操作可能な機能にUIコンポーネントでの代替操作を提 供する 3.1.1 ページの言語 ページのデフォルト言語をプログラム的に決定可能にする 3.2.1 フォーカス時 フォーカスを受け取ったときにコンテキストの変化を開始しない 3.2.2 入力時 設定変更時にコンテキストの変化を自動的に発生させない 3.2.6 一貫したヘルプ ヘルプ機構がページ間で同じ相対的順序で提示される 3.3.1 エラーの特定 入力エラーが自動検出された場合にエラー項目を特定しテキストで説明する 3.3.2 ラベルまたは説明 ユーザー入力が必要な場合にラベルまたは説明を提供する 3.3.7 冗長な入力 同一プロセスで以前入力した情報を再入力させない 4.1.2 名前・役割・値 UIコンポーネントの名前と役割がプログラム的に決定可能である
28. WCAG 2．2の全体像(ガイドライン レベルAA)1 達成基準 概要 1.2.4 キャプション（ライブ） ライブ音声コンテンツにキャプションを提供する 1.2.5 音声解説（収録済み） 収録済み映像コンテンツに音声解説を提供する 1.3.4 表示の向き コンテンツが特定の表示向きに制限されない 1.3.5 入力目的の特定 ユーザー情報を収集する入力フィールドの目的をプログラム的に決定可能に する 1.4.3 コントラスト（最低限） テキストと背景のコントラスト比が4.5:1以上（大きなテキストは3:1以上） 1.4.4 テキストのサイズ変更 テキストを200%まで拡大してもコンテンツや機能が損なわれない 1.4.5 文字画像 技術的に可能な場合は文字画像ではなくテキストを使用する 1.4.10 リフロー 320CSSピクセル幅（横スクロールコンテンツは256CSSピクセル高）で2方 向のスクロールを必要としない 1.4.11 非テキストのコントラスト UIコンポーネントとグラフィックのコントラスト比が3:1以上 1.4.12 テキストの間隔 行の高さ・段落間隔・文字間隔・単語間隔を調整してもコンテンツや機能が損 なわれない 1.4.13 ホバーまたはフォーカスで表示されるコン テンツ 追加コンテンツを解除可能・ホバー可能・持続的にする
29. WCAG 2．2の全体像(ガイドライン レベルAA)2 達成基準 概要 2.4.5 複数の手段 Webページセット内のページを見つける方法が複数提供される 2.4.6 見出しおよびラベル 見出しとラベルがトピックまたは目的を説明する 2.4.7 フォーカスの可視性 キーボード操作可能なUIのフォーカスインジケータが視覚的に確認可能であ る 2.4.11 フォーカスの遮蔽防止（最低限） フォーカスを受けたコンポーネントが作成者のコンテンツにより完全に隠され ない 2.5.7 ドラッグ操作 ドラッグ操作を使用する機能にドラッグなしの代替手段を提供する 2.5.8 ターゲットサイズ（最低限） ポインタ入力のターゲットサイズが24×24CSSピクセル以上 3.1.2 部分的な言語 各文節やフレーズの言語をプログラム的に決定可能にする 3.2.3 一貫したナビゲーション ナビゲーションが複数ページで同じ相対的順序で繰り返される 3.2.4 一貫した識別 同じ機能を持つコンポーネントが一貫して識別される 3.3.3 エラーの修正候補 入力エラーが自動検出され修正候補が分かる場合はそれを提供する
30. WCAG 2．2の全体像(ガイドライン レベルAA)3 達成基準 概要 3.3.4 エラーの防止（法的・金銭的・データ） 法的義務等を伴うページでは操作の取り消し・検証・確認のいずれかを提供す る 3.3.8 アクセシブルな認証（最低限） 認証プロセスで認知機能テストを要求しない（代替手段またはメカニズムを提 供） 4.1.3 ステータスメッセージ ステータスメッセージをrole等でプログラム的に決定可能にする
31. WCAG 2．2の全体像(ガイドライン レベルAAA)1 達成基準 概要 1.2.6 手話（収録済み） 収録済み音声コンテンツに手話通訳を提供する 1.2.7 拡張音声解説（収録済み） 映像の前景音声の間に十分な間合いがない場合に拡張音声解説を提供する 1.2.8 メディアの代替（収録済み） 収録済み同期メディア・映像のみのメディアに代替を提供する 1.2.9 音声のみ（ライブ） ライブ音声コンテンツに同等情報の代替を提供する 1.3.6 目的の特定 UIコンポーネント・アイコン・リージョンの目的をプログラム的に決定可能にす る 1.4.6 コントラスト（強化） テキストと背景のコントラスト比が7:1以上（大きなテキストは4.5:1以上） 1.4.7 背景音が小さいまたは無し 前景音声に対して背景音を20dB以上低くする 1.4.8 視覚的な表現 テキストの前景色・背景色・行幅・配置・行間・サイズをユーザーが調整可能にす る 1.4.9 文字画像（例外なし） 純粋な装飾または本質的な場合を除き文字画像を使用しない 2.1.3 キーボード（例外なし） すべての機能がキーボードで特定のタイミングなしに操作可能である
32. WCAG 2．2の全体像(ガイドライン レベルAAA)2 達成基準 概要 2.2.3 タイミング不要 タイミングがコンテンツに必須の要素ではない 2.2.4 中断 緊急時を除きユーザーが中断を延期・抑制可能にする 2.2.5 再認証 認証セッション期限切れ後にデータを失わずに活動を継続可能にする 2.2.6 タイムアウト データ損失の原因となるタイムアウトを事前に警告する 2.3.2 3回の閃光 1秒間に3回を超えて閃光するコンテンツを含まない 2.3.3 インタラクションによるアニメーション インタラクションで発生するモーションアニメーションを無効化可能にする 2.4.8 現在位置 ページセット内におけるユーザーの現在位置情報を提供する 2.4.9 リンクの目的（リンクのみ） リンクテキストのみからリンクの目的を特定可能にする 2.4.10 セクション見出し セクション見出しでコンテンツを構成する 2.4.12 フォーカスの遮蔽防止（強化） フォーカスを受けたコンポーネントのいかなる部分も隠されない
33. WCAG 2．2の全体像(ガイドライン レベルAAA)3 達成基準 概要 2.4.13 フォーカスの外観 フォーカスインジケータが十分な面積とコントラストを持つ 2.5.5 ターゲットサイズ（強化） ポインタ入力のターゲットサイズが44×44CSSピクセル以上 2.5.6 同時入力メカニズム プラットフォームで利用可能な入力モダリティの使用を制限しない 3.1.3 珍しい用語 特殊な意味で使用される用語の定義を特定する仕組を提供する 3.1.4 略語 略語の展開形式や意味を特定する仕組を提供する 3.1.5 読解レベル 中学校教育修了レベルを超える読解力を要するテキストに補足コンテンツを 提供する 3.1.6 発音 文脈上意味が曖昧になる単語の発音を特定する仕組を提供する 3.2.5 要求による変化 コンテキストの変化はユーザーの要求によってのみ開始される 3.3.5 ヘルプ コンテキストに応じたヘルプを利用可能にする 3.3.6 エラーの防止（すべて） ユーザーが情報を送信するすべてのページで取り消し・検証・確認のいずれか を提供する 3.3.9 アクセシブルな認証（強化） 認証プロセスで認知機能テストを要求しない（オブジェクト認識・個人コンテン ツの例外なし）
34. 自動テストと手動テスト • 自動テストの例 • Axe DevToolsでCIを回す • Lighthouseツールでアクセシビリティスコアとレポートを生成する • 手動テストの例 • キーボード移動で操作のつまりやフォーカスの欠落を確認 • 画面幅を小さくしたりレイアウト崩れや可読性を確認 • スクリーンリーダーで読み上げ順序・意味・状態が伝わるかを確認 • 音声認識やハイコントラストモードでも操作が破綻しないかを確認 • 言語理解・コンテキスト理解ができるかどうかの確認
35. WCAG 2．2のテスト(ガイドライン レベルA)1 達成基準 自動テスト 手動テスト 1.1.1 非テキストコンテンツ 部分的に可能 必須 1.2.1 音声のみ・映像のみ（収録済み） 不可能 必須 1.2.2 キャプション（収録済み） 限定的 必須 1.2.3 音声解説またはメディアの代替（収録済み） 不可能 必須 1.3.1 情報および関係性 部分的に可能 必須 1.3.2 意味のある順序 限定的 必須 1.3.3 感覚的な特徴 不可能 必須 1.4.1 色の使用 限定的 必須 1.4.2 音声の制御 限定的 必須 2.1.1 キーボード 限定的 必須
36. WCAG 2．2のテスト(ガイドライン レベルA)2 達成基準 自動テスト 手動テスト 2.1.2 キーボードトラップなし 限定的 必須 2.1.4 文字キーのショートカット 不可能 必須 2.2.1 タイミング調整可能 不可能 必須 2.2.2 一時停止・停止・非表示 限定的 必須 2.3.1 3回の閃光またはしきい値以下 部分的 必須 2.4.1 ブロックスキップ 部分的 必須 2.4.2 ページタイトル 可能 必須 2.4.3 フォーカス順序 限定的 必須 2.4.4 リンクの目的（コンテキスト内） 部分的 必須 2.5.1 ポインタジェスチャ 不可能 必須
37. WCAG 2．2のテスト(ガイドライン レベルA)3 達成基準 自動テスト 手動テスト 2.5.2 ポインタのキャンセル 不可能 必須 2.5.3 ラベルとアクセシブルネーム 部分的 必須 2.5.4 モーションによる操作 不可能 必須 3.1.1 ページの言語 可能 推奨 3.2.1 フォーカス時 不可能 必須 3.2.2 入力時 不可能 必須 3.2.6 一貫したヘルプ 不可能 必須 3.3.1 エラーの特定 限定的 必須 3.3.2 ラベルまたは説明 部分的 必須 3.3.7 冗長な入力 不可能 必須 4.1.2 名前・役割・値 部分的 必須
38. WCAG 2．2のテスト(ガイドライン レベルAA)1 達成基準 自動テスト 手動テスト 1.2.4 キャプション（ライブ） 不可能 必須 1.2.5 音声解説（収録済み） 限定的 必須 1.3.4 表示の向き 不可能 必須 1.3.5 入力目的の特定 部分的 必須 1.4.3 コントラスト（最低限） 多くのケースで可能 必須 1.4.4 テキストのサイズ変更 不可能 必須 1.4.5 文字画像 限定的 必須 1.4.10 リフロー 限定的 必須 1.4.11 非テキストのコントラスト 限定的 必須 1.4.12 テキストの間隔 不可能 必須 1.4.13 ホバーまたはフォーカスで表示されるコンテンツ 不可能 必須
39. WCAG 2．2のテスト(ガイドライン レベルAA)2 達成基準 自動テスト 手動テスト 2.4.5 複数の手段 不可能 必須 2.4.6 見出しおよびラベル 部分的 必須 2.4.7 フォーカスの可視性 部分的 必須 2.4.11 フォーカスの遮蔽防止（最低限） 不可能 必須 2.5.7 ドラッグ操作 不可能 必須 2.5.8 ターゲットサイズ（最低限） 部分的 必須 3.1.2 部分的な言語 限定的 必須 3.2.3 一貫したナビゲーション 不可能 必須 3.2.4 一貫した識別 不可能 必須 3.3.3 エラーの修正候補 不可能 必須
40. WCAG 2．2のテスト(ガイドライン レベルAA)3 達成基準 自動テスト 手動テスト 3.3.4 エラーの防止（法的・金銭的・データ） 不可能 必須 3.3.8 アクセシブルな認証（最低限） 限定的 必須 4.1.3 ステータスメッセージ 部分的 必須
41. WCAG 2．2のテスト(ガイドライン レベルAAA)1 達成基準 自動テスト 手動テスト 1.2.6 手話（収録済み） 不可能 必須 1.2.7 拡張音声解説（収録済み） 不可能 必須 1.2.8 メディアの代替（収録済み） 不可能 必須 1.2.9 音声のみ（ライブ） 不可能 必須 1.3.6 目的の特定 限定的 必須 1.4.6 コントラスト（強化） 多くのケースで可能 必須 1.4.7 背景音が小さいまたは無し 不可能 必須 1.4.8 視覚的な表現 限定的 必須 1.4.9 文字画像（例外なし） 不可能 必須 2.1.3 キーボード（例外なし） 限定的 必須
42. WCAG 2．2のテスト(ガイドライン レベルAAA)2 達成基準 自動テスト 手動テスト 2.2.3 タイミング不要 不可能 必須 2.2.4 中断 不可能 必須 2.2.5 再認証 不可能 必須 2.2.6 タイムアウト 不可能 必須 2.3.2 3回の閃光 部分的に可能 必須 2.3.3 インタラクションによるアニメーション 限定的に可能 必須 2.4.8 現在位置 限定的 必須 2.4.9 リンクの目的（リンクのみ） 部分的に可能 必須 2.4.10 セクション見出し 部分的に可能 必須 2.4.12 フォーカスの遮蔽防止（強化） 不可能 必須
43. WCAG 2．2のテスト(ガイドライン レベルAAA)3 達成基準 自動テスト 手動テスト 2.4.13 フォーカスの外観 限定的 必須 2.5.5 ターゲットサイズ（強化） 部分的 必須 2.5.6 同時入力メカニズム 不可能 必須 3.1.3 珍しい用語 不可能 必須 3.1.4 略語 限定的 必須 3.1.5 読解レベル 限定的 必須 3.1.6 発音 不可能 必須 3.2.5 要求による変化 不可能 必須 3.3.5 ヘルプ 不可能 必須 3.3.6 エラーの防止（すべて） 不可能 必須 3.3.9 アクセシブルな認証（強化） 限定的 必須
44. Lighthouseツールとは • Google Chrome、Microsoft Edgeに搭載されているブラウ ザーの診断機能 • この中のアクセシビリティ監査を利用 • 先に説明したとおり自動テストできる範囲はWCAGが定めるガイ ドラインの一部に過ぎない このため、今回の結果は対応状況の一部として捉えてください。
45. Azure Portalホーム画面（93点） • ARIA ロールに必要な子要素の欠落 • WAI-ARIA 仕様では grid ロールは row ロールを持 つ子要素（直接またはrowgroup経由）を含む必要があ ります。Lighthouse の検査時点でこの要件が満たさ れていないことが検出されました。 • 見出し要素の階層順序の不整合 • 「Azure サービス」というセクションタイトルが <h3> 要素として記述されていますが、その前に <h2> レベ ルの見出しが存在しない構造となっているため、見出し の階層が飛ばされていると判定されました。 • 互換性のない要素への ARIA ロールの使用 • HTML の各要素にはそれぞれ許可される ARIA ロー ルが規定されており、仕様で許可されていないロールを 要素に割り当てると、支援技術がその要素を正しく解釈 できなくなる可能性があります。（減点対象外）
46. App Service概要画面（100点） • 互換性のない要素への ARIA ロールの使用 • ホーム画面と同様に、「Uses ARIA roles only on compatible elements（互換性のある要素にのみ ARIA ロールを使用する）」という項目が指摘されまし た。この項目はスコア非対象ですが、ベストプラクティ スの観点から改善が推奨されています。 • サブスクリプションのクレジット残高を通知するトース ト表示であり、<li> 要素に role="alert" が割り当 てられています。 • もう一つの該当要素は、ユーザーフィードバックを求め るNPS（Net Promoter Score）形式のアンケート 通知です。「portal.azure.com をどの程度、友人や 同僚に勧めたいと思いますか？」という質問が0〜10 のスケールで表示されるポップアップであり、こちらも <li> 要素に role="alert" が設定されています。
47. App Service作成画面（100点） • 互換性のない要素への ARIA ロールの 使用 • ホーム画面と同様に、「Uses ARIA roles only on compatible elements（互換性 のある要素にのみ ARIA ロールを使用す る）」という項目が指摘されました。この項目 はスコア非対象ですが、ベストプラクティスの 観点から改善が推奨されています。 • サブスクリプションのクレジット残高を通知す るトースト表示であり、<li> 要素に role="alert" が割り当てられています。
48. Microsoft Foundry 概要画面（97点）1 • aria-hidden="true" 要素にフォーカス可能な子孫が含まれている • この要素は Tabster ライブラリ（Microsoft が開発したフォーカス管理ライブラリ）が自動生 成するダミー要素です。data-tabster-dummy 属性が付与されていることから、フォーカス トラップやフォーカス管理のための補助要素として配置されているものと推測されます。視覚的 には height: 1px; width: 1px; opacity: 0.001 のスタイルで実質的に不可視化されてい ますが、tabindex="0" によりキーボードフォーカスを受け取ることが可能な状態です。 この要素が検出された箇所は body#mlworkspace 直下、div.fui-Toolbar 内（2箇所）、 nav#nav-bar 内（2箇所）の合計5箇所以上に及びます。いずれもページのルート付近やナビ ゲーション、ツールバーといったフォーカス管理が重要な領域に配置されており、Tabster の フォーカス管理機構がこれらの境界にダミー要素を挿入していることがわかります。 aria-hidden="true" と tabindex="0" の組み合わせは WCAG の観点からは明確なア ンチパターンです。この問題を解消するには、ダミー要素に tabindex="-1" を設定するか、あ るいは別のフォーカス管理手法を採用する必要があります。 • ARIA ID の重複 • API キーの入力フィールドと Azure OpenAI エンドポイントの入力フィールドが、どちらも id="keyField" という同一の ID を持っています。HTML の仕様上、id 属性はドキュメント 内で一意でなければならないため、これは明確な実装上の問題です。おそらく同一のコンポーネ ントテンプレートが再利用された際に、ID のユニーク化が行われなかったものと推測されます。
49. Microsoft Foundry 概要画面（97点）2 • フォームフィールドへの複数ラベル • これは前述の ARIA ID 重複問題と根本的に同じ原因に起因 しています。API キーのフィールドとエンドポイントのフィー ルドが同一の id="keyField" を共有しているため、両方の <label> 要素の for 属性が同じ要素を指すことになり、結 果として1つのフィールドに2つのラベルが関連付けられた状 態になっています。 • 冗長な alt テキスト • ページヘッダー部分に配置された Microsoft Foundry の ロゴ画像に alt="Microsoft Foundry" が設定されてい ますが、この画像の直後に「Microsoft Foundry」というテ キストが表示されています。この結果、スクリーンリーダーで は「Microsoft Foundry Microsoft Foundry」のように 同じテキストが2回読み上げられることになります。
50. まとめ 画面 スコア スコア対象の指摘 ベストプラクティス指摘 Azure Portal ホーム 93点 ARIA必須子要素欠落、見出し 階層不整合 <li> への role="alert"（1件） App Service 概要 100点 なし <li> への role="alert"（2件） App Service 作成 100点 なし <li> への role="alert"（1件） Microsoft Foundry 概要 97点 aria-hidden 内のフォーカス 可能要素 ARIA ID重複、複数ラベル、冗長 alt（3件） Azure PortalとMicrosoft Foundryが異なるフレームワークで構築されていることに起 因する指摘事項の違いはあれどいずれも自動テストの範囲内で見えるのはとても品質が高い というところです。 残りの7割のテストは手動テストによるものですがそれでも相当にアクセシビリティに配慮し ていることがうかがえる点数となっています。
51. 宣伝 おしまい-
52. GitHub Copilot Dev Days Tokyo- .NETラボ 勉強会 2026年4月（4/25）
53. .NETラボ 勉強会 2026年5月（5/23） これのハンズオンを 2時間20分予定
54. Microsoft Buildを徹夜するBar（6/2） 収益で.NETラボの いらないもの交換会が豪華になります
55. くさば生誕祭 @ エデン日暮里(６/2６) 収益で.NETラボの いらないもの交換会が豪華になります
56. おしまい おしまい