Buzz Archive: February 2006

Kudos to Michigan State

Michigan State University launched a redesign of its Web site, yesterday.

Designed and developed with best practices that follow Web Standards and Web Accessibiity, the university Web site looks good and validates to the XHTML strict doctype.

The redesign involved the teamwork of the MSU Libraries, Computing, and Technology and MSU University Relations.

Congratulations to everyone involved with the redesign!

Visit Michigan State University's About the Site and Accessibility sections for more information.

Visit our WaSP Education Task Force section for information, resources, and interviews of others who have worked on redesigns or advocated change at their schools.

Migration

Steve here, with a brief post asking for your forbearance during the next few hours, as I migrate the Buzz from Movable Type to Wordpress, in preparation for some exciting new stuff coming soon from the WaSP.

NFB vs. Target in perspective

Since the National Federation of the Blind sued Target Corp. for the inaccessibility of its Web site, many people have taken sides, vilifying Target and/or lionizing NFB in turn. I think it's too early for that, if it's necessary at all. In terms of US law, this was a suit that needed to happen, because the case law on Web accessibility is so far pretty thin. The most important thing to take away from this news is that the same case could be brought against dozens of comparable e-commerce sites, and all over problems that stop many users dead in their tracks, and yet could be fixed without affecting their visual design or functionality.

I'm hesitant to paint Target as the solitary enemy of users with disabilities. Let's be clear: The accessibility of Target's site is terrible. But in a short review I did of big-box store sites this morning, they're not the worst around. In fact, they're pretty much the middle of the range.

Take Costco.com. Please. From an accessibility standpoint, if Target is bad, Costco is a godless abomination. Never mind the distinct lack of alt text (which, by the way, is not the alpha and omega of Web accessibility): Costco's homepage contains over a hundred subcategories in hidden drop-down boxes. But they're not links. Noooooo. They're table cells, with mouse events that fire JavaScript functions to load the relevant pages. Nice. The Costco site is not only inaccessible, its code is so poorly designed that its bloated size alone contributes to major usability problems for everyone.

Costco is only one example of many I found. But I'm picking on them in particular because their brick-and-mortar operation is refreshingly progressive. The company prides itself on a "workplace focused on ethics and obeying the law", and has enormous signs at their front door stating that they strive to accommodate the needs of their customers in accordance with the Americans with Disabilities Act.

So, to what do we attribute the utter inaccessibility of many e-commerce sites: ignorance, miscommunication, or malice? I've seen all three in practice. Often, it doesn't take the threat of a lawsuit to get site owners to come around; they merely need to understand the problems, and what they can do to solve them, in order of impact on the user.

But I've also seen cases where it's a legal game of chicken: some companies refuse to comply with a legal mandate that they feel doesn't clearly apply to them. They're gambling that the cost of being found guilty of non-compliance is lower than that of conforming to a standard that may not apply to them. This strategy falls apart like a house of cards as soon as one of them is found liable. And it's a tactic I find particularly odious when they're consciously acting to keep users with disabilities out.

The fact is that the Web has afforded many people with disabilities new-found potential to buy and sell things, work, manage finances, find community, gather news, and access government services -- all things able-bodied people take for granted. When people with disabilities received legal protection, it wasn't given out of pity. It was given to protect their right to participate equally in society. Web designers and developers can enable that equal participation with every site they design, using modern coding principles. Or they can hide in a castle or a cave, clutching their legacy code, certain that those evil, litigious disabled people are out to get them.

So, which is it?

[This entry cross-posted to take your comments and trackbacks.]

Yahoo! Developers: Setting a Standard for the New Professionalism

In an article published Monday, February 13, 2006, Yahoo! Senior Web Developer Nate Koechley outlines the Yahoo! concept of Graded Browser Support.

The approach is a work of art so beautiful and sensible it literally made me weep for joy. In light of ongoing discussion regarding a new professionalism for Web designers and developers, it's clear that the approach that Koechley outlines is not only logical and simple, but also profoundly practical.

One of the most powerful aspects of the document is it approaches the entire challenge of browser support for sites from an enlightened point of view. Instead of calling out any given browser as problematic and focusing on how to manage it, Koechley points to the nature of the Web and its evolution, encouraging us to work within that context:

“Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web. In fact, requiring the same experience for all users creates a barrier to participation. Availability and accessibility of content should be our key priority.”

The report goes on to describe Yahoo!'s definition of browser support, how it approaches “grading” browsers, and outlining a very practical means of addressing quality assurance. Along with the article is a grid that shows grades of support common browsers receive.

That all Web designers and developers seeking to solve difficult browser support concerns should read this article should go without saying.

Putting similar policies and processes in place for any design and development environment, large or small, would be a monumental step forward for not only the cause of Web standards, but improving the quality of the Web itself.

