Toegankelijke checkoutformulieren in Shopify: de bouwvolgorde die ook converteert

Ergens op je roadmap staat een regel met EAA-compliance. Die hoort bij legal of development en staat te boek als kostenpost. Op een andere plek staat een CRO-backlog, van het growth-team, en die staat te boek als omzet. Allebei gaan ze over hetzelfde checkoutformulier. Toch komen de twee lijsten zelden samen: ze spreken een andere taal en belanden in een andere sprint.

De ingrepen eronder zijn bijna helemaal dezelfde. Labels die blijven staan, foutmeldingen die precies zeggen wat er mis is, een checkout die je met alleen het toetsenbord kunt afronden: een toegankelijkheidsauditor en een conversiespecialist zouden hetzelfde lijstje opschrijven. Wat het resultaat bepaalt, is de volgorde waarin je ze bouwt. En die volgorde hangt af van iets wat de meeste checklists overslaan: op welke Shopify-checkout je eigenlijk werkt.

Begin hier: op welke checkout bouw je eigenlijk?

In welke volgorde je toegankelijke checkoutformulieren bouwt, hangt af van de Shopify-checkout die je draait. Die bepaalt namelijk hoeveel van het formulier je zelf mag aanpassen. De standaardcheckout van Shopify is al redelijk toegankelijk en hoef je vooral te bewaken. Met Checkout Extensibility op Plus of met een headless build krijg je meer van het formulier in handen, en daarmee ook meer verantwoordelijkheid voor toegankelijkheid en conversie.

Dat verschil weegt zwaarder dan welke losse ingreep ook. Een platte “checklist toegankelijkheid in 40 punten” geeft een webshop op de standaardcheckout hetzelfde lijstje als een team met een eigen Plus-build, terwijl hun prioriteiten bijna omgekeerd liggen. De lijst is gedeeld. De volgorde niet.

Shopify zegt in zijn eigen toegankelijkheidsrichtlijnen voor wie op het platform bouwt duidelijk dat standaardcomponenten al met labels, focusafhandeling en toetsenbordondersteuning komen. In de praktijk betekent dat: op de standaardcheckout zit je risico niet in het formulier dat Shopify je gaf. Het zit in wat een theme-aanpassing of een app van derden er ongemerkt overheen legt. Op Plus Checkout Extensibility erft elke extensie en elk eigen veld dat je toevoegt dezelfde verantwoordelijkheid voor toegankelijkheid die de standaardvelden al droegen. En draai je een headless storefront, dan zijn de delen van de flow die je zelf bouwde (de winkelwagen, het adresformulier, elke stap vóór de betaalpagina van Shopify) helemaal jouw zaak, ook al is die betaalpagina dat niet.

Zoek dus eerst je plek in die tabel, voordat je ook maar één label aanraakt. Dan weet je of je werk neerkomt op bewaken, op een audit van je extensies of op een volledige build. Alles wat hierna komt, volgt uit dat antwoord. (Wat er aan te passen viel toen Shopify alle winkels naar het nieuwe framework overzette, lees je in ons stuk over Shopify Checkout Extensibility. Daar staat precies waar je nu verantwoordelijk voor bent.)

Eerst: labels die een screenreader én autofill kunnen lezen

Begin bij de veldlabels, want met één ingreep help je twee systemen tegelijk. Een checkoutveld heeft een programmatisch label nodig (een echt <label> dat aan het invoerveld gekoppeld is, of een gelijkwaardig aria-label) plus een zichtbaar label. Hetzelfde label dat een screenreader voorleest, gebruiken de browser, een wachtwoordmanager en autofill op de telefoon om het veld automatisch in te vullen.

Daarom staan labels bovenaan. Elke andere ingreep helpt één groep klanten of één moment in de flow. Labels helpen ze allemaal, op elke checkout, vanaf de eerste keer. Een veld dat hulpsoftware kan lezen, kan autofill ook invullen. En de meeste checkouts gebeuren op een telefoon, waar autofill het meeste werk doet.

Het gaat verraderlijk mis, want het formulier ziet er gewoon af uit. Een placeholder met “Adresregel 2” lijkt een label, tot de klant begint te typen en de hint verdwijnt. Een screenreadergebruiker houdt dan een naamloos vakje over, en een ziende klant gaat twijfelen in welk veld hij zit. Hetzelfde veld zonder label is onzichtbaar voor autofill. De telefoon die het met één tik had ingevuld, laat de klant nu alles zelf typen. Placeholdertekst is een hint, geen label. Behandel je hem als versiering, dan raken beide systemen het veld kwijt.

