Introduction to ARIA and HTML5 – Part 1

This presentation is a two-parter, this is part one.  If you want to skip ahead to part two, this is the link you’re looking for:  Implementing ARIA and HTML5 into Modern Web Applications (Part Two)

Presenters:

  • Jared Smith from WebAIM (@jared_w_smith)
  • Jonathan Whiting from WebAIM

For those who don’t know, WebAIM is from Utah State University.  Here are some resources that were cited during the presentation:

 

SLIDE ONE

Requiring JavaScript is not an accessibility question…it’s a general usability question.

 

SLIDE TWO

WebAIM Surveys of Users with Disabilities >98% of respondents have JavaScript enabled.  Upshot:  if you’re going to do scripting, you have to do it accessibly.

  • You’re probably better off to have your scripts fail entirely rather just partially.
  • Progressive enhancement allows you to retain functionality regardless of browser capabilities.

 

SLIDE THREE

“Freak out mode”  occurs with screen readers when the currently focused page element disappears or is significantly modified via DOM manipulation, refreshes or other control changes.  Avoid it or address it by setting focus();

  • Mentioned the common use of carousels and other frequently refreshing content

 

SLIDE FOUR

JavaScript prompt, alerts, and confirmations are screen reader accessible!

 

SLIDE FIVE

Ensure Device Independence.  Functionality available to mouse users must be available to keyboard users

 

SLIDE SIX

CAPTCHA – Completely Automated Patience Test to Confuse the Hell out of your Audience (humor with some scattered chuckles and guffaws).  There are ways to accomplish the goals of CAPTCHA – that is, proving you’re a human – while avoiding its use.

 

SLIDE SEVEN

ARIA

  • Accessible Rich Internet Applications
  • Specification developed by the PFWG of the W3C’s WAI (Protocols and Formats Working Group of the World Wide Web Consortium’s Web Accessibility Initiative)
  • W3C Proposed Recommendation (final step before formal recommendation)

Implementation by browser vendors has actually been quickly adopted by comparison with other web technologies like CSS.

 

SLIDE EIGHT

ARIA Enhances accessibility of…

  • …dynamic content and AJAX
  • …scripted widgets and interactive controls
  • …keyboard interactions within a web page

ARIA bridges the gap to future versions of HTML

An example of a widget that is not available natively in HTML is the slider.  Screen readers know what a slider is, and they are able to read ARIA code and interpret it.

 

SLIDE NINE

Screen readers understand a fairly broad vocabulary, but HTML’s dictionary is very limited.  ARIA expands HTML’s semantic vocabulary.  ARIA fills in the vocabulary needed to express functions needed.  It “paves the cow paths.”  In a sense, ARIA “paves the cow paths.”  They showed a series of photos of “cow paths” at Utah State University.

 

SLIDE TEN

You can only make things more accessible by implementing ARIA now…if you do it correctly.  Some older versions of browsers and screen readers won’t read some features properly.  In that case, ARIA won’t break the page, the technology just won’t see it.  A common interaction now are light boxes that will close when pressing the escape key.

 

SLIDE ELEVEN

ARIA Core Components

  • Roles:  this is what this thing is <form role=”search”>
  • States: this is the condition of this thing <input aria-disabled=”true”>
  • Properties: this is a property of this thing <input aria-required=”true”>

HTML has default states and properties.  In ARIA, there is no limit to the number of states and properties a core component can have.  While you can include lots of states and properties to your components, you need to be cautious about overloading your users with too much information.  There is a sweet spot, though.  More info in a post here:  http://webaim.org/blog/loss-aversion-and-web-accessibility/

 

SLIDE TWELVE

ARIA and Code Validation

  • If your (X)HTML is valid and your ARIA is valid…
  • valid+valid=??

Your ARIA markup may be completely valid, but many validators will show that your ARIA code is invalid.  ARIA is a part of HTML5 spec, so if you code is marked up as HTML5, you’re less likely to get validation errors.

 

SLIDE THIRTEEN

ARIA Landmark Roles

  • Banner:  complementary, contentinfo, main, navigation and search
  • Allows easy access to major page components
  • The end of the “skip” link?  No, browser keyboard accessibility still sucks so you should keep using it.

If browsers would implement navigation via headings and landmarks, the skip link could go away.  Consumers should bug the browser vendors if they want better accessibility in their tools.

Question from the audience:  are there SEO benefits for implementing ARIA?  I don’t know, but in the future there may be benefits for content landmarks like “main”

 

SLIDE FOURTEEN

Landmark Roles – some examples

  • <div role=”main”>
  • <form role=”search”>
  • <div role=”navigation” aria-label=”Main navigation”>

