Accessibility Technology Uncategorized

The (not so) Surprising Parallels Between Responsive Design and Accessibility

This is my third session from the first day at the CSUN conference.  This session is hosted by my friend George Zamfir, who I met at this conference last year.  The session guide describes George’s session like so:  “Responsive design has borrowed principles & best practices from accessible design.  Learn about both and how to apply them to your projects.”

Presenter:  George Zamfir (@good_wally)




In this post, I’m going to dispense with my normal slide-by-slide narrative structure.  George’s presentation moved way too fast and had lots of builds. 😉


George discovered that responsive design was a great way to build accessibility into his projects.  He showed us some of his previous work on the Scotiabank web site.  This ended up being TWO projects:  first for the desktop version of the site, then the mobile responsive version of the site.  He also worked on the mobile version of the bank’s credit card application.


What do all assistive technologies have in common?

  • They don’t care much about design, and they care to change it for the user (a lot like RSS readers)
  • Content trumps design, regardless of screen size
  • RWD is not about the design, it’s about updating the design to bring out the content



Visual, Auditory, Mobility, Cognitive & Speech.  Don’t measure people through the disability lens – which automatically focuses on what people are NOT able to do.  We now measure disability by what people CAN do.


Accessibility is contextual, so we should cater to users’ context.  You’re not necessarily engaging with someone working on a desktop computer with a large monitor, keyboard and mouse anymore.  He referred to a study of how people hold their phones and also the W3C’s BAD (Before After Demo) page.

  • One simple tip:  adding padding around text links increases the “hit size”
  • Keyboard accessibility translates well into touch-friendly interfaces.
  • Use native controls wherever possible.  On the bank side, they used <div> instead of <select> control, which was a problem when they went mobile.


Design for the edge cases (mobile first design)

If you start with a small screen, prioritization really matters. A variation of this model is designing for edge cases.  If you design for the harshest conditions first, the in-between cases are much easier to work out.  Consider accessibility as one of your edge cases!


RWD is a champion for A11Y, we have common goals for our users.


Question:  how do you handle navigation in RWD?  I target the simplest possible device and design progressively.

Question:  Do you do anything special about device orientation changes?  Answer:  why would you change the content?  Perhaps you change the layout, but you should not change the content.

Question:  What is your process when you have the luxury of a “clean sheet” design…how do you handle the lowest common denominator?  I like to start with everything besides the content.  We built the framework, and the content just fits into that framework.

Question:  what about hiding content based on context?  How do you handle that? Well, that’s probably not the best way to go…you’re probably doing it wrong if you’re doing it that way.



Foundations of RWD:  fluid foundation, media queries, responsive images.  In short:  Make your layout flexible!

  • Use ratios (ems) and percentages instead of absolute values (px).
  • Adapt to the size of the viewport:  width = device-width, initial-scale=1
  • What apple does is assume that the normal viewport size is 960 pixels, so if you don’t add the viewport declaration, you can get pages with text that’s very small-looking on a small screen.
  • Media Queries in CSS:  start with smallest screen first, and then the larger screens are additive over that definition.
  • Responsive Images:  for simplicity’s sake, start with this: use max-width:100%, height: auto;
Accessibility Technology

Accessibility Features of HTML5

This is my first session of the day Wednesday morning, the first day of the CSUN conference proper.  I’m hoping to get a good overview of HTML5 accessibility features while at the conference this week, so I’m looking forward to this session.  This particular presentation is about the features available in HTML5 that you can use to improve the accessibility of your websites.  Session will include code examples and demonstrations, which I will do my best to capture in this post.







Introductions, he’s the staff contact for the HTML Accessibility Task Force


Open Web Platform

  • Accessibility in the OWP

HTML5 Accessibliity / Demos

  • Improved Semantics
  • ARIA
  • Graphics



A description of the HTML Accessibility Task Force.  They have a mandate to develop accessibility solutions, including technical reports, extension specifications, and provide integration paths.  They are about reaching consensus between groups.



A very busy graphic describing the “Open Web Platform” which includes virtually any industry or device that needs to connect to the Internet.  Since the web is meant to connect everyone, it needs to be as accessible as possible.



Tim Berners-Lee:  The web is the great equalizer!



  • Added structured access through improved semantics.
  • Ability to bring desktop paradigms into the browser
  • More options for creating text equivalents for graphics
  • Native support for synchronized captions, sign language, internationalization and more.



