HTML5 and Accessibility

[Logo - HTML5]

HTML5 AND ACCESSIBILITY

What Is Web Accessibility?

There are 4 basic types of impairment that can negatively impact users on the web:

So What Do We Need?

POUR it on

Perceivable

Information and user interface components must be presentable to users in ways they can perceive.

Perceivable
  • 1.1 Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
  • 1.2 Provide alternatives for time-based media.
  • 1.3 Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
  • 1.4 Make it easier for users to see and hear content including separating foreground from background.

So What Do We Need?

POUR it on

Operable

User interface components and navigation must be operable.

Operable
  • 2.1 Make all functionality available from a keyboard.
  • 2.2 Provide users enough time to read and use content.
  • 2.3 Do not design content in a way that is known to cause seizures.
  • 2.4 Provide ways to help users navigate, find content, and determine where they are.

So What Do We Need?

POUR it on

Understandable

Information and the operation of user interface must be understandable.

Understandable
  • 3.1 Make text content readable and understandable.
  • 3.2 Make Web pages appear and operate in predictable ways.
  • 3.3 Help users avoid and correct mistakes.

So What Do We Need?

POUR it on

Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Robust
  • 4.1 Maximize compatibility with current and future user agents, including assistive technologies.

Accessibility APIs

To provide access to desktop GUI applications, assistive technologies originally used heuristic techniques to determine the meaning of the user interface and built an alternative off screen model. For example, a row of labels displayed horizontally near the top of an application window might be a menu. Labels with a border drawn around them might be buttons. Heuristic techniques are not always accurate, however, and require assistive technologies to be updated whenever the software application is updated.

A much better technique is for the software application to provide the necessary information for interoperability with assistive technology. To meet this need, platform owners have developed specialized interfaces, called accessibility APIs, which can be used to communicate accessibility information about user interfaces to assistive technologies.

In the case of static Web pages, the Document Object Model (DOM) is used to represent the structure and state of the elements in the document being rendered by a user agent. The elements of the document are organized into a hierarchy of nodes known as the DOM tree. For traditional static Web pages, assistive technologies, such as screen readers, interact with user agents using the DOM. For UI elements that are known to be interactive, such as HTML form elements and desktop applications, assistive technologies may use platform accessibility APIs.

http://www.paciellogroup.com/blog/2011/06/aviewer-beta-updated/

ARIA

Accessible Rich Internet Application

The Web Accessibility Initiative Accessible Rich Internet Applications (WAI-ARIA) Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, Dynamic HTML, JavaScript, Cascading Style Sheets, and related technologies. Currently, certain functionality used in Web sites inaccessible to some users with disabilities, especially people who rely on screen readers and people who cannot use a mouse. WAI-ARIA addresses these accessibility challenges by defining new ways for functionality to be provided to assistive technology. Desktop operating systems have long provided APIs to allow assistive technology products to access applications, by exposing the role of a control along with its states, properties, and values. WAI-ARIA allows web application developers to expose the same sorts of information for Web applications. This information is used by user agents to support the same accessibility APIs as used by desktop applications allowing authors to provide accessibility information consistent with their intent. With WAI-ARIA, developers can make advanced Web applications accessible and usable to people with disabilities.

ARIA The Roles Model

Landmark Roles: Where am I?

<div role="XXX"> </div>

screen reader logosLandmark roles are currently supported In JAWS version 10 screen reader, NVDA 2010.1+ and VoiceOver on iPhone IOS4.

application - http://www.w3.org/TR/wai-aria/roles#application

A region declared as a web application, as opposed to a web document.

When the user navigates an element assigned the role of application, assistive technologies that typically intercept standard keyboard events SHOULD switch to an application browsing mode, and pass keyboard events through to the web application. The intent is to hint to certain assistive technologies to switch from normal browsing mode into a mode more appropriate for interacting with a web application; some user agents have a browse navigation mode where keys, such as up and down arrows, are used to browse the document, and this native behavior prevents the use of these keys by a web application.

banner - http://www.w3.org/TR/wai-aria/roles#banner

A region that contains mostly site-oriented content, rather than page-specific content.

Site-oriented content typically includes things such as the logo or identity of the site sponsor, and site-specific search tool. A banner usually appears at the top of the page and typically spans the full width.

