Identifiering av fel

Silktide granskar obligatoriska formulärfält som verkar använda anpassad validering istället för webbläsarens inbyggda kontroll och varnar när det inte finns något uppenbart sätt för felmeddelandet att nå personer som använder hjälpmedel.

Varför detta är viktigt

När ett formulär avvisar ett ogiltigt svar ser seende användare vanligtvis en röd kontur eller ett meddelande nära fältet. En användare får inget av detta om inte sidan exponerar felet i koden: formuläret vägrar helt enkelt att skickas, utan någon förklaring av vad som gick fel eller var. Resultatet blir ett formulär som i tysthet stänger ute vissa besökare.

Webbläsare läser automatiskt upp sina egna inbyggda valideringsmeddelanden. Risken uppstår när en sida stänger av detta eller ersätter det med sin egen validering och glömmer att koppla ersättningen till .

Så åtgärdar du det

Ge varje fält med anpassad validering en programmatisk väg för felmeddelandet med hjälp av :

<!-- Problem: anpassad validering utan en tillgänglig felkanal -->
<form novalidate>
  <input type="text" required>
  <span class="error">Ange ditt namn</span>
</form>

<!-- Åtgärd: fältet hänvisar till sitt felmeddelande -->
<form novalidate>
  <input type="text" required aria-describedby="name-error">
  <span id="name-error" class="error">Ange ditt namn</span>
</form>

Ett av följande räcker för att uppfylla kontrollen:

aria-errormessage på fältet, som pekar på det element där du fyller i feltexten (ange aria-invalid="true" när felet visas).
aria-describedby på fältet, som pekar på meddelandeelementet.
En i formuläret – ett element med role="alert", role="status" eller aria-live – där valideringen skriver in feltexten.

Alternativt kan du ta bort anpassningen och låta webbläsarens inbyggda validering rapportera fel, vilket är tillgängligt som standard.

Så testar Silktide detta

Hitta synliga obligatoriska fält – inmatningsfält, textområden och listrutor som är märkta med required eller aria-required="true".
Behåll endast fält där det finns tecken på att webbläsarens inbyggda validering kringgås eller ersätts: formuläret har novalidate, ett skickandekontroll har formnovalidate, fältet är märkt med aria-invalid, det använder aria-required utan det inbyggda attributet required, eller fältet eller formuläret har ledtrådar för anpassad validering (till exempel felrelaterade attribut eller behållare för felmeddelanden).
För varje sådant fält letar vi efter en tillgänglig felkanal: en giltig aria-errormessage-referens, en giltig aria-describedby-referens eller en live-region i formuläret.
Varna för fält som saknar alla dessa. Detta är en varning snarare än ett bekräftat fel, eftersom valideringsbeteendet vid körning inte kan observeras fullständigt från sidans kod.

Felsökning

Mina fel läses upp korrekt

Kontrollen letar efter den struktur som gör uppläsning möjlig, inte efter själva uppläsningen. Om ditt ramverk infogar en live-region eller ARIA-referenser först när ett fel inträffar, visar den inlästa sidan ingen kanal och fältet markeras. Om du lägger till det (tomma) meddelandeelementet och referensen från början löses problemet. Det är också mer robust.

Det refererade meddelandeelementet finns inte ännu

Referenser måste peka på element som finns på sidan. En aria-describedby som pekar på ett id som skapas först senare räknas som att det saknas en kanal.