Identifisering av feil

Silktide undersøker obligatoriske skjemafelt som ser ut til å bruke egendefinert validering i stedet for nettleserens innebygde kontroll, og varsler når det ikke finnes noen tydelig måte for feilmeldingen å nå personer som bruker hjelpemiddelteknologi.

Hvorfor dette er viktig

Når et skjema avviser et ugyldig svar, ser seende brukere vanligvis en rød ramme eller en melding nær feltet. En -bruker får ikke noe av dette med mindre siden eksponerer feilen i koden: Skjemaet nekter ganske enkelt å sendes inn, uten noen forklaring på hva som gikk galt eller hvor. Resultatet er et skjema som i stillhet stenger noen besøkende ute.

Nettlesere leser automatisk opp sine egne innebygde valideringsmeldinger. Risikoen oppstår når en side slår av dette eller erstatter det med sin egen validering, og glemmer å koble erstatningen til .

Slik løser du det

Gi hvert egendefinert validert felt en programmatisk vei for feilmeldingen ved hjelp av :

<!-- Problem: egendefinert validering uten en tilgjengelig feilkanal -->
<form novalidate>
  <input type="text" required>
  <span class="error">Skriv inn navnet ditt</span>
</form>

<!-- Løsning: Feltet peker på feilmeldingen -->
<form novalidate>
  <input type="text" required aria-describedby="name-error">
  <span id="name-error" class="error">Skriv inn navnet ditt</span>
</form>

Én av disse er nok til å bestå kontrollen:

aria-errormessage på feltet, som peker på elementet du fyller med feilteksten (sett aria-invalid="true" når feilen vises).
aria-describedby på feltet, som peker på meldingselementet.
En inne i skjemaet – et element med role="alert", role="status" eller aria-live – som valideringen din skriver feiltekst inn i.

Alternativt kan du fjerne tilpasningen og la nettleserens innebygde validering rapportere feil, noe som er tilgjengelig som standard.

Slik tester Silktide dette

Finn synlige obligatoriske felt – inndatafelt, tekstområder og nedtrekksmenyer – som er merket med required eller aria-required="true".
Behold bare felt med tegn på at nettleserens innebygde validering omgås eller erstattes: Skjemaet har novalidate, en sendekontroll har formnovalidate, feltet er merket med aria-invalid, det bruker aria-required uten det innebygde required-attributtet, eller feltet eller skjemaet har henvisninger til egendefinert validering (for eksempel feilrelaterte attributter eller beholdere for feilmeldinger).
For hvert slikt felt ser vi etter en tilgjengelig feilkanal: en gyldig aria-errormessage-referanse, en gyldig aria-describedby-referanse eller en live-region i skjemaet.
Varsle om felt som ikke har noen av delene. Dette er et varsel, ikke en bekreftet feil, fordi valideringsatferd under kjøring ikke kan observeres fullstendig fra sidens kode.

Feilsøking

Feilene mine blir lest opp riktig

Kontrollen ser etter strukturen som gjør opplesing mulig, ikke selve opplesingen. Hvis rammeverket ditt setter inn en live-region eller ARIA-referansene først når en feil oppstår, viser den innlastede siden ingen kanal, og feltet flagges. Hvis du legger til det (tomme) meldingselementet og referansen på forhånd, løser dette problemet og er også mer robust.

Det refererte meldingselementet finnes ikke ennå

Referanser må peke på elementer som finnes på siden. En aria-describedby som peker på en ID som først opprettes senere, regnes som ingen kanal.