Mark presented a page of code, pretty standard for a blog.  He then ran through the page with VoiceOver.



HTML5 Has Much Improved Semantics!

It allows you to describe your document structure with sectioning elements, including <section>, <nav>, <article>, <aside>, <header>, <footer>.  You don’t really have to do anything special except use a variety of new sectioning elements.  What makes a useful aside?  A pull quote, comments, etc.



More information about new semantic elements:  color, date, datetime, email, month, number, range, search, tel, time, url, week

Not all of these will necessarily make it into the HTML5 spec.



New attributes for the input element, including autocomplete, autofocus, autosave, list, max/min/step, maxlength, pattern, required, spellcheck.

These will help build forms much easier, particularly the task of form validation.



ARIA Landmark roles include:  application, banner, complementary, contentinfo, form, main, navigation, presentation

The ARIA specification was built to provide expose the accessibility API (roles, states, and properties) to accessible technology.  It was designed to allow dynamic web pages to be accessible and provide a more consistent experience for all users.




  • Accessibility for dynamic content (can be reparative, too)
  • Wired into accessibility APIs (roles, states, and properties)
  • Programmatically link elements with labels and descriptions (aria-label, aria-labelledby, aria-describedby)



Back to the code sample, only this time Mark replaced most of the <div> elements with a selection of the landmarks noted above.  By marking up the search field, the OS  (Mac in this case) used system styles for the search bar and button.  The demonstration highlighted how VoiceOver announces each section, and using the rotor control, allows the user to directly choose from the various page elements.

One of the things I noticed as Mark was editing his code is that using HTML5 makes hand-coding of web pages and identification of code segments much easier.  If you’ve ever had to deal with multiple nested <divs>, this is definitely something you’ll appreciate.



