Det lilla frågetecknet

Som senior frontend-utvecklare med särskild kompetens inom tillgänglighet på webben stöter jag konstant på olika situationer där något som ser enkelt ut faktiskt inte är så enkelt. I den här artikeln ska vi bygga ett litet frågetecken.

→ Grupper och roller som kan dra nytta av att läsa artikeln: frontend-utvecklare, designers, beställare, produktägare, projektledare.

Före vi börjar

Denna text är alldeles för lång. Sorry för det. Vet inte vem som ska orka läsa hela. Men jag hade mycket att säga. Om det blir för tekniskt, hoppa ner och läs summeringen i slutet.

Kapitel 1: Design

Denna design är vanligt förekommande.

Bilden föreställer ett vanligt formulärfält, alltså en input med en label (etikett). Det finns ett frågetecken som är placerat inne i fältet längst till höger. Det första kravet som spontant dyker upp är: användaren ska kunna hovra frågetecknet och då ska en pratbubbla dyka upp med text i.

Syftet är att webbplatsen vill kommunicera något särskilt, något som användaren behöver veta för just detta formulärfält.

Min grundtes och go-to är att det nästan alltid finns ett enklare sätt att göra design på. Utvecklare bör ifrågasätta design ibland och föreslå annat. Mitt spontana förslag skulle vara: om något ska kommuniceras som rör formulärfältet, placera budskapet direkt i label (texten ovanför fältet).

Det skulle innebära:

• Utvecklingstid: 1/10
• Interaktion som behövs från användare: ingen
• Tillgänglighet: 10/10

Här kunde vi varit klara.

Men — för artikeln skull antar vi att den fiktiva kunden inte godkände förslaget. Det var ju synd. Vi fortsätter.

→ Värt att nämna

Saker som placeras långt ut till höger kan missas. Personer med synnedsättning zoomar ofta in nära för att läsa, då kan frågetecknet hamna utanför bild.

→ Tips!

Vill du lära dig mer om inputs och labels? Se min video “Back 2 Basics” från t12t:s meetup [YouTube].

Kapitel 2: Utveckling

Utveckling rakt från den spontana kravspecifikationen

Användaren måste kunna hovra med mus (föra musen över) för att ta del av texten i pratbubblan.

Vi låtsas för stunden som att det inte saknas krav i specifikationen, så låt oss bygga detta rakt upp och ner.

Vi behöver två delar: frågetecknet och pratbubblan. Lite html och css:

<div class="help">
  ?
  <div class="info">
    Viktig information lorem ipsum
  </div>
</div>
<!-- Här var det många div:ar, vi återkommer till det. -->

.help {
  // Styling för cirkel och frågetecken
}
.info {
  // Styling för pratbubbla
  display: none;
}
.help:hover .info {
  // Hovring visar pratbubblan
  display: block;
}

Många utvecklare skulle nog lämna det där och gå vidare. Men denna lösning har många brister. Till exempel: om man inte kan hovra? Alla kan faktiskt inte använda mus. Och det går ju inte att hovra på en mobil eller surfplatta 🙃

Tilläggskrav 1:

Användaren måste kunna klicka med mus eller trycka med fingret för att ta del av texten i pratbubblan.

Här kan man lätt tro att vi behöver Javascript. Men tilläggskrav 1 löser sig automatiskt när vi löst tilläggskrav 2. Så pausa den.

Tilläggskrav 2:

Frågetecknet måste kunna fokuseras av personer som navigerar med tangentbord.

Fokusering (inte exakt samma som aktivering) betyder att användaren valde att sätta elementet i fokus. Vi skriver om css så att pratbubblan visas på både hover och fokusering av frågetecknet.

.help:hover .info,
.help:focus .info {
  display: block;
}

En grej bara, en div kan inte fokuseras. Den som är ny in i a11y-världen har säkert hittat tabindex-attributet. Med tabindex är det möjligt att tvinga element som egentligen inte är fokuserbara att bli fokuserbara.

<div class="help" tabindex="0">
  [...]
</div>

Men — när ett tabindex behövs är det ofta ett tecken på att något är skevt. Div-element missbrukas något kopiöst. Nej, vi behöver ett riktigt element. En knapp är det mest lämpliga eftersom användaren ska kunna aktivera det. Fokusering av knappar finns redan inbyggt i button-elementet.

<button class="help">
  [...]
</button>

→ Lästips!

Lär dig grunderna i semantisk html [Web Dev]

Tilläggskrav 3

Frågetecknet måste ha tillräcklig klickyta.

När vi ändå pratar om klickbarhet måste vi se till att frågetecknet kan klickas på utan problem. Det ska inte vara svårt att pricka rätt med muspekare eller finger. Vi justerar detta med css.

.info {
  height: 44px;
  width: 44px;
}
/* Kan åstadkommas på olika sätt */

Tilläggskrav 4

Frågetecknet måste ha ett begripligt namn i hjälpmedel.

Alla knappar exponeras för hjälpmedel, som till exempel skärmläsare. Då kan knappen inte heta ”?”, det vore ju jättekonstigt. För enkelhetens skull kallar vi knappen för ”Hjälp för fält X”.

Vi lägger därför till en visuellt dold text för hjälpmedel, och passar samtidigt på att byta ut frågetecknet mot en ikon.

