Toegankelijkheids‑prompts voor React- en Flutter‑UI-reviews

Wat mensen missen als ze proberen een UI toegankelijk te maken

De meeste toegankelijkheidsproblemen zijn geen "grote herontwerp"-issues. Het zijn kleine details die bepalen of iemand je UI überhaupt kan gebruiken.

Wat meestal als eerste misgaat is opvallend consistent. Een pagina kan er prima uitzien, een snelle visuele check doorstaan en toch moeilijk te gebruiken zijn met alleen een toetsenbord of een schermlezer.

Dit zijn de plekken waar UI's vaak falen:

• Toetsenbordtoegang: je kunt niet bij belangrijke bedieningen komen, of je zit vast in een modal
• Focusvolgorde en focusstatussen: de focus springt rond of je ziet niet waar je bent
• Labels en namen: invoervelden en knoppen hebben onduidelijke of ontbrekende toegankelijke namen
• Aankondigingen: dynamische updates gebeuren, maar schermlezers krijgen er geen bericht over
• Contrast en leesbaarheid: tekst, iconen en foutstaten zijn moeilijk te zien

Het lastige is hoe makkelijk regressies ontstaan. Een "kleine" wijziging zoals een knop vervangen door een icoon, een kaart inpakken met een gesture handler, of een custom dropdown toevoegen kan toetsenbordondersteuning wegnemen, de focusvolgorde breken of een label laten vervallen zonder dat iemand het opmerkt.

Een veelvoorkomend scenario: een React-formulier krijgt een nieuw "wissen"-icoon in een invoerveld. Het ziet er handig uit, maar het icoon is niet focusbaar, heeft geen naam en kapt met click-events. Nu kunnen toetsenbordgebruikers het niet activeren en horen schermlezergebruikers een niet-gelabeld element.

Dit bericht geeft je twee dingen: kopieerbare prompts die je met je UI-code (React en Flutter) kunt gebruiken, en een herhaalbare reviewflow die je in enkele minuten kunt doen. Het doel is niet perfectie op dag één. Het doel is de problemen te vinden die echte gebruikers blokkeren.

Als je productschermen bouwt maar geen toegankelijkheidsspecialist bent, is dit voor jou. Het past ook bij teams die vibe-coding tools zoals Koder.ai gebruiken, waar UI-wijzigingen snel kunnen gebeuren en je snelle, consistente checks nodig hebt. Als je een praktisch startpunt wil, zijn deze toegankelijkheids-prompts voor React en Flutter UI-reviews gemaakt om elke keer opnieuw te gebruiken wanneer je UI uitrolt.

De 5 checks die de meeste problemen snel vangen

Als je maar 15 minuten hebt om een scherm te reviewen, vinden deze checks de problemen die het vaakst mensen blokkeren. Ze werken voor zowel React als Flutter en passen goed in toegankelijkheids-prompts voor React en Flutter UI-reviews.

1) Kun je het alleen met een toetsenbord gebruiken?

Probeer de pagina zonder muis te doorlopen. Gebruik Tab en Shift+Tab om te bewegen, Enter en Space om te activeren, en pijltjestoetsen waar een widget op een menu, tabbladen of lijst lijkt.

Een snelle aanwijzing: als je vast komt te zitten in een modal of je niet bij een belangrijke knop kunt komen (zoals "Sluiten"), klopt er iets niet.

2) Is de focusvolgorde logisch en is de focus zichtbaar?

Terwijl je tabt, moet de focus de visuele lay-out volgen (boven naar beneden, links naar rechts) en nooit naar verborgen gebieden springen. Focus moet ook duidelijk zijn. Als het ontwerp subtiele outlines gebruikt, controleer dan of die nog steeds zichtbaar zijn op lichte en donkere achtergronden.

3) Hebben bedieningselementen duidelijke namen?

