So how do visually impaired people watch The Simpsons? With the Descriptive Video Service (DVS) of course. DVS is an audio track that explains the action taking place in a television program. With The Simpsons that includes reading all of the oddball signs that fly by during the course of an episode (not to mention Bart’s scribbling on the chalk board at the start of each episode).

WFMU’s station manager Ken has an interesting post about his accidental discovery of the DVS signal while battling with his broken VCR. Like many people, he hadn’t really given any thought to how visually impaired users might watch and enjoy programs like The Simpsons. At first he assumed The Simpsons were doing a parody of Arrested Development.

Ken also makes some interesting observations regarding censorship and editorializing on the DVS track, but that’s probably a topic for another post on another blog.

At any rate, if you’re interested in hearing what the DVS track for The Simpsons sounds like, Ken has posted an entire episode available for download.

• The Simpsons as Described by WGBH

For those of you who aren’t familiar with the term, a folksonomy is basically a taxonomy created by the people and for the people. A community of users collaborates by “tagging” various types of content with user created keywords. This concept is flourishing on a handful of community driven sites that all seem to have a certain addictive quality. I think the best way to fully grasp how folksonomies work is to dive into one of the sites that makes use of the concept. Flickr, 43things, and del.icio.us are good places to start. Given the success of these early experiments in group tagging I have no doubt that we’ll be seeing folksonomies implemented on all sorts of sites in the very near future.

Lately I’ve been thinking about one particular artifact of the folksonomy phenomenon — the folksonomy menu that serves as a sort of buzz index providing users with a quick visualization of the most popular tags (technically I think it’s called a weighted list). Popular tags are displayed in a larger font and it’s relatively easy to identify hot topics at a glance. This visual representation of the popularity of any given tag is undeniably cool. However, once the coolness factor wears off it becomes fairly obvious that these menus are also not very accessible.

I realize these sites are currently trail-blazers and they deserve to be recognized as such. I have no intention of detracting from the innovative work that’s being done. My concern is that once folksonomies enter the mainstream, the next wave of sites implementing them will likely begin a wholesale copying of the work that’s being done by these innovators — markup and all.

Also, I need to point out that folksonomies are community driven. A few minor changes to the existing markup would go a long way towards making these communities accessible to everyone.

Analysis of the accessibility of weighted lists on five websites using group tagging and folksonomy

I spent an afternoon looking under the hood of the folksonomy menus on following sites:

• Technorati
• Flickr
• 43 Things
• del.icio.us
• MetaFilter

I was somewhat surprised to find that the markup on each of the folksonomy menu pages was entirely different. While all sites were basically implementing the same type of menu they all arrived at their respective results in different ways. Given this finding, I was even more surprised to note that each site shared most the same accessibility problems:

• Unstructured Links: With the exception of Technorati, each of these menus was rendered as an unstructured collection of links separated by only whitespace or a non-breaking space entity. It seems fairly obvious that these links constitute a list. Rendering these items as a list would provide visually disabled users with more feedback regarding the number of links as well as the ability to skip the list entirely.
• Extraneous Markup: While not technically accessibility related, each of these pages uses a fair amount of extraneous markup to achieve its goal. I encountered a startling number of span elements accompanied by inline style declarations. And while Technorati wins points for realizing that these links are actually a list, they should also win an award for the most creative use of the EM element.
• Absolute Font Sizes: Without exception fonts were defined in pixels. As a result I was unable to resize type in Internet Explorer. This was somewhat puzzling given the fact that it would be fairly easy to implement the font size variations using em’s. del.icio.us actually went as far as defining the font size in fractional pixels extended to the 13th decimal place. They must be using one of those 30 inch Cinema Displays .
• Lack of Context: These menus currently require a user to actually view the page in order to discern the relative popularity of tags. There is no additional context that could be used to determine popularity. Given the fact that the difference in font size for any pair of tags can be as little as a single pixel, additional context would also be useful to those who are not visually impaired.

Recommendations:

The good news is that these issues are all easily fixed. Most of the solutions will be quite obvious.

