WCAG 1.4.4: Ändra textstorlek

Vad den här regeln innebär

WCAG 1.4.4 Resize Text (Nivå AA) anger att text måste kunna förstoras upp till 200 procent utan användning av hjälpmedelsteknik och utan förlust av innehåll eller funktionalitet. Enkelt uttryckt: när en användare zoomar sin webbläsare till 200% eller förstorar basteckenstorleken via webbläsar- eller operativsysteminställningar, måste all text på sidan förbli läsbar och all funktionalitet måste förbli intakt.

Kriteriet gäller brett för all text som återges på en webbsida, inklusive brödtext, rubriker, etiketter, knapptext, platshållartext i formulärfält, navigationslänkar, tabellinnehåll och bildtexter. Det gäller inte text som är en del av en logotyp eller ett varumärkesnamn, och inte heller dekorativ text som inte förmedlar någon information och enbart presenteras som bildinnehåll (till exempel ett inskannat foto av en handskriven lapp där själva texten inte är det tillgängliga innehållet).

För att klara kravet måste följande villkor vara uppfyllda vid 200% zoom — antingen genom webbläsarens inbyggda sidzoom (Ctrl/Cmd + plustangenten eller menyn Visa > Zooma) eller genom webbläsarens inställning för minsta teckenstorlek: ingen text får klippas av eller döljas av sin behållare, ingen text får överlappa annan text eller interaktiva element, ingen horisontell rullningslist får visas vid full visningsbredd (förutom för innehåll som faktiskt kräver tvådimensionell rullning, såsom kartor eller datatabeller), och alla interaktiva kontroller måste förbli användbara.

Ett fel registreras när fasta pixelvärden låser text i en storlek som inte kan växa, när behållare använder fasta höjder som klipper text som flödar över, när viewport-meta-taggar använder user-scalable=no eller maximum-scale=1.0 för att blockera nyp-zoom på mobiler, eller när JavaScript fångar upp zoomgester för att förhindra skalning. Kriteriet är uttryckligen teknikagnostiskt: oavsett om implementationen använder CSS, SVG-text eller canvas-renderad text är det resultatet för användaren som är avgörande. Observera att SVG-text och canvas-renderad text i sig är svåra att förstora och ofta kräver extra teknisk uppmärksamhet.

Varför det är viktigt

Enligt Världshälsoorganisationen har cirka 2,2 miljarder människor världen över någon form av synnedsättning. Bland dessa har en mycket stor andel nedsatt syn — ett tillstånd där synen inte kan korrigeras fullt ut med glasögon eller kontaktlinser men där personen inte är helt blind. Användare med nedsatt syn ställer rutinmässigt in sin webbläsarzoom på 150%, 200% eller högre, eller konfigurerar sitt operativsystem att återge text med större basstorlek. När webbplatser blockerar eller förstör detta beteende utestängs dessa användare helt från innehållet.

Utöver diagnostiserad nedsatt syn påverkar situationsfaktorer i princip alla internetanvändare vid något tillfälle: små skärmar, starkt solljus, trötthet, åldersrelaterad synförändring eller läsning på ett främmande språk kan alla göra mindre text svårare att tyda. Äldre vuxna i synnerhet — en snabbt växande demografisk grupp globalt och i Turkiet — förlitar sig ofta på zoom som en förstahandsanpassning för tillgänglighet innan de söker specialiserad hjälpmedelsteknik.

Överväg ett konkret scenario: en patient i sextioårsåldern försöker läsa sin digitala tidsbokningsbekräftelse från en sjukhusportal på sin smartphone. Sjukhusets mobila stylesheet sätter brödtextens teckenstorlek till 12px med ett fast pixelvärde och viewport-meta-taggen innehåller maximum-scale=1.0. Patienten försöker nyp-zooma men gränssnittet låser sig. Hen kan inte läsa datumet eller avdelningsnamnet tillräckligt tydligt för att känna sig säker. Hen ringer sjukhusets helpdesk, vilket tar personalens tid i anspråk och skapar oro för patienten — ett helt och hållet förebyggbart resultat om kriteriet hade uppfyllts.

