Share
Dit principe stelt dat alle inhoud in een formaat moet zijn (of beschikbaar op aanvraag in een formaat) dat gemakkelijk door de gebruiker kan worden waargenomen. Anders gezegd, uw websites moeten zodanig zijn ontworpen dat iedereen de inhoud kan 'lezen', ongeacht welke handicap zij ook hebben. Veel gebruikers met een handicap zullen ondersteunende technologieën gebruiken; bijvoorbeeld mensen met een visuele beperking kunnen een schermlezer gebruiken, die leest wat er op het scherm verschijnt, of een tekst-naar-braille-omzetter. Het doel is dan om deze ondersteunende technologieën te faciliteren.
Houd er rekening mee dat de richtlijnen hier zijn niet volledig, dus u moet altijd de Web Content Accessibility Guidelines raadplegen.
Dit is misschien wel het meest gebruikelijke advies om de toegankelijkheid te verbeteren. Als uw website bevat ieder afbeeldingen, dan worden deze genegeerd door schermlezers tenzij je gebruikt de alt label.
Merk op dat de alt-beschrijving niet noodzakelijk een beschrijving is van wat de afbeelding is, maar veeleer wat de afbeelding probeert overbrengen. De alt-tag zegt met woorden wat je met de afbeelding probeert te zeggen.
Hoewel dit advies vooral geschikt is voor redacteuren, breng ik het hier omdat themadebouwers vaak voorzien in een logo in plaats van tekst om de naam van de website of het bedrijf over te brengen. In dit geval is het waarschijnlijk het beste om de naam van de site te gebruiken (get_bloginfo ( 'name')) als de alternatieve beschrijving:
echo '';
'. get_bloginfo ('naam'). '
Alt-tags zouden moeten niet worden gebruikt voor puur decoratieve afbeeldingen, anders dwingt u de gebruiker in feite om buitensporige en onnodige informatie te doorzoeken.
Als uw plug-in een formulier maakt, hebt u mogelijk een soort bevestiging nodig dat iemand toegang heeft tot een computer en niet van een computer. Als u besluit de gebruiker een afbeelding of audioclip te verstrekken, die ze vervolgens moeten interpreteren, moet u dit in tekst uitleggen en een alternatieve vorm van CAPTCHA bieden om tegemoet te komen aan verschillende handicaps.
Deze richtlijn is grotendeels van toepassing op ontwikkelaars van plug-ins, maar kan ook op thema's van toepassing zijn. Als kleur, vorm of positie worden gebruikt om een betekenis over te brengen die niet uit de tekst te onderscheiden is, gaat die betekenis verloren bij gebruikers die kleurenblind of blind zijn.
Een typisch voorbeeld is bijvoorbeeld contactformulierknoppen die uitsluitend op een pictogram van het populaire pictogram Font Awesome vertrouwen:
Het doel van deze knoppen is gemakkelijk zichtbaar voor een ziende gebruiker, maar voor degenen die vertrouwen op schermlezers is er geen indicatie wat de knoppen doen. Als u voor ontwerpdoeleinden wilt voorkomen dat u tekst gebruikt, moet u het label opgeven met behulp van de aria-label attribuut.
Dit is slechts één voorbeeld van het ARIA-protocol, dat we in het volgende artikel gedetailleerder behandelen.
Dit is een bijna vanzelfsprekende vereiste. Zelfs voor een goedziende persoon is een website met een laag contrast tussen tekst en achtergrond moeilijk te lezen en kan het ogen belasten. Voor mensen met een visuele beperking is een nog groter contrast vereist. Daarom stelt de WCAG dat achtergrondkleur en tekstkleur een contrastverhouding van 4,5: 1 moeten hebben.
Het is niet meteen duidelijk hoe die ratio eruit ziet of wat het betekent, maar er zijn verschillende tools waarmee u de ratio kunt controleren:
Grotere tekst heeft een lagere eis van 3: 1, en logo's, tekst die pure decoratie is of niet zichtbaar, en 'uitgeschakelde' tekst / knoppen hebben geen contrastvereiste.
Hoewel de meeste thema's hun gebruikers de mogelijkheid bieden om de kleuren op de website aan te passen, is het een goed idee om ervoor te zorgen dat ten minste de standaardkleuren (of beschikbare 'paletten') voldoen aan de minimale contrastvereiste. Later in deze serie zullen we kijken naar het bouwen van een functie in uw thema, die de gebruiker waarschuwt als ze kleuren selecteren met onvoldoende contrast.
De British Dyslexia Association beveelt aan pure witte achtergronden voor tekst te vermijden en in plaats daarvan een gebroken witte kleur, crème of een zachte pastelkleur te gebruiken. De redenering hierachter is dat de helderheid van een witte pagina de lezer kan 'verblinden'.
Voor diegenen die lijden aan Scotopic sensitivity syndrome (of Irlen-syndroom), kan een te hoog contrast tussen achtergrond en tekst symptomen verergeren zoals:
Deze symptomen maken het lezen moeilijk en ongemakkelijk en kunnen oogvermoeidheid, oogvermoeidheid, sufheid en hoofdpijn veroorzaken.
In het licht van het vorige deel, is het beste advies om een goed contrast te garanderen, maar niet te veel contrast. Aangezien voorkeuren variëren van persoon tot persoon, is wat "te veel" is, te wijten aan persoonlijk oordeel.
Een gestructureerde lay-out, met het juiste gebruik van rubrieken, maakt het voor gebruikers gemakkelijker om de informatie te begrijpen die aan hen wordt gepresenteerd. Gebruikers van schermlezers vertrouwen enigszins op een 'verstandige' structuur om hen te helpen hun weg te vinden op een pagina.
Een snelle manier om dit te testen, is door je thema te bekijken met CSS en JavaScript uitgeschakeld. EEN beter manier is om Lynx te gebruiken. Dit is een op tekst gebaseerde browser. Als de structuur van uw site ervoor zorgt dat de inhoud ongeordend wordt weergegeven, is het voor gebruikers die Lynx of andere ondersteunende technologieën gebruiken moeilijk om uw website te lezen. Omdat gebruikers die vertrouwen op dergelijke technologieën niet de voordelen hebben die CSS en JavaScript bieden bij het helpen van de pagina en de stroom van inhoud, is het belangrijk dat de juiste leesvolgorde duidelijk is zonder hen.
Dit is vrij eenvoudig te bereiken: zorg ervoor dat de HTML-markering de gewenste visuele volgorde weerspiegelt. Dit is heel natuurlijk, en als je merkt dat je website niet goed leest zonder CSS, dan heb je waarschijnlijk opzettelijk afgeweken. Als algemene vuistregel zou uw website het patroon moeten volgen:
Deze is vrij gemakkelijk om goed te krijgen. De regels zijn eenvoudig:
Accentsconagua
Een vraag die vaak wordt gesteld is: Moet de titel van mijn site in een label? De aanbevelingen van de W3C geven aan dat er weliswaar een aantal gevallen zijn waar dit een goed idee zou zijn, maar dat het in de context van WordPress-thema's het beste is om dit niet te gebruiken tags voor de sitetitel. Er zijn een aantal redenen:
</code> label. Hoewel dit vaak over het hoofd wordt gezien en een beetje lelijk voor visuele gebruikers, is dit het eerste wat door schermlezers wordt uitgelezen. Daarom de titel van de site inpakken <code><h1></code> geeft het overbodige bekendheid aan gebruikers van schermlezers, terwijl het duidelijker wordt voor waarnemers om gezien te worden zonder gebruik van de header-tag.</li> <li>De header-tags worden gebruikt om informatie te organiseren. De titel van uw site is niet erg handig voor een dergelijk doel.</li> </ol><p>Ongeacht wat u beslist, de daaropvolgende headers op uw pagina moeten eronder zitten. Dus artikelen in "The Loop" of uw paginatitels zouden moeten hebben <code><h2></code> tags als u de <code><h1></code> tag voor de titel van uw site, en <code><h1></code> tags anders.</p><p>Na de berichtinhoud zullen de meeste thema's de opmerkingen van de post weergeven. Het is normaal om 'Opmerkingen' als kop te hebben, omdat het een logische breuk is met de inhoud, maar omdat het koptekstniveau gekoppeld is aan de inhoud van de post, moet dit worden weergegeven. Het meest logische om te doen is de kop 'Opmerkingen' een niveau onder de titel van het bericht te plaatsen.</p><p>Hier is een fragment van een <code>single.php</code>:</p><pre><div role="main"> <div <?php post_class(); ?>> <h1> <?php the_title(); ?> </h1> <div> <?php the_content(); ?> </div><!--.entry-content--> <?php comments_template(); ?> </div> </div></pre><p>In mijn voorbeeld heb ik een <code><h1></code> tag voor de berichttitel, dus de reactiesjabloon (<code>comments.php</code>) kan er dan ongeveer zo uitzien:</p><pre><div> <h2> <?php printf( _n( 'One Comment on %2$s', '%1$s Comments on %2$s', get_comments_number(), 'mytheme' ), number_format_i18n( get_comments_number() ), get_the_title() ); ?> </h2> // ... </div></pre><h2>Zorg dat uw site goed reageert op een groter tekstformaat (1.4)</h2><p>Sommige gebruikers met milde visuele handicaps kunnen rekenen op grotere lettertypegroottes dan op ondersteunende technologieën zoals schermvergroters. Met het oog hierop geven de WCAG-richtlijnen aan dat uw site niet mag "breken" wanneer de tekst met maximaal 200% wordt vergroot. "Pauze" betekent hier dat tekst verdwijnt, botst, uit zijn containers komt, of meer in het algemeen, de lay-out van de site wordt verstoord, zodat het moeilijk of verwarrend is om te lezen.</p><h3>Gebruik relatieve lettertypen</h3><p>Omdat moderne browsers beter zijn geworden in het wijzigen van de grootte van tekst, is het gebruik van relatieve lettergroottes niet zo belangrijk als vroeger (hoewel IE9 de grootte van de lettertypen die zijn gedefinieerd in pixels niet wijzigt). Hoe dan ook, het is nog steeds aan te raden om relatieve lettergrootten (percentages, ems of rems) te gebruiken. De remunit adresseert enkele van de problemen met de em-eenheid - en hoewel deze alleen is geïntroduceerd met CSS3, kunt u deze op een backwards-compatibele manier gebruiken met oudere browsers. Details over het implementeren van relatieve lettertypen vallen enigszins buiten de scope, maar u kunt hier meer informatie vinden:</p><ul> <li>De "Erm ..." uit Ems halen</li> <li>Lettergrootte bij REM</li> </ul><h3>Gebruik vloeibare lay-outs</h3><p>Het wijzigen van de tekst kan echter leiden tot lay-outproblemen. Tekst kan van het scherm worden gedrukt, waardoor de gebruiker moet scrollen, of de tekst kan uit de container komen, mogelijk in andere tekst, waardoor delen van de webpagina onleesbaar worden. Dit waar a <em>sympathiek</em> (of vloeistof) lay-out kan helpen. "Responsieve" sites zijn ontworpen om aan te passen aan elk apparaat waarop ze worden bekeken; als zodanig gebruiken ze zelden vaste pixels voor hoogte / breedte of lettergrootte. Bijgevolg gedragen dergelijke sites zich gewoonlijk goed wanneer lettertypegroottes worden gewijzigd: hun lay-out breekt niet.</p><p>De WCAG-richtlijnen bevelen niet alleen aan dat tekst tot 200% vergroot mag worden, maar ook dat de website geschikt is voor de toegenomen tekstgrootte. Responsief webontwerp kan dat helpen omdat:</p><ul> <li>een vergroot scherm past zich aan de 'kleinere' viewport-grootte aan</li> <li>elementen worden verplaatst om horizontaal scrollen te elimineren</li> <li>niet-vaste formaten voorkomen overlapping of afgesneden tekst</li> <li>afbeeldingen worden van formaat aangepast aan de beschikbare ruimte en overlappen elkaar niet met tekst</li> </ul><p>Het is echter belangrijk op te merken dat responsief ontwerp en toegankelijkheid niet hetzelfde zijn: hoewel ze elkaar kunnen aanvullen, hebben ze uiteindelijk verschillende doelen. Een responsieve site is niet noodzakelijk toegankelijk en vice versa.</p><h2>Gebruik correct markeren (1.3)</h2><h3>Gebruik alleen tabellen om gegevens te representeren</h3><p>Het gebruik van tabellen als hulpmiddel in een paginalay-out is (hopelijk) verleden tijd. Er zijn ook toegankelijkheid gerelateerde vertakkingen voor het misbruiken van tabellen. Tabellen zijn bedoeld om gegevens of informatie weer te geven en als zodanig hebben rijen en kolommen een inherente betekenis, en schermlezers nemen dit aan bij het uitlezen van gegevens. </p><p>Een schermlezer leest bijvoorbeeld het rij- en kolomnummer uit voordat de inhoud van de cel wordt gelezen. Aangezien de celpositie in tabellen die uitsluitend voor presentatiedoeleinden worden gebruikt irrelevant is, kan deze informatie verwarrend zijn, of op zijn minst irriterend: de eindgebruiker krijgt te horen dat er een tabellarische structuur is, terwijl er in werkelijkheid geen sprake is van.</p><h3>Correct gebruik van tabelmarkering</h3><p>De meeste thema-ontwikkelaars hoeven geen tabellen te produceren (en de WordPress-berichtenkalender is al toegankelijk). Plug-ins kunnen tabellen echter weergeven via shortcodes of widgets. Er zijn een aantal dingen waar u rekening mee moet houden bij het maken van de tabelmarkering:</p><ul> <li>Houd tabellen waar mogelijk eenvoudig. Hoewel overspannen rijen / kolommen al jarenlang een standaardmarkering zijn, worden ze niet universeel ondersteund door schermlezers.</li> <li> <p>Geef waar nodig een <code><caption></code> element aan de bovenkant van een tabel, waarin wordt beschreven wat de tabel laat zien:</p> <pre><table> <caption>... </caption>... </table></pre> </li> <li>Gebruik <code><th></code> voor tafel <em>headers</em> en <code><td></code> voor <em>tabelgegevens</em>. <code><th></code> cellen mogen nooit leeg zijn.</li> <li>Geef ruimte voor <code><th></code> cellen, wat aangeeft of het een rij- of kolomkop is: <code><th scope="col"></code> of <code><th scope="row"></code>. Hoewel het bereik vaak wordt bepaald door de schermlezer, doet het geen pijn om expliciet te zijn.</li> <li>Je kunt gebruiken <code><thead></code>, <code><tbody></code> en <code><tfoot></code>, maar ze bieden geen voordelen in termen van toegankelijkheid.</li> <li> <p>Gebruik de <code>titel</code> attribuut van kopjes om een afkorting in de cel uit te leggen:</p> <pre><table> <caption> februari 2014 </caption> <thead> <tr> <th title="maandag" scope="col">M</th> <th title="dinsdag" scope="col">T</th> <th title="woensdag" scope="col">w</th> <th title="donderdag" scope="col">T</th> <th title="vrijdag" scope="col">F</th> <th title="zaterdag" scope="col">S</th> <th title="zondag" scope="col">S</th> </tr> </thead>... </table></pre> </li> </ul><h3>ARIA & formulieren</h3><p><em>Toegankelijke rijke internettoepassingen</em> (ARIA) attributen zijn nuttig bij het identificeren van het doel van een bepaald deel van de pagina, eventuele eigenschappen (bijvoorbeeld het labelen van een vereiste vorminvoer als zodanig) en status (bijvoorbeeld het labelen van een knop als uitgeschakeld). Door ze te gebruiken, kunnen hulptechnologieën uw website beter begrijpen en zo uw pagina duidelijker presenteren aan de eindgebruiker. We zullen naar ARIA kijken in het volgende artikel in deze serie. Later in de serie zullen we ook kijken naar de juiste vormmarkering en toegankelijke feedback.</p>
<div class="rek-block">
<center>
<ins class="adsbygoogle"
style="display:inline-block;width:580px;height:400px"
data-ad-client="ca-pub-3810161443300697"
data-ad-slot="9434875811"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>
</center>
</div>
<div class="h-alltags">
<a href="articles/code">Code</a>
</div>
</div>
</div>
</div>
</div>
<div class="next_posts clearfix">
<div class="n_post">
<div class="next_posts-h1 left_nh1"><a href="/articles/code/accessibility-part-3-aria.html">Toegankelijkheid, deel 3 ARIA</a></div>
<div class="next_posts-img" style="background-image: url('//accentsconagua.com/img/images_11/accessibility-part-3-aria_2.png');"></div>
</div>
<div class="n_post">
<div class="next_posts-h1 right_nh1"><a href="/articles/code/accessibility-part-1-introduction.html">Toegankelijkheid, deel 1 introductie</a></div>
<div class="next_posts-img" style="background-image: url('//accentsconagua.com/img/images_11/accessibility-part-1-introduction.png');"></div>
</div>
</div>
<footer>
<div class="container">
<div class="footer-langs">
<ul class="site-langs-list">
<li><a href="https://www.accentsconagua.com"><i class="flag flag-DE"></i>Deutsch</a></li>
<li><a href="https://fr.accentsconagua.com"><i class="flag flag-FR"></i>Français</a></li>
<li><a href="https://nl.accentsconagua.com"><i class="flag flag-NL"></i>Nederlands</a></li>
<li><a href="https://no.accentsconagua.com"><i class="flag flag-NO"></i>Norsk</a></li>
<li><a href="https://sv.accentsconagua.com"><i class="flag flag-SE"></i>Svenska</a></li>
<li><a href="https://it.accentsconagua.com"><i class="flag flag-IT"></i>Italiano</a></li>
<li><a href="https://es.accentsconagua.com"><i class="flag flag-ES"></i>Español</a></li>
<li><a href="https://ro.accentsconagua.com"><i class="flag flag-RO"></i>Românesc</a></li>
</ul>
</div>
<div class="h-block"><a href="/">nl.accentsconagua.com</a><div class="h-block-a"></div></div>
<div class="footer-text">
Interessante informatie en nuttige tips over programmeren. Website ontwikkeling, webdesign en webontwikkeling. Photoshop-zelfstudies. Creatie van computerspellen en mobiele applicaties. Word een volledig professionele programmeur.
</div>
</div>
</footer>
<div class="search">
<img class="searchico" src="//accentsconagua.com/img/search.svg" alt="">
</div>
<div class="modal">
<div class="modal-content">
<span class="close-button">×</span>
<input class="searchmain" type="text" id="search-input" placeholder="Zoeken...">
<ul class="searchli" id="results-container"></ul>
</div>
</div>
<link rel="stylesheet" href="css/flags.css">
<link rel="stylesheet" type="text/css" href="//cdnjs.cloudflare.com/ajax/libs/cookieconsent2/3.1.0/cookieconsent.min.css" />
<script src="//cdnjs.cloudflare.com/ajax/libs/cookieconsent2/3.1.0/cookieconsent.min.js"></script>
<script>
window.addEventListener("load", function(){
window.cookieconsent.initialise({
"palette": {
"popup": {
"background": "#edeff5",
"text": "#838391"
},
"button": {
"background": "#4b81e8"
}
},
"theme": "classic",
"position": "bottom-right"
})});
</script>
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<script src="js/scripts.min.js"></script>
<script src="js/common.js"></script>
<link rel="stylesheet" href="css/fontawesome-all.min.css">
<script>
var modal = document.querySelector(".modal");
var trigger = document.querySelector(".search");
var closeButton = document.querySelector(".close-button");
function toggleModal() {
modal.classList.toggle("show-modal");
}
function windowOnClick(event) {
if (event.target === modal) {
toggleModal();
}
}
trigger.addEventListener("click", toggleModal);
closeButton.addEventListener("click", toggleModal);
window.addEventListener("click", windowOnClick);
</script>
<script src="https://unpkg.com/simple-jekyll-search@1.5.0/dest/simple-jekyll-search.min.js"></script>
<script>
SimpleJekyllSearch({
searchInput: document.getElementById('search-input'),
resultsContainer: document.getElementById('results-container'),
json: '/search.json',
searchResultTemplate: '<li><a href="{url}">{title}</a></li>'
})
</script>
<script src="jquery.unveil2.min.js"></script>
<script>
$('img').unveil();
</script>
</body>
</html>