Compatibility and Accessibility Testing

     

This section looks at the why, when, and how of validating your site documents for adherence to published standards, for compatibility with various target browsers, and for accessibility by visitors with one or more disabilities .

What Are Web Standards, Really?

We use the term Web standard to refer to what is actually a series of specifications and recommendations created by the World Wide Web Consortium (W3C). The W3C is not an authoritative standards body per se; its primary functions are to research, develop, and publish information on technologies and activities related to the Web.

The Bottom Line: Time and Money

Standards definitely can save time. Compliance probably saves money for everyone in the Web site development chain--from site owner to developer to ISP. Longer term, working with standards provides other benefits:

• Technical advantages -- Technically, Web sites will be more easily maintained and also readily available for many platforms beyond the Web.

• Creative advantages -- Creatively, you can apply style sheets that easily make a site look good on a computer screen, on a PDA screen, and even in print.

• Social advantages -- Socially, we remove barriers to access by cleaning up our hacked markup and paying attention to accessibility concerns.

When to Switch?

Good times to look at introducing XHTML, layout with CSS, and validation of documents include

• During a Web site redesign -- Much of the work being done by Web design firms and Web designers individually is redesigning of sites. This is an excellent time to introduce best practices and standards.

• Upon creation of a new Web site -- Following the guidelines in this book will help ease you into Web standards.

NOTE

The World Organization of Webmasters (WOW) provides certification, community, and educational resources for all Web professionals. This nonprofit organization works to provide you with the resources you'll need throughout your career. For more information, see www.joinwow.org.

Validating Documents

One of the first ways you can begin learning about Web standards is to validate your HTML or XHTML documents.

Using Dreamweaver MX Validation Tools

Dreamweaver MX 2004 comes complete with several built-in validators. The validators provide helpful warnings (suggestions to consider) and errors (things you really should fix) to assist you in ensuring your documents pass muster.

Trying to validate but having problems? Find out why in "Validator Trouble" in the "Troubleshooting" section at the end of this chapter.

Before you begin validating documents, you may want to go to Edit, Preferences, Validator. This lets you tell Dreamweaver what form(s) of validation you want to perform in the event that the document does not include a valid DOCTYPE declaration. Also, click the Options button to tell Dreamweaver what you'd like to see in the reports : errors, warnings, custom messages, and so on.

After that chore is done, open the document in Dreamweaver. Follow these steps to continue the validation process:

1. Select File, Check Page, Validate Markup. (If you are validating an XHTML document, select Validate as XML instead.) Dreamweaver runs its validator.
   
   
2. The Results panel, if not already open, opens and displays any warnings or errors (see Figure 11.1). Using the buttons on the left, click More Info to see the full description, Browse Report to see the report in HTML format, or Save Report to save it.
   
   

   Figure 11.1. The Results panel's Validation tab alerts you to errors and warnings after a compatibility check.

   
   
3. Examine the errors and make changes as you see fit.
   
   
4. Run the report against your entire site by clicking the green Validate button and choosing Validate Entire Site. Alternatively, select some files in the Files panel, click the green Validate button, and choose Validate Selected Files in Site.
   
   

Validation provides you with the following information:

• File -- The name of the file being validated .

• Line -- Helps you find the exact line where the associated problem to which the error or warning is referring resides. Double-click on any error or warning to go directly to the line in Code view where the problem is.

• Description -- Provides a description of the problem and ideas on how to fix it.

If your document passes with no errors, you can assume you have a valid document.

Cross-Browser Compatibility

You can use Dreamweaver to test for browser compatibility--whether the specific browser is installed on your system or not. Happily, Dreamweaver now also tests for CSS compatibility at the same time. The quick method is to click the new Browser Check icon on the Document toolbar, then examine the Results panel's Target Browser Check tab.

To learn more about dynamic cross-browser validation, and how to set this feature for specific browsers, see Chapter 7, "Working Efficiently in Dreamweaver," page 135 .

It's also recommended that you have at least two testing computer platforms: Windows and Macintosh. Macintosh versions of Web browsers differ in their capabilities from Windows versions.

Validating for Accessibility

As it does with markup, Dreamweaver MX provides a means to test and report accessibility problems. Several other public validators are available, as well.

Before you attempt to validate for accessibility, you should examine your documents to see whether they adhere to the Web Accessibility Initiative (WAI) priority guidelines. The WAI of the W3C has an official document involving 14 guidelines for Web developers. The guidelines are as follows :

