diff options
Diffstat (limited to 'files/ko/learn/accessibility/html/index.html')
| -rw-r--r-- | files/ko/learn/accessibility/html/index.html | 537 |
1 files changed, 537 insertions, 0 deletions
diff --git a/files/ko/learn/accessibility/html/index.html b/files/ko/learn/accessibility/html/index.html new file mode 100644 index 0000000000..dae842fc92 --- /dev/null +++ b/files/ko/learn/accessibility/html/index.html @@ -0,0 +1,537 @@ +--- +title: 'HTML: 접근성을 위한 기초' +slug: Learn/접근성/HTML +tags: + - HTML + - 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">HTML 요소가 늘 올바른 목적을 가지고 쓰이는지 확인하는 것만으로도, 수많은 웹 콘텐츠는 접근성이 향상됩니다. 이 문서에는 접근성을 최대한으로 보장하기 위해 HTML을 어떻게 사용해야 하는지 자세히 설명합니다.</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">Prerequisites:</th> + <td>Basic computer literacy, a basic understanding of HTML (see <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML">Introduction to HTML</a>), and understanding of <a href="/en-US/docs/Learn/Accessibility/What_is_accessibility">what accessibility is</a>.</td> + </tr> + <tr> + <th scope="row">Objective:</th> + <td>To gain familiarity with what features of HTML have accessibility benefits, and how to use them appropriately in your web documents.</td> + </tr> + </tbody> +</table> + +<h2 id="HTML과_접근성">HTML과 접근성</h2> + +<p> </p> + +<p>HTML에 대해 더 많은 자료와 예제를 접하고, 더 많이 배우면 배울수록 당신은 의미론적 HTML(시멘틱 HTML, POSH 또는 Plain Old Semantic HTML라고 부르기도 합니다)을 사용하는 것이 중요하다는 공통 주제를 계속해서 접하게 될 것입니다. 이것은 가능한 올바른 목적으로 올바른 HTML 요소를 사용하는 것을 의미합니다.</p> + +<p>당신은 아마 이것이 왜 중요한지 의문을 가질 수 있을 것입니다. 당신은 CSS와 JavaScript 조합을 사용해 원하는 방식으로 HTML 요소들을 동작시킬 수 있기 때문입니다. 예를 들어 사이트에서 동영상을 제어하기 위한 버튼을 당신은 이렇게 마크업 할 수 있습니다.</p> + +<pre class="brush: html"><div>Play video</div></pre> + +<p>그러나 당신이 나중에 더 자세하게 배울수록, 작업에 올바른 HTML 요소를 사용하는 것이 많은 의미를 내포하고 있음을 깨닫게 될 것입니다.</p> + +<pre class="brush: html"><button>Play video</button></pre> + +<p>Not only do HTML <code><button></code>s have some suitable styling applied by default (which you will probably want to override), they also have built-in keyboard accessibility — they can be tabbed between, and activated using Return/Enter.</p> + +<p>Semantic HTML doesn't take longer to write than non-semantic (bad) markup if you do it consistently from the start of your project, and it also has other benefits beyond accessibility:</p> + +<ol> + <li><strong>Easier to develop with</strong> — as mentioned above, you get some functionality for free, plus it is arguably easier to understand.</li> + <li><strong>Better on mobile</strong> — semantic HTML is arguably lighter in file size than non-semantic spaghetti code, and easier to make responsive.</li> + <li><strong>Good for SEO</strong> — search engines give more importance to keywords inside headings, links, etc., than keywords included in non-semantic <code><div></code>s, etc., so your documents will be more findable by customers.</li> +</ol> + +<p>Let's get on and look at accessible HTML in more detail.</p> + +<div class="note"> +<p><strong>Note</strong>: It is a good idea to have a screenreader set up on your local computer, so you can do some testing of the examples shown below. See our <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Screenreaders">Screenreaders guide</a> for more details.</p> +</div> + +<h2 id="Good_semantics">Good semantics</h2> + +<p>We've already talked about the importance of good semantics, and why we should use the right HTML element for the right job. This cannot be ignored, as it is one of the main places that accessibility is badly broken if not handled properly.</p> + +<p>Out there on the web, the truth is that people do some very strange things with HTML markup. Some abuses of HTML are due to legacy practices that have not been completely forgotten, and some are just plain ignorance. Whatever the case, you should replace such bad code wherever you see it, whenever you can.</p> + +<p>Sometimes you are not always in the position to get rid of bad markup — your pages might be generated by some kind of server-side framework that you don't have full control over, or you might have third party content on your page (such as ad banners) that you don't have control over.</p> + +<p>The goal isn't "all or nothing", however — every improvement you are able to make will help the cause of accessibility.</p> + +<h3 id="Text_content">Text content</h3> + +<p>One of the best accessibility aids a screenreader user can have is a good content structure of headings, paragraphs, lists, etc. A good semantic example might look something like the following:</p> + +<pre class="brush: html example-good line-numbers language-html"><code class="language-html"><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>h1</span><span class="punctuation token">></span></span>My heading<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>h1</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>p</span><span class="punctuation token">></span></span>This is the first section of my document.<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>p</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>p</span><span class="punctuation token">></span></span>I'll add another paragraph here too.<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>p</span><span class="punctuation token">> + +<ol> + <li>Here is</li> + <li>a list for</li> + <li>you to read</li> +</ol></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>h2</span><span class="punctuation token">></span></span>My subheading<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>h2</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>p</span><span class="punctuation token">></span></span>This is the first subsection of my document. I'd love people to be able to find this content!<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>p</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>h2</span><span class="punctuation token">></span></span>My 2nd subheading<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>h2</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>p</span><span class="punctuation token">></span></span>This is the second subsection of my content. I think is more interesting than the last one.<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>p</span><span class="punctuation token">></span></span></code></pre> + +<p>We've prepared a version with longer text for you to try out with a screenreader (see <a href="http://mdn.github.io/learning-area/accessibility/html/good-semantics.html">good-semantics.html</a>). If you try navigating through this, you'll see that this is pretty easy to navigate:</p> + +<ol> + <li>The screenreader reads each header out as you progress through the content, notifying you what is a heading, what is a paragraph, etc.</li> + <li>It stops after each element, letting you go at whatever pace is comfortable for you.</li> + <li>You can jump to next/previous heading in many screenreaders.</li> + <li>You can also bring up a list of all headings in many screenreaders, allowing you to use them like a handy table of contents to find specific content.</li> +</ol> + +<p>People sometimes write headings, paragraphs, etc. using presentational HTML and line breaks, something like the following:</p> + +<pre class="brush: html example-bad line-numbers language-html"><code class="language-html"><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>font</span> <span class="attr-name token">size</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>7<span class="punctuation token">"</span></span><span class="punctuation token">></span></span>My heading<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>font</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +This is the first section of my document. +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +I'll add another paragraph here too. +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">> +1. Here is +</span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">> +2. a list for +</span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">> +3. you to read +</span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>font</span> <span class="attr-name token">size</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>5<span class="punctuation token">"</span></span><span class="punctuation token">></span></span>My subheading<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>font</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +This is the first subsection of my document. I'd love people to be able to find this content! +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>font</span> <span class="attr-name token">size</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>5<span class="punctuation token">"</span></span><span class="punctuation token">></span></span>My 2nd subheading<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>font</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +This is the second subsection of my content. I think is more interesting than the last one.</code></pre> + +<p>If you try our longer version out with a screenreader (see <a href="http://mdn.github.io/learning-area/accessibility/html/bad-semantics.html">bad-semantics.html</a>), you'll not have a very good experience — the screenreader hasn't got anything to use as signposts, so you can't retrieve a useful table of contents, and the whole page is seen as a single giant block, so it is just read out in one go, all at once.</p> + +<p>There are other issues too beyond accessibility — it is harder to style the content using CSS, or manipulate it with JavaScript for example, because there are no elements to use as selectors.</p> + +<h4 id="Using_clear_language">Using clear language</h4> + +<p>The language you use can also affect accessibility. In general you should use clear language that is not overly complex, and doesn't use unnecessary jargon or slang terms. This not only benefits people with cognitive or other disabilities; it benefits readers for whom the text is not written in their first language, younger people ... everyone in fact! Apart from this, you should try to avoid using language and characters that don't get read out clearly by the screenreader. For example:</p> + +<ul> + <li>Don't use dashes if you can avoid it. Instead of writing 5–7, write 5 to 7.</li> + <li>Expand abbreviations — instead of writing Jan, write January.</li> + <li>Expand acronyms, at least once or twice. Instead of writing HTML in the first instance, write Hypertext Markup Language.</li> +</ul> + +<h3 id="Page_layouts">Page layouts</h3> + +<p>In the bad old days, people used to create page layouts using HTML tables — using different table cells to contain the header, footer, side bar, main content column, etc. This is not a good idea because a screenreader will likely give out confusing readouts, especially if the layout is complex and has many nested tables.</p> + +<p>Try our example <a href="http://mdn.github.io/learning-area/accessibility/html/table-layout.html">table-layout.html</a> example, which looks something like this:</p> + +<pre class="brush: html"><table width="1200"> + <!-- main heading row --> + <tr id="heading"> + <td colspan="6"> + + <h1 align="center">Header</h1> + + </td> + </tr> + <!-- nav menu row --> + <tr id="nav" bgcolor="#ffffff"> + <td width="200"> + <a href="#" align="center">Home</a> + </td> + <td width="200"> + <a href="#" align="center">Our team</a> + </td> + <td width="200"> + <a href="#" align="center">Projects</a> + </td> + <td width="200"> + <a href="#" align="center">Contact</a> + </td> + <td width="300"> + <form width="300"> + <input type="search" name="q" placeholder="Search query" width="300"> + </form> + </td> + <td width="100"> + <button width="100">Go!</button> + </td> + </tr> + <!-- spacer row --> + <tr id="spacer" height="10"> + <td> + + </td> + </tr> + <!-- main content and aside row --> + <tr id="main"> + <td id="content" colspan="4" bgcolor="#ffffff"> + + <!-- main content goes here --> + </td> + <td id="aside" colspan="2" bgcolor="#ff80ff" valign="top"> + <h2>Related</h2> + + <!-- aside content goes here --> + + </td> + </tr> + <!-- spacer row --> + <tr id="spacer" height="10"> + <td> + + </td> + </tr> + <!-- footer row --> + <tr id="footer" bgcolor="#ffffff"> + <td colspan="6"> + <p>©Copyright 2050 by nobody. All rights reversed.</p> + </td> + </tr> + </table></pre> + +<p>If you try to navigate this using a screenreader, it will probably tell you that there's a table to be looked at (although some screenreaders can guess the difference between table layouts and data tables). You'll then likely (depending on which screenreader you're using) have to go down into the table as an object and look at its features separately, then get out of the table again to carry on navigating the content.</p> + +<p>Table layouts are a relic of the past — they made sense back when CSS support was not widespread in browsers, but they create confusion for screenreader users, as well as being bad for many other reasons (abuse of tables, arguably requires more markup, make designs more inflexible). Don't do it!</p> + +<p>You can verify these claims by comparing your previous experience with a <a href="http://mdn.github.io/learning-area/html/introduction-to-html/document_and_website_structure/">more modern website structure example</a>, which could look something like this:</p> + +<pre class="brush: html"><header> + <h1>Header</h1> +</header> + +<nav> + <!-- main navigation in here --> +</nav> + +<!-- Here is our page's main content --> +<main> + + <!-- It contains an article --> + <article> + <h2>Article heading</h2> + + <!-- article content in here --> + </article> + + <aside> + <h2>Related</h2> + + <!-- aside content in here --> + </aside> + +</main> + +<!-- And here is our main footer that is used across all the pages of our website --> + +<footer> + <!-- footer content in here --> +</footer></pre> + +<p>If you try our more modern structure example with a screenreader, you'll see that the layout markup no longer gets in the way and confuses the content readout. It is also much leaner and smaller in terms of code size, which means easier to maintain code, and less bandwidth for the user to download (particularly prevalent for those on slow connections).</p> + +<p>Another consideration when creating layouts is using HTML5 semantic elements as seen in the above example (see <a href="/en-US/docs/Web/HTML/Element#Content_sectioning">content sectioning</a>) — you can create a layout using only nested {{htmlelement("div")}} elements, but it is better to use appropriate sectioning elements to wrap your main navigation ({{htmlelement("nav")}}), footer ({{htmlelement("footer")}}), repeating content units ({{htmlelement("article")}}), etc. These provide extra semantics for screenreaders (and other tools) to give user extra clues about the content they are navigating (see <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> for an idea of what screen reader support is like).</p> + +<div class="note"> +<p><strong>Note</strong>: As well as your content having good semantics and an attractive layout, it should make logical sense in its source order — you can always place it where you want using CSS later on, but you should get the source order right to start with, so what screenreader users get read out to them will make sense.</p> +</div> + +<h3 id="UI_controls">UI controls</h3> + +<p>By UI controls, we mean the main parts of web documents that users interact with — most commonly buttons, links, and form controls. In this section we'll look at the basic accessibility concerns to be aware of when creating such controls. Later articles on WAI-ARIA and multimedia will look at other aspects of UI accessibility.</p> + +<p>One key aspect to the accessibility of UI controls is that by default, browsers allow them to be manipulated by the keyboard. You can try this out using our <a href="http://mdn.github.io/learning-area/tools-testing/cross-browser-testing/accessibility/native-keyboard-accessibility.html">native-keyboard-accessibility.html</a> example (see the <a href="https://github.com/mdn/learning-area/blob/master/tools-testing/cross-browser-testing/accessibility/native-keyboard-accessibility.html">source code</a>) — open this in a new tab, and try pressing the tab key; after a few presses, you should see the tab focus start to move through the different focusable elements; the focused elements are given a highlighted default style in every browser (it differs slightly between different browsers) so that you can tell what element is focused.</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>You can then press Enter/Return to follow a focused link or press a button (we've included some JavaScript to make the buttons alert a message), or start typing to enter text in a text input (other form elements have different controls, for example the {{htmlelement("select")}} element can have its options displayed and cycled between using the up and down arrow keys).</p> + +<div class="note"> +<p><strong>Note</strong>: Different browsers may have different keyboard control options available. See <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Using_native_keyboard_accessibility">Using native keyboard accessibility</a> for more details.</p> +</div> + +<p>You essentially get this behavior for free, just by using the appropriate elements, e.g.</p> + +<pre class="brush: html example-good"><h1>Links</h1> + +<p>This is a link to <a href="https://www.mozilla.org">Mozilla</a>.</p> + +<p>Another link, to the <a href="https://developer.mozilla.org">Mozilla Developer Network</a>.</p> + +<h2>Buttons</h2> + +<p> + <button data-message="This is from the first button">Click me!</button> + <button data-message="This is from the second button">Click me too!</button> + <button data-message="This is from the third button">And me!</button> +</p> + +<h2>Form</h2> + +<form> + <div> + <label for="name">Fill in your name:</label> + <input type="text" id="name" name="name"> + </div> + <div> + <label for="age">Enter your age:</label> + <input type="text" id="age" name="age"> + </div> + <div> + <label for="mood">Choose your mood:</label> + <select id="mood" name="mood"> + <option>Happy</option> + <option>Sad</option> + <option>Angry</option> + <option>Worried</option> + </select> + </div> +</form></pre> + +<p>This means using links, buttons, form elements, and labels appropriately (including the {{htmlelement("label")}} element for form controls).</p> + +<p>However, it is again the case that people sometimes do strange things with HTML. For example, you sometimes see buttons marked up using {{htmlelement("div")}}s, for example:</p> + +<pre class="brush: html example-bad"><div data-message="This is from the first button">Click me!</div> +<div data-message="This is from the second button">Click me too!</div> +<div data-message="This is from the third button">And me!</div></pre> + +<p>But using such code is not advised — you immediately lose the native keyboard accessibility you would have had if you'd just used {{htmlelement("button")}} elements, plus you don't get any of the default CSS styling that buttons get.</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><div></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"><div data-message="This is from the first button" tabindex="0">Click me!</div> +<div data-message="This is from the second button" tabindex="0">Click me too!</div> +<div data-message="This is from the third button" tabindex="0">And me!</div></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 line-numbers language-js"><code class="language-js">document<span class="punctuation token">.</span>onkeydown <span class="operator token">=</span> <span class="keyword token">function</span><span class="punctuation token">(</span>e<span class="punctuation token">)</span> <span class="punctuation token">{</span> + <span class="keyword token">if</span><span class="punctuation token">(</span>e<span class="punctuation token">.</span>keyCode <span class="operator token">===</span> <span class="number token">13</span><span class="punctuation token">)</span> <span class="punctuation token">{</span> <span class="comment token">// The Enter/Return key</span> + document<span class="punctuation token">.</span>activeElement<span class="punctuation token">.</span><span class="function token">click</span><span class="punctuation token">(</span><span class="punctuation token">)</span><span class="punctuation token">;</span> + <span class="punctuation token">}</span> +<span class="punctuation token">}</span><span class="punctuation token">;</span></code></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"><p>Whales are really awesome creatures. <a href="whales.html">Find out more about whales</a>.</p></pre> + +<p>but this is bad link text:</p> + +<pre class="brush: html example-bad"><p>Whales are really awesome creatures. To find more out about whales, <a href="whales.html">click here</a>.</p></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: <input type="text" id="name" name="name"></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"><div> + <label for="name">Fill in your name:</label> + <input type="text" id="name" name="name"> +</div></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"><table> + <tr> + <td>Name</td> + <td>Age</td> + <td>Gender</td> + </tr> + <tr> + <td>Gabriel</td> + <td>13</td> + <td>Male</td> + </tr> + <tr> + <td>Elva</td> + <td>8</td> + <td>Female</td> + </tr> + <tr> + <td>Freida</td> + <td>5</td> + <td>Female</td> + </tr> +</table></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><table></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><caption></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><img src="dinosaur.png"> + +<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."> + +<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"> + + +<img src="dinosaur.png" aria-labelledby="dino-label"> + +<p id="dino-label">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.</p> +</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 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"><img src="dinosaur.png" aria-labelledby="dino-label"> + +<p id="dino-label">The Mozilla red Tyrannosaurus ... </p></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"><img src="dinosaur.png" longdesc="dino-info.html"></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"><figure> + <img src="dinosaur.png" alt="The Mozilla Tyrannosaurus"> + <figcaption>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.</figcaption> +</figure></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"><h3> + <img src="article-icon.png" alt=""> + Tyrannosaurus Rex: the king of the dinosaurs +</h3></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> + +<p> </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> + +<p> </p> |