Axe DevTools Mobile 2026年9月8日リリースノート

このステータスは廃止予定であり、2026年10月に削除されます。その時、無視されたルールはイテレーションでスキップされ、結果を返さなくなります。

注意してください AxeDevTools itself は、廃止されていません。以下のメソッドは、2026年10月のリリースで置き換えられるか完全に削除されます。

• ignoreByViewIdResourceName(viewIdResourceName: String, ruleList: List) （に置き換えられる予定 ignoreRulesOnElementWithId(id: String, vararg rules: AxeRuleName)）
• ignoreRules(rulesToIgnore: List)
• resetIgnoredRules()
• tagScansAs(tag: TagSet)
• deleteResult(axeDevToolsResultKey: AxeDevToolsResultKey)
• getResult(axeDevToolsResultKey: AxeDevToolsResultKey)

• getResult()
• postResult()
• deleteResult()
• tag()
• setScanName()
• getUserInfo()
• getResultSync()
• postResultSync()
• deleteResultSync()
• tagSync()
• setScanNameSync()
• getSessionId()
• BASE_FRONTEND_URL
• DB_DEFAULT_URL
• DB_QA_URL
• DB_DEV_URL

実験的ルールの概念は、10月のリリースで完全に削除されます。同じことがタグにも当てはまります - それらはモバイルダッシュボードの廃止に伴い消滅します。

これらのルールは実験的であり、昇格されていませんでした。それらは我々のルールイテレーションから削除されました。

• AxeDevToolsResultKey
• AxeDevToolsResultSummaryResponse
• ConnectionConfig - これに置き換わる予定です dbUrl 単一引数のコンストラクタ
• class TagsSet()
• 実験的なルールは昇格されるか削除されます

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

Visionは、同じスクリーンでの実行間で常に同じ検出されたテキストを返すとは限りません。コントロール上でテキストを見落とした場合、そのテキストに依存するルールはその要素に対して実行されません。発見事項は、同じスクリーンの2回のスキャン間で一貫しないように見えるかもしれません - あるスキャンで失敗した問題が次のスキャンで欠如していることがあります。

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

• スキャンを再実行します。Visionベースのルールがコントロールに対してスキップされた場合、同じスクリーンの別のスキャンでそれが捕捉されることがよくあります。
• Visionベースのルールの失敗を妥当として扱います - もしカラーコントラストがコントロールをフラグした場合、そのコントラストの問題は実際に存在し、対処すべきです。
• 手動検証には、Deque大学の関連するWCAG成功基準のリファレンスを使用してください。（各ルールのページの下にリンクがあります。）

iOS 26以降では、スクリーンにパーセント記号を含むテキスト（例: 「50%オフ」と表示されるテキストラベル）が含まれている場合、Supports Dynamic Typeルールはパスまたは失敗ではなく不完全と報告されるかもしれません。このルールはAppleが提供するアクセシビリティ監査に依存しており、その監査はパーセント記号に遭遇した際にテストの実行を停止します。テストを続行するために、我々のルールはそのスクリーンでのチェックをスキップし、パーセント記号を含む各要素に対して不完全と報告します。他のルールはスクリーン上で通常通り実行され、他のスクリーンには影響しません。

アクションは不要です。スキャンは完了します。これらのスクリーンのダイナミックタイプサポートを確認するには、**設定** > **アクセシビリティ** > **表示とテキストサイズ** > **大きなテキスト**でデバイスのテキストサイズを大きくし、スクリーン上のテキストが適切にスケールすることを確認してください。この問題はAppleに報告されています。（#2985）

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

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

Flutterは AppBar.title をネイティブの画面タイトルプロパティにマップしません - UIViewController.title、これにより記述的なタイトルが存在するかどうかにかかわらず、すべてのFlutterスクリーンで画面タイトルルールが失敗します。

これは、次で追跡されているFlutterの既知のプラットフォーム制限です: flutter/flutter#185894。

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

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

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

iOS 26には、デフォルトのステッパーボタンがAssistive Technologyで「減光」と発表されず、無効であることを示すアクセシビリティのバグがあります。その結果、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.

一部の画面では、誤ったassociatedTextプロパティが見つかったために、LabelInNameとLabelAtFrontで誤検知が報告されることがあります (#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)

Label at Frontルールは、要素の可視ラベルが発表されたテキストの開始位置にあることを確認します。インタラクティブな要素の可視テキストに省略形（例: 「GB」、「km」）または隠された/切り取られた識別子が含まれ、アクセシビリティ発表が表現された単語（例: 「ギガバイト」、「キロメートル」）で構成される場合、ルール違反が発生する可能性がありますが、これが省略形または切り取られたコンテンツをスクリーンリーダーフレンドリーにするための推奨パターンです。

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

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

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

Flutterは AppBar.title をネイティブの画面タイトルプロパティにマップしません - Activity.setTitle、これにより記述的なタイトルが存在するかどうかにかかわらず、すべてのFlutterスクリーンで画面タイトルルールが失敗します。

これは、次で追跡されているFlutterの既知のプラットフォーム制限です: flutter/flutter#185894。

一部のケースでは、支援技術が AccessibilityEvent Androidシステムからの説明を利用して、他のアナウンスが利用できない場合にユーザーに情報を伝えます。 AccessibilityEventはユーザーの操作によってトリガーされるため、情報が提供されていない場合に正確な説明にアクセスできません。

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

色のコントラストルールは、ユーザーに見えるようにテキストを検出するために機械学習に依存しています。ビュー内のテキストが背景と同じ色の場合、機械学習アルゴリズムはテキストが存在するかどうかを検出できないため、このビューで色のコントラストルールは実行されません。

XMLで書かれたアプリでヒントテキスト機能を利用している場合、 EditTextName ルールで誤検知が生じることがあります。ヒントテキストはAndroid 8 (SDK 26)で導入されました。この要素をXMLアプリで使用すると、ヒントテキストがテキスト入力フィールドの値に割り当てられます。より新しいバージョンのAndroidはこの体験をよりアクセシブルに提供します。

この問題を解決するために、最初の推奨は新しいバージョンのAndroidでテストを行うことです。ただし、アプリが初期のAndroidバージョンでもアクセシブルであることが重要な場合、この hintText 機能を使用しないことを検討するかもしれません。公式サポートされていません。

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

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

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

現在、Jetpack Composeで作成されたスライダーコンポーネントにはタッチターゲット間隔ルールが適用されていません。現時点では対策は取られていませんが、修正が間もなく行われる予定です！

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

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

API 31（Android 12）で導入されたのは、非システムオーバーレイを非表示にする機能です。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が実装されているデバッグビルドではminifyを無効にしてください。（#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。

AndroidエコシステムでのMAUIアプリ構造の制約により、SDKバージョン5.5.0以上ではEdit Text Nameルールがダッシュボードで「要レビュー」と表示されます。リストを確認して正しい動作を手動で確認してください。

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

スキャン詳細ページにスクリーンショットが見つからない場合、アプリがスクリーンショット撮影を妨げている可能性があります。これは通常、製品版アプリケーションのセキュリティのためです。この要件をテストビルドから削除し、Axe DevTools Mobileダッシュボードでの完全な機能を可能にすることを検討してください。

• Android - FLAG_SECURE

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