Much of the benefits come when you view an HTML5-coded page on different platforms.  For example, iOS will bring up a numeric keypad when entering digits telephone number field.  For dates and hours, the OS will present the appropriate pickers, like a calendar or a clock.




  • Added <figure> and <figcaption> to allow grouping of images with their description.
  • Provides equivalent interactivity and behavior for dynamic and/or bitmap images <canvas>
  • Provide extended descriptions for complex images <longdesc>
  • Provide detailed guidance to authors  ALT Guidance (



  • Canvas allows interaction with pixels on a page, but…they’re just pixels in a box.  Solution:  specify regions
  • How do we define roles/states/properties?  Solution:  map tose regions to Fallback Content.
  • How do we indicate focus?  Solution:  drawFocusIfNeeded()



Mark gave a demonstration of canvas that showed a list of two elements with checkboxes.  What makes this interesting is that those elements were literally just pixels painted onto the screen, but used fallback content.


Unfortunately, Mark’s presentation was rather long, and he was unable to complete his presentation and we missed out on seeing his slides on media.

Accessibility Technology Uncategorized

Implementing ARIA and HTML5 into Modern Web Applications (Part Two)

This is part two of a two-part presentation.  Catch up on part one here:  Introduction to ARIA and HTML5, Part 1

I’m typing this introduction before the presentation begins, and as I understand it, this session will be more technical than the morning session.  I’m not sure how many in-depth code samples will be included (the resources link below hints at what we’ll be talking about), so I’m making an educated guess that I may not be able to capture every nuance.  My apologies in advance if this is the case.





EVENT PLUG – TPGBB (The Paciello Group Bug Bash)

  • Wherein you and TPG can ID and squash AT bugs
  • Thursday, March 20, 5:30 – 6:30 PM
  • Suite 3233, Harbor tower, Manchester Grand Hyatt





Diving into some HTML5  – an overview of the session

Steve Faulkner talked briefly into his involvement with his having a role in the creation of the HTML specification.  His specific interest is in how APIs speak to AT.



Getting Simple

Getting to use native HTML controls makes things simpler for the developers and the AT.



HTML5 Demo – details/summary

Here’s an example of the “HTML code triangle” we’re all used to:


<summary> label </summary>

Some content


When fully supported, you’ll be able to use native HTML controls without having to use any complicated JavaScript.  In the example above, clicking details would expand and show the contained elements.

Steve then demonstrated in CodePen an example of the code above, and how vastly simplified it is to render these UI elements.  This will make UI/UX designer’s lives much easier.



Chrome, Opera, and Safari have implemented this

Keyboard = 1/2 implemented



Steve then gave a description of how the code above is exposed to the AT APIs (i.e. MSAA).   Put simply, it’s exposed as a <div>, however, it’s not an accurate description of how it’s represented within the DOM.  He then proceeded to show how this looks when viewed through the “Accessibility Viewer” tool.  The aviewer tool is an object inspection tool available from the Paciello Group’s web site at

Not all information is necessarily passed through the API and readable by aviewer.  The hope is that every browser will expose the same API Names, Roles, and States.



What We Want

  • We want to be able to see what’s actually there.
  • We also want to fill the gaps in general support in FF, IE, and webkit browsers



Steve showed and described the example above, only this time embellished with ARIA code inserted.



Showed the details summary here as a working example:

The properties of the code on this page are properly exposed by the API, and thus readable as you would expect by aviewer.




Creating a modal dialog that works with keyboard and prevents users from accessing ‘disable’ content is the holy grail…

Being able to do this within native HTML is something that sure would be awesome.  See next slide…



What we get for free:

  • Focus moves to modal dialog when displayed
  • Focus stays until it is dismissed
  • Content not in the modal dialog is really disabled
  • ESC key dismisses it
  • <dialog> = role=dialog



What we need to add (this only works in Chrome with Canary plug-in at the moment)

  • Accessible name to dialog:  <dialog aria-label=”text”>
  • Currently when the dialog is dismissed, focus moves to <body> when it needs to move to control that triggered dialog display:  can be polyfilled using scripting.

Steve demonstrated accessible modal dialog, once again with CodePen; he was unable to tab “out” of the modal dialog.  It works like a JavaScript alert()



The “good oil” on implementing custom dialogs (I didn’t capture these links, but they’re available in the TPG source slides from the “Resources” link above).

  • Juicy Studio – Custom Built Modal Dialogs
  • The Incredible Accessible Modal Dialog
  • WAI-ARIA design pattern – modal dialog



Input type=number

What we get:

  • Correct role and value information
  • Keyboard operable

Exposed as spin buttons



Input type=range control

Implemented in all browsers.  However, default styling in IE is pretty funky, and they all look different from each other.  Bottom line:  you get everything for free.



There are conformance rules for HTML5, but they can be difficult to decipher.  Steve has a “Using ARIA in HTML” document available for download which can help.



A large part of what’s been consuming Steve’s life in his role on the HTML5 specification group is figuring out which ARIA Roles, States, and Properties can be used on any HTML element.



ARIA Validation

  • Use of ARIA in HTML5 is non-conforming and probably always will be.  It doesn’t make any difference, it still works.
  • Easiest method is to use the HTML5 DOCTYPE with ARIA markup and then validate it using the W3C NU markup checker:

<!DOCTYPE html>




Live Regions

  • Allows user to be notified of content changes
  • Typically for content that changes automatically
  • Content change may exist separate to what has focus
  • Live Regions facilitate these notifications

ARIA overcomes gaps between what JavaScript has “traditionally” done in web browsers to emulate desktop applications.



Karl’s favorite thing to say:  “What is this thing & what does it do?”

  • Chat, error logs, etc. (role=’log’)
  • Status messages (role=’status’)
  • Urgent message requiring immediate notice (role=’alert’)
  • Stock ticker (role=’marquee’)
  • Timer/Clock (role=’timer’)
  • Progress indicator (role=’progressbar’)
  • None of the above (role=’region’)



How important is the content?

  • aria-live=’polite’ (waits patiently, default for most roles)
  • aria-live=’assertive’ (interrupts output, default for alert role)



What’s being changed?

  • I’m adding stuff (aria-relevant=’additions’)
  • I’m removing stuff (aria-relevant=’removals’)
  • I’m changing text (aria-relevant=’text’)
  • I’m replacing stuff (aria-relevant=’all’)

Makes relevant changes to the DOM within that live region.  You can change these properties together as needed.



What matters?

  • aria-atomic=’false’ (default behavior, only announces changed node)
  • aria-atomic=’true’ (presents entire contents)



What’s my name

A redux of aria labels that was covered in Part One



<div role=’alert’ aria-label=”Errors’>

Please correct the following errors:


Significance of the code above is that it will announce all the mistakes made in a form all at once, which is pretty handy.



Karl then demonstrated some of the challenges when using live regions with a chat he had set up at:

He also showed a web-based slideshow called “shower”

Download and play with Karl’s JQuery plug-in at

Short break here…

Karl went about soapboxing:

“ARIA is a LIE and your HTML doesn’t do anything.  They are instead a polite request to the browser about what to do with our code, which is then transformed into a DOM.”

Principle of Least Astonishment:  things should behave consistently




  • Keyboard and Focus management
  • Form validation
  • Mode conflicts
  • Solutions, workarounds, and considerations



Problem with Custom Controls (not native UI)

Usually created with generic elements like <divs> and <spans>

  • Not keyboard focusable
  • Have a default tab order
  • Behavior unknown

Best solution is to use native controls, or manually define keyboard focus and behavior needs.



Keyboard Issues in a Nutshell

  • Reachability:  via tab order, globally defined shortcut, activating another widget
  • Operability:  all functionality should be doable via keyboard and mouse input.



To be accessible, ARIA input widgets need focus.

  • Tabindex=”0″ element becomes a part of the tab order
  • Tabindex=”-1″ element is not in tab order, but focusable

Each widget should have only one stop in the tab order.  All of your widgets should be reachable via keyboard.  Hans then gave a demonstration of a tree widget, tabbing both into and out of it using JAWS.  This demonstration also pointed out the danger of wrapping a page with a role of application.

An alternative for a roving tabindex is the aria-activedescendant=”<idref>”



Every widget needs to be operable by keyboard.  Common keystrokes are:

  • Arrow keys, home, end, page up, page down, enter, space, esc
  • Mimic navigation in the desktop environment when possible:
  • Always manage and keep track of your focus.  Never let it get lost.

To demonstrate focus, Hans showed a table that allowed deletion of columns of data.  After deleting a column, the previous column received focus.



Skipping Mechanisms

  • Ability to skip content is crucial for screen reader and keyboard users
  • Skip links may be out of fashion and often misused, but users still need to be able to skip.
  • Alternatives:  collapsible sections, consistent shortcuts, custom focus manager



Form validation

  • ARIA makes form validation easier to manage:  aria-required & aria-invalid states, role=”alert” flags validation errors immediately.  Inline and error summary used together are most effective.
  • Validation summaries make invalid entries easier to find

Create a programmatic connection between validation messages and their associated fields.  Maybe there needs to be a W3C specification about how AT is supposed to behave (there’s one for UA).  Hans provided a demonstration of a sample form with required fields.  Tabbing away from a required field activated the “required” error when tabbing into the following field.  He attempted to mark up the fields as live regions, but it didn’t work very well.



Fallback solutions for link buttons

There’s no real consensus on links versus buttons.  Set role=”button” to make links look like buttons for screen readers



Mode conflicts, i.e. Role=Application

  • Screen readers normally browse in ‘virtual mode.’  This means it navigates a virtual copy of the web page.  It intercepts all keystrokes for its own navigation (i.e. “H” for heading navigation.
  • For dynamic web apps, virtual mode may need to be turned off.  Interactive widgets need to define the keystrokes themselves; content needs to be live, not a virtual copy; automatically switches between virtual and non-virtual mode.
  • role=”application”:  screen reader switches to non-virtual for these elements; must provide all keyboard navigation when in role=”application” mode; screen readers don’t intercept keystrokes then, so typical functions will not work.




  • For apps with reading or editing sections (e-mail client)
  • When applied to a container inside an application role, the screen reader switches to virtual mode.

Only use application role when your application actually IS a web application.



Explain to users how Rich Internet Applications work

Put some hidden text at the beginning of the page to explain.



The perfect dialog, in theory

  • Use role=”dialog” combined with aria-labelledby (for dialog title), aria-describedby (for dialog message text)
  • Focus management
  • For modal dialogs:  prevent virtual navigation to background using aria-hidden=”true”


Accessibility Technology

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)


  • 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:



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



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.



“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



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



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



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.




  • 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.



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.



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.



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.



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:



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.



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”



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



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



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



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



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!



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.



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.




….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




<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).



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



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