complementary - http://www.w3.org/TR/wai-aria/roles#complementary

A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content.

There are various types of content that would appropriately have this role. For example, in the case of a portal, this may include but not be limited to show times, current weather, related articles, or stocks to watch. The complementary role indicates that contained content is relevant to the main content. If the complementary content is completely separable main content, it may be appropriate to use a more general role.

contentinfo - http://www.w3.org/TR/wai-aria/roles#contentinfo

A large perceivable region that contains information about the parent document.

Examples of information included in this region of the page are copyrights and links to privacy statements.

form - http://www.w3.org/TR/wai-aria/roles#form

A landmark region that contains a collection of items and objects that, as a whole, combine to create a form. See related search.

A form may be a mix of host language form controls, scripted controls, and hyperlinks. Authors are reminded to use native host language semantics to create form controls, whenever possible. For search facilities, authors SHOULD use the search role and not the generic form role. Authors SHOULD provide a visible label for the form referenced with aria-labelledby. If an author uses a script to submit a form based on a user action that would otherwise not trigger an onsubmit event (for example, a form submission triggered by the user changing a form element's value), the author SHOULD provide the user with advance notification of the behavior. Authors are reminded to use native host language semantics to create form controls, whenever possible.

main - http://www.w3.org/TR/wai-aria/roles#main

The main content of a document. This marks the content that is directly related to or expands upon the central topic of the document. The main role is a non-obtrusive alternative for "skip to main content" links, where the navigation option to go to the main content (or other landmarks) is provided by the user agent through a dialog or by assistive technologies.

navigation - http://www.w3.org/TR/wai-aria/roles#navigation

A collection of navigational elements (usually links) for navigating the document or related documents.

search - http://www.w3.org/TR/wai-aria/roles#search

A landmark region that contains a collection of items and objects that, as a whole, combine to create a search facility.

ARIA The Roles Model

Document Structure: What's this?

A partial list of structural roles:

Describe structures that organize content in a page.

Document structures are not usually interactive.

article - http://www.w3.org/TR/wai-aria/roles#article

A section of a page that consists of a composition that forms an independent part of a document, page, or site.

An article is not a navigational landmark, but may be nested to form a discussion where assistive technologies could pay attention to article nesting to assist the user in following the discussion. An article could be a forum post, a magazine or newspaper article, a web log entry, a user-submitted comment, or any other independent item of content. It is independent in that its contents could stand alone, for example in syndication. However, the element is still associated with its ancestors; for instance, contact information that applies to a parent body element still covers the article as well. When nesting articles, the child articles represent content that is related to the content of the parent article. For instance, a web log entry on a site that accepts user-submitted comments could represent the comments as articles nested within the article for the web log entry. Author, heading, date, or other information associated with an article does not apply to nested articles.

columnheader - http://www.w3.org/TR/wai-aria/roles#columnheader

A cell containing header information for a column.

columnheader can be used as a column header in a table or grid. It could also be used in a pie chart to show a similar relationship in the data.

directory - http://www.w3.org/TR/wai-aria/roles#directory

A list of references to members of a group, such as a static table of contents. Authors SHOULD use this role for a static table of contents, whether linked or unlinked. This includes tables of contents built with lists, including nested lists. Dynamic tables of contents, however, might use a tree role instead.

document - http://www.w3.org/TR/wai-aria/roles#document

A region containing related information that is declared as document content, as opposed to a web application.

When the user navigates an element assigned the role of document, assistive technologies that typically intercept standard keyboard events SHOULD switch to document browsing mode, as opposed to passing keyboard events through to the web application. The document role informs user agents of the need to augment browser keyboard support in order to allow users to visit and read any content within the document region. In contrast, additional commands are not necessary for screen reader users to read text within a region with the application role, where if coded in an accessible manner, all text will be semantically associated with focusable elements. An important trait of documents is that they have text which is not associated with widgets or groups thereof.

note
A section whose content is parenthetic or ancillary to the main content of the resource.
presentation

An element whose implicit native role semantics will not be mapped to the accessibility API.

The intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type, or may be used to provide for an accessible fallback in older browsers that do not support WAI-ARIA.

Example use cases:

  • An element whose content is completely presentational (like a spacer image, decorative graphic, or clearing element);
  • An element used as an additional markup "hook" for CSS; or
  • A layout table and/or any of its associated rows, cells, etc.

ARIA The Roles Model

Interface Widgets: What's this?

A partial list of widget roles:

  • alert
  • alertdialog
  • button
  • checkbox
  • dialog
  • menu
  • menubar
  • menuitem
  • option
  • progressbar
  • radiogroup
  • scrollbar
  • slider
  • spinbutton
  • status
  • tab
  • tabpanel
  • textbox
  • tooltip
  • ... and 15 more.

ARIA also has 34 Widget Roles:
http://www.w3.org/TR/wai-aria/
roles#widget_roles

ARIA and HTML5

ARIA is officially part of HTML5

HTML5 logo

HTML5 Landmark Elements

Semantic Structure

[Graphic - illustration of the various landmark elements]

Anatomy of a basic HTML5 document

Looking at our code

[Graphic - illustration of the various landmark elements] 

<!DOCTYPE HTML>
...

<body>
  <header></header>
  <nav></nav>
  <div id="content">
	<section></section>
	<article></article>
	<aside></aside>
  </div>
  <footer></footer>
</body>
</html>

Belt and suspenders

Forward looking - backward compatible

Photo - John Lithgow showing off his belt and suspenders 

<!DOCTYPE HTML>
...
<body>
  <header role="banner">
    <div id="search" role="search">
Forms are next!</div>
<div id="my-button" role="button">Button text</div>
  </header>
  <nav role="navigation">
    ...<select role="menu">...
  </nav>
  <div id="content" role="main">
	<section role="group"></section>
	<article role="article"></article>
	<aside role="complementary"></aside>
  </div>
  <footer role="contentinfo"></footer>
</body>
</html>

ARIA States and Properties

35 States and Properties

http://www.w3.org/TR/wai-aria/states_and_properties

  • aria-activedescendant
  • aria-atomic
  • aria-autocomplete
  • aria-busy (state)
  • aria-checked (state)
  • aria-controls
  • aria-describedby
  • aria-disabled (state)
  • aria-dropeffect
  • aria-expanded (state)
  • aria-flowto
  • aria-grabbed (state)
  • aria-haspopup
  • aria-hidden (state)
  • aria-invalid (state)
  • aria-label
  • aria-labelledby
  • aria-level
  • aria-live
  • aria-multiline
  • aria-multiselectable
  • aria-orientation
  • aria-owns
  • aria-posinset
  • aria-pressed (state)
  • aria-readonly
  • aria-relevant
  • aria-required
  • aria-selected (state)
  • aria-setsize
  • aria-sort
  • aria-valuemax
  • aria-valuemin
  • aria-valuenow
  • aria-valuetext

The terms "states" and "properties" refer to similar features. Both provide specific information about an object, and both form part of the definition of the nature of roles. In this document, states and properties are both treated as aria-prefixed markup attributes. However, they are maintained conceptually distinct to clarify subtle differences in their meaning. One major difference is that the values of properties (such as aria-labelledby) are often less likely to change throughout the application life-cycle than the values of states (such as aria-checked) which may change frequently due to user interaction. Note that the frequency of change difference is not a rule; a few properties, such as aria-activedescendant, aria-valuenow, and aria-valuetext are expected to change often. Because the distinction between states and properties is of little consequence to most web content authors, this specification refers to both "states" and "properties" simply as "attributes" whenever possible.

HTML5 Web Forms

Interacting with your users

screenshot of a web form

Love them or hate them, we interact with our users via forms.

What's New in HTML5 Forms

Input Types & Attributes

  • input type=datetime
  • input type=datetime-local
  • input type=date
  • input type=month
  • input type=time
  • input type=week
  • input type=number
  • input type=range
  • input type=email
  • input type=url
  • input type=search
  • input type=tel
  • input type=color
  •  
  • autocomplete
  • autofocus
  • form
  • formaction
  • formenctype
  • formmethod
  • formnovalidate
  • formtarget
  • list
  • multiple
  • pattern
  • placeholder
  • required
  • step
  • spellcheck*

Forms Problems - Part 1

Search this site

Searching for Rainbows or Unicorns will cause this website to explode!


<fieldset>
  <legend>Search this site</legend>
  <p id="instructions">
  Searching for Rainbows or Unicorns will cause 
  this website to explode!</p>
  <label for="search">Search</label>
  <input type="text" name="Search" id="Search" 
  autofocus aria-describedby="instructions" 
  placeholder="Don't search Rainbows or Unicorns">
  <input type="submit" name="search" value="Go">
</fieldset>

Forms Problems - Part 2


.required {
	background-color: yellow; padding-right: 16px;
	background-image: url(images/asterix.png);
	background-repeat: no-repeat; background-position: right top;
}
#testform1{
	list-style-type:none;
}


