A showcase of red flags: How do web shops get away with this?

I recently had occasion to review the new website of a major bank's CRA/charity wing. As a web developer, I'm always curious how other sites are built. This one raised a number of red flags for me, so I'd like to write about it as a showcase. I have three questions on my mind:

1. How do professional web shops get away with such poor quality work?
2. How do clients know what to look for (and avoid)?
3. With plenty of good web shops out there, why aren't big clients connecting with them?

I don't have the answers yet, but I do want to raise the questions. First, reviewing the site from my developer's perspective:

• The page contents are loaded with Javascript. With Javascript turned off, there's a little bit of left nav, and the main area is essentially blank. This means the site is unreadable to screen readers (browsers for blind people), so the site is not 508 compliant. Maybe more importantly, it means the contents of the page are invisible to search engines. (See Google's cached copy of the homepage for example.)
• The Javascript that pulls in the page contents is loading an XML file with AJAX (see line 72 of the homepage source). XML is meant for computers to talk to each other, not for human-readable websites, and AJAX is meant for interactive applications, not the main content area of every page. (I can only imagine the workflow for editing the content on the client side: does their CMS output XML? Do they manually edit XML? Or can the content never change without the original developers?)
• The meta tags are all generic: The OpenGraph page title (used by Facebook) across the site is "ShareThis Homepage". (ShareThis has a "social" widget which I assume they copied the code from, but having those meta values is probably worse than having none at all.)
• None of the titles are links, so even if Google could read the site, it would just see a lot of Read More's.
• From a usability perspective, the 11px font size for most of the content is difficult to read.
• The Initiatives by State map is built in Flash, which makes it unviewable on non-Android mobile devices. Flash is also unnecessary for maps now, given the slew of great HTML5-based mapping tools. Not to mention the odd usability quirks/bugs of the map's interface.

I could go on, but that's enough to make the point. So what's going on here? I've seen enough similar signs in other projects to feel confident in speculating about this one.

The vendor wasn't entirely incompetent - the hundreds of lines of Javascript code needed some technical proficiency to write - yet the site ignores so many core principles of good web development circa 2011. Whatever skills were applied here, were misplaced. The "web" has to accommodate our phones, TVs, even our cars, with "mobile" browsers (broadly defined) expected to eclipse the desktop in the not-too-distant future. That means progressive enhancement and basic HTML quality are critical. Web users also have an infinity of sites to visit, so to justify the investment in yet another site, you need some basic Search Engine Optimization for people to find you. Building a site that is readable only to a narrow subset of desktop browsers constitutes an unfinished product in my book.

On the client side, any site with more than one page, that needs to be updated more than once in a blue moon, needs a content management system. I don't see the tell-tales of any common CMS here, and the way the contents are populated with AJAX suggests the CMS under the hood is weak or non-existent. Reinventing the wheel with entirely custom code for a site makes it difficult to maintain in the long run: developers with expertise in common frameworks/CMSs won't want to touch it, and whoever does will need a long ramp-up/head-scratching period to understand it. It's also unnecessary with so many tested tools available. So clients need to insist on a CMS, and if a vendor tries to talk them out of one, or claim it will be 3x the price, they need to find a better vendor. I work with Drupal and think it's the best fit for many sites (and free of license fees), but there are many good options.

The site doesn't say who built it, and searching for relevant keywords doesn't bring up any clearly proud vendors. Was it a web shop at all, or an ad agency that added some token web services to their roster? (General rule: avoid those vendors.) Clients need to see their sites not as another piece of throwaway marketing material, but as a long-term, audience-building investment. Thinking of websites as advertisements that only need to be viewed on Windows running Internet Explorer is missing the point.

I wonder, given the client (with $10 billion in profit in 2010), how much this site cost. It's not a brochure site, but it's not particularly complex either. The only really custom piece is the map, and the same style could probably be implemented with OpenLayers (or Google Maps with some compromise from the client on color requirements). Whatever they paid, I suspect they could have paid one of the top Drupal shops the same price to build a maintainable, standards-based, truly impressive website, for visitors, internal staff, and reviewing developers alike.

Then again, being such a large client means the vendor likely had to deal with all kinds of red tape. Maybe the really good web shops don't connect with that class of client because it's not worth the hassle. But surely the U.S. House of Representatives, in the process of moving to Drupal, has its own brand of red tape, and the vendor has project managers who can handle it.

Websites are complex beasts and evaluating them from the client perspective is not the same as watching a proposed TV commercial. So how do client without core competencies in web development know what to avoid? Googling it will only get them so far. But the burden is ultimately on them: we all consume products about which we lack core expertise, and big corporations (as consumers and clients themselves) need to figure out the same heuristics as everyone else. Trusting reputable vendors is one approach, but it's a vicious cycle if they're locked into one vendor (as companies with existing B2B relationships often are).

Diversifying the advice you get is critical. Big projects should have RFPs and a bidding process. (That helps enforce a realistic division of labor: little shops like mine don't respond to RFPs, but big shops that can afford that investment are happy to manage the project and outsource some development so suit their own core competencies.)

The bidding process could even involve the vendors defending their proposals in front of their competitors. Then the top-tier CMS shop can eliminate the static-HTML or Cold Fusion shop from the running before it's too late. There are no silver bullets - there's a potential to be fleeced in any market - but in most of them, consumers have figured out ways to spot red flags and protect themselves. Website clients need to educate themselves and catch up.