Share
Dit is het laatste principe waar we naar zullen kijken. In grote lijnen wordt gesteld dat de inhoud en de navigatie van de site begrijpelijk moeten zijn. Hoewel de verantwoordelijkheid voor het implementeren van veel van deze aanbevelingen ligt bij de 'eindgebruiker' van de plug-in of het thema (of degene die de inhoud publiceert), zijn er aanbevelingen die de ontwikkelaars van die plug-ins en thema's kunnen implementeren.
De eerste richtlijn stelt dat inhoud "leesbaar en begrijpelijk" moet zijn. Veel aanbevelingen hebben betrekking op het leesniveau van de inhoud en het gebruik van ongebruikelijke woorden, afkortingen en acroniemen, die geen van alle relevant zijn voor ontwikkelaars.
Een aanbeveling die we kunnen implementeren, is dat de menselijke taal van de webpagina programmatisch geïdentificeerd moet kunnen worden. Om dit te bereiken, moet de taal worden opgegeven op de element, via de LANG attribuut. Bovendien de dir kenmerk moet worden gebruikt om aan te geven of de inhoud van rechts naar links is.
WordPress maakt dit eenvoudig door te bieden language_attributes (), die de vereiste kenmerken afdrukt. In de header.php van je thema:
>
De language_attributes () functie stelt de taal van de site en, indien nodig, richting in, en filtert de uitvoer, waardoor plug-ins (bijvoorbeeld meertalige plug-ins) het attribuut naar wens kunnen wijzigen.
De tweede richtlijn stelt dat een website moet worden gepresenteerd en zich op een voorspelbare manier moet gedragen. Aan veel van de aanbevelingen kan worden voldaan door ervoor te zorgen dat de HTML-mark-up van het thema goed gestructureerd en logisch is. In combinatie met dat zijn tal van "niet doen" s-aanbevelingen tegen het maken van wijzigingen die het natuurlijke en logische gedrag van een webpagina verstoren.
We noemden het niet gebruiken tabindex in het vierde artikel van deze serie ("Opereerbaar"). Deze aanbeveling bouwt voort op dat om te stellen dat wanneer een item focus krijgt, dit niet als trigger voor een wijziging van de status van de pagina moet worden beschouwd.
Bijvoorbeeld, een knop voor het ontvangen van formulierknoppen mag dat formulier niet verzenden en een link voor het ontvangen van de ontvangst mag niet tot gevolg hebben dat die link wordt geactiveerd. Dit is niet om dat tooltip te zeggen of, in het geval van navigatiemenu's, zouden submenu's niet moeten verschijnen wanneer het juiste item focus krijgt. Die voorbeelden vormen geen staat van verandering. Losjes gezegd kun je de ideeën van een item dat focus ontvangt en een item dat zweeft, gelijkstellen.
U moet voorkomen dat de focus wordt verwijderd van een element dat de focus krijgt. U zou bijvoorbeeld nooit iets als het volgende moeten doen:
Accentsconagua
$ ('a'). on ('focus', function () $ (this) .blur (););Standaard zijn de enige formulieren die relevant zijn voor thema-ontwikkelaars de aanmeldings- / registratie-, zoek- en reactieformulieren. Van deze krijgen alleen de laatste twee typisch aandacht van de ontwikkelaar van het thema. Omdat een zoekformulier nooit resulteert in een 'fout', richten we ons in dit gedeelte op opmerkingen.
WordPress kan gebruikers heel goed op de hoogte stellen van een fout en hen precies laten weten wat die fout is. Dit doet het echter door gebruikers toe te staan de oorspronkelijke pagina te verlaten en ze een 'doodlopende' foutpagina te presenteren.
Als gebruikers terugkeren naar de oorspronkelijke pagina, heeft het formulier geen focus meer en moeten ze het opnieuw vinden. Een betere oplossing is om te voorkomen dat gebruikers het formulier verzenden voordat ze het formulier correct hebben ingevuld. Wanneer u dit doet, is het echter van essentieel belang aan gebruikers door te geven dat de ingevoerde waarde niet geldig is, anders zult u ze in essentie gevangen hebben.
Er zijn tal van client-side validatiescripts beschikbaar en het is ook heel eenvoudig om uw eigen eenvoudige validatiescript te maken. Wat belangrijk is, is:
role = "alert".Hier is een eenvoudig voorbeeld, gebaseerd op WebAIM's eigen voorbeeld van toegankelijke formuliervalidatie (die ik u aanmoedig te lezen), die een foutmelding toevoegt als het naamveld leeg is.
jQuery (document) .ready (function ($) $ ('# author'). on ('vervagen', functie (e) var value = $ (this) .val (); if (! value) if ($ ('# author-error'). length> 0) $ ('# author-error'). remove (); $ ('') .insertAfter ($ (' # author ')) .text (' Naamveldfout: geef een naam op '); else if ($ ('# author-error'). length> 0) $ ('# author-error'). remove (); ); );Het WebAIM-voorbeeld voorkomt ook dat gebruikers het veld ongeldig laten en retourneert ze naar het veld om de fout te corrigeren. Als je dat doet, zou ik je aanraden niet doen stuur de gebruiker terug naar het veld als de waarde leeg is, anders frustreert u gebruikers die per ongeluk de veldfocus hebben gegeven, maar niet van plan bent het formulier in te dienen.
Zoals eerder in deze serie is opgemerkt, moet u niet alleen op kleur of positie vertrouwen om betekenis over te brengen. In dit verband zouden foutmeldingen duidelijk zo uit de tekst moeten komen, evenals de velden waarop ze betrekking hebben.
Thema's zouden alleen moeten gebruiken comment_form () voor het weergeven van de opmerkingenformulieren en dit handelt labels op een toegankelijke manier af. Ook het standaard zoekformulier heeft geen verder werk nodig. U moet echter bij het aanpassen of stylen van deze formulieren:
Labels moeten te allen tijde zichtbaar zijn. Concreet houdt dit in dat tijdelijke aanduidingen geen label vormen en niet als zoekopdracht mogen worden gebruikt. Daar zijn verschillende redenen voor:
Als een formulierveld verdere instructies vereist, kunnen deze achter het veld worden geleverd, maar er nog steeds expliciet aan worden gekoppeld met behulp van de aria-describedby attribuut. De inhoud van het element waarnaar dit kenmerk verwijst, wordt na het veldlabel uitgelezen.
Als voorbeeld van de W3C-website:
U moet zich er echter van bewust zijn dat dit onder schermlezers inconsistent is.
Velden die vereist zijn, moeten als zodanig worden gemarkeerd met de aria-required = "true" attribuut. Het standaard WordPress comment-formulier zoals geproduceerd door comment_form () behandelt dit al, dus er is geen actie voor u nodig hebben om hier te nemen. Houd hier echter rekening mee als u de opmerkingen wilt aanpassen.
Dit artikel besluit onze ruwe gids over themaontwikkelaars voor de W3C-toegankelijkheidsprincipes en hoe deze kunnen worden geïmplementeerd. In het laatste artikel in deze serie zullen we enkele eenvoudige manieren bekijken om nog verder te gaan en de eindgebruiker van ons thema (of plugin) actief aanmoedigen en helpen om toegankelijke inhoud te produceren.