<fieldset>
<ul id="testform1">
	<li><label for="name" class="required">Name</label> 
	<input type="text" name="name" id="name" required  
          aria-required="true"></li>
	<li><label for="email" class="required">email</label> 
 <input type="text" name="email" id="email" required aria-required="true"></li>
 <li><label for="shoesize">Shoesize</label> 
 <input type="text" name="shoesize" id="shoesize"></li>
 <li><input type="submit" value="Send"></li>
</ul>
</fieldset>

Forms Problems - Part 3

All Thumbs and a Lousy Spreller

Currently the @spellcheck attribute only works in Chrome, but the benifits should be obbvious...

<input type="text" spellcheck="true">
Spellcheck in action in the Chrome browser

HTML5 - Video/Audio Part 1

One of the so-called Flash killers

[Graphic - video without Flash plugin]
http://www.w3.org/TR/html5/video.html

HTML5 - Video/Audio Part 2

Supporting Accessibility

http://www.w3.org/WAI/PF/media-a11y-reqs/

Accessible Media Requirements by Type of Disability

  • Blindness
  • Low vision
  • Atypical color perception
  • Deafness
  • Hard of hearing
  • Deaf-blind
  • Dexterity/mobility impairment
  • Cognitive and neurological disabilities
  •  

Alternative Content Technologies

  • Described video
  • Text video description
  • Extended video descriptions
  • Clean audio
  • Content navigation by content structure
  • Captioning
  • Enhanced captions/subtitles
  • Sign translation
  • Transcripts

