Html5 aria-css-ibm-csun-2016

Modern Web Accessibility with WAI-ARIA, HTML5 & CSS

Maureen Kraft, Accessibility Superhero

Charu Pandhi, Lead Accessibility Consultant

Rich Schwerdtfeger, CTO Accessibility

March 25, 2016

© 2016 IBM Corporation

Introduction

Session goals: What is new in HTML5 from accessibility perspective

How to correctly implement HTML5 and WAI-ARIA

Implied WAI-ARIA semantics overlap

HTML5 sections provide structural navigation.

ARIA CSS toggle selectors

HTML5 Canvas element with SVG

Preview of ARIA 1.1.

Current browser and assistive technology support.

2

© 2016 IBM Corporation

“Accessibility is hard”

3

Photo licensed through Shutterstock. Image ID: 96007034 Copyright: 6kor3dos

© 2016 IBM Corporation

Notes: Accessibility is hard

• “Accessibility is hard.” We hear this statement often from development

teams who wait until the 11th hour to add accessibility support to their

web application.

• Accessibility is only hard when one waits and tries to retrofit or patch their

application the night before a release. The developer takes one look at

the Web Content Accessibility Guidelines and is overwhelmed.

• Recently, a colleague told me how easy it was to add ARIA markup to his

web application to expose it to assistive technologies. He got it.

• Standards including Web Accessibility Initiative Accessible Rich Internet

Applications (WAI-ARIA), HTML5 and CSS make it easy for developers

to incorporate support for accessibility within their development

environment.

4

© 2016 IBM Corporation

ARIA can make it easy

5

© 2016 IBM Corporation

Notes: ARIA can make it easy

• By considering ARIA from the get go, we can provide a stable accessible

solution that does not have to be retrofitted. There is a slight up front cost

to ensure you solution is complete but the payoff is great.

• Building accessibility into a solution from the get go reduces costs and

opens solution to the widest possible audience, allows sales to

government agencies, academia and private institutions that require

support for their employees and customers with disabilities.

• ARIA bridges the gap.

• Carrick-a-Rede Rope Bridge in Northern Ireland. License by Creative

Commons. Photo courtesy of Nuff Cumptin, Flickr.

6

© 2016 IBM Corporation

WAI-ARIA, HTML5 and CSS

Introduction

7

© 2016 IBM Corporation

Transition from HTML4 to WAI-ARIA and HTML5

8

© 2016 IBM Corporation

Notes: Transition from HTML4 to WAI-ARIA and HTML5

• As web pages become more and more complex with dynamic content

and advanced user interface controls developed with Ajax, HTML,

JavaScript, and related technologies, these user interface controls and

content updates are often not accessible to users with disabilities,

especially screen reader users and users who cannot use a mouse or

other pointing device.

9

© 2016 IBM Corporation

Client PendulumThin Client

Network Application Model

• Multi-tier server model

• Central Management &

Deployment

• Large reach – multi-

client (browsers), server

(J2EE, Web Svc)

• Rich, native, clients no

longer the norm

Fat ClientClient Server

• Pure browser strategy

no longer sufficient

• Customers increasingly

asking to go beyond the

browser

Common

BrowserRich Browser

Supplemented

Browser

Managed Local

Web

Application

Managed

Native

Application

Native

Application

Richness & Function

Improved Manageability & Deployment

• Giga: “Companies turning back somewhat to rich clients, disconnected model”

• Gartner: “Growing trend back from thin clients to something in the middle – smart

client, fit client, HiFi client”

10

© 2016 IBM Corporation

Notes: Client Pendulum

11

Some history of the ARIA story:

• Back in the early 2000’s customers wanted to get something that was

richer. And as you can see here, they would go all the way to switching

back to what we call a fat client solution or a native client application

solution.

• We had an opportunity to do DHTML work, but it was still in its very

earlier stages.

© 2016 IBM Corporation

Problem Analysis shows for richer accessibility

12

HTML Accessibility depends on tag names (mixing content and presentation)

JavaScript creates custom widgets using HTML, user input, and CSS changing their meaning and purpose within a Web application

