diff options
Diffstat (limited to 'files/ko/learn/접근성')
| -rw-r--r-- | files/ko/learn/접근성/html/index.html | 537 | ||||
| -rw-r--r-- | files/ko/learn/접근성/index.html | 59 | ||||
| -rw-r--r-- | files/ko/learn/접근성/what_is_accessibility/index.html | 205 | ||||
| -rw-r--r-- | files/ko/learn/접근성/모바일/index.html | 315 |
4 files changed, 1116 insertions, 0 deletions
diff --git a/files/ko/learn/접근성/html/index.html b/files/ko/learn/접근성/html/index.html new file mode 100644 index 0000000000..dae842fc92 --- /dev/null +++ b/files/ko/learn/접근성/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> diff --git a/files/ko/learn/접근성/index.html b/files/ko/learn/접근성/index.html new file mode 100644 index 0000000000..01c9c2e2bb --- /dev/null +++ b/files/ko/learn/접근성/index.html @@ -0,0 +1,59 @@ +--- +title: 접근성 +slug: Learn/접근성 +tags: + - ARIA + - CSS + - HTML + - JavaScript + - 랜딩 + - 모듈 + - 문서 + - 배우기 + - 비기너 + - 접근성 +translation_of: Learn/Accessibility +--- +<div>{{LearnSidebar}}</div> + +<p class="summary"><font><font>웹 개발자가 되기위해서 HTML, CSS 및 JavaScript를 배우는 것이 필요하지만 배운 지식을 효과적으로 사용하기위해서는 지식이상의 기술이 필요로 합니다. 이 기술을 사용해서 웹사이트에 접근하려는 모든 사용자를 차별없이 접근할수 있도록 해야합니다. 이를 위하여</font><font> 모범 사례(</font></font><a href="https://developer.mozilla.org/ko/docs/Learn/HTML"><font><font>HTML</font></font></a><font><font>, </font></font><a href="https://developer.mozilla.org/ko/docs/Learn/CSS"><font><font>CSS</font></font></a><font><font> 및 </font></font><a href="https://developer.mozilla.org/ko/docs/Learn/JavaScript"><font><font>JavaScript</font></font></a><font><font> 항목에서 설명) </font><font>를 준수하고 </font></font><a href="https://developer.mozilla.org/ko/docs/Learn/Tools_and_testing/Cross_browser_testing"><font><font>브라우저 호환성 테스트를 거치며</font></font></a><font><font> 처음부터 접근성을 고려해야합니다. </font><font>이 문서에서는 후자에 대해 자세히 다룰 것입니다.</font></font></p> + +<h2 id="선결조건">선결조건</h2> + +<p><font><font>이 문서를 최대한 활용하려면 최소한 </font></font><a href="https://developer.mozilla.org/ko/docs/Learn/HTML"><font><font>HTML</font></font></a><font><font>, </font></font><a href="https://developer.mozilla.org/ko/docs/Learn/CSS"><font><font>CSS</font></font></a><font><font> 및 </font></font><a href="https://developer.mozilla.org/ko/docs/Learn/JavaScript"><font><font>JavaScript</font></font></a><font><font> 항목 </font><font>중 처음 두 문서를 </font><font>통해 작업하거나 또는 접근성 문서와 관련된 기술을 통해 개선해 나가는것이 좋습니다. </font></font></p> + +<div class="note"> +<p><strong>Note</strong>: <strong><font><font>참고</font></font></strong><font><font> : 당신은 당신이 당신의 자신의 파일을 생성 할 수있는 기능이없는 컴퓨터 / 태블릿 / 다른 장치에서 작업하는 경우, 당신은 </font></font><a href="http://jsbin.com/">JSBin</a> 또는 <a href="https://thimble.mozilla.org/">Thimble</a> <font><font>같은 온라인 코딩 프로그램에서 코드 예제의 대부분을 테스트 할수 있습니다.</font></font></p> +</div> + +<h2 id="가이드">가이드</h2> + +<dl> + <dt><a href="/ko/docs/Learn/Accessibility/What_is_accessibility">접근성이란?</a></dt> + <dd>이 문서에서는 접근성이 실제로 무엇인지 자세히 살펴보는 것으로 모듈을 시작합니다. 여기에는 고려해야 할 사람의 그룹, 웹과 상호 작용하는 데 사용하는 서로 다른 도구 및 접근성 워크 플로우를 개발하는 방법이 포함됩니다.</dd> + <dt><a href="/ko/docs/Learn/Accessibility/HTML">HTML: 접근성을 위한 좋은기초</a></dt> + <dd>항상 올바른 HTML요소를 올바른 용도로 사용하는 것만으로 수많은 웹 콘텐츠에 접근 할 수 있습니다. 이 문서는 접근성을 극대화하기 위해 HTML을 사용하는 방법을 자세히 살펴봅니다.</dd> + <dt><a href="/ko/docs/Learn/Accessibility/CSS_and_JavaScript">CSS 와 JavaScript의 접근성 모범 사례</a></dt> + <dd>또한, CSS 와 JavaScript를 적절히 사용하면 접근성 높은 웹 경험을 줄수도 있지만 , 만약 잘못 사용될 경우 접근성을 크게 해칠 수 있다. 이 문서에서는 복잡한 컨텐츠도 가능한 액세스 할 수 있도록 하기 위해 고려해야 할 몇가지 CSS 및 JavaScript모범 사례를 간략히 설명합니다.</dd> + <dt><a href="/ko/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA 기초</a></dt> + <dd>이전 문서에 이어, 시맨틱하지 못한 HTML과 동적 자바 스크립트로 업데이트되는 컨텐츠를 포함하는 복잡한 UI를 제어 하는 것은 어려울 수 있습니다. WAI-ARIA는 브라우저와 보조 기술이 사용자에게 상황을 알려 주는 데 사용할 수 있는 시맨틱한 요소를 추가하여 이러한 문제를 해결하는 기술이다. 여기서는 접근성을 향상시키기 위해 기본적인 수준에서 이 기능을 사용하는 방법을 보여 줍니다.</dd> + <dt><a href="/ko/docs/Learn/Accessibility/Multimedia">멀티미디어 접근성</a></dt> + <dd>접근성 문제를 야기할 수 있는 또 다른 범주의 콘텐츠 즉 멀티 미디어 . 비디오, 오디오 및 이미지 콘텐츠에 적절한 대체텍스트를 제공해서 보조 기술과 사용자가 이해할 수 있도록 해야 한다. 이 글은 그 방법을 보여 준다.</dd> + <dt><a href="/ko/docs/Learn/Accessibility/Mobile">모바일 접근성</a></dt> + <dd>모바일 기기를 이용한 웹 접근이 매우 널리 사용되고 있고 iOS및 Android와 같은 유명한 플랫폼에서 액세스가 가능한 툴을 사용하는 경우, 이러한 플랫폼에서 웹 콘텐츠를 접근 할 수 있는지를 고려해야 합니다. 이 자료에서는 모바일 접근성 고려 사항에 대해 살펴봅니다.</dd> +</dl> + +<h2 id="평가">평가</h2> + +<dl> + <dt><a href="/ko/docs/Learn/Accessibility/Accessibility_troubleshooting">접근성 문제 해결 </a></dt> + <dd>평가에서는 진단 및 해결해야 하는 다양한 접근성 문제가 포함된 간단한 사이트를 제공합니다.</dd> +</dl> + +<h2 id="참고_항목">참고 항목</h2> + +<ul> + <li><a href="https://egghead.io/courses/start-building-accessible-web-applications-today">Start Building Accessible Web Applications Today</a> — an excellent series of video tutorials by Marcy Sutton.</li> + <li><a href="https://dequeuniversity.com/resources/">Deque University resources</a> — includes code examples, screen reader references, and other useful resources.</li> + <li><a href="http://webaim.org/resources/">WebAIM resources</a> — includes guides, checklists, tools, and more.</li> +</ul> diff --git a/files/ko/learn/접근성/what_is_accessibility/index.html b/files/ko/learn/접근성/what_is_accessibility/index.html new file mode 100644 index 0000000000..67f4b6d302 --- /dev/null +++ b/files/ko/learn/접근성/what_is_accessibility/index.html @@ -0,0 +1,205 @@ +--- +title: What is accessibility? +slug: Learn/접근성/What_is_accessibility +translation_of: Learn/Accessibility/What_is_accessibility +--- +<p>{{LearnSidebar}}</p> + +<p>{{NextMenu("Learn/Accessibility/HTML", "Learn/Accessibility")}}</p> + +<p>이 글에서는 접근성이 실제로 무엇인지 자세히 살펴보기로 합니다. 이 글에는 웹에서 고려해야 할 사람의 그룹, 웹과 상호 작용하는 데 사용하는 서로 다른 도구 및 접근성 개발 워크 플로우를 포함됩니다.</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">선행지식:</th> + <td>기본적인 컴퓨터 사용 능력, HTML과 CSS에 대한 기본적인 이해.</td> + </tr> + <tr> + <th scope="row">목표:</th> + <td>접근성과 친해지기. 웹 개발자로서 접근성에어떻게 영향을 미치는지 알아보기</td> + </tr> + </tbody> +</table> + +<h2 id="그렇다면_접근성이란_무엇일까요">그렇다면 접근성이란 무엇일까요?</h2> + +<p>접근성은 가능한 한 많은 사람이 웹 사이트를 사용할 수 있도록 하는 방법으로, 통상적으로 장애인만을 대상으로 한다고 생각하지만 실제로는 모바일 장치를 사용하는 사람이나 느린 네트워크 연결을 사용하는 사람들도 포함하고 있습니다.</p> + +<p>접근성을 모든 사람을 동일하게 대하고, 그들의 능력이나 상황에 상관 없이 그들에게 같은 기회를 주는 것으로 생각할 수도 있습니다. 휠체어에 있기 때문에 누군가를 물리적 건물에서 제외시키는 것이 옳지 않은 것과 같은 방식으로(공공 건물에는 일반적으로 휠체어 경사로나 엘리베이터가 있기 때문에), 휴대 전화를 사용하지 않는 사람을 웹 사이트에서 제외시키는 것도 옳지 않다. 우리는 모두 다르지만, 모두 인간이기 때문에, 동일한 권리를 갖고 있다.</p> + +<p>접근성은 당연히 지켜져야 할 일이지만 일부 국가에서는 법의 일부이기도 하며, 서비스 사용이나 제품 구매가 불가능했던 사람들을 불러모아 중요한 소비자들로 만들수도 있습니다.</p> + +<p>접근성 및 이에 따른 모범 사례는 다음과 같은 모든 사람에게 도움이 될 수 있습니다.</p> + +<ul> + <li>시맨틱한 HTML (접근성이 향상된)은 SEO 향상시켜, 사이트를 찾기 쉽고 시장성이 있도록 해준다.</li> + <li>접근성에 대해 고려하는것은 좋은 윤리적인 도덕 관념을 보여 주는데, 이것은 서비스의 대중적인 이미지를 개선시킵니다.</li> + <li>접근성을 향상시키는 다른 좋은 방법은 당신의 사이트를 휴대폰 사용자, 낮은 네트워크 속도의 사용자등 다른 여러 사용자가 사용하기 쉽게 만든다.</li> + <li> + <p>우리가 어느 지역에서는 이것이 법의 적용을 받는다고 언급한 적이 있나요?</p> + </li> +</ul> + +<h2 id="어떤_종류의_장애를_본_적이_있습니까">어떤 종류의 장애를 본 적이 있습니까?</h2> + +<p>장애가 있는 사람들도 장애가 없는 사람들만큼이나 다양하고, 그만큰 그들의 장애유형도 다양합니다. 여기서 중요한 교훈은 자신이 컴퓨터와 웹을 어떻게 사용하는 지에 대해 생각하고 다른 사람들이 웹을 어떻게 사용하는 지에 대해 배우는 것이다.</p> + +<p>장애의 주요 유형은 웹 콘텐츠에 액세스 하는 데 사용하는 전문 도구와 함께 아래에 설명되어 있습니다.(흔히 보조공학기기또는 보조기술 이라고 알려진).</p> + +<div class="note"> +<p><strong>Note</strong>: 세계 보건 기구(WHO)의 장애 및 보건 현황 보고서에 따르면 전 세계 인구의 약 15%에 해당하는 십억명 이상의 사람들이 장애를 갖고 있으며 1억 1천만명에서 1억 9천만명의 성인들이 심각한 장애를 갖고 있다.</p> + +<p> </p> +</div> + +<h3 id="시각장애인">시각장애인</h3> + +<p>여기에는 전맹, 저시력 장애인 색각장애인등이 포함되며 이런 많은 사람들이 화면확대경(물리적 확대경 또는 소프트웨어 줌 기능 - 대부분의 브라우저와 운영 체제에는 최근 확대 / 축소 기능이 있음)과 디지털 글자를 큰소리로 읽어주는 소프트웨어인 화면낭독기를 사용한다.</p> + +<ul> + <li>일부는 <a class="external external-icon" href="http://www.freedomscientific.com/Products/Blindness/JAWS">JAWS</a> (Windows) 와 <a class="external external-icon" href="http://www.gwmicro.com/window-eyes/">Window Eyes</a> (Windows) 같은 상업적인 제품을 사용한다.</li> + <li>일부는 <a class="external external-icon" href="http://www.nvaccess.org/">NVDA</a> (Windows), <a class="external external-icon" href="http://www.chromevox.com/">ChromeVox</a> (Chrome, Windows and Mac OS X), 와 <a class="external external-icon" href="https://wiki.gnome.org/Projects/Orca">Orca</a> (Linux) 같은 무료 소프트웨어를 사용하기도 한다.</li> + <li>일부는 <a class="external external-icon" href="http://www.apple.com/accessibility/osx/voiceover/">VoiceOver</a> (Mac OS X and iOS), <a class="external external-icon" href="https://support.microsoft.com/en-us/help/22798/windows-10-narrator-get-started">Narrator</a> (Microsoft Windows), <a class="external external-icon" href="http://www.chromevox.com/">ChromeVox</a> (on Chrome OS), <a class="external external-icon" href="https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback">TalkBack</a> (Android)과 같은 OS에 장착된 소프트 웨어를 사용하기도 한다.</li> +</ul> + +<p> </p> + +<p>스크린 리더들과 친숙해 지는 것은 좋은 생각이다; 당신은 또한 스크린 리더를 설치하고 그것을 가지고 노는 것이 어떻게 작동하는 지에 대한 아이디어를 얻기 위해서 필요하다. 사용에 대한 자세한 내용은 크로스 브라우저 테스트 화면 판독기 가이드( <a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Screenreaders">cross browser testing screen readers guide</a>)를 참조하십시오. 아래의 비디오는 또한 경험이 어떠한지에 대한 간단한 예를 제공한다.</p> + +<p>{{EmbedYouTube("IK97XMibEws")}}</p> + +<p> </p> + +<p>In terms of statistics, the World Health Organization estimates that "285 million people are estimated to be visually impaired worldwide: 39 million are blind and 246 have low vision." (see <a href="http://www.who.int/mediacentre/factsheets/fs282/en/">Visual impairment and blindness</a>). That's a large and significant population of users to just miss out on because your site isn't coded properly — almost the same size as the population of the United States of America.</p> + +<h3 id="People_with_hearing_impairments">People with hearing impairments</h3> + +<p>Otherwise known as people with auditory impairments, or deaf people, this group of people have either low hearing levels or no hearing at all. Hearing-impaired people do use ATs (see <a href="https://www.nidcd.nih.gov/health/assistive-devices-people-hearing-voice-speech-or-language-disorders">Assistive Devices for People with Hearing, Voice, Speech, or Language Disorders</a>), but there are not really special ATs specific for computer/web use.</p> + +<p>There are, however, specific techniques to bear in mind for providing text alternatives to audio content that they can read, from simple text transcripts, to text tracks (i.e. captions) that can be displayed along with video. An article later on will discuss these.</p> + +<p>Hearing-impaired people also represent a significant userbase — "360 million people worldwide have disabling hearing loss", says the World Health Organization's <a href="http://www.who.int/mediacentre/factsheets/fs300/en/">Deafness and hearing loss</a> fact sheet.</p> + +<h3 id="People_with_mobility_impairments">People with mobility impairments</h3> + +<p>These people have disabilities concerning movement, which might involve purely physical issues (such as loss of limb or paralysis), or neurological/genetic disorders that lead to weakness or loss of control in limbs. Some people might have difficulty making the exact hand movements required to use a mouse, while others might be more severely affected, perhaps being significantly paralysed to the point where they need to use a <a href="http://pattersonmedical.com/app.aspx?cmd=getProductDetail&key=070_921118261">head pointer</a> to interact with computers.</p> + +<p>This kind of disability can also be a result of old age, rather than any specific trauma or condition, and it could also result from hardware limitations — some users might not have a mouse.</p> + +<p>The way this usually affects web development work is the requirement that controls be accessible by the keyboard — we'll discuss keyboard accessibility in later articles in the module, but it is a good idea to try out some websites using just the keyboard to see how you get on. Can you use the tab key to move between the different controls of a web form, for example? You can find more details about keyboard controls in our <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Using_native_keyboard_accessibility">Cross browser testing Using native keyboard accessibility</a> section.</p> + +<p>In terms of statistics, a significant number of people have mobility impairments. The U.S. Centers for Disease Control and Prevention <a href="http://www.cdc.gov/nchs/fastats/disability.htm">Disability and Functioning (Noninstitutionalized Adults 18 Years and Over)</a> reports the USA "Percent of adults with any physical functioning difficulty: 15.1%".</p> + +<h3 id="People_with_cognitive_impairments">People with cognitive impairments</h3> + +<p>Probably the widest range of disabilities can be seen in this last category — cognitive impairment can broadly refer to disabilities from mental illnesses to learning difficulties, difficulties in comprehension and concentration like <a href="https://www.nimh.nih.gov/health/topics/attention-deficit-hyperactivity-disorder-adhd/index.shtml">ADHD (attention deficit hyperactivity disorder)</a>, to people on the <a href="https://www.nimh.nih.gov/health/topics/autism-spectrum-disorders-asd/index.shtml">autistic spectrum</a>, to people with <a href="https://www.nimh.nih.gov/health/topics/schizophrenia/index.shtml">schizophrenia</a>, and many other types of disorder besides. Such disabilities can affect many parts of everyday life, due to problems with memory, problem solving, comprehension, attention, etc.</p> + +<p>The most common ways that such disabilities might affect website usage is difficulty in understanding how to complete a task, remembering how to do something that was previously accomplished, or increased frustration at confusing workflows or inconsistent layouts/navigation/other page features.</p> + +<p>Unlike other web accessibility issues, it is impossible to prescribe quick fixes to many web accessibility issues arising from cognitive disabilities; the best chance you've got is to design your websites to be as logical, consistent, and usable as possible, so for example making sure that:</p> + +<ul> + <li>pages are consistent — navigation, header, footer, and main content are always in the same places.</li> + <li>tools are well-designed and easy to use.</li> + <li>multi-stage processes are broken down into logical steps, with regular reminders of how far through the process you are, and how long you've got left to complete the process, if appropriate.</li> + <li>workflows are logical, simple, and require as few interactions as possible to complete. For example, registering and signing in to a website is often unneccessarily complex.</li> + <li>pages are not overly long or dense in terms of the amount of information presented at once.</li> + <li>the language used in your pages is as plain and easy to follow as possible, and not full of unneccessary jargon and slang.</li> + <li>important points and content are highlighted in some way.</li> + <li>user errors are clearly highlighted, with help messages to suggest solutions.</li> +</ul> + +<p>These are not "accessibility techniques" as such — they are good design practices. They will benefit everyone using your sites and should be a standard part of your work.</p> + +<p>In terms of statistics, again the numbers are significant. Cornell University's <a href="http://www.disabilitystatistics.org/StatusReports/2014-PDF/2014-StatusReport_US.pdf">2014 Disability Status Report</a> (PDF, 511KB) indicates that in 2014, 4.5% of people in the USA aged 21–64 had some form of cognitive disability.</p> + +<div class="note"> +<p><strong>Note</strong>: WebAIM's <a href="http://webaim.org/articles/cognitive/">Cognitive</a> page provides a useful expansion of these ideas, and is certainly worth reading.</p> +</div> + +<h2 id="Implementing_accessibility_into_your_project">Implementing accessibility into your project</h2> + +<p>A common accessibility myth is that accessibility is an expensive "added extra" to implement on a project. This myth actually <em>can</em> be true if either:</p> + +<ul> + <li>You are trying to "retrofit" accessibility onto an existing website that has significant accessiblity issues.</li> + <li>You have only started to consider accessibility and uncovered related issues in the late stages of a project.</li> +</ul> + +<p>If however you consider accessibility from the start of a project, the cost of making most content accessible should be fairly minimal.</p> + +<p>When planning your project, factor accessibility testing into your testing regime, just like testing for any other important target audience segment (e.g. target desktop or mobile browsers). Test early and often, ideally running automated tests to pick up on programmatically detectable missing features (such as missing image <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Text_alternatives">alternative text</a> or bad link text — see <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Element_relationships_and_context">Element relationships and context</a>), and doing some testing with disabled user groups to see how well more complex site features work for them. For example:</p> + +<ul> + <li>Is my date picker widget usable by people using screen readers?</li> + <li>If content updates dynamically, do visually impaired people know about it?</li> + <li>Are my UI buttons accessible using the keyboard and on touch interfaces?</li> +</ul> + +<p>You can and should keep a note of potential problem areas in your content that will need work to make it accessible, make sure it is tested thoroughly, and think about solutions/alternatives. Text content (as you'll see in the next article) is easy, but what about your multimedia content, and your whizzy 3D graphics? You should look at your project budget and realistically think about what solutions you have available to make such content accessible? You could pay to have all your multimedia content transcribed, which can be expensive, but can be done.</p> + +<p>Also, be realistic. "100% accessibility" is an unobtainable ideal — you will always come across some kind of edge case that results in a certain user finding certain content difficult to use — but you should do as much as you can. If you are planning to include a whizzy 3D pie chart graphic made using WebGL, you might want to include a data table as an accessible alternative representation of the data. Or, you might want to just include the table and get rid of the 3D pie chart — the table is accessible by everyone, quicker to code, less CPU-intensive, and easier to maintain.</p> + +<p>On the other hand, if you are working on a gallery website showing interesting 3D art, it would be unreasonable to expect every piece of art to be perfectly accessible to visually impaired people, given that it is an entirely visual medium.</p> + +<p>To show that you care and have thought about accessibility, publish an accessibility statement on your site that details what your policy is toward accessibility, and what steps you have taken toward making the site accessible. If someone does complain that your site has an accessibility problem, start a dialog with them, be empathic, and take reasonable steps to try to fix the problem.</p> + +<div class="note"> +<p><strong>Note</strong>: Our <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility">Handling common accessibility problems article</a> covers accessibility specifics that should be tested in more detail.</p> +</div> + +<p>To summarize:</p> + +<ul> + <li>Consider accessibility from the start of a project, and test early and often. Just like any other bug, an accessibility problem becomes more expensive to fix the later it is discovered.</li> + <li>Bear in mind that a lot of accessibility best practices benefit everyone, not just users with disabilities. For example, lean semantic markup is not only good for screen readers, it is also fast to load and performant, so better for everyone, especially those on mobile devices, and/or slow conections.</li> + <li>Publish an accessibility statement on your site and engage with people having problems.</li> +</ul> + +<h2 id="Accessibility_guidelines_and_the_law">Accessibility guidelines and the law</h2> + +<p>There are numerous checklists and sets of guidelines available for basing accessibility tests on, which might seem overwhelming at first glance. Our advice is to familiarize yourself with the basic areas in which you need to take care, as well as understanding the high level structures of the guidelines that are most relevant to you.</p> + +<ul> + <li>For a start, the W3C has published a large and very detailed document that includes very precise, technology-agnostic criteria for accessibility conformance. These are called the <a href="https://www.w3.org/WAI/intro/wcag.php">Web Content Accessibility Guidelines</a> (WCAG), and they are not a short read by any means. The criteria are split up into four main categories, which specify how implementations can be made perceivable, operable, understandable, and robust. The best place to get a light introduction and start learning is <a href="https://www.w3.org/WAI/WCAG20/glance/Overview.html">WCAG at a Glance</a>. There is no need to learn WCAG off by heart — be aware of the major areas of concern, and use a variety of techniques and tools to highlight any areas that don't conform to the WCAG criteria (see below for more).</li> + <li>Your country may also have specific legislation governing the need for websites serving their population to be accessible — for example <a href="http://www.section508.gov/content/learn">Section 508 of the Rehabilitation Act</a> in the US, <a href="https://www.einfach-fuer-alle.de/artikel/bitv_english/">Federal Ordinance on Barrier-Free Information Technology</a> in Germany, the <a href="http://www.legislation.gov.uk/ukpga/2010/15/contents">Equality Act</a> in the UK, <a href="http://www.agid.gov.it/agenda-digitale/pubblica-amministrazione/accessibilita">Accessibilità</a> in Italy, the <a href="https://www.humanrights.gov.au/world-wide-web-access-disability-discrimination-act-advisory-notes-ver-41-2014">Disability Discrimination Act</a> in Australia, etc.</li> +</ul> + +<p>So while the WCAG is a set of guidelines, your country will probably have laws governing web accessibility, or at least the accessibility of services available to the public (which could include websites, television, physical spaces, etc.) It is a good idea to find out what your laws are. If you make no effort to check that your content is accessible, you could possibly get in trouble with the law if people with diabilities complain about it.</p> + +<p>This sounds serious, but really you just need to consider accessibility as a main priority of your web development practices, as outlined above. If in doubt, get advice from a qualified lawyer. We're not going to offer any more advice than this, because we're not lawyers.</p> + +<h2 id="Accessibility_APIs">Accessibility APIs</h2> + +<p>Web browsers make use of special <strong>accessibility APIs</strong> (provided by the underlying operating system) that expose information useful for assistive technologies (ATs) — ATs mostly tend to make use of semantic information, so this information doesn't include things like styling information, or JavaScript. This information is structured in a tree of information called the <strong>accessibility tree</strong>.</p> + +<p>Different operating systems have different accessibility APIs available :</p> + +<ul> + <li>Windows: MSAA/IAccessible, UIAExpress, IAccessible2</li> + <li>Mac OS X: NSAccessibility</li> + <li>Linux: AT-SPI</li> + <li>Android: Accessibility framework</li> + <li>iOS: UIAccessibility</li> +</ul> + +<p>Where the native semantic information provided by the HTML elements in your web apps falls down, you can supplement it with features from the <a href="https://www.w3.org/TR/wai-aria/">WAI-ARIA specification</a>, which add semantic information to the accessibility tree to improve accessibility. You can learn a lot more about WAI-ARIA in our <a href="/en-US/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA basics</a> article.</p> + +<h2 id="Summary">Summary</h2> + +<p>This article should have given you a useful high level overview of accessibility, shown you why it's important, and looked at how you can fit it into your workflow. You should now also have a thirst to learn about the implementation details that can make sites accessible, and we'll start on that in the next section, looking at why HTML is a good basis for accessibility.</p> + +<p>{{NextMenu("Learn/Accessibility/HTML", "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> diff --git a/files/ko/learn/접근성/모바일/index.html b/files/ko/learn/접근성/모바일/index.html new file mode 100644 index 0000000000..a64c0eaa88 --- /dev/null +++ b/files/ko/learn/접근성/모바일/index.html @@ -0,0 +1,315 @@ +--- +title: 모바일 접근성 +slug: Learn/접근성/모바일 +translation_of: Learn/Accessibility/Mobile +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/Multimedia","Learn/Accessibility/Accessibility_troubleshooting", "Learn/Accessibility")}}</div> + +<p class="summary">모바일 기기에서 웹 접근이 매우 자주 발생하고 iOS와 안드로이드와 같은 유명 플랫폼들은 전문적인 접근성 점검도구들이 있기 때문에 웹콘텐츠의 접근성을 고려하는 것이 더욱 중요하다. 여기서는 모바일환경을 중심으로 접근성 고려사항을 살펴본다.</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">사전지식:</th> + <td> + <p>기본적인 컴퓨터 사용능력, HTML, CSS, JavaScript에 대한 기본적인 이해, 그리고 <a href="/en-US/docs/Learn/Accessibility">이전 내용들에 대한 이해</a>.</p> + </td> + </tr> + <tr> + <th scope="row">목표:</th> + <td> + <p>모바일 기기의 접근성에 어떤 문제가 있는지, 그리고 이를 극복하는 방법을 이해한다.</p> + </td> + </tr> + </tbody> +</table> + +<h2 id="모바일_장치에서의_접근성">모바일 장치에서의 접근성</h2> + +<p>접근성 상태(일반적으로 웹 표준에 대한 지원)는 최근의 모바일 장치에서 좋다. 모바일 기기가 데스크톱 브라우저에 전혀 다른 웹 기술을 실행하면서 개발자들이 브라우저 코웃음을 치며 완전히 별개의 사이트에 서비스를 제공하도록 강요하던 시대는 이미 오래 전에 지났다(아직도 상당수의 회사가 모바일 장치의 사용을 감지하여 별도의 모바일 도메인을 서비스하고 있다).</p> + + + +<p>The state of accessibility — and support for web standards in general — is good in modern mobile devices. Long gone are the days when mobile devices ran completely different web technologies to desktop browsers, forcing developers to use browser sniffing and serve them completely separate sites (although quite a few companies still detect usage of mobile devices and serve them a separate mobile domain).</p> + +<p>These days, mobile devices can usually handle fully-featured websites, and the main platforms even have screenreaders built in to enable visually impaired users to use them successfully. Modern mobile browsers tend to have good support for <a href="https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA</a>, too.</p> + +<p>To make a website accessible and usable on mobile, you just need to follow general good web design and accessibility best practices.</p> + +<p>There are some exceptions that need special consideration for mobile; the main ones are:</p> + +<ul> + <li>Control mechanisms — Make sure interface controls such as buttons are accessible on mobiles (i.e., mainly touchscreen), as well as desktops/laptops (mainly mouse/keyboard).</li> + <li>User input — Make user input requirements as painless as possible on mobile (e.g., in forms, keep typing to a minimum).</li> + <li>Responsive design — Make sure layouts work on mobile, conserve image download sizes, and think about the provision of images for high-resolution screens.</li> +</ul> + +<h2 id="Summary_of_screenreader_testing_on_Android_and_iOS">Summary of screenreader testing on Android and iOS</h2> + +<p>The most common mobile platforms have fully functional screen readers. These function in much the same way as desktop screenreaders, except they are largely operated using touch gestures rather than key combinations.</p> + +<p>Let's look at the main two: TalkBack on Android and VoiceOver on iOS.</p> + +<h3 id="Android_TalkBack">Android TalkBack</h3> + +<p>The TalkBack screen reader is built into the Android operating system.</p> + +<p>To turn it on, look up what phone model and Android version you have, and then look up where the TalkBack menu is. It tends to differ widely between Android versions and even between different phone models. Some phone manufacturers (e.g. Samsung) don't even have TalkBack in newer phones, and instead opted for their own screen reader.</p> + +<p>When you've found the TalkBack menu, press the slider switch to turn TalkBack on. Follow any additional on-screen prompts that you are presented with.</p> + +<p>When TalkBack is turned on, your Android device's basic controls will be a bit different. For example:</p> + +<ol> + <li>Single-tapping an app will select it, and the device will read out what the app is.</li> + <li>Swiping left and right will move between apps, or buttons/controls if you are in a control bar. The device will read out each option.</li> + <li>Double-tapping anywhere will open the app/select the option.</li> + <li>You can also "explore by touch" — hold your finger down on the screen and drag it around, and your device will read out the different apps/items you move across.</li> +</ol> + +<p>If you want to turn TalkBack off:</p> + +<ol> + <li>Navigate back to the TalkBack menu screen (using the different gestures that are currently enabled.)</li> + <li>Navigate to the slider switch and activate it to turn it off.</li> +</ol> + +<div class="blockIndicator note"> +<p><strong>Note:</strong> You can get to your home screen at any time by swiping up and left in a smooth motion. If you have more than one home screen, you can move between them by swiping two fingers left and right.</p> +</div> + +<p>For a more complete list of TalkBack gestures, see <a href="https://support.google.com/accessibility/android/answer/6151827">Use TalkBack gestures</a>.</p> + +<h4 id="Unlocking_the_phone">Unlocking the phone</h4> + +<p>When TalkBack is turned on, unlocking the phone is a bit different.</p> + +<p>You can do a two-finger swipe up from the bottom of the lock screen. If you've set a passcode or pattern for unlocking your device, you will then be taken to the relevant entry screen to enter it.</p> + +<p>You can also explore by touch to find the <em>Unlock</em> button at the bottom middle of the screen, and then double-tap.</p> + +<h4 id="Global_and_local_menus">Global and local menus</h4> + +<p>TalkBack allows you to access global and local context menus, wherever you have navigated to on the device. The former provides global options relating to the device as a whole, and the latter provides options relating just to the current app/screen you are in.</p> + +<p>To get to these menus:</p> + +<ol> + <li>Access the global menu by quickly swiping down, and then right.</li> + <li>Access the local menu by quickly swiping up, and then right.</li> + <li>Swipe left and right to cycle between the different options.</li> + <li>Once you've selected the option you want, double-click to choose that option.</li> +</ol> + +<p>For details on all the options available under the global and local context menus, see <a href="https://support.google.com/accessibility/android/answer/6007066">Use global and local context menus</a>.</p> + +<h4 id="Browsing_web_pages">Browsing web pages</h4> + +<p>You can use the local context menu while in a web browser to find options to navigate web pages using just the headings, form controls, or links, or navigate line by line, etc.</p> + +<p>For example, with TalkBack turned on:</p> + +<ol> + <li>Open your web browser.</li> + <li>Activate the URL bar.</li> + <li>Enter a web page that has a bunch of headings on it, such as the front page of bbc.co.uk. To enter the text of the URL: + <ul> + <li>Select the URL bar by swiping left/right till you get to it, and then double-tapping.</li> + <li>Hold your finger down on the virtual keyboard until you get the character you want, and then release your finger to type it. Repeat for each character.</li> + <li>Once you've finished, find the Enter key and press it.</li> + </ul> + </li> + <li>Swipe left and right to move between different items on the page.</li> + <li>Swipe up and right with a smooth motion to enter the local content menu.</li> + <li>Swipe right until you find the "Headings and Landmarks" option.</li> + <li>Double-tap to select it. Now you'll be able to swipe left and right to move between headings and ARIA landmarks.</li> + <li>To go back to the default mode, enter the local context menu again by swiping up and right, select "Default", and then double-tap to activate.</li> +</ol> + +<p><strong>Note:</strong> See <a href="https://support.google.com/accessibility/android/answer/6283677?hl=en&ref_topic=3529932">Get started on Android with TalkBack</a> for more complete documentation.</p> + +<h3 id="iOS_VoiceOver">iOS VoiceOver</h3> + +<p>A mobile version of VoiceOver is built into the iOS operating system.</p> + +<p>To turn it on, go to Your <em>Settings</em> app and select<em> Accessibility > VoiceOver</em>. Press the <em>VoiceOver</em> slider to enable it (you'll also see a number of other options related to VoiceOver on this page).</p> + +<div class="blockIndicator note"> +<p><strong>Note</strong>: Some older iOS devices have the VoiceOver menu at <em>Settings app</em> > <em>General</em> > <em>Accessibility</em> > <em>VoiceOver</em>.</p> +</div> + +<p>Once VoiceOver is enabled, iOS's basic control gestures will be a bit different:</p> + +<ol> + <li>A single tap will cause the item you tap on to be selected; your device will speak the item you've tapped on.</li> + <li>You can also navigate the items on the screen by swiping left and right to move between them, or by sliding your finger around on the screen to move between different items (when you find the item you want, you can remove your finger to select it).</li> + <li>To activate the selected item (e.g., open a selected app), double-tap anywhere on the screen.</li> + <li>Swipe with three fingers to scroll through a page.</li> + <li>Tap with two fingers to perform a context-relevant action — for example, taking a photo while in the camera app.</li> +</ol> + +<p>To turn it off again, navigate back to <em>Settings > General > Accessibility > VoiceOver</em> using the above gestures, and toggle the <em>VoiceOver</em> slider back to off.</p> + +<h4 id="Unlock_phone">Unlock phone</h4> + +<p>To unlock the phone, you need to press the home button (or swipe) as normal. If you have a passcode set, you can select each number by swiping/sliding (as explained above) and then double-tapping to enter each number when you've found the right one.</p> + +<h4 id="Using_the_Rotor">Using the Rotor</h4> + +<p>When VoiceOver is turned on, you have a navigation feature called the Rotor available to you, which allows you to quickly choose from a number of common useful options. To use it:</p> + +<ol> + <li>Twist two fingers around on the screen like you are turning a dial. Each option will be read aloud as you twist further around. You can go back and forth to cycle through the options.</li> + <li>Once you've found the option you want: + <ul> + <li>Release your fingers to select it.</li> + <li>If it is an option you can iterate the value of (such as Volume or Speaking Rate), you can do a swipe up or down to increase or decrease the value of the selected item.</li> + </ul> + </li> +</ol> + +<p>The options available under the Rotor are context-sensitive — they will differ depending on what app or view you are in (see below for an example).</p> + +<h4 id="Browsing_web_pages_2">Browsing web pages</h4> + +<p>Let's have a go at web browsing with VoiceOver:</p> + +<ol> + <li>Open your web browser.</li> + <li>Activate the URL bar.</li> + <li>Enter a web page that has a bunch of headings on it, such as the front page of bbc.co.uk. To enter the text of the URL: + <ul> + <li>Select the URL bar by swiping left/right until you get to it, and then double-tapping.</li> + <li>For each character, hold your finger down on the virtual keyboard until you get the character you want, and then release your finger to select it. Double-tap to type it.</li> + <li>Once you've finished, find the Enter key and press it.</li> + </ul> + </li> + <li>Swipe left and right to move between items on the page. You can double-tap an item to select it (e.g., follow a link).</li> + <li>By default, the selected Rotor option will be Speaking Rate; you can currently swipe up and down to increase or decrease the speaking rate.</li> + <li>Now turn two fingers around the screen like a dial to show the rotor and move between its options. Here are a few examples of the options available: + <ul> + <li><em>Speaking Rate</em>: Change the speaking rate.</li> + <li><em>Containers</em>: Move between different semantic containers on the page.</li> + <li><em>Headings</em>: Move between headings on the page.</li> + <li><em>Links</em>: Move between links on the page.</li> + <li><em>Form Controls</em>: Move between form controls on the page.</li> + <li><em>Language</em>: Move between different translations, if they are available.</li> + </ul> + </li> + <li>Select <em>Headings</em>. Now you'll be able to swipe up and down to move between headings on the page.</li> +</ol> + +<p><strong>Note:</strong> For a more complete reference covering the VoiceOver gestures available and other hints on accessibility testing on iOS, see <a href="https://developer.apple.com/library/content/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityonYourDevicewithVoiceOver/TestAccessibilityonYourDevicewithVoiceOver.html#//apple_ref/doc/uid/TP40012619-CH3">Test Accessibility on Your Device with VoiceOver</a>.</p> + +<h2 id="Control_mechanisms">Control mechanisms</h2> + +<p>In our CSS and JavaScript accessibility article, we looked at the idea of events that are specific to a certain type of control mechanism (see <a href="https://developer.mozilla.org/en-US/docs/Learn/Accessibility/CSS_and_JavaScript#mouse-specific_events">Mouse-specific events</a>). To recap, these cause accessibility issues because other control mechanisms can't activate the associated functionality.</p> + +<p>As an example, the <a href="https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onclick">click</a> event is good in terms of accessibility — an associated event handler can be invoked by clicking the element the handler is set on, tabbing to it and pressing Enter/Return, or tapping it on a touchscreen device. Try our <a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/simple-button-example.html">simple-button-example.html</a> example (<a href="http://mdn.github.io/learning-area/accessibility/mobile/simple-button-example.html">see it running live</a>) to see what we mean.</p> + +<p>Alternatively, mouse-specific events such as <a href="https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onmousedown">mousedown</a> and <a href="https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onmouseup">mouseup</a> create problems — their event handlers cannot be invoked using non-mouse controls.</p> + +<p>If you try to control our <a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/simple-box-drag.html">simple-box-drag.html</a> (<a href="http://mdn.github.io/learning-area/accessibility/mobile/simple-box-drag.html">see example live</a>) example with a keyboard or touch, you'll see the problem. This occurs because we are using code such as the following:</p> + +<pre>div.onmousedown = function() { + initialBoxX = div.offsetLeft; + initialBoxY = div.offsetTop; + movePanel(); +} + +document.onmouseup = stopMove;</pre> + +<p>To enable other forms of control, you need to use different, yet equivalent events — for example, touch events work on touchscreen devices:</p> + +<pre>div.ontouchstart = function(e) { + initialBoxX = div.offsetLeft; + initialBoxY = div.offsetTop; + positionHandler(e); + movePanel(); +} + +panel.ontouchend = stopMove;</pre> + +<p>We've provided a simple example that shows how to use the mouse and touch events together — see <a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/multi-control-box-drag.html">multi-control-box-drag.html</a> (<a href="http://mdn.github.io/learning-area/accessibility/mobile/multi-control-box-drag.html">see the example live</a> also).</p> + +<div class="blockIndicator note"> +<p><strong>Note:</strong> You can also see fully functional examples showing how to implement different control mechanisms at <a href="https://developer.mozilla.org/en-US/docs/Games/Techniques/Control_mechanisms">Implementing game control mechanisms</a>.</p> +</div> + +<h2 id="Responsive_design">Responsive design</h2> + +<p><a href="https://developer.mozilla.org/en-US/docs/Web/Apps/Progressive/Responsive">Responsive design</a> is the practice of making your layouts and other features of your apps dynamically change depending on factors such as screen size and resolution, so they are usable and accessible to users of different device types.</p> + +<p>In particular, the most common problems that need to be addressed for mobile are:</p> + +<ul> + <li>Suitability of layouts for mobile devices. A multi-column layout won't work as well on a narrow screen, for example, and the text size may need to be increased so it is legible. Such issues can be solved by creating a responsive layout using technologies such as <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries">media queries</a>, <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag">viewport</a>, and <a href="https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Flexbox">flexbox</a>.</li> + <li>Conserving image sizes downloaded. In general, small screen devices won't need images that are as large as their desktop counterparts, and they are more likely to be on slow network connections. Therefore, it is wise to serve smaller images to narrow screen devices as appropriate. You can handle this using <a href="https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">responsive image techniques</a>.</li> + <li>Thinking about high resolutions. Many mobile devices have high-resolution screens, and therefore need higher-resolution images so that the display can continue to look crisp and sharp. Again, you can serve images as appropriate using responsive image techniques. In addition, many image requirements can be fulfilled using the SVG vector images format, which is well-supported across browsers today. SVG has a small file size and will stay sharp regardless of whatever size is being displayed (see <a href="https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Adding_vector_graphics_to_the_Web">Adding vector graphics to the web</a> for more details).</li> +</ul> + +<p><strong>Note:</strong> We won't provide a full discussion of responsive design techniques here, as they are covered in other places around MDN (see above links).</p> + +<h3 id="Specific_mobile_considerations">Specific mobile considerations</h3> + +<p>There are other important issues to consider when making sites more accessible on mobile. We have listed a couple here, but we will add more when we think of them.</p> + +<h4 id="Not_disabling_zoom">Not disabling zoom</h4> + +<p>Using <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag">viewport</a>, it is possible to disable zoom. Always ensure resizing is enabled, and set the width to the device's width in the {{htmlelement("head")}}:</p> + +<pre class="brush: html"><code><meta name="viewport" content="width=device-width; user-scalable=yes"></code></pre> + +<p>You should never set <code>user-scalable=no</code> if at all possible — many people rely on zoom to be able to see the content of your website, so taking this functionality away is a really bad idea. There are certain situations where zooming might break the UI; in such cases, if you feel that you absolutely need to disable zoom, you should provide some other kind of equivalent, such as a control for increasing the text size in a way that doesn't break your UI.</p> + +<h4 id="Keeping_menus_accessible">Keeping menus accessible</h4> + +<p>Because the screen is so much narrower on mobile devices, it is very common to use media queries and other technologies to make the navigation menu shrink down to a tiny icon at the top of the display — which can be pressed to reveal the menu only if it's needed — when the site is viewed on mobile. This is commonly represented by a "three horizontal lines" icon, and the design pattern is consequently known as a "hamburger menu".</p> + +<p>When implementing such a menu, you need to make sure that the control to reveal it is accessible by appropriate control mechanisms (normally touch for mobile), as discussed in {{anch("Control mechanisms")}} above, and that the rest of the page is moved out of the way or hidden in some way while the menu is being accessed, to avoid confusion with navigating it.</p> + +<p>Click here for a <a href="http://fritz-weisshart.de/meg_men/">good hamburger menu example</a>.</p> + +<h2 id="User_input">User input</h2> + +<p>On mobile devices, inputting data tends to be more annoying for users than the equivalent experience on desktop computers. It is more convenient to type text into form inputs using a desktop or laptop keyboard than a touchscreen virtual keyboard or a tiny mobile physical keyboard.</p> + +<p>For this reason, it is worth trying to minimize the amount of typing needed. As an example, instead of getting users to fill out their job title each time using a regular text input, you could instead offer a {{htmlelement("select")}} menu containing the most common options (which also helps with consistency in data entry), and offer an "Other" option that displays a text field to type any outliers into. You can see a simple example of this idea in action in <a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/common-job-types.html">common-job-types.html</a> (see the <a href="http://mdn.github.io/learning-area/accessibility/mobile/common-job-types.html">common jobs example live</a>).</p> + +<p>It is also worth considering the use of HTML5 form input types such as the date on mobile platforms as they handle them well — both Android and iOS, for example, display usable widgets that fit well with the device experience. See <a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/html5-form-examples.html">html5-form-examples.html</a> for some examples (see the <a href="http://mdn.github.io/learning-area/accessibility/mobile/html5-form-examples.html">HTML5 form examples live</a>) — try loading these and manipulating them on mobile devices. For example:</p> + +<ul> + <li>Types <code>number</code>, <code>tel</code>, and <code>email</code> display suitable virtual keyboards for entering numbers/telephone numbers.</li> + <li>Types <code>time</code> and <code>date</code> display suitable pickers for selecting times and dates.</li> +</ul> + +<p>If you want to provide a different solution for desktops, you could always serve different markup to your mobile devices using feature detection. See <a href="http://diveinto.html5doctor.com/detect.html#input-types">input types</a> for raw information on detecting different input types, and also check out our <a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection">feature detection article</a> for much more information.</p> + +<h2 id="Summary">Summary</h2> + +<p>In this article, we have provided you with some details about common mobile accessibility-specific issues and how to overcome them. We also took you through the usage of the most common screenreaders to aid you in accessibility testing.</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a href="https://www.smashingmagazine.com/guidelines-for-mobile-web-development/">Guidelines For Mobile Web Development</a> — A list of articles in <em>Smashing Magazine</em> covering different techniques for mobile web design.</li> + <li><a href="http://www.creativebloq.com/javascript/make-your-site-work-touch-devices-51411644">Make your site work on touch devices</a> — Useful article about using touch events to get interactions working on mobile devices.</li> +</ul> + +<div>{{PreviousMenuNext("Learn/Accessibility/Multimedia","Learn/Accessibility/Accessibility_troubleshooting", "Learn/Accessibility")}}</div> + +<div> +<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> +</div> |