Adding Rules to the Accessibility Checker

  • Article

 

Lisa Wollin
Microsoft Corporation

February 2004

Applies to:
   Microsoft® Office FrontPage® 2003

Summary: As Internet use continues to increase, it is becoming more important that businesses provide Web sites that are fully accessible to people with disabilities. The Accessibility Checker in Microsoft Office FrontPage 2003 helps developers design Web sites that address accessibility issues. However, the Accessibility Checker does not address all accessibility issues. This article explains how you can extend the functionality that is built into the Accessibility Checker. (13 printed pages)

Contents

Introduction
Working with Accessibility Guidelines
Adding Accessibility Rules
Understanding the XML Patterns Schema
Conclusion

Introduction

For something to be considered "accessible," it must be easily within reach. However, many Web sites are inaccessible, or out of reach, to people with disabilities. As a result, the World Wide Web Consortium (W3C) developed the Web Content Accessibility Guidelines (WCAG)****to help Web developers understand the elements of a Web site that make it inaccessible to people with disabilities and provide information on how to fix these issues. In addition, the United States Federal Government acknowledged the need to address accessibility in technology when it amended Section 508 (29 U.S.C. 794d) to the U.S. Rehabilitation Act. Section 508 outlines the accessibility standards for a wide range of U.S. government information sources and technologies, including Web sites.

Whether you manage a U.S. government Web site, market to the U.S. Government, or are simply interested in making your Web sites more accessible to people with disabilities, you can use the Accessibility Checker in Microsoft Office FrontPage 2003 to help you evaluate the accessibility of your Web sites and report on areas that are in conflict with the WCAG Priority 1 and Priority 2 accessibility guidelines and the Section 508 accessibility standards.

However, the Accessibility Checker does not check all accessibility guidelines. There are additional guidelines, such as WCAG Priority 3 guidelines, that you may also need to address. Therefore, you can extend the Accessibility Checker to include additional accessibility issues.

Working with Accessibility Guidelines

FrontPage 2003 uses XML documents to specify a collection of rules that address the various accessibility guidelines. These rules are contained in the following two Extensible Markup Language (XML) documents. The default location for these documents is C:\Program Files\Microsoft Office\OFFICE11\1033\Accessibility.

  • WCAG1_0.XML
  • WCAG_STR.XML

These two documents adhere to the XML Patterns (XMLP) schema and provide everything that FrontPage needs to check WCAG Priority 1 and Priority 2 guidelines and Section 508 standards. You can either add new rules to the main accessibility rules document (WCAG1_0.XML) or create supplemental XMLP documents. However, we encourage you to create additional XMLP documents, and then reference these in the main accessibility rules document. (This process is described in detail later in this article.)

Note   Throughout the XMLP documents, you will find XPath queries. A thorough discussion of XPath is beyond the scope of this article. For more information, see XPath Syntax in the Microsoft Developer Network (MSDN) Library.

Understanding XMLP

The first of these two files, WCAG1_0.XML, contains the main collection of accessibility rules. The XML code in Sample 1 shows how the accessibility guidelines translate into rules in an XMLP document. This excerpt from WCAG1_0.XML contains the main top-level ruleset element and a single category element. Each category element comprises a single accessibility guideline.

Sample 1. Excerpt from WCAG1_0.XML

<?xml version="1.0"?>
<xp:ruleset version="1.0" xmlns:xp="http://schemas.microsoft.com/2001/xmlpatterns">
  <xp:include src="WCAG_str.xml"/>
  <xp:category name="$Checkpoint1_1" href="$strRedir1_1">
    <xp:rule context="(//img) | (//noembed)">
      <xp:pattern match="@alt | @longdesc" is-assert="true" priority="1">
        <xp:report type="error">
          <xp:summary>
            <xp:value-of select="$str1_1_MissingAltAndLongDesc_Summary"/>
          </xp:summary>
          <xp:message>
            <xp:value-of select="$str1_1_MissingAltAndLongDesc"/>
          </xp:message>
        </xp:report>
      </xp:pattern>
    </xp:rule>
  </xp:category>