HTML lacked the accessibility meta data to support accessibility APIs for repurposed HTML content

Keyboard usability for PWDs is poor

Almost totally dependent on tabbing

Non anchors/form elements can’t receive focus (W3C HTML browser implementation oversight)

Users needs keyboard navigation and widget behavior like a GUI

User needs consistent navigation landmark semantics to reduce usability problem

© 2016 IBM Corporation

Notes: Problem Analysis shows for richer accessibility

13

• There's a couple of things about the Document Object Model and desktop accessibility that are really

important. Both platforms have a tree structure, and the reason they have it is so that they can propagate

mouse and keyboard events.

• The second thing is this tree structure enables you to have context. So when you have a list box, you'll know

whether things within the list box are options and how many you actually have. This is one of the things that

you get from the DOM.

• The other thing is the accessibility tree only exposes semantics provided by HTML, but in desktop platforms,

we had an API that allowed the author to create an accessibility tree that shadowed the object tree in the GUI

components and had an API for exposing all the necessary semantics. And the problem you had -- again, -- is

there was no way for HTML to actually expose the accessibility semantics. And so the problem was in

JavaScript it wasn't CSS. The problem had to do with HTML itself.

• In the accessibility API, we can expose all the information you need through an API in each of the different

platforms, and this is where you get with the role, state, and properties that you experience.

• On this slide: Picture of the flow of Browser map to DOM/Accessibility API. The first node is the AT (Assistive

Technology) It has a double arrow to Role, states, actions, caret selection, text, hypertext, value, name,

description, children and relationships that form the Contract node. The Document element feeds into this

contract node and data and the UI (user interface) feed into the Document element. Below the Document

element is JavaScript which is the controller. JavaScript manipulates the data (DOM), the content, the style

(UI) and drives events. This produces custom widgets.

© 2016 IBM Corporation

DHTML Accessibility

Fixing the “JavaScript Accessibility Problem”

14

© 2016 IBM Corporation

What is WAI-ARIA?

“Web Accessibility Initiative Accessible Rich Internet Applications

(WAI-ARIA), is a technical specification that defines a way to make

Web content and Web applications more accessible to people with

disabilities.”

W3C Recommendation – 3/20/2014

WAI-ARIA provides attributes for extending HTML markup with

roles, states and properties to expose Web applications to

Assistive Technologies (AT).

15

© 2016 IBM Corporation

WAI-ARIA – In 5 steps

1. Alert users to what each element or widget is: with element’s role

(such as a menu or a tree).

2. Alert the user to each element properties and important

relationships ( such as “aria-haspopup”, “aria-describedby” and

other labels)

3. Alert the user to what each element is doing: the elements state

(such as “aria-expanded” or “aria-disabled”)

4. Alert users to any changes in the element’s state.

5. Make sure the widget is keyboard accessible and the focus is

predictable.

ARIA 1.0 Authoring Practices

16

© 2016 IBM Corporation

Notes: WAI-ARIA – In 5 steps

• The WAI-ARIA Authoring Practices is an implementation Guide intended to

provide readers with an understanding of how to use WAI-ARIA to create an

accessible Rich Internet Application.

• This guide begins by providing some general steps for building an accessible

widget using WAI-ARIA, script, and CSS. It then extends your knowledge of

WAI-ARIA with detailed guidance on how to make rich internet applications

keyboard accessible and addressing necessary layout and structural semantics

within the Web page.

Notes on keyboard and focus:

• Interactive controls should receive focus through the keyboard.

• Events can be triggered through the keyboard.

• How to trigger events should be intuitive to the user.

17

© 2016 IBM Corporation

Example - Slider

<div class="clearfix">

<span id="sliderLabel" class="floatLeft">Volume:</span>

<div id="sliderRail1" class="sliderRail floatLeft">

<button class="sliderThumb" id="sliderThumb1" role="slider"

aria-labelledby="sliderLabel" aria-valuemin="0" aria-

valuemax="100" aria-valuenow="0" aria-

valuetext="0%"></button>

</div>

<span id="sliderValue1"class="floatLeft">0%</span>

</div>

18