<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).



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;)



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


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

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



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.




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;}



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.



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)



ARIA Live Regions

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



ARIA Lists

A code example was here with <divs> and lists

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



ARIA ‘fieldset/legend’

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

Radiogroup is not reserved only for radio buttons



ARIA Table Caption

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

<p>Sales increased by…</p>

<table aria-describedby=”salescaption”>



ARIA Pop-ups/Dialogs and ARIA Expanded

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

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



Odds & Ends:  menus, tablists, grids



ARIA Design Patterns for Widget Interaction





  • 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



HTML5 History

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



HTML5 Philosophy

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



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!



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.



The smallest valid accessible HTML5 Document:

<!doctype html>

<html lang=en>

<meta charset=utf-8>


<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.



HTML5 Changes

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

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



New HTML5 Elements

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



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!



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:



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




Accessibility Technology

AccessU at CSUN 2014



Sharron Rush kicked off the event:  This is the second time we’ve brought AccessU to CSUN, we want to bring the excitement and education of our normal three-day event to you here.  We want to bring very specific and useful tools you can use.  We’ve broken this event into three tracks:   advocacy and usability (Sharron), responsive design (Derek), IT/program & project management (Elle).  Attendees are welcome to move between the three tracks as they like.

Elle:  We want to encourage collaboration and sharing of your experiences.  This is a participation sport!  There will be team exercises and things to work on together.  If there are topics you REALLY want to talk about, feel free to contribute to the conversation.