System Requirements

  • Access to interactive controls / menus
  • Granularity level control for structural navigation
  • Time-scale modification
  • Production requirements
  • Discovery of available alternative content
  • Requirements on the accessibility interface
  • Requirements on the use of the viewport
  • Requirements on multiple devices in parallel

HTML5 - Video/Audio Part 3

Where are we today?

screencap: User Requirements document

HTML5 - Video/Audio Part 4

Polyfills to the rescue!

HTML5 - Video/Audio Part 5

The 'kind' of support we can provide today.

Keyword Brief description
subtitles Transcription or translation of the dialogue, suitable for when the sound is available but not understood (e.g. because the user does not understand the language of the media resource's soundtrack). Displayed over the video.
captionsTranscription or translation of the dialogue, sound effects, relevant musical cues, and other relevant audio information, suitable for when the soundtrack is unavailable (e.g. because it is muted or because the user is deaf). Displayed over the video; labeled as appropriate for the hard-of-hearing.
descriptionsTextual descriptions of the video component of the media resource, intended for audio synthesis when the visual component is unavailable (e.g. because the user is interacting with the application without a screen while driving, or because the user is blind). Synthesized as separate audio track.
chaptersChapter titles, intended to be used for navigating the media resource. Displayed as an interactive list in the user agent's interface.
metadataTracks intended for use from script. Not displayed by the user agent.

I Want My Web-TV

Not actual code:


<video controls>
   <source src="video.mp4" type="video/mp4">
   <source src="video.webm" type="video/webm">
   <source src="video.theora.ogg" type="video/ogg">

   <track label="English Captions" kind="captions" 
         srclang="en-US">
     <source src="cap_en.ttml" type="text/ttml">
     <source src="cap_en.srt" type="text/srt">
     <source src="cap_en.vtt" type="text/vtt">
   </track>
 </video>

Canvas/SVG

Another of the so-called Flash killers

[Graphic - example of Canvas use]

HTML5 and Accessibility

Thank You

Questions?

qrcode

http://soap.stanford.edu/presentations

Contact