Axe DevTools Mobile 2026年10月23日リリースノート

大規模または複雑なビュー階層を持つ画面をスキャンする際、 axeScan コマンドは完了するのに60秒以上かかる場合があります。AppiumのWebDriverAgent（WDA）プロキシは不明なコマンドにデフォルトで60秒のタイムアウトを適用し、 axeScan はそのカテゴリに該当します。スキャンがこの時間内に終了しない場合、WDAがリクエストをキャンセルし、テストはタイムアウトエラーをスローします。

WDAプロキシされたコマンドのタイムアウトを上書きするには、 axeScan、Appiumの設定に以下をお勧めします：

• appium:commandTimeouts: 240000 （4分）
• appium:wdaConnectionTimeout: 30000 （5分）

Note: appium:newCommandTimeout is a different setting. It controls how long Appium waits between commands from the test script. That is not the cause of this issue. The relevant setting is appium:commandTimeouts

Xcode 27を使用していて、モバイルアナライザーデスクトップアプリのバージョンが2.0.0より古い場合、アプリはiOSシミュレーターを開けません。実行しようとする際に失敗します。 /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app 解決するまでシミュレーターを使ったスキャンを開始できません。

Xcode 27上でシミュレーターを使ってスキャンを実行するためには、デスクトップアナライザーをバージョン2.0.0以上にアップデートしてください。このアップデートにより、アクセシビリティの結果は Axe Developer Hub。

Axe DevTools SDKは、AppleのVisionフレームワークを使用して画面上のテキストを読み取り、いくつかのアクセシビリティルール（例：色のコントラスト、衝突するビュー、Visionで検出されたテキストに依存するルール）に適用します。

Visionは、同じ画面の異なる実行間で常に同じ検出されたテキストを返すわけではありません。Visionがコントロール上のテキストを見逃すと、そのテキストに依存するルールはそのスキャンで実行されません。同じ画面の2つのスキャン間で結果が一貫しないように見えることがあります—あるスキャンで失敗する問題が次のスキャンで見当たらないことがあります。

Visionベースのルールが失敗を報告する場合、その失敗自体は正確です。一貫性がないのはルールが実行されるかどうかです。この問題を克服するために、次のことを試してください：

• スキャンを再実行します。コントロールでVisionベースのルールがスキップされた場合、同じ画面の別のスキャンで取り上げることがよくあります。
• Visionベースのルールの失敗は有効として扱います。色のコントラストがコントロールを示した場合、そのコントラストの問題は実際に存在し、対処する必要があります。
• 手動検証のために、関連するWCAG成功基準についてDeque Universityの参照を使用してください。（リンクは各ルールページの下部にあります。）

iOS 26以降では、画面にテキストラベル「50％オフ」のようなパーセント記号が含まれている場合、動的タイプのサポートルールは合格または不合格ではなく、不完全として報告されることがあります。このルールはAppleによるアクセシビリティ監査に依存しており、その監査はパーセント記号に遭遇するとテストランを停止します。テストを続行するため、私たちのルールはその画面のチェックをスキップし、パーセント記号を含む各要素に対して不完全を報告します。他のルールはその画面で通常どおり実行され、他の画面には影響はありません。

特に行動を取る必要はありません。スキャンは完了します。これらの画面で動的タイプ対応を確認するには、デバイスの**設定** > **アクセシビリティ** > **表示とテキストサイズ** > **大きな文字**でテキストサイズを増やし、画面上のテキストが適切にスケールすることを確認してください。この問題はAppleに報告されました。（#2985）

色のコントラストルールはAppleのVisionフレームワーク（光学文字認識、OCR）を使用して要素の境界内のテキストを読み取ります。OCRは時折、小さなアイコンのような字形—例：後ろ向きの矢印のシェブロン（<）、箇条書き、装飾的な記号—をテキストとして誤認識することがあります。その場合、色のコントラストルールは読み取り可能なテキストを含まない要素に対して適用され、アイコンのみのボタンに結果をもたらすことがあります。OCRの出力がスキャン間で決定的でないため、同じ要素があるスキャンで色のコントラストの結果に現れることもあり、次のスキャンでは「該当なし」と報告されることもあります。これはOCRの既知の特性であり、ルールのバグではありません。

