Dropdown-dilemmat: Att bygga tillgängliga digitala tjänster

The WebAim Million

Varje år publicerar WebAIM rapporten ”The WebAIM Million”, där de tillgänglighetsgranskar 1 miljon webbsidor. I rapporten från 2025 hittades över 50 miljoner unika fel – i genomsnitt 51 fel per webbsida, https://webaim.org/projects/million/. Det är många fel! Notera att dessa granskningar endast är utförda med automatiska verktyg – inga manuella tester. 

Hur kan det finnas så många fel?

Likt hur det finns många sätt att använda digitala tjänster, så finns det minst lika många sätt att bygga dem på. Mängden ramverk, bibliotek och designsystem är stor och abstraktionsnivån blir högre och högre. Kanske gör det att vissa missar att det finns standarder för hur man bygger tillgängligt, gömda under alla abstraktionslager? Eller är problemet att tillgänglighet ibland inte tas med i beräkningen när projekt planeras? Kanske är det en kombination?

Oavsett vad orsaken är så finns problemen där. Vi kommer tyvärr inte lösa allt i den här artikeln, men för att komma in i rätt tankesätt – låt oss dyka ner i ett litet konkret exempel som illustrerar ett vardagligt tekniskt tillgänglighetsproblem.

GelaTogether – där glass-entusiaster möts

”Användaren ska kunna välja favoritglass.” Så skulle ett krav kunna lyda om vi bygger en social plattform för glassentusiaster, här kallad ”GelaTogether”. Vissa kanske tänker ”Lätt som en plätt! Vi bygger en Dropdown där användare kan göra ett val bland en lista av alternativ.”

Om det ändå vore så lätt. Till att börja med så kan en ”Dropdown” ibland även kallas ”Meny”, ”Rullista”, ”Popup-meny” eller ”Select”. Hur kan en sådan till synes enkel komponent ha så många namn? Inte bara det, den kan och bör även implementeras på olika sätt beroende på kontext. Ska den användas i ett formulär, eller som inställningsmeny i en applikation? En Dropdown är alltså ett bra exempel på en komponent som är mer komplex än vissa tror. Varför? Håll i er, för nu blir det tekniskt!

För att illustrera problemen så kommer vi här använda CodePen, där ni kan se både kod och en interaktiv implementation. Följande är ett exempel på hur en Dropdown kan byggas:

Vissa kanske tycker att denna lösning fungerar bra. Det går att klicka på knappen, en lista öppnas och det går att göra val. Allt löst, med ”bara” 227 rader kod! Tyvärr kan dock inte alla användare välja favoritglass med denna lösning. Här är några problem:

• Det går inte att navigera mellan alternativen med tangentbord.
• Det går inte att avgöra vad som är valt i listan, varken visuellt eller programmatiskt för skärmläsare.
• Det går inte att stänga listan med ”Escape” eller genom att klicka utanför.
• Knappen visar inte programmatiskt när listan är öppen eller stängd.
• När listan öppnas flyttas inte fokus till första alternativet.

Det där är några vanliga fel vid byggande av Dropdown-komponenter. Oavsett om utvecklare använder ett färdigt komponentbibliotek, vibe-kodar eller bygger från grunden, så är det viktigt att säkerställa att dessa saker fungerar. Och dessutom att rätt typ av Dropdown används på rätt plats.

Vi behöver mer – och rätt kod!

Hur löser vi dessa problem då? Låt oss kika på hur en mer tillgänglig Dropdown skulle kunna byggas:

Rent visuellt ser komponenten nästan likadan ut. Denna lösning landar dock på hela 458 rader kod! Det är ungefär dubbelt så många som den förra. Det krävs alltså en hel del för att göra komponenter ordentligt tillgängliga. Vi behöver inte gå igenom koden rad för rad, men kika gärna om du är intresserad. Rent praktiskt så har vi gjort följande förbättringar:

• Vi lade till stöd för att navigera alternativen i listan med piltangenter.
• Vi visar nu tydligt vad som är valt i listan, både visuellt och programmatiskt.
• Listan går nu att stänga med ”Escape” och genom att klicka utanför.
• Knappen visar nu programmatiskt om den är öppen eller stängd.
• Fokus läggs nu på första elementet i listan när den öppnas.

Nu kan fler användare välja favoritglass! Toppen va? Testa gärna båda lösningarna med tangentbord och skärmläsare, och lusläs även koden.

Slutligen

Det finns som nämnt många sätt att bygga digitala tjänster på, och det här exemplet visar bara några tekniska utmaningar med en vanlig komponent. Ämnet är stort och det finns mycket mark att täcka. Förhoppningsvis gav detta dock en liten inblick i hur det kan gå till att bygga tillgängligt. För gör vi det så säkerställer vi att så många som möjligt kan ta del av det vi bygger – och det är viktigt!

Har ni frågor eller tankar kring att bygga tillgängliga digitala tjänster? Tveka inte att höra av er till oss på Esatto! Vi hjälper er gärna.