Een schermlezer moet een bruikbare naam aankondigen voor elk interactief element. "Knop" is niet genoeg. Iconen hebben een toegankelijk label nodig en formulier velden hebben een label dat verbonden blijft, zelfs als placeholders verdwijnen.

4) Zijn contrast en tekstgrootte OK?

Controleer kleine tekst, uitgeschakelde tekst en tekst op kleurrijke knoppen. Test ook in- en uitzoomen: vergroot de lettergrootte en zorg dat de lay-out niet overlapt of belangrijke inhoud afknipt.

5) Worden veranderingen duidelijk aangekondigd?

Wanneer iets verandert (fout, laden, succes) mogen gebruikers niet hoeven te gissen. Gebruik inline fouttekst bij het veld, kondig formfouten aan en maak laadstaten duidelijk.

Als je schermen bouwt in Koder.ai, vraag het om "controleer toetsenbord-only flow, focusvolgorde en schermlezerlabels voor deze pagina" en loop dan de bovenstaande stappen na.

Stel je reviewscope vast voordat je UI verandert

Toegankelijkheidswerk gaat sneller als je van tevoren bepaalt wat je reviewt en wat "goed genoeg" betekent voor je componenten. Een strakke scope maakt toegankelijkheids-prompts voor React en Flutter UI-reviews ook nuttiger, omdat het model zich op echte schermen en echte interacties kan richten.

Kies de journeys die ertoe doen

Begin met 2 tot 4 kritieke gebruikersreizen, niet het hele product. Goede keuzes zijn die waarvan mensen de flow echt moeten afmaken om waarde te krijgen, en die gebruikers kunnen blokkeren als ze mislukken.

Voor de meeste apps is dat iets als inloggen, een primaire "aanmaken of kopen"-flow (checkout, boeking, indienen), en één accountgebied zoals instellingen of profiel.

Schrijf daarna de exacte schermen in elke reis op (ook al zijn het maar 5 tot 8 schermen). Neem ook de "tussenstadia" mee: foutmeldingen, lege staten, laadstaten en bevestigingsdialogen. Daar breekt de focus en schermlezeroutput vaak.

Een concreet voorbeeld: als je een kleine CRM-pagina bouwt in Koder.ai, scope het naar “inloggen → Open Contacten → contact toevoegen → opslaan → succesmelding zien.” Die enkele flow raakt formulieren, validatie, dialogen en aankondigingen.

Bepaal wat "slagen" betekent

Houd het praktisch. Richt je op WCAG AA-achtige verwachtingen, maar vertaal dat naar eenvoudige checks die je snel kunt toepassen: toetsenbord werkt end-to-end, focus is zichtbaar en logisch, namen en labels zijn begrijpelijk en contrast is leesbaar.

Gebruik een simpele pass/fail notatie zodat je geen tijd verliest met discussies. Voor elk scherm noteer je:

• Check: (toetsenbord, focusvolgorde, labels, contrast, aankondigingen)
• Resultaat: Pass of Fail
• Bewijs: één zin die beschrijft wat er gebeurde
• Oplossing suggestie: wat waarschijnlijk aangepast moet worden (component, prop, styling)
• Retest: wat te proberen na de fix

Dit houdt de review consistent tussen React en Flutter en maakt het makkelijk om issues aan iemand anders over te dragen zonder alles opnieuw uit te leggen.

Kopieerbare prompts voor React-componenten (toetsenbord, labels, roles)

Als je om een toegankelijkheidsreview vraagt, brengen de snelste verbeteringen specificiteit: welke component, welke gebruikersactie en hoe "goed" eruitziet. Deze toegankelijkheids-prompts voor React en Flutter UI-reviews werken het beste als je de componentcode plakt plus een korte beschrijving van wat de UI moet doen.

Als je een chat-gebaseerde builder zoals Koder.ai gebruikt, voeg de prompt meteen toe nadat je een scherm of component hebt gegenereerd zodat problemen worden opgelost voordat ze zich door de app verspreiden.

