Samme juridiske krav, to helt forskellige arkitekturer: hvor WordPress- og Wix-sider fejler WCAG 2.1 AA, og hvilken remediation-workflow der passer til hver.
Opdateret august 2026 · 7 minutters læsning
WordPress driver cirka fire gange flere websites end Wix, og begge publikummer er nu underlagt European Accessibility Act, når de tilbyder tjenester til EU-forbrugere. Juridisk er de identiske: EN 301 549 / WCAG 2.1 AA-conformance, håndhævet nationalt siden midten af 2025. Arkitektonisk kunne de ikke være mere forskellige. WordPress er open source-software du hoster selv, temaet og udvidet fra et enormt plugin-økosystem. Wix er en hosted website builder hvor visuel redigering skriver markeringen for dig. De to modeller giver markant forskellige tilgængeligheds-fejlmønstre — og markant forskellige rette-workflows.
EAA-omfattede tjenester på begge platforme skal møde WCAG 2.1 niveau AA. Håndhævelsesmyndigheder er ligeglade med hvilket CMS renderer dine sider.
WordPress giver fuld kontrol over hver byte HTML — inklusive magten til at ødelægge den. Wix begrænser hvad du kan ændre, til gavn og besvær.
WordPress-plugins og Wix-apps injicerer begge widgets af ukendt kvalitet. Formularer, sliders og popups er de værste syndere på begge.
Manglende alt-tekst (media-uploaderen tillader tomt alt), overskrifter indsat som fed tekst og linktekster som "klik her" skrevet direkte i block-editoren.
Form-builders, page-builder-blokke og slider-plugins med placeholder-only felter, div-baserede "knapper" og keyboard-fælder.
Custom themes og page-builder-layouts der springer landmarks over, fjerner fokus-outlines eller gentager identiske "læs mere"-links i arkiv-loops.
Plugin- og temaopdateringer genintroducerer lydløst rettede fejl — tilgængelighed behøver en fast plads i opdateringsrutinen.
Truk-positionerede tekstbokse giver overskriftsniveauer valgt efter udseende, ikke struktur — flere manglende eller forkert ordnede overskrifter pr. side.
Wix foreslår alt-tekst men kræver den ikke; gallerier importeret fra fotos skibes rutinemæssigt tomme.
Den separate mobileditor lader rettelser fra desktop overse mobil-viewet helt — en klassisk kilde til "rettet men fejler stadig".
Formular-, chat- og booking-apps injicerer iframes og custom kontroller med inkonsistent tastaturstøtte.
Forskellen er igen kontrol:
WordPress: næsten alt kan rettes — redaktøruddannelse dækker indholdsproblemer, tema-/child-theme-arbejde dækker strukturelle, og ødelagte plugins kan udskiftes fra tusindvis af alternativer. Prisen er at intet gennemtvinger sig selv: hvert nyt plugin, temaopdatering og ny redaktør kan rulle fremskridtet tilbage, så scanning hører hjemme i vedligeholdelsesrutinen.
Wix: mange retter er konfiguration frem for kode — alt-tekst-felter, semantisk overskriftstildeling i SEO-/tilgængelighedsindstillingerne, kontrastjustering i site styles og aktivering af ren tekst-rendering på mobil. Strukturelle grænser (hvordan en given app renderer sin widget) kan slet ikke rettes; du vælger en anden app eller dokumenterer begrænsningen.
Nettoeffekt: WordPress belønner investering med fuld retbarhed men kræver løbende årvågenhed; Wix når "rimeligt compliant" hurtigere for simple sider men rammer et loft sat af builderen og appsene.
Eksisterer siden allerede på en af platformene, bliv dér — migrationsomkostningerne overstiger udbedringen, og EAA-pligterne er identiske. Vælger du til et nyt EU-projekt:
Vælg WordPress når du har (eller kan hyre) en der er tryg ved at vedligeholde themes og plugins — hver tilgængelighedsdefekt er i sidste ende retbar. Vælg Wix til simple brochure-agtige sider vedligeholdt af ikke-tekniske ejere, og acceptér at enkelte tredjeparts-widgets kan være uretbare og skal dokumenteres.
Uanset hvad er workflowet det samme: automatisk scanning på tværs af nøgle-templates, ret mekaniske fejl (kontrast, alt-tekst, labels, overskriftsorden), auditér hver extension enkeltvis, publicér en tilgængelighedserklæring, og genscan ved hver meningsfuld ændring.
Fuldt conformante sider findes på begge platforme. Proceskvalitet slår platformvalg.
En automatisk scanning skiller rette-i-dag-problemer fra arkitektoniske på minutter — på ethvert CMS.
EAA-omfattede virksomheder bør publicere en tilgængelighedserklæring med conformance-status og dokumenterede begrænsninger.
Nej. Loven regulerer tjenesten der tilbydes forbrugeren, ikke publiceringsplatformen. En WordPress-side og en Wix-side der tilbyder samme tjeneste står overfor de samme WCAG 2.1 AA-krav.
Ingen af dem er conformant som default når rigtigt indhold, temas og extensions kommer i bildet. WordPress-kernens defaults er solide, men plugin-økosystemet er jokeren; Wix begrænser dårlig markup men dens visuelle redigering skaber strukturelle overskriftsproblemer.
Meget af det, ja: alt-tekst-felter, overskriftstildeling, farvekontrast i site styles og linkbeskrivelser er ejerniveau-indstillinger. Problemer inde i tredjeparts-apps kræver som regel app-udskiftning eller dokumenterede begrænsninger.
Uadministrerede plugins. Hvert ekstra formular-, slider- eller page-builder-plugin øger defektfladen, og opdateringer kan lydløst genintroducere rettede fejl. Hold plugin-antallet lavt og scan efter hver opdateringsrunde.
Et typisk 20-50 siders site: dage til mekaniske retter på begge. WordPress-sider tunge på page-builders og plugins kan tage uger; Wix-sider bliver normalt hurtigere færdige men kan bære dokumenterede begrænsninger for specifikke apps.
Relateret: Wix og tilgængelighed · Drupal og tilgængelighed · WCAG 2.2-ændringer