path: root/files/nl/learn/accessibility/html/index.html

---
title: 'HTML: Een goede basis voor toegankelijkheid'
slug: Learn/Accessibility/HTML
translation_of: Learn/Accessibility/HTML
---
<div>{{LearnSidebar}}</div>

<div>{{PreviousMenuNext("Learn/Accessibility/What_is_Accessibility","Learn/Accessibility/CSS_and_JavaScript", "Learn/Accessibility")}}</div>

<p class="summary">Een bijzonder groot deel van alle webcontent kan toegankelijk gemaakt worden door correcte HTML elementen te gebruiken voor het juiste doel. Dit artikel gaat in detail over hoe HTML gebruikt kan worden om maximale toegankelijkheid te garanderen.</p>

<table class="learn-box standard-table">
 <tbody>
  <tr>
   <th scope="row">Vereisten:</th>
   <td>
    <p>basiscomputervaardigheden, basiskennis van HTML (zie <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML">Introductie in HTML</a>) en inzicht in <a href="/en-US/docs/Learn/Accessibility/What_is_accessibility">wat toegankelijkheid is</a>.</p>
   </td>
  </tr>
  <tr>
   <th scope="row">Doel:</th>
   <td>
    <p>Vertrouwd raken met HTML functies die toegankelijkheidsvoordelen hebben en hoe je deze op de juiste manier kunt gebruiken in je webdocumenten.</p>
   </td>
  </tr>
 </tbody>
</table>

<h2 id="HTML_en_toegankelijkheid">HTML en toegankelijkheid</h2>

<p>Naarmate je meer leert over HTML - des te meer bronnen je leest, des te meer voorbeelden je bekijkt, enz. - blijf je een terugkerend thema zien: het belang van het gebruik van semantische HTML (ook wel POSH of 'Plain Old Semantic HTML' genoemd). Dit betekent eigenlijk niets anders dan zoveel mogelijk gebruik maken van de juiste HTML-elementen voor hun juiste doel.</p>

<p>Je vraagt je misschien af waarom dit zo belangrijk is? Je kunt immers een combinatie van CSS en JavaScript gebruiken om zo ongeveer elk HTML-element te laten werken zoals je wilt. Een control button om een video op uw site af te spelen, kan bijvoorbeeld als volgt worden gemarkeerd:</p>

<pre class="brush: html">    &lt;div&gt;Speel video af&lt;/div&gt;</pre>

<p>Maar zoals je verderop in dit artikel in meer detail zult zien, is het logisch om het juiste HTML element voor deze taak te gebruiken:</p>

<pre class="brush: html">    &lt;button&gt;Speel video af&lt;/button&gt;</pre>

<p>Niet alleen HTML &lt;button&gt; s hebben standaard een geschikte stijl toegepast (die je waarschijnlijk wilt overschrijven), ze hebben ook een ingebouwde toetsenbordtoegankelijkheid - ze kunnen namelijk worden weergegeven tussen tabbladen en worden geactiveerd met Return / Enter.</p>

<p>Het schrijven van semantische HTML duurt niet langer dan niet-semantische (slechte) markup. En als je dit consequent vanaf het begin van je project doet heeft het ook andere voordelen dan alleen toegankelijkheid:<br>
  </p>

<ol>
 <li><strong>Gemakkelijker te ontwikkelen</strong> — zoals hierboven vermeld, krijg je al standaard wat extra functionaliteit. En bovendien is het waarschijnlijk gemakkelijker te begrijpen.</li>
 <li><strong>Beter op mobiel</strong> — semantische HTML is aantoonbaar lichter in bestandsgrootte dan niet-semantische spaghetti-code, en gemakkelijker om responsive te maken.</li>
 <li><strong>Goed voor SEO</strong> — zoekmachines geven meer aandacht aan zoekwoorden binnen headings, links, enzovoort dan zoekwoorden die zijn opgenomen in niet-semantische &lt;div&gt; s, enz., Zo zijn je documenten en webpagina's beter vindbaar voor klanten.</li>
</ol>

<p>Laten we meer in detail duiken, en toegankelijke HTML bekijken.</p>

<div class="note">
<p><strong>N.b.</strong>: het is een goed idee om een schermlezer in te stellen op uw lokale computer, zodat u de onderstaande voorbeelden kunt testen. Raadpleeg de handleiding voor schermlezers (<a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Screenreaders">Screenreaders guide</a>) voor meer informatie.</p>
</div>

<h2 id="Goede_semantiek">Goede semantiek</h2>

<p>We hebben al gesproken over het belang van goede semantiek en waarom we het juiste HTML-element voor het juiste doel moeten gebruiken. Deze taak mag niet worden genegeerd. Het is een van de belangrijkste punten waarop toegankelijkheid misloopt als het niet goed wordt toegepast.</p>

<p>De rauwe waarheid van het internet is dat mensen heel vreemde dingen doen met HTML-markup. Het misbruik van HTML is te wijten aan legacy-praktijken die niet volledig zijn vergeten, en soms is het gewoon onwetendheid. Hoe het ook zij, je dient dergelijke slechte code altijd te vervangen. Waar je deze ook ziet, wanneer je maar kunt.</p>

<p>Soms ben je niet altijd in de positie om slechte markup te verwijderen - zo kunnen je pagina's worden gegenereerd door een soort server-side framework waar je geen volledige controle over hebt, of dat je inhoud van derden op je pagina hebt (zoals als advertentiebanners) waar je geen controle over hebt.</p>

<p>Het doel is echter niet "alles of niets". Elke verbetering die je kunt maken, zal de gedachte achter toegankelijkheid helpen.</p>

<h3 id="Text_content">Text content</h3>

<p>Een van de beste toegankelijkheidshulpmiddelen die een gebruiker van een schermlezer kan hebben, is een goede inhoudsstructuur van kopjes, alinea's, lijsten, enz. Een goed semantisch voorbeeld kan er ongeveer zo uitzien:</p>

<pre class="brush: html example-good">    &lt;h1&gt;Mijn heading&lt;/h1&gt;

    &lt;p&gt;Dit is de eerste sectie van mijn document.&lt;/p&gt;

    &lt;p&gt;En ik voeg hier nog een paragraaf toe.&lt;/p&gt;

    &lt;ol&gt;
    &lt;li&gt;Hier is&lt;/li&gt;
    &lt;li&gt;een lijst voor&lt;/li&gt;
    &lt;li&gt;jou om te lezen&lt;/li&gt;
    &lt;/ol&gt;

    &lt;h2&gt;Mijn subheading&lt;/h2&gt;

    &lt;p&gt;Dit is de eerste subsectie van mijn document. Ik hou van mensen die mijn content kunnen vinden!&lt;/p&gt;

    &lt;h2&gt;Mijn 2e subheading&lt;/h2&gt;

    &lt;p&gt;Dit is de tweede subsectie van mijn document. Ik denk dat deze nog interessanter is dan de andere.&lt;/p&gt;</pre>

<p>We hebben een andere versie voor je voorbereid met wat langere teksten. Deze kun je uitproberen met een screenreader (zie <a href="http://mdn.github.io/learning-area/accessibility/html/good-semantics.html">good-semantics.html</a>). Als je hierdoor heen probeert te navigeren, dan zie je dat dit vrij eenvoudig is om jezelf doorheen te navigeren:</p>

<ol>
 <li>De screenreader leest elke header uit zodra je verder door de content heen gaat. Je wordt geïnformeerd over wat een heading is, wat een paragraaf is, enz.</li>
 <li>Het stopt na ieder element. Het laat jou werken in een tempo wat prettig is voor jou.</li>
 <li>Je kunt naar ieder andere heading springen met (volgende/vorige) in de meeste screenreaders.</li>
 <li>Je kunt in vele screenreaders ook een lijst met headings naar voren brengen, en deze gebruiken als een handige 'inhoudspagina' om specifieke content te vinden.</li>
</ol>

<p>Soms schrijven mensen headings, paragrafen, enz. alleen als presentaarbare HTML en bijv. met line-breaks (&lt;br&gt;). Zoiets als onderstaande:</p>

<pre class="brush: html example-bad">    &lt;font size="7"&gt;Mijn heading&lt;/font&gt;
    &lt;br&gt;&lt;br&gt;
    Dit is de eerste sectie van mijn document.
    &lt;br&gt;&lt;br&gt;
    Ik zal hier nog een paragraaf toevoegen.
    &lt;br&gt;&lt;br&gt;
    1. Hier is
    &lt;br&gt;&lt;br&gt;
    2. een lijst voor
    &lt;br&gt;&lt;br&gt;
    3. jou om te lezen
    &lt;br&gt;&lt;br&gt;
    &lt;font size="5"&gt;Mijn subheading&lt;/font&gt;
    &lt;br&gt;&lt;br&gt;
    Dit is de eerste subsectie van mijn document. Ik hou van mensen die mijn content kunnen vinden!
    &lt;br&gt;&lt;br&gt;
    &lt;font size="5"&gt;My 2nd subheading&lt;/font&gt;
    &lt;br&gt;&lt;br&gt;
    Dit is de tweede subsectie van mijn document. Ik denk dat deze nog interessanter is dan de andere.</pre>

<p>Als je onze langere versie uitprobeert met een screenreader (zie <a href="http://mdn.github.io/learning-area/accessibility/html/bad-semantics.html">bad-semantics.html</a>), dan zul je zien dat je niet echt een goede ervaring hebt. De screenreader kan niets als wegwijzer gebruiken, dus je kunt ook geen bruikbare inhoudsopgave vinden. De hele pagina wordt zo gezien als één gigantisch blok, dus daarom het gewoon in één keer volledig uitgelezen.</p>

<p>Er zijn nog andere zaken die nog verder gaan dan toegankelijkheid. Het is bijvoorbeeld moeilijker om de inhoud te stijlen met CSS, of het manipuleren met Javascript. Er zijn immers geen elementen die als 'selectors' kunnen worden gebruikt.</p>

<h4 id="Gebruik_duidelijke_taal">Gebruik duidelijke taal</h4>

<p>De taal die je gebruikt, kan ook de toegankelijkheid beìnvloeden. Over het algemeen moet je zo duidelijk mogelijke taal gebuiken die niet overdreven complex is, en geen onnodig jargon bevat. Dit komt niet alleen ten goede aan mensen met cognitieve of andere handicaps; het komt alle lezers ten goede voor wie de tekst niet in hun eerste taal is geschreven, voor oudere mensen, voor jongere mensen ... eigenlijk iedereen! Daarnaast zou je altijd moeten proberen om taal en karakters te vermijden die niet duidelijk worden voorgelezen door de schermlezer. Bijvoorbeeld:</p>

<p> </p>

<ul>
 <li>Gebruik geen streepjes als u dit kunt voorkomen. In plaats van 5-7 te schrijven, schrijf je 5 tot 7.</li>
 <li>Breid afkortingen uit - schrijf 'Januari' in plaats van 'Jan' te schrijven.</li>
 <li>Schrijf afkortingen uit, minstens één of twee keer. In plaats van in eerste instantie HTML te schrijven, schrijf je Hypertext Markup Language.</li>
</ul>

<h3 id="Pagina_layouts">Pagina layouts</h3>

<p>Vroeger in de 'niet-zo-goede-oude-tijd' maakten mensen gebruik van HTML-tabellen om paginalay-outs te maken - ze gebruikten verschillende tabelcellen om de kop-, voettekst-, zijbalk-, hoofdinhoudskolom, enz. te gebruiken. Dit is geen goed idee, omdat een schermlezer hoogstwaarschijnlijk hele verwarrende zaken zal uitlezen, vooral als de lay-out complex is en veel geneste tabellen bevat.</p>

<p>Probeer ons <a href="http://mdn.github.io/learning-area/accessibility/html/table-layout.html">table-layout.html</a> voorbeeld. Dit ziet er ongeveer zo uit:</p>

<pre class="brush: html">    &lt;table width="1200"&gt;
        &lt;!-- main heading row --&gt;
        &lt;tr id="heading"&gt;
            &lt;td colspan="6"&gt;

            &lt;h1 align="center"&gt;Header&lt;/h1&gt;

            &lt;/td&gt;
        &lt;/tr&gt;
        &lt;!-- nav menu row  --&gt;
        &lt;tr id="nav" bgcolor="#ffffff"&gt;
            &lt;td width="200"&gt;
            &lt;a href="#" align="center"&gt;Home&lt;/a&gt;
            &lt;/td&gt;
            &lt;td width="200"&gt;
            &lt;a href="#" align="center"&gt;Ons team&lt;/a&gt;
            &lt;/td&gt;
            &lt;td width="200"&gt;
            &lt;a href="#" align="center"&gt;Projecten&lt;/a&gt;
            &lt;/td&gt;
            &lt;td width="200"&gt;
            &lt;a href="#" align="center"&gt;Contact&lt;/a&gt;
            &lt;/td&gt;
            &lt;td width="300"&gt;
            &lt;form width="300"&gt;
                &lt;input type="search" name="q" placeholder="Zoeken" width="300"&gt;
            &lt;/form&gt;
            &lt;/td&gt;
            &lt;td width="100"&gt;
            &lt;button width="100"&gt;Zoek!&lt;/button&gt;
            &lt;/td&gt;
        &lt;/tr&gt;
        &lt;!-- spacer row --&gt;
        &lt;tr id="spacer" height="10"&gt;
            &lt;td&gt;

            &lt;/td&gt;
        &lt;/tr&gt;
        &lt;!-- main content and aside row --&gt;
        &lt;tr id="main"&gt;
            &lt;td id="content" colspan="4" bgcolor="#ffffff"&gt;

            &lt;!-- main content goes here --&gt;
            &lt;/td&gt;
            &lt;td id="aside" colspan="2" bgcolor="#ff80ff" valign="top"&gt;
            &lt;h2&gt;Gerelateerd&lt;/h2&gt;

            &lt;!-- aside content goes here --&gt;

            &lt;/td&gt;
        &lt;/tr&gt;
        &lt;!-- spacer row --&gt;
        &lt;tr id="spacer" height="10"&gt;
            &lt;td&gt;

            &lt;/td&gt;
        &lt;/tr&gt;
        &lt;!-- footer row --&gt;
        &lt;tr id="footer" bgcolor="#ffffff"&gt;
            &lt;td colspan="6"&gt;
            &lt;p&gt;©Copyright 2050 by nobody. All rights reversed.&lt;/p&gt;
            &lt;/td&gt;
        &lt;/tr&gt;
        &lt;/table&gt;</pre>

<p> </p>

<p>Als je probeert hierdoor heen te navigeren met een schermlezer, zal het waarschijnlijk zeggen dat er een tabel moet worden bekeken (hoewel sommige schermlezers het verschil tussen tabel-lay-outs en gegevenstabellen kunnen raden). Je zult dan waarschijnlijk (afhankelijk van welke schermlezer je gebruikt) als object naar de tabel moeten gaan en apart naar de functies kijken, en dan weer uit de tabel gaan om verder door de inhoud te kunnen navigeren.</p>

<p>Tabel-lay-outs zijn een overblijfsel uit het verleden - ze waren logisch terug toen CSS-ondersteuning niet wijdverspreid was in browsers. Maar ze creëren verwarring voor schermlezers-gebruikers en zijn ook slecht voor veel andere redenen (onnodig gebruik van tabellen, betwistbaar meer markup, ontwerp maken wordt minder handig). Doe het niet!</p>

<p>Je kunt deze opvattingen verifiëren door je eerdere ervaring te vergelijken met een moderner voorbeeld van een websitestructuur (<a href="http://mdn.github.io/learning-area/html/introduction-to-html/document_and_website_structure/">more modern website structure example</a>), dat zou er ongeveer zo uit kunnen zien:</p>

<p> </p>

<pre class="brush: html">    &lt;header&gt;
    &lt;h1&gt;Header&lt;/h1&gt;
    &lt;/header&gt;

    &lt;nav&gt;
    &lt;!-- main navigatie hier --&gt;
    &lt;/nav&gt;

    &lt;!-- Hiet is onze pagina's main content --&gt;
    &lt;main&gt;

    &lt;!-- Het bevat een article --&gt;
    &lt;article&gt;
        &lt;h2&gt;Article heading&lt;/h2&gt;

        &lt;!-- article content gaat hier --&gt;
    &lt;/article&gt;

    &lt;aside&gt;
        &lt;h2&gt;Gerelateerd&lt;/h2&gt;

        &lt;!-- aside content gaat hier --&gt;
    &lt;/aside&gt;

    &lt;/main&gt;

    &lt;!-- En hier onze onze main footer die gebruikt worden op al onze pagina's in onze website --&gt;

    &lt;footer&gt;
    &lt;!-- footer content gaat hier --&gt;
    &lt;/footer&gt;</pre>

<p>Als je ons modernere HTML structuurvoorbeeld met een schermlezer probeert, zie je dat de opmaakmarkering niet langer in de weg zit en de inhoud keurig uitgelezen wordt. Het is ook veel schoner en kleiner qua hoeveelheid code. Dit betekent dat code eenvoudiger te onderhouden is en minder bandbreedte kost voor de gebruiker om de code te downloaden (dus vooral belangrijk voor mensen met langzame verbindingen!).</p>

<p>Een andere overweging bij het maken van lay-outs is het gebruik van HTML5-semantische elementen zoals te zien in het bovenstaande voorbeeld (zie <a href="/en-US/docs/Web/HTML/Element#Content_sectioning">content sectioning</a>). Je kunt een lay-out maken met alleen geneste {{htmlelement ("div")}} elementen, maar het is beter om de juiste sectie te gebruiken elementen om je hoofdnavigatie in te pakken ({{htmlelement ("nav")}}), footer ({{htmlelement ("footer")}}), contenteenheden ({{htmlelement ("article")}}), enz. te herhalen Deze bieden extra semantiek voor schermlezers (en andere hulpmiddelen) om de gebruiker extra aanwijzingen te geven over de inhoud waarin ze navigeren (zie <a href="http://www.weba11y.com/blog/2016/04/22/screen-reader-support-for-new-html5-section-elements/">Screen Reader Support for new HTML5 Section Elements</a> voor een idee van hoe ondersteuning voor schermlezers eruit ziet).</p>

<div class="note">
<p><strong>N.b.</strong>: Naast je inhoud met een goede semantiek en een aantrekkelijke lay-out, moet deze logisch en zinvol zijn in de bronvolgorde - je kunt deze later altijd plaatsen waar je wilt met behulp van CSS, maar je moet eerst de bronvolgorde in orde krijgen. Dit is namelijk hetgeen wat gebruikers van schermleesprogramma's word voorgelezen.</p>
</div>

<h3 id="UI_besturingselementen">UI besturingselementen</h3>

<p> </p>

<p>Met UI-besturingselementen bedoelen we de belangrijkste delen van webdocumenten waarmee gebruikers communiceren - meestal knoppen, links en formulierbesturingselementen. In deze sectie zullen we kijken naar de fundamentele toegankelijkheidsproblemen waar je rekening mee moet houden bij het maken van dergelijke besturingselementen. Andere artikelen over WAI-ARIA en multimedia zullen andere aspecten van UI-toegankelijkheid toelichten.</p>

<p>Een belangrijk aspect van de toegankelijkheid van UI-besturingselementen is dat browsers standaard toestaan dat ze door het toetsenbord worden gemanipuleerd. Je kunt dit uitproberen met ons <a href="http://mdn.github.io/learning-area/tools-testing/cross-browser-testing/accessibility/native-keyboard-accessibility.html">native-keyboard-accessibility.html</a> voorbeeld (zie de <a href="https://github.com/mdn/learning-area/blob/master/tools-testing/cross-browser-testing/accessibility/native-keyboard-accessibility.html">source code</a>) - open dit op een nieuw tabblad en probeer de tabtoets in te drukken; na een paar keer drukken, zou je moeten zien dat de tab-focus begint om door de verschillende focusseerbare elementen te bewegen; de gefocuste elementen krijgen een gemarkeerde standaardstijl in elke browser (deze verschilt enigszins tussen verschillende browsers), zodat je kunt zien welk element is gefocust.</p>

<p> </p>

<p><img alt="" src="https://mdn.mozillademos.org/files/14215/button-focused-unfocused.png" style="border-style: solid; border-width: 1px; display: block; height: 39px; margin: 0px auto; width: 288px;"></p>

<p>Je kunt vervolgens op Enter / Return drukken om een gefocusde link te volgen of op een knop te drukken (we hebben wat JavaScript toegevoegd om de knoppen een bericht te laten 'alert'). Of begin met typen om een tekst in te voeren in een text input (andere formulierelementen hebben verschillende bedieningselementen, bijvoorbeeld het element {{htmlelement ("select")}} kan zijn opties laten weergeven en rouleren zodra je de pijltjestoetsen omhoog en omlaag gebruikt).</p>

<div class="note">
<p><strong>N.b.</strong>: Verschillende browsers hebben mogelijk verschillende toetsenbordbesturingsopties beschikbaar. Zie <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Using_native_keyboard_accessibility">Using native keyboard accessibility</a> voor meer informatie.</p>
</div>

<p>Eigenlijk krijg je dit gedrag in principe gratis, gewoon door alleen maar de juiste elementen te gebruiken, bijvoorbeeld:</p>

<pre class="brush: html example-good">    &lt;h1&gt;Links&lt;/h1&gt;

    &lt;p&gt;Dit is een link naar &lt;a href="https://www.mozilla.org"&gt;Mozilla&lt;/a&gt;.&lt;/p&gt;

    &lt;p&gt;Nog een link, naar &lt;a href="https://developer.mozilla.org"&gt;Mozilla Developer Network&lt;/a&gt;.&lt;/p&gt;

    &lt;h2&gt;Buttons&lt;/h2&gt;

    &lt;p&gt;
    &lt;button data-message="Dit is van de eerste button"&gt;Klik mij!&lt;/button&gt;
    &lt;button data-message="Dit is van de tweede button"&gt;Klik mij ook!&lt;/button&gt;
    &lt;button data-message="Dit is van de derde button"&gt;En mij ook!&lt;/button&gt;
    &lt;/p&gt;

    &lt;h2&gt;Formulier&lt;/h2&gt;

    &lt;form&gt;
      &lt;div&gt;
        &lt;label for="name"&gt;Vul je naam in:&lt;/label&gt;
       &lt;input type="text" id="name" name="name"&gt;
      &lt;/div&gt;
      &lt;div&gt;
        &lt;label for="age"&gt;Voeg je leeftijd toe:&lt;/label&gt;
        &lt;input type="text" id="age" name="age"&gt;
      &lt;/div&gt;
      &lt;div&gt;
        &lt;label for="mood"&gt;Hoe voel je je vandaag:&lt;/label&gt;
        &lt;select id="mood" name="mood"&gt;
          &lt;option&gt;Blij&lt;/option&gt;
          &lt;option&gt;Verdrietig&lt;/option&gt;
          &lt;option&gt;Boos&lt;/option&gt;
          &lt;option&gt;Bezorgd&lt;/option&gt;
        &lt;/select&gt;
      &lt;/div&gt;
    &lt;/form&gt;</pre>

<p> </p>

<p>Dit betekent dat je op de juiste manier links, knoppen, formulierelementen en labels gebruikt (inclusief het element {{htmlelement ("label")}} voor formulierbesturingselementen).</p>

<p>Het is echter altijd zo dat mensen soms rare dingen doen met HTML. Je ziet bijvoorbeeld soms knoppen gemaakt worden met behulp van {{htmlelement ("div")}} s, bijvoorbeeld:</p>

<p> </p>

<pre class="brush: html example-bad">    &lt;div data-message="Dit is van de eerste button"&gt;Klik mij!&lt;/div&gt;
    &lt;div data-message="Dit is van de tweede button"&gt;Klik mij ook!&lt;/div&gt;
    &lt;div data-message="Dit is van de derde button"&gt;En mij ook!&lt;/div&gt;</pre>

<p>Het gebruik van dergelijke code wordt sterk afgeraden - je verliest namelijk onmiddellijk de toegankelijkheid voor het native toetsenbord die je wel zou hebben gehad als je net {{htmlelement ("button")}} -elementen had gebruikt. Daarnaast is het zo dat je geen van de standaard CSS-styling krijgt die knoppen automatisch meekrijgen.</p>

<h4 id="Building_keyboard_accessibility_back_in">Building keyboard accessibility back in</h4>

<p>Adding such advantages back in takes a bit of work (you can an example code in our <a class="external external-icon" href="http://mdn.github.io/learning-area/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">fake-div-buttons.html</a> example — also see the <a class="external external-icon" href="https://github.com/mdn/learning-area/blob/master/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">source code</a>). Here we've given our fake <code>&lt;div&gt;</code> buttons the ability to be focused (including via tab) by giving each one the attribute <code>tabindex="0"</code>:</p>

<pre class="brush: html">    &lt;div data-message="This is from the first button" tabindex="0"&gt;Click me!&lt;/div&gt;
    &lt;div data-message="This is from the second button" tabindex="0"&gt;Click me too!&lt;/div&gt;
    &lt;div data-message="This is from the third button" tabindex="0"&gt;And me!&lt;/div&gt;</pre>

<p>Basically, the {{htmlattrxref("tabindex")}} attribute is primarily intended to allow tabbable elements to have a custom tab order (specified in positive numerical order), instead of just being tabbed through in their default source order. This is nearly always a bad idea, as it can cause major confusion. Use it only if you really need to, for example if the layout shows things in a very different visual order to the source code, and you want to make things work more logically. There are two other options for <code>tabindex</code>:</p>

<ul>
 <li><code>tabindex="0"</code> — as indicated above, this value allows elements that are not normally tabbable to become tabbable. This is the most useful value of <code>tabindex</code>.</li>
 <li><code>tabindex="-1"</code> — this allows not normally tabbable elements to receive focus programmatically, e.g. via JavaScript, or as the target of links. </li>
</ul>

<p>Whilst the above addition allows us to tab to the buttons, it does not allow us to activate them via the Enter/Return key. To do that, we had to add the following bit of JavaScript trickery:</p>

<pre class="brush: js">    document.onkeydown = function(e) {
    if(e.keyCode === 13) { // The Enter/Return key
        document.activeElement.click();
    }
    };</pre>

<p>Here we add a listener to the <code>document</code> object to detect when a button has been pressed on the keyboard. We check what button was pressed via the event object's <code><a href="https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode">keyCode</a></code> property; if it is the keycode that matches Return/Enter, we run the function stored in the button's <code>onclick</code> handler using <code>document.activeElement.click()</code>. <code><a href="https://developer.mozilla.org/en-US/docs/Web/API/Document/activeElement">activeElement</a></code> gives us the element that is currently focused on the page.</p>

<p>This is a lot of extra hassle to build the functionality back in. And there's bound to be other problems with it. <strong>Better to just use the right element for the right job in the first place.</strong></p>

<h4 id="Meaningful_text_labels">Meaningful text labels</h4>

<p>UI control text labels are very useful to all users, but getting them right is particularly important to users with disabilities.</p>

<p>You should make sure that your button and link text labels are understandable and distinctive. Don't just use "Click here" for your labels, as screenreader users sometimes get up a list of buttons and form controls. The following screenshot shows our controls being listed by VoiceOver on Mac.</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/14335/voiceover-formcontrols.png" style="display: block; height: 604px; margin: 0px auto; width: 802px;"></p>

<p>Make sure your labels make sense out of context, read on their own, as well as in the context of the paragraph they are in. For example, the following shows an example of good link text:</p>

<pre class="brush: html example-good">    &lt;p&gt;Whales are really awesome creatures. &lt;a href="whales.html"&gt;Find out more about whales&lt;/a&gt;.&lt;/p&gt;</pre>

<p>but this is bad link text:</p>

<pre class="brush: html example-bad">    &lt;p&gt;Whales are really awesome creatures. To find more out about whales, &lt;a href="whales.html"&gt;click here&lt;/a&gt;.&lt;/p&gt;</pre>

<div class="note">
<p><strong>Note</strong>: You can find a lot more about link implementation and best practices in our <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML/Creating_hyperlinks">Creating hyperlinks</a> article. You can also see some good and bad examples at <a href="http://mdn.github.io/learning-area/accessibility/html/good-links.html">good-links.html</a> and <a href="http://mdn.github.io/learning-area/accessibility/html/bad-links.html">bad-links.html</a>.</p>
</div>

<p>Form labels are also important, for giving you a clue what you need to enter into each form input. The following seems like a reasonable enough example:</p>

<pre class="brush: html example-bad">    Fill in your name: &lt;input type="text" id="name" name="name"&gt;</pre>

<p>However, this is not so useful for disabled users. There is nothing in the above example to associate the label unambiguously with the form input, and make it clear how to fill it in if you cannot see it. If you access this with some screenreaders, you may only be given a description along the lines of "edit text".</p>

<p>The following is a much better example:</p>

<pre class="brush: html example-good">    &lt;div&gt;
    &lt;label for="name"&gt;Fill in your name:&lt;/label&gt;
    &lt;input type="text" id="name" name="name"&gt;
    &lt;/div&gt;</pre>

<p>With the code like this, the label will be clearly associated with the input; the description will be more like "Fill in your name: edit text".</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/14337/voiceover-good-form-label.png" style="display: block; margin: 0 auto;"></p>

<p>As an added bonus, in most browsers associating a label with a form input means that you can click the label to select/activate the form element. This gives the input a bigger hit area, making it easier to select.</p>

<div class="note">
<p><strong>Note</strong>: you can see some good and bad form examples in <a href="http://mdn.github.io/learning-area/accessibility/html/good-form.html">good-form.html</a> and <a href="http://mdn.github.io/learning-area/accessibility/html/bad-form.html">bad-form.html</a>.</p>
</div>

<h2 id="Accessible_data_tables">Accessible data tables</h2>

<p>A basic data table can be written with very simple markup, for example:</p>

<pre class="brush: html">    &lt;table&gt;
    &lt;tr&gt;
        &lt;td&gt;Name&lt;/td&gt;
        &lt;td&gt;Age&lt;/td&gt;
        &lt;td&gt;Gender&lt;/td&gt;
    &lt;/tr&gt;
    &lt;tr&gt;
        &lt;td&gt;Gabriel&lt;/td&gt;
        &lt;td&gt;13&lt;/td&gt;
        &lt;td&gt;Male&lt;/td&gt;
    &lt;/tr&gt;
    &lt;tr&gt;
        &lt;td&gt;Elva&lt;/td&gt;
        &lt;td&gt;8&lt;/td&gt;
        &lt;td&gt;Female&lt;/td&gt;
    &lt;/tr&gt;
    &lt;tr&gt;
        &lt;td&gt;Freida&lt;/td&gt;
        &lt;td&gt;5&lt;/td&gt;
        &lt;td&gt;Female&lt;/td&gt;
    &lt;/tr&gt;
    &lt;/table&gt;</pre>

<p>But this has problems — there is no way for a screenreader user to associate rows or columns together as groupings of data. To do this you need to know what the header rows are, and if they are heading up rows, columns, etc. This can only be done visually for the above table (see <a href="http://mdn.github.io/learning-area/accessibility/html/bad-table.html">bad-table.html</a> and try the example out yourself).</p>

<p>Now have a look at our <a href="https://github.com/mdn/learning-area/blob/master/css/styling-boxes/styling-tables/punk-bands-complete.html">punk bands table example</a> — you can see a few accessibility aids at work here:</p>

<ul>
 <li>Table headers are defined using {{htmlelement("th")}} elements — you can also specify if they are headers for rows or columns using the <code>scope</code> attribute. This gives you complete groups of data that can be consumed by screen readers as single units.</li>
 <li>The {{htmlelement("caption")}} element and <code>&lt;table&gt;</code> <code>summary</code> attribute both do similar jobs — they act as alt text for a table, giving a screen reader user a useful quick summary of the table's contents. <code>&lt;caption&gt;</code> is generally preferred as it makes it's content accessible to sighted users too, who might also find it useful. You don't really need both.</li>
</ul>

<div class="note">
<p><strong>Note</strong>: See our <a href="/en-US/docs/Learn/HTML/Tables/Advanced">HTML table advanced features and accessibility</a> article for some more details around accessible data tables.</p>
</div>

<h2 id="Text_alternatives">Text alternatives</h2>

<p>Whereas textual content is inherently accessible, the same cannot necessarily be said for multimedia content — image/video content cannot be seen by visually-impaired people, and audio content cannot be heard by hearing-impaired people. We'll cover video and audio content in detail in the Accessible multimedia article later on, but for this article we'll look accessibility for the humble {{htmlelement("img")}} element.</p>

<p>We have a simple example written up, <a href="http://mdn.github.io/learning-area/accessibility/html/accessible-image.html">accessible-image.html</a>, which features four copies of the same image:</p>

<pre>    &lt;img src="dinosaur.png"&gt;

    &lt;img src="dinosaur.png"
        alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth."&gt;

    &lt;img src="dinosaur.png"
        alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth."
        title="The Mozilla red dinosaur"&gt;


    &lt;img src="dinosaur.png" aria-labelledby="dino-label"&gt;

    &lt;p id="dino-label"&gt;The Mozilla red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth.&lt;/p&gt;
    </pre>

<p>The first image, when viewed by a screen reader, doesn't really offer the user much help — VoiceOver for example reads out "/dinosaur.png, image". It reads out the filename to try to provide some help. In this example the user will at least know it is a dinosaur of some kind, but often files may be uploaded with machine generated file names (e.g. from a digital camera) and these file names would likely provide no context to the image's content.</p>

<div class="note">
<p><strong>Note</strong>: This is why you should never include text content inside an image — screen readers simply can't access it. There are other disadvantages too — you can't select it and copy/paste it. Just don't do it!</p>
</div>

<p>When a screen reader encounters the second image, it reads out the full alt attribute — "A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth.".</p>

<p>This highlights the importance of not only using meaningful file names in case so-called <strong>alt text</strong> is not available, but also making sure that alt text is provided in <code>alt</code> attributes wherever possible. Note that the contents of the <code>alt</code> attribute should always provide a direct representation of the image and what it conveys visually. Any personal knowledge or extra description shouldn't be included here, as it is not useful for people who have not come across the image before.</p>

<p>One thing to consider is whether your images have meaning inside your content, or whether they are purely for visual decoration, so have no meaning. If they are decorational, it is better to write an empty text as a value for <code>alt</code> attribute (see <a href="#Empty_alt_attributes">Empty alt attributes</a>) or to just include them in the page as CSS background images.</p>

<div class="note">
<p><strong>Note</strong>: Read <a href="/en-US/docs/Learn/HTML/Multimedia_and_embedding/Images_in_HTML">Images in HTML</a> and <a href="/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">Responsive images</a> for a lot more information about image implementation and best practices.</p>
</div>

<p>If you do want to provide extra contextual information, you should put it in the text surrounding the image, or inside a <code>title</code> attribute, as shown above. In this case, most screenreaders will read out the alt text, the title attribute, and the filename. In addition, browsers display title text as tooltips when moused over.</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/14333/title-attribute.png" style="display: block; margin: 0 auto;"></p>

<p>Let's have another quick look at the fourth method:</p>

<pre class="brush: html">    &lt;img src="dinosaur.png" aria-labelledby="dino-label"&gt;

    &lt;p id="dino-label"&gt;The Mozilla red Tyrannosaurus ... &lt;/p&gt;</pre>

<p>In this case, we are not using the <code>alt</code> attribute at all — instead, we have presented our description of the image as a regular text paragraph, given it an <code>id</code>, and then used the <code>aria-labelledby</code> attribute to refer to that <code>id</code>, which causes screenreaders to use that paragraph as the alt text/label for that image. This is especially useful if you want to use the same text as a label for multiple images — something that isn't possible with <code>alt</code>.</p>

<div class="note">
<p><strong>Note</strong>: <code>aria-labelledby</code> is part of the <a href="https://www.w3.org/TR/wai-aria-1.1/">WAI-ARIA</a> spec, which allows developers to add in extra semantics to their markup to improve screenreader accessibility where needed. To find out more about how it works, read our <a href="/en-US/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA Basics</a> article.</p>
</div>

<h3 id="Other_text_alternative_mechanisms">Other text alternative mechanisms</h3>

<p>Images also have another mechanisms available for providing descriptive text. For example, there is a <code>longdesc</code> attribute that is meant to point to a separate web document containing an extended description of the image, for example:</p>

<pre class="brush: html">    &lt;img src="dinosaur.png" longdesc="dino-info.html"&gt;</pre>

<p>This sounds like a good idea, especially for infographics like big charts with lots of information on that could perhaps be represented as an accessible data table instead (see previous section). However, <code>longdesc</code> is not supported consistently by screenreaders, and the content is completely inaccessible to non-screenreader users. It is arguably much better to include the long description on the same page as the image, or link to it with a regular link.</p>

<p>HTML5 includes two new elements — {{htmlelement("figure")}} and {{htmlelement("figcaption")}} — which are supposed to associate a figure of some kind (it could be anything, not necessarily an image) with a figure caption:</p>

<pre class="brush: html">    &lt;figure&gt;
    &lt;img src="dinosaur.png" alt="The Mozilla Tyrannosaurus"&gt;
    &lt;figcaption&gt;A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth.&lt;/figcaption&gt;
    &lt;/figure&gt;</pre>

<p>Unfortunately, most screenreaders don't seem to associate figure captions with their figures yet, but the element structure is useful for CSS styling, plus it provides a way to place a description of the image next to it in the source.</p>

<h3 id="Empty_alt_attributes">Empty alt attributes</h3>

<pre class="brush: html">    &lt;h3&gt;
    &lt;img src="article-icon.png" alt=""&gt;
    Tyrannosaurus Rex: the king of the dinosaurs
    &lt;/h3&gt;</pre>

<p>There may be times where an image is included in a page's design, but its primary purpose is for visual decoration. You'll notice in the code example above that the image's <code>alt</code> attribute is empty — this is to make screen readers recognize the image, but not attempt to describe the image (instead they'd just say "image", or similar).</p>

<p>The reason to use an empty <code>alt</code> instead of not including it is because many screen readers announce the whole image URL if no <code>alt</code> is provided.  In the above example, the image is acting as a visual decoration to the heading its associated with. In cases like this, and in cases where an image is only decoration and has no content value, you should put an empty <code>alt</code> on your images. Another alternative is to use the aria role attribute role="presentation" — this also stops screens readers from reading out alternative text.</p>

<div class="note">
<p><strong>Note</strong>: if possible you should use CSS to display images that are only decoration.</p>
</div>

<h2 id="Summary">Summary</h2>

<p>You should now be well-versed in writing accessible HTML for most occasions. Our WAI-ARIA basics article will also fill in some gaps in this knowledge, but this article has taken care of the basics. Next up we'll explore CSS and JavaScript, and how accessibility is affected by their good or bad use.</p>

<p>{{PreviousMenuNext("Learn/Accessibility/What_is_Accessibility","Learn/Accessibility/CSS_and_JavaScript", "Learn/Accessibility")}}</p>

<h2 id="In_this_module">In this module</h2>

<ul>
 <li><a href="/en-US/docs/Learn/Accessibility/What_is_accessibility">What is accessibility?</a></li>
 <li><a href="/en-US/docs/Learn/Accessibility/HTML">HTML: A good basis for accessibility</a></li>
 <li><a href="/en-US/docs/Learn/Accessibility/CSS_and_JavaScript">CSS and JavaScript accessibility best practices</a></li>
 <li><a href="/en-US/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA basics</a></li>
 <li><a href="/en-US/docs/Learn/Accessibility/Multimedia">Accessible multimedia</a></li>
 <li><a href="/en-US/docs/Learn/Accessibility/Mobile">Mobile accessibility</a></li>
 <li><a href="/en-US/docs/Learn/Accessibility/Accessibility_troubleshooting">Accessibility troubleshooting</a></li>
</ul>