Review this React component for keyboard navigation issues. 
- Can every interactive element be reached with Tab and activated with Enter/Space?
- List the exact problems you see in the code.
- Propose fixes with small code edits.

Check focus order and focus visibility.
- Describe the expected focus order for a keyboard-only user.
- Point out where focus could get lost (modals, menus, drawers).
- Tell me exactly where to add :focus-visible styles (which elements, which CSS).

Find missing accessible names.
- Identify inputs, buttons, and icons without clear labels.
- Suggest label + htmlFor, aria-label, aria-labelledby, or visible text.
- If there is helper/error text, connect it with aria-describedby.

Identify interactive elements that are not buttons/links.
- Find div/span with onClick, custom dropdowns, and clickable cards.
- Suggest correct semantics (button/a) or add role, tabIndex, and keyboard handlers.

List screen reader announcements that will be confusing.
- Predict what a screen reader will announce for key controls.
- Rewrite UI text to be shorter and clearer.
- Suggest aria-live usage for status changes (loading, errors, saved).

Voeg vóór verzending van de prompt deze details toe zodat je bruikbare fixes krijgt, geen generiek advies:

• Wat de component is (bijvoorbeeld: "login form", "pricing toggle", "settings modal").
• Het toetsenbordpad dat gebruikers zouden moeten volgen (startpunt en eindpunt).
• Gebruikte UI-library (MUI, Chakra, Radix, custom components).
• Te testen staten (laden, fout, uitgeschakeld, lege resultaten).
• Eén concreet gebruikersdoel (bijvoorbeeld: "plan wijzigen en bevestigen").

Kopieerbare prompts voor Flutter-widgets (Semantics, focus, gestures)

Plak een widgetsnippet (of het hele scherm) en vraag om specifieke checks voor consistente resultaten. Deze toegankelijkheids-prompts voor React en Flutter UI-reviews werken het beste als je de widget tree, hoe het scherm bereikt wordt en eventuele custom gestures bijvoegt.

Prompts die je in je review kunt plakken

Review this Flutter widget tree for keyboard navigation and focus traversal.
Call out focus traps, missing focus order, and places where Tab/Shift+Tab will feel confusing.
Suggest exact widget changes (Focus, FocusTraversalGroup, Shortcuts, Actions).

Check this screen for missing Semantics labels, hints, and tap targets.
Point to the exact widgets that need Semantics(label/hint), tooltip, or exclusion.
Also flag controls under 48x48 logical pixels and suggest fixes.

Find custom gestures that break accessibility (GestureDetector/Listener).
Replace them with accessible widgets or add keyboard + semantics support.
If a gesture is required, describe how a keyboard user triggers the same action.

Audit error messages and validation on this form.
What should be announced to a screen reader, and when?
Suggest how to expose errors via Semantics and focus movement after submit.

Propose a consistent focus highlight style across screens.
It should be obvious on dark/light themes and work with keyboard navigation.
Show a small code example using FocusTheme/ThemeData.

Snelle fixes die de assistent zou moeten voorstellen

Verwacht antwoorden die een paar concrete patronen noemen:

• Wikkel de hoofdinhoud in FocusTraversalGroup en zet FocusTraversalOrder alleen wanneer nodig.
• Gebruik Semantics (of MergeSemantics) voor samengestelde controles en vermijd dubbele labels.
• Geef de voorkeur aan InkWell, IconButton, ListTile, SwitchListTile boven ruwe GestureDetector waar mogelijk.
• Voeg Shortcuts + Actions toe voor niet-tekstinputs (bijv. Enter om te activeren, Escape om te sluiten).

Een minimaal voorbeeld om een custom kaart als knop te laten werken:

Semantics(
  button: true,
  label: 'Add payment method',
  hint: 'Opens the add card screen',
  child: Focus(
    child: InkWell(
      onTap: onPressed,
      child: Card(child: child),
    ),
  ),
)

Stapsgewijs: een eenvoudige toetsenbord- en focusreviewflow

