Tag Archives: ARIA

CSUN 2014 Web Track Mega Post

As usual, I like to make a post that sums up my entire conference experience…I call this the “Mega Post.”  As you may have guessed from the titles of the sessions I attended, I’m interested in the web track.  If the web is your bag, you just might find all this helpful.

Enjoy!

 

Friday, March 21

 

Thursday, March 20

 

Wednesday, March 19

 

Tuesday, March 18

 

Monday, March 17

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

 

The CSUN 2013 Web Track Mega Post

Greetings, fellow web accessibilistas!  (not to be confused with accessiballistas, the little-known and even less-documented accessible siege engine of yore).

As you may have gathered if you followed my live blog posts a couple weeks ago, my interest in attending the CSUN 2013 conference was almost exclusively web-related.  Now that it’s been a couple weeks and I’ve had some time to reflect, I figured it would be a good idea if I consolidated everything into one mega-list.  This year, there were several times when I wish I could have been in two places at once.  Hopefully this gives you a pretty representative sampling of what was on offer web-wise this year.  Follow me @paulschantz for more web-related topics, including accessibility, project management, web development and design philosophy, thoughts on working in higher education, bad clients, off-color humor, and other ephemera.  Enough self-promotion…on with the list!

Pre-Conference Seminar:  Google Accessibility

Day One:  February 27, 2013

Day Two:  February 28, 2013

Day Three:  March 1, 2013

Using WAI-ARIA to Make Typical Pages Fabulous

Another IBM presentation:  “How to go beyond adding WAI-ARIA landmark regions to radically improve the accessibility of ordinary web pages by thinking of them as rich internet applications”

Presenters

  • Matthew King
  • Mary Jo Mueller
  • Bill Curtis-Davidson

HTML is good for documents and static forms, but not good for modern rich web sites.

1 – GET LANDMARKS RIGHT

Landmarks indicate what’s on the page and how it’s organized.  Only put inside of a region those things that belong in a region.  WAI-ARIA landmark roles are:

  • Banner (header)
  • Search (search tool)
  • Navigation (links)
  • Main (main content of page)
  • Form (collection of form elements)
  • Complementary (info related to main content)
  • Contentinfo (footnotes, copyrights, privacy statements, etc)
  • Region (content where no other role is applicable)
  • Application (software unit embedded on the page – not recommended)

Main region is the most important and needs to be created for every page (before and after screen shots of a page were shown)

Don’t create orphaned content – content that’s not included in any region, or relationship to other elements on the page are lost.

2 – DESIGN THE KEYBOARD EXPERIENCE

  • “Make keyboard navigation more like a desktop application experience”
  • Study the visual layout and group
  • With effective grouping, the tab ring of the page collapses dramatically
  • Support up and down arrows in vertical groups (showed a megamenu with categories of links within the menu – sort of like the CSUN home page)
  • QUESTION:  can you put other elements into a megamenu besides navigation elements?  Yes, you could put (for example) a search field in it.
  • Support left and right arrows in horizontal groups (i.e. – tabs, toolbars)
  • Blocks of elements that appear tabular may support all arrows
  • Don’t forget the visual focus indicator
  • Skip the “skip link” it just eats up one more tab stop; designs a “tab ring” so short that skip links do not add value.  The method for skipping large block of becomes tab itself.  Showed a slide with a horizontal group of tabs:  without horizontal grouping you have 9 tab stops, with horizontal grouping you have 3 tab stops.

3 – MAP THE KEYBOARD EXPERIENCE TO WIDGETS

  • Learn standard keyboard patterns for:  menubar with submenus, menu and menu button, tree, toolbar, grid, dialogs containing menus and other widgets
  • With appropriate widget choice:  perfectly map virtually any navigation scheme, equally efficient for all (keyboard or mouse, visual or non-visual)

QUOTABLE QUOTE:  “This is a designer’s job…interaction design is the magic”

Menubars with pulldown menus should work just like they do on the desktop.  A good example is www.FreedomScientific.com.  This was a powerful demonstration of how  much WAI-ARIA affects navigation within a page.

Since JAWS 12, opening a dialog allows you to easily navigate confined tab rings.

Even though they look like tabs, in most cases it is better not to use WAI-ARIA tablist and tab roles.  Site nav links that are styled to look like tabs usually don’t work like tabs

4 – LABELING AND DESCRIBING

After identifying elements with correct landmark or widget roles, ALL, with few exceptions, should be labeled and related to any describing elements.

  • Use aria-labelledby whenever possible
  • Re-use of strings simplifies maintenance, translation, etc
  • Brevity is key:  aim for 1 or 2 short words, 3 tops; do not use role names in labels i.e. “site navigation” for a navigation region; do not put instructions in labels “press enter to…”

A slide was shown with examples of labeling and describing elements, good and bad

Use labels on multiple regions of the same type; some powerful examples:

  • Composite labels
  • aria-labelledby multiple IDs
  • May self-reference by including ID of element being labeled
  • May have both aria-label and area-labelledby on same element
  • browser automatically concatenates in specified order

5 – COMPLETING THE DESIGN

Success is in the minutia; implement design patterns thoroughly

Implement WAI-ARIA prperties per design patterns:

COMMON MISTAKES

Lost visual focus = lost user

  • Is the new focus location logically what user would expect?
  • Telling non-visual user useful information?
  • Making the task efficient?

Pay attention to where focus moves

  • Elements need to be able to receive focus (menuitem, treeitem, button)
  • If a parent or child element has focus instead, it may not work correctly

Best practice is to have one role per element

“Code to the spec, not to the test tool or assistive technology”  GREAT ADVICE

  • WAI-ARIA spec clearly states intended use for each role
  • Purpose is to communicate the intent of UI element to assistive technology
  • Use role only to communicate WAI-ARIA specified intent
  • Do not re-purpose roles to “fix the issue” or manipulate AT behavior
  • If AT does not behave as desired or expected:  may be incorrect design or bug in your code, may be incorrect expectations, may be bug in browser, may be bug in AT

SUMMARY AND BENEFITS

WAI-ARIA can dramatically boost accessibility and be as desired by PwD as anyone else