From dff764340513a9f670fda3be002173d06f1da170 Mon Sep 17 00:00:00 2001 From: Matt King Date: Sun, 15 Oct 2017 15:38:30 -0700 Subject: [PATCH] Add New READ ME First Section Forissue #474, modified aria-practices.html to add a read me first section. This includes some aria basics, a browser and AT compatibility statement, and a mobile and touch support statement. --- aria-practices.html | 87 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) diff --git a/aria-practices.html b/aria-practices.html index f2d1c86582..6a172e088b 100644 --- a/aria-practices.html +++ b/aria-practices.html @@ -79,6 +79,93 @@

Introduction

+
+

Read Me First

+
+

No ARIA is better than Bad ARIA

+

+ Functionally, ARIA roles, states, and properties are sort of like CSS for assistive technologies. + In the case of screen readers, ARIA controls the rendering of the non-visual experience. + Incorrect ARIA misrepresents the visual experience, with potentially devastating effects on non-visual experiences. +

+

Before using ARIA or any of the guidance in this document, please take time to understand the following two essential principles.

+

Principal 1: A role is a promise

+

This code:

+ 

+        <div role="button">Press Me</div>
+
+

+ Is a promise that the author of that <div> has also incorporated JavaScript that provides the keyboard interactions expected for a button. + Unlike HTML input elements, ARIA roles do not cause browsers to provide keyboard behaviors or styling. +

+

Using a role without fulfilling the promise of that role is similar to making a "Place Order" button that abandons an order and empties the shopping cart.

+

One of the objectives of this guide is to define expected behaviors for each ARIA role.

+

Principle 2: ARIA Can Both Cloak and Enhance, Creating Both Power and Danger

+

+ From the perspective of assistive technologies, ARIA gives authors the ability to dress up HTML and SVG elements to describe critical aspects of meaning and purpose that assistive technologies would not otherwise be able to reliably derive. + The information assistive technologies need about the meaning and purpose of user interface elements is called accessibility semantics. +

+

Some of ARIA is like a dress or cloak; it covers up, or overrides, the original semantics or content.

+ 

+        <a role="menuitem">Assistive tech users perceive this element as an item in a menu, not a link.</a>
+        <a aria-label="Assistive tech users perceive this aria-label, not the link text">Link Text</a>
+
+

On the other hand, some uses of ARIA are more like suspenders or belts; they add meaning that provides essential support to the original content.

+ 

+        <button aria-pressed="false">Press Me</button>
+
+

+ This is the power of ARIA. + It enables authors to describe nearly any user interface component in ways that assistive technologies can reliably interpret, thus making components accessible to assistive technology users. +

+

+ This is also the danger of ARIA. + Authors can inadvertently override accessibility semantics. +

+ 
+        
+          <table role="log">
+            <!--
+              Table that assistive technology users will not perceive as a table.
+              The log role tells browser this is a log, not a table.
+            -->
+          </table>
+          <ul role="navigation">
+            <!-- This is a navigation region, not a list. -->
+            <li><a href="uri1">nav link 1</li>
+            <li><a href="uri2">nav link 2</li>
+            <!-- ERROR! Previous list items are not in a list! -->
+          </ul>
+        
+
+
+
+

Browser and Assistive Technology Support

+

+ This guide illustrates appropriate use of ARIA 1.1 as defined in the ARIA specification. + The design patterns, reference examples, and sample code intentionally do not implement code that fixes problems caused by gaps in support for ARIA 1.1 in browsers or assistive technologies. + This approach enables both browser and assistive technology developers to utilize code in the guide as references for test cases to assess the quality of their support for ARIA 1.1. +

+

+ Similarly, JavaScript and CSS in this guide is written to be compatible with the most recent version of Chrome, Firefox, Internet Explorer, and Safari at the time of writing. + In particular, some JavaScript and CSS may not function correctly in Internet Explorer version 10 or earlier. +

+

+ In other words, except in cases where the ARIA Working Group and other contributors have overlooked an error, + examples that do not function well in a particular browser or with a specific assistive technology are demonstrating a lack of ARIA support and can be referenced in a bug report to its developer. +

+
+
+

Mobile and Touch Support

+

+ Currently, this guide does not indicate which examples are compatible with mobile browsers or touch interfaces. + While some of the examples include specific features that enhance mobile and touch support, some ARIA features are not supported in any mobile browser. + In addition, there is not yet a standardized approach for providing touch interactions that work across mobile browsers. +

+

More guidance about touch and mobile support is planned for future releases of the guide.

+
+
+

Design Patterns and Widgets

This section demonstrates how to make common rich internet application widgets and patterns accessible by applying WAI-ARIA roles, states, and properties and implementing keyboard support.