Een snelle toetsenbord- en focusreview vindt problemen die ook schermlezers en switch-apparaten beïnvloeden. Doe het op een echte paginastroom (niet één knop) en houd aantekeningen bij zodat je later hetzelfde pad opnieuw kunt controleren.

De 5-stappen flow

Begin met één "happy path" die een gebruiker zou nemen, zoals inloggen, een instellingenpagina openen en opslaan.

1. Doe de hele flow alleen met het toetsenbord. Leg de muis weg. Gebruik Tab en Shift+Tab om te bewegen, Enter en Space om te activeren, en pijltjestoetsen waar dat logisch is. Als iets een klik of swipe vereist, markeer dat.
2. Zorg dat focus altijd duidelijk is. Elke keer dat de focus beweegt, moet je direct zien waar die is. Let op dunne outlines die op donkere achtergronden verdwijnen, focusringen die door CSS zijn verwijderd of Flutter-widgets die "actief" lijken maar geen focus tonen.
3. Controleer of de volgorde overeenkomt met wat je ziet. Focus moet de visuele lay-out en leesvolgorde volgen. Veelvoorkomende rode vlaggen: springen naar een footer, vastlopen in een zijbalk of een veld overslaan omdat het niet focusbaar is.
4. Test overlays zwaar. Open menu's, dialogen en drawers. Focus moet in de overlay bewegen, erin blijven zolang die open is en terugkeren naar een logisch element als hij sluit. Escape moet de overlay sluiten waar dat passend is.
5. Her-test na elke wijziging. Los één probleem op en doorloop hetzelfde pad opnieuw. Noteer wat verbeterde en wat slechter werd, vooral focusvolgordeverschuivingen en nieuwe "dode wegen."

Wat je moet vastleggen tijdens de review

Houd het simpel: paginanaam, wat je indrukte, wat er gebeurde en wat je verwachtte. Die kleine log maakt het makkelijk te bevestigen dat een React-refactor of Flutter-widgetwissel de toetsenbordtoegang niet heimelijk brak.

Schermlezer-vriendelijke namen, labels en aankondigingen

Schermlezers "zien" je UI niet. Ze vertrouwen op namen, rollen en korte berichten die uitleggen wat er veranderde. Als de naam ontbreekt of vaag is, wordt de app giswerk.

Begin bij formulier velden. Elk invoerveld heeft een echt label nodig dat blijft gelden, ook als het veld is ingevuld. Plaatsaanduidingen (placeholders) zijn hints, geen labels, en verdwijnen vaak zodra de gebruiker typt.

Icon-only acties zijn een andere veelvoorkomende miss. Een prullenbakicoon, een potlood of een drie-puntenmenu heeft een betekenisvolle naam nodig die het resultaat beschrijft, niet de vorm. "Project verwijderen" is beter dan "Knop" of "Prullenbak".

Koppen en sectietitels zijn belangrijk omdat ze de pagina-structuur vormen. Gebruik koppen om structuur weer te geven, niet alleen styling. Een schermlezergebruiker springt op koppen om "Facturering" of "Teamleden" te vinden, dus die labels moeten overeenkomen met de inhoud van de sectie.

Foutmeldingen moeten specifiek en actiegericht zijn. "Ongeldige invoer" is niet genoeg. Zeg wat er mis is en wat te doen, zoals "Wachtwoord moet minstens 12 tekens bevatten" of "E-mailadres mist het @-teken".

Kopieerbare reviewprompts (React en Flutter)

Gebruik deze prompts wanneer je een scherm reviewt (of wanneer je een tool als Koder.ai vraagt componenten bij te werken):