© 2016 IBM Corporation

WAI-ARIA use - General rules

• First rule: Use a native HTML element or attribute when you can

• Second rule: Do not change native semantics, unless you really must.

• Third rule: All interactive elements must have accessible name, role, state

and properties as applicable.

• Fourth rule: All interactive ARIA controls must be usable with the

keyboard.

• Fifth rule: Do not use role="presentation" or aria-hidden="true" on a visible

focusable element.

19

© 2016 IBM Corporation

Notes: WAI-ARIA use - General rules

• The WAI-ARIA specification is primarily for developers creating custom widgets and other rich internet web

applications developed with Ajax, HTML, JavaScript, and related technologies. One should always remember, WAI-

ARIA is intended to be used as a supplement for native language semantics, not a replacement and follow some

basic guidelines when using WAI-ARIA.

• Ask the question, can I use a native HTML element or attribute? Then do so as it has the required semantics

and behavior already built in?

• Instead of re-purposing an element with style and script or by adding an ARIA role on a div when the host language

provides a semantic element for that type of object.

• For examples, it is better to use an h1 element in HTML than to use the heading role on a div element. (Karl Groves

has a great blog on why this is not recommended.)

• Do not change native semantics, unless you really must. There are some exceptions to the rule. When WAI-ARIA

can do more than HTML and is semantically richer, you should use it. For example, it is better to use aria-label

instead of an off-screen or hidden label used only by Assistive Technology.

• When using WAI-ARIA it is the author’s responsibility to provide proper layout and structural semantics such as

name, role, state and properties as applicable and to implement proper relationship and keyboard accessibility so all

interactive elements are accessible.

• W3C has developed a practical guide for developers titled Using WAI-ARIA in HTML on how to add accessibility

information to HTML elements using the Accessible Rich Internet Applications specification that elaborates on the

rules listed above with details and examples.

20

© 2016 IBM Corporation

CSS

ARIA Toggle Selectors

21

© 2016 IBM Corporation

Cascading Style Sheets (CSS)

Stylesheet language that describes the presentation of an

HTML (or XML) document.

Allows separation of presentation from an application’s

logic

Complement WAI-ARIA by offering a set of selectors that

provide different styling depending upon WAI-ARIA states.

CSS selectors are patterns used to select the element(s)

you want to style.

[attribute^=value] a[href^="https"]

Selects every <a> element

whose href attribute value

begins with "https"

22

© 2016 IBM Corporation

Notes: Cascading Style Sheets (CSS)

• Cascading Style Sheets (CSS) have become very dynamic in recent years allowing

the separation of presentation from an application’s logic.

• They further complement WAI-ARIA by offering a set of selectors that provide

different styling depending upon WAI-ARIA states.

23

© 2016 IBM Corporation

ARIA CSS toggle selector example

[attribute=value] - select element whose attribute is set to the given value.

li[aria-selected='true'] {

color: black;

background-color: #fff;

border-bottom: 1px solid white;

}

<ul class="tablist" role="tablist">

<li id="tab1" class="tab" aria-controls="panel1" aria-selected="true"

role="tab">Prices</li>

<li id="tab2" class="tab" aria-controls="panel2" role="tab" aria-

selected="false">Features </li>

</ul>24

© 2016 IBM Corporation

Notes: ARIA CSS toggle selector example

• In jQuery or JavaScript change attribute to true or false and the CSS styling

will automatically toggle.

• The screen shot shows two tab panels, Prices and Features. The Prices tab

is selected and the styling changes based off aria-selected=true to give the

tab a white background and a solid white underline.

25

© 2016 IBM Corporation

Modern Web accessibility

See it working with HTML5, ARIA and CSS

26

© 2016 IBM Corporation

What is HTML5?

5th major revision of the core language of the World

Wide Web.

Recommendation of W3C – 10/28/2014.

WAI-ARIA is included in HTML5 making it part of

normative language.

Implicit ARIA semantics.

For example:

HTML <button> element, has an implied ARIA role of

button.

27

© 2016 IBM Corporation

Accessibility support in HTML5

New HTML5 elements that improve accessibility fall in the following

