Å bygge en sann kultur for digital tilgjengelighet i et selskap er et oppdrag om robusthet og utholdenhet. Det er ikke vanskelig for diskursen om tilgjengelighet å falle inn i de vanlige klisjeene. Tilgjengelighet er veldig viktig for mennesker. Tilgjengeligheten til digitale produkter og tjenester fremmer inkludering. Eller til og med alle fagfolk på teamene bør være involvert i tilgjengelighetsarbeid. Selvfølgelig. Ingen ved sitt rette sinn vil bestride noen av disse uttalelsene (håper jeg). Den andre delen av denne samtalen, som svært få selskaper når, er "hvordan?" Hvordan får vi dette til midt i det daglige arbeidet til digitale transformasjonsteam, som, som vi alle vet, er fordypet i krevende manus, ofte med et svært begrenset antall personer tilgjengelig? Mesteparten av tiden ender valget mellom "vi gjør dette" og "det". Og det burde det ikke, for i disse tilfellene så jeg aldri tilgjengelighet vinne i denne ligningen. Det burde ikke være slik. Du trenger ikke være på denne måten. Først av alt, fordi å velge mellom tilgjengelighet og noe annet ikke er det riktige valget. Tilgjengelighet er ikke lenger bare en annen funksjon som skal legges til de andre. Det er en merverdi for virksomheten og for tiden en juridisk forpliktelse som kan få alvorlige konsekvenser for bedrifter. På den annen side er det intelligente, optimaliserte og virkningsfulle måter å inkorporere tilgjengelighetsprinsipper i den naturlige dynamikken til team. Det er mulig å jobbe med tilgjengelighet uten å snu teamdriften på hodet. I hovedsak er det det AccessibilityOps gjør. Styrke mennesker og gi team enkle prosesser slik at de kan integrere tilgjengelighetsarbeid i sine daglige rutiner uten uforholdsmessig innsats. Tilgjengelighet og design Arbeid med digital tilgjengelighet i design kan innebære flere handlinger. Det er tydelig at vi må være spesielt oppmerksomme på farge og hvordan den brukes til å formidle mening. Selvfølgelig må interaksjonsstørrelsene til elementene være komfortable. Men viktigst av alt, vi må tenke på design fra et allsidig perspektiv. Et grensesnitt er ikke en plakat. Vi kan kontrollere mange aspekter av det designet, men hvordan brukere samhandler med grensesnittet er underlagt et uendelig antall variabler. Type enhet, kontekst, formål, nettverkskvalitet osv. Alt dette påvirker i stor grad hver persons opplevelse og interaksjon. Sammen med alt dette, når bekymringer om digital tilgjengelighet tas inn i designprosessen, legger det til enda flere variabler.
Folk bruker ofte det som kalles hjelpeteknologier og -strategier. I utgangspunktet er dette teknologiske verktøy eller i det minste "triks" som folk tyr til for å finne mer komfortable bruksmodeller. De kjente skjermleserne, som vanligvis forbindes med bruk av blinde (men som ikke bare er nyttige for dem), er for eksempel en hjelpeteknologi. Å endre farger eller fargekontraster mellom ulike elementer er også en hjelpeteknologi. Å øke skriftstørrelsen (som vi diskuterte i denne teksten) er et annet eksempel. Det finnes utallige hjelpeteknologier og strategier. Nesten like mange som de ulike brukskontekstene for hver person. Vi kontrollerer ikke alt Med andre ord (og dette er de "dårlige nyhetene" for oss designere), er "vårt design" underlagt, fra brukernes perspektiv, transformasjoner som vi ikke kontrollerer. Det vil bli "transformert" av brukeren, og sikrer at de kan samhandle med applikasjonen og alt den tilbyr på en mest mulig komfortabel måte. Og det er en god ting. Hvis dette skjer og alt går bra, vil vi garantert ha gjort vårt tilgjengelighetsarbeid veldig bra, og vi fortjener alle gratulasjoner. Hvis brukeren bruker noen av disse støtteteknologiene og strategiene og fortsatt ikke kan bruke den digitale applikasjonen, er det et tegn på at noe ikke fungerer som det skal. Å, og apropos det. Ikke engang tenk på å blokkere bruken av disse teknologiene eller støttestrategiene. De kan «ødelegge» det vakre designet ditt, men de lar flere og flere mennesker faktisk bruke appen. Til slutt, var det ikke akkurat det vi lovet at vi ville gjøre? Design for (alle) mennesker. Uten unntak? Øk skriftstørrelse Hvor mange ganger har vi hørt noen – venner, familie eller til og med kolleger – klage over at denne eller den teksten er for liten? Tekst spiller en svært viktig rolle i den digitale opplevelsen. Mye informasjon formidles gjennom tekst:instruksjoner for bruk, knappetekster eller interaktive elementer. Alt dette bruker tekst som et kommunikasjonsverktøy. Hvis det er vanskelig å lese alle disse elementene, blir opplevelsen naturligvis sterkt svekket. Komfortabel tekstlesing, uavhengig av funksjon, er et ikke-omsettelig prinsipp. Denne lesingen kan forenkles ved å bruke komfortable størrelser i designet. Imidlertid kan støtteteknologier og strategier, gjennom funksjonaliteten til å øke skriftstørrelsen, også bidra til å forbedre lesbarheten. I følge APPT-data øker 26 % av brukere av Android- og iOS-mobilenheter standard skriftstørrelse (data fra februar 2026). Én av fire brukere øker skriftstørrelsen på smarttelefonen. Dette er et svært betydelig utvalg av mennesker, noe som gjør denne funksjonaliteten uunngåelig i designprosesser.
Overholdelse av retningslinjer Å øke skriftstørrelsen i grensesnitt kan representere en stor designutfordring. Det er viktig å forstå at plutselig kan enkelte tekstelementer, på grunn av brukerhandlinger, dobles i størrelse fra opprinnelig størrelse. "Med unntak av bildetekster og tekstbilder, kan tekst endres størrelse uten hjelpeteknologi opptil 200 % uten tap av innhold eller funksjonalitet." — Suksesskriterium 1.4.4, "Endre størrelse på tekst" i Web Content Accessibility Guidelines (WCAG), versjon 2.2
Dette suksesskriteriet er på AA-samsvarsnivå, noe som betyr at dette er en absolutt obligatorisk funksjon i henhold til ethvert juridisk rammeverk. Det er lett å forstå 200 % i dette suksesskriteriet. Hvis vi antar at vi designer grensesnittene i en skala på 100 %, noe som betyr at elementstørrelsen er den opprinnelige størrelsen, vil en økning av teksten med opptil 200 % tilsvare en dobling av den opprinnelige størrelsen. Andre forstørrelsesskalaer kan også brukes, for eksempel 120 %, 140 % og så videre. Med andre ord, vi må sørge for at brukere kan øke teksten til å doble den opprinnelige størrelsen gjennom støtteteknologier eller strategier (og dette er ikke en liten detalj). For å overholde denne standarden trenger vi ikke å tilby verktøy for å øke tekststørrelsen i grensesnittene. I praksis er disse funksjonene ikke annet enn redundans. Enheter lar allerede dette gjøres på en standardisert måte. Brukere som virkelig trenger denne innstillingen vet det (fordi uten den ville livet deres vært mye vanskeligere). Vel, de har allerede denne innstillingen brukt på enheten deres. Og det betyr at vi kan eliminere disse ekstra grensesnittelementene, og forenkle opplevelsen.
Standardisert tilgang Et viktig konsept å huske om hjelpeteknologier, spesielt i dette tilfellet når det gjelder å øke skriftstørrelsen, er at de fleste enheter allerede har mange av disse verktøyene installert som standard. Med andre ord, i mange tilfeller trenger ikke brukere å kjøpe sin egen programvare eller kjøpe en bestemt type enhet bare for å ha denne funksjonaliteten. Enten på mobile enheter eller til og med i nettlesere, i de aller fleste tilfeller er det enkelt å finne installerte funksjoner som lar deg øke standard skriftstørrelsen vi bruker i hele grensesnittet. Dette prinsippet om å øke skriftstørrelsen kan brukes på digitale produkter, for eksempel apper, eller til og med på alle typer nettsteder som kjører på standard nettlesere som brukes i dag. iPhones På iPhone-enheter er funksjonen for økning av skriftstørrelse integrert som standard. For å bruke denne funksjonen, gå ganske enkelt til "Innstillinger"-panelet, velg "Tilgjengelighet", og i "Vision"-alternativgruppen, gå til "Tekststørrelse og visning"-funksjonen og konfigurer ønsket skriftstørrelsesøkning på den skjermen.
Google Chrome Nettlesere tilbyr også, som standard, funksjonaliteten for å øke skriftstørrelsen. For eksempel, i Google Chrome, er denne funksjonen tilgjengelig i "Alternativer"-panelet, spesielt i "Utseende"-området. I listen over alternativer som vises i denne gruppen, velg ganske enkelt alternativet "Skriftstørrelse". Normalt vil alternativet "Medium - Anbefalt" velges. Du kan endre denne innstillingen til en hvilken som helst annen tilgjengelig skriftstørrelse. Prøv for eksempel alternativet "Veldig stort".
Test i Figma For å sikre at digitalt tilgjengelighetsarbeid blir effektivt i teams daglige liv, er det vesentlig å finne enkle arbeidsprosesser. Handlinger eller initiativer som kan integreres i teamets rutine, som adresserer tilgjengelighet på en integrert måte, og som ikke krever en dramatisk transformasjon av den nåværende virkeligheten. Hvis det var nødvendig, mener han, ville det ikke skjedd mesteparten av tiden. Derfor er utforming av enkle arbeidsprosesser halve kampen for at tilgjengelighet virkelig skal skje, i dettecase, også innenfor et designteam. Når det gjelder å teste skriftstørrelsesøkninger i design, har vi ekstraordinære verktøy til rådighet i dag. De som husker tiden med å designe komplekse grensesnitt i Adobe Photoshop, vil kjenne igjen forskjellene i verktøyene vi har i dag (og heldigvis det). Det er nå mulig, gjennom verktøy som Figma, å skape en slik dynamikk i design at testing av skriftstørrelse øker for tilgjengelighet blir nesten uunngåelig for teamet.
Merk: For å ta denne testen må du ha et godt grep om Figmas tekststiler, automatiske layouter og variabler. Disse tre er grunnleggende verktøy for å lykkes uten mye ekstra innsats. Hvis du ennå ikke har mestret disse funksjonene, anbefales det sterkt at du starter der. Ikke hopp over trinn. Læring er en gradvis prosess som må følges på en strukturert, trinnvis måte. Hvor ønsker vi å gå? Testen for økning av skriftstørrelse i Figma som vi ønsker å utføre er enkel. Vi ønsker å ha et sett med variabler tilgjengelig for alle tekststilene vi bruker i grensesnittet, slik at vi kan velge om vi vil se grensesnittet med teksten i en skala på 100 %, 120 %, 140 %, 160 %, 180 % eller 200 %. Når vi bruker dette settet med variabler (omtrent som å bruke variabler for lys og mørk modus), observerer vi transformasjonene av teksten i grensesnittet og forstår i hvilken grad tilpasninger er nødvendig i hver versjon av grensesnittet med forskjellige typografiske skalaer.
Hvordan får vi dette til? For at denne testen skal gå så greit, må du gjøre litt grunnarbeid. Designsystemer kan i stor grad bidra til å optimalisere mye av dette innledende arbeidet. Men jeg vil ikke lyve for deg. For at testen skal fungere godt, må designet ditt ha et veldig seriøst nivå av organisering og systematisering. Dette er egentlig ikke en veiledning, fordi hvert team vil ha sin egen arbeidsmodell, og disse anbefalingene kan brukes på forskjellige måter (og det er greit). Men for at denne testen skal fungere, er det viktig å sikre visse forutsetninger i designet. For å hjelpe deg med å fase implementeringen av denne testmodellen, her er noen trinn du må følge. Trinn-for-trinn-instruksjoner for å veilede deg i å organisere filene dine og sikre at du kan utføre denne testen fullt ut på den enkleste og mest praktiske måten. 1. Designe grensesnittene Det hele starter med designet. Før en eventuell testing bør fokus, som det skal, være på utformingen av hvert grensesnitt som vi ønsker å teste senere. På dette stadiet er det fortsatt ingen spesifikk bekymring med skriftstørrelsesøkningen som vi skal utføre senere. Naturligvis bør all grensesnittdesign fra første stund følge de mest grunnleggende tilgjengelighetsanbefalingene som gjelder for design.
2. Bruk automatiske oppsett på alle elementer I hvert skjermdesign du lager, må du sørge for at du bruker autooppsett perfekt. Dette er et veldig viktig skritt. Det er denne konsekvente bruken av automatiske layouter på hele strukturen og designelementene som senere vil garantere skalerbarheten til grensesnittet når vi begynner å teste skriftstørrelsen øker. Du kan virkelig ikke undervurdere dette trinnet. Hvis du ikke gir den den oppmerksomheten den fortjener, vil du se når vi tester typografisk skalering i grensesnittene, at alt bryter sammen som en elefant i en kinabutikk.
3. Strukturere og bruke tekststiler For å utføre testen vår for å øke skriftstørrelsen, trenger vi også at du har brukt tekststiler på hvert grensesnittdesign. Du begynte sannsynligvis til og med å lage dem mens du tegnet. Stor. Hvis du ikke har gjort det, er det viktig at du gjør det nå. For at testen skal fungere perfekt, trenger vi virkelig dette. Ikke la noe tekstelement være i designet uten en tekststil.
4. Definer settet med variabler 100 % Denne testen tvinger frem en ganske høy grad av optimalisering. I praksis betyr dette at vi må bruke Figma-variabler for alle egenskapene til tekststilene vi har i grensesnittet. På dette stadiet må du definere Figma "nummer"-variabler for minst skriftstørrelsen og linjehøyden til tekststilene du brukte på tegningen. Med dette trinnet definerer du skalaverdiene for skriftstørrelsesøkning for en 100 % visualiseringsmodell, det vil si den første versjonen og referanseversjonen av tegningen. Det er viktig at du strukturerer disse variablene for hver tekststil i tegningen, fordi vi senere må vurdere forstørrelsesskalaen til hvert av disse tekstelementene.
5. Bruk variablene på tekststilene Etter å ha definert variablene for tekststilene i 100 % skala, må du nå bruke demtil elementene i tekststilene som allerede er opprettet. Ikke glem å bruke variabler i det minste på karakteristikkene for skriftstørrelse og linjehøyde. Hvis du har flere typografiske variabler, er det greit. Men du bør i det minste ha variabler brukt på skriftstørrelse og linjehøyde. Dette er virkelig veldig viktig.
6. Definer variablene for å øke tekststørrelsen Nå som du har brukt variablene på tekststilene i 100 % skala, er neste trinn å lage variablene for de andre skriftstørrelsesøkningene. I praksis må du lage variablene som vil fortelle systemet hvilken skriftstørrelse hver tekststil vil vokse til når økningsskalaen er 120 %, 140 %, 160 % osv. For å definere verdiene for skriftstørrelse og linjehøyde, multipliser ganske enkelt startverdien med skalaprosenten. For eksempel, hvis en tekststil har en skriftstørrelse på 16px, vil størrelsen for 120%-skalaen være 16 multiplisert med 1,2, som gir et resultat på 19,2. Gjenta denne beregningen for alle verdier for skriftstørrelse og linjehøyde for skriftstørrelsen øker skalaprosentene du velger. Du kan også velge om du vil bruke avrunding til sluttverdiene. Dette er en tilnærmet test, og derfor vil eventuelle forskjeller som kan oppstå ved avrunding ikke påvirke den endelige oppfatningen av testresultatet.
7. Bruk variabler på forskjellige skalaversjoner Sannhetens øyeblikk har kommet. Det neste trinnet er å forstå om vi har alt fungerer slik at testen går perfekt. Derfor bør du kopiere det originale grensesnittet og bruke settet med variabler for hver av fontstørrelsesøkningene som gir mening for deg. Gjenta denne prosessen for alle prosentene for økning av skriftstørrelsen du har definert. Som et forslag kan du bruke økningsprosentene på 120 %, 140 %, 160 %, 180 % og 200 % som referanse. Hvis du ønsker å forenkle, kan du redusere antall skaleringsprosenter du jobber med. Uavhengig av antall prosenter du jobber med, bør du alltid jobbe med minimum 100% og 200% skalaer.
8. Identifiser områder for forbedring Ved å bruke forskjellig skriftstørrelsesøkning på samme skjerm, er det lett å forstå hvor forbedringer kan være nødvendig. Det er her den virkelige testen med å øke skriftstørrelsen i grensesnittdesign og det mest interessante tilgjengelighetsarbeidet begynner. Når du analyserer de ulike skjermene, må du huske på noen viktige aspekter:
Det faktum at teksten fremstår som gigantisk er ikke et problem og "ødelegger" ikke designet. Husk at dette kan bety forskjellen mellom at noen kan bruke et bestemt produkt eller en tjeneste eller ikke. Et tilgjengelighetsproblem eksisterer når en økning av skriftstørrelsen gjør det umulig for brukeren å lese bestemte tekster eller å aktivere visse kontroller. For tekstelementer som allerede er veldig store, er det kanskje ikke fornuftig å øke skriftstørrelsen. Å gjøre det kan gjøre disse elementene uforholdsmessige, noe som ikke vil forbedre lesbarheten (siden de allerede har en god størrelse) og vil oppta helt unødvendig plass. Hvis det er elementer som ser ut til å dukke ut av skjermen, er det første trinnet å bekrefte hvordan du bruker automatisk layout. Mange designaspekter kan enkelt løses med riktig bruk av automatisk layout. Uavhengig av omfanget av skriftstørrelsesøkningen, er det viktig å opprettholde det visuelle hierarkiet til typografien, siden denne lesbarheten er viktig for å oppfatte de ulike informasjonsnivåene som er på skjermen. Denne testen kan bidra til å identifisere elementer som kan trenge justeringer direkte i koden for å fungere godt i en gitt økningsskala. Ikke alt kan løses gjennom design alene, og det er helt greit. Tilgjengelighet er i hovedsak et lagarbeid.
9. Foreta korrigeringer og justeringer av designet Til slutt, basert på de forskjellige skjermene med forskjellige tekstforstørrelsesskalaer, kan du gjøre designendringene som gir mening. Noen av disse justeringene er kanskje bare nødvendige i kode. I disse tilfellene dokumenterer du alle disse forslagene og sender dem videre til utviklingsteamet. Det er også avgjørende å forsterke (igjen) at noen av problemene du kan støte på i designet raskt kan løses i designprosessen, med enkel og korrekt anvendelse av auto-layout-egenskaper.
10. Gå tilbake til begynnelsen og gjenta prosessen Dette er en syklisk tilnærming. Dette betyr at du bør gjenta disse trinnene, eller variasjoner av dem, så mange ganger som nødvendig gjennom hele prosjektet. Det er naturlig at noen over tid og med prosessoptimaliseringav disse trinnene vil slutte å gi mening. Det er absolutt ikke et problem. Men det viktigste å innse her er at tilgjengelighet og denne prosessen med å teste skriftstørrelsesøkninger ikke bør gjøres bare én gang, og det er det. Det er en test som skal gjøres mange, mange ganger gjennom det daglige arbeidet til hvert prosjekt og team.
Rollen til designsystemer Ved første øyekast kan denne listen over trinn virke som en kompleks øvelse. Men det er det ikke. Dette er fordi de aller fleste, om ikke alle, av disse trinnene er enkle å utføre i enhver sammenheng der et designsystem eksisterer. Faktisk har designsystemer blitt en uunngåelig standard i produktdesignindustrien. Vi kan diskutere hva hvert team kaller et designsystem, men sannheten er at det i dag er veldig vanskelig å finne et produktdesignteam som i det minste ikke har et minimalt strukturert bibliotek med komponenter og stiler.
Med dette grunnlaget, enten det er mer eller mindre dokumentert, er det veldig enkelt å bruke denne typen skriftstørrelsesøkningstest ved hjelp av Figma-variabler. Videre, hvis designsystemet ditt allerede har for eksempel strukturerte variabler for lys og mørk modus, betyr det at du allerede bruker nøyaktig de samme prinsippene som vi brukte for å utføre denne testen. Altså, ikke noe nytt. Arbeid med designsystemer innebærer et nivå av strukturering og organisering som også er svært nyttig for å lage denne typen tester. Det er en myte om at designsystemer begrenser kreativiteten. Dette er ikke sant. Designsystemer hjelper til med å løse den "byråkratiske" delen av design, slik at vi faktisk kan ha mer tid til det som betyr noe: i dette tilfellet, testing av tilgjengelighet og bygging av flere og flere produkter og tjenester som virkelig er tilgjengelige for flest mulig mennesker. Eksempelfil Det er alltid lettere å se et eksempel enn å bare lese en beskrivelse av en prosess. Hvis dette er sant i mange kunnskapsdisipliner, i design, gir denne forutsetningen enda mer mening. Derfor, i denne Figma-filen, fritt publisert og åpent tilgjengelig for fellesskapet, finner du et praktisk eksempel på hele testprosessen beskrevet her. Husk at dette bare er et eksempel. Det kan være utallige måter å utføre denne typen tester innenfor konteksten av en Figma-fil.
Sørg for å se på denne tilnærmingen med et kritisk blikk. Det er et forslag for å teste skriftstørrelsesøkninger som følger en bestemt prosess. Til tross for dette bør tilnærmingen tilpasses teamets spesifikke virkelighet, prosesser og modenhetsnivå. Bare å kopiere formler fra andre team uten å forstå om de gir mening i vår egen kontekst er en sikker måte å gjøre tilgjengelighetsarbeidet uforholdsmessig. Hver situasjon er unik. Denne tilnærmingen forsøker å forenkle tilgjengelighetsarbeidet så mye som mulig i denne spesifikke konteksten. Og husk: Hvis noe skjer, uansett hvor lite det er, er det et skritt fremover, ikke et skritt tilbake. Og det bør alle på laget feire.