Derek:  as Elle said, we really do encourage collaboration.  Derek then reviewed housekeeping tasks and the day’s schedule; the schedule is at a web site the presenters set up here:  Copies and transcriptions of the question boards posted at the back of the room will be posted to the web site later on.

Just so you understand the rest of this post, you should know that I opted to follow the track Elle ran because a) her past presentations have been extremely coherent, useful, and focused on product management – which is something I care about – and b) I’m a bit of a fanboy.  Onward!


FIRST DEEP DIVE:  9:30 – 10:30 AM

SLIDE:  Key Points

  • Accessibility should pay for itself
  • Building the business case for accessibility is about relationships and trust
  • Building the business case for accessibility is also about being a change agent

Innovation and accessibility are closely related


SLIDE:  Discussion:  Biggest Challenges

  • What are the primary road blocks that you’ve experienced in your organization when trying to build the business case for accessibility?
  • Which departments or roles pose the greatest challenge to your success?
  • What one action could you take next to move this forward?

Comment:  executive buy-in is often a problem.  Lack of prioritization often means that accessibility gets lost in translation.


SLIDE:  How does Accessibility…

  1. Align with your company’s vision?
  2. Align with your company’s business goals?
  3. Position itself as a solution for other teams’ challenges?
  4. Align with your company’s methodologies?
  5. Support your company’s specific user groups?

Answering these five questions will help you orient yourself when discussing accessibility with everyone in your organization.  In many ways, you should be the expert in your organization about organizational objectives and processes.  This will buy you the credibility you need when having those key conversations.


SLIDE:  Team exercise:  company profile

At this point, Elle and Sharron’s groups were together.  We broke up into our constituent groups after going through the bullets below.  After that, “Elle’s group” worked on building a company profile.

  1. Organization type and size (government agency, non-profit, publicly traded corporation)
  2. Who are you?  What do you do?  What’s your company’s passion?
  3. Over-arching business philosophies (eg, Kaizen, Mobile First, Six Sigma, UCD-User Centered Design, ISO9000)
  4. Is there a single project that your whole company is focused on right now or in the near future?

It’s important for you to have as much information as possible about your company’s goals and the people you’re going to be talking to about accessibility.  Here are some key questions you should ask before getting started:

  • Do you have existing development standards at your company?  Can you point your web developers to a document that explains how to build – for example – a form?
  • Do you have a design pattern library?
  • Do you have an accessibility statement?  This is really helpful from a policy perspective.
  • How “established” is your organization’s digital governance?  Is it well-organized?
  • Describe your SDLC.  Does what you say you do bear any resemblance with what you actually do (the quote “we’re a fragile shop” drew a lot of laughs).
  • Get to know your users!  Do it with personas, channels, target markets, etc.  Does your company have regular contact with it’s customers?  What is the typical workflow for people to get their voice heard.
  • What is your organization’s background with accessibility?
  • Has your organization faced any legal action with accessibility?  Sometimes these conversations start based on legal action.

One of the attendees talked about the H&R Block lawsuit that was recently settled.  It entailed relatively minor punitive damages ($133K), but resulted in the institution of major changes in the company’s internal processes.  This included creation of a Chief Accessibility Officer, regular audits, and more.  It’s much better to be pro-active than be forced to do something as the result of legal action.  This has other negative results too, i.e. a tarnished brand image.

Another attendee wanted to talk more about building accessibility into project budgeting.  We did later on when talking about procurement…

