Tillgängliga felmeddelanden: Den fullständiga guiden

De dolda kostnaderna för meningslösa fel

Du har säkert stött på det: ett formulär som visar meddelandet ”Ogiltig inmatning” efter att du noggrant har skrivit in ditt telefonnummer. En kassa där ett fält markeras med rött utan någon förklaring. Ett felmeddelande med kryptiska koder som bara förstås av den utvecklare som skrev det klockan 23 på en fredagskväll.

Det här är inte bara små irritationsmoment i användarupplevelsen. För de 1,3 miljarder människor världen över som lever med någon form av funktionsnedsättning kan dåligt utformade felmeddelanden göra en digital produkt helt oanvändbar. För användare av skärmläsare är ett felmeddelande som bara byter färg osynligt. För användare med kognitiva funktionsnedsättningar kan en vag enradare som ”Något gick fel” vara förlamande. För någon som är beroende av röststyrning kan ett formulärfel som plötsligt tar fokus bryta hela arbetsflödet.

Tillgängliga felmeddelanden handlar inte om att lägga till ARIA-attribut i efterhand. De kräver ett genomtänkt språk, en lämplig DOM-struktur, visuella och icke-visuella signaler samt en djup respekt för mångfalden bland dina användare. Den här guiden går igenom alla aspekter av hur man får till det rätt – från WCAG-kriterier och principer för textförfattande till praktiska kodmönster.

Vad standarden faktiskt kräver

WCAG 2.2, som publicerades i oktober 2023, är den nuvarande standarden för webbtillgänglighet och utgångspunkten för de flesta rättsliga ramverk – däribland EU:s direktiv om webbtillgänglighet, den brittiska lagen om jämlikhet (Equality Act) och den amerikanska lagen ADA. Flera av framgångskriterierna gäller direkt för felmeddelanden. Det är viktigt att förstå bokstaven i varje kriterium innan man kan gå vidare och tillämpa dem i praktiken.

Vad kännetecknar ett bra felmeddelande?

Ett välformulerat felmeddelande består av fyra komponenter som är absolut nödvändiga. Var och en av dem fyller ett specifikt syfte – tar du bort någon av dem försämras upplevelsen för en del av dina användare.

Språkramverket: Sex regler för felkopiering

Felmeddelanden är en form av UX-text. De är inte loggutskrifter. De är inte anteckningar för utvecklare. De är mänsklig kommunikation i en stressad situation – skrivna för någon som just har misslyckats med något och behöver lyckas.

Verkliga felmeddelanden: före och efter

Skillnaden mellan ett svårbegripligt och ett begripligt felmeddelande är ofta bara några ord och två attribut. Dessa jämförelser visar exakt vad som förändras – och varför varje förändring är viktig.

Validering av obligatoriska fält

Formatvalidering (datum)

Lösenordsverifiering

Server-/systemfel

Felkoder och när man ska använda dem

Olika felsituationer kräver olika interaktionsmönster. Att välja fel behållare eller meddelandemekanism är ett av de vanligaste tillgänglighetsproblemen i formulär.

Tvåskiktsmetoden för formulär med flera fält

För formulär med tre eller fler fält räcker det inte med ett enda visningssätt. Både Government Digital Service (GDS) och ARIA Authoring Practices Guide rekommenderar ett system med två nivåer: en felöversikt högst upp i formuläret samt felmeddelanden direkt bredvid varje berört fält.

Kodmönster som fungerar

Att förstå teorin är halva jobbet. Nedan följer produktionsklara mallar för de vanligaste scenarierna, med kommentarer om vilka WCAG-kriterier varje attribut uppfyller.

Validering av fält i realtid

<!-- The label is always present and always linked -->
<div class="field-group">
  <label for="email">
    Email address
    <span class="required-indicator" aria-label="required"> *</span>
  </label>

  <input
    type="email"
    id="email"
    name="email"
    autocomplete="email"
    aria-required="true"
    aria-invalid="true"     <!-- set when invalid -->
    aria-describedby="email-hint email-error"
  />

  <!-- Hint text always shown (WCAG 3.3.2) -->
  <p id="email-hint" class="field-hint">
    We'll send your confirmation here.
  </p>

  <!-- Error message (shown only on error) -->
  <p
    id="email-error"
    class="field-error"
    role="alert"
    aria-live="assertive"
  >
    <!-- inject error text here -->
    Enter a complete email address — for example, [email protected]
  </p>
