Robusthet i WCAG: nej, det betyder inte utan JavaScript

Robusthet är den av WCAG:s fyra principer som alla tror att de förstår och nästan ingen har läst. Fråga runt i ett utvecklingsteam vad "robust" betyder, så kommer svaret ofta att sidan ska fungera även om besökaren stänger av JavaScript. Det är fel. Kravet finns inte i WCAG, och har inte gjort det på snart tjugo år. Det verkliga kravet är ett annat, det är strängare i praktiken, och det är webbens allra vanligaste fel.

Kravet på JS-fri sida fanns. Det togs bort.

Missförståndet är inte gripet ur luften. Kravet har funnits, och det var till och med högsta prioritet. I WCAG 1.0, från 1999, står checkpoint 6.3 (Priority 1): sidor ska vara användbara när skript är avstängda eller inte stöds.

Men WCAG 1.0 är inte den standard någon mäts mot i dag. När WCAG 2.0 kom 2008 byttes hela modellen ut. Bort från teknikförbud ("skript ska gå att stänga av"), över till teknikneutralt stöd ("skript får användas, om hjälpmedlen klarar dem"). W3C:s egen jämförelsetabell mellan 1.0 och 2.0 mappar checkpoint 6.3 till noll framgångskriterier i den nya standarden. Det som finns kvar är de allmänna konformanskraven, och de kräver inte att sidan fungerar utan skript. Kravet överlevde inte flytten.

Och W3C säger det rakt ut. I tekniken SCR38, den som faktiskt handlar om att bygga sidor som fungerar utan skript, står det svart på vitt att metoden "is not required for conformance with WCAG 2.x". Det är alltså inget krav.

Med det sagt: W3C rekommenderar ändå att bygga så att kärninnehållet finns även när tekniken inte når fram. Det är gott hantverk, och vi återkommer till varför i slutet. Men rekommendation är inte lagkrav, och att blanda ihop dem gör att du lägger tid på fel sak.

Vad robusthet faktiskt kräver

Så här lyder princip 4 i WCAG, ordagrant: innehållet ska vara robust nog att kunna tolkas av många olika användarprogram, inklusive hjälpmedel.

Läs ordet igen: tolkas, inte stängas av. Robusthet är ett krav på att koden ska gå att läsa av för en maskin som inte ser skärmen, i dag och när tekniken uppdateras. Det handlar om skärmläsaren, punktskriftsdisplayen och röststyrningen, inte om besökaren som slagit av JavaScript i webbläsaren.

Under principen ligger två krav som gäller:

• 4.1.2 Namn, roll, värde, nivå A.
• 4.1.3 Statusmeddelanden, nivå AA.

Ett tredje, 4.1.1 Parsing ("koden ska validera"), är borttaget i WCAG 2.2. W3C skriver att problemet det löste inte längre finns, eftersom hjälpmedel inte längre läser HTML-koden direkt. Formellt står kriteriet kvar i WCAG 2.1, men W3C har fört in noten att det alltid ska anses uppfyllt för HTML. I praktiken finns det alltså inget att uppfylla. Ser du en checklista där robusthet fortfarande är "validera koden" är den föråldrad. Ren kod är fortfarande en bra idé, men det är inget WCAG-krav.

Båda kraven som gäller fanns redan i WCAG 2.1. Det är den version som ligger i EN 301 549 V3.2.1, den harmoniserade standard som DOS-lagen mäts mot, och som är den etablerade referensen även för tillgänglighetslagen. Robusthet är alltså inget framtida. Omfattas er webbplats av något av regelverken är 4.1.2 och 4.1.3 krav i dag, inte en framtida ambition.

Namn, roll, värde (4.1.2, nivå A)

Kravet i klarspråk: varje sak besökaren kan klicka på, fylla i eller ändra måste kunna berätta tre saker för hjälpmedlet. Vad den heter (namn), vad den är (roll), och hur den mår just nu (värde, till exempel "ikryssad" eller "expanderad"). Ändras något av det ska hjälpmedlet få veta.

Notera vad kriteriet uttryckligen räknar upp: formulärelement, länkar och "components generated by scripts". Standarden förbjuder alltså inte JavaScript-byggda komponenter. Den kräver att de exponeras rätt. Det är precis motsatsen till hur robusthet brukar tolkas.

Så här ser felen ut i praktiken:

• Div-knappen. Ett <div> med en klickhanterare ser ut som en knapp och fungerar med mus. För skärmläsaren är den en textbit. Den annonseras inte som knapp, den går inte att nå med tabb, och Enter gör ingenting. Lösningen är inte mer ARIA, det är <button>.
• Ikonknappen utan namn. En knapp vars enda innehåll är en ikon. Skärmläsaren läser upp "knapp" och inget mer.
• ARIA som ljuger. aria-expanded som aldrig uppdateras när menyn öppnas, aria-checked="false" på en ruta som faktiskt är ikryssad. Fel roll är sämre än ingen roll, för användaren får ett löfte som gränssnittet inte håller.
• Egenbyggda kryssrutor och reglage som visar sitt tillstånd med enbart färg. Visuellt syns det. Programmatiskt finns det inte.

