Tilgængelighed bliver ofte behandlet som noget, der kun vedrører offentlige hjemmesider. I praksis møder B2B-virksomheder de samme brugere, de samme hjælpemidler og de samme forventninger til, at en hjemmeside fungerer for alle. Når en potentiel kunde ikke kan gennemføre en kontaktformular med tastatur, når en PDF ikke kan læses af en skærmlæser, eller når kontrasten er for lav på mobil, kan det koste både kundehenvendelser og troværdighed.
Samtidig er WCAG ikke kun “ekstra krav”. Det er en ret konkret opskrift på en mere robust, mere brugervenlig og ofte mere konverterende hjemmeside, fordi de ting, der hjælper brugere med handicap, typisk hjælper alle andre med travlhed, små skærme, dårligt lys eller stress.
WCAG kort fortalt: 4 principper, der styrer det hele
WCAG er retningslinjer for webtilgængelighed. De kan virke omfattende, men de hænger sammen om fire principper: Opfatteligt, Anvendeligt, Forståeligt og Robust. Brug dem som en checkliste for, om indholdet kan opfattes, betjenes, forstås og fungere på tværs af browsere og hjælpemidler.
Niveauet mange sigter efter er WCAG 2.1 AA. Det er også det niveau, der ofte nævnes i udbud, kravspecifikationer og interne compliance-lister, og som bliver mere relevant i takt med, at flere virksomheder bliver omfattet af tilgængelighedskrav til digitale tjenester.
Det gode er, at langt det meste kan bygges ind i design og struktur, så det ikke føles som “ekstra arbejde” til sidst.
Hvad betyder WCAG i en typisk B2B-kontekst?
B2B-hjemmesider handler sjældent kun om at vise et flot brand. De skal forklare komplekse ydelser, skabe tillid og gøre det let at tage næste skridt: kontakte, booke, hente materiale, tilmelde sig, logge ind eller sende en forespørgsel.
Her er nogle af de områder, der oftest giver problemer i praksis, også på ellers professionelle hjemmesider.
- Forside og landingssider
- Navigation og megamenuer
- Kontakt- og demoformularer
- PDF’er, datasheets og whitepapers
- Videoer og embeds (YouTube, Vimeo, tredjepartswidgets)
- Loginområder og portaler
Hvis man vil “i mål uden bøvl”, er nøglen at vælge de rigtige kampe fra start: De komponenter og flows, der driver forretningen, og som samtidig er mest risikable i en tilgængelighedstest.
Designvalg, der gør tilgængelighed lettere (og billigere)
Mange WCAG-udfordringer starter i designfasen. Et design kan se moderne og professionelt ud , men stadig være svært at bruge, hvis kontrast, klikflader, typografi og fokusmarkeringer ikke er tænkt med.
Kontrast er et klassisk eksempel. Man kan godt have et brand med lyse farver, men så skal de bruges rigtigt: Til baggrunde, flader og illustrationer, mens brødtekst, labels og vigtige knapper skal have tilstrækkelig kontrast. Det samme gælder skriftstørrelser og linjeafstand. En “let” typografi kan blive tung at læse, hvis teksten er lille, tæt og placeret på levende baggrunde.
En anden typisk faldgrube er, at design kun vurderes i mouse-mode”“. Når man tester med tastatur, ser man hurtigt, om navigationen er logisk, om fokus er synligt, og om man kan gennemføre en handling uden at blive fanget i et element.
Nedenfor er et praktisk overblik over fejl, der går igen, og hvad der plejer at løse dem hurtigt.
| Område | Typisk fejl | Praktisk løsning |
|---|---|---|
| Kontrast | Tekst på farvede knapper kan ikke læses | Brug kontrasttest, justér farve eller fontvægt |
| Typografi | Lille tekst, tæt linjeafstand | Hæv basisstørrelse, mere luft, roligere layout |
| Links | “Klik her” og utydelige linkmarkeringer | Skriv meningsfulde links, tydelig hover/fokus |
| Formularer | Placeholder bruges som label | Brug rigtige labels, tydelige fejlbeskeder |
| Fokus | Fokus er skjult eller meget svag | Indfør klar fokus-stil på alle interaktive elementer |
| Struktur | Overskrifter springer niveauer | Fast overskriftshierarki og skabeloner der guider redaktører |
Det er sjældent dyrt at løse de her ting, hvis de bliver fanget tidligt. Det bliver dyrt, hvis hele designet først skal “repareres” efter lancering.
Teknikken bag: Semantik, tastatur og robuste komponenter
Tilgængelighed er ikke kun et designspørgsmål. Det handler også om, hvordan hjemmesiden er bygget op i HTML, og hvordan komponenter opfører sig for tastatur, skærmlæsere og andre hjælpemidler.
Semantisk HTML er fundamentet: Overskrifter skal være overskrifter, lister skal være lister, tabeller skal bruges til data og ikke layout. Når strukturen er korrekt, kan skærmlæsere skabe en meningsfuld “kortlægning” af siden, og det bliver lettere for brugeren at springe rundt.
Tastaturnavigation er den anden store søjle. Brugeren skal kunne “tabbe” gennem siden i en logisk rækkefølge, se hvor fokus er, og aktivere knapper, links, menuer og formularfelter uden mus. Her hjælper det ofte at standardisere komponenter og genbruge dem, i stedet for at bygge specialløsninger på hver side.
I WordPress og Elementor kan man komme langt med gode skabeloner, rigtige widget-valg og konsekvent indholdsdisciplin. Der er dog stadig steder, hvor man skal være ekstra opmærksom: Popups, sliders, faneblade, accordions og tredjepartsformularer kan skabe problemer, hvis de ikke er sat rigtigt op.
En enkel huskeliste kan spare mange iterationer senere:
- Overskriftsstruktur: Én H1 pr. side, og derefter H2/H3 i logisk rækkefølge
- Alt-tekster: Beskriv funktion og indhold, ikke “billede1”, og undlad alt på rene dekorationer
- Formularer: Brug til alle felter, og giv fejlbeskeder der forklarer hvad der skal rettes
- Fokus og tastatur: Synligt fokus på links, knapper, menuer og modaler, og ingen “tastaturfælder”
- Skip-link: En “Spring til indhold” gør lange sider markant nemmere at bruge
Når man rammer de punkter, bliver resten ofte et spørgsmål om finpudsning og test.
Test uden at drukne i værktøjer
Automatiske tests er gode til at fange mange fejltyper hurtigt. De finder manglende alt-attributter, lav kontrast i visse tilfælde, fejl i ARIA (Accessible Rich Internet Applications) og strukturelle problemer. De finder ikke alt. Derfor giver det bedst mening at kombinere automatiske checks med korte, faste manuelle tests.
I praksis er en fornuftig model:
- Kør automatiske værktøjer undervejs (Lighthouse, axe, WAVE eller tilsvarende).
- Lav en manuel “kritisk sti”-test: navigation, kontaktflow, download, booking.
- Test med tastatur fra top til bund på de vigtigste sider.
- Tag en hurtig skærmlæser-gennemgang (NVDA på Windows eller VoiceOver på Mac).
Det kræver ikke, at hele organisationen bliver eksperter i hjælpemidler. Det kræver, at nogen i projektet eller organisationen har en fast rutine og tør tage de fund seriøst, også når de kommer sent i processen.
Mange B2B-hjemmesider har også integrationspunkter, der bør indgå i test: Cookie-banner, chat, CRM-formularer, kalenderbooking og embedded indhold. Her kan det være nødvendigt at justere valg af leverandør eller konfiguration, hvis komponenten ikke kan betjenes ordentligt.
Indholdet er ofte den største syndebuk
En teknisk pæn hjemmeside kan stadig være utilgængelig, hvis indholdet ikke er skrevet og struktureret rigtigt. Det er især relevant i B2B, hvor indhold ofte er langt, fagligt og skrevet af flere personer over tid.
Klart sprog handler ikke om at gøre alt “simpelt”. Det handler om at gøre det entydigt: Hvad er næste trin, hvad betyder et begreb, og hvad forventer man af brugeren. Konsistente menupunkter, ensartede CTA-tekster og forudsigelige sideopbygninger reducerer både frafald og supportspørgsmål.
En enkelt sætning kan være forskellen på en kundehenvendelse og et tabt besøg.
Når der arbejdes med downloads, bør man også se på dokumenterne. En PDF kan være “pæn” og stadig umulig at bruge med skærmlæser, hvis den er eksporteret som et billede, mangler tags, eller har ulogisk læserækkefølge. Hvis PDF’er er centrale i salgsprocessen, bør de være en del af WCAG-arbejdet, ikke en eftertanke.
Sådan kan tilgængelighed passe ind i et trygt projektforløb
Tilgængelighed fungerer bedst, når den bliver en del af kravsspecifikationen og måden, man godkender leverancer på. Ikke som en separat audit helt til sidst.
En struktureret proces kan gøre det forudsigeligt:
- Start med afklaring: Hvilke sider og flows er vigtigst for forretningen, og hvilke krav møder I fra kunder, udbud eller interne politikker?
- Byg skabeloner og komponenter: Når header, footer, knapper, formularer og typografi er sat rigtigt, bliver resten meget lettere
- Test løbende: Små tjek undervejs er hurtigere end store rettelser til sidst
Det er også her, at EistrupWeb arbejder med WordPress og Elementor til B2B-virksomheder og lægger typisk vægt på en tydelig proces fra afklaring og struktur til design, udvikling, test og lancering, efterfulgt af oplæring og driftssikker support. Den type setup er velegnet til WCAG, fordi de mest kritiske valg bliver taget tidligt, og fordi der er en naturlig ramme for korrektur og gennemgang, før noget bliver offentliggjort.
Vedligehold: Tilgængelighed er en løbende disciplin
Selv en WCAG-venlig hjemmeside kan “komme ud af kurs”, hvis der løbende bliver lagt nye sider op med forkerte overskrifter, manglende alt-tekster eller nye plugins, der ændrer adfærd på knapper og formularer. Opdateringer kan også introducere nye fejl, især i temaer og sidebyggere.
Det behøver ikke blive tungt. En praktisk tilgang er at planlægge faste “check-ins”: Når der kommer nye landingssider, når der skiftes formularplugin, eller når der laves større indholdsoprydning. For mange virksomheder giver det ro at have en serviceaftale eller et vedligeholdelsessetup, hvor opdateringer, backup og løbende tjek sker systematisk, så kvaliteten ikke afhænger af, om nogen lige husker det.
Hvis du vil gøre det konkret uden at starte et kæmpe projekt, kan en god første opgave være at vælge fem nøglesider og gennemføre en kort test: Kontrast, tastatur, formularlabels, overskrifter og alt-tekster. Det giver hurtigt et realistisk billede af, hvor indsatsen batter mest i jeres setup.