What do you do to prevent legal Action?  Having a documented organizational intent with a policy, milestones, and a feedback mechanism often helps to prevent lawsuits.  Lainey Feingold has a great session on this topic later this week, which everyone should attend.

Especially important after talking about legal action:  don’t forget that this effort is about the users!

The Prioritization Matrix (the break out activity)

  • Y-Axis:  Level of Visibility (who could see this web site)
  • X-Axis Regulatory / Legal oversight
  • These axes results in four quadrants, which help you as an accessibility professional target the items that need the most attention in your organization.

As mentioned above, when building the prioritization matrix, you really do have to be more well-versed in organizational priorities than just about everyone else.  When you meet with the people you need to evangelize to, you should probably focus on those items that fit into the top right quadrant (high priority, high regulatory / legal oversight).

I built a matrix with a group of four higher education folks.  Here were the groups:

Government team:  everything is driven by some form of a regulatory requirement.  Some of the regulatory requirements are competing.  Agency home pages are highest priority.

For-profits:  we’re in all four quadrants.  For highly visible public sites where there’s no login or transactions, inaccessible sites will be passed over by our customers.  Internal customer sites are low visibility, but high oversight (i.e. – job postings).  Internal tools used by specific users are generally low visibility/low regulatory and legal oversight.

Higher Ed:  we’re closer to the government model, with a lot of items in the top-right quadrant.  Systems that are required include student information and HR systems, course management tools, and so on.  Items that fit into static web sites often include marketing content that may have high visibility but not a lot of regulatory oversight, i.e. campus tours, about us pages, etc.

Laying your company’s profile over this matrix will help you build your strategy and communicate your message to all stakeholders.

Build your “campaign speech” and include it in every meeting about accessibility you put on, i.e. roadshows, brown bag lunches.  Senior executives should NOT hear this evangelist language from you first, they should hear it from their close colleagues.  Share your wins and share the credit…this will help keep the momentum going.

Question to Elle from the group:  How to you make the roadshow sexy?  While this gets people’s attention, it may not be the very best thing to say…but historically, there are three things that drive online innovation:  gaming, pornography, and accessibility 🙂  It also helps to be a high energy person.  Hackathons help a lot by driving developer excitement.

The Five Ps:

  1. Planning
  2. Policy
  3. Procurement
  4. Process
  5. Professional Development


SLIDE:  Procurement & Compliance

“Cabbages and Oak Trees:”  what are we going to be when we grow up?  You need quick wins with fast turnaround times…but you also need to build something that’s lasting.  You need governance and metrics to be a part of the scaffolding, and you also need to consider whether your organization will fall under ADA Section 3, CVAA, and Section 508.

Process and integration of accessibility is cyclical.  That said, you need to be at the source, at the very beginning…BEFORE the project gets into the kickoff phase.  In other words, be a part of the procurement process!  “Procurement is the ingredients, and implementation is the cake you bake.”  Customers measure the cake, not the quality of the eggs.

Procurement toolkit:

  • Define standards – what are you obligated to meet?  Be comprehensive but not redundant.  Incorporate explicit advice for how you deal with specific things like UX and code standards.
  • Develop a public policy –  key features:  statement should be aligned with your brand promise.  Show the steps you’ve taken and the progress you’ve made.  Show an example of the accessibility features on your web site.  Be sure you have a feedback mechanism with someone minding the store…there’s no point in have a contact e-mail if nobody ever reads or responds to it.
  • Map out your objectives!  Align your initiatives with specific dates.
  • Take an inventory of your vendors.  The main difference between platforms and services is that a platform can snake it’s way into every crevice of your organization, so it’s important to get it right!

Pre-lunch questions:  how many services does your organization use?  For most large organizations, it’s probably in the hundreds.


AFTERNOON:  The Gist of What You Missed, 1:30 – 2:30 PM

Each group leader reviewed what their group talked about during their respective morning sessions.

Sharron:  We are all about the people that we serve,  and that includes both the people with and without disabilities in our organizations.  We define accessibility with respect to people, not standards.  In that vein, we use these concepts:  Perceivable, Operable, Understandable, Robust.  Our group had representatives from government, corporations, and higher education.  We start our process by enlisting executive sponsors, internal and external stakeholders, launch a usability test.  When then talked about the process parts and implementation of a “game plan” over a “roadmap.”  Why do we call it a game plan and not a roadmap?  Because a game plan is more fluid/cyclical and a roadmap is linear.  We then thought through the players we need to involve in our game plan, and how to coach them to work to the best of their ability.  How do we cross-train them if necessary?   We did a quick look at EasyChecks as well.  W3C’s Education and Outreach Working Group is also working on a series of tutorials which will be rolled out over the next six months or so.


