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:
- Presentation description from the conference web site
- http://webaim.org/blog/loss-aversion-and-web-accessibility/
- http://webaim.org/resources/designers/ (nice infographic here)
- http://www.html5accessibility.com/ (HTML5 accessibility browser support info)
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
- http://www.w3.org/WAI/PF/aria-practices/#aria_ex
- JQuery Components: http://hanshilen.github.io/jqtest
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
- Why make authors do something that the browser can do for them?
- 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 replies on “Introduction to ARIA and HTML5 – Part 1”
[…] A redux of aria labels that was covered in Part One […]
[…] Introduction to ARIA and HTML 5 – Part 1 (Blog) […]