</xp:ruleset>

In Sample 1, note that the include element specifies the WCAG_str.xml file, which is the second XMLP document mentioned previously. This allows the contents of the second file to be pulled into the first file so that they are processed as a single XMLP document. This second XMLP document contains strings that are necessary in the first XMLP document. For example, in the category element shown in the above code, you will see the value of the name attribute is "$Checkpoint1_1." The dollar sign ($) indicates that the string that follows is a variable name, and the variable name is "Checkpoint1_1." In the WCAG_str.xml file, you will find a variable element that contains the corresponding string with the value "WCAG 1.1," which is shown in Sample 2. (Comments are removed from both samples).

Note   You do not need to use variables in your custom XMLP code. Microsoft uses variables in order to translate the strings into multiple languages. Later in this article, you will learn how you can specify the summary and message strings directly in the XMLP.

Sample 2. Variable element

<xp:variable name="Checkpoint1_1">
  WCAG 1.1
</xp:variable>

Note that in Sample 1, there is a single rule element within a single category element; however, a valid XMLP document may contain one or more category elements, and each category element may contain one or more rule elements that, when combined, create the functionality needed for a single guideline or standard.

Note   Sample 1 shows a fragment of the XMLP for the WCAG Checkpoint 1.1; the full XMLP for WCAG 1.1 contains multiple rule elements. For a full view of the related rules, open WCAG1_0.XML in Notepad. Sample 1 simply demonstrates the structure of the XMLP elements. For more information, see Understanding the XML Patterns Schema.

Each rule element contains one or more pattern elements that specify an XPath pattern. If the parent rule element contains a context attribute, the XPath defined in the pattern element searches for the specified pattern only within the context of the content returned for the context attribute. For example, WCAG Checkpoint 1.1 specifies that all non-text elements in a Web page contain an alt or longdesc attribute. Therefore, the context attribute for the corresponding XMLP rule element may specify that only these elements are returned. For example, Sample 1 includes the following XML. The XPath query used here returns only IMG and NOEMBED elements.

<xp:rule context="(//img) | (//noembed)">

In this case, the pattern element would specify an XPath pattern match that would check for the inclusion of the alt or longdesc attribute only, as shown in the following XMLP code also taken from Sample 1, within the returned set of IMG and NOEMBED elements.

<xp:pattern match="@alt | @longdesc" is-assert="true" priority="1">

The Accessibility Checker would then return an accessibility error for all IMG and NOEMBED elements that do not contain an alt or longdesc attribute.

Adding Accessibility Rules

Adding accessibility rules to the Accessibility Checker is a relatively simple process. The following section walks you through the process of creating an additional Accessibility Checker document.

In this section, you will add the first WCAG Priority 3 guideline, Checkpoint 1.5, to a new accessibility document. Following is the WCAG 1.5 guideline:

1.5   Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map. [Priority 3]

Checkpoint 1.5 also provides a reference to Checkpoint 1.2, which suggests providing redundant text links for server-side image maps. WCAG 1.2 is a Priority 1 guideline, and is therefore included in the rules that FrontPage automatically checks. Therefore, you can look at the code in the main accessibility documents to see how the XMLP is written to provide the built-in functionality. For simplicity, the XMLP code for WCAG 1.2 is shown in Sample 3. (Note: For simplicity, Sample 3 combines the XML for WCAG 1.2 from the two accessibility documents.)

Sample 3. XMLP code for WCAG 1.2

<xp:category name="$Checkpoint1_2" href="$strRedir1_2">
  <xp:rule context="(//img) | (//input)">
    <xp:pattern match="@ismap" priority="1">
      <xp:report type="warning">
        <xp:summary>
          <xp:value-of select="$str1_2_ImageMapPossibleNoTextLinks_Summary"/>
        </xp:summary>
        <xp:message>
          <xp:value-of select="$str1_2_ImageMapPossibleNoTextLinks"/>
        </xp:message>
      </xp:report>
    </xp:pattern>
  </xp:rule>
