Axe DevTools Mobile Release-opmerkingen van 7 oktober 2026

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

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

• 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 je Xcode 27 gebruikt en een oudere Mobile Analyzer Desktop-app dan 2.0.0, kan de app de iOS-simulator niet openen. Het mislukken gebeurt wanneer geprobeerd wordt te starten /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app Je kunt geen op simulator gebaseerde scan uitvoeren totdat dit is opgelost.

Om scans uit te voeren met een simulator op Xcode 27, update de Desktop Analyzer naar versie 2.0.0+. Let bij deze update op 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 Vision-herkende tekst).

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

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

• Voer de scan opnieuw uit. Als een op Vision gebaseerde regel werd overgeslagen voor een bedieningselement, pakt een andere scan van hetzelfde scherm deze vaak op.
• Behandel elke op Vision gebaseerde regel als geldig - als Kleurcontrast een bedieningselement markeert, is het contrastprobleem echt en moet het worden aangepakt.
• Voor handmatige verificatie, gebruik de Deque University-referentie voor het relevante WCAG-criterium voor succes. (Links zijn te vinden onderaan elke regelpagina's.)

Op iOS 26 en later, als een scherm tekst met een procentteken erin bevat (bijv. een tekstlabel met "50% Korting"), kan de Support Dynamic Type-regel rapporteren als Onvolledig in plaats van een pass of fail. Deze regel is afhankelijk van een toegankelijkheidsaudit die door Apple wordt geleverd en die audit stopt de testuitvoering wanneer deze procenttekens tegenkomt. Om je tests verder te laten lopen, slaat onze regel de controle voor dat scherm over en meldt het onvolledig voor elk element dat een procentteken bevat. Alle andere regels worden normaal uitgevoerd op het scherm, en andere schermen blijven onaangetast.

Geen actie is vereist, aangezien je scan nog steeds zal worden voltooid. Om Dynamic Type-ondersteuning voor deze schermen te controleren, vergroot je de tekstgrootte op je apparaat onder **Instellingen** > **Toegankelijkheid** > **Scherm en tekstgrootte** > **Grote tekst** en controleer je of de tekst op het scherm op de juiste manier schaalt. Dit probleem is gemeld aan Apple. (#2985)

De kleurcontrastrichtlijn maakt gebruik van het Vision-framework van Apple (Optical Character Recognition, of OCR) om tekst binnen de grenzen van een element te lezen. OCR kan af en toe kleine pictogramachtige tekens - zoals terugpijl-chevron (<), opsommingstekens, decoratieve symbolen - als tekst herkennen. Wanneer dat gebeurt, wordt de kleurcontrastrichtlijn uitgevoerd op een element dat geen leesbare tekst bevat, wat kan resulteren in een resultaat voor een knop die alleen uit een pictogram bestaat. Omdat OCR-resultaten niet deterministisch zijn over meerdere scans, kan hetzelfde element in de ene scan in de kleurcontrastresultaten verschijnen en in de volgende als „NIET TOEPASBAAR“ worden gerapporteerd. Dit is een bekend kenmerk van OCR, geen bug in de richtlijn.

Om dit probleem te omzeilen, kunt u de ignore API's gebruiken om kleurcontrastresultaten voor de getroffen elementen te onderdrukken.

Flutter koppelt niet AppBar.title aan de native eigenschap voor de schermtitel - UIViewController.title, waardoor de richtlijn voor de schermtitel mislukt op alle Flutter-schermen, ongeacht of er een beschrijvende titel aanwezig is.

Dit is een bekende beperking van het Flutter-platform, gevolgd in flutter/flutter#185894.

Bij het uitvoeren van toegankelijkheidscontroles op kleinere schermformaten of met kleinere lettergroottes, kan de kleurcontrastrichtlijn valse positieve resultaten rapporteren voor gradient-achtergronden. In dergelijke gevallen kan het niet de voorgrondkleur bepalen en in plaats daarvan achtergrondkleuren met elkaar vergelijken, wat resulteert in een falen.

Om dit probleem te omzeilen, probeert u toegankelijkheidscontroles uit te voeren op grotere apparaten. Als alternatief kunt u ervoor kiezen de richtlijn in uw tests te negeren en zelf handmatig het kleurcontrast voor deze weergaven te controleren.

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

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

Totdat Apple deze bug oplost, zal de oplossing zijn om [de regels te negeren](ios-ignore-rule). De standaard stapperknoppen hebben de namen "Decrement" en "Increment", en kunnen indien nodig worden genegeerd op basis van hun identificatie.

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 positieve resultaten rapporteren met LabelInName en LabelAtFront vanwege een onjuiste associatedText eigenschap die gevonden wordt (#1622)

Bij het zoeken naar een verbetering voor onze regels, ontdekten we dat geneste bedieningselementen in XCTest niet worden teruggegeven in de toegankelijkheidsboom. Er is een bug ingediend bij Apple. (#1110)

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

We werken actief aan oplossingen voor de volgende valse positieve resultaten en zullen deze lijst bijwerken wanneer er oplossingen worden vrijgegeven.

In Scroll View
Tekst binnen elementen met banner-gedrag, kleefkopteksten/voetteksten, zwevende actieknoppen en aangepaste tabweergaven kan worden gemarkeerd met een "Behoeft herziening" of "Faal" bericht. Om deze elementen toegankelijk 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 ingesteld maar niet focusbaar is door VoiceOver, en het bevat focusbare bedieningselementen binnenin, kan Active Control Name een vals-positief rapporteren op de UIImageView. Het verwijderen van de accessibilityIdentifier lost het probleem op. Er is een bug ingediend bij Apple. (#1633)

Label In Name and Label At Front
Deze twee regels zoeken naar het zichtbare label van een bedieningselement tussen nabijgelegen elementen om de status van de regel te bepalen. In sommige weergavehierarchieën kan de onjuiste nabijgelegen tekst worden gedetecteerd, wat ertoe leidt dat deze regels falen. (#1622)

De Label at Front-regel controleert of het zichtbare label van een element zich aan het begin van de aangekondigde tekst bevindt. Een regelfout kan optreden wanneer de zichtbare tekst van een interactief element een afkorting (bijv. "GB", "km") of een verborgen / afgekorte identifier bevat, en de toegankelijkheidsmelding bestaat uit de vertegenwoordigde woorden (bijv. "gigabytes", "kilometers"), hoewel dit het aanbevolen patroon is om verkorte of afgekorte inhoud toegankelijk voor schermlezers te maken.

Als het eerste deel van het zichtbare label van een interactief element overeenkomt met het begin van de schermlezer-aankondiging en alleen het afgekorte / verborgen gedeelte verschilt, kan het gemarkeerde resultaat veilig worden genegeerd. Verifieer met een schermlezer dat de volledige aankondiging wordt gelezen zoals bedoeld.

Bij het gebruik van decoratieve tekst in weergaven zoals "Contacticonen" is het mogelijk om 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 vervolgens verklaart dat die tekstweergave niet belangrijk is voor toegankelijkheid, kunnen we niet betrouwbaar vaststellen of u een toegankelijkheidsovertreding hebt geïntroduceerd.

Als u bewerkbare tekst negeert om twee of minder tekens, kunt u per ongeluk veel één-woord knoppen in verschillende talen negeren (bijv. "OK", "No", "Sí"). Om deze problemen te vermijden, zou u de gewenste letters uit het woord dat u wilt weergeven in het pictogram moeten halen en de letters als onderdeel van de afbeelding moeten genereren in plaats van als afzonderlijke tekstweergaven. `FocusableText` zal dan niet worden uitgevoerd op die weergaven.

Flutter koppelt niet AppBar.title aan de native eigenschap voor de schermtitel - Activity.setTitle, waardoor de richtlijn voor de schermtitel mislukt op alle Flutter-schermen, ongeacht of er een beschrijvende titel aanwezig is.

Dit is een bekende beperking van het Flutter-platform, gevolgd in flutter/flutter#185894.

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

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

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

Apps geschreven met XML die de hinttekstfunctie gebruiken, kunnen fout-positieven zien met de EditTextName regel. Hinttekst werd pas geïntroduceerd bij Android 8 (SDK 26). Het gebruik van dit element in uw XML-applicatie 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 verhelpen, is onze eerste aanbeveling om uw tests op nieuwere versies van Android uit te voeren. Als het belangrijk is dat de app toegankelijk is op oudere Android-versies, overweeg dan echter het gebruik van de hintText functie te vermijden, aangezien deze niet officieel wordt ondersteund.

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

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

ML Kit tekstdetectie 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 u verwijst naar Axe DevTools Mobile in uw geautomatiseerde Espresso of UIAutomator-tests. In sommige gevallen gebeurt de automatische import echter niet en ziet u de volgende foutmelding in de logcat:

De Touch Target Afstandsregel wordt momenteel niet uitgevoerd op schuifregelaarcomponenten die zijn geschreven in Jetpack Compose. Er kan op dit moment geen actie worden ondernomen. Echter, een oplossing komt binnenkort!

Op Android API 30 heeft een van de locaties waar we proberen resultaten lokaal op te slaan een probleem met machtigingen. Het resultaat wordt nog steeds opgeslagen als een JSON-bestand, ondanks dat deze foutmelding 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 het scherm zijn. Om een element op toegankelijkheid te testen, zorg ervoor dat het volledig op het scherm 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, zorg ervoor dat deze instelling niet is ingeschakeld. Als u ervoor heeft gekozen om deze functie te gebruiken vanwege de beveiligingsverbeteringen, raden we aan om deze uit te laten voor interne testbuilds waar u veilig testdata kunt gebruiken en beveiligingsproblemen op die manier kunt elimineren. Note: this setting does not affect Google's accessibility scanner app as it's considered a system overlay.

Om de Axe Accessibility Analyzer-app te gebruiken, update alle aanroepen naar de methode setHideOverlayWindows(true) naar setHideOverlayWindows(false) op de getroffen activiteitsvensters.

Om de volledige functionaliteit van Axe DevTools for Mobile te ontgrendelen, zorg ervoor dat schermafbeeldingen zijn ingeschakeld. We raden aan om schermafbeeldingen in te schakelen op een debug- of testversie van uw app die mock data gebruikt om beveiligingsproblemen te vermijden. Bekijk onze gids voor het inschakelen van schermafbeeldingen in Android-apps.

Als u uw build minimaliseert, ziet u een crash met een foutlogboek dat meldt dat een adapter niet gevonden kon worden wanneer u probeert in te loggen op de Axe DevTools-bibliotheek. Schakel minify uit voor uw debugbuilds met Axe DevTools geïmplementeerd. (#729)

Een build met ingeschakelde r8 kan proberen de axeDevTools-bibliotheek te minimaliseren, resulterend in een fout zoals:

De Compose-API's zijn verouderd, gebruik alstublieft de lay-out agnostische API's om updates te blijven ontvangen. Als u de Compose-API's blijft gebruiken en een fout tegenkomt zoals `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` of `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?`, raadpleeg dan Compose setTestTag API.

Vanwege beperkingen van de MAUI-apparchitectuur in het Android-ecosysteem, wordt de Bewerken Tekst Naam-regel als 'Moet worden beoordeeld' weergegeven in het dashboard wanneer een fout voor SDK versie 5.5.0 en hoger wordt vermoed. Bevestig in dit geval handmatig het juiste gedrag.

Wanneer u aangepaste dialogen of modals implementeert die de native controles niet uitbreiden, kunt u resultaten krijgen voor weergaven achter de modal. In dit geval raden we aan om onze tool niet tegen deze aangepaste modals of dialogen uit te voeren en in plaats daarvan deze handmatig te controleren om ervoor te zorgen dat ze zich gedragen zoals gewenst met assistentietechnologie.

Als de schermafbeelding ontbreekt op de pagina met scangegevens, kan het zijn dat uw app voorkomt dat er schermafbeeldingen worden gemaakt. Vaak is dit om veiligheidsredenen in uw productieapplicatie. Overweeg om deze vereiste te verwijderen voor uw testbuild om volledige functionaliteit in het Axe DevTools Mobile Dashboard mogelijk te maken.

• Android - FLAG_SECURE

Sommige Android-scannamen die standaard de schermtitel weergeven, zullen verschijnen als de volledige classnaam, inclusief de bundelidentificator. In een toekomstige release zal dit worden opgelost, zodat de schermtitel wordt opgemaakt tot een beter leesbare naam. Als tijdelijke oplossing kunt u de scannaam instellen via het dashboard of de frameworks. (#1643)