categories:

Semantic/Structural Elements offer better document structure.

Form Elements and form input types for interactive controls

Built-in media support with the Audio and Video Elements

HTML5 Canvas element for complex graphics.

28

© 2016 IBM Corporation

HTML5 Semantic/Structural Elements and the implied WAI ARIA semantic it defaults to:

HTML5 Implied ARIA role

<header> role="banner"

<nav> role="navigation"

<main> role="main"

<footer> role="contentinfo"

<aside> role="complementary"

<article> role=“article"

<section> role=“region”

Code Example:

<!-- other content -->

<main role=“main”>

Main content ….

</main>

29

© 2016 IBM Corporation

Notes: HTML5 Semantic/Structural Elements

• New Semantic/Structural Elements in HTML5 offer better document structure and are easy to

implement.

• On this slide we see the new HTML5 structural elements listed along with the implied ARIA role.

• Some consideration to keep in mind when implementing the structural elements is the hierarchy and

the content it represents.

• For example, the main element represents the main content of the body of a document or application.

• Authors must not include the main element as a descendant of an article, aside, footer, header or nav

element.

• The main element is not suitable for use to identify the main content areas of sub sections of a

document or application.

• Authors are advised to use ARIA role="main" attribute on the main element until user agents fully

support the new standard and implement the required role mapping.

30

© 2016 IBM Corporation

New HTML5 Form Input types

The input element's type attribute now has the following new values that

allow better input control and validation

tel

search

url

email

date

time

number

range

color

Code example:<form>

Quantity (between 1 and 5):<input type="number"

name="quantity" min="1" max="5"></form>

31

© 2016 IBM Corporation

Notes: New HTML5 Form Input types

• We all know the most important form element is the <input> element.

• The type attribute of the input element can now take new values as shown in the

slide. With these new types the user agent can easily provide the user interface

such as a calendar date picker or integration with the user's address book with a

defined format to submit to the server. It gives the user a better experience as his

input is checked before sending it to the server meaning there is less time to wait for

feedback.

• Note: Browsers provide validation and error messages for these new input types.

For example, the screen shot above is from Chrome and shows that an invalid input

value of 8 was entered into the Quantity field. Note: error messages can be

overridden through the JavaScript constraint validation API,

http://www.w3schools.com/js/js_validation_api.asp.

32

© 2016 IBM Corporation

New HTML5 Media Elements

Multimedia on the web includes sound, music, videos, movies, and animations.

The HTML <video> Element used for playing videos or movies, and audio files with captions.<video width="320" height="240" controls>

<source src="movie.mp4" type="video/mp4"><track src="subtitles_en.vtt" kind="subtitles" srclang="en"

label="English">

Your browser does not support the video tag.</video>

Captions can be provided, either embedded in the video stream or as external files using the track element.

The HTML <audio> Element represents a sound or audio stream.<audio controls>

<source src="horse.ogg" type="audio/ogg">

Your browser does not support the video tag.yes</audio>

33

© 2016 IBM Corporation

Notes: New HTML5 Media Elements

• Before HTML5 there was no standard for showing videos on a web page, videos

could only be played with a plug-in (like flash).

• HTML5 introduces built-in media support via the <audio> and <video> elements,

offering the ability to easily embed media into HTML documents with a variety of

features available to make the video content accessible.

• Multiple <source> elements can link to different video files.

• The <track> element is used to specify subtitles, caption files or files containing text

that should be visible when the media is playing.

• The controls attribute adds audio and video controls, like play, pause, and volume

34

© 2016 IBM Corporation

New HTML5 Graphic Element

HTML 5 <canvas> - draws 2D graphics, on the fly (with JavaScript) and how it

compares to the open standard, Scalable Vector graphic (SVG)

35

© 2016 IBM Corporation

Notes: New HTML5 Graphic Element

• SVG is a language for describing 2D graphics in XML.

• Canvas draws 2D graphics, on the fly (with a JavaScript).

• SVG is XML based, which means that every element is available within the SVG

DOM. You can attach JavaScript event handlers for an element.

• In SVG, each drawn shape is remembered as an object. If attributes of an SVG

