From da78a9e329e272dedb2400b79a3bdeebff387d47 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:42:17 -0500 Subject: initial commit --- .../index.html | 222 ++++++++++++++++++ .../aria/aria_live_regions/index.html | 255 +++++++++++++++++++++ .../accessibility/aria/aria_techniques/index.html | 213 +++++++++++++++++ .../using_the_aria-label_attribute/index.html | 66 ++++++ .../web/accessibility/aria/forms/alerts/index.html | 146 ++++++++++++ .../aria/forms/basic_form_hints/index.html | 116 ++++++++++ files/ko/web/accessibility/aria/forms/index.html | 17 ++ files/ko/web/accessibility/aria/index.html | 131 +++++++++++ .../aria/roles/dialog_role/index.html | 158 +++++++++++++ files/ko/web/accessibility/aria/roles/index.html | 78 +++++++ files/ko/web/accessibility/index.html | 49 ++++ .../mobile_accessibility_checklist/index.html | 106 +++++++++ .../accessibility/understanding_wcag/index.html | 59 +++++ .../understanding_wcag/keyboard/index.html | 87 +++++++ 14 files changed, 1703 insertions(+) create mode 100644 files/ko/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.html create mode 100644 files/ko/web/accessibility/aria/aria_live_regions/index.html create mode 100644 files/ko/web/accessibility/aria/aria_techniques/index.html create mode 100644 files/ko/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.html create mode 100644 files/ko/web/accessibility/aria/forms/alerts/index.html create mode 100644 files/ko/web/accessibility/aria/forms/basic_form_hints/index.html create mode 100644 files/ko/web/accessibility/aria/forms/index.html create mode 100644 files/ko/web/accessibility/aria/index.html create mode 100644 files/ko/web/accessibility/aria/roles/dialog_role/index.html create mode 100644 files/ko/web/accessibility/aria/roles/index.html create mode 100644 files/ko/web/accessibility/index.html create mode 100644 files/ko/web/accessibility/mobile_accessibility_checklist/index.html create mode 100644 files/ko/web/accessibility/understanding_wcag/index.html create mode 100644 files/ko/web/accessibility/understanding_wcag/keyboard/index.html (limited to 'files/ko/web/accessibility') diff --git a/files/ko/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.html b/files/ko/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.html new file mode 100644 index 0000000000..8c53f2148f --- /dev/null +++ b/files/ko/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.html @@ -0,0 +1,222 @@ +--- +title: An overview of accessible web applications and widgets +slug: Web/Accessibility/An_overview_of_accessible_web_applications_and_widgets +translation_of: Web/Accessibility/An_overview_of_accessible_web_applications_and_widgets +--- +

웹은 변화하고 있습니다. 페이지 중심의 정적이던 사이트들은 동적으로 변화하고 있고, 데스크톱 웹 어플리케이션들이 JS와 AJAX를 중점으로 사용하며 제작되고 있습니다. 디자이너들은 새로운 위젯들과 컨트롤을 한결같이 JavaScript, HTML, CSS를 조합해서 만들고 있습니다. 이런 변화는 사용성과 반응형 향상에는 극적으로 도움을 주지만, 또 다른 많은 유저들은 접근성 격차로 인해 제약이 발생하는 리스크도 안고 있습니다. JavaScript는 스크린리더 같은 보조기술을 사용하는 유저들이 접근하기 힘들다고 알려져 있었습니다. 하지만 현재는 다양한 사용자가 접근할 수 있는 동적 웹 어플리케이션을 만들 수 있습니다.

+ +

문제

+ +

대부분의 자바스크립트 개발도구는 데스크톱 인터페이스의 동작을 유사하게 만들 수 있도록 클라이언트-사이드 위젯 라이브러리를 제공하고 있습니다. Slider, Menu bar, Filelist View 등을 JavaScript, CSS, HTML을 이용해서 만들 수  있습니다. HTML4 명세가 나왔을 때는 HTML 태그에서 이런 위젯들의 설명이 제공되지 않았으며, 개발자들은 보통 <div>나 <span>같은 것들을 활용하여 개발하였습니다. 이런 시대의 결과로 데스크톱 위젯들은 충분한 정보를 제공하지 못하였으며 이는 기술적으로 전혀 도움이 되지 않았습니다. 동적 콘텐츠는 이유가 어떻든 스크린을 보지 못하는 사람에게 문제가 되었습니다. 주식 시세 표시 위젯, 트위터 라이브 피드 갱신, 프로그레스바 같은 것들을 보조공학기술(AT)로 인식하지 못하는 경우가 많았습니다. ARIA가 필요한 이유가 여기에 있습니다. 

+ +

Example 1: 탭 위젯을 ARIA 레이블링 없이 만든 마크업. 마크업에서 위젯의 폼과 동작에 대해 설명하고 있지 않습니다.

+ +
<!-- 탭 위젯을 위한 코드입니다. 어떻습니까? 마크업만 보고서 가늠이 되나요? -->
+<ol>
+  <li id="ch1Tab">
+    <a href="#ch1Panel">Chapter 1</a>
+  </li>
+  <li id="ch2Tab">
+    <a href="#ch2Panel">Chapter 2</a>
+  </li>
+  <li id="quizTab">
+    <a href="#quizPanel">Quiz</a>
+  </li>
+</ol>
+
+<div>
+  <div id="ch1Panel">Chapter 1 content goes here</div>
+  <div id="ch2Panel">Chapter 2 content goes here</div>
+  <div id="quizPanel">Quiz content goes here</div>
+</div>
+ +

Example 2: 탭 위젯의 렌더링 화면. 유저는 비주얼로 확인 가능하지만, 보조기술과 같은 기계들은 읽지 못합니다.
+ Screenshot of the tabs widget

+ +

ARIA

+ +

Accessible Rich Internet Applications(WAI-ARIA)는 W3C의 Web Accessibility Initiative에서 제작하고, 스크린리더 같은 보조기기에서 필요한 정보들을 추가하는 방법을 제공합니다. ARIA는 마크업에서 특별한 속성을 추가하여 개발자들이 위젯의 디테일한 정보를 제공할 때 사용합니다. 동적 웹 어플리케이션에서 찾을 수 있는 데스크톱 스타일 콘트롤과 표준 HTML 태그 사이에 있는 차이를 채우기 위해, ARIA는 친숙한 UI 위젯의 동작 상태(state)와 역할(Role)에 대한 설명을 제공합니다.

+ +

ARIA는 다른 타입의 속성 세개 roles, states, properties를 분할하여 정의하고 있습니다. Roles는 slider, menu bar, dialog와 같은 HTML4에서 사용하지 못하는 위젯을 설명합니다. Properties는 드래그가 가능하다는 것이나, 요소가 필요하다는 것이나, 팝업이 뜨는 것과 같은 위젯의 특징에 대해 설명합니다. State는 요소의 현재 상태에 대해 설명합니다. 이 정보는 보조기기에서 요소의 접근이 불가하거나, 숨겨져 있는 상태라는 것을 명시합니다.

+ +

ARIA attributes are designed to be interpreted automatically by the browser and translated to the operating system's native accessibility APIs. When ARIA is present, assistive technologies are able to recognize and interact with custom JavaScript controls in the same way that they do with desktop equivalents. This has the potential for providing a much more consistent user experience than was possible in the previous generation of web applications, since assistive technology users can apply all of their knowledge of how desktop applications work when they are using web-based applications.

+ +

Example 3: Markup for the tabs widget with ARIA attributes added.

+ +
<!-- Now *these* are Tabs! -->
+<!-- We've added role attributes to describe the tab list and each tab. -->
+<ol role="tablist">
+  <li id="ch1Tab" role="tab">
+    <a href="#ch1Panel">Chapter 1</a>
+  </li>
+  <li id="ch2Tab" role="tab">
+    <a href="#ch2Panel">Chapter 2</a>
+  </li>
+  <li id="quizTab" role="tab">
+    <a href="#quizPanel">Quiz</a>
+  </li>
+</ol>
+
+<div>
+  <!-- Notice the role and aria-labelledby attributes we've added to describe these panels. -->
+  <div id="ch1Panel" role=”tabpanel” aria-labelledby="ch1Tab">Chapter 1 content goes here</div>
+  <div id="ch2Panel" role=”tabpanel” aria-labelledby="ch2Tab">Chapter 2 content goes here</div>
+  <div id="quizPanel" role=”tabpanel” aria-labelledby="quizTab">Quiz content goes here</div>
+</div>
+
+ +

ARIA는 Firefox, Safari, Opera, Chrome 및 Internet Explorer를 포함한 모든 주요 브라우저의 최신 버전에서 지원됩니다. 오픈 소스 NVDA(NonVisual Desktop Access) 및 Orca 스크린 리더와 같은 많은 보조 기술도 ARIA를 지원합니다. 점차적으로 jQuery UI, YUI, Google Closure, Dojo Dijit과 같은 JavaScript 위젯 라이브러리에 ARIA 마크 업도 포함됩니다.

+ +

