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

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

WDAプロキシ経由のコマンドのタイムアウトを⟦0⟧などのコマンド用にオーバーライドするには、 axeScanAppiumの機能設定で以下の設定をお勧めします。

• 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より古いMobile Analyzer Desktopアプリを実行している場合、アプリはiOSシミュレーターを開くことができません。起動しようとすると失敗します。 /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app この問題が解決するまで、シミュレーターを使用したスキャンを開始することはできません。

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

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

Visionは同じ画面を実行するごとに同じ検出テキストを返すとは限りません。Visionがコントロール上のテキストを認識しないと、そのテキストに依存するルールはそのスキャン中、その要素では実行されません。同じ画面の2回のスキャンで結果が不一致になる場合があります - 1回目のスキャンで失敗した問題が次回では存在しないことがあります。

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

• スキャンを再実行します。コントロールのVisionベースのルールがスキップされた場合、同じ画面の別のスキャンでそれを拾うことが多いです。
• Visionベースのルールの失敗を有効と見なします - カラーコントラストがコントロールをフラグした場合、そのコントラスト問題は本物であり、対処すべきです。
• 手動で確認する場合は、関連するWCAG成功基準に関するDeque Universityのリファレンスを使用してください。（各ルールページの下部にリンクがあります。）

iOS 26以降では、テキストにパーセント記号が含まれている画面（例：「50% Off」と表示されるテキストラベル）では、動的タイプサポートのルールがパスまたは失敗ではなく、不完全として報告される場合があります。このルールは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には、Assistive Technologyがデフォルトのステッパーボタンが有効ではないことを示す「曇り」とアナウンスしないアクセシビリティバグがあります。そのため、iOSのルールもこれらのボタンは有効であると見なしますが、実際にはそうではありません。バグ報告はAppleに送信されていますが、これが解決されるまで、以下のルールは無効化されたステッパーボタンに対しても結果を報告する可能性があります： AssociatedText、 InaccessibleAction、および ColorContrast。

Appleがこのバグを修正するまで、[ルールを無視する](ios-ignore-rule)のが解決策となります。デフォルトのステッパーボタンは「Decrement」と「Increment」の識別子を持ち、必要に応じて識別子で無視できます。

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 の誤検出が報告される場合があります。 associatedText (#1622) が見つかった不正なプロパティ

ルールの改善を検討する中で、XCTestでネストされたコントロールがアクセシビリティツリーで返されないことがわかりました。バグ報告はAppleに送信されました。 (#1110)

UIKitアプリでは、`accessibilityLabel`がない画像は、デフォルトで支援技術でフォーカスされません。
画像に`accessibilityIdentifier`が設定されている場合、Appleからのフォーカス可能性をチェックするために使用されるプロパティが不正確である可能性があります。この予期しない動作により、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アクセシビリティアナライザーのFloating Action Button（FAB）は、Talkbackバージョン16.2以前のTalkbackスワイプナビゲーションと互換性がありません。16.2のリリースにより、TalkbackはオーバーレイFABのスワイプフォーカスを許可するためのバグを修正しました。

これは純粋にTalkbackのバグであり、アクセシビリティオーバーレイでレンダリングされたFABがスワイプを介してフォーカスを得たり失ったりすることを許可しませんでした。我々のアクセシビリティアナライザーアプリの最近のアップグレードにより、より多くのタイプのアプリをスキャンできるようになったため、今になってこの問題を見ることがあるかもしれません。

この問題は、Talkbackをバージョン16.2以降にアップデートすることで解決できます。

Label at Frontルールは、要素の可視ラベルが発表されたテキストの冒頭に来ることを確認します。インタラクティブ要素の可視テキストが略語（例：「GB」「km」）や隠された／切り取られた識別子を含んでいる場合、アクセシビリティ発表が（例：「ギガバイト」「キロメートル」）などの表現された単語で構成されていると、ルールが失敗する可能性がありますが、これは略語や切り取られたコンテンツをスクリーンリーダーフレンドリーにするための推奨パターンです。

インタラクティブ要素の可視ラベルの最初の部分が、スクリーンリーダーの発表の冒頭と一致し、略語化／隠された部分のみが異なる場合、フラグされた結果は安全に無視できます。発表が意図したとおりに読まれることをスクリーンリーダーで確認してください。

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

フォーカス可能なテキストを編集して2文字以下を無視する場合、さまざまな言語で多くの一語ボタン（例：「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ライブラリは、EspressoまたはUIAutomatorの自動化されたテストでAxe DevTools Mobileを参照する際に自動的にインポートされるべきですが、場合によっては、自動インポートが行われず、logcatで次のエラーが表示されます。

タッチターゲットスペーシングルールは、現在Jetpack Composeで書かれたスライダーコンポーネントでは実行されていません。現時点では対策はできませんが、修正がまもなく行われます！

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

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

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

Axeアクセシビリティアナライザーアプリを利用するには、使用されているメソッドの呼び出しを更新してください。 setHideOverlayWindows(true) を。 setHideOverlayWindows(false) 影響を受けるアクティビティウィンドウで

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

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

r8が有効な状態でビルドを行うと、axeDevToolsライブラリを縮小化しようとして、次のようなエラーが発生する可能性があります。

Compose APIは非推奨となっているため、 レイアウトに依存しないAPI を使用して更新を受け取り続けてください。Compose APIを使用し続け、`Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` または `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?` のようなエラーが発生した場合は、 Compose setTestTag API。

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

ネイティブコントロールを拡張しないカスタムダイアログやモーダルを実装している場合、モーダルの背後にあるビューの結果が得られることがあります。この場合、これらのカスタムモーダルやダイアログに対してツールを実行せず、手動で支援技術と連携するかどうかを確認することをお勧めします。

スキャン詳細ページでスクリーンショットが欠けている場合、アプリがスクリーンショットの取得を妨げている可能性があります。多くの場合、これは本番アプリケーションのセキュリティ上の理由です。テストビルドでこの要件を削除し、Axe DevToolsモバイルダッシュボードでフル機能を利用できるように検討してください。

• Android - FLAG_SECURE

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