Bästa sättet att klara 4.1.2 är att låta bli att uppfinna komponenten. Vanlig HTML klarar kravet gratis: en <button> är en knapp, har en roll och får sitt namn av sin text. Det är också W3C:s första ARIA-regel, att inte använda ARIA om det finns ett HTML-element som gör jobbet.

Att det här inte är teori syns i siffrorna. WebAIM Million 2026 granskade en miljon av världens mest besökta startsidor: 51 procent har formulärfält utan etikett, 46,3 procent har tomma länkar och 30,6 procent har tomma knappar. Det vill säga element som inte kan säga vad de heter, ett fel som bland annat kopplas till 4.1.2. Samma rapport visar att sidor med ARIA i snitt har fler fel (59,1) än sidor utan (42). Det bevisar inte att ARIA orsakar felen, komplexa sidor har både mer ARIA och fler fel. Men det stöder poängen: fel ARIA är sämre än ingen ARIA.

Statusmeddelanden (4.1.3, nivå AA)

Det här är kravet nästan ingen svensk text förklarar, och det är också det som märks mest i vardagen.

Kravet i klarspråk: får du som ser skärmen information genom att något dyker upp, ska den som inte ser skärmen få samma information uppläst, utan att fokus rycks bort från det hon höll på med.

Tänk igenom vad som händer på en vanlig sajt:

• Du lägger en vara i varukorgen. Rutan "Varan lades i varukorgen" tonar in, och siffran i varukorgsikonen tickar upp till 5. Ingenting av det hörs.
• Du söker. Ovanför träfflistan står "3 träffar hittades". Den som lyssnar vet inte om sökningen gav noll, tre eller trehundra träffar, och måste börja leta manuellt för att ta reda på det.
• Du skickar ett formulär och får "Ogiltigt postnummer" ovanför fältet. Fältet blir rött. Rött hörs inte heller.
• Appen laddar. Snurran snurrar, i tystnad.

Alla fyra är statusmeddelanden enligt W3C: information om att något lyckats, att det pågår, eller att det blivit fel, utan att sidan laddas om eller fokus flyttas. Om meddelandet inte annonseras är kravet inte uppfyllt.

Tekniskt är lösningen liten. Använd role="status" (eller aria-live="polite") för det som kan vänta, som en bekräftelse eller ett träffantal. Använd role="alert" för det som brådskar, som ett felmeddelande. Använd role="progressbar" eller aria-busy för väntetillstånd.

Men det finns två fällor, och de fäller de flesta:

1. Behållaren måste finnas i sidan innan meddelandet läggs i den. Injicerar du hela rutan med sin text på en gång hinner skärmläsaren ofta inte uppfatta ändringen, och ingenting läses upp. Lägg ut en tom behållare direkt när sidan byggs, och fyll den sedan. Det här är den vanligaste orsaken till att en korrekt uppmärkt live-region "inte fungerar".
2. En dold behållare annonseras inte. Ligger den bakom display: none blir den tyst. I ett test av tolv kombinationer av skärmläsare och webbläsare (Adrian Roselli, 2026) annonserades dolda live-regioner inte i en enda kombination. Uppmärkning är nödvändig, men den ska testas med en riktig skärmläsare, inte antas.

Därför ser de automatiska verktygen inte allt

Vi testade en sak för att se hur långt maskinen räcker. Vi byggde två sidor med exakt samma slutresultat. Den ena levererar allt innehåll direkt i HTML. Den andra levererar en tom sida, och bygger allt med JavaScript efteråt.

Båda får 100 av 100 av vår egen motor, engine (version 2.12.0). Vi körde också ett par andra vanliga automatiska verktyg i deras standardläge. Ingen av dem nämner med ett ord att den ena sidan är tom utan JavaScript.

Sedan matade vi in det en besökare utan fungerande JavaScript faktiskt möter: den helt tomma sidan.

Det är inte en bugg, och det är inte ett WCAG-brott. Det är själva poängen: automatiska verktyg letar efter fel i innehåll, och tomt innehåll har nästan inga fel att hitta. Vår egen motor ger den tomma sidan 80 av 100, men bara för att den råkar sakna rubrik och landmärke. Alltså av fel anledning. Vi upptäcker inte det som faktiskt är problemet, att sidan är tom, och det gör inte de andra verktygen heller.

Och här kommer den praktiska invändningen tillbaka, den som WCAG inte ställer men verkligheten gör. JavaScript uteblir sällan för att någon stängt av det. 99,8 procent av skärmläsaranvändarna har JavaScript påslaget (WebAIM 2024). Skripten kommer ändå inte alltid fram: en brandvägg, en proxy, ett tillägg, ett mobilnät som tappar. När brittiska myndigheten GDS mätte över 500 000 besök (2013) fick ungefär 1 av 93 inte in JavaScript-förbättringen, och bara en femtedel av dem hade valt bort JavaScript själva. För en sida som bygger allt i webbläsaren blir resultatet inte en sämre sida. Det blir en tom sida.