You can add aria-label to differentiate multiple landmarks of the same type

 

SLIDE FIFTEEN

Landmark Roles

  • Don’t overdo it!
  • Not all lnks are navigation
  • It is assumed that the footer will contain some links.  It todoesn’t need navigation also

 

SLIDE SIXTEEN

HTML5 and Landmark Roles Mapping

  • <main> – role=”main”
  • <article – role=”article”
  • <footer> – role=”contentinfo”
  • <header> – role=”banner”
  • <nav> – role=”navigation”
  • <aside> – role=”complementary”

ARIA support is better than HTML5 support, so use both…for now

 

SLIDE SEVENTEEN

Modifying and Enhancing Roles

  • Bad:  <img src=”submit.jpg” onclick=…>
  • OK:  <a onclick=”…”><img src=”submit.jpg”…
  • Better: <a role=”button” onclick=”…”><img src=”submit.jpg”…
  • Best:  <button onclick=”…”>

Always start with native HTML

 

SLIDE EIGHTEEN

Always use native, accessible HTML first, then use ARIA to enhance or fill in gaps.  Use controls that convey the correct semantic meaning wherever possible.  Above all, be consistent!

 

SLIDE NINETEEN

ARIA does not change functionality, it only changes the presented roles/properties to screen reader users.  WebAIM’s WAVE toolbar identifies ARIA roles on the page.

 

SLIDE TWENTY

If there’s a conflict between native HTML roles/attribute and ARIA roles/attributes…ARIA wins!

Example:  <input type=”radio” role=”checkbox”>

How is the above code presented to the user?  As a checkbox.

 

SLIDE TWENTY ONE

role=”application”

….routes key commands to the browser to allow it to function like a desktop application

Be very careful with <body role=”application”>

Some ARIA elements (tree view, slider, table, tabs, dialog, toolbar, menus, etc.) have an assumed application role

role=”document” should enable reading mode

An example of confusing behavior could be pressing the “h” key opening a help dialog instead of the default jump to next heading.

Paul Schantz comment:  It seems like by invoking application mode, the developer is making two big assumptions:  1) the screen reader user is advanced, and 2) the user is going to use your application an awful lot.

Hans Hillen comment:  use application role when 1) you can guarantee that your app will actually behave like an app, or 2) that this is a highly controlled intranet-style application

 

SLIDE TWENTY TWO

role=”presentation”

<ul role=”presentation”>

<li>menu item</li>…

Hides native roles of elements and all required owned child elements from assistive technology.  Useful on layout tables, lists, etc.

Is ignored if the element is navigable (e.g., links and controls).

 

SLIDE TWENTY THREE

Alert Role

  • <div role=”alert”>Read me right now</div>
  • Also role=”alertdialog”

Use this role only for really important alerts!  An alert is a special type of live region

 

SLIDE TWENTY FOUR

Form field example with a “First Name” field

<label for=”name”>First Name</label>:

<input name=”name” id=”name”><em>(required)</em>

The information about the element being required is outside the form element and its label, so it’s ignored by a screen reader

 

SLIDE TWENTY FIVE

<label for=”name”>First Name</label>:

<input name=”name” id=”name” aria=required=”true”><em>(required)</em>

A screen reader now indicates the required status of the form element (and that’s all).

 

SLIDE TWENTY SIX

Form field example using a Password field

<label for=”password”>Password</label>;

<input name=”password” id=”password” aria-invalid=”true”>

A screen reader no indicates that the field is invalid or broken (and that’s all).

Use ARIA attributes to control styling:

(aria-invalid=true) (border : 2px solid red;)

 

SLIDE TWENTY SEVEN

<input type=”submit” disabled=”disabled”>

…versus…

<input type=”submit” aria-disabled=”true”>

Disabled HTML buttons are not keyboard focusable and have very poor contrast.

 

SLIDE TWENTY EIGHT

Use scripting to change aria-disabled value, then use CSS to control the visual presentation:

