Zero to One-Eighty » markup

The accessible presidency

Adrian Cooke — Sat, 15 Nov 2008 18:21:35 +0000

Obama’s first address is available from YouTube, et al., and as Quicktime, from change.gov

It was all over the news yesterday: the Washington Post is calling it the YouTube Presidency. When it comes to embracing the web as a medium of goverment the new administration is off to an ambitious start:

Throughout the Presidential Transition Project, this website will be your source for the latest news, events, and announcements so that you can follow the setting up of the Obama Administration. And just as this historic campaign was, from the beginning, about you—the transition process will offer you opportunities to participate in redefining our government.

In terms of web accessibility they are doing pretty well, though there’s room for improvement with the video. There’s no captioning (either open or closed) on the President-elect’s first web video address, but there’s a full transcript of it on the web site, and it looks like they’re doing this for all of it. Hopefully the producers will move towards closed captioning as a serious accessibility measure. The WCAG+Samurai guidelines, for example, note that a separate transcript, either in plain text, HTML, or some other format, is not a substitute for captioning or audio description. (Conforming with WCAG 2.0 will require captions, as well.)

YouTube released closed captioning for video in late August, 2008

Meanwhile, it looks like the equally ambitious Commitment to Accessibility is a good sign and will bring the U.S. in line with 136 other countries on the UN Convention on the Rights of Persons with Disabilities. This statement claims that change.gov itself is the first step in this direction, which shows how an organisation’s approach to the web can be viewed an indicator of its approach to the broader issue of accessibility:

The Obama Administration has a comprehensive agenda to empower individuals with disabilities in order to equalize opportunities for all Americans.

In addition to reclaiming America’s global leadership on this issue by becoming a signatory to—and having the Senate ratify—the UN Convention on the Rights of Persons with Disabilities, the plan has four parts, designed to provide lifelong supports and resources to Americans with disabilities. They are as follows:

First, provide Americans with disabilities with the educational opportunities they need to succeed.

Second, end discrimination and promote equal opportunity.

Third, increase the employment rate of workers with disabilities.

And fourth, support independent, community-based living for Americans with disabilities.

This commitment to accessibility for all begins with this site and our efforts to ensure all functionality and all content is accessible to all Americans.

Also, I can’t resist mentioning that change.gov developers are using jQuery and Thickbox (both of which I use and love) for a small set of site behaviours, and it looks like they are taking progressive enhancement seriously: there is no JavaScript within the body of the page. They are even writing the Thickbox class names using unobtrusive techniques. The outgoing_links() function, for example, detects offsite links and, if you click on one, presents a Thickbox modal window to let you know that you are about to leave the site. They don’t add anything to the markup to trigger this, other than the external link itself. Regular expressions are used to determine that it’s an offsite reference.

While I’m geeking out on the site I might as well mention that the HTML is fairly lean, a lot of

tags but that’s about it. The number of HTTP requests is moderate, so it should load in a reasonable time for most visitors. Using CSS sprites for the menus could get this down a bit. You can get around the site okay in Lynx, too:

On a technical level I have to admit that I haven’t really looked at whitehouse.gov, which would be a logical point of comparison, but a brief inspection of the homepage shows that the body markup is littered with document.write in video playback scripts (ew), and uses the occasional table for layout (shudder). The government is required to make it’s own sites accessible because of Section 508, but the use of these two techniques strains the intention somewhat.

In contrast it’s the “music behind the words” of the commitment to accessibility that sets change.gov apart. The Transition Project web site isn’t perfect by any means (it doesn’t validate, lacks captioning on the video, and there’s the inexplicable use of a non-existent element called links^† in the page body) but the developers are following design principles that make content access the first priority, and when it comes to your (future) government you have got to respect that.

Looking at the bigger picture here—the user experience and technical implementation of change.gov, the use of YouTube and the ongoing commitment to web video, the success of the Obama campaign online, the use of social web technolgies, the policy positions set forth, and the sheer amount of content being generated by the Transition Project—this is what Brian was talking about when he said that November 4 was a good day for the Internet. The new administration gets it.

Update 1: The latest video posted on change.gov supports YouTube closed captioning:

This is great to see.

Update 2: As of today (November 20) the original video also supports closed captioning.

† What the? This is the second time in 24 hours: first and now . How many people are making up their own elements, and, more curiously, why?

Element sarcasm undefined

Adrian Cooke — Sat, 15 Nov 2008 03:58:01 +0000

Some say that after 47 minutes of struggling with an unruly CSS layout you should get a cup of coffee and then give up and use tables.^† Here’s the pitch, straight from the source:


You know, we've all been there. We want to make it work with CSS.
But sometimes it's just not worth the effort. The hacks and
conditional comments ruin our clean markup. And we spend hours
trying to make a simple layout work. Occasionally, we have to
remind ourselves that we've done enough and it's time to move on.