• Provide equivalent alternatives to auditory and visual content -- If you're using sound or graphics, include text descriptions and employ HTML-based aids, such as the alt attribute in images, wherever possible.

• Don't rely on color alone -- Because many people cannot see color, have problems with color blindness, or are accessing the Web via noncolor devices, relying solely on color to convey information is problematic . Make sure that foreground and background colors have high contrast.

• Use markup and style sheets, and do so properly -- This guideline is an important one! It encourages the creation of well- formed documents in accordance with recommendations. The more separation you can get between presentation and document structure, the more accessible your pages will automatically become.

  For more information on markup, see Chapter 8, "Writing and Editing HTML, XHTML, and CSS," page 161 .

  
  

• Clarify natural language usage -- Any foreign pronunciations, acronyms, or abbreviations should be spelled out or accommodated through the use of the title attribute in related elements.

• Create tables that transform gracefully -- Ideally, you're using tables now only for tabular data. Tables present specific problems, such as screen reader software reading across table cells , which can be very confusing.

  To work effectively with tables, see Chapter 9, "Professional Page Design," page 191 .

  
  

• Ensure that pages featuring new technologies transform gracefully -- All pages should be accessible no matter which technologies are being employed.

• Ensure user control of time-sensitive content changes -- Many users with disabilities are adversely affected by things that move and blink. Other people have mobility impairments and cannot keep up with any kind of moving object. Anything that moves, blinks, or auto-updates should have controls that allow the user to stop, start, and pause the object to make the page more effective and usable.

• Ensure direct accessibility of embedded user interfaces -- If you're placing an embedded object within your page, such as an applet or Flash design, be sure that users have access to the interface of that embedded object.

• Design for device independence -- Individuals accessing the Web might be doing so through a number of devices, including keyboards, mice, voice commands, a head or mouth stick, and so on. General guidelines to manage this issue include using client-side imagemaps rather than server-side maps and providing tab order mechanisms in forms for easier navigation.

• Use interim solutions -- Older browsers and assistive devices often do not operate properly, yet many are in abundance in various government organizations, including those that provide services to disabled communities. So, if I wrote a document with a consecutive list of links (very common in navigation schemes), my screen reader might read the link as one uninterrupted link and attempt to resolve it, to no avail. Another problem is the pop-up window, which these days is often used in advertising.

• Use W3C technologies and guidelines -- The W3C provides recommendations for all browser and tools manufacturers as well as Web authors.

• Provide context and orientation information -- The more complex a page or site, the more helpful it is to ensure that visitors know what they are doing at a given location and why.

• Provide clear navigation mechanisms -- Clear and consistent navigation not only is an imperative in accessibility, but is also an imperative in user interface design. Links should be clearly identified and organized, and graphical options should have appropriate alternatives available.

• Ensure that documents are clear and simple -- The easier your content is to understand, the more you'll get your point across, no matter who the audience is.

Testing Accessibility with Macromedia Dreamweaver MX

Macromedia Dreamweaver MX provides several means of helping you to ensure that your documents are accessible. After you believe your document (or a section of a document) is ready to be tested , you can run an accessibility report.

Running a Document Report

To run an accessibility report on a document, follow these steps:

1. Open the document in Dreamweaver.
   
   
2. Select File, Check Page, Check Accessibility. The checker runs and provides a report in the Results panel, this time in the Site Reports tab.
   
   
3. Use the report to find and correct problems in the document.
   
   

NOTE

Context-sensitive explanations are at your fingertips. Right-click (control-click on the Mac) a report entry and choose More Info to open the Reference panel and see details about that specific accessibility problem.

As with the markup validation report, you will see the filename, line number where the error resides, and a description of the problem with a suggestion for fixing it (see Figure 11.2).

Figure 11.2. Dreamweaver MX 2004 provides a detailed accessibility report in the Results panel.

Running a Site Report

You can run accessibility reports for an entire site, too, although the procedure is different. Select Site, Reports to display the Reports dialog box, choose Entire Current Local Site in the drop-down list, then click Accessibility (see Figure 11.3).

Figure 11.3. Performing a site-wide accessibility report.

If you want to specify feature-specific settings, click the Report Settings button and enable or disable the features in which you're interested (see Figure 11.4). Finally, click the Run button to generate the report. It will appear in the Site Reports tab of the Results panel.

Figure 11.4. Setting detailed features for an accessibility report.