Knapp

en kontroll som en person trycker på för att något ska hända

Vad det är

En knapp är den del av ett gränssnitt som utför något när den aktiveras: skickar ett meddelande, sparar ett utkast, öppnar en dialog, stänger av ljudet i ett samtal. På webben är den oftast HTML-elementet <button>, och i tillgänglighetssammanhang är det allt som bär rollen button. Tryckknapp är ett äldre namn på samma sak, och i kod och specifikationer heter den button.

WAI-ARIA 1.2 beskriver rollen som en inmatning där användaren utlöser en handling genom att klicka eller trycka, och påpekar att knappar mest används för avgränsade handlingar. En vanlig kommandoknapp minns ingenting. En växlingsknapp, markerad med aria-pressed, förblir på eller av tills någon trycker igen, och en menyknapp, markerad med aria-haspopup, öppnar en lista med fler val.

Den gräns som betyder mest går mellan knapp och länk. En länk för läsaren någon annanstans; en knapp ändrar något där läsaren redan befinner sig. ARIA Authoring Practices Guide (APG) kallar de två funktionerna tydligt åtskilda. När en länk har ritats som en knapp, eller tvärtom, föredrar guiden att den visuella designen ändras så att den passar funktionen, framför att elementet lånar den andras roll.

HTML Living Standard beskriver <button> som en knapp vars etikett är dess innehåll. Attributet type har tre nyckelord. submit skickar formuläret som knappen hör till, reset återställer formulärets fält till startvärdena och button gör ingenting av sig själv, utan lämnar handlingen åt ett skript. Saknas type, eller är det felstavat, hamnar knappen i tillståndet Auto, och en sådan knapp i ett formulär, utan något kommando kopplat till sig, är en skickaknapp. Inget interaktivt innehåll får ligga inuti den: ingen länk, inget fält och ingen andra knapp.

Standarden låter också en knapp verka på ett annat element utan skript. commandfor pekar ut målet med dess ID, och command säger vad som ska göras med det, till exempel att visa en popover eller öppna en dialog som modal. Hur mycket av det en viss webbläsare har levererat är en fråga för den webbläsarens egna versionsanteckningar.

Varför det spelar roll

Knappen är platsen där läsning blir handling: att köpa, skicka, spara och radera går alla genom en. En knapp som vissa människor inte hittar, når eller förstår stänger ute dem från just den del av produkten som betalar för resten.

Det riktiga elementet har beteendet med sig. En <button> tar emot tangentbordsfokus, kör sin handling på mellanslag och på Enter, berättar för hjälpmedlen att den är en knapp och vad den heter, och slutar svara när den bär disabled. I förklaringsdokumentet till WCAG 2.2 för framgångskriterium 4.1.2, Name, Role, Value, står att vanliga HTML-kontroller redan uppfyller kriteriet när de används enligt specifikationen. En <div> med en klickhanterare har inget av detta, och varje bit som fattas stänger ute någon.

Namnet är ett löfte. En skärmläsare presenterar en knapp med dess tillgängliga namn och dess roll, så namnet ska säga vad knappen gör, inte hur den ser ut. APG lägger till en regel för växlingsknappar som är lätt att bryta: etiketten är densamma medan tillståndet ändras. Guidens exempel är en knapp med namnet ”Mute”, som läses upp som ”Mute toggle button pressed” när den är påslagen. Om designen hellre växlar mellan två etiketter, som ”Stäng av ljud” och ”Slå på ljud”, behövs inget aria-pressed, eftersom etiketten själv berättar tillståndet.

Storlek är ett krav, inte en smaksak. Framgångskriterium 2.5.8 i WCAG 2.2, Target Size (Minimum), på nivå AA, kräver att ett mål för pekaren är minst 24 gånger 24 CSS-pixlar. Undantagen gäller små mål med tillräckligt utrymme runt sig, en fullstor kontroll någon annanstans på sidan som gör samma sak, länkar mitt i en mening, kontroller vars storlek webbläsaren bestämmer och storlekar som är nödvändiga. Ett darrande finger, en buss i rörelse och en tumme på en telefon gör alla små mål svårare att träffa.

