WebView2上のダウンロード操作で、スクリーンリーダーが「download shortcut」を誤って案内する問題は、MicrosoftがPreview Runtime 152.0.4181.0で修正しています。対処の要点は、検証端末でWebView2を修正版Runtimeへ切り替え、アプリを完全終了してから再起動し、実際に使用中のRuntimeバージョンを確認したうえで、同じ操作を再テストすることです。(Microsoft Learn)
注意したいのは、1.0.4181-prereleaseはWebView2 SDKのバージョンであり、修正を含む実行環境のバージョンは152.0.4181.0だという点です。NuGetパッケージだけを更新しても、端末上で動作するWebView2 Runtimeが切り替わっていなければ、読み上げ問題は解消しません。(Microsoft Learn)
WebView2のダウンロード操作をスクリーンリーダーが誤読する問題とは
Microsoftは、2026年8月3日公開のWebView2 Preview Runtime 152.0.4181.0の修正内容として、スクリーンリーダーによる「download shortcut」の案内を修正したと記載しています。(Microsoft Learn)
この問題では、WebView2内でダウンロードに関係する操作を行った際、スクリーンリーダーが実際の状態や操作内容と一致しない案内を行う可能性があります。
スクリーンリーダー利用者は音声案内を手掛かりに操作するため、誤った案内が発生すると、次のような影響につながります。
- 実行可能なショートカットを誤認する
- ダウンロードが開始されたか判断できない
- フォーカス位置や次に行う操作が分からなくなる
- 同じ操作を繰り返し、複数回ダウンロードしてしまう
- アプリの操作を継続できなくなる
ただし、Microsoftのリリースノートには、誤って読み上げられていた具体的な文言、対象となるダウンロードUI、対象スクリーンリーダーまでは記載されていません。
そのため、「WebView2内のすべてのダウンロード読み上げ問題が修正された」と判断するのではなく、実際に発生していた操作手順を使って再テストする必要があります。
修正版のRuntimeとSDKを混同しない
今回の修正を確認するときは、RuntimeとSDKの違いを理解しておくことが重要です。
| 項目 | 対象バージョン |
|---|---|
| 修正を含む実行環境 | WebView2 Preview Runtime 152.0.4181.0 |
| 対応するSDK | WebView2 SDK 1.0.4181-prerelease |
| 公開日 | 2026年8月3日 |
| Microsoftの修正内容 | スクリーンリーダーによる「download shortcut」の案内を修正 |
| 主な対処 | 修正版Runtimeでアプリを起動し、読み上げを再テスト |
WebView2 SDKは、アプリを開発・ビルドするためのAPIやライブラリです。一方、WebView2 Runtimeは、ユーザー端末でWebコンテンツを表示し、アクセシビリティツリーやスクリーンリーダー連携を処理する実行環境です。
SDK 1.0.4181-prereleaseは、完全なAPI互換性を確保するためにRuntime 152.0.4181.0以降を必要とします。今回の読み上げ修正そのものは、SDKではなくRuntime側のバグ修正として掲載されています。(Microsoft Learn)
したがって、次のような対応では不十分です。
- NuGetパッケージだけを更新した
- プロジェクトを再ビルドしただけ
- Microsoft Edgeブラウザーだけを更新した
- HTMLやARIA属性だけを変更した
- スクリーンリーダーの設定だけを初期化した
最初に確認すべきなのは、問題が発生するアプリが実際にどのWebView2 Runtimeを読み込んでいるかです。
ダウンロードショートカットの誤読を修正する手順
現在の読み上げ内容とRuntimeバージョンを記録する
更新作業を始める前に、現在の状態を記録します。
最低限、次の情報を残してください。
| 記録項目 | 具体例 |
|---|---|
| アプリのバージョン | 2.4.1 |
| WebView2 Runtime | 151.0.xxxx.xx |
| Windows | Windows 11 24H2 |
| スクリーンリーダー | ナレーター、NVDA、JAWSなど |
| スクリーンリーダーのバージョン | テスト時点のバージョン |
| 表示言語 | 日本語 |
| 操作方法 | Tab移動後にEnter、ショートカットキーなど |
| 誤った読み上げ | 実際に聞こえた内容をそのまま記録 |
| ダウンロード結果 | 成功、失敗、複数回実行など |
読み上げ内容だけでなく、フォーカスがどこに移動したか、ダウンロードが実際に開始されたかも記録します。
更新前後で同じ条件を比較できなければ、Runtime更新によって直ったのか、別の設定変更によって挙動が変わったのか判断できません。
検証端末にMicrosoft Edgeのプレビューチャネルを用意する
WebView2のPrerelease SDKやPreview Runtimeを検証する場合、MicrosoftはMicrosoft EdgeのBeta、Dev、Canaryといったプレビューチャネルを利用する方法を案内しています。
特にCanaryは更新頻度が高く、新しいWebView2実装を早期に検証するためのチャネルとして推奨されています。プレビューチャネルにはWebView2 Preview Runtimeが含まれます。(Microsoft Learn)
本番端末へ一斉導入するのではなく、まず次のような検証環境で確認してください。
- 開発者のローカル端末
- QA専用端末
- 仮想マシン
- アクセシビリティ検証用端末
- 本番と同じWindows設定を再現したステージング環境
Prerelease SDKは変更される可能性があるため、Microsoftも本番アプリでの利用を避けるよう案内しています。Preview Runtimeで修正を確認した後、組織の方針に沿って、修正を含む安定版Runtimeへ展開するのが安全です。(Microsoft Learn)
WebView2がプレビューチャネルを使用するように設定する
Microsoft Edge Canaryをインストールしただけでは、WebView2アプリが自動的にCanaryを使用するとは限りません。
WebView2は通常、安定性の高いチャネルから順番に検索します。既定の検索順は次のとおりです。
WebView2 Runtime → Edge Beta → Edge Dev → Edge Canaryそのため、端末に通常版のWebView2 Runtimeがインストールされていると、Canaryを導入しても通常版Runtimeが選択される可能性があります。
ChannelSearchKindをLeastStableに設定すると、検索順を次のように反転できます。
Edge Canary → Edge Dev → Edge Beta → WebView2 Runtimeこの設定は、WebView2コントロールを初期化する前に行う必要があります。(Microsoft Learn)
.NETアプリでは、次のように検証用の環境を作成できます。
using System.Diagnostics;
using Microsoft.Web.WebView2.Core;
var options = new CoreWebView2EnvironmentOptions
{
ChannelSearchKind = CoreWebView2ChannelSearchKind.LeastStable,
ReleaseChannels = CoreWebView2ReleaseChannels.Canary
};
var environment = await CoreWebView2Environment.CreateAsync(
null,
null,
options);
await webView2.EnsureCoreWebView2Async(environment);
Debug.WriteLine(
$"WebView2 Runtime: {environment.BrowserVersionString}");ReleaseChannelsをCanaryに限定しているため、Canaryがインストールされていなければ環境の作成に失敗します。
これは一見不便ですが、検証では有効です。LeastStableだけを設定した場合、Canaryが見つからなければDev、Beta、通常版Runtimeへフォールバックします。その結果、修正版をテストしているつもりでも、実際には古いRuntimeを使っていたという状況が起こり得ます。
複数のチャネルを許可する場合は、ビットマスクとして指定できます。
ReleaseChannels =
CoreWebView2ReleaseChannels.Canary |
CoreWebView2ReleaseChannels.Dev |
CoreWebView2ReleaseChannels.Beta;ReleaseChannelsでは、検索対象とするチャネルを限定できます。Microsoftのドキュメントでも、実際に選択されたチャネルをバージョン取得APIで確認することが推奨されています。(Microsoft Learn)
アプリを完全終了してから再起動する
WebView2 Runtimeが更新されても、すでに起動しているWebView2ブラウザープロセスは、更新前のRuntimeを使い続ける場合があります。
Microsoftによると、新しいEvergreen Runtimeはダウンロード後、WebView2アプリを再起動したときに使用されます。継続稼働中のアプリでは、以前のRuntimeがそのまま使用されます。(Microsoft Learn)
検証時は、単に画面を閉じるだけでなく、次の手順を行います。
- WebView2を使用しているアプリを終了する
- タスクマネージャーでアプリのプロセスが残っていないことを確認する
- 必要に応じて関連するWebView2プロセスの終了を確認する
- アプリを再起動する
- 起動直後にRuntimeバージョンをログへ出力する
- 読み上げテストを実施する
環境変数、レジストリ、グループポリシーでチャネルを変更した場合も、すでに存在するWebView2ブラウザープロセスには設定が反映されません。
同じユーザーデータフォルダーを使う既存プロセスが残っていると、新しいRuntimeを検索せず、そのプロセスが再利用される場合があります。アプリの再起動、WebView2コントロールの再作成、または検証専用ユーザーデータフォルダーの使用で切り分けてください。(Microsoft Learn)
実際に使用中のRuntimeバージョンを確認する
Runtimeのインストール状況だけでなく、WebView2アプリが実際に選択したバージョンを確認します。
CoreWebView2Environment.BrowserVersionStringを使うと、現在のWebView2環境が使用しているバージョンを取得できます。プレビューチャネルの場合は、チャネル名も含まれます。(Microsoft Learn)
Debug.WriteLine(environment.BrowserVersionString);出力例は次のようになります。
152.0.4181.0 canaryアプリ初期化前に利用可能なRuntimeを調べる場合は、GetAvailableBrowserVersionStringも使用できます。
var version =
CoreWebView2Environment.GetAvailableBrowserVersionString(
null,
options);
Debug.WriteLine(version);ただし、BrowserExecutableFolder、ReleaseChannels、ChannelSearchKindにレジストリや環境変数による上書きがあると、コードで指定した内容とは異なるチャネルが選択される可能性があります。検証結果には、取得したバージョン文字列を必ず残してください。(Microsoft Learn)
修正後に行うスクリーンリーダーの再テスト
Runtimeの更新を確認したら、更新前と同じ操作を実行します。
最初は不具合が発生した条件を変えない
最初の再テストでは、スクリーンリーダーやアプリ設定を同時に変更しないことが重要です。
次の条件を更新前とそろえます。
- 同じアプリビルド
- 同じWebページ
- 同じユーザーアカウント
- 同じ表示言語
- 同じスクリーンリーダー
- 同じキーボード操作
- 同じダウンロード対象
- 同じフォーカス開始位置
Runtimeだけを変更して再現しなくなれば、今回のWebView2修正によって改善した可能性が高いと判断できます。
読み上げ内容だけでなく操作結果も確認する
次の項目を確認してください。
| 確認項目 | 合格の目安 |
|---|---|
| ダウンロード操作の案内 | 実際の操作と矛盾しない |
| ショートカットの案内 | 存在しない操作や誤ったキーを案内しない |
| 重複読み上げ | 同じ案内が不自然に繰り返されない |
| フォーカス | 操作後も利用者が現在位置を把握できる |
| ダウンロード開始 | 1回の操作で意図した回数だけ実行される |
| 完了通知 | ダウンロード結果を認識できる |
| キャンセル操作 | キーボードとスクリーンリーダーで操作できる |
| ダウンロード一覧 | 項目名、状態、操作ボタンを識別できる |
単に誤った文言が消えたかだけでなく、利用者がダウンロード開始から完了まで操作を継続できるかを確認します。
複数の操作経路をテストする
同じダウンロードでも、操作経路によってWebView2内の処理が異なる場合があります。
アプリで利用できる範囲で、次の経路を確認します。
- Tabキーでリンクへ移動し、Enterキーで実行
- アプリ独自のダウンロードボタン
- コンテキストメニュー
- キーボードショートカット
- ファイル名リンク
- ダウンロード確認画面
- 複数ファイルの連続ダウンロード
- ダウンロードのキャンセルと再実行
Microsoftのリリースノートでは、修正対象となった具体的な操作経路が示されていません。既存の再現手順を優先しつつ、周辺操作にも回帰がないか確認してください。
Runtime 152でも誤読が残る場合の切り分け
Runtime 152.0.4181.0以降を使用していても読み上げ問題が残る場合、今回修正された問題とは別の原因である可能性があります。
実際には古いRuntimeを使っていないか確認する
最も多い確認漏れは、Runtimeのインストールと実際の使用バージョンを混同することです。
次を再確認します。
BrowserVersionStringが152.0.4181.0以降になっているか- Canary、Dev、Betaなど目的のチャネル名が表示されているか
- アプリを完全終了したか
- 別のWebView2プロセスが残っていないか
BrowserExecutableFolderで古い固定バージョンを指定していないか- 環境変数で設定が上書きされていないか
- レジストリやグループポリシーでチャネルが固定されていないか
「端末にはRuntime 152がある」という確認だけでは不十分です。
アプリ側のARIA属性やフォーカス制御を確認する
特定の画面や独自ボタンだけで問題が続く場合は、アプリ側の実装も確認します。
確認対象は次のとおりです。
aria-labelと画面表示が矛盾していないか- 同じ要素に複数の名前が設定されていないか
title属性が不要な案内を追加していないか- ボタンに適切な要素や
roleが使われているか - 無効なARIA属性を指定していないか
- キーボードイベントを二重登録していないか
- ダウンロード開始後にフォーカスを失っていないか
- 非表示要素がアクセシビリティツリーに残っていないか
- ライブリージョンが同じ通知を繰り返していないか
WebView2 Runtimeの修正と、Webコンテンツ側のアクセシビリティ実装は別の層です。Runtimeを更新しても、不適切なARIA属性やフォーカス処理までは自動的に修正されません。
スクリーンリーダーごとの差を比較する
1種類のスクリーンリーダーだけで問題が起きる場合は、スクリーンリーダー固有の互換性問題も考えられます。
切り分けでは、まず問題が報告されたスクリーンリーダーで確認し、その後、利用環境に応じて別のスクリーンリーダーでも比較します。
| テスト結果 | 切り分けの目安 |
|---|---|
| 複数のスクリーンリーダーで同じ誤読 | WebView2またはWebコンテンツ側を重点確認 |
| 1種類だけで誤読 | スクリーンリーダー固有の挙動も確認 |
| 特定ページだけで誤読 | HTML、ARIA、JavaScript、フォーカス制御を確認 |
| すべてのダウンロード画面で誤読 | Runtimeとアプリ共通処理を確認 |
| 更新前だけで発生 | Runtime修正による改善の可能性が高い |
| 更新後も完全に同じ | 使用中Runtimeと再現条件を再確認 |
本番環境へ展開するときの注意点
Evergreen Runtimeを使用している場合
Evergreen Runtimeは自動更新される配布方式です。Microsoftは、多くのWebView2アプリでEvergreen Runtimeを推奨しています。(Microsoft Learn)
ただし、自動更新された直後に、起動中のアプリが新しいRuntimeへ切り替わるとは限りません。アプリが長時間起動し続ける構成では、更新後の再起動が必要です。(Microsoft Learn)
業務アプリでは、NewBrowserVersionAvailableイベントを利用し、新しいRuntimeが利用可能になったことをユーザーへ通知する方法もあります。
本番展開では、次の流れが安全です。
- Preview Runtimeで修正を確認する
- 修正を含む安定版Runtimeの提供状況を確認する
- QA環境で回帰テストを行う
- 一部ユーザーへ段階的に展開する
- スクリーンリーダー利用者の操作確認を行う
- 問題がなければ全体へ展開する
Fixed Version Runtimeを使用している場合
Fixed Versionでは、アプリが使用するRuntimeを開発側で固定します。クライアント上のRuntimeは自動更新されないため、修正版Runtimeをアプリパッケージへ組み込み、アプリと一緒に再配布する必要があります。(Microsoft Learn)
次の点を確認してください。
- 配布パッケージ内のRuntimeが更新されているか
browserExecutableFolderが新しいフォルダーを指しているか- 古いRuntimeフォルダーが参照されていないか
- アップデーターがRuntimeファイルを置き換えているか
- 更新後にアプリを再起動しているか
- ロールバック時に戻すRuntimeを保管しているか
Fixed Versionでは、OS上のEvergreen Runtimeを更新しても、アプリが同梱Runtimeを参照していれば動作は変わりません。
再発を防ぐためのアクセシビリティテスト
今回のような問題は、画面表示だけを確認するテストでは見落とされます。
WebView2アプリでは、通常のUIテストに加えて、次のテストを継続的に実施してください。
Runtimeバージョンをテスト結果へ記録する
不具合報告には、必ず次の情報を含めます。
App Version:
WebView2 SDK:
WebView2 Runtime:
Runtime Channel:
Windows Version:
Screen Reader:
Screen Reader Version:
Display Language:
Reproduction Steps:
Actual Announcement:
Expected Announcement:「最新版で発生した」という表現だけでは、後から再現できません。Runtimeの完全なバージョン番号とチャネル名を残すことが重要です。
安定版とプレビュー版を比較する
Microsoftは、安定版をベースラインとして、WebView2 Preview Runtimeとの比較テストを行うことを推奨しています。自動テストと手動テストを組み合わせることで、安定版へ変更が入る前にアプリ固有の問題を発見できます。(Microsoft Learn)
アクセシビリティテストでは、少なくとも次の2系統を用意すると効果的です。
- 現在の本番向けEvergreen Runtime
- Edge CanaryなどのWebView2 Preview Runtime
ダウンロード、ファイル選択、印刷、認証、ポップアップ、コンテキストメニューなど、ブラウザーUIに近い機能は重点的に確認します。
音声内容を人が確認する
自動テストでは、要素の名前、ロール、状態、フォーカス移動を検査できます。しかし、実際にどの順序で何が読み上げられ、利用者が次の操作を理解できるかまでは判断しにくい場合があります。
重要な操作は、スクリーンリーダーを有効にした手動テストを残してください。
特にダウンロードでは、次の一連の流れを確認します。
対象を見つける
→ ダウンロード操作を実行する
→ 開始を認識する
→ 進行状況または完了を認識する
→ ファイルを開く、保存場所を確認する
→ 元の画面へ戻る修正後も再現する場合は情報を整理して報告する
修正版Runtimeでも同じ問題が再現する場合は、最小構成で再現できるか確認します。
報告時には次の情報を整理してください。
- WebView2 Runtimeの完全なバージョン
- 使用チャネル
- WebView2 SDKのバージョン
- スクリーンリーダー名とバージョン
- Windowsのバージョン
- 表示言語
- 実際の読み上げ内容
- 期待する読み上げ内容
- 再現手順
- 最小限のHTML、CSS、JavaScript
- Runtime更新前後の比較結果
- 動画または音声記録
- 複数のスクリーンリーダーでの結果
Microsoftは、プレビューチャネルで問題を発見した場合、WebView2のフィードバックリポジトリへ報告し、Runtime Channelにプレビューチャネルであることを記載するよう案内しています。(Microsoft Learn)
まとめ
WebView2のダウンロード操作でスクリーンリーダーが「download shortcut」を誤って案内する問題は、Preview Runtime 152.0.4181.0で修正されています。
対応では、次の順序を守ることが重要です。
- 更新前の読み上げ内容とRuntimeバージョンを記録する
- 検証端末にWebView2 Preview Runtimeを含むプレビューチャネルを用意する
ChannelSearchKindやReleaseChannelsで検証対象を明示する- アプリを完全終了して再起動する
BrowserVersionStringで実際のRuntimeを確認する- 同じスクリーンリーダーと操作手順で再テストする
- 修正を含む安定版を確認してから本番へ段階展開する
最も避けたいのは、SDKだけを更新して「修正されなかった」と判断することです。まずアプリが使用しているRuntimeを確認し、152.0.4181.0以降の修正済み環境で読み上げを再検証してください。
コメント