この問題を回避するには、 ignore APIを使用して影響を受けた要素の色のコントラスト結果を抑制できます。

Flutterは AppBar.title をネイティブのスクリーンタイトルプロパティにマッピングしないため、 UIViewController.title、スクリーンタイトルルールがすべてのFlutterスクリーンで失敗します。説明的なタイトルが存在するかどうかにかかわらず。

これは、 flutter/flutter#185894。

小さな画面サイズまたは小さなフォントサイズでアクセシビリティチェックを実行する場合、色のコントラストルールはグラデーション背景に対して誤検出を報告することがあります。このような場合、前景色を決定できず、代わりに背景色同士を比較し、その結果として失敗となります。

この問題を回避するには、大型デバイスでアクセシビリティチェックを実行してみてください。または、テストでそのルールを無視し、これらのビューの色のコントラストを手動で確認することができます。

AppleのアクセシビリティAPIが、WKWebView内のウェブコンテンツをすすに「isVisible」と誤って報告することがあります。ネイティブオーバーレイ（モーダルビュー、アラート、その他のネイティブUI要素）で覆われている場合でも、アクセスビリティシステムはWKWebViewコンテナ自体が表示されているかどうかをチェックしますが、そのウェブコンテンツが実際に遮られているかどうかや、ユーザーに知覚可能であるかどうかはチェックしません。

iOS 26には、デフォルトのステッパーボタンが無効であることを示す「ディムド」という情報を支援技術が発表しないというアクセシビリティバグがあります。結果として、そのボタンが無効であるにもかかわらずiOSルールもそれらを有効として認識します。この問題はAppleに報告されていますが、解決されるまでは以下のルールが無効なステッパーボタンに対して結果を報告する可能性があります： AssociatedText、 InaccessibleAction、および ColorContrast。

Appleがこのバグを修正するまで、解決策は[ルールを無視する](ios-ignore-rule)ことです。デフォルトのステッパーボタンには「減少」と「増加」という識別子があり、必要であれば識別子で無視することができます。

Our Color Contrast rule depends on Machine Learning to detect text, which ensures that the text being scanned is visible to users of your application. In cases where the text contained in a view is the same color as the background, our Machine Learning algorithm is unable to detect if any text is present, so the Color Contrast rule does not run on this view.

