Axe DevTools Mobile Release Notes van 23 oktober 2026

Bij het scannen van een scherm met grote of complexe weergavehiërarchieën, kan de axeScan opdracht langer dan 60 seconden duren om te voltooien. Appium's WebDriverAgent (WDA) proxy past een standaard-timeout van 60 seconden toe op onbekende opdrachten, en axeScan valt in die categorie. Als de scan binnen die tijd niet is voltooid, annuleert WDA het verzoek en gooit de test een timeouterror

Om de per-opdrachttimeout voor WDA-geproxiede opdrachten zoals axeScante overschrijven, raden we de volgende instellingen in uw Appium-mogelijkheden aan:

• appium:commandTimeouts: 240000 (4 minuten)
• appium:wdaConnectionTimeout: 30000 (5 minuten)

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

Als u Xcode 27 gebruikt en een oudere dan 2.0.0 versie van de Mobile Analyzer Desktop-app draait, kan de app de iOS-simulator niet openen. Het faalt wanneer het probeert om /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app U kunt geen op simulator gebaseerde scan starten totdat dit is opgelost.

Om scans uit te voeren met behulp van een simulator op Xcode 27, update de Desktop Analyzer naar versie 2.0.0+. Met deze update, let erop dat toegankelijkheidsresultaten nu te vinden zijn in Axe Developer Hub.

De Axe DevTools SDK gebruikt het Vision-framework van Apple om tekst van het scherm te lezen voor verschillende toegankelijkheidsregels (bijv. kleurcontrast, botsende weergaven, elke regel die afhankelijk is van door Vision gedetecteerde tekst).

Vision geeft niet altijd dezelfde gedetecteerde tekst terug tussen uitvoeringen van hetzelfde scherm. Wanneer Vision de tekst op een controle mist, zullen regels die afhankelijk zijn van die tekst niet worden uitgevoerd voor dat element tijdens die scan. Bevindingen kunnen inconsistent lijken tussen twee scans van hetzelfde scherm - een probleem dat bij de ene scan faalt, kan bij de volgende ontbreken.

Wanneer een op Vision gebaseerde regel een fout meldt, is de fout zelf accuraat. De inconsistentie zit in of de regel wordt uitgevoerd of niet. Om dit probleem te overwinnen, probeer het volgende:

• Herhaal de scan. Als een op Vision gebaseerde regel werd overgeslagen voor een controle, detecteert een andere scan van hetzelfde scherm dit vaak wel.
• Behandel elke fout in de op Vision gebaseerde regel als geldig - als Kleurcontrast een controle markeert, is het contrastprobleem echt en moet het worden aangepakt.
• Voor handmatige verificatie gebruik je de Deque University-referentie voor het relevante WCAG-succescriterium. (Links zijn te vinden onderaan elke regelpagina.)

Op iOS 26 en later, als een scherm tekst met een procentteken bevat (bijv. een tekstlabel met "50% Korting"), kan de Regel Ondersteunt Dynamic Type als Onvolledig in plaats van geslaagd of gefaald rapporteren. Deze regel is afhankelijk van een toegankelijkheidsaudit die door Apple wordt geleverd, en die audit stopt de testuitvoering wanneer procenttekens worden tegengekomen. Om je tests draaiend te houden, slaat onze regel de controle voor dat scherm over en rapporteert als onvolledig voor elk element met een procentteken. Alle andere regels verlopen normaal op het scherm, en andere schermen worden niet beïnvloed.