object are changed, the browser can automatically re-render the shape.

• Canvas is rendered pixel by pixel. In canvas, once the graphic is drawn, it is

forgotten by the browser. If its position should be changed, the entire scene needs to

be redrawn, including any objects that might have been covered by the graphic.

36

© 2016 IBM Corporation

HTML5 Accessibility

Browser support and Implied Semantics

37

© 2016 IBM Corporation

HTML5 Accessibility and Browser Support

Browsers and Assistive technology support and limitations

• Some browsers don’t fully support HTML5, but most support ARIA, what do you do?

• The answer is: Use both.

The HTML5 Accessibility page is a great resource where you can find out which browsers

support which parts of HTML5.

20

© 2016 IBM Corporation

Notes: HTML5 Accessibility and Browser Support

• While there’s cool stuff for accessibility in HTML5 not all of HTML5 is set in stone yet, these techniques

are not yet supported in every browser. The browsers have started implementing parts of it but even

when the newest version of a browser supports something, the older versions of that browser won’t be

updated to support it, and some people will continue to use these older browsers.

• So, if some browsers don’t support HTML5, but most support ARIA, what do you do?

The answer is: Use both.

HTML5 Accessibility website gives us the latest support provided by major browsers for HTML5

accessibility:

• Chrome - 94.5%

• Firefox - 91 %

• Safari - 68%

• IE - 37%

• Edge - unknown

39

© 2016 IBM Corporation

Implicit ARIA semantic and restrictions

Rule: The WAI ARIA semantic should meet the implicit ARIA semantic restriction(s)

for the element.

Implied ARIA role for the “aside” element is role=“complementary.”

<aside role=“complimentary”>About the editor, Max Perkins: Editor of

Genius(1978),…… </aside>

Code correctly overrides the “aside” element’s implicit semantic (role=”complementary”)

by using the ARIA role of “note” to designate the notated content on the page.

<aside role="note">About the editor, Max Perkins: Editor of

Genius(1978),…… </aside>

Code triggers this rule's error message because the ARIA role of “main” is used to

override the implicit semantic for the “aside” element, The “main” role does not meet the

restrictions listed for the element

<aside role="main">Complementary content for the page</aside>

21

© 2016 IBM Corporation

Notes: Implicit ARIA semantic and restrictions

• Some HTML language features (i.e., element or attribute) have native semantics

that map by default to an implied WAI ARIA semantic. It is possible to override

implicit semantic under restricted conditions. Fortunately we have a DAP rule that

verifies the adherence to those restrictions.

• HTML5 Vocabulary provides a table of all the Implicit ARIA semantic and

appropriate overrides of implicit roles, http://www.w3.org/TR/html5/dom.html#sec-

implicit-aria-semantics.

• Note: The rule does not apply to any element in the table that has a role of

“presentation”

41

© 2016 IBM Corporation

Conflicting use of the associated WAI-ARIA attribute with HTML5 attribute

Avoid conflicting use of the associated WAI-ARIA attribute with HTML5 attribute on any one input

element

html 5 <required> attribute implies WAI-ARIA required attribute

html5 <autocomplete> attribute implies WAI-ARIA autocomplete attribute

html5 <readonly> attribute implies WAI-ARIA readonly attribute

html5 <disabled> attribute implies WAI-ARIA disabled attribute

Correct use of the HTML5 “required” attribute on the INPUT element

<label for="phone">* Phone number: </label>

<input type="text" id="phone" name="phone" required aria-required=“true">

use of aria-required=”false” (indicating the field is not required) on the same INPUT element

overrides the fields input requirement creating a conflict

<label for="phone">* Phone number: </label>

<input type="text" id="phone" name="phone" required aria-required="false">

42

© 2016 IBM Corporation

Notes: Conflicting use of the associated WAI-ARIA attribute with HTML5 attribute

• Listed on this slide are the HTML5 attributes that are used during field input. They

each have a similar purpose as the WAI-ARIA counterpart.

• In order to avoid any conflict between these attributes, it is important to make sure

the HTML5 attribute and the associated WAI-ARIA attribute are used with care not