いくつかの画面では LabelInName 、および LabelAtFront が誤って検出されることがあります (#1622) due to an incorrect associatedText プロパティが発見されたため（#1622）

ルールの改善を検討している際、XCTestで入れ子になったコントロールがアクセシビリティツリーに返されないことが判明しました。Appleにバグ報告がなされています。（#1110）

UIKitアプリでは、`accessibilityLabel`がない画像はデフォルトで支援技術でフォーカスできません。
Appleから焦点可能性をチェックするために使用するプロパティは、画像に `accessibilityIdentifier` が設定されている場合、正確でないことがあります。この予期しない動作により、UIKitアプリでのImageView Nameの問題の結果が要再確認として報告されます。Appleにバグ報告がされています。（#1633）

これらの誤検出の修正に積極的に取り組んでおり、修正がリリースされると、このリストを更新します。

In Scroll View
バナービヘービング要素、固定ヘッダー/フッター、フローティングアクションボタン、カスタムタブビュー内のテキストには、「要再確認」または「失敗」メッセージが表示される場合があります。これらの要素を大きなテキストを必要とする人々に利用可能にするため、 UILargeContentViewer。（#622、#2077）

v2.11.0 Image View Name & Active Control Name
UIImageViewに accessibilityIdentifier が設定されているが、VoiceOverでフォーカスできず、その中にフォーカス可能なコントロールがネストされている場合、Active Control NameがUIImageViewで誤検出される可能性があります。この accessibilityIdentifier を削除すると問題が解決します。Appleにバグが報告されています。（#1633）

Label In Name and Label At Front
これらの2つのルールは、コントロールの可視ラベルを近くの要素の中から探し、ルールの状態を判断します。一部のビュー階層では、誤った近くのテキストが検出され、これらのルールが失敗する原因となることがあります。（#1622）

Android Accessibility AnalyzerのFloating Action Button（FAB）は、バージョン16.2より古いTalkbackのスワイプナビゲーションでは動作しません。バージョン16.2のリリースにより、Talkbackはコード内のバグを修正し、オーバーレイFABのスワイプフォーカスが可能になりました。

これはTalkbackのバグにすぎません。アクセシビリティオーバーレイでレンダリングされたFABがスワイプでフォーカスを得たり失ったりすることができませんでした。最近のAccessibility Analyzerアプリのアップグレードにより、より多くのアプリタイプをスキャンできるようになったため、この問題を今目撃したかもしれません。

この問題は、Talkbackをバージョン16.2以降に更新することで解決できます。

Label at Frontルールは、要素の可視ラベルが発表されるテキストの最初に来ることを確認します。インタラクティブ要素の可視テキストに略語（例: "GB"、"km"）や隠され/切り取られた識別子が含まれていて、アクセシビリティ発表が表現された単語（例: "ギガバイト"、"キロメートル"）で構成されている場合、ルールの失敗が起こる可能性があります。これは略語や切り取られた内容をスクリーンリーダー対応にするための推奨パターンにもかかわらずです。

インタラクティブ要素の可視ラベルの最初の部分がスクリーンリーダー発表の冒頭と一致し、略され/隠された部分のみが異なる場合、その結果は無視して問題ありません。スクリーンリーダーで全体の発表が意図した通りに読まれることを確認してください。

「連絡先アイコン」などのビューで装飾的なテキストを使用する場合、アクセシビリティの問題を引き起こす可能性があります。テキストビューを使用して目的の文字をベクトルとして画像を生成する代わりに文字を表示し、そのテキストビューをアクセシビリティの観点で重要でないと宣言した場合、アクセシビリティ違反を引き起こしたかどうかを確実に判断することはできません。

フォーカス可能なテキストを編集して2文字以下を無視すると、さまざまな言語で1単語のボタン（例: "OK"、"No"、"Sí"）を誤って無視する可能性があります。これらの問題を避けるためには、アイコンで表現したい単語から目的の文字を取得し、それを画像の一部として生成してください。そうすれば、`FocusableText`はこれらのビューに対しては実行されません。

Flutterは AppBar.title をネイティブのスクリーンタイトルプロパティにマッピングしないため、 Activity.setTitle、スクリーンタイトルルールがすべてのFlutterスクリーンで失敗します。説明的なタイトルが存在するかどうかにかかわらず。

これは、 flutter/flutter#185894。

いくつかのケースでは、支援技術は AccessibilityEvent Androidシステムからの説明に依存して、他の発表がないときに情報をユーザーに知らせます。その理由は、 AccessibilityEventがユーザーのアクションによってトリガーされるため、この情報が提供されていない場合、正しい説明にアクセスすることができません。

この問題を避けるために、関連するすべてのビューがアクセシビリティの観点で重要としてマークされていることを確認してください。これにより、Talkbackがビューから情報にアクセスでき、私たちのツールがそれを検出できるようになります。

私たちの色のコントラストルールは、テキストがアプリケーションのユーザーに表示されていることを確認するためにマシンラーニングに依存しています。ビュー内のテキストが背景と同じ色である場合、私たちのマシンラーニングアルゴリズムはテキストが存在するかどうかを検出できません。そのため、色のコントラストルールはこのビューで実行されません。

XMLで書かれたアプリがヒントテキスト機能を利用していると、 EditTextName ルールで誤検出される可能性があります。ヒントテキストはAndroid 8（SDK 26）まで導入されていません。XMLアプリでこの要素を使用すると、テキスト入力フィールドの値にヒントテキストが割り当てられます。Androidの最新バージョンは、この体験をアクセシブルにするのにより適しています。

この問題を解決するためには、まずテストをAndroidの新しいバージョンで実行することをお勧めします。しかし、それが古いAndroidバージョンでアプリをアクセシブルにするうえで重要であれば、この hintText 機能の使用を避けることを検討してください。それは公式にサポートされていません。

画面上の他のビューに隠されたビューの結果が表示されることがあります。これらの非表示ビューは支援技術には利用できませんが、Axe DevTools Mobileはそれらを問題として報告します。

この複雑な問題に対する修正に取り組んでいます。その間に、TalkBackがこれらのビューに到達できない場合は、対応する問題を無視することができます。アクセシビリティを確保するための修正は不要です。

ML Kitテキスト検出は、結果の正確性を保証するためにAxe DevTools Mobileの多くのルールで必要です。ML Kitライブラリは、Axe DevTools Mobileを参照するときに自動的にインポートされるべきです。しかし、場合によっては自動インポートが行われず、logcatに以下のエラーが表示されます：

タッチターゲット間隔ルールは、現在Jetpack Composeで記述されたスライダーコンポーネントでは実行されていません。現時点では対応できませんが、修正は近々予定されています！

Android API 30では、ローカルに結果を保存しようとする場所の1つにパーミッションエラーがあります。このエラーが表示されるにもかかわらず、結果はJSONファイルとして保存されます。このエラーは、次のブロックのコードをコメントアウトすることで抑制できます：

一部のハイブリッドおよびクロスプラットフォームアプリでは、スクロールビュー内のアイテムが画面外に部分的に見えると、予期しない結果が返されることがあります。要素をアクセシブルかどうかテストするためには、スキャンを行う前に完全に画面上に表示されていることを確認してください。

Android 12（API 31）で導入されたのは、非システムオーバーレイを非表示にする機能です。Axe Analyzerアプリを利用するには、この設定がオンになっていないことを確認してください。セキュリティ強化のためにこの機能を利用することを選択した場合は、内部テストビルドで設定をオフにしてテストデータを安全に活用し、セキュリティ上の懸念を解消することをお勧めします。 Note: this setting does not affect Google's accessibility scanner app as it's considered a system overlay.

Axe Accessibility Analyzerアプリを利用するためには、メソッドを setHideOverlayWindows(true) に更新してください setHideOverlayWindows(false) 影響を受けたアクティビティウィンドウで。

Axe DevTools for Mobileの完全な機能を解放するには、スクリーンショットを有効にしてください。セキュリティ上の懸念を避けるために、モックデータを使用するデバッグまたはテストバージョンのアプリでスクリーンショットを有効にすることをお勧めします。Androidアプリでの スクリーンショットの有効化ガイドをご覧ください。

ビルドを縮小する際、Axe DevToolsライブラリへのログイン時にアダプターが見つからなかったというエラーログとともにクラッシュすることがあります。Axe DevToolsを実装したデバッグビルドでは縮小を無効にしてください。 (#729)

r8が有効化されたビルドは、axeDevToolsライブラリの縮小を試みることで以下のようなエラーが発生することがあります。

Compose APIは非推奨です。引き続き更新を受け取るには レイアウトに依存しないAPI を使用してください。Compose APIを使用し続け、「(isRoot)を満たすノードが「1」個のはずが「2」個見つかりました」という内容や「ビューが初期化されていません。AxeDevToolsCompose.setComposeTestRule()を呼び出しましたか？」というエラーが発生した場合は、以下を参照してください。 Compose setTestTag API。

AndroidエコシステムでのMAUIアプリアーキテクチャのレンダリングの制約により、SDKバージョン5.5.0以降で失敗が疑われる場合、Edit Text Nameルールはダッシュボードで見直しが必要として表示されます。この場合、正しい動作を手動で確認してください。

ネイティブコントロールを拡張しないカスタムダイアログやモーダルを実装する際、モーダル背後のビューに対する結果を取得することがあります。この場合、これらのカスタムモーダルやダイアログに対してツールを実行せず、代わりに支援技術が期待通りに機能することを確認するために手動でチェックすることをお勧めします。

スキャン詳細ページにスクリーンショットが表示されない場合、アプリがスクリーンショットの撮影を禁止している可能性があります。これはよく、製品アプリケーションにおけるセキュリティ上の理由によるものです。Axe DevToolsモバイルダッシュボードでの機能を完全に利用できるようにするため、テストビルドではこの要件を削除することを検討してください。

• Android - FLAG_SECURE

デフォルトで画面タイトルに設定されている一部のAndroidスキャン名は、バンドル識別子を含むフルクラス名として表示されます。将来のリリースでは、画面タイトルがより読みやすい名前にフォーマットされるように解決されます。代替策として、ダッシュボードやフレームワークからスキャン名を設定することができます。 (#1643)