</xp:category>

<xp:variable name="Checkpoint1_2">
  WCAG 1.2
</xp:variable>

<xp:variable name="str1_2_ImageMapPossibleNoTextLinks">
  Ensure there are text links for each active region of this image map.
  If &lt;img&gt; is used provide a redundant list of links 
    following the image map.
</xp:variable>

<xp:variable name="str1_2_ImageMapPossibleNoTextLinks_Summary">
  Ensure there are text links for each active region of this image map.
</xp:variable>

In Sample 3, note that the rule context includes IMG and INPUT elements. The pattern match includes the ismap attribute. Therefore, this rule checks all IMG and INPUT elements for the ismap attribute. If these elements occur in an HTML page, the specified warning is included in the report that FrontPage generates.

Checkpoint 1.2 is designed for server-side image maps, and Checkpoint 1.5 is designed for client-side image maps. The only difference between these two checkpoints is that you would use the ismap attribute for server-side image maps and the usemap attribute for client-side image maps. Therefore, a simple change to the attribute name changes this rule to check for client-side image maps.

However, you also need to change the category name and the referenced URL, as shown in Sample 4, so that the report warning includes the correct reference information. The summary and message strings included in Sample 3 make no mention of client or server-side image maps, so they can work for either. Therefore, you do not need to change the summary and message strings.

One last change that you will need to make is to the priority attribute for the pattern element. Since Checkpoint 1.2 is a Priority 1 guideline, the XMLP indicates a priority attribute value of "1." However, the possible values for the priority attribute are "1" (for WCAG Priority 1), "2" (for WCAG Priority 2), and "4" (for Section 508). You can change the priority attribute value to indicate the accessibility check with which you want a custom rule associated. For this XMLP code, leave the priority value as it is. This means that this accessibility rule is associated with the Priority 1 accessibility rules.

Note   While WCAG 1.5 is not a Priority 1, there is not a comparable priority value in the XMLP schema for Priority 3 guidelines.

Sample 4. URL with reference information

<xp:category name="WCAG 1.5" href=" http://www.w3.org/TR/WCAG10/
   wai-pageauth.html#tech-redundant-client-links ">
    <xp:rule context="(//img) | (//input)">
        <xp:pattern match="@usemap" priority="1">
            <xp:report type="warning">
                <xp:summary>
                    Ensure there are text links for each 
                      active region of this image map.
                </xp:summary>
                <xp:message>
                    Ensure there are text links for each 
                      active region of this image map.
                        If &lt;img&gt; is used provide a 
                          redundant list of links following
                             the image map.
                </xp:message>
            </xp:report>
        </xp:pattern>
    </xp:rule>

</xp:category>

To ensure that this new rule is included every time a user performs an accessibility check, you need to save the XMLP code from Sample 4 to a valid XMLP document and modify the WCAG1_0.XML accessibility document to include the new file.

To create a valid XMLP document

  1. Open Notepad.

  2. Type or copy and paste the following code into a Notepad document:

    <?xml version="1.0" encoding="UTF-8"?>
<xp:ruleset version="1.0" xmlns:xp="http://schemas.microsoft.com/2001/xmlpatterns">

  3. Paste the code from Sample 4 after the code from Step 2.

  4. Type or copy and paste the following code at the end of the document.

    </xp:ruleset>

  5. Save the file as "WCAG1_0_Custom.xml" to the same folder in which WCAG1_0.XML is stored. (The default installation folder for the accessibility documents is C:\Program Files\Microsoft Office\OFFICE11\1033\Accessibility.)

To modify WCAG1_0.XML to include a reference the new file

  1. Open WCAG1_0.XML in Notepad.

  2. Immediately following the include line, <xp:include src="WCAG_str.xml" />, type or copy and paste the following text.

    <xp:include src=" WCAG1_0_Custom.xml" />

  3. Save the WCAG1_0.XML file.