[This entry cross-posted to take your comments and trackbacks].

Staying on Target

A lot can happen in 24 hours.

In the time since yesterday's post, Taking Aim at Target(.com), the Target.com web site has been changed to address at least the image based submit buttons on the Target Pharmacy sign in page. It no longer requires a mouse click to submit the forms.

They literally fixed this overnight. If it took so little time to fix, why now and not ten months ago when the US National Federation of the Blind originally complained to Target?

We have all heard it: "until there's the threat of legal action, companies just won't take notice." It shouldn't take a law suit and significant press and buzz across the web to motivate people into action. If we rely on law suits from special interest groups and then fix those problems, we don't do anything for any of the other groups that require accessibility.

So, a small victory, and kudos to Target for making this change. Too bad the alt attributes for the submit buttons on the sign in page are still missing.

Clearly this is a long way from over and we're all watching with interest.

Taking Aim at Target(.com)

With a name like Target, you would almost think they would have seen it coming, wouldn't you?

The US National Federation of the Blind (NFB) has brought legal action against Target corporation (a major US-based discount retailer which operates more than 1,300 stores in 47 states) because their web site is not accessible. The NFB has raised the issue with Target Corporation before:

The website is no more accessible today than it was in May of last year, when we first complained to Target.

That's about 10 months ago. Sorry Target, but that's just not good enough.

Ten months is more than enough time to fix the issues, or at least get started doing so. (Word to the wise - if you are making accessibility changes to your site based on feedback - make sure you document your process so that you can at least show that you're doing something to address the issues, and if you are doing it incrementally make some sort of public announcment with each improvement you make, ok? You know - that would make good business sense.)

There's quite a few areas that are described as problematic in the official NFB v Target case documents but the main points are:

  • Lack of alt text
  • images maps that neither have alt text or a functional equivalent on the page
  • requirement for a mouse to perform various functions on the site

Honestly - I'm shocked at the first two. This is Accessibility 101. Should be in HTML 101 and Web Design 101 as well. But the third? A requirement for a mouse? I had to see this for myself.

It seems that Target.com uses image based submit buttons for certain forms (<input type="image" .../>). See the Target Pharmacy Sign In page. That's right there's no alt text on the image based submit buttons. Oh, but it gets worse.

When using these type of submit buttons, x and y co-ordinates that represent the exact location in pixels where the image was clicked are submitted along with the rest of the form as part of its array of name-value pairs. And if you use the keyboard to submit the link what happens? No x or y co-ordinates. And if your server side logic requires those x and y co-ordinates? Yes, that's right. You have effectively locked out keyboard users.

This will be an interesting case for a number of reasons:

  1. Target.com is powered by Amazon.com, so who is responsible? are both responsible? a 50-50 split? 75-25? does the Amazon.com engine that is powering the site even allow Target developers make it accessible? Depending on the functionality of the Amazon engine, can it be considered an Authoring Tool and thus subject to the Authoring Tool Accessibility Guidelines? Did Amazon promise accessibility but not deliver? Did accessibility even make it on to the radar when building the site?
  2. other cases have failed for a variety of reasons; the Southwest Airlines case had less teeth because they admitted fully that a screen reader user could still buy tickets online, but it was tougher to do so. Not the case with Target.com. A non-mouse user can not buy online. Nor can they create or sign in to the Target online pharmacy. A screen reader user can not find out what grocery coupons found exclusively on the web they can print to take into the store.

Will the NFB be successful? Can a case like this have an influence on web accessibility in the private sector world-wide? One can only hope. We need this to be big, and we need it to hurt badly so that corporations world-wide take more notice.

Cross-posted to take your comments

For further reading:

!important Fixed in Later IE7 Releases

It was brought to my attention today that the IE7 Beta 2 Preview wasn't honoring the role of the !important declaration and as such was causing alternative box model hacks to fail.

!important is important for several important reasons. First is the very reason !important exists, which is to provide a balance between author and user styles. It has been part of CSS since CSS 1.0, although implemented differently back then.

The other important reason !important is so important in current practices is because it plays a role in 2 of the 3 Alternate Box Model Hacks outlined by Edwardson Tan.

The hacks in question work when the browser interprets CSS properly, and filters correct information to certain browsers that do not. Ingo Chao has documented why this now fails in the current IE7 Beta 2 Preview.

The good news today is that the IE team has in fact fixed the way IE handles !important in all future builds beyond the IE7 Beta 2 Preview.

So worry not, my important friends, we'll soon have an IE that understands just how important !important is.

Note: I apologize if any "importants" were inadvertently left out of this message. I assure you that I didn't mean to suggest they were not (!) important.