creating any override or conflict with each other.

• For example, the presence of the HTML5 “required” attribute defaults to true and

indicates the element is required and it is OK to use aria-required=”true”, but the

use of aria-required=”false” (indicating the field is not required) on the same INPUT

element overrides the fields input requirement creating a conflict.

43

© 2016 IBM Corporation

Accessibility of the Canvas Element

Canvas exposed as an image element.

<canvas id="example" width="260" height="200" role="img" alt=”Circles”

ariadescribedby="img1"></canvas><div id="img1"> <p>The prose in this

div describes the circles in detail</p></div>

Canvas exposed as a button element

<canvas id="roundButton" width="50" height="50" onmousedown="..."

onmouseup="..." onclick="..." onkeydown="..." onkeyup="..."> <div

tabindex="0" role="button">ok</div> </canvas>

22

© 2016 IBM Corporation

Notes: Accessibility of the Canvas Element• For a canvas element with a simple drawing the author must provide a role=”img” on the canvas element with a

label and a description (aria-describedby=”foo” ) if label is not sufficient to make the drawing accessible.

• The first example on the slide shows the use of the canvas element with circles drawn and exposed as an image

with a WAI-ARIA role attribute, label and a description within the canvas tags, information that an assistive

technology will announce to the end user making it accessible.

• When the canvas drawing is more complex such as a static chart, or an interactive drawing such as in example 2 on

this slide, in order to provide meaningful information either an alternative accessible rendering must be provided or

the author must make use of canvas fallback (between the canvas tags). Fallback content is a semantic

representation of what is rendered on the physical canvas and must convey the same function or purpose as the

bitmap canvas. Semantically important objects drawn on the physical canvas, using the Cavnas 2D Context APIs,

must have a one to one mapping to elements in canvas fallback. Fallback content elements are used to expose the

accessibility semantics to the browser which then maps this information to assistive technologies similar to the way

that native HTML elements do. Canvas fallback content is included in the in the tab sequence like the directly visible

HTML elements. Fallback content must be keyboard accessible and therefor must have an associated visible focus

indicator when focused. Fallback content must also be made semantically accessible using WAI-ARIA or HTML5

element host language semantics.

• The first example shows the use of the canvas element with circles drawn and exposed as an image with a WAI-

ARIA role attribute, label and a description within the canvas tags that an assistive technology will announce to the

end user making it accessible.

• The second example shows an interactive canvas with equivalent accessible information provided in the canvas

fallback content. The keyboard equivalent would be applied to the corresponding fallback elements.

45

© 2016 IBM Corporation

Coming soon: HTML5.1, ARIA 1.1 and SVG2

What’s new?

46

© 2016 IBM Corporation

HTML5.1- 2016

HTML 5.1 introduced new elements, attributes, and features,

extending HTML 5.0 with the new API calls and methods.

With the standardization of the HTML5 specification, the core

vocabulary and features are being extended in few different ways:

• Specifications removed and to be standardized separately such

as SVG, Microdata and the Canvas

• Upcoming specifications such as HTML5.1 and HTML 5.2

HTML 5.1 is expected to be finalized in 2016, and it is currently on

the standardization track at the W3C

47

© 2016 IBM Corporation

WAI-ARIA 1.1 - 2016

• Leverage Native Host language Semantics

• Enhanced Table and Grid Support

• Feeds (like Facebook and Twitter): role=“feed”

• Error message support: aria-errormessage

• Role Descriptions: aria-roledescription

• Properties: aria-placeholder, aria-current, aria-keyshortcuts, aria-modal,

aria-readonly, aria-details, aria-current (via URI)

• Roles: switch, none, figure, searchbox

• Role definition changes (region to landmark, application to non-landmark)

• General Cleanup, expanded use of ARIA features

Applies to HTML5.1 and SVG 2

Additional Modules for Digital Publishing and Graphics

48

© 2016 IBM Corporation

Notes: WAI-ARIA 1.1 - 2016

• Continues to leverages native host language semantics. See Section 7

Implementation in Host Languages in ARIA 1.1 specifications,