After performing these steps, each time that you run a Priority 1 accessibility check for warnings on pages that contain image maps, FrontPage will create a report that includes this warning.

Creating this rule was a relatively simple matter after looking at the existing WCAG Checkpoint 1.2 XMLP code. However, you may have additional rules that require a greater understanding of the XMLP schema. Therefore, the following section provides reference information about the elements and attributes included in the XMLP schema.

Understanding the XML Patterns Schema

The XML Patterns (XMLP) schema is comprised of ten elements that give you a great deal of flexibility when adding custom accessibility rules.

Note   If you are unfamiliar with XML, XML stands for Extensible Markup Language. Similar to HTML, XML is a markup language designed for the Internet. However, unlike HTML, which was designed to define formatting of Web pages, XML was designed to describe data. You can use XML to develop custom schemas. As with HTML, the W3C defined the specifications for XML. For more information on XML and the XML specification, see Extensible Markup Language on the W3C Web site.

The syntax for the XMLP is shown in Sample 5. For information about a specific element, click on the element name.

Syntax

Sample 5. XML Patterns (XMLP) schema

<?xml version="1.0" encoding="UTF-8"?>
<xp:ruleset version="1.0" xmlns:xp="http://schemas.microsoft.com/2001/xmlpatterns">
    <xp:include />
    <xp:category >
        <xp:rule >
            <xp:pattern>
                <xp:report >
                    <xp:summary>
                        <xp:value />
                    </xp:summary>
                    <xp:message >
                        <xp:value-of />
                    </xp:message>
                </xp:report>
            </xp:pattern>
        </xp:rule>
    </xp:category>
    <xp:variable />
</xp:ruleset>

The first line of the query syntax shown in Sample 5 specifies the document type declaration. The version attribute indicates that the document conforms to version 1.0 of the XML specification. The character-set attribute indicates that the XML document is encoded using the UTF-8 transformation of ISO 10646.

category element

The category element encloses a collection of rules that, taken together, comprise a single accessibility guideline or standard. The category element is a required element. It may occur one or more times within a valid XMLP document, and it contains one required and one optional attribute.

Syntax

<xp:category>
    <xp:rule />
</xp:category>

Table 1. category element attributes

Name Description
href Optional. Specifies a URL where users can find additional information about the accessibility guideline or standard addressed with a collection of rules.
name Required. Specifies a string or variable reference that describes the accessibility guideline or standard for the collection of rules. Variable reference names must begin with a dollar sign ($) and have a corresponding variable element where the value of the variable is defined.

include element

The include element specifies another valid XMLP document that needs to be inserted into the current one. For example, the WCAG1_0.xml file mentioned in the previous section contains an include statement that specifies the WCAG_STR.xml file. This include statement pulls the WCAG_STR.xml file into the WCAG1_0.xml file so that they function as a single file. The include element is optional and contains one required attribute.

Syntax

<xp:include />

Table 2. include element attributes

Name Description
src Required. Specifies the path and filename for a valid XMLP document. You can use relative paths. In this case, FrontPage determines the base URL by one of the following:
  1. The path source XMLP document.

  2. The path of the calling application.

    Note   The file that you reference must be a valid XMLP document and, therefore, must contain the <?xml> document type declaration and the top-level ruleset element.

message element

The message element defines a plain-text message that FrontPage includes in the report generated for a rule. The message element contains no attributes and may contain one or more child value-of elements.

Syntax

<xp:message>
    <xp:value-of />
</xp:message>

pattern element

The pattern element specifies an XPath pattern match query. The pattern element is a required child element of the rule element and contains two optional attributes and one required attribute.

Syntax

<xp:pattern>
    <xp:report />
</xp:pattern>

Table 3. pattern element attributes

