initial commit

3 files changed, 471 insertions, 0 deletions

diff --git a/files/vi/web/accessibility/aria/aria_live_regions/index.html b/files/vi/web/accessibility/aria/aria_live_regions/index.html
new file mode 100644
index 0000000000..bbeee0897f
--- /dev/null
+++ b/files/vi/web/accessibility/aria/aria_live_regions/index.html
@@ -0,0 +1,259 @@
+---
+title: ARIA live regions
+slug: Web/Accessibility/ARIA/ARIA_Live_Regions
+translation_of: Web/Accessibility/ARIA/ARIA_Live_Regions
+---
+<p>Sử dụng JavaScript, nó có thể thay đổi vài phần trong trang web mà không yêu cầu tải lại trang — lấy ví dụ, để cập nhật danh sách kết quả tìm kiếm ngay lập tức, hoặc để hiển thị một cảnh báo hay thông báo mà không bắt người dùng phải tương tác. Mặc dù những thay đổi này có thể nhìn thấy đối với người dùng, nó lại có thể không rõ ràng với những người cần sự hỗ trợ của công nghệ trợ năng. ARIA live regions giúp xử lý điều này bằng <span class="tlid-translation translation" lang="vi"><span title="">việc cung cấp một cách để lập trình các thay đổi nội dung động có thể được nhận diện bởi các công nghệ trợ năng.</span></span></p>
+
+<div class="note">
+<p><span class="tlid-translation translation" lang="vi"><span title=""><strong>Lưu ý:</strong> Các công nghệ trợ năng sẽ thông báo các thay đổi trong nội dung của một khu vực trực tiếp.</span> <span title="">Khu vực trực tiếp trước hết phải hiện diện (và thường trống), để trình duyệt và công nghệ hỗ trợ nhận thức được điều đó.</span> <span title="">Mọi thay đổi sau đó sẽ được thông báo.</span></span></p>
+
+<p>Đơn giản chỉ cần thêm vào thuộc tính <code>aria-live</code> hoặc thuộc tính chuyên biệt <code>role</code> (như là <code>role="alert"</code>) trong markup ban đầu chưa có hoạt động.</p>
+
+<p>Dynamically adding an element with an <code>aria-live</code> attribute or specialized <code>role</code> to the document also won't result in any announcement by assistive technologies (as, at that point, the browser/assistive technologies are not aware of the live region yet, so cannot monitor it for changes).</p>
+
+<p>Always make sure that the live region is present in the document first, and only then dynamically add/change any content.</p>
+</div>
+
+<h2 id="Simple_live_regions"><span class="mw-headline" id="Live_Region_State">Simple live regions</span></h2>
+
+<p>Dynamic content which updates without a page reload is generally either a region or a widget. Simple content changes which are not interactive should be marked as live regions. Below is a list of each related ARIA live region property with a description.</p>
+
+<ol>
+ <li><code><strong>aria-live</strong></code>: The <code>aria-live=POLITENESS_SETTING</code> is used to set the priority with which screen reader should treat updates to live regions - the possible settings are: <code>off</code>, <code>polite</code> or <code>assertive</code>. The default setting is <code>off</code>. This attribute is by far the most important.</li>
+ <li>
+  <p class="comment"><code><strong>aria-controls</strong></code>: The <code>aria-controls=[IDLIST]</code> is used to associate a control with the regions that it controls. Regions are identified just like an <code>id</code> in a <code>div</code>, and multiple regions can be associated with a control using a space, e.g. <code>aria-controls="myRegionID1 myRegionsID2"</code>.</p>
+
+  <div class="warning">Not known if the aria-controls aspect of live regions is implemented in current ATs, or which. Needs research.</div>
+ </li>
+</ol>
+
+<p>Normally, only <code>aria-live="polite"</code> 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.</p>
+
+<p>For regions which are not important, or would be annoying because of rapid updates or other reasons, silence them with <code>aria-live="off"</code>.</p>
+
+<h3 id="Dropdown_box_updates_useful_onscreen_information">Dropdown box updates useful onscreen information</h3>
+
+<p>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.</p>
+
+<h4 id="HTML">HTML</h4>
+
+<pre class="brush: html notranslate">&lt;fieldset&gt;
+  &lt;legend&gt;Planet information&lt;/legend&gt;
+  &lt;label for="planetsSelect"&gt;Planet:&lt;/label&gt;
+  &lt;select id="planetsSelect" aria-controls="planetInfo"&gt;
+    &lt;option value=""&gt;Select a planet&amp;hellip;&lt;/option&gt;
+    &lt;option value="mercury"&gt;Mercury&lt;/option&gt;
+    &lt;option value="venus"&gt;Venus&lt;/option&gt;
+    &lt;option value="earth"&gt;Earth&lt;/option&gt;
+    &lt;option value="mars"&gt;Mars&lt;/option&gt;
+  &lt;/select&gt;
+  &lt;button id="renderPlanetInfoButton"&gt;Go&lt;/button&gt;
+&lt;/fieldset&gt;
+
+&lt;div role="region" id="planetInfo" aria-live="polite"&gt;
+  &lt;h2 id="planetTitle"&gt;No planet selected&lt;/h2&gt;
+  &lt;p id="planetDescription"&gt;Select a planet to view its description&lt;/p&gt;
+&lt;/div&gt;
+
+&lt;p&gt;&lt;small&gt;Information courtesy &lt;a href="https://en.wikipedia.org/wiki/Solar_System#Inner_Solar_System"&gt;Wikipedia&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;
+</pre>
+
+<h4 id="JavaScript">JavaScript</h4>
+
+<pre class="brush: js notranslate">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 =&gt; {
+  const planetsSelect = document.querySelector('#planetsSelect');
+  const selectedPlanet = planetsSelect.options[planetsSelect.selectedIndex].value;
+
+  renderPlanetInfo(selectedPlanet);
+});
+</pre>
+
+<p>{{EmbedLiveSample('Dropdown_box_updates_useful_onscreen_information', '', 350)}}</p>
+
+<p>As the user selects a new planet, the information in the live region will be announced. Because the live region has <code>aria-live="polite"</code>, 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.</p>
+
+<p>Here is a screenshot of VoiceOver on Mac announcing the update (via subtitles) to the live region:</p>
+
+<p><img alt="A screenshot of VoiceOver on Mac announcing the update to a live region. Subtitles are shown in the picture." src="https://mdn.mozillademos.org/files/15815/Web_Accessibility_ARIA_ARIA_Live_Regions.png" style="height: 573px; width: 800px;"></p>
+
+<h2 id="Preferring_specialized_live_region_roles">Preferring specialized live region roles</h2>
+
+<p>In the following well-known predefined cases it is better to use a specific provided "live region role":</p>
+
+<table style="width: 100%;">
+ <thead>
+  <tr>
+   <th scope="col">Role</th>
+   <th scope="col">Description</th>
+   <th scope="col">Compatibility Notes</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>log</td>
+   <td>Chat, error, game or other type of log</td>
+   <td>To maximize compatibility, add a redundant <code>aria-live="polite"</code> when using this role.</td>
+  </tr>
+  <tr>
+   <td>status</td>
+   <td>A 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.</td>
+   <td>To maximize compatibility, add a redundant <code>aria-live="polite"</code> when using this role.</td>
+  </tr>
+  <tr>
+   <td>alert</td>
+   <td>Error 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)</td>
+   <td>To maximize compatibility, some people recommend adding a redundant <code>aria-live="assertive"</code> when using this role. However, adding both <code>aria-live</code> and <code>role="alert"</code> causes double speaking issues in VoiceOver on iOS.</td>
+  </tr>
+  <tr>
+   <td>progressbar</td>
+   <td>A hybrid between a widget and a live region. Use this with aria-valuemin, aria-valuenow and aria-valuemax. (TBD: add more info here).</td>
+   <td></td>
+  </tr>
+  <tr>
+   <td>marquee</td>
+   <td>for text which scrolls, such as a stock ticker.</td>
+   <td></td>
+  </tr>
+  <tr>
+   <td>timer</td>
+   <td>or any kind of timer or clock, such as a countdown timer or stopwatch readout.</td>
+   <td></td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Advanced_live_regions">Advanced live regions</h2>
+
+<p>(TBD: more granular information on the support of the individual attributes with combinations of OS/Browser/AT).</p>
+
+<p>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).</p>
+
+<p>The Paciello Group has some <a href="https://www.paciellogroup.com/blog/2014/03/screen-reader-support-aria-live-regions/">information about the state of the support of Live Regions </a>(2014). Paul J. Adam has researched<a href="http://pauljadam.com/demos/aria-atomic-relevant.html"> the support of Aria-Atomic and Aria-Relevant</a> in particular. </p>
+
+<ol>
+ <li><code><strong>aria-atomic</strong></code>: The <code>aria-atomic=BOOLEAN</code> 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: <code>false</code> or <code>true</code>. The default setting is <code>false</code>.</li>
+ <li><code><a href="/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-relevant_attribute" title="/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-relevant_attribute"><strong>aria-relevant</strong></a></code>: The <code>aria-relevant=[LIST_OF_CHANGES]</code> is used to set what types of changes are relevant to a live region. The possible settings are one or more of: <code>additions</code>, <code>removals</code>, <code>text</code>, <code>all</code>. The default setting is: <code>additions text</code>.</li>
+ <li><code><strong>aria-labelledby</strong></code>: The <code>aria-labelledby=[IDLIST]</code> 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.</li>
+ <li><code><strong>aria-describedby</strong></code>: The <code>aria-describedby=[IDLIST]</code> 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.</li>
+</ol>
+
+<h3 id="Advanced_use_case_Clock"><span class="mw-headline" id="Use_Case:_Clock">Advanced use case: Clock</span></h3>
+
+<p>As an illustration of <code>aria-atomic</code>, 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.</p>
+
+<pre class="notranslate">&lt;div id="clock" role="timer" aria-live="polite"&gt;&lt;/div&gt;
+</pre>
+
+<pre class="brush: js notranslate">/* 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);
+</pre>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p><code>aria-atomic="true"</code> ensures that each time the live region is updated, the entirety of the content is announced in full (e.g. "Time: 17:34").</p>
+
+<pre class="notranslate">&lt;div id="clock" role="timer" aria-live="polite" aria-atomic="true"&gt;&lt;/div&gt;
+</pre>
+
+<div class="note">
+<p><strong>Note</strong>: 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.</p>
+</div>
+
+<p class="syntaxbox">A working example of a simple year control for better understanding:</p>
+
+<pre class="syntaxbox notranslate">&lt;div id="date-input"&gt;
+  &lt;label&gt;Year:
+    &lt;input type="text" id="year" value="1990" onblur="change(event)"/&gt;
+  &lt;/label&gt;
+&lt;/div&gt;
+
+&lt;div id="date-output" aria-live="polite"&gt;
+  The set year is:
+  &lt;span id="year-output"&gt;1990&lt;/span&gt;
+&lt;/div&gt;</pre>
+
+<p class="syntaxbox"></p>
+
+<pre class="syntaxbox notranslate">function change(event) {
+  var yearOut = document.getElementById("year-output");
+  switch (event.target.id) {
+    case "year":
+      yearOut.innerHTML = event.target.value;
+      break;
+   default:
+      return;
+  }
+};</pre>
+
+<p class="syntaxbox"></p>
+
+<p>Without <code>aria-atomic="true" </code>the screenreader announces only the changed value of year.</p>
+
+<p>With <code>aria-atomic="true"</code>, the screenreader announces "The set year is: <em>changedvalue</em>"</p>
+
+<h3 id="Advanced_use_case_Roster"><span class="mw-headline" id="Use_Case:_Roster">Advanced use case: Roster</span></h3>
+
+<p>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).</p>
+
+<pre class="notranslate">&lt;ul id="roster" aria-live="polite" aria-relevant="additions removals"&gt;
+	&lt;!-- use JavaScript to add remove users here--&gt;
+&lt;/ul&gt;
+</pre>
+
+<p>Breakdown of ARIA live properties:</p>
+
+<ul>
+ <li><code>aria-live="polite"</code> indicates that the screen reader should wait until the user is idle before presenting updates to the user. This is the most commonly used value, as interrupting the user with "assertive" might interrupt their flow.</li>
+ <li><code>aria-atomic</code> is not set (<code>false</code> by default) so that only the added or removed users should be spoken and not the entire roster each time.</li>
+ <li><code>aria-relevant="additions removals"</code> ensures that both users added or removed to the roster will be spoken.</li>
+</ul>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/Accessibility/ARIA/Roles">ARIA roles</a></li>
+</ul>
diff --git a/files/vi/web/accessibility/aria/index.html b/files/vi/web/accessibility/aria/index.html
new file mode 100644
index 0000000000..b7587c76b0
--- /dev/null
+++ b/files/vi/web/accessibility/aria/index.html
@@ -0,0 +1,136 @@
+---
+title: ARIA
+slug: Web/Accessibility/ARIA
+tags:
+  - ARIA
+  - Accessibility
+  - HTML
+  - NeedsTranslation
+  - TopicStub
+translation_of: Web/Accessibility/ARIA
+---
+<p class="summary"><span class="seoSummary">Accessible Rich Internet Applications <strong>(ARIA) </strong>is a set of attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to people with disabilities. </span></p>
+
+<p><span class="seoSummary">It supplements HTML so that interactions and widgets commonly used in applications can be passed to assistive technologies</span> when there is not otherwise a mechanism. For example, ARIA enables accessible navigation landmarks in HTML4, JavaScript widgets, form hints and error messages, live content updates, and more. </p>
+
+<div class="warning">
+<p>Many of these widgets were later incorporated into HTML5, and <strong>developers should prefer using the correct semantic HTML element over using ARIA</strong>, if such an element exists. For instance, native elements have built-in <a href="/en-US/docs/Web/Accessibility/Keyboard-navigable_JavaScript_widgets">keyboard accessibility</a>, roles and states. However, if you choose to use ARIA, you are responsible for mimicking (the equivalent) browser behaviour in script.</p>
+</div>
+
+<p>Here's the markup for a progress bar widget:</p>
+
+<pre class="brush: html notranslate">&lt;div id="percent-loaded" role="progressbar" aria-valuenow="75"
+     aria-valuemin="0" aria-valuemax="100"&gt;
+&lt;/div&gt;
+</pre>
+
+<p>This progress bar is built using a <code>&lt;div&gt;</code>, which has no meaning. Unfortunately, there isn't a more semantic tag available to developers in HTML 4, so we need to include ARIA roles and properties. These are specified by adding attributes to the element. In this example, the <code>role="progressbar"</code> attribute informs the browser that this element is actually a JavaScript-powered progress bar widget. The <code>aria-valuemin</code> and <code>aria-valuemax</code> attributes specify the minimum and maximum values for the progress bar, and the <code>aria-valuenow</code> describes the current state of it and therefore must be kept updated with JavaScript.</p>
+
+<p>Along with placing them directly in the markup, ARIA attributes can be added to the element and updated dynamically using JavaScript code like this:</p>
+
+<pre class="brush: js notranslate"><code>// Find the progress bar &lt;div&gt; in the DOM.
+ var progressBar = document.getElementById("percent-loaded");</code>
+
+<code>// Set its ARIA roles and states,
+// so that assistive technologies know what kind of widget it is.</code>
+ progressBar.setAttribute("role", "progressbar");
+ progressBar.setAttribute("aria-valuemin", 0);
+ progressBar.setAttribute("aria-valuemax", 100);
+
+// Create a function that can be called at any time to update
+// the value of the progress bar.
+ function updateProgress(percentComplete) {
+   progressBar.setAttribute("aria-valuenow", percentComplete);
+ }</pre>
+
+<div class="note">
+<p>Note that ARIA was invented after HTML4, so does not validate in HTML4 or its XHTML variants. However, the accessibility gains it provides far outweigh any technical invalidity.</p>
+
+<p>In HTML5, all ARIA attributes validate. The new landmark elements (<code>&lt;main&gt;</code>, <code>&lt;header&gt;</code>, <code>&lt;nav&gt;</code> etc) have built-in ARIA roles, so there is no need to duplicate them.</p>
+</div>
+
+<h2 id="Support">Support</h2>
+
+<p>Like any other web technology, there are varying degrees of support for ARIA. Support is based on the operating system and browser being used, as well as the kind of assistive technology interfacing with it. In addition, the version of the operating system, browser, and assistive technology are contributing factors. Older software versions may not support certain ARIA roles, have only partial support, or misreport its functionality.</p>
+
+<p>It is also important to acknowledge that some people who rely on assistive technology are reluctant to upgrade their software, for fear of losing the ability to interact with their computer and browser. Because of this, it is important to <a href="/en-US/docs/Learn/Accessibility/HTML">use semantic HTML elements</a> whenever possible, as semantic HTML has far better support for assistive technology.</p>
+
+<p>It is also important to test your authored ARIA with actual assistive technology. Much as how browser emulators and simulators are not an effective solution for testing full support, proxy assistive technology solutions aren't sufficient to fully guarantee functionality.</p>
+
+<section id="sect1">
+<div class="row topicpage-table">
+<div class="section">
+<h2 class="Documentation" id="Tutorials">Tutorials</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Accessibility/An_overview_of_accessible_web_applications_and_widgets">Introduction to ARIA</a></dt>
+ <dd>A quick introduction to making dynamic content accessible with ARIA. See also the classic <a class="external" href="http://dev.opera.com/articles/view/introduction-to-wai-aria/">ARIA intro by Gez Lemon</a>, from 2008.</dd>
+ <dt><a class="external" href="http://zomigi.com/blog/videos-of-screen-readers-using-aria-updated/">Videos of screen readers using ARIA</a></dt>
+ <dd>See both real and simplified examples from around the web, including "before" and "after" ARIA videos.</dd>
+ <dt><a class="external" href="https://w3c.github.io/using-aria/">Using ARIA</a></dt>
+ <dd>A practical guide for developers. It suggests what ARIA attributes to use on HTML elements. Suggestions are based on implementation realities.</dd>
+</dl>
+
+<h2 id="Simple_ARIA_enhancements">Simple ARIA enhancements</h2>
+
+<dl>
+ <dt><a class="external" href="https://www.paciellogroup.com/blog/2013/02/using-wai-aria-landmarks-2013/">Enhancing page navigation with ARIA landmarks</a></dt>
+ <dd>A nice intro to using ARIA landmarks to improve web page navigation for screen reader users. <a class="external" href="http://www.paciellogroup.com/blog/2011/07/html5-accessibility-chops-aria-landmark-support/">See also, ARIA landmark implementation notes</a> and examples on real sites (updated as of July 2011).</dd>
+ <dt><a href="/en-US/docs/ARIA/forms">Improving form accessibility</a></dt>
+ <dd>ARIA is not just for dynamic content! Learn how to improve accessibility of HTML forms using additional ARIA attributes.</dd>
+</dl>
+
+<h2 id="ARIA_for_Scripted_Widgets">ARIA for Scripted Widgets</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/Accessibility/Keyboard-navigable_JavaScript_widgets">Writing keyboard-navigable JavaScript widgets</a></dt>
+ <dd>Built-in elements like &lt;input&gt;, &lt;button&gt; etc have built-in keyboard accessibility. If you 'fake' these with &lt;div&gt;s and ARIA, you must ensure your widgets are keyboard accessible.</dd>
+ <dt><a href="/en-US/docs/Accessibility/ARIA/ARIA_Live_Regions" title="Live Regions">Live regions</a></dt>
+ <dd>Live regions provide suggestions to screen readers about how to handle changes to the contents of a page.</dd>
+ <dt><a class="external" href="http://www.freedomscientific.com/Training/Surfs-up/AriaLiveRegions.htm">Using ARIA Live Regions to announce content changes</a></dt>
+ <dd>A quick summary of live regions, by the makers of JAWS screen reader software. Live regions are also supported by NVDA with Firefox, and VoiceOver with Safari.</dd>
+</dl>
+</div>
+
+<div class="section">
+<h2 class="Tools" id="References">References</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/Accessibility/ARIA/Roles">ARIA Roles</a></dt>
+ <dd>Reference pages covering all the WAI-ARIA roles discussed on MDN.</dd>
+</dl>
+
+<h2 class="Tools" id="Standardization_Efforts">Standardization Efforts</h2>
+
+<dl>
+ <dt><a class="external" href="https://www.w3.org/TR/wai-aria-1.1/">WAI-ARIA Specification</a></dt>
+ <dd>The W3C specification itself.</dd>
+ <dt><a class="external" href="https://www.w3.org/TR/wai-aria-practices-1.1/">WAI-ARIA Authoring Practices</a></dt>
+ <dd>
+ <p>The official best practices documents how best to ARIA-ify common widgets and interactions. An excellent resource.</p>
+ </dd>
+</dl>
+
+<h2 id="Videos">Videos</h2>
+
+<p>Following talks are a great way to understand ARIA:</p>
+
+<p><a href="https://www.youtube.com/watch?v=qdB8SRhqvFc">ARIA, Accessibility APIs and coding like you give a damn! – Léonie Watson</a></p>
+
+<h2 id="Filing_Bugs">Filing Bugs</h2>
+
+<p><a href="/en/Accessibility/ARIA/How_to_file_ARIA-related_bugs" title="https://developer.mozilla.org/en/ARIA/How_to_file_ARIA-related_bugs">File ARIA bugs on browsers, screen readers, and JavaScript libraries.</a></p>
+</div>
+</div>
+</section>
+
+<h2 id="Related_Topics" name="Related_Topics">Related topics</h2>
+
+<p><a href="/en-US/docs/Accessibility">Accessibility</a>, <a href="/en-US/docs/AJAX">AJAX</a>, <a href="/en-US/docs/Web/JavaScript">JavaScript</a></p>
+
+<section id="Quick_Links">
+<ol>
+ <li><a href="/en-US/docs/Web/Guide" title="REDIRECT Web">Web Development</a></li>
+ <li><a href="/en-US/docs/Mozilla/Accessibility" title="Accessibility is the idea that software (among other things) should be designed to be usable and, as much as possible, convenient to use for people with disabilities. Mozilla strives to make its software accessible; the documents below cover the ways in which we do so.">Accessibility and Mozilla</a></li>
+</ol>
+</section>
diff --git a/files/vi/web/accessibility/index.html b/files/vi/web/accessibility/index.html
new file mode 100644
index 0000000000..908f9c13c5
--- /dev/null
+++ b/files/vi/web/accessibility/index.html
@@ -0,0 +1,76 @@
+---
+title: Accessibility
+slug: Web/Accessibility
+tags:
+  - Accessibility
+  - Landing
+  - NeedsTranslation
+  - TopicStub
+translation_of: Web/Accessibility
+---
+<p><span class="seoSummary"><strong>Accessibility</strong> (often abbreviated to <strong>A11y</strong>—as in "a" then 11 characters then "y") in Web development means enabling as many people as possible to use Web sites, even when those people's abilities are limited in some way. </span></p>
+
+<p>For many people, technology makes things easier. For people with disabilities, technology makes things possible. Accessibility means developing content to be as accessible as possible no matter an individual's physical and cognitive abilities and no matter how they access the web.</p>
+
+<p>"<strong>The Web is fundamentally designed to work for all people</strong>, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability." (<a href="http://www.w3.org/standards/webdesign/accessibility" title="http://www.w3.org/standards/webdesign/accessibility">W3C - Accessibility</a>)</p>
+
+<div class="cleared topicpage-table">
+<div class="section">
+<h2 class="Key_accessibility_tutorials" id="Key_accessibility_tutorials" name="Key_accessibility_tutorials">Key tutorials</h2>
+
+<p>The MDN <a href="/en-US/docs/Learn/Accessibility">Accessibility Learning Area</a> contains modern, up-to-date tutorials covering accessibility essentials:</p>
+
+<dl>
+ <dt><a href="/en-US/docs/Learn/Accessibility/What_is_accessibility">What is accessibility?</a></dt>
+ <dd>This article starts off the module with a good look at what accessibility actually is — this includes what groups of people we need to consider and why, what tools different people use to interact with the Web, and how we can make accessibility part of our web development workflow.</dd>
+ <dt><a href="/en-US/docs/Learn/Accessibility/HTML">HTML: A good basis for accessibility</a></dt>
+ <dd>A great deal of web content can be made accessible just by making sure the correct HTML elements are used for the correct purpose at all times. This article looks in detail at how HTML can be used to ensure maximum accessibility.</dd>
+ <dt><a href="/en-US/docs/Learn/Accessibility/CSS_and_JavaScript">CSS and JavaScript accessibility best practices</a></dt>
+ <dd>CSS and JavaScript, when used properly, also have the potential to allow for accessible web experiences ... or they can significantly harm accessibility if misused. This article outlines some CSS and JavaScript best practices that should be considered to ensure even complex content is as accessible as possible.</dd>
+ <dt><a href="/en-US/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA basics</a></dt>
+ <dd>Following on from the previous article, sometimes making complex UI controls that involve unsemantic HTML and dynamic JavaScript-updated content can be difficult. WAI-ARIA is a technology that can help with such problems by adding in further semantics that browsers and assistive technologies can recognize and use to let users know what is going on. Here we'll show how to use it at a basic level to improve accessibility.</dd>
+ <dt><a href="/en-US/docs/Learn/Accessibility/Multimedia">Accessible multimedia</a></dt>
+ <dd>Another category of content that can create accessibility problems is multimedia — video, audio, and image content need to be given proper textual alternatives so they can be understood by assistive technologies and their users. This article shows how.</dd>
+ <dt><a href="/en-US/docs/Learn/Accessibility/Mobile">Mobile accessibility</a></dt>
+ <dd>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.</dd>
+</dl>
+</div>
+
+<div class="section">
+<h2 class="Other_documentation" id="Other_documentation" name="Other_documentation">Other documentation</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/Accessibility/Understanding_WCAG">Understanding the Web Content Accessibility Guidelines</a></dt>
+ <dd>
+ <p>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 (WCAG 2.0 or just WCAG, for the purposes of this writing).</p>
+ </dd>
+ <dt><a href="/en/Accessibility/Keyboard-navigable_JavaScript_widgets" title="en/Accessibility/Keyboard-navigable JavaScript widgets">Keyboard-navigable JavaScript widgets</a></dt>
+ <dd>Until now, web developers who want to make their styled &lt;div&gt; and &lt;span&gt; based widgets accessible have lacked the proper techniques. <strong>Keyboard accessibility</strong> is part of the minimum accessibility requirements which a developer should be aware of.</dd>
+ <dt><a href="/en-US/docs/Accessibility/ARIA" title="/en-US/docs/Accessibility/ARIA">ARIA</a></dt>
+ <dd>A collection of articles to learn how to use ARIA to make your HTML documents more accessible.</dd>
+ <dt><a href="/en-US/docs/Accessibility/AT_Development" title="AT Development">Assistive technology (AT) development</a></dt>
+ <dd>A collection of articles intended for AT developers</dd>
+ <dt><a href="/en-US/docs/Web/Accessibility/Mobile_accessibility_checklist">Mobile accessibility checklist</a></dt>
+ <dd>This document provides a concise checklist of accessibility requirements for mobile app developers.</dd>
+ <dt><a href="/en-US/docs/Web/Accessibility/Cognitive_accessibility">Cognitive accessibility</a></dt>
+ <dd>When creating web content, be aware of how you can ensure that it is accessible to people cognitive impairments.</dd>
+ <dt><a href="/en-US/docs/Web/Accessibility/Seizure_disorders">Accessibility for seizure disorders</a></dt>
+ <dd>Some types of visual web content can induce seizures in people with certain brain disorders. Understand the types of content that can be problematic, and find tools and strategies to help you avoid them.</dd>
+ <dt></dt>
+</dl>
+
+<p><span class="alllinks"><a href="/en-US/docs/tag/Accessibility" title="/en-US/docs/tag/Accessibility">View all articles about Accessibility...</a></span></p>
+</div>
+</div>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="https://lists.mozilla.org/listinfo/accessibility">Mozilla mailing list about accessibility</a></li>
+ <li><a href="http://www.w3.org/WAI/IG/">WAI Interest Group</a></li>
+ <li><a href="https://mozillians.org/en-US/group/1-accessibility">Mozillians group about accessibility</a></li>
+ <li><a href="/en-US/docs/Web/Guide" title="REDIRECT Web">Developer guides</a></li>
+ <li><a href="/en-US/docs/Mozilla/Accessibility" title="Accessibility is the idea that software (among other things) should be designed to be usable and, as much as possible, convenient to use for people with disabilities. Mozilla strives to make its software accessible; the documents below cover the ways in which we do so.">Accessibility and Mozilla</a></li>
+</ul>
+
+<section id="Quick_Links"></section>