# Knapp

## 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](/sv/portfolio/named-all-seventeen-interface-icons-for-screen-readers-159/)
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](/sv/portfolio/built-the-payments-and-entitlements-layer-96/),
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](/sv/ai-ready/)
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

- [WAI-ARIA 1.2: button role](https://www.w3.org/TR/wai-aria-1.2/#button) —
  rollens definition, varianterna för växling och meny, och de tillstånd och
  egenskaper den stöder.
- [HTML Living Standard: the button element](https://html.spec.whatwg.org/multipage/form-elements.html#the-button-element)
  — innehållsmodellen, typerna submit, reset och button, tillståndet Auto och
  attributen `command` och `commandfor`.
- [ARIA Authoring Practices Guide: Button Pattern](https://www.w3.org/WAI/ARIA/apg/patterns/button/)
  — knappar kontra länkar, tangentbordsbeteende, vart fokus tar vägen efter ett
  tryck och regeln för etiketter på växlingsknappar.
- [Understanding SC 2.5.8: Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html)
  — minimimåttet 24 gånger 24 pixlar, testet för avstånd och de övriga
  undantagen.
- [Understanding SC 4.1.2: Name, Role, Value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html)
  — varför varje kontroll behöver ett namn och en roll som programvara kan läsa,
  och när vanliga HTML-kontroller redan uppfyller kriteriet.

<https://engineer.company/sv/glossary/button/>