If you're wasting time fighting with CSS -- and we know you are --
we've got just the tool you need. Download the Give Up and Use
Tables timer. We've scientifically determined the
maximum amount of time that you should need to make a layout work in
CSS: it's 47 minutes. When your time is up, we'll even give you the
table code you need. Take three minutes to build a table. And ten
minutes to get a donut. Bill the client for an hour. Done.

That’s “awesome.”

† Via Lydia.

X and accessibility

Adrian Cooke — Sat, 12 Jul 2008 22:11:36 +0000

In April, 2007 David Andersson summarised the development of, and differences between, HTML5 and XHTML2 and concluded that the web’s future lies with HTML5. I think he’s generally right, though XHTML2 has never been a likely successor to HTML4/XHTML1. The real question is what will become of the X in XHTML given that most authors are doing it wrong?

HTML5 is looking so strong because it’s a pragmatically driven project that incorporates much of what people are already doing—stealing XHTML’s thunder by keeping the standards-based focus while decoupling the web’s primary language from XML. (HTML5 is homologous to XML—it can even be served as XML—but most browsers will never see it that way.) And because it’s well-grounded it’s already being implemented.

Despite the efforts of the W3C to absorb HTML under the XML project, it seems that the two vocabularies will remain on separate paths, running parallel for now. This threatens the W3C’s goal of a semantic (machine-readable) web in its idealist form. WHATWG’s efforts which, like those of the microformats community, are grounded in popular practice, will get us only part-way there, but unlike XHTML2 they promise us something we can use here and now.

So is HTML5 a fait accompli? Taking the contrary view in a recent article, James Edwards still favours the current XHMTL standard, served as XML where possible, over HTML5 for accessibility reasons. He doesn’t mention XHTML5 explicitly (i.e. HTML5 served with an XML MIME-type), but he does say he’d rather stick with XHTML1 than adopt HTML5′s markup spec, which drops support for several accessibility features, including the alt attribute for images and the summary and headers attributes for tables.

Edwards and Gez Lemon, linked above, are right that this is a problem, especially regarding the alt attribute (given the prevalence of images over correctly marked-up complex data tables). This needn’t be a practical quandry: Edwards is taking a stand on principle in sticking with XHTML1 because the spec recognises these accessibility features.

So what should an organisation that is concerned about accessibility do? This is a question I’m trying to answer. Two new sets of guidelines are particularly relevant: WCAG+Samurai released on February 26 (see commentary by Joe Clark and Roger Johansson), and the W3C’s much-revised WCAG 2 Candidate Recommendation released on April 30 (discussed in interviews with Patrick Lauke and Lachlan Hunt).

The two questions that need to be addressed:

Which set of normative rules, if any, should guide the organisation?
Which X/HTML syntax, if any, maximises access for both assistive technologies and mobile user agents?

“If any” is important: I don’t want to presume that a single choice must be adopted in either case. It may be true, for example, that more than one versions of HTML could be used without any significant detriment to accessibility, or that neither set of accessibility guidelines is completely appropriate or usable. (I doubt that, but let’s see.) Nevertheless, being able to specify one in each case is desirable, and so is testing and evaluating the results.

I’m planning to follow up on this post once I’ve read the two documents and done some testing, and I’m interested in hearing what people think.

Navigation via the link element

Adrian Cooke — Tue, 01 Jul 2008 03:58:00 +0000

Pretty much every navigation menu on every site is different. They have commonalities, but obviously they’re not exactly the same. The minute you want to find something else on the site you’re viewing a small part of your brain energy goes into figuring out what’s available to get you there. You probably look for a navigation menu, some persistent pattern of options that outlines the site’s scope and allows you to move across, down into, or up and out. Unless the designer hates you, you’ll probably find the navigation in the same place on each page. It will take you time and effort to move your mouse there. Not much, but some.

Opera’s Navigation Bar.

Another way to provide navigation is through the page’s meta information. If you mark up the head of each page with link element relationships to nearby documents then visitors with a capable user agent can navigate to nearby stuff using their application controls. Opera is one such browser. Note the available Home, Previous, Next and Author buttons on the lower toolbar in the screenshot. There’s also a Firefox plugin called Link Widgets that works in a similar way. The blue arrow buttons are Top, Up, Previous and Next though there are others you can add by customising your toolbar.

Link Widgets for Firefox 1.5⁺.

In this scenario you expend some brain energy seeing which options are available, and some time moving your mouse to the one you want, say the “Previous” button. But the next time you come to a site that supports this type of navigation, you know those buttons are in exactly the same place, the same distance from each other, the same distance from your Reload and Back buttons, i.e. not far.

In HTML4 this was the intention of the link element: to provide a way for the browser to render links through the user interface (though I just learned about it). Opera’s implementation is quite addictive—fast the way a feed reader is when you’re skipping through a list of posts. I’ve no idea how widely supported this is, but it’s another tick for Opera. I think they are slowly winning me over.