MS FrontPage


When developers talk about making sites accessible, they're referring to the laudable goal of designing pages so that disabled visitors can explore a site. For example, many blind people use a screen reader (which translates the text into a synthesized computer voice) or a Braille display program. These devices depend on site designers who take the time to label their graphics with alternative text tags (Formatting Pictures).

FAQs: FrontPage and DOCTYPE

I tried to validate my Web page and got the error "no document type." What does this mean?

The truth is that no Web page produced by FrontPage passes the well-formed HTML test. For starters, FrontPage never begins a page with a DOCTYPE declaration, so the validator immediately shoots out a "NO DOCTYPE FOUND!" message (complete with the alarmist capital letters). DOCTYPE is short for document type. This snippet of code tells the browser what version of HTML the page is written in. (The most recent HTML version sanctioned by the W3C is HTML 4.01. Past versions are HTML 3.2 and HTML 2.0, which can't handle more recent Web technology like CSS.) This way, in interpreting a Web page's HTML, the browser sticks to the established standards for that version of HTML. The advantage is that all browsers know what those standards are and there won't be so many differences between the way they interpret and display your page. When a browser renders (displays) a page that has a DOCTYPE declaration (in what's called "standards mode"), it ignores invalid tags or attributes.

So how could Microsoft decide to neglect such an important item? Well, you actually don't need a DOCTYPE declaration. If it's missing, a browser displays the page in quirks mode. Anything goes in quirks mode. If a tag or attribute isn't official HTML, the browser takes a crack at it anyway and tries to display all the elements it sees in a particular page. As you can imagine, in quirks mode, the page can look pretty different in each browser.

So what should you do? First, keep in mind that you don't really need a DOCTYPE, and adding one out of the blue can cause more problems than it solves. Pages that FrontPage creates may not follow the strict guidelines of "standards mode." If you insert a DOCTYPE declaration, then the browser expects your code to be in line with the version of HTML that you've specified. In other words, the browser won't display elements that aren't sanctioned. However, if you decide that you want to bring your HTML in line with strict W3C standards, you can add one. But which version of HTML should you tell the world you're using? To choose the correct DOCTYPE, visit and read up on all your options. In most cases, you can probably use the following common declaration:

      01 Transitional//EN"

That last line refers the browser to the DTD (document type definition) file that contains the standards. A DTD lists the legal elements that define document structure and syntax. There are different DTDs for framed pages. You can also choose from DTDs that enforce stricter adherence to the HTML version's standard. Read about the different types of DTDs on the W3C Web site (

Use Find and Replace (see Making Good Impression) to add the declaration to existing pages. You add a DOCTYPE declaration at the very beginning of the pagebefore the first <HTML> tag. Make sure you include that last line with the URL. A DOCTYPE declaration must reference a DTD file. Without it, a browser reverts to quirks mode.

To automatically add the declaration to any of your future pages, create a FrontPage template (Creating a Page Template) or Dynamic Web Template (Creating a Page Template), add the declaration to it, and then use the template to create new Web pages.

Even if you decide you don't want to add a DOCTYPE, you can still validate your pages to look for other errors. FrontPage also helps you check pages with its accessibility checker (see the next section). But if you're legally required to make your pages accessible, you probably need to add DOCTYPE declarations to all your pages.

FrontPage may not help you much when it comes to validation, but it does try to help you comply with accessibility standards. This is important, since many companies and organizations are legally bound to make their sites accessible. To help youand your visitorsout, FrontPage comes with an accessibility checker. To use it, select Tools » Accessibility.

The accessibility checker analyzes your site and displays a report containing errors it finds. To run a report:

  1. Decide which pages you want to perform an accessibility check on.

    If you want to check just a few pages, start by selecting them in the folder list, then select Tools » Accessibility. Within the "Check where" section, tell FrontPage which pages you want to check. Most often, you'll want to check your entire site, of course.

    If your site has pages with included content (see Included Content), you may want to check included pages first and then check the rest of your site. The reason? When the accessibility checker examines a page with included content, it doesn't check the include page.
  2. Select an accessibility standard for FrontPage to measure against.

    Within the "Check for" section, FrontPage gives you three options. You can select them all, if you want:

    • WCAG Priority 1 includes the basic Web Content Accessibility Guidelines (WCAG) set forth by the W3C. Priority 1 guidelines are the most basic. If your page doesn't meet them, a disabled visitor will be unable to use the page at all, and your site will be inaccessible to him.

    • WCAG Priority 2 is a less stringent level of guidelines. If a page doesn't rise to this level, a disabled visitor would have a difficult time using the Web page. You should try to meet these guidelines, too. The more accessible your site is, the larger the number of people who can enjoy it.

    • Access Board Section 508 is for sites published under the aegis of the U.S. Federal Government. Section 508 of the Rehabilitation Act requires that any technology used by the Federal government comply with the standards set by the Access Board. You'll need to check this box if you're designing a site for the Feds.

  3. Tell FrontPage what feedback you want.

    In the Show section, select one or all of the following:

    • Errors reports situations in your Web site that definitely fall short of the standards you selected in step 2.

    • Warnings reports situations in your Web site that might possibly fall short of the standards you selected in step 2.

    • Manual Checklist lists items that you need to review (FrontPage can't check all issues automatically). These can range from general accessibility guidelines for making your pages accessible (like "Provide sufficient contrast for low vision users") to specific items you should check on each page.

  4. Check accessibility.

    Once you've made all your settings, click Check. Results appear within the Accessibility dialog box (see Figure 12-6).

    Figure 12-6. While FrontPage checks for accessibility errors, this dialog box tracks progress for you in the status bar, at bottom. The program lists all problems it finds. The report tells you the page name, what standard the page failed, and summarizes the problem.

  5. Make changes.

    Double-click an entry to go to the page where the problem's been flagged. FrontPage opens the page in Split view and highlights the code in question. Edit or remove elements as you wish (you can add alternative text to a graphic, for instance). You can also proceed in order through the list. Double-click the first entry. Then click Next to address each item down the list. Click the Previous button to go back an entry.

If you want to generate a paper checklist from this report, click Generate HTML Report. You can print the resulting HTML page or open it in a browser and check off issues as you resolve them.