Ur ett rent kommersiellt perspektiv hänger tillgänglig textstorlek samman med bredare användbarhetsförbättringar som gynnar alla användare. Sökmotorer belönar också webbplatser som återger läsbar text i normal och förstorat storlek, eftersom Googlebot bedömer läsbarhetssignaler som en del av Core Web Vitals och rankingfaktorer för sidupplevelse. Att åtgärda problem med textförstoring förbättrar därför samtidigt SEO, minskar supportbördan och utökar den potentiella målgruppen.

Relaterade Axe-core-regler

WCAG 1.4.4 är i första hand ett kriterium för manuell testning. Automatiserade verktyg kan flagga en begränsad uppsättning förhållanden som är kända för att förhindra textförstoring, men de kan inte pålitligt simulera och utvärdera alla layoutresultat vid 200% zoom. Följande förhållanden är vad automatiserade verktyg försöker upptäcka, och vad som kräver manuell uppföljning:

• viewport-meta-tagg som blockerar zoom (manuell kontroll krävs): Axe-core inkluderar regeln meta-viewport, som flaggar alla <meta name='viewport'>-taggar som sätter user-scalable=no eller maximum-scale till ett värde på 1,0 eller lägre. Detta är det enda scenariot där en helt automatiserad upptäckt är möjlig, eftersom överträdelsen är deklarativ och inte beror på layoutresultat. Men inte ens denna regel kan avgöra om en webbplats använder JavaScript för att programmatiskt förhindra zoom, så manuell verifiering behövs alltid.
• Fasta teckenstorlekar i pixlar (manuell kontroll krävs): Automatiserade verktyg kan rapportera när CSS-värden för font-size anges i absoluta pixelenheter (px) i stället för relativa enheter (em, rem, % eller viewport-relaterade enheter). Moderna webbläsare åsidosätter dock absoluta pixelstorlekar när användaren ändrar webbläsarens standardteckenstorlek, så ett pixelvärde i sig utgör inte ett garanterat fel — det beror på webbläsarens beteende och om webbplatsen respekterar font-size-arv. Manuell inspektion av beräknade stilar och visuell verifiering krävs för att bekräfta ett faktiskt fel.
• Innehåll som flödar över och klipps vid 200% zoom (endast manuellt): Inget automatiserat verktyg kan pålitligt återge en sida vid 200% och utvärdera om all text förblir synlig och alla interaktiva element förblir användbara. Detta kräver att en mänsklig testare ställer in webbläsarens zoomnivå, rullar genom sidan och verifierar varje innehållsområde. Automatiserade verktyg har ingen åtkomst till det renderade tillståndet efter zoom.
• Text i bilder och canvas (endast manuellt): Text som är inbakad i rasterbilder (<img>-taggar som innehåller skärmdumpar av text) eller renderas på ett <canvas>-element kan inte förstoras av webbläsaren alls. Automatiserade verktyg kan flagga förekomsten av canvas-element för manuell granskning, men de kan inte avgöra om dessa canvas-element innehåller meningsfull text som användaren behöver läsa.

Hur man testar

