Wednesday, August 27, 2008

Target to pay out $6M and have quarterly/annual accessibility tests

Found via Glenda the Good, this marks a huge milestone in moving from infrequently enforced laws regarding government sites to making sites and web applications of private entities accessible to the general public.

"As part of the settlement, Target will establish a $6 million fund from which members of the California settlement class can make claims. In addition, the National Federation of the Blind will certify the Target Web site through its Nonvisual Accessibility Web Certification program once agreed upon improvements are completed in early 2009. Target and NFB have agreed to a three-year relationship during which NFB will perform accessibility testing of the Target Web site. For more information about the terms of the settlement, please visit www.nfbtargetlawsuit.com."

The $6,000,000 fund doled out to those who file claims will draw attention to this, but to me the (comparatively) rapid compliance and ongoing tests make this worthwhile. Target won't just throw money at the issue, but will make its site accessible to those using assistive technologies, and maintain that for at least three years following!

Labels: ,

Monday, July 07, 2008

W3C recently posts updated docs on relationship between usability and accessibility

The W3C posted an update to the Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG), something which I (for some reason) don't remember seeing go by in January when they posted the initial draft.

Work like this means a great deal to web developers who promote accessibility, as most people regard accessibility as little more than a drain or a checkbox on a compliance to-do list. The MWBP and WCAG relationship guidelines look at the similarities in issues and solutions found in each working group, providing a comprehensive list of direct connections between accessibility and usability. Until seeing this work, I have had little reference material to offer those who questioned my (and others') relentless insisting that they should use accessible markup and scripting in order to make their web applications both accessible and more usable in one fell swoop. All efforts had previously resulted in spontaneous lectures at the nearest machine where I could demonstrate examples, and (more recently) Chapter 1: Usability and Chapter 2: Accessibility in Advanced Ajax: Architectures and Best Practices.

The current MWBP and WCAG relationship guidelines have the following in-progress sections available, which will all prove exceedingly useful to web developers and designers, especially for those learning about one side of this after implementing the other:

These sections cover specific examples of matching mobile web usability issues with accessibility issues, ranging from color contrast requirements (...unfavorable ambient light and the ability of devices to display contrasting color at all, while users may have color blindness and color perception deficits...) to the fact that large amounts of dry text becomes equally unreadable for those with attention deficit related disabilities to those with postage stamp-sized screen. Anyone who had clicked impatiently through an EULA displayed in a one-inch textarea knows the latter of these two quick examples all too well.

For a quick introduction to the correlation between web accessibility mobile web usability, the WAI has posted Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices as part of their Implementation Plan for Web Accessibility.

Labels:

Saturday, May 05, 2007

Support for different HTTP status codes with Ajax

While writing about adding support for different status codes into the AjaxRequest object (very easy, as I'll show momentarily), I made a little test page to try each of the initial set: HTTP Status Codes. Just click each link (check Firebug) and it optionally fetches all, part, or none of a 400-line file.

Now on to the excerpt:

Most browsers and XML feed readers take full advantage of the HTTP/1.1 specification to greatly reduce the data sent from the server, and the XMLHttpRequest object gives developers access to the same functionality. Two intertwined aspects of the HTTP/1.1 specification in particular can help Ajax-driven applications: status codes and cache-control.

Supporting these in the previously defined AjaxRequest object comes easily. It already supports setting custom headers through its headers object, just like setting GET and POST variables. In order to support the various status codes that the server can return, it just takes adding event types and adding some more flexibility to the stateChanged() method by changing it from:

// Event dispatching
AjaxRequest.prototype.events = {
  abort : [],
  data : [],
  load : [],
  open : [],
  send : [],
 };

// Callback for this.xhr.onreadystatechanged
AjaxRequest.prototype.stateChanged = function() {
 // Only trigger load if finished returning
 switch(this.xhr.readyState) {
  case 3:
   var e = new AjaxEvent(this);
   this.dispatchEvent('data', e);
   break;
  case 4:
   // Only continue if status OK
   if (this.xhr.status == 200) {
    var e = new AjaxEvent(this);
    this.dispatchEvent('load', e);
   }
 }
}

...to a new version that can handle multiple status codes:

// Event dispatching
AjaxRequest.prototype.events = {
  abort : [],
  data : [],
  internalservererror : [],
  load : [],
  notfound : [],
  notmodified : [],
  open : [],
  partialload : [],
  requestedrangenotsatisfiable : [],
  send : [],
  unauthorized : []
 };
// Simple lookup of event types by status code
AjaxRequest.prototype.statusCodeEvents = {
  200 : 'load',
  206 : 'partialload',
  304 : 'notmodified',
  401 : 'unauthorized',
  404 : 'notfound',
  416 : 'requestedrangenotsatisfiable',
  500 : 'internalservererror'
 };
// Callback for this.xhr.onreadystatechanged
AjaxRequest.prototype.stateChanged = function() {
 // Only trigger load if finished returning
 switch(this.xhr.readyState) {
  case 3:
   var e = new AjaxEvent(this);
   this.dispatchEvent('data', e);
   break;
  case 4:
   if (this.statusCodeEvents[this.xhr.status]) {
    var e = new AjaxEvent(this);
    this.dispatchEvent(this.statusCodeEvents[this.xhr.status], e);
   }
 }
}

The new implementation of stateChanged() now simply triggers the event mapped to the returned status code from the request, if the AjaxRequest object implements that event type. While the list of status codes only includes the most commonly used codes for this chapter's usage, it can include any additional codes added to the events and statusCodeEvents objects.

Labels: , , , ,

Saturday, April 14, 2007

WAI-ARIA makes life much easier

I decided to re-post here my comment to the A List Apart article, Accessible Web 2.0 Applications with WAI-ARIA, as it seemed from most of the other comments that people don't really see just how much WAI-ARIA will help both developers and users.

In the current methods of adding screen reader support (see an example at Juicy Studio with excellent descriptions), it takes a lot of scripting in order to dynamically inform a screen reader that things have changed. These methods also rip the user out of whatever they’ve started reading or writing at that time, and drop their cursor wherever the change occurs. The later versions of Jaws don’t quite do that, but in order to support a broader user base, you need to do it that way...Jaws costs a lot of money for an individual to keep paying for every year.

With WAI-ARIA, this gets handled just by adding an attribute of aaa:live, and you can fully control the urgency with which the screen reader will read the updated DOM elements! This not only keeps the user in their current context, but allows “polite” live elements to wait for the user to complete their current task before the user needs to hear it. Errors and other urgent information can either user “assertive” or “rude” in the worst case scenarios.

This doesn’t even touch on some of the benefits of the other attributes available, but just the aaa:live attribute itself makes screen reader support infinitely easier to implement and much, much more flexible.

You can see some good examples on the Firevox (open source, cross platform Firefox screen reader) site.

Yes, this very new working draft has some time and work before it exists as a specification. But it needs support from developers in order to take off some of its rough edges, and for the more widely-used screen readers to start paying closer attention. WAI-ARIA can only help developers and we have every reason to help push this project forward.

Note: I edited the comment to use actual links and markup...and to fix some spelling errors.

Labels: , ,

Monday, March 12, 2007

Opera Developer Console

It figures I would find this as I wrap up the initial draft of the chapter on client-side debugging, but it makes me extremely happy to see it: Opera has started work on a Developer Console, which (among many other things) logs XMLHttpRequest calls.

An Opera debugging window showing HTTP, Cookies, and an XHR logger.

The Opera Developer Community runs through some of the DOM, JavaScript, and CSS tools, and the Opera Desktop team posted about it over a month ago when they initially started putting it into their development builds.

From what I can tell by peaking at the source (since, like most Opera extensions, they wrote it in JavaScript), it looks like they made a simple wrapper object and replaced the native object (after storing a backup reference for when logging gets shut off again) in order to create hooks into each of the events so it can report everything as it happens.

This means that I can now debug XMLHttpRequest usage in more than one browser, which makes life much easier than either guessing how it went or using a standalone traffic sniffer.

Edited two minutes later to add: you can get it from the Opera Developer Tools page.

Labels: , , , , ,

Wednesday, February 28, 2007

Last call for the XMLHttpRequest object spec

The working draft for the XMLHttpRequest object has just reached the Last Call. As someone who touts the use of web standards fairly heavily, both in and out of the book-in-progress, having the ability to stop saying,"Follow web standards...except for this one bit of functionality the entire application centers around," definitely appeals.

Labels: ,

Friday, January 26, 2007

Contrast comparisons

dark text on a black background darker, partially unreadable text on a black background

A color of rgb(100, 100, 100) on black has a luminosity contrast ratio of 3.550595556268441, falling short of both Level 2 and Level 3. When enhancing contrast and having such similar colors, it actually lessens the readability.

lighter text on a black background lighter, sharper text on a black background

A color of rgb(150, 150, 150) on black has a luminosity contrast ratio of 7.2236099811596866, which meets Level 2, but falls short of Level 3. Enhancement at this level sharpens the letters more than increasing the contrast between the text and the background.

even lighter text on a black background even lighter, sharper on a black background

A color of rgb(200, 200, 200) on black has a luminosity contrast ratio of 12.719459678993227, which exceeds Level 2 and Level 3. Enhancement at this level also sharpens the letters.

Side note: I kind of wish I had found the Colour Contrast Analyser Firefox Extension before writing the "High Contrast Design" section of the chapter.

Labels: , ,

Thursday, January 25, 2007

CSS3

I know we still have quite a bit of lobbying and pestering to go before IE7 version X supports even CSS2 in its entirety. That said, the Opera team has continually updated their progress in support for CSS3. Several browsers, at this point, have adapted rudimentary versions of CSS3 columns support, as well as transparency, shadows, and background manipulation.

The latest post on Opera's CSS3 support has some very promising aspects to it, considering that functionality such as alternating table row styles, special formatting of empty elements, all off the of-type rules, and many more have the potential to reduce the workload of designers and developers by quite a bit. I know that I, for one, have emulated most of those mentioned using extra markup, scripting, or both throughout the last few years...

Labels: ,