Trykknap

et element, man trykker på for at få noget til at ske

Hvad det er

En trykknap, i daglig tale bare en knap, er den del af en brugerflade, der handler, når den aktiveres: den sender en besked, gemmer en kladde, åbner en dialog eller slår lyden fra i et opkald. På nettet er knappen som regel HTML-elementet <button>, og set med tilgængelighedens øjne er det alt, der bærer rollen button.

WAI-ARIA 1.2 definerer rollen som »an input that allows for user-triggered actions when clicked or pressed«, altså et input, som brugeren udløser handlinger med ved klik eller tryk, og tilføjer, at knapper mest bruges til afgrænsede handlinger. En almindelig kommandoknap har ingen tilstand. En skifteknap, markeret med aria-pressed, forbliver slået til eller fra, indtil den trykkes igen, og en menuknap, markeret med aria-haspopup, åbner en liste med flere valg.

Den vigtigste grænse går mellem en knap og et link. Et link fører læseren et andet sted hen; en knap ændrer noget dér, hvor læseren allerede er. ARIA Authoring Practices Guide kalder de to funktioner tydeligt forskellige og foretrækker, når et link er tegnet som en knap eller omvendt, at det visuelle design bliver tilpasset funktionen frem for at låne det andet elements rolle.

HTML Living Standard beskriver <button>-elementet som en knap, der får sin etiket fra sit indhold. Dets type-attribut har tre nøgleord. submit sender den formular, knappen hører til, reset sætter formularens felter tilbage til deres startværdier, og button gør intet af sig selv og overlader handlingen til et script. Mangler type, eller er værdien stavet forkert, er knappen i tilstanden Auto, og en knap i den tilstand inde i en formular, uden en tilknyttet kommando, er en submitknap. Der må ikke ligge interaktivt indhold inde i den: intet link, intet felt og ingen knap nummer to.

Standarden lader også en knap virke på et andet element uden script: commandfor angiver målet ved dets ID, og command siger, hvad der skal ske med det, for eksempel at vise en popover eller åbne en dialog som modal. Hvor meget af det en given browser understøtter, er et spørgsmål for den browsers egne udgivelsesnoter.

Hvorfor det betyder noget

En knap er stedet, hvor læsning bliver til handling: at købe, sende, gemme og slette går altid gennem en. En knap, som nogle mennesker ikke kan finde, nå eller forstå, lukker dem ude fra den del af produktet, der betaler for resten.

Det rigtige element kommer med adfærden indbygget. En <button> kan få tastaturfokus, udfører sin handling på mellemrumstasten og på Enter, fortæller hjælpeteknologien, at den er en knap, og hvad den hedder, og holder op med at reagere, når den har disabled. Understanding-dokumentet til succeskriterium 4.1.2 i WCAG 2.2, Name, Role, Value, bemærker, at almindelige HTML-kontroller allerede opfylder kriteriet, når de bruges efter specifikationen. En <div> med en klikhandler har intet af det, og hver brik, der mangler, lukker nogen ude.

Navnet er et løfte. En skærmlæser annoncerer en knap ved dens tilgængelige navn og dens rolle, så navnet skal sige, hvad knappen gør, ikke hvordan den ser ud. APG tilføjer en regel for skifteknapper, som er let at bryde: etiketten forbliver den samme, mens tilstanden skifter. Vejledningens eksempel er en knap med navnet »Mute«, der annonceres som »Mute toggle button pressed«, når den er slået til. Foretrækker et design en etiket, der skifter mellem »Mute« og »Unmute«, er aria-pressed overflødig, fordi etiketten selv melder tilstanden.

Størrelse er et krav, ikke en smagssag. Succeskriterium 2.5.8 i WCAG 2.2, Target Size (Minimum), på niveau AA, kræver, at et mål for en pegeenhed er mindst 24 gange 24 CSS-pixel. Undtagelserne dækker små mål med plads nok omkring sig, en kontrol i fuld størrelse et andet sted på siden, der gør det samme, links inde i en sætning, kontroller, hvis størrelse browseren bestemmer, og tilfælde, hvor størrelsen er afgørende. En rystende hånd, en bus i bevægelse og en tommelfinger på en telefon gør alle små mål sværere at ramme.