• “Loop dit scherm door en zorg dat elk tekstveld een zichtbaar label heeft en dat de toegankelijke naam ermee overeenkomt (React: label + htmlFor, aria-labelledby; Flutter: InputDecoration.labelText).”
• “Vind icon-only knoppen en geef elk een toegankelijke naam die de actie uitlegt (React: aria-label; Flutter: Tooltip of Semantics(label: ...)).”
• “Controleer koppen: gebruik juiste headingniveaus in React en duidelijke sectietitels in Flutter zodat de structuur correct uitgelezen wordt.”
• “Herschrijf validatiefouten zodat ze zeggen wat er gebeurde en hoe het te repareren is, en zorg dat de fout wordt aangekondigd wanneer deze verschijnt.”

Aankondigingen voor dynamische updates

Veel schermen veranderen zonder paginaherlaad: profiel opslaan, item toevoegen, resultaten laden. Zorg dat die updates aangekondigd worden.

Voor React heeft een aria-live regio de voorkeur (polite voor "Opgeslagen", assertive voor kritieke fouten). Voor Flutter gebruik Semantics en maak statusberichten ook visueel zichtbaar (bijv. een banner of SnackBar) zodat ze worden voorgelezen, niet alleen getoond. Een snelle check: trigger "Opslaan" en bevestig dat je een korte boodschap hoort zoals "Wijzigingen opgeslagen" zonder dat de focus van de knop wegspringt.

Contrast- en visuele duidelijkheidschecks die niet lang duren

Je kunt de meeste contrast- en duidelijkheidsproblemen in enkele minuten vinden als je je richt op de plekken waar mensen echt moeite mee hebben: kleine tekst, iconen, focusringen en statuskleuren. Dit is een praktisch deel van toegankelijkheids-prompts voor React en Flutter UI-reviews omdat het makkelijk te verifiëren en te herstellen is.

Een 10-minuten contrastpass

Begin met het scannen van één scherm op 100% zoom en daarna op 200%. Als iets moeilijk leesbaar wordt, is het meestal een contrast-, gewicht- of spacingprobleem, niet een "gebruikersprobleem".

Controleer eerst deze vijf plekken:

• Bodytekst, bijschriften en helpertekst (vooral lichtgrijs op wit)
• Uitgeschakelde staten (moet eruitzien alsof het uitgeschakeld is, maar nog steeds leesbaar)
• Iconen zonder labels (een vage icoon is voor veel gebruikers effectief onzichtbaar)
• Focusindicatoren (ring/outline moet contrasteren met de achtergrond)
• Fout- en succesmeldingen (tekst en icoon, niet alleen kleur)

Een snelle vuistregel: als je moet knijpen met je ogen, zullen je gebruikers dat ook doen. Als je twijfelt over een kleurcombinatie, schakel de tekst tijdelijk naar puur zwart of puur wit. Als de leesbaarheid sterk verbetert, was het contrast te laag.

Focuszichtbaarheid wordt vaak gemist. Zorg dat de focusring dik genoeg is om op te merken en niet dezelfde kleur als de achtergrond heeft. Als je een "geselecteerde" staat in een lijst hebt, moet die ook in grijstinten duidelijk zijn, bijvoorbeeld door een icoon, onderstreping of een duidelijke rand toe te voegen.

Mobiele duidelijkheid: targets en thema's

Op mobiel gaat duidelijkheid ook over touch. Knoppen en icon-only acties moeten ruime tapdoelen en voldoende afstand hebben zodat gebruikers niet per ongeluk het verkeerde element raken.

Doe een snelle thema-check: schakel dark mode en, indien ondersteund, hoge-contrastinstellingen aan. Controleer tekst op oppervlakken, scheidingen en focusringen opnieuw. Een veelvoorkomende bug is een focusring die in dark mode verdwijnt of een "inactief" icoon dat bijna dezelfde kleur krijgt als de achtergrond.

Als je UI snel genereert in een tool zoals Koder.ai, voeg dan een extra reviewstap toe: vraag om een "contrast- en focusring-pass" na de eerste lay-out, voordat je de visuals perfectioneert.

Veelgemaakte fouten die telkens terugkomen

