Skip to content
Holm Digital
Alla inlägg

Varför @holmdigital/engine föreslår specifika mönster för WCAG 2.2

Karin Holm

Bild

Om du har jobbat med tillgänglighet i en produkt som deployar ofta känner du igen det här:

  • Ett formulärfält saknar label.
  • En knapp har otydligt tillgängligt namn.
  • Fokusbeteendet i en modal bryter tangentbordsflödet.

Någon fixar den aktuella raden. Pull requesten mergas. Alla går vidare.

Två sprintar senare är samma typ av fel tillbaka — i en annan vy.

Det är exakt här styrkan i @holmdigital/engine blir tydlig: motorn stannar inte vid att hitta felet, utan föreslår vilket komponentmönster som bör användas för att lösa problemet strukturellt och permanent.

Kort sagt: från “rätta detta element” till “inför detta mönster i hela systemet”.

Varför klassiska felrapporter inte räcker

Många verktyg säger i praktiken:

“Input saknar label (WCAG 2.2: Name, Role, Value).”

Det är en korrekt diagnos — men inte en hållbar leveransstrategi.

När team arbetar snabbt med många utvecklare räcker det inte att peka på enstaka fel. Du behöver också göra det svårt att göra fel nästa gång.

Därför blir mönsterförslag centrala:

  1. Felet identifieras i sin kontext.
  2. Felet kopplas till ett rekommenderat tillgänglighetsmönster.
  3. Teamet får en tydlig riktning mot en återanvändbar komponent (exempelvis A11yInput).

Exempel: saknad label i formulärfält

1) Symptombaserad fix (snabb men kortlivad)

<input type="email" placeholder="E-post" />

Vanlig fix:

<label for="email">E-post</label>
<input id="email" type="email" placeholder="name@company.com" />

Detta löser den aktuella sidan. Men samma miss kan fortfarande göras i nästa formulär.

2) Mönsterbaserad fix (strukturell och skalbar)

I stället kan rekommendationen vara att ersätta fria inputs med en komponent som alltid bär rätt semantik:

<A11yInput
  id="email"
  label="E-post"
  type="email"
  required
  error={errors.email}
  hint="Vi delar aldrig din e-post med tredje part."
/>

Nu flyttas ansvaret från varje enskild vy till ett etablerat mönster i design systemet.

Det gör att ni centraliserar:

  • kopplingen mellan label och input,
  • hint- och hjälptext,
  • felstatus och semantiska felmeddelanden,
  • konsekvent beteende för tangentbord och skärmläsare.

Effekten blir att nya formulär ärver korrekt beteende som standard.

Konfiguration i praktiken: CLI, .a11yrc och CI/CD

För att få ut maximal effekt av @holmdigital/engine behöver rekommendationerna också vara enkla att köra konsekvent i olika miljöer.

Scannern kan konfigureras på två sätt:

  • via en .a11yrc-fil (JSON), eller
  • via CLI-argument i terminalen/CI.

Grundkommando:

npx hd-a11y-scan <url> [options]

Viktiga CLI-val

  • --lang <code>: språk (en, sv, no, da, fi, de, fr, es, nl), standard en.
  • --threshold <level>: allvarlighetsgräns (critical, high, medium, low), standard high.
  • --ci: kör i CI-läge och kan faila bygget vid överträdelse.
  • --json / --format <type>: maskinläsbart outputformat (text, json, junit).
  • --junit <path>: generera JUnit XML för dashboards i CI.
  • --pdf <path>: generera PDF-rapport till angiven sökväg.
  • --viewport <size>: mobile, desktop, tablet eller eget WxH.
  • --generate-tests: (experimentellt) skapa reproduktionsskript.
  • --country <code>: landsspecifik juridisk mappning (se, de, nl, fr, es).
  • --api-key <key> och --cloud-url <url>: uppladdning till HolmDigital Cloud Dashboard.

Exempel för CI

npx hd-a11y-scan https://example.se \
  --lang sv \
  --threshold high \
  --ci \
  --format junit \
  --junit reports/a11y-junit.xml

Detta gör att tillgänglighet blir en del av release-gaten, inte en aktivitet som sker “senare”.

Statement-generator och metadata-mappning

CLI kan också generera ett statiskt tillgänglighetsutlåtande med:

  • --statement <path>
  • --org <name>
  • --email <email>
  • --phone <number>
  • --response-time <val>
  • --publish-date <date>

Mappningen mellan .a11yrc och komponentens props är:

| .a11yrc-nyckel | Prop-namn | Beskrivning | |---|---|---| | org | organizationName | Juridiskt namn på organisationen | | email | contactEmail | Publik kontaktadress | | responseTime | responseTime | Exempelvis “2 working days” | | phone | contactPhone | Publikt telefonnummer | | publish-date | publishDate | Publiceringsdatum (YYYY-MM-DD) |

Den här kopplingen är viktig: den gör att governance-krav och teknisk implementation hänger ihop i samma pipeline.

Varför detta är extra viktigt i WCAG 2.2

WCAG 2.2 ökar kraven på robust och förutsägbar interaktion. I praktiken betyder det att manuella punktfixar blir dyra över tid.

Ett mönsterdrivet arbetssätt gör det lättare att:

  • skala efterlevnad över många team och flöden,
  • minska regressioner vid refaktorering och feature-arbete,
  • korta PR-cykler genom tydligare standardkomponenter,
  • förbättra CI-kvalitet när detektion kombineras med prevention.

Från policy till vardagskod

Många organisationer har redan policy, revision och checklistor.

Det som ofta saknas är bryggan mellan dokument och implementation i vardaglig kod.

Den bryggan skapas när ni kombinerar:

  • en motor som hittar och prioriterar avvikelser,
  • rekommenderade mönster för hur avvikelserna ska lösas,
  • ett komponentbibliotek som gör rätt lösning återanvändbar.

Då lämnar ni “vi ska bli bättre på tillgänglighet” och går mot “vår kodbas producerar tillgängliga gränssnitt by default”.

Slutsats

Det viktigaste med @holmdigital/engine är alltså inte enbart att fel upptäcks.

Det viktigaste är att motorn kan styra teamet mot specifika, återanvändbara mönster som tar bort felklassen vid roten.

När en saknad label leder till införandet av en robust A11yInput-komponent får ni inte bara en fix i en vy — ni får en hållbar leveransmodell för WCAG 2.2.

Källa och utgångspunkt: holmdigital/a11y-hd