Twee toevoegingen maken het af en kosten bijna niets. Geef elk invoerveld het juiste autocomplete-attribuut (email, given-name, postal-code enzovoort), zodat de browser weet wat erin hoort. En moet een label om layoutredenen onzichtbaar zijn, verberg het dan met een utility class die screenreaders ongemoeid laat, in plaats van het te verwijderen. Zo blijft de programmatische naam bestaan, ook als de zichtbare moet wijken. Voor een screenreader en voor een mobiel toetsenbord is het resultaat hetzelfde: een formulier dat zijn eigen velden benoemt.

Daarna: foutmeldingen die het probleem benoemen

Een toegankelijke foutmelding doet drie dingen tegelijk. Ze zegt welk veld fout ging, ze zegt in gewone taal waarom, en ze meldt zich bij de screenreader in plaats van alleen als rode rand te verschijnen. In markup betekent dat: de melding is met aria-describedby aan het invoerveld gekoppeld en gaat via een aria-live-regio naar hulpsoftware, zodat je haar hoort en niet alleen ziet.

Voor conversie geldt precies hetzelfde, alleen bekeken vanaf de kant van de klant. Een foutmelding die het veld noemt, maakt van een afhaker iemand die het nog een keer probeert. “Vul een geldige postcode in” wijst direct naar de oplossing. Een algemene balk met “Er ging iets mis”, of een veld dat zonder tekst rood wordt, laat de klant zelf naar het probleem zoeken. En zoeken bij de betaalstap is precies waar winkelwagens blijven staan. Een screenreadergebruiker krijgt dezelfde fout in een ergere vorm: de validatie slaat aan, de rand verandert en er wordt niets voorgelezen. Hij hoort dat de bestelling mislukt is, maar niet waar. Beide klanten lopen tegen dezelfde muur. Een van hen kan hem niet eens zien.

Verplichte velden hebben een stillere versie van dezelfde valkuil. Een rood sterretje alleen zegt niets tegen een klant die geen kleur ziet, en ongeveer één op de twaalf mannen is in enige mate kleurenblind. Markeer verplichte velden met het woord “verplicht” in het label of met het juiste ARIA-attribuut, niet alleen met kleur. Dan komt de instructie bij iedereen aan: bij kleurenblinde klanten, bij screenreadergebruikers en bij de ziende klant die te snel scant om een legenda te ontcijferen.

Die volgorde heeft een reden. Labels vertellen wat een veld is; foutafhandeling vertelt wat je moet doen als een veld niet klopt. Repareer je eerst de labels, dan komen veel validatiefouten nooit voor, want een goed gelabeld en automatisch ingevuld veld is de eerste keer al goed ingevuld. Bouw je daarna de foutmeldingen, dan vang je op wat er nog doorheen glipt. Je lapt dan geen formulier op dat niemand kon lezen.

Dan: een checkout die je met alleen het toetsenbord afrondt

Een klant moet de hele aankoop, van winkelwagen tot geplaatste bestelling, met alleen het toetsenbord kunnen doorlopen. Een zichtbare focusrand laat zien waar hij is, en de focusvolgorde loopt zoals je de pagina leest. Verdwijnt die rand als je door de checkout tabt, springt de focus alle kanten op of blijft hij hangen in een component, dan is de flow stuk voor toetsenbord- en screenreadergebruikers. En ongemerkt slechter voor alle anderen.

Dit staat op drie en niet op één, omdat het op de standaardcheckout van Shopify grotendeels al geregeld is. De toegankelijkheidseisen voor themes van Shopify beschrijven het gedrag waar de standaard op gebouwd is: een zichtbare focusrand op elk interactief element, een focusvolgorde van boven naar beneden en van links naar rechts, en modals en uitschuifbare winkelwagens die de focus naar zich toe halen en bij Esc teruggeven. Je hoeft dat niet na te bouwen. Je moet controleren dat niets wat je hebt toegevoegd het kapot heeft gemaakt.

Toetsenbordbediening gaat kapot op dezelfde plek waar labels en foutmeldingen kapotgingen. Daarom loont het om het patroon één keer te benoemen en daarna te hergebruiken. Eigen componenten zijn het zwakke punt. Een winkelwagen die openschuift maar de focus niet naar zich toe haalt, laat een toetsenbordgebruiker erachter doortabben, door de pagina die hij dacht te hebben verlaten. Een eigen datumkiezer of variantkiezer zonder toetsenbordafhandeling wordt halverwege de checkout een doodlopende weg. Een CSS-override die de focusrand weghaalt omdat het strakker oogt, neemt het enige signaal weg waarmee een toetsenbordgebruiker ziet waar hij is. Zie toetsenbordbediening als de kanarie in de kolenmijn voor je aanpassingen: komt een toetsenbord niet door een component die je hebt toegevoegd, dan komt de conversie die ervan afhing er ook niet door.

