När vi bygger moderna, dynamiska webbapplikationer strävar vi ofta efter en sömlös användarupplevelse. Vi använder asynkrona anrop för att spara formulär, lägga till varor i en kundvagn eller hämta in nytt data utan att ladda om sidan. Visuellt är detta fantastiskt – en liten grön ruta dyker kanske upp med texten “Dina ändringar har sparats!”.

Men vad händer för de användare som inte ser skärmen och förlitar sig på skärmläsare? Ofta: ingenting alls.

Detta glapp i tillgängligheten adresserades specifikt i WCAG 2.1 genom riktlinjen 4.1.3 Status Messages (Statusmeddelanden). Låt oss titta på hur vi som utvecklare kan koda bort detta problem och skapa en inkluderande upplevelse för alla.

Problemet med tysta uppdateringar

Föreställ dig att du navigerar på en sida med hjälp av tangentbordet och en skärmläsare. Du fyller i ett komplext formulär, trycker på “Spara”, och… tystnad. Sidan laddades inte om. Du vet inte om sparningen lyckades, om ett nätverksfel inträffade eller om du missade ett obligatoriskt fält.

För en seende användare förmedlas statusen ofta via förändringar i gränssnittet (färger, ikoner, nya textblock). Om skärmläsaren inte uttryckligen tillsägs att något har förändrats, kommer den inte att läsa upp den nya informationen förrän användaren aktivt navigerar till just det elementet.

Lösningen: ARIA Live Regions

För att uppfylla WCAG 2.1 (nivå AA) måste statusmeddelanden kunna presenteras av assisterande teknik utan att de får fokus. Lösningen stavas WAI-ARIA, och mer specifikt attributet aria-live samt specifika roller (role).

När du märker upp en container med en “live region” instruerar du skärmläsaren att hålla ett öga på detta element och läsa upp innehållet när det förändras.

Exempel 1: Ett icke-tillgängligt statusmeddelande

Här är ett klassiskt exempel på hur det ofta ser ut. Meddelandet blir synligt via JavaScript (t.ex. genom att ta bort klassen .hidden), men skärmläsaren noterar det inte.

<div id="notification-area" class="hidden error-text">
    Ett fel uppstod vid anslutning till databasen.
</div>

Exempel 2: Det tillgängliga alternativet

Genom att lägga till role="status" eller aria-live="polite" gör vi webbläsaren uppmärksam på att uppdateringar här är viktiga.

<div role="status" aria-live="polite" id="notification-area">
    Dina ändringar har sparats!
</div>

Vid mer kritiska meddelanden (exempelvis sessionstidsutloggning eller allvarliga serverfel) vill vi avbryta användaren direkt. Då använder vi role="alert" eller aria-live="assertive".

<div role="alert" aria-live="assertive" id="error-area">
    Ett fel uppstod vid anslutning till databasen.
</div>

3 Snabba tips för implementation

  • Rendera containern från start: Lägg in din aria-live-container i HTML-koden redan när sidan laddas, även om den är tom. Om du injicerar hela div:en samtidigt som innehållet, missar vissa äldre skärmläsare att läsa upp det.
  • Använd “polite” som standard: Om du använder assertive för ofta blir upplevelsen väldigt ryckig och frustrerande för användaren. Spara assertive till varningar som kräver omedelbar handling.
  • Töm meddelandet: När ett meddelande inte längre är relevant, se till att rensa innehållet i DOM:en, annars riskerar det att läsas upp igen vid fel tillfälle.

Att bygga dynamiska och snabba gränssnitt behöver inte betyda att vi bygger bort tillgängligheten. Med några enkla HTML-attribut säkerställer vi att vår arkitektur fungerar för alla.

Källor och fördjupning

Vill du läsa mer om de exakta specifikationerna och hur du testar dina statusmeddelanden? Här är de officiella resurserna: