Share
Dette er det siste prinsippet vi skal se på. I bred grad sier det at innholdet og navigasjonen på nettstedet må være forståelig. Mens ansvaret for å implementere mange av disse anbefalingene ligger i plugin eller temaets sluttbruker (eller den som publiserer innholdet), er det anbefalinger som utviklerne av disse pluginene og temaene kan implementere.
Den første retningslinjen sier at innholdet skal være "lesbart og forståelig". Mange anbefalinger vedrører innholdets leseinnhold, og bruken av uvanlige ord, forkortelser og akronymer, hvorav ingen er relevante for utviklere.
En anbefaling vi kan implementere er at det menneskelige språket på nettsiden skal kunne identifiseres programmatisk. For å oppnå dette bør språket spesifiseres på element, via lang Egenskap. I tillegg dir Attributt skal brukes til å indikere om innholdet er høyre til venstre.
WordPress gjør dette enkelt ved å tilby language_attributes (), som skriver ut de nødvendige egenskapene. I header.php av temaet ditt:
>
De language_attributes () funksjonen setter nettstedets språk og, om nødvendig, retning, og filtrerer utdataene, slik at plugins (for eksempel flerspråklige programtillegg) forandrer attributten etter behov.
Den andre retningslinjen sier at et nettsted skal presenteres og oppføre seg på en forutsigbar måte. Mange anbefalinger kan bli oppfylt ved å sikre at HTML-oppslaget av temaet er godt strukturert og logisk. I kombinasjon med det er mange "ikke gjør" s-anbefalinger mot å gjøre endringer som forstyrrer den naturlige og logiske oppførselen til en nettside.
Vi nevnte ikke å bruke tabindex i den fjerde artikkelen i denne serien ("Operable"). Denne anbefalingen bygger på det for å angi at når et objekt mottar fokus, bør det ikke betraktes som en utløser for noen endring av sidens tilstand.
For eksempel bør et skjema mottakende fokus ikke føre til at skjemaet sendes inn, og et lenkeopptaksfokus bør ikke føre til at koblingen aktiveres. Dette er ikke å si at verktøytipsene, eller i navigasjonsmenyene, bør undermenyer ikke vises når det aktuelle elementet mottar fokus. Disse eksemplene utgjør ikke en endring av staten. Løst snakkes kan du likestille ideene til et element som mottar fokus og et element som svever over.
Du bør unngå å fjerne fokus fra et element som mottar det. For eksempel bør du aldri gjøre noe som følger:
Accentsconagua
$ ('a'). på ('fokus', funksjon () $ (dette) .blur (););Som standard er de eneste skjemaene som er relevante for temautviklere, innloggings- / registrerings-, søk- og kommentarformularene. Av disse blir bare de to sistnevnte vanligvis gitt oppmerksomhet av temautvikleren. Siden søkeskjemaer aldri resulterer i en "feil", fokuserer vi i denne delen på kommentarskjemaer.
WordPress gjør en veldig god jobb med å varsle brukere om en feil, og informerer dem nøyaktig hva den feilen er. Det gjør det imidlertid ved å la brukerne forlate den opprinnelige siden, og presentere dem med en feilsøkingsside.
Hvis brukerne kommer tilbake til den opprinnelige siden, vil skjemaet ha mistet fokus, og de må finne det igjen. En bedre løsning ville være å hindre brukere fra å sende inn skjemaet til de har fylt ut skjemaet riktig. Men når du gjør dette, er det viktig å formidle til brukerne at den oppgitte verdien ikke er gyldig, ellers vil du i hovedsak ha fanget dem.
Det er mange klient-side valideringskript tilgjengelig, og det er også veldig enkelt å bygge ditt eget enkle valideringsskript. Det som er viktig er:
role = "alert".Her er et enkelt eksempel, basert på WebAIMs eget eksempel på tilgjengelig form validering, (som jeg oppfordrer deg til å lese), som legger til en feilmelding hvis navnefeltet er tomt.
jQuery (dokument) .ready (funksjon ($) $ ('# author'). på ('uskarphet', funksjon (e) var verdi = $ (dette) .val ($ ('# author-error'). lengde> 0) $ ('# author-error'). fjern (); $ ('') .insertAfter ($ (' # author ')) .text (' Navn feltfeil: Vennligst oppgi et navn '); ellers hvis ($ ('# author-error'). lengde> 0) $ ('# author-error'). fjern (); ); );WebAIM-eksemplet forhindrer også at brukerne forlater feltet ugyldig, og returnerer dem til feltet for å rette feilen. Hvis du gjør det, vil jeg anbefale deg ikke returner brukeren til feltet hvis verdien er tom, ellers vil du frustrere brukere som ved et uhell har gitt feltfokus, men har ikke tenkt å sende inn skjemaet.
Som nevnt tidligere i denne serien, bør du ikke stole på farge eller posisjon alene for å formidle mening. I denne sammenheng bør feilmeldinger åpenbart være så fra teksten, som det skulle være feltet (e) som de relaterer til.
Temaer skal bare brukes comment_form () for å vise kommentarskjemaene, og dette håndterer etiketter på en tilgjengelig måte. Tilsvarende trenger ikke standard søkeskjema lenger arbeid. Men når du tilpasser eller styler disse skjemaene, bør du:
Etiketter må alltid være synlige. Spesielt betyr dette at plassholdere ikke utgjør en etikett, og bør ikke brukes som søk. Det er flere grunner til dette:
Hvis et skjemafelt krever ytterligere instruksjoner, kan disse leveres etter feltet, men likevel eksplisitt knyttet til det ved å bruke aria-describedby Egenskap. Innholdet av elementet referert av dette attributtet blir lest ut etter feltets etikett.
Som et eksempel fra W3C nettsted:
Du bør imidlertid være oppmerksom på at det er inkonsekvent støtte for dette blant skjermleserne.
Felt som kreves, skal merkes som sådan med aria-required = "true" Egenskap. Standard WordPress kommentarformet som produsert av comment_form () håndterer allerede dette, så det er ingen handling du trenge å ta her. Du bør imidlertid være oppmerksom på dette hvis du velger å tilpasse kommentarformene.
Denne artikkelen konkluderer med vår grove temautviklerguide til W3C-tilgjengelighetsprinsippene, og hvordan de kan implementeres. I den siste artikkelen i denne serien ser vi på noen enkle måter å gå enda lenger, og aktivt oppfordre og hjelpe sluttbrukeren til temaet vårt (eller plugin) for å produsere tilgjengelig innhold.