Eén eis mis je makkelijk, omdat hij klinkt als een opmerking over mobiel design en niet over toegankelijkheid. Interactieve elementen, de bestelknop inbegrepen, moeten groot genoeg zijn om zeker te raken: ongeveer 44 bij 44 pixels. Die maat beschermt klanten met een motorische beperking. En op de telefoon, waar de meeste checkouts plaatsvinden, beschermt hij elke duim die naar “Bestelling plaatsen” reikt. Een knop die te klein is om aan te tikken, is een toegankelijkheidsprobleem en een reden om af te haken, in dezelfde pixel.

Waar deze volgorde misgaat: eigen velden, apps en extensies

Een bouwvolgorde werkt beter dan een checklist, omdat de standaard zelden faalt. Wat faalt, is alles wat erbovenop komt, en toevoegingen hebben een volgorde die een platte lijst niet kan laten zien. De standaardcheckout van Shopify heeft labels, foutafhandeling en toetsenbordondersteuning al aan boord. Het cadeauveld dat een app vorig kwartaal toevoegde, de leverdatumkiezer die een developer erop schroefde, de upsell-widget die tussen de adresstap en de betaling opduikt: die kwamen allemaal na de audit waarmee de checkout werd goedgekeurd. Elk ervan erfde de verantwoordelijkheid van de standaardvelden, maar niet de zorg waarmee die gebouwd zijn.

Dat verandert wat “je checkout controleren” eigenlijk betekent. Een audit leest het formulier van links naar rechts en van boven naar beneden, zoals de pagina rendert. Een bouwvolgorde leest het op herkomst: wat hebben we toegevoegd, in welke volgorde, en welke toevoeging heeft waarschijnlijk de screenreader, de voorgelezen foutmeldingen of de toetsenbordroute gebroken? Het nieuwste en meest aangepaste veld is de eerste verdachte, niet de laatste. Dat had de meeste kans om een standaard te overschrijven en werd bij binnenkomst het minst gecontroleerd.

Het risico groeit met het deel van het formulier dat je zelf in handen hebt, en daar betaalt de tabel van het begin zich uit. Op de standaardcheckout is de audit kort: loop de apps en theme-aanpassingen na die aan de checkout zitten en controleer dat geen ervan een label of focusrand heeft weggehaald. Op Plus Checkout Extensibility is elke UI-extensie een klein formulier op zich, met eigen labels, foutmeldingen en focusgedrag. Dat controleer je voordat hij live gaat, niet nadat een klant het meldt. Bij een headless build is er voor de stappen die je zelf bouwde geen standaard om op terug te vallen. Daar draagt de hele eigen flow dus het volle gewicht van de drie ingrepen hierboven. Elke keer dezelfde drie ingrepen. Alleen het terrein waarop ze moeten werken verschilt.

Hierin zit een governancevraag verstopt, en juist die slaan de meeste teams over. Als toevoegingen een toegankelijke checkout breken, dan is toegankelijkheid geen project dat ooit af is. Het is een poort waar elk nieuw veld, elke app en elke extensie doorheen moet voordat het de checkout bereikt. De teams met een checkout die toegankelijk blijft, zijn niet de teams die één keer het strengst hebben geaudit. Het zijn de teams die zijn gestopt met het uitrollen van componenten zonder label en zonder toetsenbordbediening.

Controleer de build, zet hem niet alleen live

Een toegankelijke checkout controleer je met drie rondes over de enige flow die ertoe doet. Rond een echte aankoop af met alleen het toetsenbord. Doe het nog een keer met een screenreader aan. En laat een automatische scan lopen voor wat beide rondes missen. Alle drie gaan van begin tot eind, van winkelwagen tot bevestiging, want juist bij de checkout houdt testen op templateniveau op.

De toetsenbordronde geeft het snelste signaal, dus die doe je eerst. Leg de muis weg, tab van de winkelwagen tot een geplaatste bestelling en let op drie dingen: een focusrand die je altijd ziet, een focusvolgorde die nooit onverwacht verspringt, en geen component waarin je vastloopt of die je niet kunt bedienen. Loop je vast, dan loopt een klant die alleen het toetsenbord gebruikt op dezelfde plek vast. Net als een groot deel van de screenreadergebruikers, die op dezelfde manier navigeren. De screenreaderronde is de tweede lezing, met NVDA, VoiceOver of TalkBack. Luister of elk veld zijn label voorleest, of fouten hardop worden gemeld als de validatie faalt, en of de volgorde van wat je hoort klopt met de volgorde van het formulier.

Automatische scanners komen als laatste, en met mate. Ze zijn nuttig om op vaste momenten regressies te vangen en om duidelijke fouten in contrast en labels te signaleren. Maar ze vinden maar een deel van de echte drempels; meestal wordt ongeveer een derde genoemd. Een groene score op een checkout die je met het toetsenbord niet kunt afronden, is schijnzekerheid. Gebruik de scan om te zien of er in de loop van de tijd iets verschuift, niet om de flow goed te keuren. Dat doen de handmatige rondes.

