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

Xcode 27を使用していて、Mobile Analyzer Desktopアプリが2.0.0より古い場合、アプリはiOSシミュレーターを開くことができません。 /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app シミュレーターを基にしたスキャンを開始することができません。

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

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

Visionは同じ画面の複数回の実行間で同じ検出テキストを常に返すわけではありません。Visionがコントロールのテキストを逃すと、そのテキストに依存するルールはその要素に対してそのスキャンで実行されません。同じ画面の2回のスキャン間で結果が不一致に見える場合があり、あるスキャンで失敗した問題が次のスキャンでは存在しないことがあります。

Visionベースのルールが失敗を報告した場合、その失敗自体は正確です。不一致は、そのルールが実行されるかどうかです。この問題を解決するために、以下の方法を試してください:

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

iOS 26以降では、テキストにパーセント記号が含まれている画面（例："50%オフ"と表示されるテキストラベル）では、Supports Dynamic Typeルールは合格や不合格ではなく不完全と報告されることがあります。このルールはAppleが提供するアクセシビリティ監査に依存しており、その監査はパーセント記号が含まれるとテスト実行を停止します。テストを続行するために、我々のルールはその画面のチェックをスキップし、パーセント記号を含む各要素について不完全と報告します。他のすべてのルールはその画面で正常に動作し、他の画面には影響しません。

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

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

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

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

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

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

この問題を回避するために、より大きなデバイスでアクセシビリティチェックを試みるか、ルールをテストで無視して、これらのビューのカラーコントラストを手動で確認することを選択できます。

AppleのアクセシビリティAPIは、WKWebView内のWebコンテンツを誤って「isVisible」と報告することがあります。これは、アクセシビリティシステムがWKWebViewコンテナ自体が表示されているかどうかをチェックするためであり、そのWebコンテンツが実際に妨げられず、ユーザーに知覚可能かどうかを確認していないからです。

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`がない画像は通常、支援技術ではフォーカスできません。
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)

前面ラベルルールは、要素の可視ラベルがそのアナウンスされたテキストの冒頭に来ることをチェックします。インタラクティブな要素の可視テキストに省略形（例：「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 モバイルはそれらを問題として報告します。

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

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

タッチターゲット間隔ルールは、現在Jetpack Composeで書かれたスライダーコンポーネントで実行されていません。この時点では何の対応もできません。ただし、修正は間もなく公開されます！

Android API 30では、結果をローカルに保存しようとする場所の一つに権限エラーがあります。このエラーが表示されても、結果は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 Accessibility Analyzerアプリを使用するには、影響を受けるアクティビティウィンドウで呼び出すメソッドを更新してください 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）