diff options
Diffstat (limited to 'files/zh-tw/learn/accessibility')
| -rw-r--r-- | files/zh-tw/learn/accessibility/index.html | 75 | ||||
| -rw-r--r-- | files/zh-tw/learn/accessibility/mobile/index.html | 302 | ||||
| -rw-r--r-- | files/zh-tw/learn/accessibility/wai-aria_basics/index.html | 421 | ||||
| -rw-r--r-- | files/zh-tw/learn/accessibility/what_is_accessibility/index.html | 201 |
4 files changed, 999 insertions, 0 deletions
diff --git a/files/zh-tw/learn/accessibility/index.html b/files/zh-tw/learn/accessibility/index.html new file mode 100644 index 0000000000..9ded955a1e --- /dev/null +++ b/files/zh-tw/learn/accessibility/index.html @@ -0,0 +1,75 @@ +--- +title: 無障礙網頁 +slug: Learn/Accessibility +tags: + - ARIA + - Accessibility + - Articles + - Beginner + - CSS + - CodingScripting + - HTML + - JavaScript + - Landing + - Learn + - Module + - NeedsTranslation + - TopicStub +translation_of: Learn/Accessibility +--- +<div>{{LearnSidebar}}</div> + +<p class="summary">如果要當 web 開發者，學會 HTML、CSS、JavaScript 是很重要的。不過除此之外，你還要學得更多：你需要<strong>負責任地</strong>運用這些技術，才能讓所有讀者都能使用你的網頁。要達成這點，本模塊將展示一般最佳實做（在 <a href="/zh-TW/docs/Learn/HTML">HTML</a>、<a href="/zh-TW/docs/Learn/CSS">CSS</a>、<a href="/en-US/docs/Learn/JavaScript">JavaScript</a> 有示範）、<a href="/zh-TW/docs/Learn/Tools_and_testing/Cross_browser_testing">跨瀏覽器測試</a>、還有其他啟動的要點。</p> + +<h2 id="概觀">概觀</h2> + +<p>When someone describes a site as "accessible," they mean that any user can use all its features and content, regardless of how the user accesses the web — even and especially users with physical or mental impairments.</p> + +<ul> + <li>Sites should be accessible to keyboard, mouse, and touch screen users, and any other way users access the web, including screen readers and voice assistants like Alexa and Google Home.</li> + <li>Applications should be understandable and usable by people regardless of auditory, visual, physical, or cognitive abilities.</li> + <li>Sites should also not cause harm: web features like motion can cause migraines or epileptic seizures.</li> +</ul> + +<p><strong>By default, HTML is accessible, if used correctly.</strong> Web accessibility involves ensuring that content remains accessible, regardless of who and how the web is accessed.</p> + +<h2 id="先決條件">先決條件</h2> + +<p>要理解本模塊的概念，最少理解 <a href="/zh-TW/docs/Learn/HTML">HTML</a>、<a href="/zh-TW/docs/Learn/CSS">CSS</a>、<a href="/zh-TW/docs/Learn/JavaScript">JavaScript</a> 是個好主意。如果在學習相關技術時學習會更好。</p> + +<div class="note"> +<p><strong>注</strong>：如果使用的設備無法讓你建立自己的文件，可以試著在 <a href="http://jsbin.com/">JSBin</a> 或 <a href="https://thimble.mozilla.org/">Thimble</a> 這種程式撰寫網站，執行大多數範例。</p> +</div> + +<h2 id="教學">教學</h2> + +<dl> + <dt><a href="/zh-TW/docs/Learn/Accessibility/What_is_accessibility">何謂無障礙網頁？</a></dt> + <dd>這篇文章針對何謂無障礙網頁，起了一個好開頭。這模塊包含了要考慮哪些族群以及理由、不同族群會用什麼工具和 Web 互動、還有怎麼把無障礙網頁導入 Web 開發工作流程。</dd> + <dt><a href="/zh-TW/docs/Learn/Accessibility/HTML">HTML：無障礙網頁的好開始</a></dt> + <dd>只要確保在任何時候，正確的 HTML 元素都用於正確的目的，就能消除各種網頁的障礙。這篇文章詳述 HTML 如何確保網頁無障礙。</dd> + <dt><a href="/zh-TW/docs/Learn/Accessibility/CSS_and_JavaScript">充分實踐 CSS 與 JavaScript 的無障礙</a></dt> + <dd>如果 CSS 與 JavaScript 使用得當，將可以為無障礙網頁提供助力……反過來的話，就會嚴重影響無障礙體驗。這篇文章詳述如何在內容複雜的情況下，確保能充分實踐 CSS 與 JavaScript 的無障礙。</dd> + <dt><a href="/zh-TW/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA 基礎</a></dt> + <dd>從之前的文章來看，有時製作要涉及到非語意的 HTML 還有動態 JavaScript 更新技術……等，會令複雜的 UI 控制變得很困難。WAI-ARIA 正是為了解決此一問題而生。它對瀏覽器和輔助技術添加進一步的語意，讓用戶能知道發生了什麼事。我們將介紹如何在基本層面使用此技術，以提昇無障礙。</dd> + <dt><a href="/zh-TW/docs/Learn/Accessibility/Multimedia">無障礙多媒體</a></dt> + <dd>會導致無障礙網頁出問題的另一個根源是多媒體：影片、聲音、圖片等內容，需要有合適的文字替代，以便輔助技術和它的用戶能夠理解。我們將在這篇文章中闡明作法。</dd> + <dt><a href="/zh-TW/docs/Learn/Accessibility/Mobile">行動無障礙網頁</a></dt> + <dd>隨著行動設備訪問漸受歡迎、還有像是 iOS 與 Android 這般熱門平台，已經具備完善的輔助工具，考慮到如何在這些平台上實踐無障礙網頁，就變得十分重要。這篇文章將討論行動裝置特有的無障礙網頁相關議題。</dd> +</dl> + +<h2 id="評估">評估</h2> + +<dl> + <dt><a href="/zh-TW/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>：Marcy Sutton 所作的一套優秀教學影片。</li> + <li><a href="https://dequeuniversity.com/resources/">Deque University resources</a>：包含程式碼範例、螢幕閱讀器參考、或是其他有用的資源。</li> + <li><a href="http://webaim.org/resources/">WebAIM resources</a>：有教學、便覽、工具……等。</li> + <li><a href="https://www.w3.org/WAI/ER/tools/">Web Accessibility Evaluation Tools List</a> - includes a list of web accessibility evaluation tools.</li> +</ul> diff --git a/files/zh-tw/learn/accessibility/mobile/index.html b/files/zh-tw/learn/accessibility/mobile/index.html new file mode 100644 index 0000000000..eb04f93fd4 --- /dev/null +++ b/files/zh-tw/learn/accessibility/mobile/index.html @@ -0,0 +1,302 @@ +--- +title: Mobile accessibility +slug: Learn/Accessibility/Mobile +translation_of: Learn/Accessibility/Mobile +--- +<div> +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/Multimedia","Learn/Accessibility/Accessibility_troubleshooting", "Learn/Accessibility")}}</div> + +<p class="summary">With web access on mobile devices being so popular, and popular platforms such as iOS and Android having fully fledged accessibility tools, it is important to consider the accessibility of your web content on these platforms. This article looks at mobile-specific accessibility considerations.</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">Prerequisites:</th> + <td>Basic computer literacy, a basic understanding of HTML, CSS, and JavaScript, and an understanding of the <a href="/en-US/docs/Learn/Accessibility">previous articles in the course</a>.</td> + </tr> + <tr> + <th scope="row">Objective:</th> + <td>To understand what problems exist with accessibility on mobile devices, and how to overcome them.</td> + </tr> + </tbody> +</table> + +<h2 id="行動裝置上的無障礙">行動裝置上的無障礙</h2> + +<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>目前，行動裝置通常可以處理“全脂(full fat)”網站，主要平台甚至還內置了屏幕閱讀器，使視障人士能夠成功使用它們。 現代手機行動瀏覽器也傾向於對<a href="https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA</a>有很好的支持。</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 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 screenreaders. 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 screenreader is built into the Android operating system.</p> + +<p>To turn it on, select <em>Settings > Accessibility > TalkBack</em>, and then press the slider switch to turn it on. Follow any additional on-screen prompts that you are presented with.</p> + +<p><strong>Note:</strong> Older versions of TalkBack are turned on in <a href="https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback">slightly different ways</a>.</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 to your <em>Settings</em> app using the above gestures.</li> + <li>Navigate to <em>Accessibility > TalkBack</em>.</li> + <li>Navigate to the slider switch and activate it to turn it off.</li> +</ol> + +<p><strong>Note:</strong> You can get to your homescreen at any time by swiping up and left in a smooth motion. If you have more than one homescreen, you can move between them by swiping two fingers left and right.</p> + +<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>General > 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> + +<p>Once VoiceOver is enabled, the 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 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> + +<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> + +<h2 id="響應式設計">響應式設計</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. Alwasy ensure resizing is enabled, and set the width to the device's width in the {{htmlelement("head")}}:</p> + +<pre><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 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="總結">總結</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 usage of the most common screenreaders to aid you in accessibility testing.</p> + +<h2 id="延伸閱讀">延伸閱讀</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> +</div> diff --git a/files/zh-tw/learn/accessibility/wai-aria_basics/index.html b/files/zh-tw/learn/accessibility/wai-aria_basics/index.html new file mode 100644 index 0000000000..926505aa85 --- /dev/null +++ b/files/zh-tw/learn/accessibility/wai-aria_basics/index.html @@ -0,0 +1,421 @@ +--- +title: WAI-ARIA基礎 +slug: Learn/Accessibility/WAI-ARIA_basics +translation_of: Learn/Accessibility/WAI-ARIA_basics +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/CSS_and_JavaScript","Learn/Accessibility/Multimedia", "Learn/Accessibility")}}</div> + +<p class="summary">接續之前的文章，有時在涉及非語意HTML與動態 JavaScript更新的內容製作複雜的UI控制措施將是個難題。WAI-ARIA即是一個能藉由添加進一步的語意幫助處理這種問題的技術 ，讓瀏覽器與輔助科技可以辨識及用以讓使用者知道發生甚麼事情。這裡我們將展示如何以基本水準的運用來增進無障礙使用。</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">先決條件：</th> + <td>基本電腦技能、基本瞭解HTML, CSS與JavaScript、瞭解本課程先前文章。</td> + </tr> + <tr> + <th scope="row">目標：</th> + <td>能熟悉WAI-ARIA，以及在必要時如何用於提供有用的附加語意強化無障礙。</td> + </tr> + </tbody> +</table> + +<h2 id="甚麼是WAI-ARIA">甚麼是WAI-ARIA?</h2> + +<p>開始瞭解甚麼是WAI-ARIA，以及它可為我們做些甚麼。</p> + +<h3 id="一個全新問題集"><strong>一個全新問題集</strong></h3> + +<p>當網站應用程式開始更複雜與動態，新的無障礙特性與問題集就開始出現。</p> + +<p>例如，HTML5 導入許多語意的元素來定義一般頁面的特性({{htmlelement("nav")}}, {{htmlelement("footer")}}等) 在沒有這些可用之前，開發者僅簡單使用{{htmlelement("div")}}搭配IDs或classes，如<div class="nav">，但這些是有問題的，因為沒有很簡單的方法可程式化地容易找到特定的頁面特性如主要導覽功能。</p> + +<p>起初的解決方案是在頁面的頂端添加一個或更多隱藏的連結去連結到導覽功能(或其他任何的功能)，例如：</p> + +<pre class="brush: html"><a href="#hidden" class="hidden">Skip to navigation</a></pre> + +<p>但這仍然不是非常精確，並且僅能使用於螢幕報讀器從頁面頂端閱讀下來的時候。</p> + +<p>如同另一個例子，應用程式開始具有複雜的控制措施如日期選取器提供選擇日期，內容滑塊提供選取內容值等。HTML5提供特定的輸入型態來呈現這些控制措施：</p> + +<pre class="brush: html"><input type="date"> +<input type="range"></pre> + +<p>這些在跨瀏覽器之間沒有全面性支援，而且也非常困難去為他們指定樣式，而使他們與網站設計整合時不是很好用。因此，開發者時常依賴JavaScript資源庫來產生這些一系列內嵌的控制措施 {{htmlelement("div")}}或具有classnames的表格元素，透過CSS指定樣式與使用JavaScript控制。</p> + +<p>這個的問題是視覺上可以運作，但螢幕報讀器則一點也無法理解它們是甚麼，以及它們的使用者僅被告知他們可以看到一堆沒有語意的元素來描述它們的含意。</p> + +<h3 id="進入WAI-ARIA">進入WAI-ARIA</h3> + +<p><a href="https://www.w3.org/TR/wai-aria-1.1/">WAI-ARIA</a> 是一個由W3C編撰的規格，定義一套額外的HTML屬性能用於元素上提供額外的語意及改善可及性，當元素缺乏這些條件時可適用。本規格定義三個主要的特點：</p> + +<ul> + <li><strong>Roles</strong> — 這些角色用以定義元素是甚麼或做甚麼事。在這些當中許多被稱為地標角色，大部分重複了HTML5結構化元素的語意值如<code>role="navigation"</code> ({{htmlelement("nav")}}) or <code>role="complementary"</code> ({{htmlelement("aside")}}), 但也有其他描述不同的頁面結構者，如<code>role="banner"</code>, <code>role="search"</code>, <code>role="tabgroup"</code>, <code>role="tab"</code>等常見於使用者介面中。</li> + <li><strong>Properties</strong> — 這些用以定義元素的屬性，可用來賦予元素額外的意義或語意。舉例，<code>aria-required="true"</code>指定一個表單輸入必須填寫才有效，而<code>aria-labelledby="label"</code>讓你可以在一個元素上置放一個ID，當該頁面上任何內容設定標籤後而引用它，頁面包含多個元素而不可能使用<code><label for="input"></code>。舉例，你可使用<code>aria-labelledby</code>指定一個鍵盤鍵描述包含在一個{{htmlelement("div")}}之中是多個表格儲存格的標籤，或者你可使用它做為圖片alt文字的替代方案 — 指定頁面上現有的資訊做為圖片的alt文字，而非將它重複放在<code>alt</code>屬性之內. 範例可參考<a href="/en-US/docs/Learn/Accessibility/HTML?document_saved=true#Text_alternatives">Text alternatives</a>。</li> + <li><strong>States</strong> — 定義目前元素狀態的特殊屬性，例如 <code>aria-disabled="true"</code>，是對螢幕報讀器指定表單輸入目前是停用的狀態。狀態不同於屬性，在於屬性在應用程序整個生命週期中不會改變，而狀態通常會透過 JavaScript程式化改變。</li> +</ul> + +<p>有關WAI-ARIA屬性的重要觀點是他們不會影響網頁的任何內容，除了透過瀏覽器無障礙API揭露資訊之外(螢幕報讀器即從中獲得資訊)。儘管WAI-ARIA屬性對CSS選擇元素很有用，但不會影響網頁結構、DOM等。</p> + +<div class="note"> +<p><strong>注意：</strong>你可以在WAI-ARIA規格中找到所有ARIA的角色及其用法的很有用清單，請參見 <a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">Definition of Roles</a>連結以獲得更進一步的資訊。</p> + +<p>本規格也涵括所有屬性與狀態的清單，請參見 <a href="https://www.w3.org/TR/wai-aria-1.1/#state_prop_def">Definitions of States and Properties (all aria-* attributes)</a>連結以獲得更進一步的資訊。</p> +</div> + +<h3 id="哪裡支援WAI-ARIA？">哪裡支援WAI-ARIA？</h3> + +<p>這不是一個容易回答的問題。要難找到一個決定性的資源來陳述何者是支援WAI-ARIA的特點以及在何處，因為：</p> + +<ol> + <li>在WAI-ARIA規格中有很多特點。</li> + <li>要考量作業系統、瀏覽器與螢幕報讀器的許多組合。</li> +</ol> + +<p>最後一點是關鍵—首先要使用螢幕報讀器，你的作業系統必須執行具有必要的無障礙API的瀏覽器去揭露螢幕報讀器必須去完成工作的資訊。大部分主流的作業系統有1個或2個瀏覽器可供螢幕報讀器使用。Paciello Group一則最近的文章提供這些數據—請參見 <a href="https://www.paciellogroup.com/blog/2014/10/rough-guide-browsers-operating-systems-and-screen-reader-support-updated/">Rough Guide: browsers, operating systems and screen reader support updated</a>。</p> + +<p>接著，你必須擔心瀏覽器是否支援ARIA特徵並透過其API揭露，同時螢幕報讀器是否辨識該資訊並以可用的方式向使用者呈現的問題。</p> + +<ol> + <li>瀏覽器支援一般相當好—在撰文當下， <a href="http://caniuse.com/#feat=wai-aria">caniuse.com</a>表示全球瀏覽器對WAI-ARIA的支援率大約為88%。</li> + <li>螢幕報讀器對ARIA特徵的支援沒有相當於此水平，但大部分主流的螢幕報讀器是有達到此水平。你可查閱Powermapper的 <a href="http://www.powermapper.com/tests/screen-readers/aria/">WAI-ARIA Screen reader compatibility</a>這篇文章了解支援的水平。</li> +</ol> + +<p>在本文中，我們未試圖涵蓋每一個WAI-ARIA特徵及其確切的支援細節。相反地，我們將涵蓋最關鍵的WAI-ARIA特徵讓你知道；如果我們沒有提到任何支援細節，你可認定該特徵得到很好的支援。我們會明確地提到這個例外情況。</p> + +<div class="note"> +<p><strong>注意</strong>:某些JavaScript儲存庫支援WAI-ARIA，亦即當他們產生UI特徵如複雜的表單控制措施，他們添加ARIA屬性來增進這些特徵的無障礙。如果你在尋找第三方的JavaScript解決方案來快速的開發UI，你應該謹慎地考量其UI插件的無障礙作為你決定使用的重要因素。jQuery UI(參見<a href="https://jqueryui.com/about/#deep-accessibility-support">About jQuery UI: Deep accessibility support</a>)、 <a href="https://www.sencha.com/products/extjs/">ExtJS</a>與 <a href="https://dojotoolkit.org/reference-guide/1.10/dijit/a11y/statement.html">Dojo/Dijit</a>是良好範例。</p> +</div> + +<h3 id="何時應該使用WAI-ARIA"><strong>何時應該使用WAI-ARIA?</strong></h3> + +<p>我們討論了促使WAI-ARIA早期建立的一些問題，但基本上WAI-ARIA在4個主要領域很有用：</p> + +<ol> + <li><strong>路標/地標：</strong>ARIA的角色屬性值可作為地標，不是複製HTML5元素的語意(如{{htmlelement("nav")}})，就是超越HTML5語意而對不同的功能區域提供路標，如搜尋、頁籤群組、頁籤、清單框等。</li> + <li><strong>動態內容更新：</strong>螢幕報讀器往往難以報讀不斷改變的內容；當某個內容區域更新時，我們可以使用aria-live通知螢幕報讀器的使用者，例如透過 <a href="/en-US/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a>或<a href="/en-US/docs/Web/API/Document_Object_Model">DOM APIs</a>。</li> + <li><strong>增強鍵盤無障礙</strong>：內建的HTML元素具有原生的鍵盤無障礙；當其他元素伴隨使用JavaScript模擬相似的互動時，鍵盤無障礙操作與螢幕報讀器報讀會遭遇問題。如果這是不可避免的，WAI-ARIA提供讓其他元素獲得焦點的一種方法(使用 <code>tabindex</code>)。</li> + <li><strong>非語意控制措施的無障礙</strong>：當一系列巢狀的<code><div></code>搭配CSS/JavaScript用於創建一個複雜的UI特徵，或者一個透過JavaScript大幅增強/改變的原生控制措施，無障礙會遭遇到困難—如果沒有語意或其他線索，螢幕報讀器使用者將發覺難以理解該特徵的作用。在這種情況下，ARIA可以幫助提供缺失的部分使用如按鈕、清單框或頁籤群組等角色組合，以及aria-required 或aria-posinset等屬性對功能性提供進一步的線索。</li> +</ol> + +<p>記住一件事 — <strong>僅在必需時才使用WAI-ARIA! </strong>理想情況下，你應該總是使用<a>原生HTML特徵</a>提供螢幕報讀器所需要的語意來告訴其使用者接下來將發生甚麼事情。有時候這是不可能的情形，不是因為你受限於控制該程式碼，就是因為你創建一些複雜而無法用簡易的HTML元素來開發。在這種情況下，WAI-ARIA可作為有價值的無障礙增強工作。</p> + +<p>再說一次，只有需要的時候才使用它！</p> + +<div class="note"> +<p><strong>注意</strong>: 請確保有各類實際的使用者來測試你的網站 — 非身障者、使用螢幕報讀器者、使用鍵盤導覽者等。他們將比你更能了解它運作的效果。</p> +</div> + +<h2 id="實作WAI-ARIA開發">實作WAI-ARIA開發</h2> + +<p>在下一個章節我們將更仔細地看看這4個領域，並附帶實際的範例。在繼續之前，你應該將備妥螢幕報讀器測試設置，以便在過程中你可以測試這些範例。</p> + +<p>更多資訊請參見<a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Screenreaders">螢幕報讀器測試</a>章節。</p> + +<h3 id="路標地標"><strong>路標/地標</strong></h3> + +<p>WAI-ARIA添加<a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">角色屬性</a>給瀏覽器，讓你可以在必要時添加額外的語意值到你網站上的元素。這第一個主要的領域在為螢幕報讀器提供資訊方面非常有用，讓螢幕報讀器的使用者可以找到常見的頁面元素。我們來看個範例 — <a href="https://github.com/mdn/learning-area/tree/master/accessibility/aria/website-no-roles">網站-無-角色</a>範例(<a href="http://mdn.github.io/learning-area/accessibility/aria/website-no-roles/">看實際頁面</a>)有以下的結構：</p> + +<pre class="brush: html"><header> + <h1>...</h1> + <nav> + <ul>...</ul> + <form> + <!-- search form --> + </form> + </nav> +</header> + +<main> + <article>...</article> + <aside>...</aside> +</main> + +<footer>...</footer></pre> + +<p>若你嘗試在現代瀏覽器中使用螢幕報讀器來測試此範例，你將可以獲得一些有用的資訊。例如，VoiceOver給你以下的資訊：</p> + +<ul> + <li>在 <code><header></code> 元素上— "橫幅，2個項目"(含有一個標題與 <code><nav></code>)。</li> + <li>在 <code><nav></code> 元素上—"導航列 2個項目" (含有一個清單與一個表單)。</li> + <li>在 <code><main></code> 元素上—"主要內容 2個項目" (含有一則文章與一個附帶內容)。</li> + <li>在<code><aside></code> 元素上—"補充 2個項目" (含有一個標題與一個清單)。</li> + <li>在搜尋表單輸入—"搜尋查詢，插入文字開始處"。</li> + <li>在<code><footer></code> 元素上—"頁尾1個項目"。</li> +</ul> + +<p>如果你到VoiceOver地標選單(使用VoiceOver主鍵+ U，然後使用游標鍵循環整個選單選項)，你會看到大部分元素被列的很好，因此可以很快地訪問他們。</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14420/landmarks-list.png" style="display: block; margin: 0 auto;"></p> + +<p>然而，這裡我們可以做得更好，搜尋表單是一個人們想要找到的很重要的地標，但是它並沒有列在地標選項之中或者被視為顯著的地標，除了在實際輸入而被召喚作為搜尋輸入之外(<code><input type="search"></code>)。另外，有些舊的瀏覽器(大部分是指IE8)無法辨識HTML5元素的語意。</p> + +<p>讓我們使用一些ARIA特徵來改善它。首先，我們將添加一些角色屬性到我們的HTML結構。你可以試著複製我們原始的檔案(參見<a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/website-no-roles/index.html">index.html</a>與<a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/website-no-roles/style.css">style.css</a>)，或者瀏覽我們的<a href="https://github.com/mdn/learning-area/tree/master/accessibility/aria/website-aria-roles">網站-aria-角色</a>範例(<a href="http://mdn.github.io/learning-area/accessibility/aria/website-aria-roles/">看實際頁面</a>)，其結構如下：</p> + +<pre class="brush: html"><header> + <h1>...</h1> + <nav role="navigation"> + <ul>...</ul> + <form role="search"> + <!-- search form --> + </form> + </nav> +</header> + +<main> + <article role="article">...</article> + <aside role="complementary">...</aside> +</main> + +<footer>...</footer></pre> + +<p>在本範例中我們也將給你一個額外的特徵—{{htmlelement("input")}} 元素賦予 <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-label">aria-label</a></code>屬性，藉由給予描述性的標籤讓螢幕報讀器可以報讀出來，即使我們沒有包含{{htmlelement("label")}}元素。像這種情況就非常有用—搜尋表單是一個非常常見、容易辨識的特徵，而添加視覺的標籤可能破壞頁面的設計。</p> + +<pre class="brush: html"><input type="search" name="q" placeholder="Search query" aria-label="Search through site content"></pre> + +<p>現在如果我們使用VoiceOver來看這個範例，我們可以獲得一些改善：</p> + +<ul> + <li>召喚搜尋表單當作獨立的項目，無論是在瀏覽頁面，或在地標選項之中。</li> + <li>當表單輸入凸顯時，將報讀出包含在<code>aria-label</code>屬性的標籤文字。</li> +</ul> + +<p>除此之外，該網站對舊瀏覽器如IE8的使用者更可能無障礙；為了這個目的，包含ARIA角色是值得的。如果為了某些原因，你的網站僅使用 <code><div></code>建置，那麼肯定你應該包含ARIA角色來提供這些非常需要的語意！</p> + +<p>當ARIA超越從HTML5所能獲得的語意時，搜尋表單的改進語意已經顯示實現的可能性。你將會在下面看到更多關於這些語意與ARIA屬性的能力，尤其在{{anch("Accessibility of non-semantic controls")}}章節。現在，我們先來看看ARIA如何幫助動態內容更新。</p> + +<h3 id="動態內容更新">動態內容更新</h3> + +<p>從文本內容到附著於圖片的替代文字，其內容載入至DOM中可方便螢幕報讀器使用。因此，大部分使用文字內容的傳統靜態網站能輕易讓視覺障礙者無障礙使用。</p> + +<p>問題在於現代網頁應用程式通常不只是靜態的文字—他們傾向有很多動態更新的內容，例如透過像<a href="/en-US/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a>, <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a>, 或<a href="/en-US/docs/Web/API/Document_Object_Model">DOM APIs</a>等機制更新的內容而不必重新載入全部的頁面。這些有時稱為即時區塊。</p> + +<p>我們來看一個簡單的範例—請看 <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-no-live.html">aria-no-live.html</a> (<a href="http://mdn.github.io/learning-area/accessibility/aria/aria-no-live.html">看實際頁面</a>)。本範例中我們有簡單的隨機引言框：</p> + +<pre class="brush: html"><section> + <h1>Random quote</h1> + <blockquote> + <p></p> + </blockquote> +</section></pre> + +<p>我們的JavaScript透過含有一系列的隨機引言與其作者的 <code><a href="/en-US/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a></code> <code>載入一個</code>JSON檔案。一旦這些完成，我們就開始 <code><a href="/en-US/docs/Web/API/WindowTimers/setInterval">setInterval()</a></code> 迴圈每10秒載入新的隨機引言到引言框之中。</p> + +<pre class="brush: js">var intervalID = window.setInterval(showQuote, 10000);</pre> + +<p>這個運作正常，但對無障礙不是很好—此內容更新無法被螢幕報讀器所偵測，所以他們的使用者不知道發生甚麼事情。這是一個相當平凡的例子，但只要想像一下如果你正在創建一個有著大量不斷更新內容的複雜UI，如聊天室、一個策略型的遊戲UI、或者一個即時更新的購物車顯示窗—則將不可能以任何有效的方式使用該應用程式而沒有某種提醒使用者該更新內容的方法。</p> + +<p>很幸運地WAI-ARIA提供一項有用的機制來提供這些警告—即<code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-live">aria-live</a></code> 屬性。將此屬性用在元素上可讓螢幕報讀器讀出更新的內容。報讀內容的緊急性決定於以下屬性值：</p> + +<ul> + <li><code>off:</code> 預設值，更新不應該通知。</li> + <li><code>polite</code>: 更新應該只在使用者空閒時才通知。</li> + <li><code>assertive</code>: 更新應盡快通知使用者。</li> + <li><code>rude</code>: 更新應立即通知，即使打斷使用者。</li> +</ul> + +<p>一般而言， <code>assertive</code> 設置足以讓你的更新內容在他們出現時依序地讀出，因此如果同時有多個事件改變，你將獲得所有的更新。只有對非常高優先順序的更新使用 <code>rude</code> 才能覆蓋其他所有的更新。</p> + +<p>我們希望你複製 <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-no-live.html">aria-no-live.html</a> 與 <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/quotes.json">quotes.json</a>，並更新 <code><section></code> 標籤如下所示：</p> + +<pre class="brush: html"><section aria-live="assertive"></pre> + +<p>這將使螢幕報讀器在內容更新時讀出更新的內容。</p> + +<div class="note"> +<p><strong>注意</strong>: 如果你嘗試從 <code>XMLHttpRequest</code> 執行 <code>file://</code> URL<code>，</code>大部分的瀏覽器會拋出安全異常，例如你直接上傳該檔案到瀏覽器(透過雙擊滑鼠鍵等)。為了這項可以執行，你需要將檔案上傳到一個網站伺服器如<a href="/en-US/docs/Learn/Common_questions/Using_Github_pages"> GitHub</a>，或本機網站伺服器如 <a href="http://www.pythonforbeginners.com/modules-in-python/how-to-use-simplehttpserver/">Python's SimpleHTTPServer</a>。</p> +</div> + +<p>這裡有一項額外的考量—只有文字更新才讀出。如果我們也總是讀出標題，那將很好，以讓使用者記住讀出的內容。為做到這樣，我們可以添加 <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-atomic">aria-atomic</a></code> 屬性到這個部分，再次更新您的 <code><section></code> 標籤如下所示：</p> + +<pre class="brush: html"><section aria-live="assertive" aria-atomic="true"></pre> + +<p><code>aria-atomic="true"</code>屬性告訴螢幕報讀器以一個原子單位方式讀出完整的元素內容，而不僅只讀出更新的部分。</p> + +<div class="note"> +<p><strong>注意</strong>:你可以查看完成的範例 <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-live.html">aria-live.html</a> (<a href="http://mdn.github.io/learning-area/accessibility/aria/aria-live.html">看實際頁面</a>)。</p> +</div> + +<div class="note"> +<p><strong>注意</strong>: <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-relevant">aria-relevant</a></code> 屬性在即時區塊更新時對於控制讀出甚麼內容也相當有用，例如你可以僅獲得讀出新增或移除的內容。</p> +</div> + +<h3 id="增強鍵盤無障礙"><strong>增強鍵盤無障礙</strong></h3> + +<p>如同在本模組其他章節所討論， HTML關於無障礙的關鍵優勢之一是內建鍵盤無障礙特徵如按鈕、表單控制措施及連結。一般而言，你可以使用tab鍵在控制措施之間移動，輸入(Enter)/返回(Return)鍵用來選擇或觸發控制措施，以及偶爾需要其他的控制措施(例如上下游標在 <code><select></code> 框中的選項間移動)。</p> + +<p>然而，有時你最終必須撰寫不是使用非語意的元素如按鈕(或其他控制的型態)，或者使用可獲焦點的控制措施用作非正確目的程式碼。你可能嘗試修正一些繼承來的不好的程式碼，或者你可能創建需要某些種類的複雜插件。</p> + +<p>讓非焦點的程式碼可獲得焦點，WAI-ARIA使用一些新值擴展 <code>tabindex</code> 屬性：</p> + +<ul> + <li><code>tabindex="0"</code> —如上述，此值允許正常不被tab遊走到的元素變得可以tab遊走，這是<code>tabindex</code>最有用的值。</li> + <li><code>tabindex="-1"</code> — 此允許正常不被tab遊走到的元素，可以程式化地獲得焦點，如透過JavaScript或作為連結的對象。</li> +</ul> + +<p>我們更詳細討論這一點並在我們的HTML無障礙文章中展示典型的實作—請參見 <a href="/en-US/docs/Learn/Accessibility/HTML#Building_keyboard_accessibility_back_in">Building keyboard accessibility back in</a>.</p> + +<h3 id="非語意控制措施的無障礙">非語意控制措施的無障礙</h3> + +<p>本部份接續前一章節—當一系列巢狀的 <code><div></code>搭配CSS/JavaScript用於創建一個複雜的UI特徵，或者一個透過JavaScript大幅增強/改變的原生控制措施，不僅鍵盤無障礙會遭遇到困難，而且如果沒有語意或其他線索，螢幕報讀器使用者也會發覺難以理解該特徵的作用。在這種情況下，ARIA可以幫助提供缺失的語意。</p> + +<h4 id="表單驗證與錯誤警告">表單驗證與錯誤警告</h4> + +<p>首先，讓我們再看一次在我們的CSS與JavaScript無障礙文章中第一次看的表單範例(請閱讀 <a href="/en-US/docs/Learn/Accessibility/CSS_and_JavaScript#Keeping_it_unobtrusive">Keeping it unobtrusive</a>完整回顧)。在本章節文末我們展示當你試著送出表單而驗證錯誤時，出現我們包含一些在錯誤訊息框的ARIA屬性。</p> + +<pre class="brush: html"><code class="language-html"><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>div</span> <span class="attr-name token">class</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>errors<span class="punctuation token">"</span></span> <span class="attr-name token">role</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>alert<span class="punctuation token">"</span></span> <span class="attr-name token">aria-relevant</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>all<span class="punctuation token">"</span></span><span class="punctuation token">></span></span> + <span class="tag token"><span class="tag token"><span class="punctuation token"><</span>ul</span><span class="punctuation token">></span></span> + <span class="tag token"><span class="tag token"><span class="punctuation token"></</span>ul</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>div</span><span class="punctuation token">></span></span></code></pre> + +<ul> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#alert">role="alert"</a></code> 自動地將其應用的該元素轉換為即時區塊，以利讀出它的改變；它也將語意地辨識其為警告訊息(重要時間/內容脈絡敏感資訊)，而呈現以更好、更無障礙的方式向使用者傳遞警告(模態對話框如 <code><a href="/en-US/docs/Web/API/Window/alert">alert()</a></code> 具有許多無障礙的問題；請參見WebAIM的 <a href="http://webaim.org/techniques/javascript/other#popups">Popup Windows</a>)。</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-relevant">aria-relevant</a></code> 的all值指示螢幕報讀器當它任何改變時讀出錯誤清單的內容—例如當錯誤新增或移除時。這個很有用因為使用者會想知道留著的錯誤是甚麼，而不只有知道清單中甚麼是已經新增或移除。</li> +</ul> + +<p>我們可進一步使用我們的ARIA，並提供更多的驗證協助。如何指出區塊是否需要在第一個位置，以及年齡的範圍應該多少？</p> + +<ol> + <li>在此，複製我們的 <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/form-validation.html">form-validation.html</a> 與 <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/validation.js">validation.js</a> 檔案，並將他們儲存在本機目錄。</li> + <li>在文字編輯器開啟他們並且看一下該程式碼如何運作。</li> + <li>首先，在開始的 <code><form></code> 標籤之上增加一個段落，如下所示，並且用星號標記兩個表單的 <code><label></code>。這是一般我們對有視力的使用者標記必要區塊的方法。 + <pre class="brush: html"><p>Fields marked with an asterisk (*) are required.</p></pre> + </li> + <li>這讓視覺有意義，但這對螢幕報讀器使用者不能輕易理解。很幸運地，WAI-ARIA提供 <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-required">aria-required</a></code> 屬性以提示螢幕報讀器應告訴使用者需要填寫的表單輸入欄位。更新<code><input></code> 元素如下： + <pre class="brush: html"><input type="text" name="name" id="name" aria-required="true"> + +<input type="number" name="age" id="age" aria-required="true"></pre> + </li> + <li>如果你現在儲存本範例並使用螢幕報讀器測試，你應該聽到這個內容 "Enter your name star, required, edit text"。</li> + <li>如果我們給予螢幕報讀器使用者與視覺的使用者有關年齡的值應該是甚麼的概念，這樣也將會很有用。這個或許常以提示或在表單輸入區內預設文本的方式呈現。WAI-ARIA用包含 <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-valuemin">aria-valuemin</a></code> 與 <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-valuemax">aria-valuemax</a></code> 屬性來指定最小與最大值，但這些目前未受到很好的支持；比較受支持的特徵是 HTML5 <code>placeholder</code> 屬性，它在沒有輸入值的時間將含有的訊息顯示在輸入框，並能由許多螢幕報讀器讀出。更新你的數值輸入如下所示： + <pre class="brush: html"><input type="number" name="age" id="age" placeholder="Enter 1 to 150" aria-required="true"></pre> + </li> +</ol> + +<div class="note"> +<p><strong>注意</strong>：你可以查看完成的範例 <a href="http://mdn.github.io/learning-area/accessibility/aria/form-validation-updated.html">form-validation-updated.html</a>。</p> +</div> + +<p>除了傳統的 {{htmlelement("label")}} 元素之外，WAI-ARIA也能賦予一些進階的表單標籤技術。我們已經談論過使用 <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-label">aria-label</a></code> 屬性在我們不希望標籤讓有視覺的使用者看見的地方來提供標籤(參見上述 {{anch("Signposts/Landmarks")}} 章節。如果你想要指定一個非<code><label></code> 元素當作標籤或具有相同標籤多重的表單輸入標籤，這裡有使用其他屬性如 <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby">aria-labelledby</a></code> 的其他標籤技術，如果你想要其他的訊息與表單輸入關聯並且報讀出來，使用 <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-describedby">aria-describedby</a></code>。更多細節請參見 <a href="http://webaim.org/techniques/forms/advanced">WebAIM's Advanced Form Labeling article</a><span class="subtitle"> 。</span></p> + +<p>還有許多其他有用的屬性與狀態，用來指出表單元素的狀態。例如，<span class="subtitle"> <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-disabled">aria-disabled</a>="true"</code> </span>可用於指出表單區域是處於停用的狀態。許多瀏覽器只會跳過停用的表單區塊，並且甚至不會被螢幕報讀器讀出，但在某些情況下，他們可被感知，所以最好包含此屬性讓螢幕報讀器知道停用的輸入事實上即是停用的狀態。</p> + +<p>如果輸入的停用狀態可能產生改變，也最好在發生時指出，以及其結果為何。例如，在我們的<span class="subtitle"> <a href="http://mdn.github.io/learning-area/accessibility/aria/form-validation-checkbox-disabled.html">form-validation-checkbox-disabled.html</a> </span>展示中，當核取框被核取時，可以讓另一個表單輸入允許輸入更進一步的資訊。我們已經設置一個隱藏的即時區塊：</p> + +<pre class="brush: html"><p class="hidden-alert" aria-live="assertive"></p></pre> + +<p>這是使用絕對位置從視窗中隱藏。當核取/未核取時，我們更新在隱藏的即時區塊中的文字，告訴螢幕報讀器使用者選取這個核取框時結果會是甚麼，以及更新 <code>aria-disabled</code> 的狀態，連同一些視覺的指示：</p> + +<pre class="brush: js">function toggleMusician(bool) { + var instruItem = formItems[formItems.length-1]; + if(bool) { + instruItem.input.disabled = false; + instruItem.label.style.color = '#000'; + instruItem.input.setAttribute('aria-disabled', 'false'); + hiddenAlert.textContent = 'Instruments played field now enabled; use it to tell us what you play.'; + } else { + instruItem.input.disabled = true; + instruItem.label.style.color = '#999'; + instruItem.input.setAttribute('aria-disabled', 'true'); + instruItem.input.removeAttribute('aria-label'); + hiddenAlert.textContent = 'Instruments played field now disabled.'; + } +}</pre> + +<h4 id="描述非語意按鈕為按鈕">描述非語意按鈕為按鈕</h4> + +<p>本課程我們已經談過幾次按鈕、連結或表單元素(參見HTML無障礙文章的 <a href="/en-US/docs/Learn/Accessibility/HTML#UI_controls">UI controls</a> ，以及前述{{anch("Enhancing keyboard accessibility")}}的原生無障礙(以及在使用其他元素偽造背後的無障礙議題)。基本上，使用 <code>tabindex</code> 與一些 JavaScript，在很多情況下，你可以在沒有太多困難下增加鍵盤無障礙支援功能。</p> + +<p>但螢幕報讀器的情況如何呢？他們仍然無法將這些元素視為按鈕。如果我們用螢幕報讀器測試我們的 <a href="http://mdn.github.io/learning-area/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">fake-div-buttons.html</a> 範例，我們偽造的按鈕將會用句子如 "Click me!, group"讀出，很顯然地令人困惑。</p> + +<p>我們可以使用WAI-ARIA角色來修正它。請複製 <a href="https://github.com/mdn/learning-area/blob/master/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">fake-div-buttons.html</a>在本機，並且對每個按鈕<code><div></code>增加 <code><a href="https://www.w3.org/TR/wai-aria-1.1/#button">role="button"</a></code> ，範例如下：</p> + +<pre><div data-message="This is from the first button" tabindex="0" role="button">Click me!</div></pre> + +<p>現在當你使用螢幕報讀器測試它時，按鈕將會用句子如"Click me!, button" 讀出—這樣好多了。</p> + +<div class="note"> +<p>注意：記住最好盡可能使用正確的語意元素，如果你希望創建一個按鈕，並且可使用 {{htmlelement("button")}} 元素，就應該使用 {{htmlelement("button")}} 元素！</p> +</div> + +<h4 id="透過複雜的插件引導使用者">透過複雜的插件引導使用者</h4> + +<p>除了標準HTML可用外，還有一堆其他<a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">角色</a>可以辨識非語意的元素結構作為一般的使用者介面特徵，例如 <code><a href="https://www.w3.org/TR/wai-aria-1.1/#combobox">combobox</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#slider">slider</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tabpanel">tabpanel</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tree">tree</a></code>。你可在 <a href="https://dequeuniversity.com/library/">Deque university code library</a>中找到很多有用的範例，可給你這些控制措施如何做到無障礙的想法。</p> + +<p>我們來看看我們自己的範例，我們回到我們簡單的絕對位置頁籤的介面(參見在我們的CSS與JavaScript無障礙文章中的 <a href="/en-US/docs/Learn/Accessibility/CSS_and_JavaScript#Hiding_things">Hiding things</a> )，你可以找到 <a href="http://mdn.github.io/learning-area/css/css-layout/practical-positioning-examples/info-box.html">頁籤資訊框範例</a>(看<a href="https://github.com/mdn/learning-area/blob/master/css/css-layout/practical-positioning-examples/info-box.html">原始碼</a>).</p> + +<p>本範例以鍵盤無障礙而言運作正常—你可以開心地在不同的頁籤間跳位，並且選擇他們顯示該頁籤的內容，也相當地容易操作—你可以滾動內容並使用標題來導覽，即使你看不到螢幕上正發生的事情。然而內容是甚麼並非很明顯—螢幕報讀器目前以連結的清單報讀內容，以及有三個標題的內容。這樣無法給你了解內容之間的關係。最好給予使用者更多關於內容結構的線索。</p> + +<p>為改善這些，我們創建新的範例版本為 <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-tabbed-info-box.html">aria-tabbed-info-box.html</a> (<a href="http://mdn.github.io/learning-area/accessibility/aria/aria-tabbed-info-box.html">看實際頁面</a>)，我們已經更新頁籤介面的結構如下：</p> + +<pre class="brush: html"><ul role="tablist"> + <li class="active" role="tab" aria-selected="true" aria-setsize="3" aria-posinset="1" tabindex="0">Tab 1</li> + <li role="tab" aria-selected="false" aria-setsize="3" aria-posinset="2" tabindex="0">Tab 2</li> + <li role="tab" aria-selected="false" aria-setsize="3" aria-posinset="3" tabindex="0">Tab 3</li> +</ul> +<div class="panels"> + <article class="active-panel" role="tabpanel" aria-hidden="false"> + ... + </article> + <article role="tabpanel" aria-hidden="true"> + ... + </article> + <article role="tabpanel" aria-hidden="true"> + ... + </article> +</div></pre> + +<div class="note"> +<p><strong>注意</strong>: 這裡最引人注目的是我們移除在原來範例中的連結，並且只使用清單項目作為頁籤—這樣做是因為對螢幕報讀器使用者比較少困擾(連結並非真正地帶妳到哪個地方；他們只是改變視窗)，並且可讓組件大小/位置在組件特徵中有很好的運作—當這些是放在連結上的時候，瀏覽器將維持報讀"1 of 1"，而非"1 of 3"、"2 of 3"等。</p> +</div> + +<p>新的特徵如下：</p> + +<ul> + <li>新的角色— <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tablist">tablist</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tab">tab</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tabpanel">tabpanel</a></code> — 這些確認頁籤介面的重要區域—頁籤的容器、頁籤本身，以及相對應的頁籤控制盤。</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-selected">aria-selected</a></code> — 定義目前被選取的是哪一個頁籤。當不同的頁籤被使用者選取時，本屬性在不同頁籤的值透過JavaScript更新。</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-hidden">aria-hidden</a></code> — 隱藏元素不讓螢幕報讀器讀出來。當不同的頁籤被使用者選取時，本屬性在不同頁籤的值透過JavaScript更新。</li> + <li><code>tabindex="0"</code> — 由於我們已經移除連結，我們需要給予清單項目本屬性，提供鍵盤焦點。</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-setsize">aria-setsize</a></code> — T本屬性允許你向螢幕報讀器指定某元素是一系列中的部分，以及該系列有多少項目。</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-posinset">aria-posinset</a></code> — 本屬性允許你指定某個元素在一系列中的位置，伴隨 <code>aria-setsize，</code>提供螢幕報讀器有足夠資訊來告訴你目前的位置在"1 of 3"項目等。在許多情況下，瀏覽器應該可從元素層級結構推測這項資訊，但它肯定有助於提供更多的線索。</li> +</ul> + +<p>在我們的測試中，這些新的結構確實提供整體的改善。頁籤現在被認定為頁籤(如螢幕報讀器讀出"索引標籤")，被選取的頁籤以”已選取”指出並讀出頁籤的名稱，螢幕報讀器也告訴你目前所在的頁籤數目。此外，因為設置 <code>aria-hidden</code> (只有非隱藏的頁籤才設定<code>aria-hidden="false"</code> )，非隱藏的頁籤是唯一你可以向下導覽的內容，意即所選取的內容很容易找到。</p> + +<div class="note"> +<p>注意：如果有任何你很明確地不希望螢幕報讀器讀出的內容，你可賦予它們 <code>aria-hidden="true"</code> 屬性。</p> +</div> + +<h2 id="總結">總結</h2> + +<p>本文並未涵蓋所有WAI-ARIA的內容，但應該給予你足夠的資訊來了解如何使用它，以及了解一些你會遇到而需要它的最常見型態。</p> + +<h2 id="相關參考資訊">相關參考資訊</h2> + +<ul> + <li><a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">Definition of Roles</a> — ARIA角色參考資訊。</li> + <li><a href="https://www.w3.org/TR/wai-aria-1.1/#state_prop_def">Definitions of States and Properties (all aria-* attributes)</a> — 屬性與狀態參考資訊。</li> + <li><a href="https://dequeuniversity.com/library/">Deque university code library</a> — 實用的範例資源庫，展示使用WAI-ARIA特徵讓複雜的UI控制措施無障礙</li> + <li><a href="http://w3c.github.io/aria-practices/">WAI-ARIA Authoring Practices</a> — 由W3C發佈之非常詳細的設計模型，解釋如何使用WAI-ARIA特徵實作不同類型的複雜UI控制措施無障礙</li> + <li><a href="https://www.w3.org/TR/html-aria/">ARIA in HTML</a> — W3C標準針對每一個HTML特徵定義由瀏覽器設置隱含特徵的無障礙(ARIA)語意，以及如果需要額外的語意，你可以設置的WAI-ARIA特徵。</li> +</ul> + +<p>{{PreviousMenuNext("Learn/Accessibility/CSS_and_JavaScript","Learn/Accessibility/Multimedia", "Learn/Accessibility")}}</p> + +<p> </p> + +<h2 id="本模組章節">本模組章節</h2> + +<ul> + <li><a href="/en-US/docs/Learn/Accessibility/What_is_accessibility">何謂無障礙網頁?</a></li> + <li><a href="/en-US/docs/Learn/Accessibility/HTML">HTML: 無障礙網頁的好開始</a></li> + <li><a href="/en-US/docs/Learn/Accessibility/CSS_and_JavaScript">充分實踐CSS與JavaScript的無障礙</a></li> + <li><a href="/en-US/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA基礎</a></li> + <li><a href="/en-US/docs/Learn/Accessibility/Multimedia">無障礙多媒體</a></li> + <li><a href="/en-US/docs/Learn/Accessibility/Mobile">行動無障礙網頁</a></li> + <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Accessibility/Accessibility_troubleshooting">無障礙問題排除</a></li> +</ul> + +<p> </p> diff --git a/files/zh-tw/learn/accessibility/what_is_accessibility/index.html b/files/zh-tw/learn/accessibility/what_is_accessibility/index.html new file mode 100644 index 0000000000..35e520c814 --- /dev/null +++ b/files/zh-tw/learn/accessibility/what_is_accessibility/index.html @@ -0,0 +1,201 @@ +--- +title: 何謂無障礙網頁？ +slug: Learn/Accessibility/What_is_accessibility +translation_of: Learn/Accessibility/What_is_accessibility +--- +<div>{{LearnSidebar}}</div> + +<div>{{NextMenu("Learn/Accessibility/HTML", "Learn/Accessibility")}}</div> + +<p class="summary">這篇文章給「到底什麼是無障礙網頁」的模塊，開了個好起頭：以下將包括我們該考慮什麼樣的用戶以及理由、不同的人要在 web 用什麼工具互動、還有如何令無障礙網頁成為 web 開發的一部分。</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">先決要求：</th> + <td>基本資訊能力、還有對 HTML 與 CSS 有基本的理解。</td> + </tr> + <tr> + <th scope="row">目標：</th> + <td>熟悉無障礙網頁，包含它是什麼、還有它如何影響作為 web 開發者的你。</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>我們還要提提某些地區的法律規定嗎？</li> +</ul> + +<h2 id="你在鎖定什麼樣的障礙者？">你在鎖定什麼樣的障礙者？</h2> + +<p>身心障礙者和非身心障礙者一樣多元，他們的障別也是如此。重點是，不要光用自己使用電腦和 web 的角度去思考這件事：<em>你並不是無障礙網頁的用戶</em>。下文將解釋應當考慮的障別，還有他們訪問 web 內容的特殊工具（通常稱作 <strong>assistive technologies</strong>、<strong>AT</strong>、<strong>輔助工具</strong>、<strong>輔具</strong>）。</p> + +<div class="note"> +<p><strong>註</strong>：世界衛生組織的<a href="http://www.who.int/mediacentre/factsheets/fs352/zh/">殘疾與健康</a>指出「超過10億人，約佔世界人口的15%，患有某種形式的殘疾。」、且「1.1億至1.9億成年人有很嚴重的功能性障礙。」。</p> +</div> + +<h3 id="視覺障礙">視覺障礙</h3> + +<p>視覺障礙包括盲人、低度視覺、色盲……等等。這類的用戶會使用擴視器（screen magnifier，可能是物理擴視機、或是軟體的縮放功能：當代多數瀏覽器和作業系統都有這種功能），也有些人會用螢幕閱讀器（screen reader，朗讀數位文字的軟體）：</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、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 與 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>（Chrome OS）、<a class="external external-icon" href="https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback">TalkBack</a>（Android）。</li> +</ul> + +<p>熟悉螢幕閱讀器是個好主意；你得設定好螢幕閱讀器、還要會使用它，以理解其工作原理。請參見<a href="/zh-TW/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Screenreaders">cross browser testing screen readers guide</a>以深入理解。以下影片提供了簡單的體驗。</p> + +<p>{{EmbedYouTube("IK97XMibEws")}}</p> + +<p>在統計方面，世界衛生組織表明：「全球視力受損人數約2.53億：3600萬人患有盲症，2.17億人有中度至重度視力損害。」（請參見<a href="http://www.who.int/mediacentre/factsheets/fs282/zh">視力損害和盲症</a>）。如果網站編寫不正確，你的網站就會失去如此龐大的和重要的用戶群：這大約是全美國的總人口數。</p> + +<h3 id="聽覺障礙">聽覺障礙</h3> + +<p>聽覺障礙者、或聾人，是指聽力低落、或毫無聽力的群體。聽覺障礙者通常會用輔具（請參見<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>），但沒有給電腦/web使用的專門輔具。</p> + +<p>不過，請記得有專門技術，會針對有聲內容，提供閱讀的替代文字。有簡單的文本記錄（text transcript）、也有能在影片出現的追蹤文字（text track），例如字幕。接下來將有文章深入探討。</p> + +<p>聽覺障礙者也是龐大的人口，世界衛生組織在<a href="http://www.who.int/mediacentre/factsheets/fs300/zh">耳聾和聽力損失</a>指出：「全球有3.6億人患有殘疾性聽力損失」。</p> + +<h3 id="行動障礙">行動障礙</h3> + +<p>有運動障礙的人，可能是純粹身體問題（例如： 肢體殘缺或癱瘓）或是四肢無力、失去控制等神經或遺傳疾病。他們可能難以使用滑鼠做出精確的手部動作，甚至可能只能使用<a href="http://pattersonmedical.com/app.aspx?cmd=getProductDetail&key=070_921118261">頭指針（head pointer）</a>操作電腦。</p> + +<p>這些殘疾也可能是老化的結果，而不是受到創傷或疾病，或可能是硬體的限制——有些使用者可能沒有滑鼠。</p> + +<p>通常影響開發者開發網站的需求是要能使用鍵盤操作網頁——我們會在後續的文內討論使用鍵盤操作網頁。雖然這個需求有些麻煩，但這是一個很好的主意，請開發者嘗試看看。例如：你可以使用 Tab 鍵在表單中切換填寫項目嗎？你可以在我們的<a href="/zh-TW/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Using_native_keyboard_accessibility">跨瀏覽器測試中找到更多關於使用鍵盤控制網頁的相關資訊</a>。</p> + +<p>統計數據顯示，許多人有行動障礙。 美國疾病控制和預防中心的<a href="http://www.cdc.gov/nchs/fastats/disability.htm">殘疾統計數據（涵蓋範圍為非法人的18歲以上成人）</a>顯示，在美國，有身體機能障礙者佔成人人口的 15.1% 。</p> + +<h3 id="認知障礙">認知障礙</h3> + +<p>最後一類，可能是最廣泛出現的殘疾——認知障礙。認知障礙廣義可涵蓋從精神疾病到學習困難，包含<a href="https://www.nimh.nih.gov/health/topics/attention-deficit-hyperactivity-disorder-adhd/index.shtml">ADHD（注意缺陷多動障礙）</a>、<a href="https://www.nimh.nih.gov/health/topics/autism-spectrum-disorders-asd/index.shtml">自閉症</a>患者、<a href="https://www.nimh.nih.gov/health/topics/schizophrenia/index.shtml">思覺失調</a>以及許多其他相關疾病。這些與記憶、解決問題能力、理解能力與注意力等問題相關的疾病，都大大影響病患的日常生活。</p> + +<p>這些疾病會影響病患使用網站，而最常見的問題就是他們會在理解如何完成網頁操作、記憶以往完成網頁操作的過程、以及經歷各種不同的操作流程與不一致的佈局/導覽列/其他頁面功能時，增加許許多多的挫敗感。</p> + +<p>與其他網路無障礙問題不同，我們無法快速解決認知障礙引起的網路操作問題；<br> + 你唯一能做的就是設計網站時，盡可能符合邏輯性、一致性與可用性，例如：</p> + +<ul> + <li>頁面一致 － 導覽列、頁眉、頁腳和主要內容區塊在每一個頁面都位在相同的位置。</li> + <li><span class="short_text" id="result_box" lang="zh-TW"><span>網站內工具設計精良，易於使用。</span></span></li> + <li>多個階段的流程（例如註冊），被細分有邏輯性的步驟，並提醒使用者如何進行流程，以及他需要多長的時間才能完成流程。</li> + <li>工作流程是合乎邏輯的、簡單的，並且盡可能減少需要與網站互動的流程<br> + 例如：註冊和登入網站常常就是很複雜且不必要的。</li> + <li>適量呈現頁面資訊，盡量讓頁面呈現的資訊不要過多或過密。</li> + <li>適當的用語，頁面呈現的用語須標準或通俗易懂，不要充滿不必要的行話或俚語。</li> + <li>內容的重點處適時以某些方式（例如：使用螢光色標示）突顯出來。</li> + <li>使用者操作錯誤的地方也需要標示出來，並且提供相關訊息或解決方法，幫助使用者解決錯誤。</li> +</ul> + +<p>上述這些並不是「無障礙技術」，但他們是很好的設計理念。他們會讓使用者受益良多，因此他們應該成為你開發網站的工作標準之一。</p> + +<p>康乃爾大學 <a href="http://www.disabilitystatistics.org/StatusReports/2014-PDF/2014-StatusReport_US.pdf">2014 年的殘疾報告</a>顯示，2014 年美國 21 歲至 64 歲的人中，有 4.5% 的人有認知障礙。</p> + +<div class="note"> +<p><strong>注：</strong>WebAIM 的<a href="http://webaim.org/articles/cognitive/">認知頁面</a>提供了更多資訊，值得一讀</p> +</div> + +<h2 id="專案引入無障礙">專案引入無障礙</h2> + +<p>有一個很常見的迷思，就是在專案管理方面，無障礙屬於昂貴的「外加」成本。如果有以下情形的話，這個迷思<em>的確會</em>發生：</p> + +<ul> + <li>針對明顯有障礙的網站，想要「重寫」為無障礙網站。</li> + <li>在專案後期才想到無障礙網頁相關問題時。</li> +</ul> + +<p>如果在專案初期就考慮到無障礙網頁，大多數無障礙內容的成本可以最小化。</p> + +<p>當在規劃專案時，將無障礙測試納入你的測試中，就像測試其他功能一樣（例如：移動裝置 UI 測試）。<br> + 及早測試、經常測試，理想情況是運行自動化測試以檢測缺少的功能（例如：圖片缺少<a href="/zh-TW/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Text_alternatives">替代文字</a>、不好的連結文字 － 請參見 <a href="/zh-TW/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Element_relationships_and_context">Element relationships and context</a>），並做一些測試，為了讓殘疾人士能夠操作更複雜的網站功能。例如：</p> + +<ul> + <li>日期選擇器是否可以提供給螢幕閱讀器的人使用？</li> + <li>如果內容動態更新了，視障人士是否能馬上收到資訊？</li> + <li>使用鍵盤或觸控式介面的人能順利操作我的 UI 按鈕嗎？</li> +</ul> + +<p>你應該記錄自己網站中有問題的地方，並努力讓這些地方變成無障礙或考慮解決方案 / 替代方案，並持續進行測試。文字內容（你可以在下一章看到更多資訊）要做到無障礙很簡單，但是如你想要在網站中放上更多絢麗的 3D 圖形，那應該要怎麼做呢？<br> + 你應該評估專案的預算，並考慮有什麼解決方案可以讓這些絢麗的 3D 圖形容易被存取。<br> + 例如：你可以支付高額的費用，讓那些多媒體內容轉錄成無障礙設備可存取的資訊，雖然昂貴，卻是可行的方案。</p> + +<p>雖然要實現 100% 無障礙網頁是一種難以達成的理想，世事難料，你總是會遇到一些不常見的問題，導致某個使用者難以使用網頁，但你還是應該盡可能做到無障礙網頁。如果你打算使用WebGL製作的炫麗的 3D 圓餅圖，可以撰寫替代的文字，來傳達圖表的資訊。或者你可以只使用表格來傳達資訊而不使用3D 圓餅圖，這樣每個人都可以一目了然表格傳達的資訊、網頁傳輸編碼更快、CPU使用率更低，並且更容易維護。</p> + +<p>但是如果你是一個有趣的 3D 藝術畫廊網站開發者，那麼期待這些藝術品能夠傳達給視障人士，就不太合理，因為圖畫這類的藝術品本身就是透過視覺作為傳達訊息的媒介。</p> + +<p>為了表明你對無障礙網頁的關心，請在你的網站上發佈無障礙網頁聲明，並詳細說明你為無障礙網頁做了哪些事情、採取了哪些步驟。如果有人抱怨你的網站存在無障礙問題，請他們回報給你們，並嘗試解決。</p> + +<div class="note"> +<p><strong>注</strong>：我們的 <a href="/zh-TW/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility">Handling common accessibility problems article</a> 包含了應該進行詳細測試的無障礙網頁規範。</p> +</div> + +<p>總而言之：</p> + +<ul> + <li>在專案初期就考量到無障礙網頁、還要測試得早而多。一如其他錯誤，無障礙網頁問題在越晚發現時，麻煩也越大。</li> + <li>謹記無障礙網頁，是對大家都有利的。例如說，精實的語意標記不只對螢幕閱讀有利，也利於快速載入與效能，從而對大家有利，尤其對行動設備、或是網速過慢的人。</li> + <li>再網站上標明支援無障礙網頁，並鼓勵身心障礙者參與。</li> +</ul> + +<h2 id="無障礙網頁的指引與法律">無障礙網頁的指引與法律</h2> + +<p>有一些針對無障礙網頁的檢查清單和指引能夠用做測試，它們乍看之下可能令人眼花撩亂。我們建議你只要專注熟悉的基本領域、並理解指引裡面，與你最相關的高層次結構。</p> + +<ul> + <li>首先，W3C 針對無障礙網頁的一致性，發布了龐大而詳盡、並包含精確而不講明具體技術的準則文件。它們通常稱作 <a href="https://www.w3.org/WAI/intro/wcag.php">Web Content Accessibility Guidelines</a>（WCAG，無障礙網頁內容指引），無論從哪個角度來說，讀起來都不是普通的長。整個準則能分為以下四大類：它指定如何實做可感知、可操作、可理解、還有健壯（perceivable, operable, understandable, robust）的內容。要取得簡易指引並開始學習，可以去參閱 <a href="https://www.w3.org/WAI/WCAG20/glance/Overview.html">WCAG at a Glance</a>。你不需要學習 WCAG 的一切：只要了解主要的關注領域，並使用各種技術和工具來高亮任何不符 WCAG 標準的領域就型（參閱以下）。</li> + <li>你的國家或地區可能有特別立法，以管理這方面人口的需求：例如美國的 <a href="http://www.section508.gov/content/learn">Section 508 of the Rehabilitation Act</a>、德國的 <a href="https://www.einfach-fuer-alle.de/artikel/bitv_english/">Federal Ordinance on Barrier-Free Information Technology</a>、英國的 <a href="http://www.legislation.gov.uk/ukpga/2010/15/contents">Equality Act</a>、義大利的 <a href="http://www.agid.gov.it/agenda-digitale/pubblica-amministrazione/accessibilita">Accessibilità</a>、還有澳洲的 <a href="https://www.humanrights.gov.au/world-wide-web-access-disability-discrimination-act-advisory-notes-ver-41-2014">Disability Discrimination Act</a>……等等。<br> + （譯註：針對繁體中文，台灣有<a href="https://www.handicap-free.nat.gov.tw">基於《身心障礙者權益保障法》的無障礙網頁開發規範</a>、香港有<a href="https://www.ogcio.gov.hk/tc/community/web_mobileapp_accessibility/promulgating_resources/handbook/doc/Web_Accessibility_Handbook.pdf">基於《殘疾歧視條例》的無障礙設計指引</a>）</li> +</ul> + +<p>因此，儘管 WCAG 有所指引，你的國家可能還是有管理無障礙網頁、或最少針對公眾無障礙服務（可能包含了網站、電視、物理空間……等等）的法案。最好先看看所處地區的法律管轄權。如果不好好檢查內容是否無障礙，當身心障礙者投訴時，你可能會面臨法律問題。</p> + +<p>聽起來很可怕，但只要在開發時，如上所述地把無障礙網頁議題當作高度優先就可以了。如果真的有疑問，請諮詢合格的專業律師。我們不是律師，所以不會提供更深入的意見。</p> + +<h2 id="無障礙網頁_API">無障礙網頁 API</h2> + +<p>瀏覽器使用特殊的<strong>accessibility API</strong>（由各自的作業系統底層提供）對輔助技術（AT）提供有用的信息：輔助技術傾向使用語義訊息，因此這種訊息不包含樣式化資訊、或是 JavaScript。這種資訊建構成一個稱為 <strong>accessibility tree</strong> 的訊息樹（tree of information）。</p> + +<p>不同的作業系統有不同的 accessibility API：</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>如果由 web app 裡面，HTML 元素提供的原生語意訊息出問題了，你可以把它用做 <a href="https://www.w3.org/TR/wai-aria/">WAI-ARIA 規範</a>的補充：它會把語意訊息添加到 accessibility tree 以增進無障礙功能。你可以在 <a href="/zh-TW/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA 基礎</a>文章學習 WAI-ARIA。</p> + +<h2 id="結論">結論</h2> + +<p>本文應當使你對無障礙網頁有著概括性的認知、明白其重要性、並在知道如何在工作流程中安排它。你也該對知道如何實做無障礙網頁的細節有興趣。我們將在下個章節開始闡明為什麼 HTML 是無障礙網頁的好基礎。</p> + +<p>{{NextMenu("Learn/Accessibility/HTML", "Learn/Accessibility")}}</p> + +<h2 id="在本模塊">在本模塊</h2> + +<ul> + <li><a href="/zh-TW/docs/Learn/Accessibility/What_is_accessibility">What is accessibility?</a></li> + <li><a href="/zh-TW/docs/Learn/Accessibility/HTML">HTML: A good basis for accessibility</a></li> + <li><a href="/zh-TW/docs/Learn/Accessibility/CSS_and_JavaScript">CSS and JavaScript accessibility best practices</a></li> + <li><a href="/zh-TW/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA basics</a></li> + <li><a href="/zh-TW/docs/Learn/Accessibility/Multimedia">Accessible multimedia</a></li> + <li><a href="/zh-TW/docs/Learn/Accessibility/Mobile">Mobile accessibility</a></li> + <li><a href="/zh-TW/docs/Learn/Accessibility/Accessibility_troubleshooting">Accessibility troubleshooting</a></li> +</ul> |