Rich Internet App Accessibility

Share on FacebookShare on LinkedInShare on Twitter

Development Newsletter Sign-up Button

Today we have a guest post from Ryan Hemphill and Bradley Momberger about Rich Internet App Accessibility.  Both Ryan and Brad work for Cengage Learning - Ryan is a Senior User Experience Designer-Developer and Brad is a Senior Software Engineer, Front End Specialist. 


When Brad and I first started writing this post, we really struggled. It's hard to know where to begin on a topic as vast as Rich Internet App Accessibility and we have taken a pretty deep dive over the last two years. Some of the major issues could be a chapter of a technical manual all by themselves, easily. We thought it would be best to start by explaining where we're coming from, our primary goals in our work.


Primary Goals:

1. Provide normalized behavior across all RIA-capable screen readers*.

2. Provide normalized support for screen reader, keyboard only, and non-keyboard (i.e., Dragon Dictate) users.

3. Prevent screen readers from breaking when using the application and, conversely, prevent the screen reader from breaking the application itself.

4. Provide robust, extensible patterns that can be used across all software platforms and can also be accomplished after the development is done.

5. Provide complex RIA accessibility implementation strategies that are reasonable quick, easily estimated, and light on bandwidth requirements.


Sounds like fun, right?

It was a monumental task for us to conquer. The reason we used this as our starting point for this conversation is to address where our thoughts on this matter have stemmed from. It was this set of goals that made us realize that ARIA had, from our perspective, a serious strategic flaw. It's missing a pattern that has flourished in web design and development over the last decade. We refer to it as the Christmas Paradigm.

The Christmas Paradigm is our way of describing the basic model behind the creative explosion of design and development on the web over the last 10 years. Why Christmas? Well, much like a CSS-styled <div> tag, a Christmas present is a decorated box whose meaning/value is unknown until the gift itself is "unwrapped" by visual inspection.   An artfully arranged pile of these gifts is compositionally no different than a modern, <div>-heavy HTML/CSS Web page or application. I'm sure that there is a far more technical term for this concept, but what matters is that its lack of semantic rigidity is the key and behind much of the rapid evolution in web design as a whole.

Let's start by talking about the nature of the <div> tag. When the spec for HTML4 was developed, the div was meant to be a container of last resort for data of a form represented by no other element (not a list, table, paragraph, etc). As most Web designers and developers know, this describes most of the presentation data on the Web, and it follows that just about every site on the Web that has graduated past table layouts is dominated by the <div> tag. I am Wild Mass Guessing on the number here, but I'd say that 90% of web page code is dominated by <div> tags. While valid arguments against their overuse frequently pop up in Web design communities, especially when considering accessibility, there is good reason for their prevalence and that is what we're trying to address.


<div> + CSS = Value.


The importance of CSS here is its ability to apply new or different properties to any tag in HTML. What makes the <div> tag so unique is that it has no value. It's equivalent of a blank canvas for an artist, or as we mentioned before, a box - before decoration. It's when you start combining these options into complex designs that results in what the web looks like today, especially in Rich Internet Apps. In fact, a good (although naughty) designer could conceivably create most web pages in nothing but div tags and no sighted user would be the wiser.   You can use <div> tags to create text containers, buttons, backgrounds, images, spacers, page regions, etc.


ARIA in practice.

Now let's take a look at ARIA. Its objective has been to fill in a Web page's missing semantic information, a valuable asset when a page's structure needs to be understood by other software. <div>-MacGuffins are usually the elements most in need of this extra information, since by default they convey practically no semantics of their own. One of ARIA's main jobs is to apply this meaning and value where it has not otherwise been provided. A simple example of this is roles.

Imagine this is a <div> tag CSS'd up as a button

<div id="my-button" tabindex="0"></div>

It can be easily fixed by adding a role like this...

<div id="my-button" tabindex="0" role="button"></div>

It would appear that we are applying properties for semantics just like CSS does for style, it even takes on the inline style-like behaviors used early on. However, the truth is that ARIA is compensating for the <div> abstraction.  We think this is the wrong direction and propose that ARIA should not do this.

It should, instead, aggressively adopt the Christmas paradigm to protect RIA accessibility going forward.

In our next post we're going to show why ARIA needs this strategy so badly, and what we think could be done to enhance the spec...and probably preach a little sacrilege along the way.  };^)

-Ryan Hemphill and Bradley Momberger


Both Ryan and Brad are members of Deque's Accessibility Consultant Engagement (ACE) Program.  If you'd like to be part of this program, please sign up here for the ACE Program.

Development Newsletter Sign-up Button

1 comment

Leave a Reply

You can use these HTML tags:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>