This spring, I conducted an in-depth website accessibility evaluation for nonprofit Skills Inc.

My site audit identified 12 issues that did not conform to federal Section 508 Standards, WCAG (Web Content Accessibility Guidelines) 1.0, and the latest WCAG 2.0, released in 2009.

Some of the WCAG priority 1 updates launched included:

• providing a method for visitors using keyboard navigation to skip repetitive navigation links
• linking to third-party websites in the same browser window (vs. launching a new window)
• adding alternate text for all images on the site
• adding an underline (a second visual identifier) to body hyperlinks

Other updates included:

• converting fixed-width font units to relative font units, which are adjustable – as well as adding a font resizer (provided by Ryan Salva of Capitol Media) for better usability
• increasing the color contrast of text for sight impaired visitors
• removing HTML errors and deprecated elements for better rendering in Assisstive Technology (AT) devices
• adding the meta language to all pages to identify the natural language for screen readers

Introduction to Website Accessibility

The goal of website usability is generally to satisfy 95% of site visitors. Usability concerns how easy a website is to use. Accessibility addresses the physical limitations to visitors based on 4 main disabilities: blindness, cognitive impairments (like dyslexia), deafness, and motor impairment (like paralysis).

There are two main initiatives that set guidelines for accessibility conformance:

1. Section 508, an amendment to the Rehabilitation Act of 1973, is a law that applies to Federal agencies only. Conformance to Section 508 for non-federal agencies and agencies that do not contract with the Federal government is voluntary.
2. The World Wide Web Consortium’s (W3C) Web Content Accessibility Guidelines (WCAG). Conformance to WCAG is strictly voluntary. There are three levels of conformance, from Single A to Triple A – each with higher levels of accessibility.

WCAG 1.0 guidelines are a decade old. In 2004, websites started to become more interactive; Web 2.0 includes social networking sites (like Facebook), wikis (like Wikipedia), blogs, and other information-sharing web-based applications. WCAG 2.0 attempts to deal with the new accessibility issues created by the social web.

Background

Amateur web designers, particularly graphic designers with limited HTML skills, produce websites that look fine to the average viewer. However, often these sites are coded by What-You-See-Is-What-You-Get (WYSIWYG) visual HTML authoring software, like Microsoft FrontPage. WYSIWYG editors often produce bloated, non-semantic markup that does not validate to the W3C specifications. Additionally, these authoring tools often export proprietary code that is browser/device-dependent, meaning visitors with Assistive Technology (AT) devices or third-party browsers cannot access the content or other site features.

Websites like these are often “hard-coded” by “slicing and dicing” Photoshop images into a table-based HTML layout. These nested-table based websites often do not validate to W3C specifications, and, as a result, are not as accessible, particularly to disabled visitors, as properly coded sites. Finally, these sites are not flexible because layout changes must be performed at the single page level.

The modern way to build websites is to use Cascading Style Sheets (CSS) to separate your layout from your presentation; with CSS, style effects can be changed sitewide with one or more CSS files, instead of having to recode entire sites ‘line-by-line’ of code.

Browser and AT device vendors are aware of the issues created by poor HTML programming; therefore, many vendors compensate for non-validating code by automatically correcting some HTML errors. For example, newer “A-grade” browsers, like Internet Explorer 8 and Firefox 3, can often resize hard-coded font sizes by using a full page zoom. However, browsers cannot correct for all accessibility problems. For example, browsers and AT devices cannot yet create semantically-structured pages or interpret images that do not include alternate text, which, again, is important not just to disabled visitors but to search engines as well.

Manufacturers of browsers (like Microsoft Internet Explorer), web applications (like Windows Media Player) and AT Devices (like screen readers) determine how respective tools render HTML and CSS. Some tools interpret CSS rules differently; others ignore certain CSS rules altogether; and some AT devices do not even load CSS files. For example, Microsoft Outlook 2007 uses Microsoft Word, a proprietary nonstandard application, to render HTML.

It is important that (graphic) web designers understand the branding implications behind browser rendering of HTML. Semantic markup is extremely important when designing for disabled visitors.

Opportunities

Accessible sites are generally more usable sites and are more search engine-friendly. For example, because the HTML markup is semantically structured – properly coded sites more effectively inform search engines of the site content. Accessibility testing includes identifying non-semantic markup, as well as other features, that can help with search engine optimization (SEO).

The Return on Investment for accessibility testing can be justified in many ways, including:

1. To improve the chances of getting found via search engines
2. To avoid boycotts or discrimination lawsuits
3. To serve and treat all visitors equally (brand goodwill)
4. To improve site usability
5. To reduce bandwidth time and costs
6. To improve customer conversion rates
7. To reduce support costs, like site maintenance

Process

The best time to conduct accessibility testing is prior to a site design or redesign. Testing a site can be as simple as running several semi-automated browser-based tests of a single site page. Or you can use a variety of AT devices to manual test an entire site and its applications over a period of days. Expect to spend several hours conducting automated and manual tests of most sites.

Sites that grossly fail accessibility guidelines may not be able to justify the cost of a complete site overhaul. Since it is rare for any site to meet 100% of the guidelines, accessibility improvements can be rolled out gradually. The W3C Web Accessibility Initiative (WAI) provides a handy accessibility evaluation report template.

Walter Sepulveda asked me for help updating the static website for his Seattle landscape design company, Tierra Landscape.

The new site features an open-source content management system, expanded photo gallery, and a page for Spanish speakers.

A website makeover for Bravo Environmental. After inspecting the accessibility and usability of the original site, I located the underlying problem: an over-engineered site for engineers. Al Schumacher swept me into the project.

Site repairs included cleaning up the ASP code, cutting out redundant HTML and vacuuming up 5 nested tables to make content updates easier. Image-based headers were jettisoned to make room for search engine-friendly text-based headers. Site maintenance also involved adding pages to the site map.

You get the idea. Thanks to Beegee Tolpa for the graphic design.

1. Create an account at technorati.com
2. Verify your account by clicking on the link that Technorati emails you
3. Check your Claim Status
4. Create a blog post that includes your unique token, like MF2B68NAKRS2
5. Verify Claim Token at Technorati

Why do you have to add your blog to a search engine? I don’t really know since Google’s blog search already indexes my blog content. In fact, that same content also exists in Google’s regular search index.

And Bing.com? Yeah, they index my blog content too. No registration. No claiming. No verifying.