• Use Lists: Lists have become the standard way of rendering a collection of links. Lists provide additional structure that can have a significant impact on accessibility.
• Avoid Inline Style Declarations: I’m sure there’s room for debate on this recommendation, but personally I would assign a class to each LI element. There’s really no reason for extraneous elements or inline style definitions.
• User Relative Font Sizes: Defining font sizes in em’s would allow users to easily resize type in any browser. Fractional em’s are easy to calculate, and they make more sense than fractional pixels.
• Add Context: While it’s not a perfect solution, it might be a good idea to add each topic’s relative rank to the title attribute of the anchor. Something like title=”Politics – Rank 3 or 10″.
• Consider Alternate Views: There’s no reason that the current standard folksonomy menu has to be the only way of representing the relative popularity of tags. An ordered list sorted by popularity would eliminate some of the need for visual clues. Adding a link to such a list would provide users with more choice while addressing accessibility concerns.

Here’s a page demonstrating my recommendations.

I realize that it can be challenging to focus on these types of details while innovating in the way that each of these sites has. While folksonomies are still relatively new, I think we’ve reached a point where it’s time to start thinking seriously about best practices.

One of the stated goals for the site was accessibilty. Granted, this was not the term used, but as we went through the process of identifying the site’s customers, local senior citizens were mentioned. Because this is a city website, they do not have to comply with Section 508 — however, as many local government agencies choose to do, the city made compliance a goal. Throughout the design process, we kept this in mind, and, because the backend of the site is a content management system, we included “hooks” to ensure things like alt attributes weren’t forgotten.

Okay, fine. Mission accomplished.

Sort of. The day-to-management of the website is handled in a decentralized manner by non-technical staff. The final review before new content is published is done from an an editorial perspective — the webmaster doesn’t know HTML, and the chances of her learning it are slim. When we loaded the original batch of content on behalf of the client, we converted as much as possible to plain HTML. Unfortunately, due to a variety of factors, not everything could be converted, and there are many documents posted as PDF files.

As the person tasked with converting the bulk of the content on the site, I realized that the goal of accessibility faced multiple challenges, all which are part of a bigger challenge:

• Non-Technical Staff Updating The Site. Have you ever tried to create an accessible table in HTML? I have, and it’s not a simple process. In fact, if you don’t do it regularly, you’re going to require a refresher course. Every time you create a new table. Let’s see, you have the actual table structure, the summary, the caption, grouping of columns and/or rows, the thead, the tbody…I’m sure I’ve missed a few pieces, but you get the picture. Just the idea of explaining the differences between caption and summary makes my head spin; if you want enforcement, we need to talk.

  Basic HTML is easy, but most people think it’s hard. Hard enough that they don’t want to be bothered learning it. I see this every day. A WYSIWYG HTML editor works just fine for the average content creator. When you get to fun stuff like acronyms and abbreviations and the art of remembering what code works with which browser, you’ve lost your audience (heck, even if you get someone who has the time and energy to do the right thing, there will always be a few who pop out of the woodwork to argue the semantic differences between acronyms and abbreviations). Coding for accessibility is easy when you’re looking at lightly formatted content. It’s not easy, as evidenced by the various discussions on the WAI lists, when the requirements of the content move beyond the basics.

• Time and Money. Our content migration process bumped up against the very real constraints of time and money. Like most cities, the particular agency didn’t have unlimited funds to devote to the project. As it was, we took a loss on this aspect of the project, partially because we, the developers, were committed to doing it right. Even so, we were confined by project deadlines. Eventually a site must be handed over to the client and launched.

  As staff integrates updating their areas of the website into their day-to-day activities, they will also face this challenge. Content will be added between meetings, phone calls, constituent questions, even emergencies like fires (including while the fire is raging). Careful HTML coding will necessarily give way to “get it up fast” attitudes. This organization cannot afford the luxury of a full-time staff member working on the website. The webmaster mentioned above already has a full, full-time job; the mandate to increase web content adds to her job.