[aria-disabled=true] (color : #999;)

aria-disabled does not disable the button, it simply presents it as disabled to screen reader users.

 

SLIDE TWENTY NINE

aria-hidden=”true”

Indicates element (and all descendants) are hidden from all (???) users.

You can’t unhide a child element.

Use ARIA attributes to control visual appearance:

[aria-hidden=true] (display:none;}

 

SLIDE THIRTY

First Name form field example

<label for=”name” id=”fnamelabel”>First name</label>:

<input type=”text” id=”fname” aria-labelledby=”fnamelabel”>

Redundant, but doesn’t cause any problems.  Remember, ARIA always overrides native semantics.  Use aria-labelled by when you already have a textual description on the page.

There were then a few example slides that showed labeling examples with forms, multiple fields in a grid, and so on.

 

SLIDE THIRTY ONE

ARIA Live Regions

aria-live=”off | polite | assertive”

  • aria-busy
  • aria-atomic – read the entire region or only what has changed
  • aria-relevant – additions, removals, text, or all
  • aria-controls
  • Special live regions:  alert(important), status (not important), timer(always changing), marquee(same as aria-live=”polite”), and log(updates added to the bottom)

 

SLIDE THIRTY TWO

ARIA Live Regions

Some highly dynamic content updates simply cannot be made accessible using ARIA.  Be sure to give users control over content updates

 

SLIDE THIRTY THREE

ARIA Lists

A code example was here with <divs> and lists

Could use aria-checked=true|false|mixed to make it interactive

 

SLIDE THIRTY FOUR

ARIA ‘fieldset/legend’

A code example was here with <divs> and radio buttons

Radiogroup is not reserved only for radio buttons

 

SLIDE THIRTY FIVE

ARIA Table Caption

<h2 id=”salescaption”>2013 Sales Data</h2>

<p>Sales increased by…</p>

<table aria-describedby=”salescaption”>

 

SLIDE THIRTY SIX

ARIA Pop-ups/Dialogs and ARIA Expanded

<a aria-haspopup=”true”>Option dialog</a>

<a aria-expanded=”false”>Expand details</a>

 

SLIDE THIRTY SEVEN

Odds & Ends:  menus, tablists, grids

 

SLIDE THIRTY EIGHT

ARIA Design Patterns for Widget Interaction

 

 

SLIDE THIRTY NINE

HTML5

  • Adds new features- primarily for application development and enhanced semantics
  • Maintains backward compatibility (mostly)
  • Defines error handling for browsers
  • Drops all (actually most) presentational markup

 

SLIDE FORTY

HTML5 History

A slide with a timeline that contained lots of dates that showed the history (too many bullets to capture…sorry!)

 

SLIDE FORTY ONE

HTML5 Philosophy

  1. Why make authors do something that the browser can do for them?
  2. Things that actually work matter most.

 

SLIDE FORTY TWO

HTML5 Doctype

<!DOCTYPE html>

  • The last DOCTYPE you’ll ever use?
  • HTML versions vs. HTML the “living standard”
  • HTML is very much a work in progress

If you write it and the browser supports it, then you’re good!

 

SLIDE FORTY THREE

HTML5 Simplifications

  • HTML5 is case insensitive
  • Quoted single-word attribute values are not required.  Example <label for=fname> is acceptable
  • Don’t have to self close elements

There were then a series of slides that demonstrated a series of code simplifications, including language, charset, CSS type, script, style type.

 

SLIDE FORTY FOUR

The smallest valid accessible HTML5 Document:

<!doctype html>

<html lang=en>

<meta charset=utf-8>

<title>blah</title>

<p>I’m the content</p>

HTML5 allows browsers to do much of the work.  Just because you can, doesn’t mean that you should.

 

SLIDE FORTY FIVE

HTML5 Changes

Dropped:  <acronym>, <applet>, <frameset>, <font>, <s> (strike), <big>, <center>

Maintained:  <b>, <em>, <i>, <strong>, <small>, (side comments), <u>, and <cite>

 

SLIDE FORTY SIX

New HTML5 Elements

  • nav
  • header
  • main
  • footer
  • article
  • section
  • aside
  • …and more

 

SLIDE FORTY SEVEN

HTML5 Sectioning Elements

  • <section>, <article>, <aside> and <nav>
  • Each should generally begin with a heading that describes that section
  • <article> is self-contained, syndicatable
  • The outline presented to the user may be different than the heading structure defined

A blog was given as an example of how the outline presentation might work.  Each blog post title will logically have an <h1> within the page of the post itself, while in a table of contents on the site home page, those <h1> might be shifted to <h2>

If you’re going to use these items, just use proper headings!

 

SLIDE FORTY EIGHT

HTML5 Accessibility Changes

  • Alt attribute is optional when <figcaption> presents an equivalent alternative for an image within a <figure>
  • Dropped longdesc (subject to change)
  • Dropped table summary
  • ARIA markup is valid
  • <video> and <audio> natively support captioning

More details here on browser support:  http://www.html5accessibility.com/

 

SLIDE FORTY NINE

New HTML5 Input Types

  • search, number, range, color, url, email, tel, date, month, week, time, datetime, datetime-local
  • New form attributes: – required, pattern, autocomplete, placeholder, autofocus, etc.
  • The browser can (or, more accurately, hopefully will) provide a natively accessible control/interface

 

SLIDE FIFTY

 

2 thoughts on “Introduction to ARIA and HTML5 – Part 1”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>