1. Kör först en automatiserad skanning. Öppna sidan i Chrome eller Firefox och kör axe DevTools (webbläsartillägg) eller Lighthouse (Chrome DevTools, fliken Lighthouse). Titta specifikt efter regelöverträdelsen meta-viewport. Om den flaggas, notera den som ett kritiskt fel. Kontrollera också CSS-granskningen för eventuella font-size-deklarationer i px-enheter som visas i axe-varningarna för best practice.
2. Kontrollera viewport-meta-taggen i källkoden. Öppna DevTools (F12), gå till fliken Elements och sök efter meta name='viewport'. Läs content-attributet noggrant. Om det innehåller user-scalable=no, user-scalable=0 eller maximum-scale=1 (eller något värde under 2) är detta ett direkt fel mot 1.4.4.
3. Ställ in webbläsarzoom på 200%. I Chrome eller Firefox, tryck Ctrl + Plus (Windows/Linux) eller Cmd + Plus (macOS) upprepade gånger tills webbläsarens zoomindikator visar 200%. Alternativt, gå till Visa > Zooma in. På macOS Safari, använd Visa > Zooma in. Använd inte operativsystemets skärmskalning för detta test — använd specifikt webbläsarzoom.
4. Rulla igenom varje sidsektion vid 200% zoom. Rulla systematiskt från topp till botten. Leta efter: text som kapas eller döljs av sin behållare, text som flödar ut ur sin ruta och överlappar intilliggande innehåll, formetiketter som försvinner bakom sina inmatningsfält, knappar vars text kapas, rullgardinsmenyer som sträcker sig utanför skärmen och inte kan rullas in i vy, och modala dialoger som överskrider viewporten och inte kan rullas.
5. Testa all interaktiv funktionalitet vid 200% zoom. Aktivera varje navigationsmeny, öppna varje modal, skicka formulär, trigga verktygstips och popovers och interagera med eventuella karuseller eller dragspel. Verifiera att alla dessa förblir fullt användbara — inte bara visuellt närvarande.
6. Testa med NVDA + Firefox (Windows). Aktivera NVDA och öppna Firefox vid 200% zoom. Navigera med Tab-tangenten och piltangenterna. Bekräfta att fokuserbara element får fokus, att fokusindikatorer är synliga (överlappning med WCAG 2.4.7, men bra att kontrollera) och att läsordningen matchar den visuella ordningen vid den förstora storleken.
7. Testa med VoiceOver + Safari (macOS/iOS). Aktivera VoiceOver. På iOS, gå till Inställningar > Hjälpmedel > Skärm och textstorlek och aktivera Större text. Navigera på samma sida och verifiera innehållets integritet. Använd också nyp-zoomgesten för att bekräfta att den inte blockeras.
8. Testa webbläsarens inställning för minsta teckenstorlek. I Firefox, gå till Inställningar > Allmänt > Typsnitt och färger och ställ in minsta teckenstorlek till 24px. Ladda om sidan och verifiera att all text uppfyller detta minimum och att layouten inte går sönder. Detta testar en annan vektor av samma kriterium.
9. Testa med JAWS + Chrome (Windows). Öppna sidan i Chrome vid 200% zoom med JAWS aktivt. Använd JAWS läskommandon (Insert + Nedåtpil för att läsa från markören) för att bekräfta att allt textinnehåll läses upp och att inget innehåll hoppas över på grund av att det döljs av overflow-klippning.

Hur man åtgärdar

Viewport-meta-tagg som blockerar zoom — Felaktigt

<!-- WRONG: user-scalable=no prevents pinch-to-zoom on mobile,
     directly violating WCAG 1.4.4 -->
<meta name='viewport' content='width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no'>

Viewport-meta-tagg som blockerar zoom — Korrekt

<!-- CORRECT: Remove user-scalable=no and do not cap maximum-scale below 2.
     Allowing zoom to at least 2 (200%) satisfies WCAG 1.4.4. -->
<meta name='viewport' content='width=device-width, initial-scale=1.0'>

Fasta teckenstorlekar i pixlar — Felaktigt

<!-- WRONG: font-size in px ignores the user's browser font-size preference.
     If the user sets a larger default, px values override that preference. -->
<style>
  body {
    font-size: 14px;
  }
  h1 {
    font-size: 24px;
  }
  .caption {
    font-size: 11px;
  }
</style>
<p>Your appointment is confirmed.</p>

Fasta teckenstorlekar i pixlar — Korrekt

<!-- CORRECT: Use rem units relative to the root font size (typically 16px browser default).
     1rem = 16px by default, but scales with user preference.
     Setting font-size on :root in % rather than px also respects user settings. -->
