At opbygge en sand kultur for digital tilgængelighed i en virksomhed er en mission om robusthed og vedholdenhed. Det er ikke svært for diskursen om tilgængelighed at falde ind i de sædvanlige klicheer. Tilgængelighed er meget vigtigt for mennesker. Tilgængeligheden af digitale produkter og tjenester fremmer inklusion. Eller endda bør alle fagfolk på teamene involveres i tilgængelighedsarbejde. Selvfølgelig. Ingen ved deres rette sind vil bestride nogen af disse udsagn (håber jeg). Men den anden del af denne samtale, som meget få virksomheder når, er "hvordan?" Hvordan får vi det til at ske midt i det daglige arbejde i digitale transformationsteams, der, som vi alle ved, er fordybet i krævende manuskripter, ofte med et meget begrænset antal mennesker til rådighed? Det meste af tiden ender valget med at stå mellem "vi gør det her" og "det". Og det burde det ikke, for i disse tilfælde har jeg aldrig set tilgængelighed vinde i denne ligning. Sådan burde det ikke være. Du behøver ikke være på denne måde. Først og fremmest fordi at vælge mellem tilgængelighed og alt andet ikke er det rigtige valg. Tilgængelighed er ikke længere blot endnu en funktion, der skal føjes til de andre. Det er en merværdi for virksomheden og i øjeblikket en juridisk forpligtelse, der kan få alvorlige konsekvenser for virksomhederne. På den anden side er der intelligente, optimerede og virkningsfulde måder at inkorporere tilgængelighedsprincipper i teams naturlige dynamik. Det er muligt at arbejde med tilgængelighed uden at vende op og ned på teamdriften. I bund og grund er det, hvad AccessibilityOps gør. Bemyndigelse af mennesker og give teams enkle processer, så de kan integrere tilgængelighedsarbejde i deres daglige rutiner uden uforholdsmæssig indsats. Tilgængelighed og design Arbejdet med digital tilgængelighed i design kan involvere flere handlinger. Det er klart, at vi skal være særligt opmærksomme på farve, og hvordan den bruges til at formidle mening. Naturligvis skal interaktionsstørrelserne af elementer være behagelige. Men vigtigst af alt skal vi tænke design fra et alsidigt perspektiv. En grænseflade er ikke en plakat. Vi kan kontrollere mange aspekter af det design, men hvordan brugere interagerer med grænsefladen er underlagt et uendeligt antal variabler. Typen af enhed, kontekst, formål, netværkskvalitet osv. Alt dette påvirker i høj grad hver persons oplevelse og interaktion. Sammen med alt dette, når bekymringer om digital tilgængelighed bringes ind i designprocessen, tilføjer det endnu flere variabler.
Folk bruger ofte det, der kaldes hjælpeteknologier og -strategier. Dybest set er disse teknologiske værktøjer eller i det mindste "tricks", som folk tyr til for at finde mere komfortable brugsmodeller. De berømte skærmlæsere, der almindeligvis forbindes med brugen af blinde mennesker (men som ikke kun er nyttige for dem), er for eksempel en hjælpeteknologi. Ændring af farver eller farvekontraster mellem forskellige elementer er også en hjælpeteknologi. Forøgelse af skriftstørrelsen (som vi diskuterede i denne tekst) er et andet eksempel. Der er utallige hjælpeteknologier og strategier. Næsten lige så mange som de forskellige brugskontekster for hver person. Vi kontrollerer ikke alt Med andre ord (og dette er de "dårlige nyheder" for os designere), er "vores design" ud fra brugernes perspektiv underlagt transformationer, som vi ikke kontrollerer. Det vil blive "transformeret" af brugeren, hvilket sikrer, at de kan interagere med applikationen og alt, hvad den tilbyder på den mest behagelige måde som muligt. Og det er en god ting. Hvis dette sker, og alt går godt, vil vi helt sikkert have gjort vores tilgængelighedsarbejde rigtig godt, og vi fortjener alle tillykke. Hvis brugeren anvender nogen af disse støtteteknologier og -strategier og stadig ikke kan bruge den digitale applikation, er det et tegn på, at noget ikke fungerer, som det skal. Åh, og apropos det. Tænk ikke engang på at blokere brugen af disse teknologier eller supportstrategier. De "ødelægger" måske dit smukke design, men de giver flere og flere mennesker mulighed for rent faktisk at bruge appen. I sidste ende, var det ikke præcis det, vi lovede, at vi ville gøre? Design til (alle) mennesker. Uden undtagelse? Forøg skriftstørrelse Hvor mange gange har vi hørt nogen – venner, familie eller endda kolleger – beklage sig over, at den eller den tekst er for lille? Tekst spiller en meget vigtig rolle i den digitale oplevelse. Meget information formidles gennem tekst:brugsanvisninger, knaptekster eller interaktive elementer. Alt dette bruger tekst som et kommunikationsværktøj. Hvis det er svært at læse alle disse elementer, er oplevelsen naturligvis alvorligt svækket. Komfortabel tekstlæsning, uanset dens funktion, er et princip, der ikke kan forhandles. Denne læsning kan lettes ved at bruge komfortable størrelser i designet. Men understøttende teknologier og strategier, gennem funktionaliteten med at øge skriftstørrelsen, kan også hjælpe med at forbedre læsbarheden. Ifølge APPT-data øger 26 % af brugere af Android- og iOS-mobilenheder standardskriftstørrelsen (data fra februar 2026). Hver fjerde bruger øger skriftstørrelsen på deres smartphone. Dette er et meget betydeligt udvalg af mennesker, hvilket gør denne funktionalitet uundgåelig i designprocesser.
Overholdelse af retningslinjer Forøgelse af skriftstørrelse i grænseflader kan repræsentere en stor designudfordring. Det er vigtigt at forstå, at nogle tekstelementer pludselig på grund af brugerhandlinger kan fordobles i størrelse fra deres oprindelige størrelse. "Med undtagelse af billedtekster og tekstbilleder kan tekst ændres størrelse uden hjælpeteknologi op til 200 % uden tab af indhold eller funktionalitet." — Succeskriterium 1.4.4, "Ændring af størrelse på tekst" i Web Content Accessibility Guidelines (WCAG), version 2.2
Dette succeskriterium er på AA-overholdelsesniveau, hvilket betyder, at dette er en absolut obligatorisk funktion i henhold til enhver juridisk ramme. Det er let at forstå de 200 % i dette succeskriterium. Hvis vi antager, at vi designer grænsefladerne i en skala på 100 %, hvilket betyder, at elementstørrelsen er den oprindelige størrelse, så vil en forøgelse af teksten med op til 200 % svare til en fordobling af den oprindelige størrelse. Andre forstørrelsesskalaer kan også bruges, såsom 120%, 140% og så videre. Med andre ord skal vi sikre, at brugerne kan øge teksten til at fordoble dens oprindelige størrelse gennem understøttende teknologier eller strategier (og dette er ikke en mindre detalje). For at overholde denne standard behøver vi ikke at levere værktøjer til forøgelse af tekststørrelse i grænsefladerne. I praksis er disse funktioner ikke andet end redundans. Enheder gør det allerede muligt at gøre dette på en standardiseret måde. Brugere, der virkelig har brug for denne indstilling, ved det (fordi uden den ville deres liv være meget vanskeligere). Nå, de har allerede denne indstilling anvendt på deres enhed. Og det betyder, at vi kan fjerne disse ekstra grænsefladeelementer, hvilket forenkler oplevelsen.
Standardiseret adgang Et vigtigt koncept at huske om hjælpeteknologier, især i dette tilfælde med hensyn til at øge skriftstørrelsen, er, at de fleste enheder allerede har mange af disse værktøjer installeret som standard. Med andre ord, i mange tilfælde behøver brugere ikke at købe deres egen software eller købe en bestemt type enhed bare for at have denne funktionalitet. Uanset om det er på mobile enheder eller endda i webbrowsere, er det i langt de fleste tilfælde nemt at finde installerede funktioner, der giver dig mulighed for at øge standardskriftstørrelsen, vi bruger i hele grænsefladen. Dette princip om at øge skriftstørrelsen kan anvendes på digitale produkter, såsom apps, eller endda på enhver type hjemmeside, der kører på de standard webbrowsere, der bruges i dag. iPhones På iPhone-enheder er funktionen til forøgelse af skriftstørrelse integreret som standard. For at bruge denne funktion skal du blot få adgang til panelet "Indstillinger", vælge "Tilgængelighed", og i gruppen "Vision"-indstilling, få adgang til funktionen "Tekststørrelse og visning" og konfigurere den ønskede skriftstørrelsesforøgelse på den skærm.
Google Chrome Webbrowsere tilbyder også som standard funktionaliteten til at øge skriftstørrelsen. For eksempel i Google Chrome er denne funktion tilgængelig i panelet "Indstillinger", specifikt i området "Udseende". På listen over muligheder, der vises i denne gruppe, skal du blot vælge "Skriftstørrelse". Normalt vil indstillingen "Medium — Anbefalet" være valgt. Du kan ændre denne indstilling til enhver anden tilgængelig skriftstørrelse. Prøv for eksempel muligheden "Meget stor".
Test i Figma For at sikre, at digitalt tilgængelighedsarbejde bliver effektivt i teams dagligdag, er det essentielt at finde enkle arbejdsprocesser. Handlinger eller initiativer, der kan integreres i teamets rutine, som adresserer tilgængelighed på en integreret måde, og som ikke kræver en dramatisk transformation af den nuværende virkelighed. Hvis det var nødvendigt, mener han, ville det ikke ske det meste af tiden. Derfor er design af simple arbejdsprocesser halvdelen af kampen for, at tilgængelighed virkelig sker i dettecase, også inden for et designteam. Med hensyn til at teste skriftstørrelsesstigninger i design, har vi ekstraordinære værktøjer til vores rådighed i dag. De, der husker tiden med at designe komplekse grænseflader i Adobe Photoshop, vil genkende forskellene i de værktøjer, vi har i dag (og heldigvis også). Det er nu muligt, gennem værktøjer som Figma, at skabe en sådan dynamik i designet, at test af skriftstørrelsesstigninger for tilgængelighed bliver næsten uundgåelig for teamet.
Bemærk: For at tage denne test skal du have et godt kendskab til Figmas tekststile, automatiske layouts og variabler. Disse tre er grundlæggende værktøjer til succes uden meget ekstra indsats. Hvis du endnu ikke har mestret disse funktioner, anbefales det stærkt, at du starter der. Spring ikke trin over. Læring er en gradvis proces, der skal følges på en struktureret, trin-for-trin måde. Hvor vil vi hen? Den skriftstørrelsesforøgelsestest i Figma, som vi ønsker at udføre, er enkel. Vi ønsker at have et sæt variabler tilgængelige for alle de tekststilarter, vi bruger i grænsefladen, så vi kan vælge, om vi vil se grænsefladen med teksten i en skala på 100 %, 120 %, 140 %, 160 %, 180 % eller 200 %. Når vi anvender dette sæt af variabler (meget som at anvende variabler for lys og mørk tilstand), observerer vi transformationerne af teksten i grænsefladen og forstår, i hvilket omfang der er behov for tilpasninger i hver version af grænsefladen med forskellige typografiske skalaer.
Hvordan får vi dette til at ske? For at denne test skal forløbe så gnidningsløst, skal du lave noget grundarbejde. Designsystemer kan i høj grad hjælpe med at optimere meget af dette indledende arbejde. Men jeg vil ikke lyve for dig. For at testen kan fungere godt, skal dit design have et meget seriøst niveau af organisation og systematisering. Dette er ikke rigtig en guide, fordi hvert team vil have sin egen arbejdsmodel, og disse anbefalinger kan anvendes på forskellige måder (og det er okay). Men for at denne test skal fungere, er det vigtigt at sikre visse antagelser i designet. For at hjælpe dig med at fase implementeringen af denne testmodel er her nogle trin, du skal følge. Trin-for-trin instruktioner til at guide dig i at organisere dine filer og sikre, at du fuldt ud kan udføre denne test på den enkleste og mest praktiske måde. 1. Design af grænseflader Det hele starter med designet. Inden enhver test bør fokus, som det skal, være på designet af hver grænseflade, som vi ønsker at teste senere. På nuværende tidspunkt er der stadig ingen specifik bekymring med den skriftstørrelsesforøgelsestest, som vi vil udføre senere. Naturligvis bør alt interfacedesign fra starten følge de mest basale tilgængelighedsanbefalinger, der anvendes til design.
2. Anvend automatiske layouts på alle elementer I hvert skærmdesign, du opretter, skal du sikre, at du anvender automatiske layouts perfekt. Dette er et meget vigtigt skridt. Det er denne konsekvente anvendelse af automatiske layouts til hele strukturen og designelementerne, der senere vil garantere skalerbarheden af grænsefladen, når vi begynder at teste, at skriftstørrelsen stiger. Du kan virkelig ikke undervurdere dette trin. Hvis du ikke giver den den opmærksomhed, den fortjener, vil du se, når vi tester typografisk skalering i grænsefladerne, at alt går i stykker som en elefant i en porcelænsbutik.
3. Strukturering og anvendelse af tekststile For at udføre vores test for øgning af skriftstørrelse skal du også have anvendt tekststile på hvert interfacedesign. Du begyndte sikkert endda at skabe dem, mens du tegnede. Stor. Hvis du ikke har gjort det, er det vigtigt, at du gør det nu. For at testen skal fungere perfekt, har vi virkelig brug for dette. Efterlad ikke noget tekstelement i designet uden en tekststil.
4. Definer sætet af variabler 100 % Denne test fremtvinger en ret høj grad af optimering. I praksis betyder det, at vi bliver nødt til at bruge Figma-variabler til alle karakteristika ved de tekststilarter, vi har i grænsefladen. På dette trin skal du definere Figma "nummer"-variabler for mindst skriftstørrelsen og linjehøjden af de tekststile, du har anvendt på tegningen. Med dette trin definerer du skalaværdierne for forøgelse af skriftstørrelsen for en 100 % visualiseringsmodel, det vil sige den indledende version og referenceversionen af tegningen. Det er vigtigt, at du strukturerer disse variable for hver tekststil i tegningen, fordi vi efterfølgende skal overveje forstørrelsesskalaen for hvert af disse tekstelementer.
5. Anvend variablerne på tekststilene Efter at have defineret variablerne for tekststilene i 100 % skala, skal du nu anvende demtil elementerne i de allerede oprettede tekststile. Glem ikke at anvende variabler i det mindste til karakteristika for skriftstørrelse og linjehøjde. Hvis du har flere typografiske variabler, er det fint. Men du bør i det mindste have variabler anvendt på skriftstørrelse og linjehøjde. Dette er virkelig meget vigtigt.
6. Definer variablerne for at øge tekststørrelsen Nu hvor du har anvendt variablerne på 100 % skala tekststile, er næste trin at oprette variablerne for de andre skriftstørrelsesforøgende skalaer. I praksis skal du oprette de variable, der fortæller systemet, hvilken skriftstørrelse hver tekststil vil vokse til, når stigningsskalaen er 120 %, 140 %, 160 % osv. For at definere værdierne for skriftstørrelse og linjehøjde skal du blot gange startværdien med skalaprocenten. For eksempel, hvis en tekststil har en skriftstørrelse på 16px, vil størrelsen for 120% skalaen være 16 ganget med 1,2, hvilket giver et resultat på 19,2. Gentag denne beregning for alle værdier for skriftstørrelse og linjehøjde for den skriftstørrelse, der øger skalaprocenter, du vælger. Du kan også vælge, om du vil anvende afrunding til de endelige værdier. Dette er en tilnærmet test, og derfor vil eventuelle forskelle, der måtte opstå ved afrunding, ikke påvirke den endelige opfattelse af testresultatet.
7. Anvend variabler på forskellige skalaversioner Sandhedens øjeblik er kommet. Det næste trin er at forstå, om vi har alt til at fungere, så testen kører perfekt. Derfor bør du kopiere den originale grænseflade og anvende det sæt af variabler for hver af de skriftstørrelsesforøgelseshastigheder, der giver mening for dig. Gentag denne proces for alle de skriftstørrelsesstigningsprocenter, du har defineret. Som et forslag kan du bruge stigningsprocenterne på 120 %, 140 %, 160 %, 180 % og 200 % som reference. Hvis du vil forenkle, kan du reducere antallet af skaleringsprocenter, du arbejder med. Uanset hvor mange procenter du arbejder med, bør du altid arbejde med minimum 100% og 200% skalaer.
8. Identificer områder for forbedring Ved at anvende forskellige skriftstørrelsesforøgelsesskalaer på den samme skærm er det nemt at forstå, hvor der kan være behov for forbedringer. Det er her den virkelige test med at øge skriftstørrelsen i interfacedesign og det mest interessante tilgængelighedsarbejde begynder. I din analyse af de forskellige skærmbilleder skal du huske på nogle vigtige aspekter:
At teksten fremstår gigantisk er ikke et problem og "ødelægger" ikke designet. Husk, at dette kan betyde forskellen mellem, om nogen kan bruge et bestemt produkt eller en bestemt tjeneste eller ej. Der opstår et tilgængelighedsproblem, når en forøgelse af skriftstørrelsen gør det umuligt for brugeren at læse bestemte tekster eller at aktivere visse kontroller. For tekstelementer, der allerede er meget store, giver det måske ikke mening at øge skriftstørrelsen. Hvis du gør det, kan det gøre disse elementer uforholdsmæssigt store, hvilket ikke ville forbedre læsbarheden (da de allerede har en god størrelse) og ville optage helt unødvendig plads. Hvis der er elementer, der ser ud til at poppe ud af skærmen, er det første trin at bekræfte, hvordan du anvender automatisk layout. Mange designaspekter kan let løses med korrekt brug af autolayout. Uanset omfanget af skriftstørrelsesstigningen, er det vigtigt at bevare det visuelle hierarki i typografien, da denne læsbarhed er vigtig for at opfatte de forskellige niveauer af information, der er til stede på skærmen. Denne test kan hjælpe med at identificere elementer, der kan have behov for justeringer direkte i koden for at fungere godt i en given stigningsskala. Ikke alt kan løses gennem design alene, og det er helt i orden. Tilgængelighed er i bund og grund en teamindsats.
9. Foretag rettelser og justeringer af designet Endelig kan du, baseret på de forskellige skærmbilleder med forskellige tekstforstørrelsesskalaer, foretage de designændringer, der giver mening. Nogle af disse justeringer er muligvis kun nødvendige i kode. I disse tilfælde dokumenterer du alle disse forslag og sender dem videre til udviklingsteamet. Det er også afgørende at understrege (igen), at nogle af de problemer, du kan støde på i designet, hurtigt kan løses i designprocessen, med den enkle og korrekte anvendelse af auto-layout-egenskaber.
10. Gå tilbage til begyndelsen og gentag processen Dette er en cyklisk tilgang. Det betyder, at du skal gentage disse trin, eller variationer deraf, så mange gange som nødvendigt gennem hele projektet. Det er naturligt, at nogle over tid og med procesoptimeringaf disse trin vil ophøre med at give mening. Det er absolut ikke et problem. Men den vigtigste ting at indse her er, at tilgængelighed og denne proces med at teste skriftstørrelsesstigninger ikke bør gøres kun én gang, og det er det. Det er en test, der skal udføres mange, mange gange i løbet af det daglige arbejde for hvert projekt og team.
Designsystemernes rolle Ved første øjekast kan denne liste over trin virke som en kompleks øvelse. Men det er det ikke. Dette skyldes, at langt de fleste, hvis ikke alle, af disse trin er nemme at udføre i enhver sammenhæng, hvor der findes et designsystem. Faktisk er designsystemer blevet en uundgåelig standard i produktdesignindustrien. Vi kan diskutere, hvad hvert team kalder et designsystem, men sandheden er, at det i dag er meget svært at finde et produktdesignteam, der i det mindste ikke har et minimalt struktureret bibliotek af komponenter og stilarter.
Med dette fundament, hvad enten det er mere eller mindre dokumenteret, er det meget nemt at anvende denne type skriftstørrelsesforøgelsestest ved hjælp af Figma-variabler. Ydermere, hvis dit designsystem allerede har for eksempel strukturerede variabler for lys og mørk tilstand, betyder det, at du allerede anvender nøjagtig de samme principper, som vi brugte til at udføre denne test. Altså intet nyt. At arbejde med designsystemer involverer et niveau af strukturering og organisering, som også er meget nyttigt til at skabe denne type test. Der er en myte om, at designsystemer begrænser kreativiteten. Dette er ikke sandt. Designsystemer hjælper med at løse den "bureaukratiske" del af design, så vi faktisk kan have mere tid til det, der betyder noget: i dette tilfælde at teste tilgængelighed og bygge flere og flere produkter og tjenester, der virkelig er tilgængelige for det største antal mennesker. Eksempel fil Det er altid nemmere at se et eksempel end blot at læse en beskrivelse af en proces. Hvis dette er sandt i mange vidensdiscipliner, i design, giver denne forudsætning endnu mere mening. Derfor finder du i denne Figma-fil, som er frit offentliggjort og åbent tilgængelig for fællesskabet, et praktisk eksempel på hele testprocessen beskrevet her. Husk at dette kun er et eksempel. Der kan være utallige måder at udføre denne type test i sammenhæng med en Figma-fil.
Sørg for at se på denne tilgang med et kritisk blik. Det er et forslag til test af skriftstørrelsesforøgelser, der følger en bestemt proces. På trods af dette bør tilgangen tilpasses dit teams specifikke virkelighed, processer og modenhedsniveau. Blot at kopiere formler fra andre teams uden at forstå, om de giver mening i vores egen kontekst, er en sikker måde at gøre tilgængelighedsindsatsen uforholdsmæssig. Hver situation er unik. Denne tilgang forsøger at forenkle tilgængelighedsarbejdet så meget som muligt i denne specifikke sammenhæng. Og husk: Hvis der sker noget, uanset hvor lille, er det et skridt frem, ikke et tilbageskridt. Og det skal alle på holdet fejre.
