Afbeeldingsbeschrijving: Een klant betaalt met een kaart via een draagbare betaalterminal.
Afrekenen bij e-commerce: het meest omstreden onderdeel van het internet
Afrekenen bij e-commerce: het meest omstreden onderdeel van het internet
Uit een dataset van 8.788 rechtszaken over de toegankelijkheid van federale websites komt een weinig rooskleurig patroon naar voren. Steeds weer dezelfde paar bugs komen in de productie terecht in steeds weer dezelfde paar fasen – en steeds weer dezelfde paar eisers ontdekken ze. Van de 81.509 problemen die advocaten in gerechtelijke stukken hebben opgesomd, zijn er meer dan 4.050 geconcentreerd in de vijf onderdelen die van een browser een koper maken: het winkelwagentje, het adres, de betaling, foutmeldingen en de afrekenknop zelf.
Waarom het afrekenen de overtreding is die je geld kost
Rechtszaken over webtoegankelijkheid worden aangespannen op elk niveau van een website – de startpagina, de navigatie, de voettekst, de zoekfunctie. Maar in de zeldzame gevallen waarin een klacht tot een beslissende motie leidt, laten rechtbanken zich niet beïnvloeden door esthetische belemmeringen. Zij laten zich beïnvloeden door functionele belemmeringen. Een blinde klant die een hero-banner niet kan vinden, heeft, in de meest rechttoe rechtaan juridische bewoordingen, niets verloren. Een blinde klant die een aankoop niet kan afronden, is een dienst ontzegd die de verkoper aan elke andere bezoeker heeft aangeboden. Dat is de schoolvoorbeeldformulering van een schending van Titel III, en het is hetzelfde feitenpatroon dat terugkeert in elke sommatiebrief die de eisers opstellen.
Dit is de reden waarom de meest genoemde onderdelen in de dataset niet de onderdelen zijn die in totaal de meeste klachten opleveren. „Algemeen / Niet-gecategoriseerd“ is veruit de grootste categorie (38.671 meldingen). Maar op basis van het geldbedrag dat per fout op het spel staat, leidt de afrekenfunnel tot meer rechtszaken dan alle andere categorieën samen. Elk niet-gelabeld CVC-veld is een denial-of-service. Elke onaangekondigde "Bestelling bevestigd" is een transactie waarvan de gebruiker niet kan bewijzen dat hij deze heeft uitgevoerd. Elk modaal venster dat de focus vasthoudt op de stap "Coupon toepassen" is een korting waarvoor de gebruiker van een schermlezer de volledige prijs heeft betaald om deze over te slaan.
In een Amerikaanse federale rechtbank luidt de vraag niet: „Is de startpagina toegankelijk?“, maar: „Kon de eiser kopen wat de gedaagde aanbood?“ Het afrekenen is het enige punt waarop het antwoord eenduidig is, en het enige punt waarop de schadevergoeding eenvoudig te vorderen is.
De dataset
De analyse waarop dit artikel is gebaseerd, is gebaseerd op twee onafhankelijke corpora. Het eerste is een gestructureerd PACER-overzicht van 8.788 federale civiele zaken die tussen januari 2007 en april 2026 zijn aangespannen op grond van de Americans with Disabilities Act en daarmee samenhangende staatswetgeving, waarbij elke zaak is gekoppeld aan de eiser(s), verweerder(s), de datum van indiening en de datum van uitspraak. De tweede is een parallelle extractie van 81.509 afzonderlijke toegankelijkheidskwesties die uit de tekst van die dossiers zijn gehaald – de feitelijke zinnen die advocaten schreven om te beschrijven wat hun cliënten niet konden doen.
Door deze twee bronnen te combineren, kunnen we vragen beantwoorden die een enkele bron niet kan beantwoorden. We weten niet alleen welke websites voor de rechter zijn gedaagd, maar ook wat advocaten de rechtbank hebben verteld wat er misging – en op welk punt in het gebruikersproces dat gebeurde. Voor dit artikel hebben we de verzameling problemen gefilterd op vijf categorieën in de aankooptrechter: AFREKENPROCES, WINKELWAGEN, TOEVOEGEN AAN WINKELWAGEN, BETALING , ADRESBEHEER. Samen zijn deze vijf aspecten goed voor 4.050 problemen – ongeveer 5% van de verzameling, maar het deel met de sterkste causale link naar doorslaggevende schade.
De ontwikkeling die niemand in het plan voor het vierde kwartaal had ingecalculeerd
Voordat we ingaan op de binnenkant van de trechter, is het de moeite waard om vast te stellen hoe steil de buitenkant inmiddels is geworden. Het aantal jaarlijkse aanmeldingen is sinds 2020 met een factor tien toegenomen en blijft in een stroomversnelling komen. Het onderstaande cijfer voor 2026 heeft alleen betrekking op het eerste kwartaal; op basis van een extrapolatie voor het hele jaar lijkt het erop dat het aantal de 4.500 zal overschrijden – bijna tien keer zoveel als het referentiecijfer van 2021.
▱ 2026 (gedeeltelijk): aanvragen tot en met april 2026. Gezien het tempo in het eerste kwartaal ligt het jaar op koers voor ongeveer 3.500 aanvragen, wat in lijn is met de trend van 2025.
Twee punten die het overwegen waard zijn. Ten eerste is 2021 het keerpuntjaar – dat samenviel met de e-commerceboom na de pandemie en een golf van jurisprudentie van staatsrechtbanken (met name Robles v. Domino’s, waarvan het Hooggerechtshof in 2019 het beroep afwees), waardoor federale rechtbanken in het Negende Circuit websites gingen beschouwen als „openbare gelegenheden“ in de zin van Titel III. Ten tweede is de groei nog niet afgevlakt. Sinds 2021 is elk jaar een nieuw record bereikt, en elk nieuw jaarlijks record is behaald terwijl Titel III, formeel gezien, ongereguleerd is gebleven voor particuliere commerciële websites.
De trechter binnen de trechter
Van de 81.509 kwesties die op basis van ingediende stukken zijn gecatalogiseerd, vallen er 4.050 onder een van de vijf onderstaande categorieën van de aankooptrechter. De proportionele verdeling komt vrijwel perfect overeen met de klassieke conversietrechter: er worden meer kwesties gemeld in de vroege fasen van het traject, waarbij bij elke stap zowel legitieme gebruikers als juridische belemmeringen wegvallen.
De categorie „Afrekenproces“ is het grootst, omdat de meeste meldingen de ervaring als één doorlopend traject beschrijven. Maar de uitsplitsing is leerzaam: het winkelwagentje en 'toevoegen aan winkelwagentje' samen (1.740 meldingen) genereren iets meer klachten dan de afrekenpagina zelf. Dat komt deels doordat het winkelwagentje de plek is waar de eerste onomkeerbare actie plaatsvindt – zodra de gebruiker van een schermlezer niet kan bevestigen dat een artikel is toegevoegd, wordt elke volgende stap in het duister uitgevoerd. Problemen die stroomopwaarts beginnen, stapelen zich stroomafwaarts op.
De vijf meest voorkomende fouten, in volgorde van frequentie
Wanneer de 4.050 problemen in de afrekenfase worden vergeleken met hun beschrijvingen in platte tekst, blijkt dat vijf soorten fouten het grootste deel van de klachten van eisers uitmaken. Hieronder zetten we ze op een rij in volgorde van hoe vaak ze in de ingediende stukken voorkomen, met daarbij de WCAG-criteria die advocaten het vaakst aanhalen.
Bij het toevoegen aan het winkelmandje verschijnt er een visuele bevestiging – een pop-up, een uitschuifbaar winkelmandje of een bijgewerkte badge – die door schermlezers niet wordt voorgelezen. De gebruiker klikt nogmaals, bestelt het artikel dubbel of geeft het op. Dit is de meest genoemde belemmering in klachten over het winkelmandje.
De velden voor kortingscodes zijn niet gelabeld, er worden geen foutmeldingen weergegeven en de inline-validatie wordt alleen als gekleurde tekst weergegeven. Eisers voeren vaak aan dat ze de volledige prijs hebben betaald omdat het kortingskanaal niet toegankelijk was – een concrete financiële schade.
Dialoogvensters voor adresbevestiging, tussenschermpjes met de vraag „Weet u het zeker?“, upsells en CAPTCHA-tests worden weliswaar visueel weergegeven, maar krijgen nooit programmatisch de focus. Gebruikers van toetsenborden en schermlezers kunnen deze vensters niet sluiten of er niet voorbij gaan.
Lege verplichte velden, creditcards die niet aan de regex-voorwaarden voldoen en adresfouten worden alleen aangegeven door middel van rode randen of validatie-indicatoren met verdwijnende tekst. De gebruiker van een schermlezer verzendt het formulier, krijgt geen feedback te horen en gaat ervan uit dat de bestelling is doorgegaan. WCAG 3.3.1 is het meest genoemde criterium in rapportages over het afrekenproces.
Kaartnummer, vervaldatum, postcode, „Hetzelfde als factuuradres“ – velden zonder label worden aangekondigd als „leeg“ of „tekst bewerken“. Gebruikers kunnen niet zien welk veld wat is, vullen ze in de verkeerde volgorde in en veroorzaken validatiefouten die zelf niet worden aangekondigd (zie nr. 4).
Wanneer één enkel veld de validatiecontrole niet doorstaat, wissen sommige afrekenprocessen het hele formulier en laden ze het opnieuw op. Voor gebruikers die er de eerste keer zes minuten over deden om het formulier in te vullen met behulp van ondersteunende technologie, vormt dit een belemmering die niet bestaat voor ziende kopers die met de muis werken – een schoolvoorbeeld van ongelijke toegang.
De criteria die advocaten daadwerkelijk aanvoeren
In de meeste stukken worden de WCAG-criteria niet expliciet genoemd – er worden slechts symptomen beschreven. Wanneer advocaten in hun argumenten in de afsluitende fase wel naar specifieke criteria verwijzen, is de verdeling echter sterk scheefgetrokken. Zes criteria zijn goed voor 89% van alle expliciete verwijzingen; de overige ruim zestig criteria van WCAG 2.2 worden slechts sporadisch genoemd.
| WCAG | Naam van het criterium | Niveau | Geciteerd in | Delen | Waar het bij het afrekenen pijn doet |
|---|---|---|---|---|---|
| 3.3.1 | Foutopsporing | A | 104 | 32.5% | Het formulier heeft de verplichte velden en validatiefouten niet gemarkeerd |
| 2.4.3 | Focus-bestelling | A | 72 | 22.5% | Modalen, dialoogvensters en overgangen tussen stappen verplaatsten de focus niet |
| 2.1.1 | Toetsenbord | A | 43 | 13.4% | PayPal- en Express-knoppen zijn zonder muis niet te bereiken |
| 4.1.3 | Statusberichten | AA | 26 | 8.1% | "Toegevoegd aan winkelwagen", "korting toegepast", "bestelling geplaatst" (zonder geluid) |
| 4.1.2 | Naam, Functie, Waarde | A | 23 | 7.2% | Aangepaste radio-/selectie-widgets geven geen statusgegevens door aan AT |
| 3.3.2 | Etiketten of instructies | A | 18 | 5.6% | CVC, postcode, „Hetzelfde als factuuradres“ wordt weergegeven als „leeg“ |
| 1.3.1 | Informatie en relaties | A | 7 | 2.2% | Richtingaanwijzers niet zichtbaar; groepering van verplichte velden |
| 2.4.7 | Focus zichtbaar | AA | 4 | 1.2% | Er is geen zichtbare nadruk op de betaalknoppen |
| 2.5.3 | Label in naam | A | 1 | 0.3% | Discrepanties bij spraakbesturing tussen de zichtbare en de toegankelijke naam |
Slechts 320 van de 4.050 problemen (ongeveer 8%) vermelden een WCAG-criterium met nummer. De rest beschrijft het symptoom in gewone taal. De implicatie: zelfs als je een vlekkeloos WCAG 2.2 AA-auditrapport inlevert, wordt je engineeringteam nog steeds beoordeeld op de symptomen – “gebruiker kon aankoop niet voltooien” is de norm waar een rechtbank naar kijkt, niet “Succescriterium 3.3.1 geschonden.”
Wat de eisers daadwerkelijk schreven
De dataset is samengesteld uit bij de rechtbank ingediende processtukken. De onderstaande zinnen zijn overgenomen uit die stukken – geanonimiseerd om verwijzingen naar locaties te verwijderen, maar verder ongewijzigd. Ze zijn nuttig omdat ze technische teams laten zien hoe gebruikers, in hun eigen woorden, beschrijven wat advocaten in juridische stukken hebben weergegeven.
Wat deze dataset bindt, is niet de technische verfijning ervan. De belemmeringen die advocaten aanhalen, zijn niet nieuw of onduidelijk – het gaat om dezelfde tiental patronen die zich herhalen in duizenden rechtszaken tegen duizenden gedaagden. De eisers hebben het opsporen van fouten die door de technische teams over het hoofd zijn gezien, in feite tot een gestroomlijnd proces gemaakt, omdat die technische teams hun eigen code niet met een schermlezer hebben getest.
Het 97-dagen-fenomeen
Van de 8.788 zaken in de dataset waren er 6.945 in april 2026 afgerond, met geldige data voor de indiening en de afhandeling. De duur van deze zaken vormt een van de meest veelzeggende verdelingen in de dataset. De mediane tijd tussen de indiening van de klacht en de afronding bedraagt 97 dagen; 83,4% van alle zaken wordt binnen zes maanden afgerond.
Zaken die binnen 180 dagen worden afgerond, leiden vrijwel zonder uitzondering niet tot een gepubliceerde uitspraak ten gronde. Ze worden geschikt. De vorm van deze verdeling vertelt het strategische verhaal van de gehele eisersgroep: massaal zaken aanhangig maken, snel schikken en het kleine aantal beslissende uitspraken vermijden waarmee gedaagden hun schikkingen zouden kunnen onderscheiden van die van andere bedrijven. De mediane schikking vindt plaats voordat een van beide partijen een verzoek tot afwijzing indient.
Omdat zaken snel worden afgerond, bestaat er geen bindende jurisprudentie die verduidelijkt wat onder een „toegankelijke kassa“ wordt verstaan op het niveau dat een senior engineer zou verwachten. De norm wordt in plaats daarvan bepaald door de gezamenlijke inhoud van schikkingsovereenkomsten – waarvan de meeste naleving van WCAG 2.1 AA, een jaarlijkse audit en een herstelplan vereisen. Bedrijven betalen voor naleving van een norm die is vastgelegd in onderhandse contracten, maar nooit is bevestigd in gepubliceerde uitspraken.
Het volumemodel: tien eisers, 1.289 zaken
Het totale aantal – 8.788 zaken – is misleidend zonder een nadere uitsplitsing. De eiserszijde van de rol is sterk geconcentreerd. De tien meest actieve eisers in de dataset zijn samen goed voor 14,7% van alle ingediende zaken. De meest productieve individuele eiser heeft 256 afzonderlijke zaken aanhangig gemaakt.
De namen van eisers zijn weggelaten; de cijfers zijn afgeleid uit PACER-metadata. Van de 8.788 ingediende zaken hebben de tien grootste eisers samen 1.289 zaken aangespannen (14,66%). De grootste individuele eiser komt in bijna 1 op de 35 zaken in de dataset voor als genoemde partij.
Deze concentratie is geen teken van kwade trouw – veel van deze eisers hebben legitieme, gedocumenteerde beperkingen en hebben zelf de belemmeringen ondervonden die in hun stukken worden beschreven. Maar het is wel een teken dat gedaagden die voor de rechter verliezen, zelden verliezen van een onbekende. Dezelfde namen komen steeds weer terug, vaak vertegenwoordigd door dezelfde advocatenkantoren, die vaak gebruikmaken van vrijwel identieke sjablonen. De structuur van de rechtszaak beloont efficiëntie aan de kant van de eiser en capitulatie aan de kant van de gedaagde. Ze beloont geen van beide partijen voor vernieuwende argumenten.
De triagematrix
Als de vraag luidt: „Wat moet ik als eerste aanpakken?“, hangt het antwoord af van twee factoren: hoe vaak een bepaalde belemmering wordt genoemd (frequentie) en in hoeverre deze een transactie direct blokkeert (ernst). In de onderstaande matrix worden beide factoren gecombineerd. De cellen zijn gekleurd op basis van het relatieve aantal vermeldingen in ons corpus van 4.050 afrekenprocessen, waarbij de donkerste cellen de storingspatronen aangeven die het meest de moeite waard zijn om in een sprint aan te pakken.
| Foutpatroon | In winkelwagen | Winkelwagen | Adres | Betaling | Bevestiging |
|---|---|---|---|---|---|
| Status nog niet bekendgemaakt | Hoog | Hoog | Med | Med | Hoog |
| Velden zonder label | – | Laag | Hoog | Hoog | – |
| Fouten die niet worden gemeld | Laag | Med | Hoog | Hoog | Med |
| Verlies van modus / focus | Hoog | Hoog | Med | Med | Med |
| Het toetsenbord werkt niet | Med | Med | Laag | Hoog | Laag |
| Geforceerde terugkeer bij een fout | – | Laag | Med | Med | – |
| CAPTCHA is niet toegankelijk | – | – | Laag | Med | – |
Twee gevallen die extra aandacht verdienen. „Status niet aangegeven × In winkelwagen” is de meest genoemde belemmering in de hele dataset; als je maar één ding aanpakt, pak dan dit aan. „Onbenoemde velden × Betaling” is een schoolvoorbeeld van een nalevingsfout – een creditcardformulier met velden die als leeg worden aangeduid, is een overtreding waarover geen discussie mogelijk is.
Wat kost dit u vandaag, nog voordat er een rechtszaak komt?
Het risico op rechtszaken is één van de kosten die gepaard gaan met een ontoegankelijk afrekenproces. De andere – doorgaans grotere en altijd aanwezige – kostenpost betreft de bestellingen die nooit worden afgerond omdat de koper het formulier niet kon invullen. Met de onderstaande calculator kunt u aan de hand van drie instelbare parameters deze kosten voor uw eigen verkooptrechter berekenen. De standaardinstellingen zijn conservatief en gebaseerd op sectoroverschrijdende referentiewaarden; pas ze aan uw bedrijf aan.
Blootstellingsmodel voor ontoegankelijke kassa’s
Alle invoervelden zijn schuifregelaars. De getallen worden direct bijgewerkt terwijl je ze aanpast. Dit is geen definitieve berekening, maar een ruw schattingsmodel dat bedoeld is als uitgangspunt voor een nauwkeuriger model.
Methodologie. Volgens schattingen van WebAIM en BOIA maakt ongeveer 1–3% van de Amerikaanse internetbezoekers actief gebruik van een schermlezer; als we ook gebruikers die uitsluitend het toetsenbord gebruiken of een motorische beperking hebben meerekenen, loopt dit percentage op. Het blokkeringspercentage van 65% is de bovengrens van de WebAIM Million-meting voor 2024 van hoe vaak een scan van een startpagina ten minste één blokkerende barrière oplevert (95,9%); barrières bij het afrekenen zijn doorgaans beperkter in omvang. Gebruik uw eigen gegevens indien u die heeft. Dit model sluit het risico op rechtszaken, merkverlies en de waarde van klanten die na een mislukt afrekenproces definitief verloren gaan uit – factoren die de getoonde cijfers allemaal nog verder opdrijven.
Hoe een gebruiksvriendelijke kassa er daarentegen uitziet
In het onderstaande vergelijkingsoverzicht worden de in de dataset meest genoemde fouten vergeleken met het technische patroon waarmee ze kunnen worden verholpen. Geen van de patronen aan de rechterkant is speculatief – elk patroon is een gedocumenteerde WCAG 2.2 AA-techniek.
Tegen wie de eisers een rechtszaak hebben aangespannen
- De melding 'Toevoegen aan winkelwagen' verschijnt visueel zonder
role="status"regio; er is geen informatie over ondersteunende technologie - De CVC-invoer bevat alleen tijdelijke tekst – geen programmatische gegevens
<label> - Het venster voor adresbevestiging wordt geopend, maar de focus blijft op de vorige knop ‘Doorgaan’
- De inline-validatie wordt in rode tekst onder het veld weergegeven; de schermlezer leest deze niet voor
- PayPal-/Apple Pay-knoppen weergegeven als
<div>met klikhandler; geen toetsenbordgebeurtenislistener - Als het verzenden mislukt, wordt de pagina opnieuw geladen en wordt het formulier gewist; de gebruiker begint opnieuw bij naam en e-mailadres
Wat een gebruiksvriendelijke kassa doet
- “Item toegevoegd” aangekondigd via
aria-live="polite"regio ofrole="status" - Elke invoer die is ingekapseld in een programmatisch gekoppelde
<label>– de tijdelijke aanduiding is geen label - Het modaalvenster wordt geopend, de focus verschuift naar de koptekst van het dialoogvenster, de focus blijft daar hangen, met ESC wordt de vorige focus hersteld
- Fouten gemeld via
aria-describedbyen het veld ontvangtaria-invalid="true" - Betaalknoppen zijn echt
<button>elementen met een zichtbare focusrand van ≥ 2 px - Fouten worden direct weergegeven; eerder geldige velden blijven ingevuld; de hele pagina wordt niet opnieuw geladen
De dertienstappen-checklist voor sanering
Op basis van de patronen in de citatiedichtheid van de dataset zijn de onderstaande punten gerangschikt in aflopende volgorde van hoe vaak ze voorkomen in stukken die in de afwikkelingsfase worden ingediend. Door deze lijst van boven naar beneden te doorlopen, worden de meeste beschuldigingen behandeld die in een klacht van een seriële eiser naar voren worden gebracht.
Sanering van het risico op rechtszaken, gerangschikt naar frequentie van vermeldingen
- Geef aan of het product aan het winkelmandje is toegevoegd. Voeg een visueel verborgen
role="status"live-gebied; vul dit bij elke succesvolle toevoeging aan met „Artikel toegevoegd – N artikelen in winkelwagen”. - Geef elk invoerveld programmatisch een label. Controleer je checkout met een Axe-Core- of WAVE-scan; los elk
label-missingregel. Plaatshouders zijn nooit labels. - Meld fouten in kortingsbonnen en promoties. Stropdasfout
<span>elementen aan de invoer viaaria-describedby; toevoegenaria-invalid="true"bij een mislukte validatie. - Verplaats de focus naar modale vensters. Wanneer een bevestigingsvenster wordt geopend, plaats de focus dan op de koptekst of het eerste interactieve element. Bij het sluiten moet de focus weer naar de trigger worden teruggezet.
- De focus blijft binnen actieve modale vensters. In een geopend dialoogvenster kun je met Tab en Shift+Tab door het venster bladeren; met Esc sluit je het.
- Maak van betaalknoppen echte knoppen. Vervang alle
<div onclick>integraties voor PayPal, Apple Pay, Google Pay en 'Bestelling plaatsen' met<button>elementen. Voeg zichtbare focusstijlen toe van ≥ 2px. - Markeer verplichte velden semantisch. Toevoegen
aria-required="true"en een zichtbare aanduiding ‘Verplicht’. Groepeer verwante verplichte velden met<fieldset>. - Bewaar de formulierstatus bij een fout bij het valideren. Fouten mogen correct ingevulde velden niet wissen. Keer terug naar de huidige pagina; plaats de focus op het eerste ongeldige invoerveld.
- Geef aan wanneer een taak is voltooid. "Bestelling geplaatst" en "Korting toegepast" moeten via hetzelfde kanaal naar de ondersteunende technologie worden verzonden
role="status"mechanisme zoals 'Toevoegen aan winkelwagen'. - Gebruik een toegankelijke CAPTCHA. Als je er toch een moet gebruiken, zijn een audio-alternatief en de toegankelijkheidsmodus van reCAPTCHA het absolute minimum. Beter nog: vervang deze door onzichtbare of gedragsgebaseerde verificatie.
- Zorg ervoor dat de stapindicatoren duidelijk zijn. Als je afrekenproces uit verschillende stappen bestaat, presenteer deze dan als een
<nav aria-label="Checkout progress">met een<ol>enaria-current="step". - Test met een echte schermlezer. Doorloop het hele afrekenproces van begin tot eind met NVDA + Firefox of VoiceOver + Safari. Geautomatiseerde scans missen ongeveer de helft van de belemmeringen waar je gebruikers tegenaan zullen lopen.
- Los het probleem op het niveau van het ontwerpsysteem op. De meeste fouten bij het afrekenen vinden hun oorsprong in gedeelde componenten (Modal, Input, Toast). Als je de component één keer aanpast, wordt de wijziging doorgevoerd in alle afrekenprocessen die er gebruik van maken; als je de pagina één keer aanpast, is dat niet het geval.
De knelpunten in de afrekenfase van de dataset kunnen worden onderverdeeld in vijf onderdelen: de toast, het modaalvenster, het invoerveld, de foutmelding en de verzendknop. Als deze vijf onderdelen afzonderlijk met een schermlezer worden getest voordat ze in de afrekenfase worden geïmplementeerd, slinkt het totale aantal klachten in het corpus tot een lange staart. De hefboomwerking ligt op het niveau van het ontwerpsysteem. De rechtszaak speelt zich helaas af op paginaniveau – en wordt per aangetekende post bezorgd.
Afsluiting – de technische vraag, nogmaals geformuleerd
De stelling van dit artikel – dat het afrekenproces het meest omstreden onderdeel van het internet is – is niet gebaseerd op het aantal rechtszaken, hoewel dat aantal opvallend hoog is. Ze is gebaseerd op de structuur van het gebruikerstraject. Van alle onderdelen op een commerciële website is het afrekenen het onderdeel waarvan het falen het meest precies overeenkomt met de juridische definitie van een denial-of-service, het onderdeel waarvan de schade het duidelijkst vertaald kan worden in een klacht, en het onderdeel waarvan de bugs het meest consistent zijn bij alle gedaagden. Geen van deze feiten zal veranderen in 2027. Wat wel kan veranderen, is de technische beslissing die hieraan ten grondslag ligt.
De 4.050 problemen die in dit artikel worden opgesomd, zijn bij nader inzien niet zo mysterieus. Het gaat om dezelfde vijf of zes fouten die voortkomen uit dezelfde vijf of zes componenten. De meest efficiënte oplossing die een webwinkel kan toepassen, ligt niet op de afrekenpagina zelf, maar in het ontwerpsysteem waarmee die afrekenpagina wordt gebouwd. Corrigeer de toast, het modaalvenster, het invoerveld, de foutmelding en de verzendknop – één keer, in de componentenbibliotheek – en de dataset achter dit artikel wordt met een factor tien kleiner. De eisers zullen zich op een ander terrein richten. Uw klanten zullen dat niet doen.
Bronnen en methodologie
De metadata van federale civiele zaken is afkomstig uit PACER (Public Access to Court Electronic Records) en omvat 8.788 zaken inzake webtoegankelijkheid die tussen januari 2007 en april 2026 bij Amerikaanse districtsrechtbanken zijn aangespannen, geïdentificeerd aan de hand van ADA Title III-claimcodes en door middel van filtering op de zoekterm „website“. Er wordt een analyse op themaniveau uitgevoerd op basis van een OCR- en NLP-uittreksel van dezelfde dossiers, wat 81.509 afzonderlijke vermeldingen van toegankelijkheidskwesties oplevert, gecategoriseerd in 28 oppervlaktetaxonomieën.
Verwijzingen naar WCAG hebben betrekking op WCAG 2.1 (de meest geciteerde norm in schikkingsovereenkomsten in de Amerikaanse particuliere sector) en WCAG 2.2 (de meest recente aanbeveling, gepubliceerd in oktober 2023 en bekrachtigd in december 2024). Wanneer in ingediende stukken wordt verwezen naar de EAA, EN 301 549 of de DOJ Title II Final Rule (april 2024), worden de criteria genormaliseerd naar hun WCAG 2.1 AA-equivalent.
De namen van de eisers zijn in dit artikel weggelaten. Alle klagers bestaan echt en hun zaken zijn openbaar te raadplegen op PACER. Het overzicht is opgesteld voor analytische doeleinden; de oorspronkelijke dossiervermeldingen zijn voor elke lezer die een specifieke indiening wil controleren, openbaar doorzoekbaar.
De berekeningsmodule in §11 dient ter illustratie. De enquêtes onder schermlezergebruikers van WebAIM (2014–2024) en de jaarlijkse controle van de startpagina’s door WebAIM Million vormen de belangrijkste referentiepunten binnen de sector voor schattingen van het bezoekersaandeel en de frequentie van toegankelijkheidsbarrières. Pas de standaardinstellingen van de berekeningsmodule aan op basis van uw eigen analysegegevens, indien u daarover beschikt.
Bronvermelding: AIOPSGROUP Accessibility Intelligence (2026). E-commerce-afrekenproces: het meest omstreden onderdeel van het internet. Nummer 04:12.