Share
In grote lijnen is dit het principe dat uw website moet kunnen zijn veilig genavigeerd voor alle gebruikers. Dit omvat de richtlijn dat uw hele website toegankelijk moet zijn door alleen het toetsenbord te gebruiken. Bovendien moet de manier waarop uw website reageert op gebruikersinvoer (via een toetsenbord of anderszins) voorspelbaar, duidelijk en veilig zijn.
Dit laatste punt heeft voornamelijk betrekking op het voorkomen dat een mogelijk inbeslagname-inducerend kenmerk van uw site standaard wordt uitgeschakeld en dat gebruikers worden gewaarschuwd voordat ze worden ingeschakeld. Dit principe biedt ook richtlijnen om gebruikers voldoende tijd te geven om taken uit te voeren, maar we behandelen het hier niet.
Alleen met een toetsenbord kunnen navigeren en uw site gebruiken, is een van de belangrijkste aspecten van toegankelijkheid. Blinde gebruikers vertrouwen bijna uitsluitend op toetsenborden en mensen met een motorische beperking kunnen moeite hebben met het besturen van een muis en vertrouwen dus ook op toegang tot het toetsenbord. Sommige mensen hebben misschien weinig of geen gebruik van hun handen en vertrouwen op grotere toetsenborden, mondstokken, hoofdstokjes, één schakelaar of Sip 'n' Puff.
U kunt beschrijvingen van deze apparaten vinden op de WebAIM-website, maar ze kunnen allemaal gebruikersinvoer in toetsenbordslagen verwerken. Als uw website niet toegankelijk is via toetsenborden, kunnen alle gebruikers die op deze apparaten vertrouwen uw website niet gebruiken.
Gelukkig is het eenvoudig om je thema of plugin-toetsenbord toegankelijk te maken. Hier zijn enkele belangrijke punten:
Veel thema's zijn afhankelijk van het zweven boven een menu-item om eventuele submenu's te onthullen. Dit is prima, maar over het algemeen zal het submenu dat wel doen niet verschijnen als het bovenliggende menu-item focus heeft (in plaats van zweven). Als u relevante regels dupliceert voor : hover en pas ze toe :focus ook, dit zal je er halverwege brengen: de submenu-items verschijnen als de gebruikerstabbladen in het menu. Zodra de gebruiker echter naar het submenu gaat, verliest het oudermenu de focus en verdwijnt het submenu. Dit kan worden gecorrigeerd met JavaScript. Details hierover en hoe een niet-JavaScript-fallback te bieden, worden behandeld in het volgende artikel van deze serie.
U hoeft niets te doen om 'native' invoer van formulieren (selecteren, invoeren, radio, etc.) toegankelijk te maken voor het toetsenbord. Moet echter elk aspect van uw pagina (inclusief formuliervelden) focus krijgen, het moet mogelijk zijn om er vanaf weg te gaan met alleen een toetsenbord - anders is de gebruiker effectief opgesloten. Dit is normaal gesproken standaard gedrag, dus u moet voorkomen dat u het overschrijft.
Deze richtlijn heeft twee soorten aanbevelingen: vind waar de gebruiker momenteel is is voor de hand liggend, en maken het gemakkelijker om naar waar ze willen gaan te gaan.
Een deel van het volgen van de aanbevelingen om dit te doen omvat iets dat veel thema's al doen: een consistent navigatiemenu op pagina's hebben, de huidige pagina markeren en gebruikers in staat stellen snel te bepalen waar ze zich op de site bevinden (bijvoorbeeld met paneermeel).
Een belangrijk onderdeel van het kunnen gebruiken van een toetsenbord om door een webpagina te navigeren, is om precies te kunnen zien wat er op dat moment focus heeft. Het element dat op dat moment focus heeft, moet zichtbaar anders zijn en te onderscheiden zijn van de rest van de pagina. Om deze reden moet je vermijden schetsen: none; tenzij je een alternatieve styling gaat aanbieden:
a: focus outline: none; achtergrond: # ee7b00; kleur: #fff;
Een ander belangrijk onderdeel van de toegankelijkheid van het toetsenbord is dat tabbing zich voorspelbaar en op een natuurlijke manier gedraagt. Als de focus bijvoorbeeld momenteel een formulierveld is, zou ik verwachten dat het volgende tabblad mij naar het volgende veld in die vorm zou brengen. Als tabben ertoe leidt dat de focus onregelmatig op en neer springt, zal dit de gebruiker frustreren en desoriënteren.
Vermijd het gebruik van tabindex: Met het tabindex-kenmerk kunt u de volgorde waarin elementen worden bereikt, wijzigen door te tabben. Als u echter het advies in artikel 2 van deze serie over de DOM-structuur hebt gevolgd, moet de tabvolgorde de "natuurlijke" volgorde van de pagina weergeven. Hoewel tabindex zijn toepassingen heeft, zijn deze zeldzaam, en het gebruik ervan om een slechte sitestructuur te 'patchen' kan verdere problemen veroorzaken. De beste methode is om te voorkomen dat u tabindex gebruikt en in plaats daarvan uw thema een logische DOM-structuur te laten produceren, waarbij CSS wordt gebruikt om de visuele presentatie te wijzigen.
Schermlezergebruikers zullen vaak tussen koppelingen springen, de tekst overslaan tussen, en bij elke link leest de schermlezer "link [link text]". Als zodanig is het ongelooflijk nutteloos voor dergelijke gebruikers als ze herhaaldelijk "link read more", "link click here" of "link continue reading" horen. Het toevoegen van context aan de link in dit geval is eenvoudigweg het geven van de titel van het bericht. Dus in plaats van "Continue reading" hebben we "Continue reading [post title]".
Om dit te doen in een WordPress-thema, moeten we gewoon inhaken op de excerpt_more filter en voeg onze link "verder lezen" toe:
// Voegt "blijvende lees X" link functie mytheme_continue_reading_link () return 'toe'. sprintf (__ ('Continue reading% s', 'mytheme'), esc_url (get_permalink ()), esc_html (get_the_title ())). '
'; // Vervangt "[...]" (toegevoegd aan automatisch gegenereerde fragmenten) met een ellips en mytheme_continue_reading_link (). functie mytheme_auto_excerpt_more ($ meer) ga terug ' …'. mytheme_continue_reading_link (); add_filter ('excerpt_more', 'mytheme_auto_excerpt_more');
Dit geeft de juiste context voor de "lees meer" -link. Er zijn echter een aantal verbeteringen die kunnen worden aangebracht.
Ten eerste zal de toevoeging van de titel van het artikel doorgaans de esthetiek van het thema bederven en voor geobserveerde gebruikers overbodig zijn, omdat de positie van de link "meer lezen" in relatie tot de titel en het fragment van het artikel de context duidelijk zal maken. Om deze problemen te omzeilen, kunnen we de titel van het artikel "verbergen", maar op een manier dat schermlezers ze nog steeds lezen.
Dit betekent dat wij kan niet gebruikenGeen weergeven of visibility: hidden; omdat schermlezers deze eigenschappen begrijpen en de inhoud negeren. In plaats daarvan kunnen we de tekst van het scherm plaatsen of de klem eigendom:
.schermlezer positie: absoluut! belangrijk; breedte: 1px; hoogte: 1px; opvulling: 0; marge: -1px; overloop verborgen; clip: rect (0,0,0,0); rand: 0;
Er zijn veel verschillende voorbeelden van "screen reader classes"; deze is afkomstig van Bootstrap 3. Voeg vervolgens de juiste klasse toe aan de titel van het artikel en vervang specifiek lijn 5 hierboven door:
Accentsconagua
__( 'Lees verder % s', 'mijn thema' ), Ten tweede, hoewel dit gebruikers een indicatie zou geven waar die link naar verwijst, zouden ze nog steeds moeten luisteren via "link verder lezen ..." voordat ze de titel van het bericht bereiken. Idealiter moet u overbodige informatie aan het einde van de linktekst plaatsen of volledig weglaten van de ankertag, om de tijd die nodig is om een link te identificeren te verkorten..
Een ander voordeel voor gebruikers van schermlezers van niet eerder gekoppelde tekst met overbodige informatie is dat schermlezers vaak een lijst met links op een pagina genereren. Als veel van uw links beginnen met dezelfde tekst, kan dit het zoeken naar een gewenste link moeilijker maken, vooral als de link voor uw contactpagina onder "H" staat omdat er staat: "Hoe kunt u contact met ons opnemen".
</code> Tag correct</h3><p>De <code><title></code> tag moet worden gebruikt om de huidige locatie van de gebruiker te identificeren. Dit wordt uitgelezen door schermlezers en wordt weergegeven in de zoekresultaten en op het scherm en in het browsertabblad. Om het gebruikers gemakkelijk te maken om te bepalen waar ze zich bevinden (of wat de zoekopdracht heeft gevonden), moet deze title-tag de titel van de pagina en de naam van de website bevatten. Idealiter zou de naam van de website als laatste moeten komen, zodat mensen die schermlezers gebruiken niet naar de naam van uw site hoeven te luisteren bij het laden van elke pagina voordat ze de paginatitel horen.</p><p>De title-tag kan aan een thema worden toegevoegd met:</p><pre><title><?php wp_title(); ?> Om de titel van de site toe te voegen:
/ ** * Titel van site toevoegen aan paginatitel * / functie mytheme_wp_title ($ title, $ sep, $ seplocation) return $ title. '| '. get_bloginfo ( 'name'); add_filter ('wp_title', 'mytheme_wp_title', 10, 3);Meteen naar de inhoud
Doorgaans hebben websites een gemeenschappelijke header en een navigatiemenu die, met uitzondering van het markeren van de huidige positie van de gebruiker, exact hetzelfde blijven. Het is vervelend en frustrerend om al deze links te doorlopen, of te luisteren naar een schermlezer die ze bij elke paginaweergave herhalen. Degenen onder ons met een goed (voldoende) gezichtsvermogen en motoriek kunnen onmiddellijk naar de inhoud springen - en we kunnen dit net zo gemakkelijk maken voor degenen die dat niet doen.
Als u in uw WordPress-beheerder bent en druk op tab Nadat de pagina is geladen, ziet u een link die zegt Ga naar de hoofdinhoud verschijnt in de linkerbovenhoek (als u nogmaals op het tabblad drukt, Ga naar de werkbalk link verschijnt). Deze link bevindt zich helemaal bovenaan de pagina, zodat het de eerste link is die focus krijgt tijdens het tabben en de eerste link van de website wordt uitgelezen door een schermlezer. Na die link springt de gebruiker rechtstreeks naar de hoofdinhoud en slaat alle onnodige links en logo's van de site er tussen over.
Het maken van een skip to content is een geweldige manier om uw website gemakkelijker te laten navigeren, en het is ongelooflijk eenvoudig, vereist slechts een klein beetje HTML en wat CSS.
Eerst de HTML. De link moet bovenaan uw pagina staan, direct onder de header.php het dossier:
// Rest van pagina-inhoud
De enige dingen om op te merken zijn hier:
- De href-waarde, in dit geval 'main'. Dit moet overeenkomen met de ID van het element dat de inhoud van de pagina bevat.
- De klasse van de link, die we zullen gebruiken voor styling.
Met betrekking tot (1) ziet uw lus er dan als volgt uit:
//De lus // Geen berichten gevonden ... zoekresultaat weergeven
en je paginasjablonen zien er ongeveer zo uit:
>
Nu rest alleen nog wat styling aan de link.
Ten eerste willen we dat de link wordt verborgen maar niet verborgen voor schermlezers, dus we plaatsen de link buiten het scherm in plaats van deze te gebruiken Geen weergeven (in welk geval screen-readers het negeren).
Ten tweede willen we dat de koppeling duidelijker wordt, dus het is duidelijk dat een eerder verborgen link nu zichtbaar is en focus heeft.
.skip-link positie: absoluut; left: 6px; top: -100px; / * positie offscreen zodat het niet zichtbaar is, maar kan focus * / z-index ontvangen: 100000; / * Positie boven WordPress 'werkbalk * / font-size: 1em; lettertype: vet; weergave: blok; achtergrond: # ee7b00; kleur wit; / * Style de link zodat deze duidelijk is * / height: auto; breedte: auto; regelhoogte: normaal; opvulling: 15px 25px; tekstdecoratie: geen; -webkit-overgang: top 1s gemak; overgang: top 1s gemak; .skip-link: focus top: 5px; / * Verplaats naar scherm * / -webkit-overgang: rechter 0s; overgang: rechter 0s; / * Animeren, zodat het uiterlijk zichtbaar wordt * /
Maak navigeren op uw site veilig (2.3)
Let ten slotte op dat sommige mensen vatbaar zijn voor lichtgevoelige epileptische aanvallen. Dit kan worden veroorzaakt door flikkerende of flitsende effecten. Afgelopen december verwijderde Jeff Chandler een "sneeuweffect" van WP Tavern nadat een bezoeker hem had gewaarschuwd dat dit een aanval zou kunnen uitlokken.
Dit is niet beperkt tot aanvallen - het kan bij sommige personen migraine of paniekaanvallen veroorzaken. Noch is het beperkt tot sneeuweffecten - een video, carrousel of audiobestand autoplaying kan deze ook activeren.
Hoewel dit grotendeels de beslissing van een redacteur is en het als onze ontwikkelaars niet onze taak is voorkomen automatisch afspelen, we kunnen het op zijn minst ontmoedigen door het standaard uit te schakelen. Jeff vermeldt in zijn artikel dat hij geen plug-in kon vinden die het "sneeuweffect" bood dat bezoekers zelf konden spelen.