Eén gewoonte houdt de hele bouwvolgorde overeind. Doe de ronde met toetsenbord en screenreader niet één keer aan het eind, maar telkens als er een nieuw veld, een nieuwe app of een nieuwe extensie in de checkout komt. Juist die toevoegingen maken het werk ongemerkt ongedaan. Controleren is niet de laatste stap van het project. Het is de poort uit het vorige deel, in een ander jasje.

Veelgestelde vragen

Levert een toegankelijke checkout echt meer conversie op, of gaat het alleen om compliance? 

Allebei, met dezelfde ingrepen. Velden met een label worden sneller automatisch ingevuld, specifieke foutmeldingen maken van afhakers mensen die het nog eens proberen, en een flow die je met het toetsenbord kunt bedienen haalt frictie weg die elke klant voelt. Toegankelijkheid en conversie zijn dezelfde werklijst, alleen in twee vakjargons opgeschreven. Waarom die overlap zo groot is, lees je in het artikel waar we hieronder naar linken.

Is de standaardcheckout van Shopify al toegankelijk? 

Grotendeels wel. De standaardcheckout van Shopify heeft programmatische labels, voorgelezen foutmeldingen, toetsenbordondersteuning en focusafhandeling al aan boord. De drempels komen meestal van wat erbovenop ligt: CSS-overrides in het theme, apps van derden, en eigen velden of extensies die een label of focusrand weghalen die de standaard nooit kwijt was. Test je eigen checkout in plaats van aan te nemen dat de standaard nog overeind staat.

Kan ik de toegankelijkheid van mijn checkout verbeteren zonder developer? 

Voor een deel. Kleurcontrast verbeteren, specifieke foutteksten schrijven en verplichte velden met woorden markeren in plaats van alleen met kleur: dat zijn vaak aanpassingen in de theme-editor of in de tekst. Programmatische labels, aria-live-meldingen, focusbeheer in eigen componenten en alles wat een Plus-extensie of headless flow raakt, vragen meestal om een developer.

Wat breekt de toegankelijkheid van een Plus- of maatwerkcheckout het vaakst? 

Toevoegingen. Eigen velden, upsell-widgets, leverdatumkiezers en app-koppelingen zijn de vaste boosdoeners. Elk ervan erft de verantwoordelijkheid van de standaardvelden, maar wordt zelden even streng gecontroleerd. Ontbrekende formulierlabels en een toetsenbordfocus die vastzit in een eigen component worden het vaakst genoemd, en beide houden een aankoop direct tegen.

Wat je moet onthouden

• Je type checkout bepaalt de bouwvolgorde voor toegankelijke checkoutformulieren. Op de standaardcheckout bewaak je wat er is, op Plus Extensibility audit je je extensies, en headless is een volledige build.

• Labels komen eerst, omdat één ingreep twee systemen helpt: het label dat een screenreader voorleest, is het label waarmee autofill het veld invult.

• Foutmeldingen komen daarna. Een specifieke melding die aan het veld gekoppeld is en wordt voorgelezen, maakt van een afhaker iemand die het nog eens probeert, of hij nu kan zien of niet.

• Toetsenbordbediening is de kanarie in de kolenmijn voor je aanpassingen. Komt een toetsenbord niet door een component die je hebt toegevoegd, dan komt de conversie die ervan afhing er ook niet door.

• De standaard faalt zelden, toevoegingen wel. Audit op herkomst (nieuwste en meest aangepaste eerst), niet van links naar rechts.

• Controleer met een toetsenbordronde en een screenreaderronde van begin tot eind. Automatische scanners vangen maar een deel, dus gebruik ze om verschuivingen te zien, niet om goed te keuren.

Eén checkout, één bouwvolgorde

Toegankelijke checkoutformulieren en checkoutformulieren die converteren zijn geen twee projecten die om dezelfde sprint vechten. Het is één build, en de volgorde hierboven voorkomt dat je een compliancedeadline en een conversiebacklog twee keer oplost. Bewaar deze volgorde en deel hem met wie de volgende wijziging aan je checkout doet. Het werk houdt alleen stand als degene die het volgende veld toevoegt hem ook doorloopt.

Een ervaren Shopify Plus-bureau hanteert zo'n bouwvolgorde bij elk checkoutproject als vaste werkwijze, niet als extra verzoek.

Wil je het waarom hierachter nog scherp krijgen voor je team? Het stuk over hoe toegankelijke checkoutverbeteringen je Shopify-conversie verhogen behandelt de overlap volledig: dezelfde labels, foutmeldingen en toetsenbordroutes, bekeken vanaf de omzetkant.