It’s amazing to think that despite the fact that the World Wide Web is in its infancy, access to it has become an integral part of our lives. Access to the Web is quickly becoming not just a convenience, but a necessity.
This sense of necessity has largely driven the need for computer applications and sites to be accessible to people who might have hearing loss, low vision, or other disabilities. In fact, in 1998, Congress enacted the Workforce Investment Act, which consisted (in part) of an amendment to the Rehabilitation Act of 1973. That amendment was titled Section 508, and it has become synonymous with accessibility in the world of technology.
Government agencies and most educational institutions are required to abide by Section 508 requirements. Section 508 specifies requirements not only for sites, but also for multimedia, video, telecommunication products, and more. It is far-reaching legislation that affects most web designers.
Accessibility doesn’t just refer to the ability of people with vision problems to experience a site via a screen reader. It also applies to proper color choice so that those with various types of color blindness can read your site and so on. It even prohibits design techniques that can cause screen flicker beyond a certain frequency. All in all, 16 rules comprise Section 508 standards.
There are many points to consider when designing your site to be accessible. Expression Web provides some user interface elements designed to keep you in compliance with accessibility requirements. Many other techniques require attention to detail and a touch of common sense when developing your site.
Section 508 is not the only standard for accessibility, but it’s the only government-enforced standard. The W3C has devised the Web Content Accessibility Guidelines (WCAG) in an effort to enhance the accessibility of sites. Expression Web recognizes both Section 508 and WCAG. However, Expression Web only checks your site against WCAG 1.0 and not the updated WCAG 2.0.
When creating a hyperlink in Expression Web, you’ll have the option of also specifying a ScreenTip by clicking the ScreenTip button in the Insert Hyperlink dialog, as shown in Figure 12.1.
Figure 12.1. Configuring ScreenTips for hyperlinks is important for accessibility. Expression Web makes it easy.
When you click the ScreenTip button, the Insert Hyperlink ScreenTip dialog is displayed, as shown in Figure 12.2. Enter the text for the ScreenTip and click OK. When a user hovers over the hyperlink with his mouse, the text configured as the ScreenTip pops up next to the mouse. Additionally, the text you enter is read by a screen reader for those with visual disabilities.
Figure 12.2. Enter the text for your ScreenTip. It will then be available to a screen reader for those with visual disabilities.
The ScreenTip feature in Expression Web is implemented using the title
attribute of the hyperlink.
For more information on inserting hyperlinks, see “Creating Hyperlinks,” Chapter 3, p. 55.
When creating a table, it’s often tempting to describe the table in the site’s text and then present the data without headers. However, Section 508 requires that all tables containing data must also contain header information. The table shown in Figure 12.3 is compliant with Section 508 guidelines.
Figure 12.3. All data tables must have header information. This table meets that requirement.
For more information on creating tables, see Chapter 5, “Using Tables.”
Frames pages are a challenge for screen readers because a screen reader sees a frames page as two or more separate pages. You should follow a few general guidelines to make frames pages more accessible.
Make sure each <frames>
tag in the frameset contains a title
attribute that clearly defines the purpose of the page. For example, the following <frames>
tags aid in accessibility:
<frame title="Site Navigation" name="navframe" src="nav.htm" />
<frame title="Main Site Content" name="main" src="main.htm" />
You should also be sure you include a proper DOCTYPE
declaration on your frameset page. The following DOCTYPE
declaration should be used on a frameset that conforms to the XHTML 1.0 standard:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
Finally, make sure you include a <noframes>
section in your frameset.
For more information on using frames, see Chapter 6, “Using Frames.”
There’s no possible way to cover all the accessibility topics in this chapter. However, in addition to the common issues we’ve already discussed, there are some general considerations to keep in mind as you develop a site.
Be sure to always provide some alternative representation for images, navigation elements, Adobe Flash animations, and any element implemented with client script. Expression Web provides user interface elements for ensuring that you meet the necessary requirements in this area. For example, when you insert an image onto a page, Expression Web displays the Accessibility Properties dialog shown in Figure 12.4.
Figure 12.4. The Accessibility Properties dialog serves as a reminder to enter attributes required for accessibility.
Another item web designers often overlook is that a site should be viewable without the application of any style sheets. For example, consider a site with white text inside a table styled with a black background using a style sheet. Because Internet Explorer uses white as a background color by default, the text for such a site would not be visible to anyone without CSS support. Not only is that a counterproductive design, but it also falls outside the Section 508 requirements.
The bottom line is that you should always think about accessibility when designing your sites. Many accessibility rules are based on common sense. However, no matter how much effort you put into making your sites accessible, you are bound to miss something. Thankfully, Expression Web provides an Accessibility Checker feature so you can locate accessibility problems and correct them before you deploy a site.
The Expression Web Accessibility Checker allows you to run reports on how well your site holds up to accessibility standards. The Accessibility Checker can check one or more pages (or your entire site) against WCAG and Section 508 requirements and provide a comprehensive report of the results.
To access the Accessibility Checker, select Tools, Accessibility Reports to display the dialog shown in Figure 12.5.
Figure 12.5. The Accessibility Checker is a flexible tool for finding accessibility problems in your site.
The Check Where section of the Accessibility Checker dialog lets you check all pages, all open pages, selected pages, or the current page for accessibility problems. The Check For section allows you to choose which standard(s) you want to check your pages against. You can choose WCAG Priority 1, WCAG Priority 2, and Section 508 requirements.
Priority 1 results are problems that must be corrected for a page to remain compliant with accessibility standards. A priority 2 result should be corrected for maximum accessibility, but not doing so does not cause your page to fail validation.
The Show section provides a series of check boxes that control how much information is displayed in the accessibility report. The following options are available:
• Errors—Represents problems that cause the page to fail accessibility requirements. Any errors must be corrected if the site is to fall within accessibility standards.
• Warnings—Represents areas of a page that might be problematic based on the content. You should review these areas for possible accessibility problems.
• Manual Checklist—Lists the general requirements for the selected standards. These are somewhat similar to reminders that are designed to ensure you are aware of the requirements imposed by the selected standards. Because the items on this list cannot be checked automatically, you will want to check them manually.
After you’ve made your choices in the Accessibility Checker, click Check to check the page(s). When the check is complete, Expression Web displays the results in the Accessibility panel, as shown in Figure 12.6.
Figure 12.6. The Accessibility Checker’s results are displayed in the Accessibility panel.
Additional options in the Accessibility panel are available by right-clicking a particular item. For example, for additional details on an item, right-click the item and select Problem Details. Expression Web displays the Problem Details dialog with details on that item (see Figure 12.7). This is useful not only to get a better understanding of the problem, but also to provide hints on how to correct the issue.
Figure 12.7. The Problem Details dialog can provide helpful hints on how to resolve issues that appear in the Accessibility report.
If a particular item appears because of a WCAG checkpoint, additional information on that specific item can be obtained by either clicking the WCAG link in the Checkpoint column (shown previously in Figure 12.6) or by right-clicking the item and selecting Learn More from the menu. Doing so opens your browser and takes you to the W3C site, where you can read about the specific requirement, as shown in Figure 12.8.
Figure 12.8. Expression Web provides direct links to W3C documentation on particular items in the Accessibility panel.
To correct a problem or warning displayed in the Accessibility panel, double-click the entry. Expression Web opens the applicable page and selects the code that caused the error or warning, as shown in Figure 12.9, so that it can be easily corrected.
Figure 12.9. Locating problems in code is easy. Just double-click the item in the Accessibility panel to open the page and highlight the offending code.
In some cases, saving the results of the Accessibility Checker can be convenient. Perhaps you are not the person responsible for correcting all the errors and warnings, or maybe you want to correct the problems over time. Expression Web lets you copy selected Accessibility Report results so that you can paste them into a new page for printing or saving.
To generate a page with details of selected Accessibility Report results, select the entries you’re interested in. Right-click and select Copy Selected Results from the menu as shown in Figure 12.10. You can then paste the entries into a new page. The resulting page is shown in Figure 12.11.
Figure 12.10. A printable report can be generated by copying results from the Accessibility panel.
Figure 12.11. Accessibility Report results can be pasted into a new page for easy printing or saving.
Not all of us are required to abide by Section 508, but all of us should. Considering the effort web designers take to ensure that their sites render correctly in all browsers, it only makes sense that equal effort should go into ensuring that your sites are accessible to those with disabilities.
Here’s a trivia question for you: What was the name of the first web browser? For many of you, Mosaic probably came to mind. Although Mosaic is commonly thought of as the first browser, it was not. The first web browser was invented by Tim Berners-Lee in 1989, and it was called WorldWideWeb.
WorldWideWeb was nothing like what comes to mind when we think of a web browser today. It didn’t have the capability to render graphics. Even so, it was an extraordinary accomplishment, and—as history can testify—it transformed the way we access information.
In 1993, NCSA Mosaic 1.0 was released, but it also lacked the capability to display images. That capability wasn’t made available until 1994, when Mosaic 2.0 was released.
In 1994, Netscape Communications released Netscape 1.0. A year later, Microsoft released Internet Explorer 1.0, and the race was on. By 1997, Microsoft had released Internet Explorer 4.0, which contained a solid implementation of the Document Object Model (DOM), allowing web developers to begin using JavaScript to manipulate pages. In the meantime, Netscape had released version 3.0 and the Netscape 3.0 Gold Edition, which contained a what-you-see-is-what-you-get (WYSIWYG) web design tool called Netscape Composer. Add Microsoft’s FrontPage 97 (another WYSIWYG web design tool available at the time) into the mix and the stage was set for a compatibility nightmare.
The concept of browser compatibility can be traced directly to the browser wars of the 1990s. As Netscape and Microsoft battled it out for browser superiority, web developers became casualties of that war. Code that looked great in one browser looked entirely different on another browser. The design divergence wasn’t limited to Microsoft versus Netscape design decisions. Pages that looked great in one version of a particular browser might fall apart on a different version of the same browser.
Recent browsers and design tools are almost entirely standards-compliant, but plenty of people are still using older browser versions. Keep that in mind when designing your site. See the “Should You Design for Older Browsers?” sidebar for my take on how to deal with this situation.
As the war heated up, it became clear that web designers would not get relief from browser developers. Instead, it was up to web designers to “fix” the problem. Web development hacks began to pop up in forums frequented by designers. If you were a web developer during this painful period, you no doubt remember how difficult it was to keep up with all the latest techniques.
A few years ago, I could have easily filled an entire book on compatibility issues. Fortunately, that is no longer the case. Today’s web design tools and web browsers are more standards-compliant. The hacks that web designers used in the past are often no longer necessary. To avoid compatibility issues, today’s web designer can focus on the standards and be fairly certain that her site will appear as expected for most people.
Expression Web has many features designed to help you create standards-compliant sites. The most important feature offered by Expression Web is its capability to create standards-compliant code automatically. Because of that, you are free to work on your site without worrying about what’s going on under the hood. However, what if you’re working on a site that was originally created in another application? Fortunately, Expression Web offers features to help you identify and correct inherited code problems as well.
Expression Web has a few ways of notifying you when a code problem exists. Among these are the status bar, marking invalid code in Code View, and compatibility reports.
The status bar displays an icon when it finds incompatible code or a code error (see Figure 12.12). For example, if an HTML table is missing the closing </table>
tag, Expression Web informs you that a code error has been detected. Other errors can be subtler, such as improperly closed tags in an XHTML-compliant document.
Figure 12.12. In Code View, icons appear on the status bar when a code problem is found. (Both code errors and code incompatibilities.)
The icon indicating incompatible code appears only when in Code View or Split View. The Code Error icon appears in all views when a code error is present.
For more information on identifying and correcting code errors in Code View, see Chapter 4, “Using Page Views.”
To determine whether code problems exist, Expression Web uses several methods to determine the formatting and layout rules applicable to the current page.
doctype
The doctype
declaration is a statement contained within the first line of code in a page. It defines the rules that are applicable to the document. The following doctype
specifies that a document should follow the XHTML 1.0 Transitional rules:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Expression Web displays the current doctype
in the status bar. In Figure 12.12 (shown previously), the Status Bar indicates that the doctype
is set to XHTML 1.0 Transitional.
For more information on using Code Snippets, see Chapter 3, “Creating Pages and Basic Page Editing.”
XHTML is the latest standard in web design. The current XHTML standard is almost identical to the HTML 4.01 standard with the addition of XML formatting and elements.
A full discussion of XHTML is beyond the scope of this book. For more information on XHTML, read Special Edition Using HTML and XHTML, available from Que Publishing.
If there is no doctype
declaration in your document, Expression Web uses the schema of the document to determine whether problems exist. The schema is defined in Expression Web and can target a standard (for example, HTML 4.01 or XHTML 1.0) or a browser (for example, Internet Explorer 5.0 or Internet Explorer 8.0).
Most doctype
declarations contain a URL to the definition file (.dtd
file) that defines the rules for the document type. Expression Web does not read the definition file to determine the rules of the document, but your web browser will often format the document differently if the URL is missing.
Needless to say, if you decide you want to design your page to be compatible with an older schema such as the Internet Explorer 5.0 schema, you’re going to have a tough time. Much of the code Expression Web creates when you format page elements is CSS code, and older schemas cause Expression Web to complain heavily about such code.
Expression Web will not alter the code it creates based on doctype
or schema settings. Specifying a doctype
or setting a schema only affects the rules Expression Web uses to flag certain code as invalid or incompatible.
Another drawback to using older schemas is that Expression Web will continue to create code that uses CSS elements and other features that likely aren’t compatible with older schemas. If you insist on using older schemas, you should prepare yourself to do a fair amount of code editing and hand coding to replace the code that Expression Web generates.
To alter the doctype
and schema settings, select Tools, Page Editor Options, and click the Authoring tab. The doctype
and schema can be set using the doctype
and Secondary Schema drop-down, as shown in Figure 12.13. Note that you can also select the CSS schema in this dialog, but doing so affects only what is displayed in IntelliSense.
Figure 12.13. The doctype
and schema are configured in the Page Editor Options dialog.
When Expression Web encounters invalid or incompatible code, it underlines the code in red. If you hover your mouse over the underlined code, a ScreenTip informs you of the problem, as shown in Figure 12.14.
Figure 12.14. Expression Web makes finding code errors fast and easy by highlighting them in Code View.
For more information on working in Code View, see Chapter 4, “Using Page Views.”
When Expression Web encounters a code error (such as mismatching tags), it highlights the offending code in yellow. Just as with underlined code, you can hover the mouse over the highlighted code for details of the problem.
You can quickly display the Page Editor Options dialog by clicking the doctype
, schema, or CSS schema displayed in the status bar.
Expression Web has three reporting options specifically designed to aid in locating problems with code:
• Accessibility Reports—Also called the Accessibility Checker, this report locates any code problems affecting the accessibility of your site.
• Compatibility Reports—This report analyzes your page code and shows problems with code that doesn’t comply with the standards you’ve specified.
• CSS Reports—This reports on CSS usage and shows any problems with CSS code in your site.
CSS reports are covered in-depth in Chapter 18, “Managing CSS Styles.” Therefore, we won’t go into any detail on the reports here.
To access compatibility reports, select Tools, Compatibility Reports to display the Compatibility Checker dialog, as shown in Figure 12.15. You’ll have the option of checking all pages, all open pages, selected pages, or the current page using the Check Where options. Pages can be checked against selected HTML/XHTML standards using the Check HTML/XHTML Compatibility With drop-down, and CSS code can be checked against a CSS standard specified in the Check CSS Compatibility With drop-down.
Figure 12.15. The Compatibility Checker makes it easy to find problems in your code.
If you have a doctype
declaration on your pages, you can check the Run Check Based on Doctype Declaration in Page if Available check box and the Compatibility Checker checks your pages based on the doctype
. When you use this option, the setting in the Check HTML/XHTML Compatibility With drop-down is ignored if a doctype
declaration is on your page.
It’s important to realize that checking the Run Check Based on Doctype Declaration in Page if Available check box does not automatically negate the setting in the Check HTML/XHTML Compatibility With drop-down. In fact, you might find yourself in a situation where you have inherited a site that contains some pages with a doctype
declaration and some pages without one. In such cases, it’s often convenient to check against the doctype
in the page when present, but check other pages against a particular standard in preparation for adding a doctype
later. It’s in these types of situations that the flexibility of the Compatibility Checker is truly appreciated.
The results of the Compatibility Checker are displayed in the Compatibility pane, as shown in Figure 12.16. Each column in the Compatibility pane can be sorted by clicking the column header. Double-clicking an item in the list takes you to the code that is causing the problem so you can correct it. As you make corrections, you can use the buttons along the left edge of the Compatibility pane to refresh the results, rerun the compatibility reports, and navigate between compatibility errors.
Figure 12.16. The Compatibility pane displays the results of a compatibility check in an easy-to-filter view.
By clicking the small arrow at the right edge of a column in the Compatibility pane, the results can be filtered using either the drop-down menu that appears or by selecting Custom from the menu and entering filtering criteria in the Custom AutoFilter dialog. To remove the filter you’ve applied, right-click the column header and select Clear Filters, as shown in Figure 12.17.
Figure 12.17. Filters can be removed using the context menu that appears when you right-click a column header.
Many of us take for granted that everyone sees color the same way we do. In fact, many people do not. There are many forms of color blindness, and each of them can affect the way your site appears. However, because most of us see color accurately, ensuring our site appears correctly to those with a form of color blindness is a tough job. Vischeck can make it a lot easier.
Vischeck (www.vischeck.com/vischeck/) offers a site where you can enter a URL and generate a view of what the URL looks like to people with various forms of color blindness. You can also upload an image file and Vischeck provides a view of that image as it appears to someone with color blindness.
If you’d prefer, you can download a plug-in from Vischeck (free of charge) that allows you to run Vischeck’s algorithm on images from within Adobe Photoshop or another image-editing application that supports Photoshop plug-ins.
Choosing colors for your site is a critical task. You can avoid selecting colors in a vacuum by using Vischeck to ensure that your color choices make your site accessible.
18.119.103.96