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

“Accessibility is hard”
3
Photo licensed through Shutterstock. Image ID: 96007034 Copyright: 6kor3dos

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

ARIA can make it easy
5

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

WAI-ARIA, HTML5 and CSS
Introduction
7

Transition from HTML4 to WAI-ARIA and HTML5
8

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

Client Pendulum
Thin 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 Client
Client Server
• Pure browser strategy
no longer sufficient
• Customers increasingly
asking to go beyond the
browser
Common
Browser
Rich 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

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.

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

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.

DHTML Accessibility
Fixing the “JavaScript Accessibility Problem”
14

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

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

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

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

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

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

CSS
ARIA Toggle Selectors
21

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

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

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

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

Modern Web accessibility
See it working with HTML5, ARIA and CSS
26

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

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

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:

<main role=“main”>
Main content ….
</main>
29

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

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

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

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

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

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

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

HTML5 Accessibility
Browser support and Implied Semantics
37

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

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

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

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

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

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

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

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

Coming soon: HTML5.1, ARIA 1.1 and SVG2
What’s new?
46

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

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

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

Open Web Accessibility Semantic Interoperability and Convergence
50

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.

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

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

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

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

Thank you!
Maureen Kraft, IBM Accessibility
maureen_kraft@us.ibm.com
Charu Pandhi
cpandhi@us.ibm.com
Rich Scwerdtfeger, CTO Accessibility IBM
schwer@us.ibm.com
For more information about IBM Accessibility visit:
www.ibm.com/able and age&ability.com
Facebook group:
IBM Accessibility
LinkedIn group:
IBM Accessibility
@IBMAccess

Html5 aria-css-ibm-csun-2016

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Html5 aria-css-ibm-csun-2016

Similar to Html5 aria-css-ibm-csun-2016 (20)

Recently uploaded

Recently uploaded (20)

Html5 aria-css-ibm-csun-2016