http://www.w3.org/TR/wai-aria-1.1/#host_languages

• Enhanced table and grid support includes properties for aria-colcount, aria-rowcount,

aria-colindex, aria-rowindex, aria-colspan, and aria-rowspan as well as cell and table

roles for non-interactive tables.

• Aria-errormessage allows you to point to an element that holds the error message.

• Aria-roledescription allows for human understandable text to describe generic

elements such as regions and sections. As well let’s you define more information

about elements, eg. a button is used to attach a file, aria-

roledescription=“attachment”

• New properties: aria-placeholder, aria-current, aria-kbdshortcuts, aria-modal,

aria-readonly, aria-describedat

• New roles: switch (on/off), none (presentation), figure, searchbox, feed

49

© 2016 IBM Corporation

Open Web Accessibility Semantic Interoperability and Convergence

50

© 2016 IBM Corporation

Notes: Open Web Accessibility Semantic Interoperability and Convergence

51

• Declarative markup of host languages and ARIA results in overall 20% less

enablement work than native desktop applications

• This slide contains a picture showing the flow of Open Web Accessibility Semantic

Interoperability and Convergence: At the base we have Assistive Technology that

taps into the Application Platform Accessibility APIs in iOS, Windows, Mac OSX,

Linux and Android.

• At the Core we have WAI-ARIA which allows for name, role, states and properties

that map back to the accessibility APIs. HTML5 and HTML5.1 provide implied ARIA

semantics and further map to the Accessibility APIs of the platform.

• SVG2 furthers this mapping for Scalable Vector Graphics.

• These all represent Open Web Standards that are supported by the User

Agent/Browser.

• And these standards have been adopted by reusable components such as RAVE,

D3, Dojo and jQuery UI. This flow also shows additional ARIA modules, ARIA ePub,

Structure semantics and ARIA Graphics.

© 2016 IBM Corporation

Web Accessibility Standards Work

Write once, accessible on all platforms

HTML Canvas 2D Context 1.0 – Recently Completed

Targeted for completion 2016 in next 1-2 years

– WAI-ARIA 1.1, ARIA Graphics Module, ARIA Digital Publishing Module

– HTML 5.1

– SVG 2.0 (Keyboard, ARIA and browser accessibility services support)

– User Agent Accessibility Mapping Specifications

Beyond 2016

– WAI-ARIA 2.0 (Extensible accessibility, less code, etc.)

– WAI-ARIA Cognitive Accessibility and WCAG extensions for Cognitive

– New User Context and Device Independence work (Browser APIs and CSS Media

queries)

– SVG directional keyboard accessibility and richer accessibility semantics

52

© 2016 IBM Corporation

Automation

• Automated Accessibility Tester and/or Digital Content

Checker services on IBM Bluemix provide services to

analyze your HTML and WAI-ARIA markup.

• Visit www.ibm.com/able for more info.

53

© 2016 IBM Corporation

References

Accessible Rich Internet Applications (WAI-ARIA) 1.0, W3C Recommendation, 20 March

2014.

ARIA 1.0 Authoring Practices

HTML5: A vocabulary and associated APIs for HTML and XHTML, W3C

Recommendation, 28 October 2014.

HTML5 Accessibility, The Paciello Group.

HTML5 Vocabulary: Implicit ARIA Semantics, W3C, October 2014.

ARIA 1.1 , W3C Working draft.

HTML5.1, W3C Working draft.

IBM Accessibility BlueMix Services

54

© 2016 IBM Corporation

Examples and Code samples

A Basic ARIA Slider, Paciello Group.

ARIA Tab Panel Example, Athena ICT.

Tooltip: ARIA CSS selectors, Open Ajax Alliance.

Menubar: ARIA CSS selectors, Open Ajax Alliance.

55

© 2016 IBM Corporation

Thank you!

Maureen Kraft, IBM [email protected]

Charu [email protected]

Rich Scwerdtfeger, CTO Accessibility [email protected]

For more information about IBM Accessibility visit: www.ibm.com/able and age&ability.com

Facebook group:

IBM Accessibility

LinkedIn group:

IBM Accessibility@IBMAccess