Axe DevTools Mobile August 5, 2026 Release Notes

On iOS 26 and later, if a screen contains text with a percent sign in it (e.g. a text label reading "50% Off"), the Supports Dynamic Type rule may report as Incomplete instead of a pass or fail. This rule relies on an accessibility audit provided by Apple, and that audit stops the test run when it encounters percent signs. To keep your tests running, our rule skips the check for that screen and reports incomplete for each element containing a percent sign. All other rules run normally on the screen, and other screens are unaffected.

No action is required, since your scan will still complete. To check Dynamic Type support for these screens, increase the text size on your device under **Settings** > **Accessibility** > **Display & Text Size** > **Large Text**, and confirm the text on the screen scales appropriately. This issue has been reported to Apple. (#2985)

The Color Contrast rule uses Apple's Vision framework (Optical Character Recognition, or OCR) to read text inside an element's bounds. OCR can occasionally misidentify small icon-like glyphs - such as back-arrow chevrons (<), bullets, decorative symbols - as text. When that happens, the Color Contrast rule runs on an element that contains no readable text, which can produce a result for an icon-only button. Because OCR output isn't deterministic across scans, the same element may appear in Color Contrast results in one scan and be reported as "INAPPLICABLE" in the next. This is a known characteristic of OCR, not a bug in the rule.

To work around this issue, you can use the ignore APIs to suppress Color Contrast results for the affected elements.

// Ignore Color Contrast for a specific element by accessibility identifier
axeDevTools?.configuration.ignore(rulesFor: [
    "backButton": [AxeRuleId.ColorContrast.toString()]
])

// Or ignore Color Contrast globally
axeDevTools?.configuration.ignore(rule: AxeRuleId.ColorContrast.toString())

Learn more about ignoring rules.

Flutter does not map AppBar.title to the native screen title property - UIViewController.title, causing the Screen Title rule to fail on all Flutter screens regardless of whether a descriptive title is present.

This is a known Flutter platform limitation tracked in flutter/flutter#185894.

When running accessibility checks on smaller screen sizes or with smaller font sizes, the Color Contrast rule may report false positives for gradient backgrounds. In such cases, it may be unable to determine the foreground color and instead compare background colors to each other, resulting in a failure.

To work around this issue, try running accessibility checks on larger devices. Alternatively, you may opt to ignore the rule in your tests and check Color Contrast manually for these views.

Apple's accessibility APIs may incorrectly report web content inside WKWebView as "isVisible", even when the web view is covered by native overlays (such as modal views, alerts, or other native UI elements). This occurs because the accessibility system checks whether the WKWebView container itself is visible, rather than whether its web content is actually unobstructed and perceivable to the user.

iOS 26 contains an accessibility bug where default stepper buttons do not announce "dimmed" by Assistive Technology to indicate that they are not enabled. As a result, the iOS rules also see these buttons as enabled even if they are not. A bug report has been filed with Apple, but until this is resolved, the following rules may report results on disabled stepper buttons: AssociatedText, InaccessibleAction, and ColorContrast.

Until Apple fixes this bug, the resolution will be to [ignore the rules](ios-ignore-rule). The default stepper buttons have the identifiers "Decrement" and "Increment", and can be ignored by identifier if needed.

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.

Some screens may report false positives with LabelInName and LabelAtFront due to an incorrect associatedText property being found (#1622)

While looking at an improvement for our rules, we found that in XCTest, nested controls are not returned in the accessibility tree. A bug has been filed with Apple. (#1110)

In UIKit apps, an image without an `accessibilityLabel` is not focusable with assistive technology by default.
The properties we use to check focusability from Apple may be inaccurate when an `accessibilityIdentifier` is set on the image. Due to this unexpected behavior, results for ImageView Name issues in UIKit apps will report as Needs Review. A bug report has been filed with Apple. (#1633)

We are actively working on fixes for the following false positives and will update this list as fixes are released.

In Scroll View
Text within banner-behaving elements, sticky headers/footers, floating action buttons and custom tab views may be flagged with a "Needs Review" or "Fail" message. To make these elements available to those that require larger text, use UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
If an UIImageView has an accessibilityIdentifier set but is not focusable by VoiceOver, and it has focusable controls nested within it, Active Control Name may report a false positive on the UIImageView. Removing the accessibilityIdentifier resolves the issue. A bug has been filed with Apple. (#1633)

Label In Name and Label At Front
These two rules look for a control's visible label amongst nearby elements to help determine rule status. In some view hierarchies, the incorrect nearby text may be detected causing these rules to fail. (#1622)

The Label at Front rule checks that an element's visible label comes at the start of its announced text. A rule failure may result when an interactive element's visible text contains an abbreviation (e.g. "GB", "km") or an obscured / truncated identifier, and the accessibility announcement consists of the represented words (e.g. "gigabytes", "kilometers"), even though this is the recommended pattern for making abbreviated or truncated content screen-reader friendly.

If the first part of the visible label of an interactive element matches the beginning of the screen reader announcement and only the abbreviated / obscured portion differs, the flagged result may be safely ignored. Verify with a screen reader that the full announcement reads as intended.

When using decorative text in views such as "Contact Icons", it is possible to introduce an accessibility issue. If you are using a text view to display letters instead of generating images with the desired letters as vectors, and you then declare that text view as not important for accessibility, we will not be able to reliably tell if you have introduced an accessibility violation.

If you edit focusable text to ignore two or fewer characters, you may inadvertently ignore many one-word buttons in various languages (e.g. "OK", "No", "Sí"). To avoid these issues, you should grab the desired letters from the word you wish to represent in the icon and generate the letters as a part of the image instead of as separate text views. `FocusableText` then will not run on those views.

Flutter does not map AppBar.title to the native screen title property - Activity.setTitle, causing the Screen Title rule to fail on all Flutter screens regardless of whether a descriptive title is present.

This is a known Flutter platform limitation tracked in flutter/flutter#185894.

In some cases, assistive technology relies on AccessibilityEvent descriptions from the Android system to announce information to the user when no other announcement is available. Since AccessibilityEvents are triggered by user actions, we are unable to access the correct description if this information is not provided.

To avoid this issue, ensure that all relevant views are marked as important for accessibility. This will allow Talkback to access the information from the view, which our tool can then detect.

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.

Apps written with XML that utilize the hint text feature may see false positives with the EditTextName rule. Hint text was not introduced until Android 8 (SDK 26). Using this element in your XML app will assign the hint text to the value of the text input field. More recent versions of Android are better equipped to make this experience accessible.

To overcome this issue, our first recommendation is to run your tests on newer versions of Android. If it is important that the app is accessible on earlier Android versions however, you might consider avoiding usage of the hintText feature, as it is not officially supported.

You may see results for views which are hidden behind other views on the screen. These hidden views are not available to assistive technology, but Axe DevTools Mobile still reports them as issues.

We are working on a fix for this complex issue. In the meantime, if TalkBack cannot reach these views, you can disregard the corresponding issues. They do not require a fix to ensure accessibility.

ML Kit text detection is required in many of the Axe DevTools Mobile rules to ensure accuracy of results. The ML Kit library should be automatically imported when referencing Axe DevTools Mobile in your automated Espresso or UIAutomator tests. In some cases however, the automatic import does not happen and you will see the following error in the logcat:

Axe DevTools Android: Error while running mlKit Text Detection: MlKitContext has not been initialized.

To overcome this issue, you should import the ML Kit library into your project manually. In your application's build.gradle file, add the following under dependencies:

debugImplementation 'com.google.mlkit:text-recognition:16.0.1'

Find a full working example of the ML Kit library being imported in the Android Mobile SDK Getting Started section, under Implementation

The Touch Target Spacing rule is currently not running on any slider components that were written in Jetpack Compose. No action can be taken at this time. However, a fix is coming soon!

On Android API 30, one of the locations that we attempt to save results locally has a permissions error. The result will still be saved as a JSON file despite this error being displayed. The error can be suppressed by commenting out the code in the following block:

def clearDirectoryTask = task('clearDirectoryTask', type: Exec, group: 'reporting') {
	executable "${android.getAdbExecutable().toString()}"
	args 'shell', 'rm', '-r', '/storage/emulated/0/Documents/AxeTestCases'

//    finalizedBy {
//        fetchAndroidFolderAxeReportsTask
//    }
}

Please note that this code should only be commented out for API 30 as it will cause problems when saving locally for other API levels.

In some hybrid and cross-platform apps, we may return unexpected results when items in a scroll view are partially off screen. To test an element for accessibility, ensure it is fully onscreen before performing the scan.

Introduced with API 31 (Android 12) is the ability to hide non-system overlays. In order to utilize the Axe Analyzer app, please ensure this setting is not turned on. If you have opted to utilize this feature for its security enhancements, we recommend leaving it off for internal testing builds where you can safely utilize testing data and eliminate security concerns that way. Note: this setting does not affect Google's accessibility scanner app as it's considered a system overlay.

To utilize the Axe Accessibility Analyzer app, update any calls to the method setHideOverlayWindows(true) to setHideOverlayWindows(false) on the affected activity windows.

To unlock full functionality of Axe DevTools for Mobile, ensure screenshots are enabled. We recommend enabling screenshots on a debug or test version of your app that uses mock data to avoid security concerns. Checkout our guide for enabling screenshots in Android apps.

If minifying your build, you'll see a crash with an error log reporting an adapter could not be found when trying to login to the Axe DevTools library. Disable minify for your debug builds with Axe DevTools implemented. (#729)

A build with r8 enabled may attempt to minify the axeDevTools library resulting in an error similar to:

To resolve this error add the following line to your ProGuard file to keep axeDevTools classes:

keep class com.deque.** { *; }

The Compose APIs are deprecated, please use the layout agnostic APIs to continue receiving updates. If you continue to use the Compose APIs and encounter an error along the lines of `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` or `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?`, please refer to Compose setTestTag API.

Due to limitations of the MAUI app architecture rendering in the Android ecosystem, the Edit Text Name rule will show as Needs Review in the dashboard when a failure is suspected for SDK version 5.5.0 and up. Please confirm correct behavior manually for this case.

When you're implementing custom dialogs or modals that do not extend the native controls, you may get results for views behind the modal. In this case, we recommend not running our tool against these custom modals or dialogs and instead manually checking them to ensure they behave with assistive technology as desired.

If the screenshot is missing from the scan details page, your app may be preventing screenshots from being taken. Often this is for security reasons in your production application. Consider removing this requirement for your testing build to allow for full functionality in the Axe DevTools Mobile Dashboard.

• Android - FLAG_SECURE

Some Android scan names that are defaulted to the screen title will appear as the full class name including the bundle identifier. In a future release, this will be resolved so that the screen title is formatted into a more readable name. As a workaround, you can set the scan name from the dashboard or frameworks. (#1643)