Fokus ska landa någonstans vettigt. Efter ett tryck förväntar sig APG att fokus flyttas in i en dialog som knappen öppnade, och att det när dialogen stängs normalt återvänder till knappen som öppnade den. Lämnar trycket läsaren i samma sammanhang, som en Verkställ-knapp gör, stannar fokus normalt på knappen. Den som använder tangentbord och får fokus kastat till sidans topp efter varje sparning börjar om sidan varje gång.

Så ser det ut i praktiken

Det tydligaste exemplet börjar med en enda uppläsning. I en SwiftUI-applikation byggd på systemsymboler läste skärmläsaren upp skicka-knappen som ”arrow up circle, button”, eftersom en symbol utan etikett presenteras med sitt interna namn. Arbetet med att ge alla sjutton ikonkontroller namn för skärmläsare gav var och en en etikett som namnger handlingen snarare än formen, och där en kontrolls betydelse beror på tillståndet följer etiketten tillståndet. Det som håller längst är kontrollen: en linter som letar upp konstruktionen som skapar en kontroll med enbart ikon och kräver en tillgänglighetsetikett inom åtta rader från den. Åtta rader valdes genom mätning och är medvetet grovt. Lintern godtar också en etikett som hör till en vy strax bredvid, så knappens namn kan fortfarande vara fel tills någon lyssnar på det.

Nästa lärdom handlar om det en knapp inte klarar av. I skiktet för betalningar och åtkomsträttigheter, byggt på Stripe och på köp i appen hos Apple och Google, avgör ett separat åtkomstschema på 11 tabeller om ett konto får använda företagskatalogen, sökningen och dataexporten. Servern prövar det svaret igen för varje anrop, vad knappen på skärmen än visar, och sidan säger skälet på en rad: en dold knapp är en artighet och inte ett skydd.

Knappar spelar roll också för läsare som inte är människor. Webbplatsens sida om att vara redo för AI-agenter noterar att många agenter som styr en webbläsare läser sidan genom dess tillgänglighetsträd, precis som en skärmläsare gör. Riktiga knappar och formulär med etiketter är en del av det som låter en agent hitta ett formulär och fylla i det.

Webbplatsens egna mallar innehåller inte ett enda <button>-element. Den fyllda uppmaningen ”Hör av dig” är ett <a> som stylats som en knapp, eftersom den leder till kontaktsidan, och regeln i dess stilmall sätter min-height till 24 pixlar, med en kommentar som hänvisar till framgångskriterium 2.5.8. Huvudmenyn är ett <details>-element vars <summary> öppnar och stänger den, och kommentaren i mallen säger att det är webbläsaren som äger det öppna tillståndet och knappsemantiken, helt utan skript.

Var det går fel

  • En klickbar ruta får stå i elementets ställe. En <div> eller <span> med en klickhanterare svarar på musen och på lite annat: den tar inget fokus, struntar i mellanslag och Enter och presenteras som vanlig text. Att lägga till role="button" rättar bara uppläsningen; fokus och tangenter måste fortfarande skrivas för hand.
  • En länk gör en knapps jobb, eller tvärtom. En länk som raderar en post kan öppnas i en ny flik eller sparas som bokmärke, och då upprepas raderingen eller så tappar någon bort den. En knapp som bara navigerar går inte att öppna i en ny flik och har ingen adress att kopiera.
  • En naken knapp i ett formulär skickar formuläret. Eftersom en knapp utan type hamnar i tillståndet Auto, skickar en knapp för ”Lägg till rad” eller ”Visa lösenord” som ligger i ett formulär iväg formuläret i samma ögonblick som någon trycker på den. Att skriva type="button" på varje knapp som inte ska skicka tar bort överraskningen.
  • Ikonen är hela etiketten. En soptunna, en penna eller en pil betyder något för den som ritade den. Skärmläsaren läser då upp ett filnamn, ett symbolnamn eller bara ”knapp”, om ingen har gett kontrollen ett tillgängligt namn. Ett synligt ord är bäst; där det inte får plats fyller ett tillgängligt namn som säger vad som händer luckan.
  • En dold eller inaktiverad knapp behandlas som säkerhet. Att ta bort knappen från sidan stoppar bara ärliga användare. Anropet bakom den kan fortfarande skickas, och servern måste på egen hand avgöra om just det här kontot får göra just det här.

Läs mer

Ordlista