De meeste toegankelijkheidsbugs herhalen zich omdat ze aanvoelen als kleine UI-aanpassingen, niet als productgedrag. Als je toegankelijkheids-prompts voor React en Flutter UI-reviews uitvoert, let dan eerst op deze patronen.

Placeholdertekst is geen label. Een placeholder verdwijnt zodra iemand typt en veel schermlezers behandelen het niet als de veldnaam. Gebruik een echt zichtbaar label (of een expliciete toegankelijke naam) zodat het veld begrijpelijk is wanneer het leeg, ingevuld of fout is.

Focusstijlen worden verwijderd omdat ze "er lelijk uitzien." Dat maakt toetsenbordgebruikers vaak verloren. Als je de standaardoutline verandert, vervang deze dan door iets evenduidelijks: een sterke ring, een achtergrondverandering en voldoende contrast met de pagina.

Een andere terugkerende fout is nep-knoppen. In React is het verleidelijk een div met onClick te gebruiken en in Flutter een Container met GestureDetector. Zonder de juiste semantiek lijden toetsenbordondersteuning en schermlezers. Native controls (button, a, TextButton, ElevatedButton) geven je focus, rol, uitgeschakelde staat en activeringsgedrag gratis.

Dialog- en formulieren-focusbugs zijn subtiel maar pijnlijk. Na het sluiten van een modal of het opslaan van een formulier springt focus vaak naar de top van de pagina of verdwijnt. Dat gebeurt wanneer focus niet wordt teruggezet naar de control die de dialoog opende, of wanneer de save-actie de pagina her-rendered en focus verliest. Gebruikers moeten dan opnieuw zoeken waar ze waren.

Overmatig gebruik van ARIA (of Flutter Semantics) kan dingen ook breken. Rollen en labels overal toevoegen kan conflicteren met wat het native element al biedt, wat leidt tot dubbele aankondigingen of verkeerde namen.

Een korte "repeat issues" check die je kunt vragen tijdens het reviewen van een scherm:

• Bevestig dat elk invoerveld een persistent label heeft, niet alleen een placeholder
• Bevestig dat elk interactief element een echt control is met de juiste rol
• Bevestig dat focus altijd zichtbaar is en nooit verwijderd wordt zonder vervanging
• Bevestig dat focus terugkeert naar de trigger na dialogen, toasts en saves
• Bevestig dat ARIA/Semantics alleen toevoegt wat native controls niet kunnen

Als je UI genereert vanuit chat (bijv. in Koder.ai), neem deze criteria op als acceptatie-eisen zodat het eerste ontwerp de valkuilen al vermijdt.

Voorbeeld-doorloop: één scherm, end-to-end

Stel je een eenvoudige Instellingenpagina voor: een profielformulier (Naam, E-mail), twee toggles (E-mailmeldingen, Donker thema), een "Wijzigingen opslaan"-knop en een toast die na opslaan verschijnt.

Begin met het toetsenbord. De verwachte focusvolgorde moet overeenkomen met de visuele volgorde, van boven naar beneden en van links naar rechts. Tabbing mag nooit naar de toast, de footer of een verborgen menu springen.

Een snelle controle die voor de meeste toegankelijkheids-prompts voor React en Flutter UI-reviews werkt:

• Druk Tab vanaf boven: focus landt op Naam, daarna E-mail, dan de toggle voor E-mailmeldingen, dan Donker thema en dan Wijzigingen opslaan.
• Gebruik Shift+Tab om terug te gaan en bevestig dat het netjes omkeert.
• Op toggles moet Space wisselen. Pijltjestoetsen mogen de focus niet vasthouden.
• Op Wijzigingen opslaan moet Enter verzenden en de focus mag na versturen niet verdwijnen.
• Wanneer de toast verschijnt, moet de focus blijven waar die was, tenzij de toast een actie heeft (zoals "Ongedaan maken").