Name Description
is-assert Optional. Specifies whether a pattern match is missing. Setting the is-assert attribute to true indicates a problem if the match query returns empty. Default value is false.
match Optional. Specifies that the XPath query should run within the context set by the context attribute of the parent rule element.
priority Optional. Specifies an integer that represents the priority of the pattern. This value is returned if the is-assert attribute is set to true. Possible values are:
  • 1 – Indicates WCAG Priority 1
  • 2 – Indicates WCAG Priority 2.
  • 4 – Indicates Section 508.

report element

The report element surrounds a report block. FrontPage uses the contents of a report block to report accessibility issues to users. The report element contains one required attribute.

Syntax

<xp:report>
    <xp:summary />
    <xp:message />
</xp:report>

Table 4. report element attributes

Name Description
type Required. Indicates the type of error. May be one of the following string values:

error – Indicates a Web page contains an element that is inaccessible.

warning – Indicates that accessibility for a Web page may be broken.

guideline – Indicates an accessibility guideline.

rule element

The rule element specifies an XMLP rule that is used to match against an XPath query and sets the context of a pattern match query. The rule element is required and contains one optional attribute.

Syntax

<xp:rule>
    <xp:pattern />
</xp:rule>

Table 5. rule element attributes

Name Description
context Optional. Specifies an XPath query that is run against the source document. All nodes returned are passed to the child pattern elements. If omitted, the context for an XPath query is specified within each pattern element.

ruleset element

The ruleset element is the top-level element of an XMLP document that encloses the entire document. The ruleset element is required and contains three required attribute.

Syntax

<xp:ruleset version="1.0" xmlns:xp="http://schemas.microsoft.com/2001/xmlpatterns">
    <xp:include />
    <xp:category />
    <xp:variable />
</xp:ruleset>

Table 6. ruleset element attributes

Name Description
version Required. Specifies the version of the XMLP schema used in the XMLP document.
xmlns:prefix Optional. Specifies additional namespaces that are used in the XMLP document for XPath pattern matching. The namespace prefix may be anything other than the default namespace of "xp". This attribute allows you to define an XML namespace within the rule and pattern elements that checks for markup, such as VML, that specifies a different namespace.

For example, the following rule element will find all elements within the VML namespace. (You should note that this does not search for the prefix "vml", but any prefix defined with the VML namespace URI.)

<xp:rule xmlns:vml="http://www.w3.org/Recommendations/VML1" context="//vml:*">
xmlns:xp Required. Specifies the namespace URI for the XMLP schema. The version 1.0 namespace URI is: 
http://schemas.microsoft.com/2001/xmlpatterns

summary element

The summary element defines a plain-text summary of the contents of the message element that FrontPage includes in the report generated for a rule. The summary element contains no attributes and may contain one or more child value-of elements.

Syntax

<xp:summary>
    <xp:value-of />
</xp:summary>

value-of element

The value-of element specifies the value of the results found with the expression specified in the select attribute. The value-of element is optional and may be a child of the category, rule, pattern, report, summary, or message element. The value-of element contains one required attribute.

Syntax

<xp:value-of />

Table 7. value-of element attributes

Name Description
select Required. Specifies that the XPath query is to retrieve a resulting node or variable reference. If more than one node is returned with an XPath query, the first node returned is used.

variable element

The variable element defines an XMLP variable that is referenced elsewhere in an XMLP document. The variable element contains one required attribute.

Syntax

<xp:variable />

Table 8. variable element attributes

Name Description
name Required. Specifies a text string that represents the name of the variable. The variable name should be unique across the final rule set document. The value of the variable is contained in the child value-of element.

Conclusion

Designing accessible Web sites takes time and effort, and the Accessibility Checker in FrontPage 2003 helps you to reduce the amount of time you spend making your Web sites accessible to people with disabilities. However, as Web technologies grow and evolve, accessibility standards will expand and change as well. Now you can easily keep your Web sites updated by creating accessibility documents that enable you to comply with changes to accessibility standards.