• Lack of Effective Tools. As noted, we posted a lot of items as PDF files. Sometimes this was because of the time/money issue; sometimes it was because the documents were heavily formatted and converting to HTML didn’t make sense; sometimes it was because the information presented didn’t lend itself to HTML — like complex spreadsheets. Inevitably, these documents were created in applications such as Word or Excel and converted to PDF.

  Yes, Acrobat has accessibility tools. Have you used them? Even well-formatted Word documents require scrubbing after conversion. And I doubt anyone is going to pretend that the vast majority of Word documents are well-formatted. Drilling down into documents and fixing conversion errors is a time-consuming process. See above for more information on why this is a problem.

  For some documents, there’s the option of copying and pasting from Word. The CMS used by the city allows users to copy items as plain text, and we trained them on this process. A few people will likely remember the steps for stripping out the extraneous Word code and there’s an extra process run on content to clean up the HTML as much as possible. Bottom line, of course, is that these are band-aids, and most users will copy and paste directly into the HTML editing box, note that the document “looks” okay, and post. All of the lovely semantic coding will be forgotten because very few word processor users consider structuring their documents properly.

  If Word allowed someone to copy and paste plain text, maybe the final result would have better structure because the HTML mark-up tools in the editor would provide structural elements. Personally, I’d advocate for removing the bold, italic, underline, font selection and size options from the toolbars. Clearly, nobody’s asked me, and users will continue to hit the “B” button at will.

We did everything we could — from design to tool integration to template development to training — to ensure the goal of an accessible website was met. Now the full burden of maintaining the site is on non-technical staff. This is not an uncommon situation — in our experience, more websites are maintained in this manner than are sites under the control of individuals who live and breathe HTML with all of its nuances. Whenever I read that content owners “should” do this and that to achieve accessibility, I wonder how many people dictating the “shoulds” actually understand the process from the perspective of someone who drew the short end of the straw and must now add updating their department’s area on a website to their daily duties?

When we work with clients, nobody questions the goal of accessibility. Quite the opposite. But businesses and government agencies do not have unlimited resources, and they don’t always have technically-oriented staff. I realize there are many individuals pushing for improved user agents and technology; until someone can copy and paste clean HTML from Word or convert to a well-formatted (even if structurally incorrect) PDF file, websites will be littered with the ghosts of well-intentioned content authors who had to balance the “shoulds” with reality. It probably wouldn’t hurt if actual coding guidelines were evaluated from the perspective of people in the trenches, either.

[t]he Attorney General opined that the Americans With Disabilities Act requires that private web sites be accessible to blind and visually impaired Internet users. The ADA generally dictates that all “places of public accommodation” and all “goods, services, facilities, privileges, advantages, or accommodations” of places of public accommodation, must be made accessible to disabled citizens, absent undue hardship. New York law provides similar civil rights protections.

Priceline and Ramada will reimburse the state for its costs as well as make necessary changes to their sites. Priceline has reportedly already begun work to make its website more accessible, and, according to the Washington Post sought to reassure investors that the settlement is not a blow to the company’s bottom line.

