The new site has received a lot of press since its unveiling a few days ago. Many have rightly given it kudos for bringing a modern sense of design and “Web 2.0”-style social practices to the White House. I agree the new site is a big improvement, but upon looking under the hood, there are a number of things I’d have done differently. Here’s a quick-hit list (not comprehensive at all):

Use semantic IDs and class names.

The site currently uses IDs such as ctl09_rptNavigation_ctl00_rptNavigationItems_ctl01_hlSubNav. Yikes. It also uses class names like graybox; any developer worth their salt should know that a class name should never contain colors or descriptions of the presentation in the name. What if the visual designer decides to switch color schemes? The class name would no longer make any sense.

At a minimum a developer should use human-readable IDs and class names.

Design the site to work well without JavaScript and CSS.

The site’s menus are suckerfish-style and work great without JavaScript, but if you view the site with both JavaScript and CSS disabled, you will see chunks of content that make no sense whatsoever. Case in point: The ‘home’ page contains a div bearing a message to visitors who are leaving the site. When CSS is disabled, this message is visible whether you’re leaving or not!

<div id="tb_external" style="display:none">
  <h2>You are exiting the White House Web Server</h2>
  Thank you for visiting our site.
  <div class="graybox">
    <strong><div>You will now access</div></strong>
  <strong>We hope your visit was informative and enjoyable.</strong>

  To comment on the site, send feedback to the Web Development 
  Team by <a href="/contact/">clicking here</a>.
</div>Code language: HTML, XML (xml)

The entire div was hidden using CSS, which means it’s visible if CSS is disabled. Plus, there is a nested div containing a fragmented sentence clearly meant to be augmented by JavaScript. If JavaScript is not available, this div should not even exist! If the developer used progressive enhancement techniques, they would have used JavaScript to create the div and populate the text only when needed.

Don’t use inline styles or behaviors.

Progressive enhancement techniques are easy and in the long run make your entire experience that much better. It therefore goes without saying that you should use CSS and progressive enhancement JavaScript techniques instead of inline code like this:

<div id="ctl02_pnlSearch" class="mod-search332" 
     onkeypress="javascript:return WebForm_FireDefaultButton(event, 'ctl02_btnSearch')">
Code language: JavaScript (javascript)


<div style="padding-left: 20px;">Code language: HTML, XML (xml)

Arrange the content in a logical order before applying styles and behaviors.

Example: The search box is in the bottom third of the page, and there is no clear sense of structure on the page (h1, h2, h3, etc.). The structure only becomes clear when the presentational CSS is added; without the CSS, it appears mushy at best.

Don’t repeat your markup.

The navigation menu <ul>, which is quite long, is located at the top of the page and then repeated at the bottom. I would have used the markup once in an accessible way, such as with semantic HTML and CSS, then used JavaScript to duplicate the markup and apply different CSS classes to handle the stylistic differences. The site already uses jQuery, so this task should have been a piece of cake.

Why wouldn’t I use two hard-coded menus? Mostly practical reasons:

  1. A site like will undoubtedly get massive hits and therefore require a ton of bandwidth. Reducing the page markup will reduce bandwidth and conceivably save money.
  2. If someone is accessing the site with a screen reader, I imagine it would be annoying to run into the navigation menu twice. It feels like bloat.

Reduce the amount of unnecessary markup in the page.

Along the lines of the last point, it looks like this site suffers from div-itis. Here’s a great example of when you should use an <h1> element and not a <div>: The top of the page has an image element that contains the text “The White House – President Barack Obama”. They wanted this portion of the page to be clickable, returning the user to the home page. To accomplish this task, the developer added the following code to the page:

<div class="hdrttl">
  <a href="/">
    <img src="/images/eop/clear.gif" alt="The White House - President Barack Obama" />
  <br />
Code language: HTML, XML (xml)

An empty(!) image surrounded by a link, which is in turn followed by a line break <br/> and wrapped in a div with a cryptic ID. Doh! This makes no semantic sense at all. The empty image appears to be an attempt at 508 compliance because it has an ALT attribute, but truth be told they would have been better off using a simple <h1> that contained a link, like so:

  <a id="someUniqueIDhere" title="The White House - President Barack Obama" href="/">
    The White House - President Barack Obama
Code language: HTML, XML (xml)

This version maintains good semantics, is completely accessible (removes the need for an ALT attribute), allows the link to be styled as a clear block (removing the need for an empty image), allows tooltips via the title attribute (if desired), and removes the need for the extra <br/> element. Much cleaner, much leaner, and much more maintainable, too.

Only load script files when you need them.

The page I examined did not have any SWF files embedded in it, but it still loaded the SWFObject library. A basic rule of thumb for web developers is that if a page doesn’t use a script, the script shouldn’t be loaded. Loading the unused scripts adds to page load time, adds to bandwidth costs, and really doesn’t make any sense. Lazy loading would be a better approach.

Granted, I can see the “always load it” approach making sense if the developers envisioned every page having a SWF embedded in it; maybe this SWF-less page is an exception.

Use better typography.

Don’t use double hyphens (- -) when you could be using proper em (—) and en (–) dashes. We’re all guilty of lazy web typography from time to time, but I expect more from the White House site, especially considering it was just unveiled a few days ago.

The good parts

The site, while flawed, is not without its bright spots. Among them: pleasant visual design, good use of CSS sprites, tasteful use of alpha transparency in the menu backgrounds, usage of SWFObject as the Flash SWF embedding mechanism, and availability of multiple atom feeds.

Similar Posts

One Comment

  1. Nice (and thorough) review, Philip. We’ll have to see if anyone is watching the blogosphere and will apply suggested changes.

Comments are closed.