Tutorial Mockup ARIA Concepts

(Background) Another alternative approach to proposed ARIA tutorial/guide

This mock-up (expanded outline with details) shows an alternative approach to a tutorial (or overview or guide) on ARIA concepts. It includes:
- a few examples of how to apply those concepts to a few examples, and
- a welcome mat for the ARIA Authoring Practices Guide.
Key changes since the original outline include relabeling this as a Conceptual Tutorial; then adding detail on concepts to be covered.
- This is taking a different approach than some suggested such as to do a standalone ARIA tutorial that goes into more variety about tutorials.
- Instead, this goes into more detail about ARIA concepts to better illustrate the original approach.
Purpose of this approach:
- Introduce developers to ARIA concepts, and to the ARIA Authoring Practices Guide, with a focus on appropriate use of ARIA;
- Technical review would be requested of the ARIA WG and/or ARIA Authoring Practices Task Force
Current Status:
- This is a draft outline, subject to change, and has not yet been reviewed by EOWG.
- Input welcome.

This tutorial uses the process of creating a custom checkbox to demonstrate three fundamental concepts every developer must understand to effectively and safely apply ARIA. It teaches:
- Purpose: What ARIA does
- Limits: What ARIA does not do
- Risks: Why appropriate use is important

ARIA is the developer telling the browser what to tell the assistive technology about what the developer has done;
- in order that a screen reader user can reliably know what feature is present, and to be able to operate it (perceive what it is, understand what it means, and operate on it)
- if you use any role, the developer is telling the AT via browser that they have provided keyboard support.

Using ARIA the wrong way can make accessibility worse;
[Matt can you clarify the following] something about input with type number (spin box) or simpler (check box));
If you give a check box a role, but don't provide keyboard support, then you’ve essentially said that you’ve made a checkbox but not given it any functionality.
Or if you do role="presentation", or role="search" on a button that does search, then that can’t be operated by someone who is a screen reader user [Matt please check]
Or if you put ARIA hidden on it, then it hides all of its children, it's no longer accessible.

HTML gives you a checkbox
- It looks like a checkbox
- HTML can be fully accessible
- For instance, if you start with an Accessible HTML Checkbox:

 <label><input type="checkbox"> Yes I agree to the above terms.</label>

It is accessible:
- Screen readers and other assistive technologies know the element is a checkbox because browsers automatically tell assistive technologies about the accessibility role of HTML inputs by mapping the type attribute into their accessibility APIs.
- Screen readers and other assistive technologies can communicate the checked or unchecked state because browsers automatically tell assistive technologies about the accessibility states and properties of HTML inputs by mapping the value of the checked attribute into their accessibility APIs.
- It has an accessible name provided by the label element.
- It is focusable with the keyboard because browsers automatically make HTML input elements focusable and includes them in the tab sequence.
- It is operable with the keyboard because browsers automatically provide keyboard operability appropriate for each input type. For checkboxes, the space bar toggles the state.
Now let's say you need a custom checkbox, because designers have asked you to do a combination of tasks that require that you have to replace the HTML input with a custom element. Now, your HTML looks like this.

Yes I agree to the above terms.

ARIA is another way to make things accessible, but it comes with responsibilities.
- Doing so will require more than just ARIA; it will require JavaScript as well.
To make it functional
- Give it keyboard support (for operability)
- Give it a role (for understandability)
- Give it state(s) (for perception and operability)
Let's look at a relevant example from the ARIA Authoring Practices Guide
- Bear in mind that as a developer, you need to be thinking in roles, states and properties
  - And about these other things too @@@@, @@

Explain purpose of role.
Explain what it does.
Show adding role.
Talk about what it does not solve.
- At this point, the ARIA is telling a lie! It this div is a checkbox, but it really is not because it does not yet behave like a checkbox.
ARIA does not change browser behavior. Adding the role only tells ....
- What ARIA states and properties do
Show adding checked state and talk about what that does and does not do.
- Keyboard Operability
Talk about completing picture by adding tabindex and js for operability.
- Essential concepts
Review the essential concepts that have been demonstrated and how they are demonstrated.
- Risks
Show examples of how misuse totally breaks things.
- What Else Can ARIA DO
Talk about tri-state checkbox and other custom widgets not possible without ARIA.
- Let's add another level of complexity: create a tri-state checkbox
  - [Mini-example Tri-State Checkbox]