[Priceline's Brian] Ek said the firm encourages other firms to do the same. He said the firm isn’t releasing the cost of making the entire site accessible for the visually disabled, but said it won’t be enough to reduce earnings.

Our Analysis of The Settlement

This settlement is particularly interesting in light of a previous ruling that determined the opposite. That case (02-21734-C1V – Access Now/Gumson vs. Southwest Airlines) turned on the fact that the web does not occupy physical space; the judge believed Congress’s specificity in defining public accommodations limited the act to physical space. That Spitzer believed otherwise is precedent setting. As the businesses in question clearly engaged in commercial operations, they can be defined as public accommodations. The Internet was not contemplated when the ADA was written, but in 2000, a Congressional hearing concluded:

…the ADA does apply to the Internet, and . . . [due to] the substantial First Amendment implications of an application of the ADA to the Internet, the development of a legislative record on these issues now would likely prove valuable to all interested parties.

We expect this settlement will lead to increased lawsuits, with the ultimate result being the amendment of the ADA to include websites under the umbrella of public accommodations. At that point, it will be become more expensive for businesses to try to achieve compliance as they’ll be facing increased penalties.

Businesses who launch new websites subsequent to this ruling will likely be targets for lawsuits given that precedent has been set. Ensuring WCAG compliance prior to launch will not only save money, but will reduce legal bills.

Spitzer’s settlement is also interesting because of what it doesn’t cover. Perhaps because the lawsuit was brought on behalf of only one disabled group, the settlement and website fixes are focused solely on increasing accessibility for blind and low-vision users. It is unclear as to whether Spitzer purposely limited the scope of the settlement or he was unaware of the wide range of other disabilities the accessibility guidelines address. It will be interesting to see how the two sites in question approach retrofitting their websites, and whether or not they address a broad range of disabilities or not.

We believe this settlement will lead to increased awareness, and, yes, more lawsuits as Americans fight for accessible websites. While most non-web professionals and many web professionals remain unaware of web accessibility guidelines, advocacy groups for disabled persons will use the settlement as a platform for educating both the public and Internet community on the issues created by inaccessible websites. Web developers who understand Section 508 (which applies to Federal government websites, but is often voluntarily adopted by state and local government agencies) or WCAG (even as it evolves) will be in a strong position to assist clients making the transition to accessible websites.

• Spitzer Agreement to Make Web Sites Accessible to the Blind and Visually Impaired
• Priceline, Ramada to Make Sites More Accessible to Blind
• Judge: Disabilities Act doesn’t cover Web
• United States District Court Southern District of Florida Case Number 02-21734-C1V (Access Now/Gumson vs. Southwest Airlines)
• Applicability of the Americans with Disability Act (ADA) to Private Internet Sites

As the decade progressed and web authoring tools became commonplace, most cities advanced to the point where they had at least a token web presence. While the sites were primitive when compared to commercial websites, local government saw the Internet as revolutionary. Suddenly there was this great tool that could be used to quickly disseminate all kinds of information to the community. Best of all, the medium was relatively cheap. There was incredible excitement about this new high tech, cost effective information delivery method.

Needless to say, accessibility was not a consideration in the early days of the web. As we discovered in our recent survey of municipal web accessibility, it’s not much of a consideration today, either, despite the pressing needs of each agency’s constituency. Of the 408 California cities we tested, 91% failed to achieve Section 508 compliance. The numbers were nearly as bad for the WCAG guidelines, with 89% of the sites failing to achieve WCAG’s Priority 1.

Our findings indicate that the vast majority of city websites are frozen in time — not only are they inaccessbile, but most are unsuable. The only change in the past nine years is that most cities appear to have forgotten why they embraced the web in the first place. The novelty of the Internet has worn off, and unbridled enthusiasm has been replaced by the day-to-day realities of posting city council agendas and annual financial statements. The result is that many cities put little effort into improving the quality of their websites.

This failure is a shame for a couple of reasons:

• For the disabled, including many senior citizens, the Internet is usually the most convenient way to interact with local government agencies. It’s generally safe to say that disabilities frequently result in mobility challenges. For disabled individuals, a trip to city hall might require as much planning as a trip to another country.
• The Internet remains a cost effective information delivery platform. In California (and around the country), municipalities struggle to do more with less. The web represents their best hope for continuing acceptable levels of customer service in the face of shrinking budgets. It is arguable that the failure of municipalities to effectively deliver accessible web content actually costs cities money — in both direct costs and indirect costs such as valuable staff time expended fulfilling routine information requests that could easily be routed through the city website.

In addition to accessibility-related problems, most municipal web sites exhibit significant usability problems. In fact, many of the sites we evaluated were challenging to use even before we factored disabilities into the mix. As we performed manual testing, we noted dozens of common usability issues ranging from poorly coded JavaScript menus to extensive use of uncompressed image files, which created unnecessarily long page load times.

Lack of consistent navigation was one of the most widespread problems. Time and again, we were dropped into a site with no roadmap forward or backward. As mentioned, city websites can impact direct and indirect costs, yet we suspect most constituents give up in frustration a few clicks into the website. We’ve noted nearly a dozen common usability issues that were present on nearly every site that was tested manually. If our experience is any indication, best practices are almost non-existent on municipal websites.

Testing Notes:

We limited our testing to municipalities in the state of California (primarily because that’s where we’re located). We tested 408 city websites in two phases. The first phase involved automated testing using the Bobby testing tool. Sites were tested for compliance with Section 508 and WCAG 1.0. Following the initial testing phase, a secondary manual testing phase was undertaken to confirm the Bobby results. Approximately 75 sites were tested manually, including all sites that passed the initial test. There were several instances where sites passed the automated test, but failed manual testing. In most cases, these sites had poorly coded splash pages that were unusable without images. When in doubt, we accessed sites using the text-based Lynx browser. Questionable sites that passed automated testing, but were unusable in Lynx, were failed.

I’ll be the first to admit that our results may be somewhat misleading. We only tested the home pages of the sites. In nearly all cases, further testing would lead to a higher rate of failure. In some respects, we tried to be generous in our testing. We’re of the belief that it’s better to encourage the few that are close to compliance than it is to prove beyond a shadow of a doubt that absolutely no sites are in compliance.

I should also note that Section 508 is a Federal standard. Municipalities are not bound to comply to Section 508 or WCAG. Frequently, however, we find that municipalities identify Section 508 compliance as a voluntary goal because of the important role their sites play in day-to-day operations. Unfortunately, many agencies seem unaware of the details of Section 508 compliance, or the fact that maintaining accessibility is an ongoing process, rather than a one-time effort. We hope our survey raises awareness of this important issue and look forward to hearing from municipalities who wish to be proactive in making their sites more accessible.

• Read the complete Alt Tags Municipal Accessibilty Survey Results

Our complete report details our findings and recommendations for municipalities wishing to improve the accessibility of their websites. We’re presenting our report in a PDF format and encouraging readers to pass this on to interested parties in hopes that we can raise awareness of this important issue.

• Alt Tags Municipal Web Accessibility Report

Against a backdrop of hyper sensitivity to accessibility issues Veen steps up and announces, “I don’t care about accessibility.” Veen’s proclamation was met with a few nervous chuckles followed by an uncomfortable moment of silence before he began to build his case.

Veen, of course, was exaggerating his position to make a point. After proclaiming he didn’t care about accessibility, he went on to explain what he does care about: professional web design practiced as a craft by skilled practitioners who understand the limits of the media as well as the opportunities presented by the media. He noted that in the past he always had problems working with print designers who felt constricted by the limitations of web technology — but those designers are no longer a problem for him because he no longer works with them. The designers Veen works with now are steeped in web standards and interactive design, and welcome the challenges of their chosen media. Because Veen is now fortunate enough to be working with skilled web craftsmen, accessibility is much easier to achieve.

He went on to demonstrate a few standards based sites that degrade gracefully and work well with assistive technologies. His presentation was a welcomed contrast to what might have turned into a prolonged debate on the proper implementation of access keys.

For me, this was one of the most memorable presentations at this year’s SXSW — others must have felt the same since a Google search on “Veen ‘I Don’t Care About Accessibility’” returns 316 hits (that’s about two results for every person in the room at the time Veen made his comment, but since he was also working the back channel via iChat there may have been some remote participants).

Matt May has another perspective on Veen’s now infamous assertion. In his post titled I Care About Accessibility, May is concerned that some designers may have taken Veen’s claim at face value, while missing the rest of his message. One can only imagine what sort of damage the ‘I Don’t Care About Accessibility’ meme might inflict on the efforts of accessibility advocates everywhere. I can already hear the phrase “But Veen said . . .” ringing through conference rooms across America.

I have to admit that there is a certain danger in taking Veen’s approach — especially in a world where so many decision makers are just now learning about the issue of accessibility. In many cases those same decision makers are also looking for an easy way out.

I was pondering all of this yesterday when I received the latest press release from UsableNet. The message was touting the latest succesfull implementation of the LIFT Text Transcoder. The County of Sacramento has just implemented LIFT on 40 county-run websites.

For those of you who aren’t familiar with the LIFT Text Transcoder, it’s a product that will automatically create a text-only version of your entire website. According to UsableNet:

“LIFT Text Transcoder allows you to easily and quickly add the valuable “text-only” version to every page on your web site, providing the best possible access to your site for people with disabilities.”

“The best possible access” for people with disabilities? There are so many things wrong with this claim, I’m not sure where to start. Aside from the fact that this statement assumes that all disabled users are visually impaired, it also makes the false assumption that all web content is magically made more usable by simply removing images.

A quick review of the Sacramento County website should dispel anyone of this notion almost immediately. The home page’s HTML doesn’t validate, there are several accessibility problems on the entry page, and the cluttered design and seemingly random navigation is far from usable. Ah, but there’s that ‘text only’ link near the top of the page. If (and that’s a big if) this site’s disabled users make it that far they’re treated to a plain-text version of the home page that, while technically compliant with section 508 guidelines, does not in any way provide a better user experience. It’s certainly no easier to navigate, and extremely challenging to find anything useful (although we are informed that the site banner is a “Collage with basketball, ballet and river boats”).

The problem with products like the LIFT Text Transcoder is that they appeal to people who really don’t care about web accessibility. Decision makers who have just been informed that they have a problem they were not previously aware of are usually looking for the quickest possible solution. If that solution comes in the form of a piece of software that purports to provide “the best possible access” for people with disabilities, you can probably guess what decision will be made. Executives will buy LIFT thinking they’ve just bought a lifetime pass on the accessibility issue — problem solved. Meanwhile, the underlying structural problems that contribute to the most common accessibility and usability problems go unaddressed.

In UsableNet’s defense, they do make a variety of other tools that appear to be more substantial than the LIFT Text Transcoder, and elsewhere on their website they note:

“LIFT Text Transcoder is not a complete solution for providing an accessible website”

Despite the disclaimer, I think the damage has already been done. I doubt that many decision makers looking for a quick fix will make it this far. Even if they do, they’ve already been conditioned to think that accessibility is a problem that can be addressed with automated technology and minimal human intervention. Worse, these systems seem to reinforce the belief that web design is the end result of some commmoditized product, rather than the result of an ongoing effort to improve communications by crafting a quality user experience. The former is cheap and requires little thought. The latter is hard and requires organizational commitment.

In contrast to LIFT’s automated approach to accessibility, Veen’s position seems positively enlightened. The Veen approach places an emphasis on well architected information, good design, educated designers, and a commitment to standards. While these elements are not always guaranteed to produce accessible web content, they’ll usually get you pretty darn close. In most cases close enough to bring your site into compliance with a minimal amount of effort. The result will almost certainly be a better user experience for all of your users.

Links:

• Matt May – I Care About Accessibility
• Jeffrey Veen – I Don’t Care About Accessibility
• UsableNet’s Text Transcoder
• Sacramento County
• It Could Be Worse
• Zeldman On Lift

While there are now numerous examples of major corporate websites adopting web standards, there’s nothing to keep the public/non-profit sector from following suit. Web Standards are for everyone. With a bit of education, advocacy, and training, non-profits can easily reap the benefits of standards in the same way the corporate sector is.

It seems quite obvious that corporations are not adopting web standards because of some innate sense of social responsibility. Businesses are attracted to standards because of the many cost related benefits they offer. Standards offer lower cost of maintenance, ease of implementation, and better cross-platform support. It just so happens that increased accessibility is a byproduct of using the most recent technology.

Non-profits and government agencies should realize they can lower their costs and improve the quality of their websites by embracing standards and by rejecting authoring tools that mangle code. In most parts of the world non-commercial agencies are under increased pressure to do more with less. What better way to economize than to make a commitment to standards?

Has your educational, non-profit, or government agency made a commitment to standards and accessibility? If so, leave a comment telling us about your experience. And by all means, link to your site.

Okay, maybe not everything. Human and machine. We’ll leave the rocks and minerals to sort out their own computing issues.

So why is this important? Well, a usable site gets used. Sounds like I’m stating the obvious, doesn’t it? If you’ve spent more than five minutes on the Web, you’ll realize I’m not. Setting aside the issue of accessibility (which I believe is a big part of usability), most sites are designed without the end user in mind. The focus is on…well, I don’t know what the focus is; all I can assume is that the person trying to access, buy, or read the site wasn’t considered by the design team.

Where usability and accessibility intersect is at the non-technical aspects of your website. The organization of the navigation. The organization of information. The clarity of the writing. The ease of completing tasks. When we visited the Knowbility booth at SXSW 2004, we sat down with Wen, an experienced JAWS user. Given the overall accessibility of our site, she had no trouble working it. It was only as I listened to the site (rather than my normal visual skimming for topics of interest) that I understood where we could improve on our usability.

This experience led us to think about our work in a different way. As we reviewed a content item we’d posted for a client, we agreed it was well-formatted, clear, and understandable. We also agreed that we could make it just that much better by adding bulleted lists (which we can stylize using CSS). Doing this will make it easier for non-sighted users to quickly move through this rather lengthy document of names and contact information.

For most of our clients, sitting down and thinking about how to make something good even better isn’t a luxury they can afford. Get it up and move on is the basic goal. As the developers, it’s something we can both consider and address — by improving the tools we provide our clients, we can improve both the usability and accessibility of their sites. We can help them achieve their number one goal: universal access.