Kan alla använda din AI-byggda app? En enkel guide till tillgänglighet

Apptillgänglighet innebär att alla — personen som zoomar in skärmen, knappar med en tumme, eller inte kan skilja rött från grönt — faktiskt kan använda din app, inte bara du. Tre snabba kontroller avslöjar de flesta problemen: zoom, färg och en skärmläsare.

När du bygger en app med AI testar du den på det sätt du själv använder den: din skärm, dina ögon, ditt stadiga tvåhandsgrepp om en bärbar dator. Problemet är att en stor del av dem som kommer att öppna din app inte använder den på det sättet. Någon zoomar in mobiltexten till dubbel storlek. Någon kan inte skilja ditt röda felmeddelande från den svarta texten runt omkring. Någon håller en bebis och knappar med en tumme. Apptillgänglighet handlar helt enkelt om huruvida de personerna ändå kan ta sig igenom appen — och det är en fråga som de flesta AI-byggda appar aldrig får sig ställd.

Du behöver ingen examen eller ett efterlevnadsteam för att hantera det. Du behöver veta var de fyra eller fem ställena är där appar brukar stänga ute folk, och hur du ber din builder åtgärda dem. Låt mig visa dig de vanligaste med berättelser, för de är lättare att upptäcka när man väl har sett dem.

Varför går layouten i min app sönder när någon zoomar in?

Eftersom de flesta AI-byggda appar designas med en fast textstorlek, så när någon förstorar texten på sin telefon eller i sin webbläsare — något många gör, särskilt alla över sextio — överlappar knapparna varandra, kolumner faller ihop till en rörig stapel, och kontroller glider in under varandra.

En builder jag känner byggde en snygg liten bokningsapp för sin mammas hårsalong. Den såg bra ut. Sedan öppnade hennes mamma appen, och det första hon gjorde — som många över sextio — var att nypa för att zooma in texten. Layouten föll samman. Knappar överlappade varandra, “Boka”-knappen gled in under menyn, och en kolumn med tider blev till en rörig stapel man inte kunde läsa.

Det här är det vanligaste tillgänglighetsproblemet i AI-byggda appar, och det syns inte förrän någon zoomar. Be din builder: “Se till att layouten fortfarande fungerar när texten zoomas till 200 %. Inget ska överlappa eller klippas av.” Testa det sedan själv — höj systemtypsnittet på din telefon till dess högsta inställning och öppna din app. Om den rasar samman, det är din första sak att fixa.

Varför ska min app inte använda enbart färg för att visa status?

Eftersom ungefär en av tolv män ser färg annorlunda, oftast rött och grönt — så en status som visas enbart som en röd prick jämfört med en grön prick ser likadan ut för dem, och de kan verkligen inte skilja “betald” från “förfallen.”

En frilansare byggde en fakturaspårare som visade status enbart genom färg — grön prick, röd prick. En av hans kunder, som råkade vara röd-grön färgblind, fortsatte betala fakturor som redan var betalda eftersom de två prickarna såg identiska ut för honom. Informationen fanns där. Den fanns bara inte där för honom.

Lösningen är en vana, inte en funktion: använd aldrig färg som det enda sättet att säga något. Lägg till ett ord, en ikon eller en form bredvid. “Förfallen” bredvid den röda. En bock bredvid den gröna. En asterisk och ordet “obligatoriskt”, inte bara en röd kant. Färgen får gärna vara kvar — den kan bara inte bära budskapet ensam.

Varför säger skärmläsare bara “knapp” istället för att namnge den?

Eftersom en ikonknapp utan etikett — en papperskorg, en penna, ett förstoringsglas utan ord — inte har någon text för skärmläsaren (mjukvaran som blinda och synsvaga personer använder för att få skärmen uppläst) att läsa upp, så säger den, bokstavligen, “knapp”. Inte “radera”. Inte “redigera”. Bara “knapp”.

AI-byggare älskar rena ikonknappar eftersom de ser moderna ut. Men föreställ dig att använda en app där varje kontroll heter “knapp” och du måste gissa. Du behöver inte lägga till synlig text på varje ikon — du måste se till att varje kontroll har ett namn under ytan, även ett osynligt som skärmläsaren kan läsa upp. Be din builder: “Ge varje ikonknapp en tillgänglig etikett — en papperskorgsikon ska läsas upp som ‘Radera’, en penna som ‘Redigera’.” Det är en liten ändring, och det är skillnaden mellan en app en blind användare kan navigera i och en som är en mur av anonyma knappar.

Hur stora bör tryckytorna vara i en mobilapp?

Tumregeln designers använder är att allt som går att trycka på bör vara ungefär 44 pixlar — ungefär storleken på en fingertopp — med riktigt mellanrum så att inte två tryckbara saker sitter tätt intill varandra.

Titta på när någon använder din app med en hand på en buss. Tummar är breda och oprecisa, bussen rör sig, och ditt “X” för att stänga är en 16-pixlar stor prick i hörnet. De missar den två gånger, träffar det som ligger bakom en gång, och ger upp. Små, tätt placerade tryckytor är ett tillgänglighetsproblem, inte bara en irritation — de drabbar personer med skakningar, större fingrar, eller en rörlig miljö hårdast. Be din builder: “Gör tryckytorna minst 44 pixlar och lägg till mellanrum mellan dem så att folk inte trycker fel.” Testa det sedan: öppna din app på din telefon och försök göra huvudåtgärden med en hand, medan du går omkring. Om du fortsätter trycka fel kommer alla andra också göra det.

Hur testar jag min app för tillgänglighet på fem minuter?

Du kan hitta det mesta av det här själv utan några verktyg, med tre snabba kontroller på skärmen folk använder mest:

  1. Zooma in den. Höj texten på din telefon eller i din webbläsare till högsta inställningen och öppna huvudskärmen. Överlappar, försvinner eller klipps något av?
  2. Töm den på färg. Titta på varje ställe din app använder färg för att betyda något — status, fel, obligatoriska fält. Om du föreställer dig allt i gråskala, kan du fortfarande se vad som händer? Om inte, lägg till ett ord eller en ikon.
  3. Slå på skärmläsaren i två minuter. Både iPhone (VoiceOver) och Android (TalkBack) har en inbyggd. Slå på den, blunda, och försök göra huvudsaken din app är till för. Du kommer genast höra vilka knappar som saknar namn.

Inget av det här kräver att du är utvecklare. Det kräver att du slutar testa som dig själv i fem minuter och testar som någon vars händer, ögon eller skärm inte matchar dina egna.

Du behöver inte fixa allt på en gång. Välj den ena skärm folk använder mest — bokningsformuläret, registreringen, huvudlistan — och se till att just den fungerar när den zoomas in, töms på färg och läses upp. Den enda skärmen, rätt gjord, täcker fler människor än en hel tillgänglighetsgranskning av hörnen ingen besöker. Börja där, så får nästa person som öppnar din app med en tumme och en inzoomad skärm vara en användare istället för att studsa iväg.