Er is geen actie nodig, aangezien je scan toch wordt voltooid. Om de ondersteuning voor Dynamic Type voor deze schermen te controleren, vergroot je de tekstgrootte op je apparaat onder **Instellingen** > **Toegankelijkheid** > **Weergave & Tekstgrootte** > **Grote Tekst**, en bevestig je dat de tekst op het scherm passend schaalt. Dit probleem is gemeld aan Apple. (#2985)

De Kleurcontrastsregel gebruikt het Vision-framework van Apple (optische tekenherkenning, of OCR) om tekst binnen de grenzen van een element te lezen. OCR kan soms kleine icoonachtige glyphs verkeerd identificeren - zoals pijlterug-chevrons (<), opsommingstekens, decoratieve symbolen - als tekst. Wanneer dat gebeurt, voert de Kleurcontrastsregel uit op een element dat geen leesbare tekst bevat, wat een resultaat kan opleveren voor een knop met alleen een icoon. Omdat OCR-uitvoer niet deterministisch is tussen scans, kan hetzelfde element in Kleurcontrastresultaten verschijnen in de ene scan en als "NIET VAN TOEPASSING" worden gerapporteerd in de volgende. Dit is een bekend kenmerk van OCR, geen bug in de regel.

Om dit probleem te omzeilen, kun je de ignore API's gebruiken om Kleurcontrastresultaten voor de getroffen elementen te onderdrukken.

Flutter mappt niet AppBar.title naar de native eigenschap van schermtitel - UIViewController.title, wat ervoor zorgt dat de Schermtitelregel faalt op alle Flutterschermen, ongeacht of er een beschrijvende titel aanwezig is.

Dit is een bekende Flutter-platformbeperking die wordt bijgehouden in flutter/flutter#185894.

Bij het doen van toegankelijkheidscontroles op kleinere schermformaten of met kleinere letterformaten, kan de Kleurcontrastsregel valse positieven rapporteren voor gradiëntachtergronden. In zulke gevallen kan het mogelijk de voorgrondkleur niet bepalen en in plaats daarvan achtergrondkleuren met elkaar vergelijken, wat tot een fout leidt.

Om dit probleem te omzeilen, probeer toegankelijkheidscontroles op grotere apparaten uit te voeren. Als alternatief kun je ervoor kiezen de regel in je tests te negeren en Kleurcontrast handmatig te controleren voor deze weergaven.

De toegankelijkheids-API's van Apple kunnen webinhoud binnen WKWebView onjuist rapporteren als "isVisible", zelfs wanneer de webweergave is bedekt door native overlays (zoals modale weergaven, waarschuwingen of andere native UI-elementen). Dit gebeurt omdat het toegankelijkheidssysteem controleert of de WKWebView-container zelf zichtbaar is, in plaats van of de webinhoud daadwerkelijk onbelemmerd en waarneembaar voor de gebruiker is.

iOS 26 bevat een toegankelijkheidsbug waarbij standaardstapknoppen niet "gedimd" door Assistive Technology aankondigen om aan te geven dat ze niet ingeschakeld zijn. Als gevolg hiervan zien ook de iOS-regels deze knoppen als ingeschakeld, zelfs als ze dat niet zijn. Er is een bugrapport ingediend bij Apple, maar totdat dit is opgelost, kunnen de volgende regels resultaten rapporteren op uitgeschakelde stapknoppen: AssociatedText, InaccessibleAction, en ColorContrast.

Totdat Apple deze bug oplost, blijft de oplossing om [de regels te negeren](ios-ignore-rule). De standaardstapknoppen hebben de identificatoren "Decrement" en "Increment" en kunnen indien nodig worden genegeerd op identificator.

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.

Sommige schermen kunnen valse positieven rapporteren met LabelInName en LabelAtFront vanwege een onjuiste associatedText eigenschap die wordt gevonden (#1622)

Bij het bekijken van een verbetering voor onze regels, ontdekten we dat in XCTest, geneste controles niet worden geretourneerd in de toegankelijkheidsboom. Er is een bug ingediend bij Apple. (#1110)

In UIKit-apps is een afbeelding zonder een `accessibilityLabel` standaard niet focusbaar met ondersteunende technologie.
De eigenschappen die we gebruiken om focusbaarheid van Apple te controleren kunnen onnauwkeurig zijn wanneer een `accessibilityIdentifier` op de afbeelding is ingesteld. Vanwege dit onverwachte gedrag zullen resultaten voor problemen met de ImageView Name kwesties in UIKit-apps worden gerapporteerd als Behoeft Review. Er is een bugrapport ingediend bij Apple. (#1633)

We werken actief aan oplossingen voor de volgende valse positieven en zullen deze lijst bijwerken naarmate er oplossingen worden vrijgegeven.

In Scroll View
Tekst binnen banner-gedragselementen, sticky headers/footers, zwevende actieknoppen en aangepaste tabweergaven kunnen worden gemarkeerd met een "Behoeft Review" of "Falen" bericht. Om deze elementen beschikbaar te maken voor degenen die grotere tekst nodig hebben, gebruik UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Als een UIImageView een accessibilityIdentifier heeft maar niet focusbaar is door VoiceOver, en er zijn focusbare bedieningen binnenin genesteld, kan Actieve Controle Naam een false positive rapporteren op de UIImageView. Door de accessibilityIdentifier te verwijderen, wordt het probleem opgelost. Er is een bug gemeld bij Apple. (#1633)

Label In Name and Label At Front
Deze twee regels zoeken naar een zichtbaar label van een bedieningselement tussen de nabijgelegen elementen om de regelstatus te bepalen. In sommige weergavehiërarchieën kan de onjuiste nabijgelegen tekst worden gedetecteerd, waardoor deze regels falen. (#1622)

De Floating Action Button (FAB) van de Android Accessibility Analyzer is niet compatibel met de swiper-navigatie van Talkback in Talkback-versies ouder dan 16.2. Met de release van 16.2 heeft Talkback een bug in hun code gepatcht om swipefocus voor overlay-FAB's mogelijk te maken.

Let op dat dit puur een Talkback-bug is, die het niet toestond dat FAB's, gerenderd in toegankelijkheidsoverlays, focus konden krijgen of verliezen via swipen. De recente upgrade naar onze Accessibility Analyzer-app maakt het mogelijk om meer soorten apps te scannen; daarom kunt u dit probleem nu pas zien.

Dit probleem kan worden opgelost door Talkback bij te werken naar versie 16.2 of hoger.

De Label aan de Voorkant-regel controleert of het zichtbare label van een element aan het begin komt van de aangekondigde tekst. Een regelmislukking kan optreden wanneer de zichtbare tekst van een interactief element een afkorting bevat (bijv. „GB“, „km“) of een verduisterde / afgekorte identificator, en de toegankelijkheidsaankondiging bestaat uit de weergegeven woorden (bijv. „gigabytes“, „kilometers“), hoewel dit het aanbevolen patroon is om afgekorte of afgekorte inhoud schermlezer-vriendelijk te maken.

Als het eerste deel van het zichtbare label van een interactief element overeenkomt met het begin van de aankondiging van de schermlezer en alleen het afgekorte / verduisterde deel verschilt, kan het gemarkeerde resultaat veilig worden genegeerd. Verifieer met een schermlezer dat de volledige aankondiging correct wordt weergegeven.

Bij het gebruik van decoratieve tekst in weergaven zoals „Contacticonen“, is het mogelijk een toegankelijkheidsprobleem te introduceren. Als u een tekstweergave gebruikt om letters weer te geven in plaats van afbeeldingen te genereren met de gewenste letters als vectoren, en u verklaart die tekstweergave als niet belangrijk voor toegankelijkheid, kunnen we niet betrouwbaar bepalen of u een toegankelijkheidsinbreuk heeft veroorzaakt.

Als u focustekst bewerkt om twee of minder tekens te negeren, kunt u per ongeluk veel één-woordknoppen in verschillende talen negeren (bijv. „OK“, „Nee“, „Sí“). Om deze problemen te vermijden, moet u de gewenste letters uit het woord halen dat u in het pictogram wilt weergeven en de letters als onderdeel van de afbeelding genereren in plaats van als afzonderlijke tekstweergaven. `FocusableText` zal dan niet op die weergaven draaien.

Flutter mappt niet AppBar.title naar de native eigenschap van schermtitel - Activity.setTitle, wat ervoor zorgt dat de Schermtitelregel faalt op alle Flutterschermen, ongeacht of er een beschrijvende titel aanwezig is.

Dit is een bekende Flutter-platformbeperking die wordt bijgehouden in flutter/flutter#185894.

In sommige gevallen vertrouwt assistieve technologie op AccessibilityEvent beschrijvingen van het Android-systeem om informatie aan de gebruiker aan te kondigen wanneer er geen andere aankondiging beschikbaar is. Aangezien AccessibilityEvents worden geactiveerd door gebruikersacties, kunnen we geen toegang krijgen tot de juiste beschrijving als deze informatie niet wordt verstrekt.

Om dit probleem te voorkomen, zorg ervoor dat alle relevante weergaven als belangrijk voor toegankelijkheid zijn gemarkeerd. Hierdoor kan Talkback de informatie uit de weergave halen, die onze tool vervolgens kan detecteren.

Onze Kleurcontrastsregel is afhankelijk van Machine Learning om tekst te detecteren, wat ervoor zorgt dat de gescande tekst zichtbaar is voor de gebruikers van je applicatie. In gevallen waar de tekst in een weergave dezelfde kleur heeft als de achtergrond, is ons Machine Learning-algoritme niet in staat om te detecteren of er tekst aanwezig is, zodat de Kleurcontrastsregel niet wordt uitgevoerd op deze weergave.

Apps geschreven met XML die de hintteksteigenschap gebruiken, kunnen valse positieven zien bij de EditTextName regel. Hinttekst werd pas geïntroduceerd in Android 8 (SDK 26). Het gebruik van dit element in uw XML-app zal de hinttekst toewijzen aan de waarde van het tekstinvoerveld. Recentere versies van Android zijn beter uitgerust om deze ervaring toegankelijk te maken.

Om dit probleem te overkomen, is onze eerste aanbeveling om uw tests uit te voeren op nieuwere Android-versies. Als het echter belangrijk is dat de app toegankelijk is op eerdere Android-versies, kunt u overwegen het gebruik van de hintText eigenschap te vermijden, omdat deze officieel niet wordt ondersteund.

U kunt resultaten zien voor weergaven die achter andere weergaven op het scherm verborgen zijn. Deze verborgen weergaven zijn niet beschikbaar voor assistieve technologie, maar Axe DevTools Mobile rapporteert ze nog steeds als problemen.

We werken aan een oplossing voor dit complexe probleem. Ondertussen, als TalkBack deze weergaven niet kan bereiken, kunt u de overeenkomstige problemen negeren. Ze vereisen geen oplossing om toegankelijkheid te garanderen.

ML Kit tekstherkenning is vereist in veel van de Axe DevTools Mobile-regels om de nauwkeurigheid van resultaten te garanderen. De ML Kit-bibliotheek moet automatisch worden geïmporteerd wanneer Axe DevTools Mobile wordt aangeroepen in uw geautomatiseerde Espresso- of UIAutomator-tests. In sommige gevallen echter, vindt de automatische import niet plaats en ziet u de volgende fout in de logcat:

De Aanraakdoelafstand-regel wordt momenteel niet uitgevoerd op schuifcomponenten die zijn geschreven in Jetpack Compose. Er kan op dit moment geen actie worden ondernomen. Een oplossing komt echter binnenkort!

Op Android API 30 heeft een van de locaties waar we proberen resultaten lokaal op te slaan een toestemmingsfout. Het resultaat wordt nog steeds opgeslagen als een JSON-bestand, ondanks deze fout dat wordt weergegeven. De fout kan onderdrukt worden door de code in het volgende blok te becommentariëren:

In sommige hybride en cross-platform apps kunnen we onverwachte resultaten teruggeven wanneer items in een scrollweergave gedeeltelijk buiten beeld zijn. Om een element op toegankelijkheid te testen, moet u ervoor zorgen dat het volledig in beeld is voordat u de scan uitvoert.

Geïntroduceerd met API 31 (Android 12) is de mogelijkheid om niet-systeemoverlays te verbergen. Om de Axe Analyzer-app te gebruiken, zorgt u ervoor dat deze instelling niet is ingeschakeld. Als u ervoor heeft gekozen deze functie te gebruiken vanwege de beveiligingsverbeteringen, raden we aan deze uit te laten staan voor interne testversies waarin u veilig testgegevens kunt gebruiken en zo beveiligingsproblemen kunt elimineren. Note: this setting does not affect Google's accessibility scanner app as it's considered a system overlay.

Om gebruik te maken van de Axe Accessibility Analyzer-app, werk dan eventuele oproepen naar de methode setHideOverlayWindows(true) bij op de getroffen activiteitenvensters. setHideOverlayWindows(false) .

Om de volledige functionaliteit van Axe DevTools voor Mobile te ontgrendelen, moet u ervoor zorgen dat screenshots zijn ingeschakeld. We raden aan screenshots in te schakelen op een debug- of testversie van uw app die gebruikmaakt van gesimuleerde gegevens om beveiligingsproblemen te vermijden. Bekijk onze gids voor schermafbeeldingen inschakelen in Android-apps.

Als je je build minimaliseert, merk je een crash met een foutlog dat meldt dat een adapter niet kon worden gevonden bij het proberen in te loggen in de Axe DevTools-bibliotheek. Schakel minimaliseren uit voor je debug-builds met Axe DevTools geïmplementeerd. (#729)

Een build met r8 ingeschakeld kan proberen de axeDevTools-bibliotheek te minimaliseren, wat resulteert in een foutmelding zoals:

De Compose-API's zijn verouderd, gebruik alstublieft de layout-agnostische API's om updates te blijven ontvangen. Als je de Compose-API's blijft gebruiken en een fout tegenkomt zoals `Exact '1' node verwacht maar '2' nodes gevonden die voldoen aan: (isRoot)` of `Geen Weergave geïnitialiseerd, heb je AxeDevToolsCompose.setComposeTestRule() aangeroepen?`, raadpleeg dan Compose setTestTag API.

Vanwege beperkingen van de MAUI-apparchitectuur in het Android-ecosysteem, zal de regel voor Bewerken Tekstnaam als Beoordeling Nodig verschijnen op het dashboard wanneer een fout wordt vermoed voor SDK-versie 5.5.0 en hoger. Bevestig correct gedrag handmatig voor dit geval.

Als je aangepaste dialogen of modals implementeert die de native controls niet uitbreiden, krijg je mogelijk resultaten voor weergaven achter de modal. In dit geval raden we aan om onze tool niet te gebruiken tegen deze aangepaste modals of dialogen en in plaats daarvan ze handmatig te controleren om te verzekeren dat ze correct werken met assistieve technologie.

Als de schermafbeelding ontbreekt op de scangegevenspagina, kan het zijn dat je app het maken van schermafbeeldingen verhindert. Vaak is dit om veiligheidsredenen in je productieapplicatie. Overweeg deze vereiste te verwijderen voor je testbuild om volledige functionaliteit in het Axe DevTools Mobile Dashboard mogelijk te maken.

• Android - FLAG_SECURE

Sommige namen van Android-scans die standaard de schermtitel hebben, verschijnen als de volledige klasnaam inclusief de bundel-ID. In een toekomstige release zal dit worden opgelost zodat de schermtitel wordt geformatteerd naar een beter leesbare naam. Als tijdelijke oplossing kun je de scannaam instellen vanuit het dashboard of frameworks. (#1643)