<style>
  :root {
    font-size: 100%; /* inherits browser default, typically 16px */
  }
  body {
    font-size: 0.875rem; /* ~14px at default, but scales with user preference */
  }
  h1 {
    font-size: 1.5rem; /* ~24px at default */
  }
  .caption {
    font-size: 0.75rem; /* ~12px at default — still scalable */
  }
</style>
<p>Your appointment is confirmed.</p>

Behållare med fast höjd som klipper text — Felaktigt

<!-- WRONG: A fixed height with overflow:hidden will clip enlarged text.
     At 200% zoom, the text grows but the box does not, hiding content. -->
<style>
  .card {
    height: 120px;
    overflow: hidden;
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

Behållare med fast höjd som klipper text — Korrekt

<!-- CORRECT: Use min-height instead of height so the container grows
     with the content when text is enlarged. -->
<style>
  .card {
    min-height: 7.5rem; /* sets a minimum but allows growth */
    overflow: visible; /* or remove overflow:hidden entirely */
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

Text inbakad i bilder — Felaktigt

<!-- WRONG: A banner image containing text cannot be resized by the browser.
     Even with alt text, the visual text is inaccessible at high zoom levels. -->
<img src='promo-banner-with-text.jpg' alt='50% indirim — sadece bu hafta sonu'>

Text inbakad i bilder — Korrekt

<!-- CORRECT: Use real HTML text over a background image so the browser
     can resize it. The image is decorative background; text is live HTML. -->
<div class='promo-banner' role='region' aria-label='Promosyon'>
  <p class='promo-text'>50% İndirim &mdash; Sadece Bu Hafta Sonu</p>
</div>
<!-- CSS sets the background image on .promo-banner, while .promo-text
     uses rem font-size and contrasts safely against the background. -->

Vanliga misstag

• Att lägga till user-scalable=no i viewport-meta-taggen för att förhindra att layouten "går sönder" på mobiler — detta är en direkt, testbar överträdelse av 1.4.4 och får aldrig användas. Åtgärda layouten i stället för att undertrycka användarens möjlighet att zooma.
• Att sätta maximum-scale=1.0 eller något värde under 2.0 — även utan user-scalable=no förhindrar en begränsning av zoomen till 1,0 eller 1,5 att användare når 200% och innebär att kriteriet inte uppfylls.
• Att använda JavaScript-händelselyssnare för att anropa event.preventDefault() på nyp-zoom- eller rullhändelser — att blockera inbyggd zoom programmatiskt är funktionellt likvärdigt med metoden via viewport-meta-taggen och bryter mot samma kriterium.
• Att sätta font-size i pixlar på <html>- eller <body>-elementet och sedan använda em-enheter för allt annat — om rotteckenstorleken är fast i px är alla em/rem-efterkommande också i praktiken fasta och kommer inte att reagera på användarens webbläsarinställning för teckenstorlek.
• Att använda height i stället för min-height på kortkomponenter, sidofält eller modal-kroppar — vid 200% zoom flödar förstora texter över fasta höjder och klipps av overflow: hidden, vilket döljer kritiskt innehåll.
• Att placera viktig text enbart inuti <canvas>-element — canvas-renderad text är en rasteriserad bitmap och kan inte skalas av webbläsarens mekanismer för textförstoring eller zoom. All meningsfull text som en användare behöver läsa måste finnas som riktig HTML-text eller åtminstone som tillgänglig alternativtext.
• Att använda SVG-<text>-element med absoluta koordinater och ingen viewBox-skalning — SVG-text kan vara skalbar när SVG:n använder en viewBox och storleksätts med relativa enheter, men SVG-text med fasta x-, y-, font-size-attribut satta i pixlar inuti en SVG med fast width och height förstoras inte med webbläsarzoom i alla webbläsare.
• Att anta att webbläsarzoom automatiskt uppfyller kriteriet och hoppa över manuell testning — webbläsarzoom skalar hela sidan inklusive bilder och layout, men text som redan var för liten, klippt eller överlappande vid 100% blir ett större problem vid 200%. Manuell verifiering vid zoomnivå krävs alltid.
• Att glömma att testa inbäddade tredjepartswidgets — chattwidgets, betalnings-iframes, cookie-samtyckesbanners och analysöverlägg utvecklas ofta av tredje part med fasta px-storlekar och kan blockera zoom. Även om koden är från tredje part gäller kriteriet för hela sidan så som den levereras till användaren.
• Att åtgärda desktoplayouten för zoom men försumma mobilbrytpunkt — många team testar zoom på desktop och deklarerar framgång, men mobila viewporter vid 200% zoom innebär en separat uppsättning layoututmaningar, särskilt för navigationsmenyer, klistriga sidhuvuden och nedersta navigationsfält som är beroende av fasta pixelhöjder.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentdekret 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webb- och mobiltillgänglighet för en definierad uppsättning organisationer som är verksamma i Turkiet. Dekretet hänvisar till internationellt erkända tillgänglighetsstandarder — vilket i praktiken innebär att turkiska krav linjeras med WCAG 2.1 och WCAG 2.2 Nivå AA som riktmärke för överensstämmelse.

WCAG 1.4.4 Resize Text är ett kriterium på Nivå AA, och överensstämmelse på Nivå AA är tröskeln som krävs för att erhålla tillgänglighetslogotypen (Erişilebilirlik Logosu) som utfärdas av Ministeriet för familje- och socialtjänster (Aile ve Sosyal Hizmetler Bakanlığı). Tillgänglighetslogotypen är både en signal om allmänhetens förtroende och en regulatorisk kontrollpunkt — organisationer som omfattas av dekretet och som vill visa logotypen eller visa överensstämmelse för revisorer måste uppfylla alla kriterier på Nivå AA, inklusive 1.4.4.

Kategorierna av aktörer som omfattas av presidentdekret 2025/10 inkluderar: offentliga institutioner och myndigheter på alla förvaltningsnivåer; e-handelsplattformar och nätmarknadsplatser; banker och finansiella tjänsteleverantörer som regleras av Banktillsyns- och regleringsmyndigheten (BDDK); sjukhus, vårdcentraler och andra vårdorganisationer med digitala patientinriktade tjänster; teleoperatörer med 200 000 eller fler abonnenter; resebyråer och nätbaserade reseplattformar; privata transportföretag som erbjuder digital biljettförsäljning eller bokningstjänster; samt privatskolor och utbildningsinstitutioner som auktoriserats av Utbildningsministeriet (Millî Eğitim Bakanlığı, MoNE).

För var och en av dessa aktörstyper är den praktiska innebörden av 1.4.4 betydande. En banks internetbankportal som blockerar nyp-zoom på mobiler är inte bara ett användbarhetsfel — det är en regulatorisk avvikelse som kan leda till revisionsanmärkningar eller uteslutning från programmet för tillgänglighetslogotypen. Ett sjukhus bokningssystem för tider som använder fasta teckenstorlekar i pixlar inuti behållare som klipper innehåll misslyckas med att betjäna patienter med nedsatt syn och misslyckas samtidigt med sina skyldigheter enligt dekretet. En privatskoles antagningsplattform som bäddar in text i bilder i stället för att använda skalbar HTML-text är på liknande sätt icke-kompatibel.

Organisationer bör se WCAG 1.4.4 inte som en snäv teknisk kryssruta utan som en grundläggande förväntan på respekt för användare med synnedsättning — en förväntan där turkisk lag, internationell best practice och grundläggande användbarhet alla sammanfaller. Accsible's overlay SDK stödjer efterlevnad av krav på textförstoring genom att tillhandahålla konfigurerbara kontroller för teckenskalning som gör det möjligt för slutanvändare att öka textstorleken oberoende av webbläsarzoom, vilket erbjuder ett extra anpassningslager ovanpå de grundläggande krav som webbplatserna själva måste implementera.