Controleer nu wat een schermlezer aankondigt. Elk controlelement heeft een duidelijke naam, rol en status nodig. Bijvoorbeeld: "Naam, tekstveld, verplicht" en "E-mailmeldingen, schakelaar, aan". Als het E-mailveld een fout heeft, moet die worden aangekondigd wanneer de focus het veld betreedt en wanneer de fout verschijnt (bijv. "E-mail, tekstveld, ongeldig, voer een geldig e-mailadres in"). De Opslaan-knop moet voorgelezen worden als "Wijzigingen opslaan, knop" en alleen uitgeschakeld zijn als je ook uitlegt waarom.

Voor contrast, controleer normale tekst, placeholdertekst en foutmeldingen. Controleer ook de focusring: deze moet makkelijk te zien zijn op zowel lichte als donkere achtergronden. Foutstaten mogen niet alleen op rood vertrouwen. Voeg een icoon, duidelijke tekst of beide toe.

Maak van wat je vindt een korte fix-lijst:

• Herstel de focusvolgorde zodat deze overeenkomt met de lay-out.
• Voeg ontbrekende toegankelijke namen toe voor toggles en iconen.
• Kondig fouten aan bij het veld (niet alleen als banner).
• Verbeter focusstijlen en laag-contrast placeholder/fouttekst.
• Maak de toast niet-blokkerend, of alleen focusbaar als er acties op staan.

Als je in Koder.ai bouwt, plak deze schermbeschrijving en je bevindingen in de chat en vraag of het de React- of Flutter-UI bijwerkt zodat deze het verwachte toetsenbord- en schermlezergedrag volgt.

Volgende stappen: hergebruik deze checklist en veranker hem in je workflow

Als je wilt dat toegankelijkheids-prompts voor React en Flutter UI-reviews op lange termijn iets opleveren, behandel ze dan als een herhaalbare gewoonte, niet als een eenmalige opruiming. Het doel is dezelfde kleine set checks elke keer te doen wanneer je een nieuw scherm of component toevoegt.

Houd een enkele "definition of done" voor UI-wijzigingen. Voordat iets live gaat, doe je een snelle pas die toetsenbord, focus, namen en contrast dekt. Het kost maar enkele minuten als je het vaak doet.

Hier is een snelle checklist die je op bijna elke UI kunt draaien:

• Toetsenbord: kun je elk interactief element bereiken en gebruiken zonder muis?
• Focus: is de focus zichtbaar en beweegt die in een logische volgorde?
• Labels: heeft elk veld en elke knop een duidelijke naam (inclusief iconen)?
• Aankondigingen: worden statusveranderingen aangekondigd (fouten, laden, succes)?
• Contrast: is tekst leesbaar en blijven uitgeschakelde staten begrijpelijk?

Sla je beste prompts op als templates. Een eenvoudige manier is één "React review prompt" en één "Flutter review prompt" die je aan het einde van elke change request plakt. Voeg daarna één regel toe die de nieuwe component beschrijft en speciaal gedrag (modal, stepper, lijst met infinite scroll).

Voer dezelfde checks opnieuw uit bij elk nieuw component vóór release, ook al voelt het repetitief. Toegankelijkheidsproblemen worden vaak geïntroduceerd door kleine bewerkingen: een nieuwe icon-only knop, een custom dropdown, een toastbericht of een focusval in een dialoog.

Als je met Koder.ai bouwt, plak de prompts in de chat en vraag om specifieke fixes, geen algemene verbeteringen. Gebruik dan planningmodus om de impact te reviewen vóór het toepassen van wijzigingen. Maak een snapshot vóór de toegankelijkheidspass en gebruik rollback als een fix lay-out of gedrag breekt. Dat maakt het veiliger om te itereren op focusvolgorde en semantiek zonder angst.

Na je toegankelijkheidspass kun je het als een release-gate behandelen: exporteer de broncode voor je repo-workflow, of deploy en host de app en koppel een custom domein zodra je tevreden bent met de resultaten.