Creating Accessible Websites

screenshot Skills Inc.

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.