Presentational changes

+ +

Dynamic presentational changes include using CSS to change the appearance of content (such as a red border around invalid data, or changing the background colour of a checked checkbox), as well as showing or hiding content.

+ +

State changes

+ +

ARIA provides attributes for declaring the current state of a UI widget. Examples include (but are certainly not limited to):

+ + + +

(For a full list of ARIA states, consult the ARIA list of states and properties.)

+ +

Developers should use ARIA states to indicate the state of UI widget elements and use CSS attribute selectors to alter the visual appearance based on the state changes (rather than using script to change a class name on the element).

+ +

The Open Ajax Alliance website provides an example of CSS attribute selectors based on ARIA states. The example shows a WYSIWYG editor interface with a dynamic menu system. Items currently selected in a menu, such as the font face, are visually distinguished from other items. The relevant parts of the example are explained below.

+ +

In this example, the HTML for a menu has the form shown in Example 1a. Note how, on lines 7 and 13, the aria-checked property is used to declare the selection state of the menu items.

+ +

Example 1a. HTML for a selectable menu (adapted from http://www.oaa-accessibility.org/example/25/).

+ +
<ul id="fontMenu" class="menu" role="menu" aria-hidden="true">
+  <li id="sans-serif"
+      class="menu-item"
+      role="menuitemradio"
+      tabindex="-1"
+      aria-controls="st1"
+      aria-checked="true">Sans-serif</li>
+  <li id="serif"
+      class="menu-item"
+      role="menuitemradio"
+      tabindex="-1"
+      aria-controls="st1"
+      aria-checked="false">Serif</li>
+  ...
+
+ +

The CSS that is used to alter the visual appearance of the selected item is shown in Example 1b. Note that there is no custom classname used, only the status of the aria-checked attribute on line 1.

+ +

Example 1b. Attribute-based selector for indicating state (from http://www.oaa-accessibility.org/example/25/).

+ +
li[aria-checked="true"] {
+  font-weight: bold;
+  background-image: url('images/dot.png');
+  background-repeat: no-repeat;
+  background-position: 5px 10px;
+}
+
+ +

The JavaScript to update the aria-checked property has the form shown in Example 1c. Note that the script only updates the aria-checked attribute (lines 3 and 8); it does not need to also add or remove a custom classname.

+ +

Example 1c. JavaScript to update the aria-checked attribute (based on http://www.oaa-accessibility.org/example/25/).

+ +
var processMenuChoice = function(item) {
+  // 'check' the selected item
+  item.setAttribute('aria-checked', 'true');
+  // 'un-check' the other menu items
+  var sib = item.parentNode.firstChild;
+  for (; sib; sib = sib.nextSibling ) {
+    if ( sib.nodeType === 1 && sib !== item ) {
+      sib.setAttribute('aria-checked', 'false');
+    }
+  }
+};
+
+ +

Visibility changes

+ +

When content visibility is changed (i.e. an element is hidden or shown), developers should change the aria-hidden property value. The techniques described above should be used to declare CSS to visually hide an element using display:none.

+ +

The Open Ajax Alliance website provides an example of a tooltip that uses aria-hidden to control the visibility of the tooltip. The example shows a simple web form with tooltips containing instructions associated with the entry fields. The relevant parts of the example are explained below.

+ +

In this example, the HTML for the tooltip has the form shown in Example 2a. Line 9 sets the aria-hidden state to true.

+ +

Example 2a. HTML for a tooltip (adapted from http://www.oaa-accessibility.org/example/39/).

+ +
<div class="text">
+    <label id="tp1-label" for="first">First Name:</label>
+    <input type="text" id="first" name="first" size="20"
+           aria-labelledby="tp1-label"
+           aria-describedby="tp1"
+           aria-required="false" />
+    <div id="tp1" class="tooltip"
+         role="tooltip"
+         aria-hidden="true">Your first name is a optional</div>
+</div>
+
+ +

The CSS for this markup is shown in Example 2b. Note that there is no custom classname used, only the status of the aria-hidden attribute on line 1.

+ +

Example 2b. Attribute-based selector for indicating state (from http://www.oaa-accessibility.org/example/39/).

+ +
div.tooltip[aria-hidden="true"] {
+  display: none;
+}
+
+ +

The JavaScript to update the aria-hidden property has the form shown in Example 2c. Note that the script only updates the aria-hidden attribute (line 2); it does not need to also add or remove a custom classname.

+ +

Example 2c. JavaScript to update the aria-checked attribute (based on http://www.oaa-accessibility.org/example/39/).

+ +
var showTip = function(el) {
+  el.setAttribute('aria-hidden', 'false');
+}
+ +

Role changes

+ +
Under construction
+ +

ARIA allows developers to declare a semantic role for an element that otherwise offers incorrect or no semantics. For example, when an unordered list is used to create a menu, the {{ HTMLElement("ul") }} should be given a role of menubar and each {{ HTMLElement("li") }} should be given a role of menuitem.

+ +

The role of an element should not change. Instead, remove the original element and replace it with an element with the new role.

+ +

For example, consider an "inline edit" widget: a component that allows users to edit a piece of text in place, without switching contexts. This component has a "view" mode, in which the text is not editable, but is activatable, and an "edit" mode, in which the text can be edited. A developer might be tempted to implement the "view" mode using a read-only text  {{ HTMLElement("input") }} element and setting its ARIA role to button, then switching to "edit" mode by making the element writable and removing the role attribute in "edit" mode (since {{ HTMLElement("input") }} elements have their own role semantics).

+ +

Do not do this. Instead, implement the "view" mode using a different element altogether, such as a {{ HTMLElement("div") }} or {{ HTMLElement("span") }} with a role of button, and the "edit" mode using a text  {{ HTMLElement("input") }} element.

+ +

Asynchronous content changes

+ +
Under construction. See also Live Regions
+ +

Keyboard navigation

+ +

Often times developers overlook support for the keyboard when they create custom widgets. To be accessible to a variety of users, all features of a web application or widget should also be controllable with the keyboard, without requiring a mouse. In practice, this usually involves following the conventions supported by similar widgets on the desktop, taking full advantage of the Tab, Enter, Spacebar, and arrow keys.

+ +

Traditionally, keyboard navigation on the web has been limited to the Tab key. A user presses Tab to focus each link, button, or form on the page in a linear order, using Shift-Tab to navigate backwards. It's a one-dimensional form of navigation—forward and back, one element at a time. On fairly dense pages, a keyboard-only user often has to press the Tab key dozens of times before they can access the section they need. Implementing desktop-style keyboard conventions on the web has the potential to significantly speed up navigation for many users.

+ +

Here's a summary of how keyboard navigation should work in an ARIA-enabled web application:

+ + + +

So, for the Tabs widget example above, the user should be able to navigate into and out of the widget's container (the <ol> in our markup) using the Tab and Shift-Tab keys. Once keyboard focus is inside the container, the arrow keys should allow the user to navigate between each tab (the <li> elements). From here, conventions vary from platform to platform. On Windows, the next tab should automatically be activated when the user presses the arrow keys. On Mac OS X, the user can press either Enter or the Spacebar to activate the next tab. An in-depth tutorial for creating Keyboard-navigable JavaScript widgets describes how to implement this behavior with JavaScript.

+ +

For more detail about desktop-style keyboard navigation conventions, a comprehensive DHTML style guide is available. It provides an overview of how keyboard navigation should work for each type of widget supported by ARIA. The W3C also offers a helpful ARIA Best Practices document that includes keyboard navigation and shortcut conventions for a variety of widgets. 

+ +

See also

+ + diff --git a/files/ko/web/accessibility/aria/aria_live_regions/index.html b/files/ko/web/accessibility/aria/aria_live_regions/index.html new file mode 100644 index 0000000000..c609e9698f --- /dev/null +++ b/files/ko/web/accessibility/aria/aria_live_regions/index.html @@ -0,0 +1,255 @@ +--- +title: ARIA live regions +slug: Web/Accessibility/ARIA/ARIA_Live_Regions +translation_of: Web/Accessibility/ARIA/ARIA_Live_Regions +--- +

JavaScript를 이용하면, 전체 페이지를 다시 로드할 필요 없이 페이지의 일부를 동적으로 변경하는 것이 가능합니다. 예를 들면, 검색 결과 리스트를 즉시 업데이트 하거나, 사용자 상호 작용이 필요 없는 경고 또는 알림을 표시합니다. 이러한 변경사항들은 일반적으로 페이지를 볼 수 있는 사용자에게 시각적으로 분명하게 보이지만, 보조과학기술 사용자들에겐 분명하지 않을 수 있습니다. ARIA live regions은 이 간격을 메우고, 보조과학기술에 의해 발표될 수 있는 방식으로 동적 컨텐츠 변화들을 프로그래밍 방식으로 노출할 수 있는 방법을 제공합니다.

+ +
+

Note: 보조과학기술은 live region 컨텐츠에 동적인  변화를 발표할 것입니다.

+ +

Including an aria-live attribute or a specialized live region role (such as role="alert") on the element you want to announce changes to works as long as you add the attribute before the changes occur — either in the original markup, or dynamically using JavaScript.

+
+ +

간단한 live regions

+ +

페이지를 재로드 없이 업데이트 되는 동적 컨텐츠는 일반적으로 영역 또는 위젯입니다. 대화형 컨텐츠가 아닌 단순 컨텐츠 변경은 live regions 으로 표시해야만 합니다. 아래는 관련 ARIA live region 속성에 관한 리스트와 설명입니다.

+ +
    +
  1. aria-live: aria-live=POLITENESS_SETTING는 스크린 리더가 live regions에 대한 업데이트를 처리할때 우선 순위를 설정하는 데 사용되며, 가능한 세팅으로 off, polite, assertive가 있습니다. 기본 설정은 off입니다. 이 속성은 단연코 가장 중요합니다.
    2. +
  2. +

    aria-controls: The aria-controls=[IDLIST] is used to associate a control with the regions that it controls. Regions are identified just like an id in a div, and multiple regions can be associated with a control using a space, e.g. aria-controls="myRegionID1 myRegionsID2".

    + +
    Not known if the aria-controls aspect of live regions is implemented in current ATs, or which. Needs research.
    +
    3. +
+ +

Normally, only aria-live="polite" is used. Any region which receives updates that are important for the user to receive, but not so rapid as to be annoying, should receive this attribute. The screen reader will speak changes whenever the user is idle.

+ +

For regions which are not important, or would be annoying because of rapid updates or other reasons, silence them with aria-live="off".

+ + + +

A website specializing in providing information about planets provides a dropdown box. When a planet is selected from the dropdown, a region on the page is updated with information about the selected planet.

+ +

HTML

+ +
<fieldset>
+  <legend>Planet information</legend>
+  <label for="planetsSelect">Planet:</label>
+  <select id="planetsSelect" aria-controls="planetInfo">
+    <option value="">Select a planet&hellip;</option>
+    <option value="mercury">Mercury</option>
+    <option value="venus">Venus</option>
+    <option value="earth">Earth</option>
+    <option value="mars">Mars</option>
+  </select>
+  <button id="renderPlanetInfoButton">Go</button>
+</fieldset>
+
+<div role="region" id="planetInfo" aria-live="polite">
+  <h2 id="planetTitle">No planet selected</h2>
+  <p id="planetDescription">Select a planet to view its description</p>
+</div>
+
+<p><small>Information courtesy <a href="https://en.wikipedia.org/wiki/Solar_System#Inner_Solar_System">Wikipedia</a></small></p>
+
+ +

JavaScript

+ +
const PLANETS_INFO = {
+  mercury: {
+    title: 'Mercury',
+    description: 'Mercury is the smallest and innermost planet in the Solar System. It is named after the Roman deity Mercury, the messenger to the gods.'
+  },
+
+  venus: {
+    title: "Venus",
+    description: 'Venus is the second planet from the Sun. It is named after the Roman goddess of love and beauty.'
+  },
+
+  earth: {
+    title: "Earth",
+    description: 'Earth is the third planet from the Sun and the only object in the Universe known to harbor life.'
+  },
+
+  mars: {
+    title: "Mars",
+    description: 'Mars is the fourth planet from the Sun and the second-smallest planet in the Solar System after Mercury. In English, Mars carries a name of the Roman god of war, and is often referred to as the "Red Planet".'
+  }
+};
+
+function renderPlanetInfo(planet) {
+  const planetTitle = document.querySelector('#planetTitle');
+  const planetDescription = document.querySelector('#planetDescription');
+
+  if (planet in PLANETS_INFO) {
+    planetTitle.textContent = PLANETS_INFO[planet].title;
+    planetDescription.textContent = PLANETS_INFO[planet].description;
+  } else {
+    planetTitle.textContent = 'No planet selected';
+    planetDescription.textContent = 'Select a planet to view its description';
+  }
+}
+
+const renderPlanetInfoButton = document.querySelector('#renderPlanetInfoButton');
+
+renderPlanetInfoButton.addEventListener('click', event => {
+  const planetsSelect = document.querySelector('#planetsSelect');
+  const selectedPlanet = planetsSelect.options[planetsSelect.selectedIndex].value;
+
+  renderPlanetInfo(selectedPlanet);
+});
+
+ +

{{EmbedLiveSample('Dropdown_box_updates_useful_onscreen_information', '', 350)}}

+ +

As the user selects a new planet, the information in the live region will be announced. Because the live region has aria-live="polite", the screen reader will wait until the user pauses before announcing the update. Thus, moving down in the list and selecting another planet will not announce updates in the live region. Updates in the live region will only be announced for the planet finally chosen.

+ +

Here is a screenshot of VoiceOver on Mac announcing the update (via subtitles) to the live region:

+ +

A screenshot of VoiceOver on Mac announcing the update to a live region. Subtitles are shown in the picture.

+ +

Preferring specialized live region roles

+ +

In the following well-known predefined cases it is better to use a specific provided "live region role":

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RoleDescriptionCompatibility Notes
logChat, error, game or other type of logTo maximize compatibility, add a redundant aria-live="polite" when using this role.
statusA status bar or area of the screen that provides an updated status of some kind. Screen reader users have a special command to read the current status.To maximize compatibility, add a redundant aria-live="polite" when using this role.
alertError or warning message that flashes on the screen. Alerts are particularly important for client side validation notices to users. (TBD: link to ARIA form tutorial with aria info)To maximize compatibility, some people recommend adding a redundant aria-live="assertive" when using this role. However, adding both aria-live and role="alert" causes double speaking issues in VoiceOver on iOS.
progressbarA hybrid between a widget and a live region. Use this with aria-valuemin, aria-valuenow and aria-valuemax. (TBD: add more info here).
marqueefor text which scrolls, such as a stock ticker.
timeror any kind of timer or clock, such as a countdown timer or stopwatch readout.
+ +

Advanced live regions

+ +

(TBD: more granular information on the support of the individual attributes with combinations of OS/Browser/AT).

+ +

General support for Live Regions was added to JAWS on version 10.0. In Windows Eyes supports Live Regions since version 8.0 "for use outside of Browse Mode for Microsoft Internet Explorer and Mozilla Firefox". NVDA added some basic support for Live Regions for Mozilla Firefox back in 2008 and was improved in 2010 and 2014. In 2015, basic support was also added for Internet Explorer (MSHTML).

+ +

The Paciello Group has some information about the state of the support of Live Regions (2014). Paul J. Adam has researched the support of Aria-Atomic and Aria-Relevant in particular. 

+ +
    +
  1. aria-atomic: The aria-atomic=BOOLEAN is used to set whether or not the screen reader should always present the live region as a whole, even if only part of the region changes. The possible settings are: false or true. The default setting is false.
    2. +
  2. aria-relevant: The aria-relevant=[LIST_OF_CHANGES] is used to set what types of changes are relevant to a live region. The possible settings are one or more of: additions, removals, text, all. The default setting is: additions text.
    3. +
  3. aria-labelledby: The aria-labelledby=[IDLIST] is used to associate a region with its labels, similar to aria-controls but instead associating labels to the region. and label identifiers are separated with a space.
    4. +
  4. aria-describedby: The aria-describedby=[IDLIST] is used to associate a region with its descriptions, similar to aria-controls but instead associating descriptions to the region and description identifiers are separated with a space.
    5. +
+ +

Advanced use case: Clock

+ +

As an illustration of aria-atomic, consider a site with a simple clock, showing hours and minutes. The clock is updated each minute, with the new remaining time simply overwriting the current content.

+ +
<div id="clock" role="timer" aria-live="polite"></div>
+
+ +
/* basic JavaScript to update the clock */
+
+setInterval(function() {
+  var now = new Date();
+  document.getElementById('clock').innerHTML = "Time: " + now.getHours() + ":" + ("0"+now.getMinutes()).substr(-2);
+}, 60000);
+
+ +

The first time the function executes, the entirety of the string that is added will be announced. On subsequent calls, only the parts of the content that changed compared to the previous content will be announced. For instance, when the clock changes from "17:33" to "17:34", assistive technologies will only announce "4", which won't be very useful to users.

+ +

One way around this would be to first clear the contents of the live region, and then inject the new content. However, this can sometimes be unreliable, as it's dependent on the exact timing of these two updates.

+ +

aria-atomic="true" ensures that each time the live region is updated, the entirety of the content is announced in full (e.g. "Time: 17:34").

+ +
<div id="clock" role="timer" aria-live="polite" aria-atomic="true"></div>
+
+ +
+

Note: As observed, setting/updating the innerHTML again would cause the whole text to be read again, whether or not you set aria-atomic="true", so the above Clock example does not work as expected.

+
+ +

A working example of a simple year control for better understanding:

+ +
<div id="date-input">
+  <label>Year:
+    <input type="text" id="year" value="1990" onblur="change(event)"/>
+  </label>
+</div>
+
+<div id="date-output" aria-live="polite">
+  The set year is:
+  <span id="year-output">1990</span>
+</div>
+ +

+ +
function change(event) {
+  var yearOut = document.getElementById("year-output");
+  switch (event.target.id) {
+    case "year":
+      yearOut.innerHTML = event.target.value;
+      break;
+   default:
+      return;
+  }
+};
+ +

+ +

Without aria-atomic="true" the screenreader announces only the changed value of year.

+ +

With aria-atomic="true", the screenreader announces "The set year is: changedvalue"

+ +

Advanced use case: Roster

+ +

A chat site would like to display a list of users currently logged in. Display a list of users where a user's log-in and log-out status will be reflected dynamically (without a page reload).

+ +
<ul id="roster" aria-live="polite" aria-relevant="additions removals">
+	<!-- use JavaScript to add remove users here-->
+</ul>
+
+ +

Breakdown of ARIA live properties:

+ + + +

See also

+ + diff --git a/files/ko/web/accessibility/aria/aria_techniques/index.html b/files/ko/web/accessibility/aria/aria_techniques/index.html new file mode 100644 index 0000000000..c628a228e1 --- /dev/null +++ b/files/ko/web/accessibility/aria/aria_techniques/index.html @@ -0,0 +1,213 @@ +--- +title: 'ARIA 사용하기: 규칙, 상태, 속성' +slug: Web/Accessibility/ARIA/ARIA_Techniques +tags: + - ARIA + - Accessibility + - Overview + - Reference +translation_of: Web/Accessibility/ARIA/ARIA_Techniques +--- +

ARIA defines semantics that can be applied to elements, with these divided into roles (defining a type of user interface element) and states and properties that are supported by a role. Authors must assign an ARIA role and the appropriate states and properties to an element during its life-cycle, unless the element already has appropriate ARIA semantics (via use of an appropriate HTML element). Addition of ARIA semantics only exposes extra information to a browser's accessibility API, and does not affect a page's DOM.

+ +

Roles

+ +

Widget roles

+ +
+ +
+ +

Composite roles

+ +

The techniques below describe each composite role as well as their required and optional child roles.

+ +
+ +
+ +

Document structure roles

+ +
+ +
+ +

Landmark roles

+ +
+ +
+ +

Live Region Roles

+ +
+ +
+ +

Window Roles

+ +
+ +
+ +

States and properties

+ +

Widget attributes

+ +
+ +
+ +

Live region attributes

+ +
+ +
+ +

Drag & drop attributes

+ +
+ +
+ +

Relationship attributes

+ +
+ +
+ +

MicrosoftEdge-specific properties

+ +
+ +
diff --git a/files/ko/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.html b/files/ko/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.html new file mode 100644 index 0000000000..d667416f9d --- /dev/null +++ b/files/ko/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.html @@ -0,0 +1,66 @@ +--- +title: aria-label 속성 사용 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute +tags: + - ARIA + - Accessibility + - aria-label +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute +--- +

aria-label 속성은 현재 요소에 레이블을 정의하기 위해서 사용합니다. 텍스트 레이블이 화면에 표시되지 않을 때에 사용하세요. 만약에 요소에 레이블을 정의하는 화면에 보이는 텍스트가 있다면  aria-labelledby을 대신 사용하세요

+ +

이 속성은 일반적인 HTML 요소와 함께 사용할 수 있습니다. ARIA role 이 적용된 요소에만 한정되지 않습니다.

+ +

값

+ +

문자열

+ +

사용자 에이전트와 보조도구에 대한 영향

+ +
+

Edit section

+
+ +
참고: 보조기기가 이 기술을 처리하는 방법에 대한 의견에는 차이가 있을 수 있습니다. 위에서 제공하는 정보는 그러한 의견 중 하나일 뿐 규범이 아닙니다. 
+ +

예

+ +
+

예 1: 다수의 레이블

+ +

아래의 예제에서 버튼은 X가 가운데있는 전형적인 "닫기" 버튼처럼 스타일됩니다. 버튼의 목적이 대화상자를 닫는 것임을 암시하는 것이 없으므로 보조기기에 레이블을 제공하기 위해 aria-label 를 사용합니다.

+
+ +
<button aria-label="Close" onclick="myDialog.close()">X</button>
+
+ +

동작하는 예:

+ +

 

+ +

주의

+ + + +

Used by ARIA roles

+ +

베이스 마크업의 모든 요소

+ +

관련된 ARIA 기술

+ + + +

적합성

+ +

TBD: 일반적인 UA와 AT 제품 조합을 위한 서포트 정보를 추가합니다.

+ +

추가 리소스

+ + diff --git a/files/ko/web/accessibility/aria/forms/alerts/index.html b/files/ko/web/accessibility/aria/forms/alerts/index.html new file mode 100644 index 0000000000..072f9443b7 --- /dev/null +++ b/files/ko/web/accessibility/aria/forms/alerts/index.html @@ -0,0 +1,146 @@ +--- +title: Alerts +slug: Web/Accessibility/ARIA/forms/alerts +tags: + - ARIA + - Forms + - Web + - 접근성 +translation_of: Web/Accessibility/ARIA/forms/alerts +--- +

문제점

+ +

엑세스 가능한 오류 검사를 포함하고 싶은 폼, 예를 들어 콘택트 폼이 있습니다. 자주 있는 문제점으로는 Email이 유효하지 않거나, 이름 필드에 성이나 이름이 포함되지 않은 것이 있습니다.

+ +

폼

+ +

우선 aria-required 기술을 읽지 않았다면 먼저 읽어주세요. 여기서는 그것의 확장된 내용을 다룹니다. 

+ +

여기에 샘플 폼이 있습니다:

+ +
 <form method="post" action="post.php">
+   <fieldset>
+     <legend>Please enter your contact details</legend>
+     <label for="name">Your name (required):</label>
+     <input name="name" id="name" aria-required="true"/>
+     <br />
+     <label for="email">E-Mail address (required):</label>
+     <input name="email" id="email" aria-required="true"/>
+     <br />
+     <label for="website">Website (optional):</label>
+     <input name="website" id="website"/>
+   </fieldset>
+   <label for="message">Please enter your message (required):</label>
+   <br />
+   <textarea name="message" id="message" rows="5" cols="80"
+             aria-required="true"></textarea>
+   <br />
+   <input type="submit" name="submit" value="Send message"/>
+   <input type="reset" name="reset" value="Reset form"/>
+ </form>
+
+ +

유효성 검사 및 사용자에게 알림

+ +

폼 유효성 검사는 여러 단계로 구성됩니다. :

+ +
    +
  1. Email 또는 입력한 이름이 유효한지 확인하십시오. 각 필드는 유효성 검사를 통과하기 위해 충족되어야 하는 일련의 기준이 있습니다. 이 예제를 단순화하기 위해, Email에 '@' 마크가 있는지 이름에는 적어도 하나의 문자가 포함되어 있는지를 확인할 것입니다. 
    2. +
  2. 만약 위의 기준이 충족되지 않으면, 필드의  aria-invalid 속성에 “true” 값이 주어질 것입니다.
    3. +
  3. 기준이 충족되지 않으면 경고를 통해 사용자에게 알립니다. JavaScript의 ‘alert’ function을 사용하는 대신 아림을 위해 간단한 WAI-ARIA 위젯을 사용할 것입니다. 이것은 사용자에게 에러를 알려주지만, Javascript의 기본 ‘alert’ function의 “onblur”로 인해 발생하는 포커스 손실 없이 계속해서 폼을 수정할 수 있게 해줍니다. 
    4. +
+ +

아래의 예제는  “head” 의 닫는 태그를 삽입하는 Javascript 코드입니다.:

+ +
 <script type="application/javascript">
+ function removeOldAlert()
+ {
+   var oldAlert = document.getElementById("alert");
+   if (oldAlert){
+     document.body.removeChild(oldAlert);
+   }
+ }
+
+ function addAlert(aMsg)
+ {
+   removeOldAlert();
+   var newAlert = document.createElement("div");
+   newAlert.setAttribute("role", "alert");
+   newAlert.setAttribute("id", "alert");
+   var msg = document.createTextNode(aMsg);
+   newAlert.appendChild(msg);
+   document.body.appendChild(newAlert);
+ }
+
+ function checkValidity(aID, aSearchTerm, aMsg)
+ {
+   var elem = document.getElementById(aID);
+   var invalid = (elem.value.indexOf(aSearchTerm) < 0);
+   if (invalid) {
+     elem.setAttribute("aria-invalid", "true");
+     addAlert(aMsg);
+   } else {
+     elem.setAttribute("aria-invalid", "false");
+     removeOldAlert();
+   }
+ }
+ </script>
+
+ +

checkValidity 함수

+ +

Javascript에서 폼 유효성 검사에 사용되는 기본 메소드는 checkValidity 함수입니다. 이 메소드는 세 개의 파라미터를 가집니다: 유효성 검사를 할 input의 ID, 유효성을 확인하기 위해 검색할 검색어, alert에 삽입할 에러 메시지입니다.

+ +

유효성을 확인하기 위해, 이 함수는 input의 값 indexOf가 -1보다 큰지 확인합니다. 검색어를 찾을 수 없을 때 -1 혹은 그보다 작은 값을 반환합니다. 

+ +

만약에 값이 유효하지 않다면 이 함수는 2가지 작업을 수행합니다. 

+ +
    +
  1. 요소의 aria-invalid 속성을 “true”로 설정합니다. 이 속성은 사용자에게 여기에 유효하지 않은 값이 있다는 것을 알립니다. 
    2. +
  2. addAlert 함수를 호출하여 제공된 에러 메시지와 함께 alert을 추가합니다. 
    3. +
+ +

검색어가 발견되면 aria-invalid 속성은 “false”로 재설정됩니다. 또한 남아있는 모든 alert가 제거됩니다. 

+ +

addAlert 함수

+ +

이 함수는 일단 오래된 alert을 제거합니다. 이 함수는 간단합니다. : id가 “alert”인 요소를 찾고, 발견되면 document object model.에서 해당 요소를 제거합니다. 

+ +

다음으로 함수는 alert 테스트를 저장할 div 요소를 만듭니다. 그 div요소는 “alert”이라는 ID를 갖습니다. 그리고  “alert”이라는 role을 갖습니다. 이름에 "aria"가 없지만 사실은 ARIA에서 만들어진 것입니다. role이 간소화를 위해 단순히 HTML로 이식된 XHTML Role Attribute Module에 기반하기 때문입니다.

+ +

텍스트가 div 요소에 추가되고 div 요소는 문서에 추가됩니다. 

+ +

이 div  요소가 나타나면 Firefox는 보조기기에 "alert" 이벤트를 발생시킵니다. 대부분의 스크린 리더는 자동으로 그것을 주워서 읽습니다. 이건 암호 저장 여부를 묻는 Firefox의 알림 표시 줄과 비슷합니다. 방금 만든 alert에는 버튼이 없으므로 단순히 무엇이 문제인지만을 알려줍니다. 

+ +

“onblur” 이벤트 수정하기

+ +

이제 남은 것은 이벤트 핸들러를 추가하는 것뿐입니다. 우리는 Email과 이름에 대한 두개의 인풋을 다음과 같이 변경해야합니다. :

+ +
 <input name="name" id="name" aria-required="true"
+        onblur="checkValidity('name', ' ', 'Invalid name entered!');"/>
+ <br />
+ <input name="email" id="email" aria-required="true"
+        onblur="checkValidity('email', '@', 'Invalid e-mail address');"/>
+
+ +

예제 테스트하기

+ +

만약 Firefox 3 와 현재 지원되는 스크린 리더를 사용하고 있다면 다음을 시도해보세요.:

+ +
    +
  1. 이름에 성만을 입력해보세요. 탭을 하면 유효하지 않은 이름을 입력했다는 알림을 들을 수 있을 겁니다. shift-tab을 눌러서 돌아간 다음 에러를 수정할 수 있습니다. 
    2. +
  2. "@"없이 Email 주소를 입력해보세요. 탭을 해서 필드를 벗어나면 유효하지 않은 Email을 입력했다는 알림을 들을 수 있을 겁니다. 
    3. +
+ +

두 경우 모두 필드로 포커스가 돌아가면 스크린 리더는 해당 필드가 유효하지 않음을 알려주어야 합니다. JAWS 9는 이것을 지원하지만,  JAWS 8는 지원하지 않습니다. 그렇기때문에 이것은 스크린 리더 버전에 따라서 동작하지 않을 수 있습니다. 

+ +

자주 하는 질문

+ +
+
Q. 왜 label에 “(required)” 를 넣고 일부 input에 aria-required 속성을 넣었나요?
+
A. 만약 이게 실제 폼이고 아직 ARIA를 지원하지 않는 브라우저에서 사이트를 방문한 경우에도 이것이 필수 입력란임을 알려주는 것이 좋습니다. 
+
Q. 왜 유효하지 않은 필드로 자동 포커스되도록 하지 않나요?
+
A. 왜냐하면 Windows API 사양 및 기타 사양에 따라 허용되지 않기 때문입니다. 또한, 사용자 상호작용 없이 포커스를 자주 이동하는 것은  좋지 않습니다. 
+
+ +
TBD: 이건 다시 생각해봅시다. 개인적으로 키보드 트랩을 발생시키지 않는다면 포커스를 설정하는 것이 좋을 것 같습니다.
diff --git a/files/ko/web/accessibility/aria/forms/basic_form_hints/index.html b/files/ko/web/accessibility/aria/forms/basic_form_hints/index.html new file mode 100644 index 0000000000..f3757219ab --- /dev/null +++ b/files/ko/web/accessibility/aria/forms/basic_form_hints/index.html @@ -0,0 +1,116 @@ +--- +title: 기본적인 폼 힌트 +slug: Web/Accessibility/ARIA/forms/Basic_form_hints +tags: + - ARIA + - Forms + - 접근성 +translation_of: Web/Accessibility/ARIA/forms/Basic_form_hints +--- +

전통적인 HTML 폼 관련 요소를 사용하여 폼을 구현할 때 컨트롤에 레이블을 지정하고 레이블을 컨트롤과 명시적으로 연결하는 것이 중요합니다. 스크린 리더 사용자가 페이지를 탐색할 때, 스크린 리더는 폼 컨트롤을 알려주지만, 레이블과 폼이 직접적으로 연결되지 않으면 스크린 리더는 어떤 레이블이 적절한지 알 방법이 없습니다. 

+ +

아래의 예는 레이블이 있는 간단한 폼을 보여줍니다. 각{{ HTMLElement("input") }} 요소는 id를 가지고 있고, 각{{ HTMLElement("label") }} 요소는 자신과 연결된 {{ HTMLElement("input") }}의 id를 나타내는  for 속성을 가지고 있습니다.

+ +
<form>
+  <ul>
+    <li>
+      <input id="wine-1" type="checkbox" value="riesling"/>
+      <label for="wine-1">Berg Rottland Riesling</label>
+    </li>
+    <li>
+      <input id="wine-2" type="checkbox" value="pinot-blanc"/>
+      <label for="wine-2">Pinot Blanc</label>
+    </li>
+    <li>
+      <input id="wine-3" type="checkbox" value="pinot-grigio"/>
+      <label for="wine-3">Pinot Grigio</label>
+    </li>
+    <li>
+      <input id="wine-4" type="checkbox" value="gewurztraminer"/>
+      <label for="wine-4">Gewürztraminer</label>
+    </li>
+  </ul>
+</form>
+
+ +

ARIA로 라벨링 하기

+ +

HTML {{ HTMLElement("label") }} 요소는 폼 관련 요소로 적당하지만, 많은 폼 컨트롤은 {{ HTMLElement("div") }}나 {{ HTMLElement("span") }}를 사용한 동적인 Javascript 위젯으로 구현되어있습니다. W3C의 Web Accessibility Initiative에서 만들어진 WAI-ARIA, Accessible Rich Internet Applications 사양은 이러한 경우를 위해 aria-labelledby 속성을 제공하고 있습니다.

+ +

아래의 예에서는 순서 없는 리스트를 사용하여 구현한 라디오 버튼 그룹을 보여주고 있습니다. 3행의  {{ HTMLElement("ul") }} 요소에 aria-labelledby 속성에 라디오 그룹의 레이블인 {{ HTMLElement("h3") }} 요소의  id  rg1_label을 설정했습니다. 

+ +
<h3 id="rg1_label">Lunch Options</h3>
+
+<ul class="radiogroup" id="rg1"  role="radiogroup" aria-labelledby="rg1_label">
+  <li id="r1"  tabindex="-1" role="radio" aria-checked="false">
+    <img role="presentation" src="radio-unchecked.gif" /> Thai
+  </li>
+  <li id="r2"  tabindex="-1" role="radio"  aria-checked="false">
+    <img role="presentation" src="radio-unchecked.gif" /> Subway
+  </li>
+  <li id="r3"   tabindex="0" role="radio" aria-checked="true">
+    <img role="presentation" src="radio-checked.gif" /> Radio Maria
+  </li>
+</ul>
+
+ +

ARIA로 설명하기

+ +

폼 컨트롤을 가끔 label 외에 추가설명이 있는 경우가 있다. ARIA는 aria-describedby 속성을 사용하여 설명을 컨트롤과 직접 연관시킵니다. 

+ +

아래 예제는 {{ HTMLElement("div") }} 안의 문장이  {{ HTMLElement("button") }} 요소를 설명하는 것을 보여줍니다. {{ HTMLElement("button") }}의  aria-describedby 속성은 {{ HTMLElement("div") }}의 id를 참조합니다. 

+ +
<button aria-describedby="descriptionRevert">Revert</button>
+<div id="descriptionRevert">Reverting will undo any changes that have been made
+                            since the last save.</div>
+ +
+

Note: aria-describedby 속성은 폼 컨트롤 외에도 다른 용도로 사용됩니다. 

+
+ +

필수 필드와 유효하지 않은 필드 

+ +
+

Note: 현재는 전 세계 사용자의 97%가  required를 사용할 수 있으므로 required와 aria-required 모두를 사용하는 것은 더는 권장하지 않습니다.

+
+ +

일반적으로 웹 개발자는 필수 필드와 유효하지 않은 필드를 나타내기 위해서 시각적인 방법을 사용합니다. 보조 기술(ATs)은 언제나 표시된 것을 통해서 정보를 추측하지는 않습니다. ARIA 는 폼 컨트롤의 필수나 유효하지 않음을 나타내는 속성을 제공합니다. 

+ + + +

아래의 예제는 세 개의 필드가 있는 간단한 폼을 보여줍니다. 4행과 12행에서는 aria-required 속성이 true(레이블 옆에 별표와 함께)로 설정되어 name과 email 필드가 필수임을 나타냅니다. 두 번째 예제는 email 형식을 검증하고 그 결과에 따라서 email 필드(HTML 12행)의 (요소를 시각적으로 변경하는 것과 함께) aria-invalid 속성을 설정하는 Javascript 스니펫입니다. 

+ +
<form>
+  <div>
+    <label for="name">* Name:</label>
+    <input type="text" value="name" id="name" aria-required="true"/>
+  </div>
+  <div>
+    <label for="phone">Phone:</label>
+    <input type="text" value="phone" id="phone" aria-required="false"/>
+  </div>
+  <div>
+    <label for="email">* E-mail:</label>
+    <input type="text" value="email" id="email" aria-required="true"/>
+  </div>
+</form>
+ +

폼 항목의 유효성을 검사하는 스크립트는 다음과 같습니다. 

+ +
var validate = function () {
+  var emailElement = document.getElementById(emailFieldId);
+  var valid = emailValid(formData.email); // returns true if valid, false otherwise
+
+  emailElement.setAttribute("aria-invalid", !valid);
+  setElementBorderColour(emailElement, valid); // sets the border to red if second arg is false
+};
+
+ +

유용한 오류 메시지 제공

+ +

ARIA alerts to enhance forms 사용법을 읽으세요.

+ +

폼 접근성을위한 ARIA 사용에 대한 자세한 지침은 WAI-ARIA Authoring Practices 문서를 참조하세요. 

diff --git a/files/ko/web/accessibility/aria/forms/index.html b/files/ko/web/accessibility/aria/forms/index.html new file mode 100644 index 0000000000..a9028b2416 --- /dev/null +++ b/files/ko/web/accessibility/aria/forms/index.html @@ -0,0 +1,17 @@ +--- +title: Forms +slug: Web/Accessibility/ARIA/forms +tags: + - ARIA + - 접근성 +translation_of: Web/Accessibility/ARIA/forms +--- +

아래의 페이지에서는 Web Form의 접근성을 향상시키는 여러 가지 테크닉을 소개합니다. 

+ + + +

유사한 콘텐츠를 다루고 있는 Yahoo! article on form validation and ARIA 도 봐주세요.

diff --git a/files/ko/web/accessibility/aria/index.html b/files/ko/web/accessibility/aria/index.html new file mode 100644 index 0000000000..c1c77f78f4 --- /dev/null +++ b/files/ko/web/accessibility/aria/index.html @@ -0,0 +1,131 @@ +--- +title: ARIA +slug: Web/Accessibility/ARIA +tags: + - ARIA + - Accessibility + - HTML + - 웹 접근성 + - 접근성 +translation_of: Web/Accessibility/ARIA +--- +

접근가능한 리치 인터넷 어플리케이션(Accessible Rich Internet Applications, ARIA)은 장애를 가진 사용자가 웹 콘텐츠와 웹 어플리케이션(특히 JavaScript를 사용하여 개발한 경우)에 더 쉽게 접근할 수 있는 방법을 정의하는 여러 특성을 말합니다.

+ +

ARIA는 HTML을 보충해, 일반적으로 보조 기술이 알 수 없는 상호작용 및 흔히 쓰이는 어플리케이션 위젯에 필요한 정보를 제공합니다. 예를 들어 ARIA는 HTML4에서의 탐색 랜드마크, JavaScript 위젯, 폼 힌트 및 오류 메시지, 실시간 콘텐츠 업데이트 등을 접근 가능한 형태로 제공합니다.

+ +
+

여기 등장하는 많은 위젯은 나중에 HTML5로 통합됐으므로, 구현하려는 기능을 가진 요소가 존재한다면 개발자는 되도록 의미를 가진 HTML을 ARIA보다 선호해야 합니다. 몇 가지 예시로, 네이티브 요소는 키보드 접근성, 역할, 상태를 내장하고 있습니다. 그러나 ARIA를 쓰기로 결정했다면 브라우저 동작 방식을 따라 하는 건 개발자의 책임입니다.

+
+ +

다음은 진행 표시줄 위젯의 마크업입니다.

+ +
<div id="percent-loaded" role="progressbar" aria-valuenow="75"
+     aria-valuemin="0" aria-valuemax="100">
+</div>
+
+ + + +

지원

+ +

다른 웹 기술과 마찬가지로, ARIA 역시 환경 별 지원 수준에 차이를 보입니다. 지원 수준은 사용자의 운영 체제 및 사용하는 브라우저, 그리고 연결된 보조 기술마다 다릅니다. 게다가 각각의 버전 또한 영향을 줍니다. 오래된 소프트웨어 버전은 특정 ARIA 역할을 지원하지 않거나, 부분적으로만 지원하거나, 잘못된 기능을 가지고 있을 수 있습니다.

+ +

또 다른 중요한 점은, 보조 기술에 의존하는 사용자 일부가 컴퓨터 및 브라우저 상호작용 기능을 잃어버릴까 두려워 소프트웨어 업그레이드를 주저할 수 있다는 점을 인지하는 것입니다. 그러므로 가능한 한 보조 기술이 훨씬 넓게 지원하는, 의미를 가진 HTML 요소를 사용하는 편이 좋습니다.

+ +

마지막으로 작성한 ARIA을 실제 보조 기술로 시험하는 것도 필요합니다. 브라우저 에뮬레이터와 시뮬레이터가 전체 테스트에 효율적인 도구가 아니듯, 유사 보조 기술만으로는 완벽한 지원을 장담하기엔 부족합니다.

+ +
+
+
+

자습서

+ +
+
ARIA 소개
+
동적인 컨텐츠를 ARIA를 적용해 접근성을 갖추도록 하는 방법에 대한 소개한 글입니다. Gez Lemon이 2008년에 쓴 ARIA 분야의 고전인 ARIA intro도 참조하십시오.
+
스크린 리더기에서 ARIA를 어떻게 사용하는지에 대한 영상
+
ARIA "적용 전", "적용 후" 영상을 비롯하여, 웹에서 볼 수 있는 실제 사용 예제들과 그것보다 간략화된 예시들을 볼 수 있습니다.
+
ARIA 사용하기
+
개발자를 위한 실용 가이드를 제공하는 글입니다. HTML 요소에 어떤 ARIA 속성들을 써야 하는지에 대해 제안하는 내용을 담고 있습니다. 제안은 실제 구현 상황을 바탕으로 합니다.
+
+ +

간단한 ARIA 향상

+ +
+
ARIA 랜드마크를 사용하여 페이지 탐색 고도화
+
스크린 리더 사용자들을 위해 ARIA 랜드마크를 사용하여 웹 페이지의 탐색 기능을 향상시키는 법을 소개해주는 좋은 글입니다. 이와 더불어서 ARIA 구현 노트 및 실제 사이트에서의 활용 예시들을 참고하세요. (2011년 7월에 업데이트됨)
+
폼 접근성 향상하기
+
ARIA는 동적 콘텐츠만을 위한 것이 아닙니다! ARIA 특성을 사용해 HTML 폼의 접근성을 높이는 방법을 알아보세요.
+
+ +

스크립트 처리된 위젯을 위한 ARIA

+ +
+
JavaScript 위젯에 키보드 탐색 및 초점 적용하기
+
{{htmlelement("input")}}, {{htmlelement("button")}} 등 내장 요소는 기본적으로 키보드를 지원합니다. {{htmlelement("div")}}와 ARIA로 특정 요소를 흉내 낸다면, 그 위젯도 키보드를 지원하도록 해야 합니다.
+
실시간 영역
+
실시간 영역은 페이지 콘텐츠에 가해지는 변경점을 접근성 보조 기술이 어떻게 처리해야 하는지 제안합니다.
+
ARIA 실시간 영역으로 콘텐츠 변경 알리기
+
JAWS 스크린 리더 소프트웨어의 개발진이 실시간 영역에 대해 요약한 글입니다.
+
+
+ +
+

표준화를 위한 노고

+ +
+
WAI-ARIA 명세
+
W3C 명세입니다.
+
WAI-ARIA 작성 안내서
+
+

흔히 쓰이는 위젯을 ARIA스럽게 만드는 방법에 대한 공식 안내서로, 훌륭한 자원입니다.

+
+
+ +

비디오

+ +

다음 발표 비디오는 ARIA를 이해할 수 있는 훌륭한 방법입니다.

+ +

ARIA, Accessibility APIs and coding like you give a damn! – Léonie Watson

+ +

버그 제출

+ +

브라우저, 스크린 리더, JavaScript 라이브러리의 ARIA 버그 제출하기

+
+
+
+ + + +

{{glossary("Accessibility", "접근성")}}, {{glossary("AJAX")}}, JavaScript

+ + diff --git a/files/ko/web/accessibility/aria/roles/dialog_role/index.html b/files/ko/web/accessibility/aria/roles/dialog_role/index.html new file mode 100644 index 0000000000..90fc507652 --- /dev/null +++ b/files/ko/web/accessibility/aria/roles/dialog_role/index.html @@ -0,0 +1,158 @@ +--- +title: 'ARIA: dialog role' +slug: Web/Accessibility/ARIA/Roles/dialog_role +tags: + - ARIA + - Web Development + - 접근성 +translation_of: Web/Accessibility/ARIA/Roles/dialog_role +--- +

{{draft()}}

+ +

\{{ariaref}}

+ +

dialog 역할(role)은 HTML 기반의 애플리케이션의 다이얼로그 또는 콘텐츠를 분리하는 창 또는 다른 웹 애플리케이션의 UI 혹은 페이지를 마크업하는데 사용됩니다. 다이얼로그는 일반적으로 오버레이를 사용하여 페이지 위에 표시됩니다. 다이얼로그는 비모달(non-modal) (열린 이후에도 다이얼로그 바깥의 콘텐츠와 상호작용할 수 있습니다) 또는 모달(오로지 다이얼로그 콘텐츠와 상호작용할 수 있습니다) 형태일 수 있습니다.

+ +
<div role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc">
+  <h2 id="dialog1Title">귀하의 개인정보가 성공적으로 갱신되었습니다.</h2>
+  <p id="dialog1Desc">
+    <a href="/account">개인정보 관리</a> 페이지에서 언제든지 개인정보를 수정할 수 있습니다.
+  </p>
+  <button>닫기</button>
+</div>
+ +

설명

+ +

다이얼로그 요소를 마크업하는 것은 보조 기술(Assistive Technology)이 다이얼로그의 콘텐츠가 그룹하 되어 페이지의 나머지 콘텐츠와 분리됨을 식별하는 것을 돕습니다. 하지만, 단순히 role="dialog"를 추가하는 것으로 다이얼로그의 접근성을 높이지 못합니다. 추가적으로 다음 항목들이 충족되어야 합니다:

+ + + +

아래 섹션들은 이 두가지 요구 사항을 어떻게 만족시킬 수 있을지 설명합니다.

+ +

레이블링

+ +

다이얼로그 요소 자체가 포커스를 가질 필요는 없지만, 여전히 레이블링을 할 필요가 있습니다. 다이얼로그에 주어진 레이블은 다이얼로그 내 상호작용 가능한 컨트롤들에 contextual information를 제공합니다. 예를 들어, 다이얼로그의 레이블은 내부의 컨트롤들의 레이블의 그롭화된 레이블처럼 작동합니다. (<legend> 요소가 내부의 <fieldset> 요소에 그룹화된 레이블을 제공하는 것과 비슷합니다)

+ +

만약 다이얼로그가 이미 눈에 보이는 타이틀바를 가지고 있다면, 그 안속의 텍스트는 다이얼로그를 레이블하는데 사용될 수 있습니다. 이를 이루기 위해 role="dialog" 속성을 가진 요소에 aria-labelledby 속성을 사용합니다. 또한, 만약 다이얼로그에 제목 외의 추가적인 설명 텍스트가 있다면, 그 텍스트는 aria-describedby 속성을 사용하여 다이얼로그에 관련되게 만들 수 있습니다. 이러한 방법은 아래 코드를 통해 확인하실 수 있습니다:

+ +
<div role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc">
+  <h2 id="dialog1Title">귀하의 개인정보가 성공적으로 갱신되었습니다.</h2>
+  <p id="dialog1Desc">
+    <a href="/account">개인정보 관리</a> 페이지에서 언제든지 개인정보를 수정할 수 있습니다.
+  </p>
+  <button>닫기</button>
+</div>
+ +

 

+ +
비가상 모드에서 작동하는 스크린 판독기에 의해 인지되기 위해서는 다이얼로그 제목과 설명 텍스트가 포커스가 가능하지 않아야 한다는 점을 유의하십시오. ARIA 다이얼로그 역할과 레이블링 기술은 다이얼로그로 포커스가 이동하였을 때 스크린 판독기가 다이얼로그의 정보를 인지할 수 있도록 합니다.
+ +

Focus management 포커스 관리

+ +

다이얼로그는 키보드 포커스를 관리하는 방법에 대한 특별한 요구 사항이 있습니다.

+ + + +

 

+ +

관련된 ARIA 역할, 상태 및 속성

+ +
+
aria-labelledby
+
다이얼로그에 label을 하려면 이 속성을 사용하십시오. 보통, 다이얼로그의 제목 요소의 id값이 aria-labelledby 속성의 값이 됩니다.
+
aria-describedby
+
다이얼로그의 콘텐츠를 묘사하기 위해 이 속성을 사용하십시오.
+
+ +

Possible effects on user agents and assistive technology 

+ +

When the dialog role is used, the user agent should do the following:

+ + + +

When the dialog is correctly labeled and focus is moved to a control inside the dialog, screen readers should announce the dialog's accessible role, name and optionally description before announcing the focused element. 

+ +
Note: Opinions may differ on how assistive technology should handle this technique. The information provided above is one of those opinions and therefore not normative.
+ +

예제

+ +

예제 1: 폼을 포함하는 다이얼로그

+ +
 <div role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc">
+   <h2 id="dialog1Title">구독하기</h2>
+   <p id="dialog1Desc">우리는 이 정보를 제 3자에게 제공하지 않습니다.</p>
+   <form>
+     <p>
+       <label for="firstName">이름</label>
+       <input id="firstName" type="text" />
+     </p>
+     <p>
+       <label for="lastName">성</label>
+       <input id="lastName" type="text"/>
+     </p>
+     <p>
+       <label for="interests">관심분야</label>
+       <textarea id="interests"></textarea>
+     </p>
+     <p>
+         <input type="submit" value="정보 저장하기"/>
+     </p>
+   </form>
+ </div>
+ +

Example 2: A dialog based on a Fieldset as fallback content

+ +

To support browsers or AT products that do not support ARIA mark up, it's also possible to use apply the dialog markup to a fieldset element as fallback content. This way the dialog title will still be announced correctly:

+ +
<fieldset role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc">
+  <legend>
+    <span id="dialog1Title">Your personal details were successfully updated.</span>
+    <span id="dialog1Desc">You can change your details at any time in the user account section.</span>
+  </legend>
+
+  <button>Close</button>
+</fieldset>
+ +

작업된 예제:

+ + + +

Notes 

+ +
Note: While it is possible to prevent keyboard users from moving focus to elements outside of the dialog, screen reader users may still be able to navigate that content virtually to use their screen reader's virtual cursor. Because of this, dialogs are considered to be a special case of the application role: They are expected to be navigated by screen reader users in a non-virtual navigation mode.
+ +

사용되는 ARIA 속성

+ + + +

관련된 ARIA 기술 

+ + + +

Compatibility

+ +

TBD: Add support information for common UA and AT product combinations

+ +

Additional resources

+ +

 

diff --git a/files/ko/web/accessibility/aria/roles/index.html b/files/ko/web/accessibility/aria/roles/index.html new file mode 100644 index 0000000000..3b92115b59 --- /dev/null +++ b/files/ko/web/accessibility/aria/roles/index.html @@ -0,0 +1,78 @@ +--- +title: WAI-ARIA Roles +slug: Web/Accessibility/ARIA/Roles +tags: + - ARIA + - Accessibility + - NeedsTranslation + - Rôles + - TopicStub +translation_of: Web/Accessibility/ARIA/Roles +--- +

This page lists reference pages covering all the WAI-ARIA roles discussed on MDN. For a full list of roles, see Using ARIA: Roles, States, and Properties

+ +

{{SubpagesWithSummaries}}

+ + diff --git a/files/ko/web/accessibility/index.html b/files/ko/web/accessibility/index.html new file mode 100644 index 0000000000..9faf5ccaa5 --- /dev/null +++ b/files/ko/web/accessibility/index.html @@ -0,0 +1,49 @@ +--- +title: 접근성 +slug: Web/Accessibility +tags: + - Accessibility + - 접근성 +translation_of: Web/Accessibility +--- +

웹 개발에서의 접근성은 사람들의 능력이 어느정도 제한되어 있더라도 가능한 많은 사람들이 웹사이트를 사용 할 수 있도록 하는것 입니다. 여기서 우리는 접근할 수 있는 콘텐츠 개발에 관한 정보를 제공 합니다.

+ +

"접근성은 장애인을 돕기 위한 '휠체어접근' 과 같은 시설이나 편의 시설을 설명하는 데 가장 많이 사용됩니다. 이것은 점저 감판, 휠체어 경사로, 보행자 교차점에서의 오디오 신호등, 보행로 등고선, 웹 사이트 디자인 등으로 확장될 수 있습니다." Wikipedia entry for Accessibility

+ +

"그들의 하드웨어, 소프트웨어, 언어, 문화, 위치 또는 신체적 혹은 정신적 능력이 무엇이든지 간에, 웹은 근본적으로 모든 사람들을 위해 일하도록 설계되어 있습니다. 웹이 이 목표를 달성할 때, 다양한 범위의 청각, 움직임, 시각, 인지 능력을 가진 사람들에게 접근할 수 있습니다." W3C - Accessibility

+ +
+
+

Documentation

+ +
+
Web development
+
접근성 세계에서 웹 개발 문제를 강조하기 위해 지정된 문서 모음 입니다.
+
ARIA
+
HTML문서를 좀 더 쉽게 접근 할 수 있는 방법을 배우기 위해 사용할 수 있는 문서 모음 입니다.
+
Assistive technology (AT) development
+
AT 개발자를 위한 기사 모음 입니다.
+
Mobile accessibility checklist
+
모바일 앱 개발자에 대한 접근성 요구 사항을 간략하게 확인할 수 있는 문서 모음 입니다.
+
+ +

View all articles about Accessibility...

+
+ +
+

웹 개발자들을 위한 도구

+ + + +

View All...

+ +

기타 유용한 사이트

+ + +
+
diff --git a/files/ko/web/accessibility/mobile_accessibility_checklist/index.html b/files/ko/web/accessibility/mobile_accessibility_checklist/index.html new file mode 100644 index 0000000000..6a9a73cdbe --- /dev/null +++ b/files/ko/web/accessibility/mobile_accessibility_checklist/index.html @@ -0,0 +1,106 @@ +--- +title: 모바일 접근성 점검항목 +slug: Web/Accessibility/Mobile_accessibility_checklist +translation_of: Web/Accessibility/Mobile_accessibility_checklist +--- +
+

이 문서는 모바일 앱 개발자를 위한 접근성 요구 사항에 대한 간결한 체크리스트를 제공한다. 더 많은 패턴이 발생할수록 지속적으로 진화하려는 의도다.

+
+ +

색

+ + + +

  가시성

+ + + +

초점

+ + + +

텍스트 동등성

+ + + +

처리 상태

+ + + +

방향

+ + + +

General Guidelines

+ + + +
+

Note: The original version of this document was written by Yura Zenevich.

+
diff --git a/files/ko/web/accessibility/understanding_wcag/index.html b/files/ko/web/accessibility/understanding_wcag/index.html new file mode 100644 index 0000000000..fe71b20ebc --- /dev/null +++ b/files/ko/web/accessibility/understanding_wcag/index.html @@ -0,0 +1,59 @@ +--- +title: Understanding the Web Content Accessibility Guidelines +slug: Web/Accessibility/Understanding_WCAG +tags: + - NeedsTranslation + - TopicStub + - WCAG + - Web Content Accessibility Guidelines +translation_of: Web/Accessibility/Understanding_WCAG +--- +

This set of articles provides quick explanations to help you understand the steps that need to be taken to conform to the recommendations outlined in the W3C Web Content Accessibility Guidelines 2.0 or 2.1 (or just WCAG, for the purposes of this writing).

+ +

The WCAG 2.0 and 2.1 provide a detailed set of guidelines for making web content more accessible to people with a wide variety of disabilities. It is comprehensive but incredibly detailed, and quite difficult to gain a rapid understanding of. For this reason, we have summarised the practical steps you need to take to satisfy the different recommendations, with further links to more details where required.

+ +

The four principles

+ +

WCAG is broadly broken down into four principles — major things that web content must be to be considered accessible (see Understanding the Four Principles of Accessibility for the WCAG definitions).

+ +

Each of the links below will take you to pages that further expand on these areas, giving you practical advice on how to write your web content so it conforms to the success criteria outlined in each of the WCAG 2.0 and 2.1 guidelines that further sub-divides each principle.

+ + + +

Should I use WCAG 2.0 or 2.1?

+ +

WCAG 2.1 is the most recent and relevant accessibility standard. Use WCAG 2.1 to help more people with disabilities and reduce the future legal risk for web site owners. Target WCAG 2.0 first when allocating resources. Then step up to WCAG 2.1. 

+ +

What is WCAG 2.1?

+ +

WCAG 2.1 was published as an official recommendation on 05 June 2018. The European Union (EU) adopted WCAG 2.1 as the digital accessibility standard in September 2018. W3C published a press release WCAG 2.1 Adoption in Europe. 

+ +

WCAG 2.1 includes:

+ + + + + +

This guide is intended to provide practical information to help you build better, more accessible websites. However, we are not lawyers, and none of this constitutes legal advice. If you are worried about the legal implications of web accessibility, we'd recommend that you check the specific legislation governing accessibility for the web/public resources in your country or locale, and seek the advice of a qualified lawyer.

+ +

What is accessibility? and particularity the Accessibility guidelines and the law section provide more related information.

diff --git a/files/ko/web/accessibility/understanding_wcag/keyboard/index.html b/files/ko/web/accessibility/understanding_wcag/keyboard/index.html new file mode 100644 index 0000000000..32705d664f --- /dev/null +++ b/files/ko/web/accessibility/understanding_wcag/keyboard/index.html @@ -0,0 +1,87 @@ +--- +title: Keyboard +slug: Web/Accessibility/Understanding_WCAG/Keyboard +translation_of: Web/Accessibility/Understanding_WCAG/Keyboard +--- +
To be fully accessible, a web page must be operable by someone using only a keyboard to access and control it. This includes users of screen readers, but can also include users who have trouble operating a pointing device such as a mouse or trackball, or whose mouse is not working at the moment, or who simply prefer to use a keyboard for input whenever possible.
+ +

Focusable elements should have interactive semantics

+ +

If an element can be focused using the keyboard, then it should be interactive; that is, the user should be able to do something to it and produce a change of some kind (for example, activating a link or changing an option).

+ +
+

Note: One important exception to this rule is if the element has role="document" applied to it, inside an interactive context (such as role="application"). In such a case, focusing the nested document is the only way of returning assistive technology to a non-interactive state (often called "browse mode").

+
+ +

Most interactive elements are focusable by default; you can make an element focusable by adding a tabindex=0 attribute value to it. However, you should only add tabindex if you have also made the element interactive, for example, by defining appropriate event handlers keyboard events.

+ +

See also

+ + + +

Avoid using tabindex attribute greater than zero

+ +

The tabindex attribute indicates that an element is focusable using the keyboard. A value of zero indicates that the element is part of the default focus order, which is based on the ordering of elements in the HTML document. A positive value puts the element ahead of those in the default ordering; elements with positive values are focused in the order of their tabindex values (1, then 2, then 3, etc.).

+ +

This creates confusion for keyboard-only users when the focus order differs from the logical order of the page. A better strategy is to structure the HTML document so that focusable elements are in a logical order, without the need to re-order them with positive tabindex values.

+ +

See also

+ + + +

Clickable elements must be focusable and should have interactive semantics

+ +

If an element can be clicked with a pointing device, such as a mouse, then it should also be focusable using the keyboard, and the user should be able to do something by interacting with it.

+ +

An element is clickable if it has an onclick event handler defined. You can make it focusable by adding a tabindex=0 attribute value to it. You can make it operable with the keyboard by defining an onkeydown event handler; in most cases, the action taken by event handler should be the same for both types of events.

+ +

See also

+ + + +

Interactive elements must be able to be activated using a keyboard

+ +

If the user can interact with an element using touch or a pointing device, then the element should also support interacting using the keyboard. That is, if you have defined event handlers for touch or click events, you should also define them for keyboard events. The keyboard event handlers should enable the effectively the same interaction as the touch or click handlers.

+ +

See also

+ + + +

Interactive elements must be focusable

+ +

If the user can interact with an element (for example, using touch or a pointing device), then it should be focusable using the keyboard. You can make it focusable by adding a tabindex=0 attribute value to it. That will add the element to the list of elements that can be focused by pressing the Tab key, in the sequence of such elements as defined in the HTML document.

+ +

See also

+ + + +

Focusable element must have focus styling

+ +

Any element that can receive keyboard focus should have visible styling that indicates when the element is focused. You can do this with the :focus CSS pseudo-class.

+ +

Standard focusable elements such as links and input fields are given special styling by the browser by default, so you might not need to specify focus styling for such elements, unless you want the focus styling to be more distinctive.

+ +

If you create your own focusable components, be sure that you also define focus styling for them.

+ +

See also

+ + -- cgit v1.2.3-54-g00ecf