Elle:  We talked about building the business case, and then we split out into our “building the business case” groups.  Bold statement:  accessibility should pay for itself, because it builds so many benefits for your company.  It’s also about building relationships of trust.  It’s about being a change agent within your organization.  We talked about developing a company profile risk matrix so that you can map your organization’s risk profile to it.  You then have to be strategic and target those tasks that will have the biggest impact.  Once you have these elements, you take your show on the road and take every opportunity you have to communicate your message.  We also talked about the pillars of accessibility, the 5 Ps:  Planning, Policy, Procurement, Process, Professional Development.  We talked about developing a policy page that articulates your organization’s plan, your roadmap, and a place to highlight your “wins” so visitors can see what you’ve done.  Also be sure to have a mechanism in place that allows visitors to provide feedback, and then actively monitor it!  We finally talked about procurement as a key part of the process that you should bake your accessibility concerns into.


Derek:   two philosophies of responsive design.  One is the “old method” of fixed width, the other “new method” is building for resolution ranges.   Responsive design allows you to provide your customer with more than one way to accomplish a task.  Mobile devices use gestures that may have different meanings depending on the operational mode, i.e. a swipe down means something different when accessibility features are turned on.  Historically, designers have looked at design problems in a very constrained way.  We spent some time looking at mobile devices and how they work with accessible technology turned on.  We showed how the rotor control works on iOS.  We also reviewed a few key concepts, most notably how a change in layout / display may require a change in interaction, role (markup), source order, alt text, state or other property.  A good practical example of this would be a mega-menu.



Back with Elle again…

Procurement as a priority – how do you make it successful?

You can’t sit in on every single conversation where accessibility might be mentioned.  You’re best off getting your language into the boilerplate documentation used by your organization in their day-to-day business.  An example of this would be RFP & RFQ documents.  BUT…how do you make sure that the vendors you’re talking to fully understand what you need from their products with respect to accessibility?

  1. Boilerplate language needs to be in your documents
  2. Vendors need to demonstrate tool accessibility via testing, or a VPAT
  3. Have live discussions with your vendors; use open-ended questions i.e. “please describe your understanding of and commitment to open web standards and progressive enhancement” or “describe what POUR means to you” or “please describe your testing process with individuals, machines, etc.” “who will pay for accessibility deficiency fixes after purchase?”

Question to Elle from an attendee:  is there a list of vendors who are invested in making their products accessible?  Not exactly, but there are a number of vendors that do have excellent reputations.  Loop 11 is a good vendor for doing remote user testing.


Design Pattern Library

Standardization of designs wherever possible is extremely important for providing contextual meaning.  Yelp is one company that has published their design patterns and is worth looking at.  LinkedIn has an interesting way of dealing with developing design pattern standards:  they have a sort of “lab space” where things are being tested but vetted by their accessibility team.  Having a versioning system (SVN, github, mercurial) is important as well.


Role-Based Responsibility Requirements

Take all the roles in your organization that have contact with digital content and make a matrix of what their responsibilities are, and how their roles influence the organization’s response to accessibility.  Accessibility teams that operate as a stand-alone entity generally aren’t as effective.


Distributed Responsibility:  Long-Term Growth

(this description is a transcription of a graphical slide, so the translation may not make sense…my apologies)  Project Management Links directly to Accessibility, while accessibility itself is split between the following tasks:

  • Analysis
  • Architecture
  • Interaction design
  • Content Strategy
  • Graphic Design
  • Prototyping
  • Development
  • Quality Control

We broke up into five groups, each taking on a particular HTML control type.  My group took on the slider control.  We spent our time talking about the specific requirements that would be required to ensure the control is accessible, and who would be responsible for handling each slice of the responsibility pie.  We ended up having ten different roles (i.e. business analyst, marketing, content people, developers, designers, interaction designers, testers, UX researchers, and product managers) to handle each item.

Resources including slide decks, photos, resource links, transcriptions of items written on the easels, etc. will be available at sateach.ex/csun

I hope you find this – the first of many posts – helpful.