</div>

Felöversikt (formulär med flera fält)

<!-- Inject this above the form on submission, then focus #error-summary -->
<div
  id="error-summary"
  role="alert"
  aria-labelledby="error-summary-title"
  tabindex="-1"   <!-- allows programmatic focus -->
  class="error-summary"
>
  <h2 id="error-summary-title">
    There are 2 errors. Fix these to continue.
  </h2>
  <ul>
    <li><a href="#email">Email address: enter a complete email</a></li>
    <li><a href="#dob">Date of birth: use DD/MM/YYYY format</a></li>
  </ul>
</div>

<!-- JavaScript: move focus to summary after injection -->
<script>
  const summary = document.getElementById('error-summary');
  summary.focus(); // fires after DOM update
</script>

Dynamiska fel/AJAX-fel (sidan laddas inte om)

När fel returneras asynkront – till exempel från ett API-anrop – kan man inte förlita sig på att de visas automatiskt när sidan laddas. Här är ARIA-mönstret för live-regioner avgörande.

// Set up the live region once on page load (empty, hidden)
// <div id="live-error" role="alert" aria-live="assertive" aria-atomic="true"></div>

async function submitForm(data) {
  try {
    const res = await fetch('/api/save', { method: 'POST', body: data });
    if (!res.ok) throw new Error(await res.text());
    announceStatus('Your changes have been saved.', 'polite');
  } catch (err) {
    announceStatus(
      'We couldn\'t save your changes. Try again or contact support.',
      'assertive'
    );
  }
}

function announceStatus(message, urgency = 'polite') {
  const region = document.getElementById('live-error');
  region.setAttribute('aria-live', urgency);
  // Clear first to re-trigger announcement if same message
  region.textContent = '';
  requestAnimationFrame(() => {
    region.textContent = message;
  });
}

Checklista för granskning av tillgänglighet

Använd denna checklista vid granskning av design, kodgranskning och kvalitetssäkring. Den täcker alla kriterier på nivå A och nivå AA i WCAG 2.2 som är relevanta för felmeddelanden.

Bild och innehåll

Programmatisk annonsering och hjälpmedel

Fokus och tangentbord

Hur vi hamnade här: En kort tidslinje

Felmeddelanden som en spegel av produktens värden

Felmeddelandet är ett av de mest avslöjande ögonblicken i varje digital upplevelse. Det dyker upp just när användaren befinner sig i en stressad situation – när hen har gjort ett misstag eller när något utanför hens kontroll har gått fel. Hur du agerar i det ögonblicket säger allt om hur seriöst du tar inkludering.

En röd ram utan text är inte ett felmeddelande. En kodutskrift är inte ett felmeddelande. Ett vagt ”något gick fel” är inte ett felmeddelande. Ett tillgängligt felmeddelande är ett tydligt, vänligt och konkret meddelande som fungerar för alla – inklusive de 26 % av användarna som har någon form av funktionsnedsättning, de 15 % som förlitar sig på tangentbordsnavigering och de 100 % av användarna som någon gång kommer att stöta på ett fel.

Den goda nyheten är att det kräver mycket lite extra arbete att skapa tillgängliga felmeddelanden om man tar hänsyn till detta redan från början. ARIA-attributen är få. Riktlinjerna för texterna är tydliga. Mönstren är väl etablerade. Det som krävs är en medveten vilja – ett medvetet beslut att testa med hjälpmedel, att skriva för människor istället för system och att se varje fel som en möjlighet att vinna förtroende.

På AIOPSGROUP, ett företag inom valantic-koncernen, utvecklar vi digitala produkter som fungerar för alla. Tillgänglighetsarbete är en integrerad del av vårt designsystem, våra kodgranskningar och vår kvalitetssäkringsprocess – det är inte något som läggs till i efterhand. Om ditt team behöver hjälp med att granska, implementera eller bygga upp ett tillgängligt designsystem från grunden, står vi gärna till tjänst.