• Basic HTML5 elements
• ARIA landmark roles
• Browsers, accessibility APIs, and screen readers
• Expected screen reader behaviour
• Actual screen reader behaviour
  • NVDA, JAWS
  • VoiceOver
• HTML5/ARIA accessibility: a shared responsibility

• a bunch of attributes: roles, states, properties
• dynamic, interactive content
• document structure
• part of the HTML5 specification

“regions of the page intended as navigational landmarks”

• application
• banner
• complementary
• contentinfo
• form
• main
• navigation
• search

<div id="main" role="main">

“structures that organize content in a page”

• article
• columnheader
• definition
• directory
• document
• group
• heading
• img
• list

• listitem
• math
• note
• presentation
• region
• row
• rowheader
• separator
• toolbar

Refer to the HTML5 Only Test Case.

Refer to the HTML5 Plus ARIA Test Case.

Accessiblity APIs

• Interface between the browser and screen reader
• Browsers relay roles, states, properties, and events to the API
• Screen readers access the API and are notified of changes in elements, states, properties

Internet Explorer 6 and 7

• Microsoft Active Accessibility (MSAA)

Internet Explorer 8 and 9

• Microsoft Active Accessibility (MSAA)
• User Interface Automation (UIA) [Windows 7]

Firefox in Windows

• Microsoft Active Accessibility (MSAA)
• IAccessible2 (IA2)

Safari and the Mac Accessibility API

• Mac Accessibility API

Linux

• Assistive Technology–Service Provider Interface (AT-SPI)

IE9 passes an accRole of “text” for the <header> element set with role=“banner”

MSAA: <header> with role=“banner” gets accRole of “banner”

IA2: role is “header”; “xml-roles” attribute is “banner”

<header> with role=“banner” gets an AXRoleDescription of “banner”

Extreme Variability in:

• What type of information each API supports
• The information the browser sends to the API
• The information the screen reader takes from the API

• A tree of nodes: elements and their attributes
• Screen readers can access the DOM directly
• Is useful when:
  • the API does not support certain information, or
  • the information sent by the browser to the API is incomplete

Navigation by landmark

• Special keyboard commands

Reading through the page

• Announce landmarks as they come
• Note the entering and leaving of landmarks

ARIA Landmarks List Dialog

• Special dialog window listing all landmarks

HTML5 Only

• <aside> → “complementary landmark”
• <footer> → “contentinfo landmark” only once per document, if at all
• <header> → “banner landmark” only once per document, if at all
• <nav> → “navigation landmark”
• <article>, <section> → not landmarks

HTML5 plus ARIA Roles

• All explicitly identified landmark roles are announced
• Document structure roles, e.g., article and region, are not announced

HTML5 Only

HTML5 Only

NVDA is not using the DOM, but relying on the APIs:

• In IE, no HTML5 elements on their own are considered landmarks
• In FF, nav, footer, and aside are considered landmarks

HTML5 plus ARIA Roles

HTML5 plus ARIA Roles

• In FF, NVDA is reading landmark role information from the IA2 API
• In IE, NVDA gets it straight from the DOM, since IE passes no landmark information to the API:
  • In IE6 and above, NVDA announces the same landmark roles as it does in FF

HTML5 Only

HTML5 Only

• JAWS reads from the DOM to identify article and nav elements as landmarks:
  • article and nav elements are considered landmarks, even in IE6
• In FF, JAWS also uses the API: all footer and aside elements are called contentinfo and complementary landmarks

HTML5 plus ARIA Roles

• Each landmark is called a “landmark region”, e.g., “navigation landmark region”
• JAWS announces the start and end of landmarks, e.g.,
  • "banner landmark region start"
  • "banner landmark region end"

HTML5 and ARIA roles

Reading through the page

The HTML5 Outline Algorithm

Sectioning Elements: article, aside, nav and section

<h1>Level 1</h1>
<section>
   <h1>Level 2</h1>
   <article>
      <h1>Level 3</h1>
   </article>
</section>

<h1>Level 1</h1>

   <h2>Level 2</h2>

      <h3>Level 3</h3>

The HTML5 Outline Algorithm

This should also work:

<h2>Level 1</h2>
<section>
   <h6>Level 2</h6>
   <article>
      <h4>Level 3</h4>
   </article>
</section>

<h1>Level 1</h1>

   <h2>Level 2</h2>

      <h3>Level 3</h3>

The HTML5 Outline Algorithm

What JAWS 12/13 do:

<h1>Level 1</h1>
<section>
   <h2>Level 2</h2>
   <article>
      <h3>Level 3</h3>
   </article>
</section>

<h1>Level 1</h1>

   <h3>Level 2</h3>

      <h5>Level 3</h5>

For example, in our test page, the h3 nested two sectioning levels deep in our article element becomes an h5.

For more, read JAWS, IE and Headings in HTML5.

HTML5 <header> bug in Firefox

• Content inside the header element is not accessible!
• Fixed in JAWS 12

HTML5 Only

HTML5 plus ARIA Roles

HTML5 and ARIA roles

• Browser vendors
• Screen reader vendors
• Developers
• Users

Browser vendors

• Implement HTML5 and ARIA according to their specifications
• Fully utilise the accessibility APIs to pass information to assistive technology

Screen Reader vendors

• Implement HTML5 and ARIA according to their specifications
• Fully utilise the accessibility APIs to present page structure, content, and events to the user

Developers

• Implement HTML5 and ARIA according to their specifications
• Keep up with how browsers, APIs, and AT work together, including buggy behaviour
• Provide reasonable workarounds as necessary to improve the experience for screen reader users
• Know the audience and the technology users have at their disposal
• Identify and report bugs

Users

• Keep browser and screen reader up-to-date
• Use screen readers that support HTML5 and ARIA
• Not settle for less: Demand improved support from vendors
• Identify and report bugs

Use HTML5 and ARIA, but...

• Keep abreast of current browser and AT support for HTML5 and ARIA
• Understand how it can impact users
• Make an informed decision that balances your development needs with the access needs of your desired audience