Det är därför vi har byggt in en robusthetskontroll i vår motor, som mäter hur mycket av innehållet som faktiskt finns kvar utan JavaScript. Den sänker inte något konformansbetyg, för det vore att påstå ett lagkrav som inte finns. Den är en varningslampa, inget annat.

Vad du gör i stället

• Använd riktiga HTML-element före egenbyggda. <button>, <a>, <input> med <label>. De klarar 4.1.2 utan att du gör något.
• Ge varje ikonknapp och varje länk ett tillgängligt namn. Tabba igenom sidan och fråga vid varje stopp: vad heter det här, och skulle någon som inte ser skärmen förstå vad det gör?
• Kontrollera att tillstånd verkligen uppdateras, inte bara ser rätt ut. Öppnas menyn, ändras aria-expanded?
• Lägg ut tomma live-regioner när sidan byggs, och fyll dem när något händer. Bekräftelser och träffantal med role="status", fel med role="alert".
• Lyssna på sidan med en skärmläsare (NVDA på Windows, VoiceOver på Mac). Du behöver inte vara van användare. Det räcker att du hör när något blir obegripligt, eller helt tyst.

Vinsten

Robusthet är det billigaste kravet att uppfylla och det dyraste att missa. Billigt, för att det mesta löses genom att använda rätt HTML-element från början. Dyrt, för att när det brister blir gränssnittet inte otympligt, det blir omöjligt. En knapp utan namn går inte att trycka på om du inte ser den.

Läs grunderna i vår kompletta WCAG-guide, där robusthet är en av de fyra principerna. Vill du veta hur din egen sajt klarar namn, roll och värde? Börja med en tillgänglighetsanalys, så mäter vi din webbplats mot WCAG 2.2 nivå AA, med både automatisk skanning och manuell testning med skärmläsare. Behöver ni hjälp att tolka resultatet och prioritera finns vår rådgivning där.

Vill ni veta var ni står? Börja med en tillgänglighetsanalys.

Den här texten är allmän information, inte juridisk rådgivning. Vad som gäller för just er verksamhet beror på sektor, storlek och vilka tjänster ni erbjuder.

Vanliga frågor

Kräver WCAG att webbplatsen fungerar utan JavaScript? Nej. Inget framgångskriterium i WCAG 2.0, 2.1 eller 2.2 kräver det. Kravet fanns i WCAG 1.0 från 1999 (checkpoint 6.3) och togs bort när WCAG 2.0 kom 2008. W3C skriver i tekniken SCR38 att metoden "is not required for conformance with WCAG 2.x". Det är rekommenderad god praxis, inte ett krav.

Vad betyder robust i WCAG? Att innehållet ska kunna tolkas av många olika användarprogram, inklusive hjälpmedel som skärmläsare. I praktiken: varje komponent ska ha rätt namn, roll och värde, och viktiga ändringar ska annonseras.

Vilken nivå ligger 4.1.2 och 4.1.3 på? 4.1.2 Namn, roll, värde är nivå A. 4.1.3 Statusmeddelanden är nivå AA. Båda finns redan i WCAG 2.1, den version som EN 301 549 pekar ut. De är alltså inga nyheter i WCAG 2.2, utan krav som gäller redan i dag för den som omfattas av DOS-lagen eller tillgänglighetslagen.

Gäller 4.1.1 Parsing fortfarande? Nej. Kriteriet är borttaget i WCAG 2.2, och i WCAG 2.1 har W3C fört in noten att det alltid ska anses uppfyllt för HTML. "Koden ska validera" är alltså inte ett WCAG-krav.

Räcker det att lägga till aria-live för att klara statusmeddelanden? Nej. Behållaren måste finnas i sidan innan meddelandet läggs i den, och den får inte vara dold. Testa alltid med en riktig skärmläsare.

Är det tillåtet att bygga gränssnittet med JavaScript? Ja. Kriteriet 4.1.2 nämner uttryckligen komponenter som genereras av skript. Kravet är att de exponeras rätt för hjälpmedel, inte att de undviks.

Källor

WCAG 2.2: princip 4 Robust, standardens egen text, W3C.

WCAG 2.2: framgångskriterium 4.1.2 Namn, roll, värde, nivå A, W3C.

Att förstå 4.1.3 Statusmeddelanden, nivå AA, med definition och exempel, W3C.

WCAG 2.2: framgångskriterium 4.1.1 Parsing, markerat som borttaget, W3C.

WCAG 1.0 från 1999, där checkpoint 6.3 om avstängda skript står, W3C.

Tekniken SCR38, där W3C skriver att metoden inte krävs för konformans med WCAG 2.x, W3C.

WebAIM Million 2026: granskning av en miljon startsidor, källan till siffrorna om tomma länkar, tomma knappar och etikettlösa fält, WebAIM.

Enkät bland skärmläsaranvändare, källan till att 99,8 procent har JavaScript påslaget, WebAIM.

Så många besökare fick inte JavaScript: brittiska Government Digital Service mätte över 500 000 besök 2013, GDS.

Test av live-regioner i tolv kombinationer av skärmläsare och webbläsare, källan till att dolda live-regioner inte annonseras, Adrian Roselli, 2026.