Fokus skal lande et fornuftigt sted. Efter et tryk forventer APG, at fokus flytter ind i en dialog, som knappen har åbnet, og typisk vender tilbage til knappen, når dialogen lukkes. Efterlader trykket læseren i samme sammenhæng, som en Anvend-knap gør, bliver fokus typisk på knappen. En tastaturbruger, hvis fokus springer til toppen af siden, hver gang noget gemmes, begynder forfra hver gang.

Sådan ser det ud i praksis

Det tydeligste eksempel begynder med én annoncering. I en SwiftUI-applikation bygget af systemsymboler læste skærmlæseren send-knappen op som »pil op cirkel, knap«, fordi et symbol uden etiket bliver annonceret med sit interne navn. Da alle sytten ikonknapper blev navngivet for skærmlæsere, fik hver af dem en etiket, der angiver handlingen og ikke formen, og hvor en kontrols betydning afhænger af tilstanden, følger etiketten tilstanden. Den mere varige del er tjekket: en linter, der finder den konstruktion, som skaber en kontrol med kun et ikon, og kræver en tilgængelighedsetiket højst otte linjer derfra. Otte linjer blev valgt ved måling og er bevidst groft: reglen beviser, at en etiket findes i nærheden, ikke at den er korrekt, og nogen skal stadig lytte efter.

Den anden lektie handler om, hvad en knap ikke kan. I betalings- og rettighedslaget, bygget på Stripe og på Apples og Googles in-app-køb, afgør et separat access-skema på 11 tabeller, om en konto må bruge virksomhedskataloget, søgningen og dataeksporten. Svaret bliver kontrolleret igen på serveren ved hver forespørgsel, og siden giver grunden på én linje: en skjult knap er en høflighed og ikke en kontrol.

Knapper betyder også noget for læsere, der ikke er mennesker. Sitets side om at være klar til AI-agenter bemærker, at mange agenter, der betjener en browser, læser en side gennem dens tilgængelighedstræ, som en skærmlæser gør. Rigtige knapper og formularer med labels er en del af det, der lader en agent finde en formular og udfylde den.

Dette sites egne skabeloner indeholder slet intet <button>-element. Den udfyldte opfordring »Kontakt os« er et <a>-element stylet som en knap, fordi den fører til kontaktsiden, og dens stylesheetregel sætter min-height til 24 pixel med en kommentar, der henviser til succeskriterium 2.5.8. Hovedmenuen er et <details>-element, som dets <summary> åbner og lukker, og skabelonens kommentar siger, at browseren ejer den åbne tilstand og knapsemantikken, uden script.

Hvor det går galt

  • En klikbar boks erstatter elementet. En <div> eller <span> med en klikhandler svarer på en mus og ikke ret meget andet: den får intet fokus, ignorerer mellemrumstasten og Enter og bliver annonceret som almindelig tekst. role="button" retter kun annonceringen; fokus og taster skal stadig skrives i hånden.
  • Et link gør en knaps arbejde eller omvendt. Et link, der sletter en post, kan åbnes i en ny fane eller gemmes som bogmærke, så sletningen bliver gentaget eller tabt af syne. En knap, der kun navigerer, kan ikke åbnes i en ny fane og har ingen adresse at kopiere.
  • En knap uden type sender formularen. Fordi en manglende type sætter knappen i tilstanden Auto, sender en knap som »Tilføj række« eller »Vis adgangskode« inde i en formular hele formularen i det øjeblik, den trykkes. type="button" på hver knap, der ikke skal sende, fjerner overraskelsen.
  • Ikonet er hele etiketten. En skraldespand, en blyant eller en pil betyder noget for den, der tegnede den. Uden et tilgængeligt navn læser skærmlæseren et filnavn, et symbolnavn eller bare »knap«. Et synligt ord er bedst; hvor der ikke er plads til et, udfylder et tilgængeligt navn, der angiver handlingen, hullet.
  • En skjult eller deaktiveret knap bruges som sikkerhed. At fjerne knappen fra siden stopper kun ærlige brugere; forespørgslen bag den kan stadig sendes, og serveren må selv afgøre, om denne konto må gøre dette.

Læs mere

Ordliste