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 9, 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 designers understand the branding implications behind browser rendering of HTML. Semantic markup is extremely important when designing for disabled visitors.
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:
- To improve the chances of getting found via search engines
- To avoid boycotts or discrimination lawsuits
- To serve and treat all visitors equally (brand goodwill)
- To improve site usability
- To reduce bandwidth time and costs
- To improve customer conversion rates
- To reduce support costs, like site maintenance
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.