Ett gränssnitt som inte går att styra med tangentbordet är trasigt

Om du kan klicka på något ska du kunna nå det med Tab och trycka Enter. Det är hela regeln. GNOME:s designriktlinjer formulerar den ungefär så: varje handling som går att utföra med en pekdon ska också gå att utföra med tangentbordet. WCAG säger samma sak i lagtext-form och sedan lagen om tillgänglighet till digital offentlig service gäller den i praktiken för varje svensk myndighetssajt och kommunal e-tjänst.

Ändå är det här ett av de vanligaste felen i modern webbutveckling. Inte för att utvecklare är slarviga, utan för att ett `

Fyra tekniska val avgör om ditt gränssnitt går att navigera

Det mesta löser sig av sig självt om du använder rätt HTML-element. ``, ``, ``, `` och `` är fokuserbara i alla webbläsare, aktiveras med Enter eller mellanslag och rapporterar sin roll till skärmläsare. En `<div onclick>` gör ingenting av detta. Den syns men existerar inte för tangentbordet.</p></p> <p><p>När semantiken inte räcker till kommer `tabindex`. Regeln är enklare än den ser ut: använd `tabindex=”0″` för att lägga in ett element i den naturliga tabbordningen och `tabindex=”-1″` för element du vill kunna fokusera programmatiskt utan att de dyker upp när användaren tabbar förbi. Positiva värden som `tabindex=”3″` finns men bryter dokumentordningen och skapar en tabbsekvens som ingen kan förutse. Skriv dem inte.</p></p> <p><p>Fokusindikatorn är det tredje benet. Webbläsarens standardring är ful och därför har `outline: none` blivit ett av de mest kopierade CSS-fragmenten på internet. Problemet är att den raderar användarens enda sätt att veta var hen befinner sig. Ta bort den om du vill men ersätt med något eget som syns mot bakgrunden. `:focus-visible` löser dessutom det gamla dilemmat, att fokusringen såg konstig ut vid musklick, den träffar bara när webbläsaren bedömer att användaren faktiskt navigerar med tangentbord. Kontrasten mellan fokusmarkering och bakgrund ska klara samma krav som text, vilket du kan kontrollera med en <a href=”https://monc.se/fargkonverterare/”>färgkonverterare med WCAG-kontroll</a>.</p></p> <p><p>Det fjärde är fokushantering och det är där de flesta ramverk faller. Öppnar du en modal måste fokus flyttas in i den, stanna kvar där så länge den är öppen och återvända till knappen som öppnade den när den stängs. Escape ska stänga. Utan detta hamnar tangentbordsanvändaren bakom modalen och tabbar runt i en sida som ser blockerad ut men inte är det. Samma princip gäller allt som dyker upp, dropdowns, sidopaneler, autocomplete-listor.</p></p> <p><p>Sedan finns mönstren där Tab inte är rätt tangent. En menyrad, en flikuppsättning eller en radioknappsgrupp ska ha <em>en</em> tabbstopp totalt och piltangenter som flyttar mellan alternativen inuti. Det kallas roving tabindex: det aktiva elementet har `tabindex=”0″`, resten `tabindex=”-1″` och din kod flyttar nollan när användaren trycker pil. Tänk på hur du navigerar i en filmeny i vilket skrivbordsprogram som helst. Ingen tabbar sig genom tolv menyalternativ.</p></p> <p><p>Ett sista mönster som kostar tio minuter och betyder mycket: en skiplänk först i dokumentet som hoppar förbi navigationen till huvudinnehållet. Den behöver inte synas förrän den får fokus.</p></p> <p><h2>Skärmläsaranvändare och gipsarmar är inte de enda som behöver tangentbordsstöd</h2></p> <p><p>Argumentet för tangentbordsstöd formuleras nästan alltid som ett tillgänglighetskrav och det är korrekt. Personer som använder skärmläsare, personer med motoriska funktionsnedsättningar och alla som tillfälligt har en arm i gips är beroende av det. Men det är en underdrift av vem som drar nytta.</p></p> <p><p>Varje person som lärt sig sitt verktyg ordentligt slutar använda musen för de vanliga sakerna. Utvecklare i VS Code, ekonomiassistenter i Excel, alla som någonsin lärt sig `Ctrl+K` i Slack. Tangentbordet är snabbare därför att handen redan ligger där och därför att ett kortkommando är ett steg medan ett musklick är sikta, flytta, träffa.</p></p> <p><p>Det här är också varför kommandoradsgränssnitt aldrig dog. GUI:t vann på 1980-talet av goda skäl, från Macintosh 1984 till Windows 3.0 år 1990 men <a href=”https://en.wikipedia.org/wiki/Text-based_user_interface”>textbaserade gränssnitt</a> lever kvar hos precis de användare som gör samma sak hundra gånger om dagen. Kommandopaletten, som numera finns i nästan varje seriös webbapp, är i praktiken en CLI som smugit sig tillbaka in i det grafiska gränssnittet. Den är populär av samma anledning som `ssh` fortfarande är text: <a href=”https://monc.se/sa-funkar-det/grafiskt-skal-ssh/”>det snabbaste sättet att uttrycka en avsikt är ofta att skriva den</a>.</p></p> <p><h2>Testet tar två minuter och du gör det utan verktyg</h2></p> <p><p>Lägg undan musen. Ladda om sidan. Tabba igenom den från början till slut.</p></p> <p><p>Tre saker ska stämma. Du ska alltid kunna se var fokus är. Ordningen ska följa det du ser på skärmen, inte hoppa mellan spalter i den ordning elementen råkade hamna i DOM:en. Och du ska kunna utföra varje uppgift sidan erbjuder, inklusive att stänga det du öppnat. Fastnar fokus någonstans har du hittat en bugg som en fjärdedel av dina användare stöter på dagligen.</p></p> <p><p>Automatiska verktyg fångar de grova felen, ungefär som W3C-validatorn fångar trasig HTML men de kan inte bedöma om tabbordningen är logisk för en människa. Det kräver att någon faktiskt tabbar. Gör det tidigt, medan komponenten fortfarande är billig att skriva om och du slipper upptäcka veckan före lansering att hela designsystemet bygger på klickbara divar.</p>