Utöver dessa åtgärder markerar vi med attributet aria-hidden så att själva hjälptexten inte exponeras. Den texten kan ju vara lång — föreställ dig följande beskrivning för knappen: ”Hjälp för fält X. Samtliga passager med bilen under en kalendermånad sammanställs i ett skattebeslut även om du kört med bilen i både Stockholm och Göteborg. Knapp”.

<button class="help">
  <img src="img/help.svg" alt="">
  <span class="visually-hidden">Hjälp för fält X</span>
  <div class="info" aria-hidden="true">
    Viktig information lorem ipsum
  </div>
</button>

→ Värt att nämna

Det finns nackdelar med visuellt dolda namn och etiketter. Personer som använder röststyrning kan ha stora problem med att lista ut vad knappar med endast ikoner heter, och kan därför ha svårt att aktivera länkar och knappar.

Tilläggskrav 5

Personer som använder hjälpmedel måste kunna aktivera frågetecknet och få återkoppling med ljud.

Personer som kan hovra, fokusera eller klicka på frågetecknet kommer nu att se info-texten direkt. Men om personen inte kan se? De som använder hjälpmedel kommer att kunna hitta och aktivera knappen, och något måste hända när knappen aktiveras, annars kommer den att upplevas som trasig. Och vad vore mer lämpligt än att texten som ligger i pratbubblan läses upp för hjälpmedel?

Här använder jag ett mönster som kallas ”announcer”. Det är en tom och dold behållare som bevakas med attributet ”aria-live”. All text som trycks in i behållaren kommer att läsas upp. Announcern behöver bara några få rader Javascript och den skrivs modulärt så att den kan användas för flera olika slags situationer på webbplatsen.

Mönstret för Javascriptet, förenklat: klick på frågetecknet → tryck in info-texten i announcern → uppläsning händer.

<span class="js-announcer visually-hidden" aria-live="polite"></span>

<button class="help" onclick="announce(this)">
  [...]
  <div class="info" aria-hidden="true" data-announcement>
    [...]
  </div>
</button>

const announce = (el) => {
  const announcer = document.querySelector(".js-announcer");
  let announcement = el.querySelector("[data-announcement]").innerText;
  announcer.innerHTML = announcement;
}
/* Det finns många olika sätt att skriva Javascript på :) */

→ Lär dig mer om Aria!

En guide till WAI-ARIA [Smashing Magazine]

Tilläggskrav 6

Text som skrivs i fältet får inte döljas.

Frågetecknet ligger placerat i ett eget lager ovanpå formulärfältet. I de fall som användaren skriver något långt behöver vi se till att det inte döljs bakom frågetecknet, eller krockar.

Det innebär ytterligare justeringar, på formulärfältet.

.input:has(+.help) {
  padding-right: 44px; // Eller lämpligt värde
}

Summering

• Utvecklingstid: 8/10
• Interaktion som behövs från användare: hover, fokusering eller klick
• Tillgänglighet: 6/10

Ytterligare aspekter att ta hänsyn till!

Ogiltig html

Det finns olika sätt att koda labels och inputs. Jämför dessa varianter, bägge är giltiga:

Exempel 1:
<label>
  <input type="text">
  Fält X
</label>

Exempel 2:
<label for="x">Fält X</label>
<input id="x" type="text">

Men pass på:

Exempel 1:
<label>
  <input type="text">
  Fält X
  <!-- Placeras knappen här, blir html ogiltigt -->
</label>

Ytor som krockar

Vissa typer av formulärkontroller har redan inbyggda funktioner eller symboler till höger:

• Sökfält: det finns ett rensa-kryss.
• Nummerfält: det finns pilknappar för att öka och minska värdet.
• Datumfält: det finns en ikon som öppnar en kalenderruta.
• Rullgardinsmeny har en pil som pekar neråt.

Hur ska frågetecknet och dessa inbyggda varianter leva på samma yta? Är det verkligen bara textfält som kan ha viktig information? Detta blir ytterligare en diskussionspunkt.

Artikelns budskap

Vad jag lärt mig genom åren: utgå ifrån att ingen har kravställt uppgiften utifrån olika användares behov, eller att någon har problematiserat tillräckligt mycket. Vi behöver därför lägga till extra tid för att fundera ut och skriva krav, och tid för testning för att säkerställa att alla olika scenarios verkligen fungerar.

Allt som oftast hör jag att det inte finns tid för tillgänglighet. Nya funktioner är viktigare, buggfixar är viktigare. Jag får berättat för mig att tillgänglighet är krångligt och dyrt. Det är något ”vi tar sen”.

Det blir bara krångligt och dyrt om:

• Designen är komplicerad → Våga gör en enkel design!
• Man tvingar html-element att göra saker de inte är byggda för → Använd semantisk html!
• Teamet inte pratar med varandra om att göra tillgängliga lösningar → Problematisera och diskutera före utveckling!
• Man väntar till senare → Ta det direkt!

Disclaimer!

Det finns många sätt att göra rätt på. Detta är min egen approach som kändes naturlig för mig. Men det finns naturligtvis andra sätt att lösa det på.

Till exempel, om vi pratar lite om ordningen som delarna ligger i: labeln, fältet och sedan frågetecknet. Jag har åsikten att information som är relevant för att fylla i ett fält, bör komma före fältet ska fyllas i (inte efter).

Det finns ett nytt och intressant element på väg in: popover. Den kan vara värd att experimentera med för just denna design. Den har just nu (2023) endast stöd för Chrome och Edge.