[contents]

Abstract

This document specifies an internationally harmonized methodology for evaluating the accessibility conformance of websites to the Web Content Accessibility Guidelines (WCAG) 2.0. This specified methodology supports conformance evaluation in different contexts, including self-assessment and third-party evaluation. It is applicable to any website, including web applications and websites for mobile devices, and is independent of any particular evaluation tools, web browsers, and assistive technologies.

Status of this document

This clause describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This 3 March 2012 Editors Draft of Website Accessibility Conformance Evaluation Methodology 1.0 is intended to be published and maintained as a W3C Working Group Note after review and refinement. This version reflects the input and discussions from the EvalTF and provides direction and focus to evaluators who want to evaluate accessibility conformance against the WCAG 2.0 guidelines.

The WCAG 2.0 Evaluation Methodology Task Force (Eval TF) invites discussion and feedback about this document by developers, evaluators, researchers, and other practitioners who have interest in web accessibility evaluation. In particular, Eval TF is looking for feedback on section 3 and the changes to the other sections compared to the previous version.

Please send comments on this Website Accessibility Evaluation Methodology for WCAG 2.0 document to public-wai-evaltf@w3.org (publicly visible mailing list archive).

Publication as Editor Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Table of Contents

  1. Introduction
  2. Using this Methodology
  3. Evaluation Procedure
  4. Conformance with this Methodology
  5. Limitations of this Methodology

Appendices

1. Introduction

Website owners, procurers, suppliers, developers, and others are frequently tasked with assessing the conformance of an existing website to the Web Content Accessibility Guidelines (WCAG) 2.0. Because it is generally not feasible nor desired to evaluate every single web page in such a context, it is essential to employ a reliable method for determining the overall conformance level of a website.

This document constitutes a standardized methodology for evaluating the conformance of websites, including web applications and websites for mobile devices, to WCAG 2.0. It is developed through the open, collaborative W3C Process with participation and involvement of international experts and stakeholders. It is a supporting document for WCAG 2.0 and does not replace or supersede it in any way.

1.1 Scope of this Document

The methodology described in this document supports conformance evaluation in different contexts including self-assessment and third-party assessment of websites. It is applicable to all websites, including web applications, websites for mobile devices, and other types of websites. It is independent of the size of the website, the web technologies used to create the website, and of any particular web accessibility evaluation tools, web browsers, assistive technologies, and other software tools.

While this document provides useful guidance for evaluation throughout the website development process it focuses primarily on the last stage of the process, in which confirmation is sought on whether conformance targets have been achieved (commonly referred to as acceptance testing). The document presents concrete steps to define the scope of the evaluation, select a representative sample, audit the selected sample and aggregate and report the results of the evaluation findings in a structured and uniform way.

1.2 Target Audience

The primary target audience for this methodology are individuals and organizations, wanting to evaluate the conformance of existing websites to WCAG 2.0. This includes but is not limited to:

Other audiences for whom this methodology is also relevant include:

Users of the methodology are assumed to have expertise in WCAG 2.0, accessible web design, assistive technologies, and of how people with different disabilities use the Web; read more in section 2. Using this Methodology.

1.3 Background Reading

It is assumed that the reader of this document is familiar with the following resources:

Evaluating Websites for Accessibility

A multi-page resource suite that outlines different approaches for evaluating websites for accessibility. The following resources are particularly important in this context:

Web Content Accessibility Guidelines (WCAG) 2.0

Internationally recognized standard explaining how to make web content more accessible to people with disabilities. The following resources are particularly important in this context:

Accessible Web Design

These documents explore the potential overlap of essential components of web accessibility, inclusive design and people with disabilities and the elderly. They are meant to help managers, designers, developers, policy makers, researchers, and others optimize their efforts in these overlapping areas.

1.4 Terms and Definitions

For the purposes of this document, the following terms and definitions apply:

Elemental Web Pages
Fundamental web pages that are relevant to the entire website. This includes the homepage, login page, and other entry pages, and, where applicable, the sitemap, contacts, site help, legal information, and similar web pages that are typically linked from all web pages (usually from the header, footer, or navigation menu of a web page).
Evaluator
The person, team of people, organization, in-house department, or other entity responsible for carrying out the evaluation.
Evaluation Commissioner
The person, team of people, organization, in-house department, or other entity that commissioned the evaluation. The Evaluation Commissioner can also be the website owner.
Key Functionality
@@@SHADI: I added this term and definition from your definition in step 2b:
Primary functionality of a website that is expressed in the terms of tasks for the users of the website, such as "selecting and purchasing a product from the shop area of the website", "filling and submitting the form provided on the website", or "contributing comments in the forum area of the website".
Website developer
Anyone involved in the website development process including but not limited to content authors, designers, programmers, quality assurance testers, and project managers.
Website Owner
The person, team of people, organization, in-house department, or other entity that is responsible for the website.
Web page
"A non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent", as defined by WCAG 2.0 in http://www.w3.org/TR/WCAG20/#webpagedef.
Website
A coherent collection of one or more related web pages that together provide common use or functionality. It includes static web pages, dynamically generated web pages, and web applications.

2. Using This Methodology

The methodology defined by this document is used for comprehensively assessing the conformance of websites to WCAG 2.0. A more cursory approach for exploring the accessibility of a website is described in Preliminary Review of Websites for Accessibility. In many cases it is advisable to carry out such preliminary reviews before applying this methodology, for example to identify obvious errors and to develop a rough understanding of the overall performance of the website.

2.1 Scope of Applicability

The methodology defined by this document applies to full, self-enclosed websites. Examples of such websites include:

While a website in this context can be part of a larger website, the methodology always applies to a full website without exclusions or ommissions of website parts. For example, the methodology could be applied to the website of a university or the library of that university, but the methodology may not be applied to the website of the university excluding the website of the library.

It is also not possible to exclude individual web pages or functions such as an embedded mapping application or a linked credit card authorization form as

@@@SHADI: SHOULD THIS BE "IF THIS WOULD CONFLICT WITH..."? IN THE CURRENT VERSION, IT MEANS THAT YOU WOULD ALWAYS HAVE TO INCLUDE EMBEDDED MAPPING APPLICATIONS. WE SOMETIMES AGREE TO LEAVE THEM OUTSIDE OF THE SCOPE IF THEY ARE NOT KEY FUNCTIONALITY OF A WEBSITE..

this would conflict with the complete processes requirement of WCAG 2.0 (the WCAG 2.0 concept for conforming alternate versions may be useful in some of these situations). Similarly, for websites that are parts of other websites it is also not possible to exclude shared web pages that are part of both websites, such as a common contacts page or site navigation.

Exception: The methodology can be applied to clearly separable areas of a single website, such as to the public and restricted area of a website or the front-end and back-end of a web-based tool, provided that this scope matches the evaluation goals and the context of website use; read more in section Step 1: Define the Evaluation Scope of the evaluation procedure.

2.2 Required Expertise

Users of the methodology defined by this document are assumed to be knowledgeable of WCAG 2.0, accessible web design, assistive technologies, and of how people with different disabilities use the Web. This includes understanding of the relevant web technologies, barriers that people with disabilities experience, assistive technologies and approaches that people with disabilities use, and evaluation techniques and tools to identify potential barriers for people with disaibilities. Background reading is proposed in section 1.3.

2.3 Evaluation Tools (Optional)

The methodology defined by this document is independent of any particular web accessibility evaluation tool, web browsers, and other software tools. However, web accessibility evaluation tools can significantly assist an evaluator during the evaluation process and contribute to more effective evaluations. For example, web accessibility evaluation tools can scan entire websites to help identify relevant pages for manual evaluation, and they can assist manual evaluation in a variety of ways. Specific guidance is provided in Selecting Web Accessibility Evaluation Tools.

Note that tools can only check for a limited set of accessibility guidelines that can be tested automatically. Additional manual testing isalways necessary to determine a given conformance level.

2.4 Review Teams (Optional)

The methodology defined by this document can be carried out by an individual evaluator with the skills described in section 2.2 Required Expertise. However, using the combined expertise of review teams provides better coverage for the required skills and helps identify accessibility barriers more effectively. While not required, it is strongly recommended to employ review teams for conformance evaluation of websites. Specific guidance is provided in Using Combined Expertise to Evaluate Web Accessibility.

2.5 Involving Users (Optional)

The methodology defined by this document can be carried out by an individual evaluator with the skills described in section 2.2 Required Expertise. However, involving people with disabilities and older people helps identify additional accessibility barriers that are not easily discovered by the evaluator alone. While not required, it is strongly recommended to involve real people during the evaluation process. Specific guidance is provided in Involving Users in Web Accessibility Evaluation.

3. Evaluation Procedure

This section defines the steps of the evaluation procedure. The specifics of these steps may shift slightly depending on the type of website, the purpose of the evaluation, and the process used by the evaluator. Some of the steps may also overlap or be carried out in parallel but it is important that all steps are considered to ensure a reliable assessment. It is also important to clearly document each step to ensure verifiable results and justifiable conformance claims.

Step 1: Define the Evaluation Scope

During this step the overall scope of the evaluation is defined. It is a fundamental step that affects the subsequent steps in the evaluation procedure and is ideally carried out together with the evaluation commissioner and the website owner. In many cases the evaluation commissioner may be the website owner, in other cases it may be another entity such as a procurer or an accessibility monitoring survey.

Step 1.a: Define the Scope of the Website

During this step the exact scope of the website is defined and documented. The scope definition of the website may not contradict the scope of applicability of this methodology, as defined in section 2.1 Scope of Applicability.

[Editor Note: Do we need further explanation here? Maybe provide some example scope definitions?]

Step 1.b: Define the Goal of the Evaluation

Defining the goal of the evaluation is particularly relevant to the auditing stage defined in Step 4: Audit the Selected Sample and the reporting stage defined in Step 5: Report the Evaluation Findings. Some of the evaluation goals include:

Basic Conformance
Only identifies whether a website conforms or not, but does not provide any additional information. This type of evaluation is typically carried out when the website is assumed to conform, for example to verify a conformance claim, and for large-scale evaluations with less resources to explore the details of individual websites.
Detailed Review
Identifies whether a website conforms or not, and provides further information about any identified errors. This includes counts of the number of errors and their locations within the web pages. This type of evaluation is particularly useful for instructing web developers and for acquiring statics for monitoring progress over time.
In-Depth Analysis
Identifies whether a website conforms or not, and analyzes any identified errors in detail. This includes descriptions of the errors and suggestions for possible repair options. This type of evaluation is particularly useful for organizations that want to improve the accessibility of their website and need a detailed analysis

Step 1.c: Define the Conformance Target

Part of initiating the evaluation process is to define the target WCAG 2.0 conformance level ("A", "AA", or "AAA") to evaluate for. In many situations it is useful to evaluate to WCAG 2.0 Level AAA even if the conformance target for website is below that, because a full evaluation provides a more complete picture of the website performance. For example, it can identify accessibility requirements beyond the website conformance target that the website conforms to and helps develop more effective plans for improving entire aspects of a website (such as improving how tables, forms, widgets, videos, and other components are generated or developed) rather than fixing individual errors one by one.

Step 1.d: Define the Context of Website Use

Define who uses the website and how they use it. It is particularly important to define if a website is public or restricted to specific users, such as an intranet or a website that requires authentication for use. In some situations there may be more than one mode of use, for example a website with a public area and a restricted area for selected users or websites depending on user characteristics. Each of those modalities must be identified and clearly documented.

Following the definition for the mode of use it is important to also define the minimum set of web browsers and assistive technology to evaluate for. For example, if it is an intranet with known software that will access the website then this definition will be significantly different from a public website with unknown software. This definition is also influenced by language, geographical location, and the target audience of the website. This definition of software support may not conflict with the WCAG 2.0 guidance on the Level of Assistive Technology Support Needed for "Accessibility Support".

Step 1.e: Define the Techniques to be Used (Optional)

While optional, it is usually quite important to define the WCAG 2.0 Techniques that will be used to carry out the evaluation, to ensure consistent expectation between the evaluation commissioner and the evaluator. W3C/WAI provides a set of publicly documented Techniques for WCAG 2.0 but other techniques may be used too.

Note: This step may overlap with the exploration of the website defined in Step 2: Explore the Target Website.

Step 2: Explore the Target Website

During this step the evaluator explores the target website to be evaluated, to develop a better understanding of the website use and functionality. Carrying out initial cursory checks during this stage already helps identify web pages that are relevant for more detailed evaluation later on. For example, an evaluator may identify web pages that seem to be lacking color contrast, consistent navigation, or document structures (headings, links, etc.) with simple checks while studying the website, and note them down as candidates for selection in the sampling step defined in Step 3: Select a Representative Sample.

For carrying out this step it is critical that the evaluator has access to all the relevant parts of the website to be evaluated. For example, it may be necessary to create accounts or otherwise provide access for evaluators to restricted areas of a website that are part of the evaluation.

Step 2.a: Identify Elemental Web Pages of the Website

During this step the elemental web pages of the website are identified and documented. In most situations the elemental web pages will be part of the sample to be selected through the steps defined in Step 3: Select a Representative Sample. This step also helps understand key aspects of the website, such as the navigational structures and overall structure of the website.

Step 2.b: Identify Key Functionality of the Website

During this step the key functionality of the website is identified and documented, to provide a comprehensive basis for the sample to be selected through the steps defined in Step 3: Select a Representative Sample. Functionality should be expressed in terms of tasks for the users of the website, such as "selecting and purchasing a product from the shop area of the website", "filling and submitting the form provided on the website", or "contributing comments in the forum area of the website".

Step 2.c: Identify the Variety of Web Page Types

Web pages with varying styles, layouts, structures, and functionality often have different implementations of accessibility features. They are also often generated by different templates and authored by different people. It is important to identify and document the different types of web page designs to provide a comprehensive basis for the sample to be selected through the steps defined in Step 3: Select a Representative Sample.

Note: The variety targetted by this step includes variety of design as well as functionality. Specifically, it includes web pages that provide varying visual and interaction designs and web page elements such as forms, tables, lists, headings, multimedia, and scripting.

Step 2.d: Identify Technologies Used in the Website

During this step the web technologies used to create the website are identified documented, to provide a comprehensive basis for the sample to be selected through the steps defined in Step 3: Select a Representative Sample. This includes base web technologies such as HTML and CSS, auxillary web technologies such as Flash, JavaScript, PDF, Silverlight and WAI-ARIA, as well as advanced web technologies such as SMIL and SVG.

Step 3: Select a Representative Sample

From exploration of the website defined in Step 2: Explore the Target Website the evaluator should have an understanding of the website, to facilitate the selection of a sample of web pages that is representative of the entire website. Depending on the size and complexity of the website, the size of this sample will vary. For example, a website with few types of web pages that are all generated from confined templates, such as a data repository, will likely require a much smaller sample to evaluate than a website with many types of web pages that are authored using different mechanisms.

The web pages identified through the exploration will typcially relate to more than one aspect. For example, web pages with particular functionality such as scripting, multimedia, and forms will typically also use related technologies such as Flash, JavaScript, PDF, Silverlight, and WAI-ARIA, and in many cases these web pages may have different designs to other pages. A carefull selection of web pages can significantly reduce the required sample size while maintaining appropriate representation of the entire website.

Step 3.a: Include Elemental Web Pages of the Website

The elemental web pages identified through the step defined in Step 2.a: Identify Elemental Web Pages of the Website usually provide key information and functionality for website users and are to be included as part of the selected sample. Additional key web pages such as particularly popular web pages (identified through the server logs, search engine rankings, etc.), web pages that are particularly relevant for people with disabilities, and web pages that explain the functionality of the website should also be included where applicable.

Step 3.b: Include Examplar Instances of Web Pages

From the variety of web pages and types of web page identified through the steps defined in Step 2: Explore the Target Website, select at least two distinct web pages with the following features each (where applicable):

Reminder: A selected web page could have any number of these features. For example, a selected web page could be used to represent the use of forms and scripting at the same time. The important aspect is to select at least two distinct pages for each type of form and scripting identified on the website.

Note: When a website is being re-evaluated, it is sometimes useful for comparision to include a portion of web pages from the sample selected for the previous evaluation. However, the majority of web pages should be freshly selected to provide an accurate representation of the entire website.

Step 3.c: Include Edge Cases and Atypical Web Pages

[Editore Note: This section will include guidance on including web pages that do not match any of the above selection aspects, in particular to address web pages that are frequently missed by evaluators.]

Step 3.d: Include Complete Processes in the Sample

The WCAG 2.0 conformance requirement complete processes reads as follows:

"When a Web page is one of a series of Web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all Web pages in the process conform at the specified level or better. (Conformance is not possible at a particular level if any page in the process does not conform at that level or better.)"

For this reason, the selected sample must include all web pages that belong to a series of web pages presenting a process for each web page selected. In other words, no web page in the selected sample may be part of a process without all other web pages that are part of that process to be also included in the selection.

Step 4: Audit the Selected Sample

[Editore Note: This section will provide guidance on applying WCAG 2.0 to the selected sample. An introduction to this section will be inserted here.]

Step 4.a: Check for the Broadest Variety of Use Cases

[Editore Note: This section will instruct evaluators to apply all WCAG 2.0 Success Criteria for each web page in the selected sample, and in doing so to consider the broadest possible set of users, software tools, and use cases as scoped out in Step 1.d: Define the Context of Website Use.]

Step 4.b: Apply Documented WCAG 2.0 Techniques

[Editore Note: This section will instruct evaluators to use documented WCAG 2.0 Techniques for auditing the selected web pages, ideally those initially defined in Step 1.e: Define the Techniques to be Used (Optional).]

Step 4.c: Assess Accessibility Support for Techniques

[Editore Note: This section will instruct evaluators to assess accessibility support for WCAG 2.0 Techniques used and accessibility features identified in the audited web pages, ideally those initially defined in Step 1.d: Define the Context of Website Use.]

Step 4.d: Archive Web Pages for Reference (Optional)

[Editore Note: This section will advise evaluators to archive the audited web pages in any form (screenshots, saving copies of the web page, etc.) for future references and in case of disputes. This step is optional.]

Step 5: Report the Evaluation Findings

[Editore Note: This section will provide guidance on reporting the evaluation findings. An introduction to this section will be inserted here.]

Step 5.a: Provide Documentation for Each Step

[Editore Note: This section will provide guidance on documenting each step and will link to Appendix C: Template Reports for different types of sample reports. The Methodology will not require such documentation to be public, as it is up to the website owner and/or evaluation commissioner to choose disclosing it.]

Step 5.b: Provide an Accessibility Statement (optional)

[Editore Note: This section will provide guidance on providing public accessibility statements referencing the outcomes of an evaluation according to this Methodology. This step is optional. However, in this case the website owners and/or evaluation commissioners choose to make a public conformance statement according to this Methodology so that certain restrictions can be applicable. For instance, it may be important to at least include or reference information about the scope defined in Step 1: Define the Evaluation Scope in such a public statement.]

Step 5.c: Provide a Performance Score (optional)

[Editore Note: This section will provide guidance on calculating an overall performance score. This step is optional. There is currently no particular alogrithm for this calculation but it is likely that this step may only be available to evaluations of type Detailed Review and above, to ensure sufficient data for aggregating a useful score.]

Step 5.d: Provide Information on the Findings (optional)

[Editore Note: This section will provide guidance on providing additional information on any identified errors, using existing WCAG 2.0 materials where possible. This step is optional.]

Step 5.e: Provide Suggestions for Repairs (optional)

[Editore Note: This section will provide guidance on providing suggestions for repairing any identified errors, using existing WCAG 2.0 materials where possible. This step is optional.]

Step 5.f: Provide a Machine-Readable Report (optional)

[Editore Note: This section will provide guidance on providing machine-readable reports in addition to a human-readable form. This step is optional.] There will be an appendix or a link to an example machine readable report based on the manual report.

4. Conformance with this Methodology

Evaluations that conform with this website accessibility conformance evaluation methodology must fulfill the following requirements:

Requirement 1: Website Scope
The scope of the website shall be defined according to the constraints expressed in section 2.1 Scope of Applicability. Read more background in section Step 1.a: Define the Scope of the Website.
Requirement 2: Evaluation Goal
The goal of the evaluation shall be defined. Read more background in section Step 1.b: Define the Goal of the Evaluation.
Requirement 3: Conformance Target
The target WCAG 2.0 conformance level ("A", "AA", or "AAA") to evaluate for shall be defined. Read more background in section Step 1.c: Define the Conformance Target.
Requirement 4: Context of Website Use
The users of the website and minimum set of web browsers and assistive technology to evaluate for shall be defined, noting that the definition of software support shall not conflict with the WCAG 2.0 guidance on the Level of Assistive Technology Support Needed for "Accessibility Support". Read more background in section Step 1.d: Define the Context of Website Use.
Requirement 5: Techniques to be Used (Optional)
The WCAG 2.0 techniques to be used during the evaluation should be defined. Read more background in section Step 1.e: Define the Techniques to be Used (Optional).
Requirement 6: Sufficient Access
Evaluators shall have sufficient access to all web pages that are part of the evaluation scope.
Requirement 7: Elemental Web Pages
The elemental web pages of the website shall be identified. Read more background in section Step 2.a: Identify Elemental Web Pages of the Website.
Requirement 8: Key Functionality
The key functionality of the website shall be identified. Read more background in section Step 2.b: Identify Key Functionality of the Website.
Requirement 9: Web Page Designs
The variety of web page designs shall be identified. Read more background in section Step 2.c: Identify the Variety of Web Page Designs.
Requirement 10: Technologies Used
The technologies used to create the website shall be identified. Read more background in section Step 2.d: Identify Technologies Used in the Website.
Requirement 11: Tools Used
The tools used to evaluate the website will be identified including the version number and possible calibration dates.
Requirement 12: @@@
@@@
Requirement 13: @@@
@@@
Requirement 14: @@@
@@@
Requirement 15: @@@
@@@
Requirement 16: @@@
@@@
Requirement 17: @@@
@@@
Requirement 18: @@@
@@@
Requirement 19: @@@
@@@

5. Limitations of this Methodology

[Editore Note: This section will discuss the limitiations of this methodology, in particular that such evaluations are always an approximation to the true conformance (which would require evaluating every single page on a website). It will also highlight aspects of applicability, such as large-scale evaluations that may not be able to include extensive samples so that they would possibly meet the requirements of this methodology. Suggestions for other considerations for this section are requested.]

Appendices

Appendix A. Acknowledgements

This publication has been developed with support from the European Commission funded WAI-ACT Project (IST 287725).

Contributors

@@@

Appendix B. References

Editor note: Below list needs correct formatting.

QA-FRAMEWORK
Dubost K, Rosenthal L, Hazaël-Massieux D, Henderson L (eds) (2005) W3C Quality Assurance Framework: Specification Guidelines. W3C. Available at: http://www.w3.org/TR/qaframe-spec/
RFC3986
Fielding R, Gettys J, Mogul J, Frystik H, Masinter L, Berners-Lee T (eds) (1999). Hypertext Transfer Protocol - HTTP/1.1. Request for Comments: 2616. IETF. Available at: http://www.ietf.org/rfc/rfc2616.txt
RFC2616
Berners-Lee T, Fielding R, Masinter L (eds) (2005). Uniform Resource Identifier (URI): Generic Syntax. Request for Comments: 3986. IETF. Available at: http://www.ietf.org/rfc/rfc3986.txt
UWEM
Velleman E.M, Velasco C.A, Snaprud M (eds) (2007). D-WAB4 Unified Web Evaluation Methodology (UWEM 1.2 Core). Wabcluster. Available at: http://www.wabcluster.org/uwem1_2/

Appendix C. Template for manual evaluation report

Editor note: A complete example template for evaluation reporting in human understandable language. Discussion proposal below built upon the idea to have three different levels of reporting. The template will have to be ok for official evaluations so some change is still necessary. The difference between option 1 and 2 is currently very small (open for discussion).This section needs appending to the requirements in section 4.

This Appendix proposes three different levels of reporting following the discussion in clause 5 on levels of evaluation. The three options are:

The options should at least have the following information:

Option 1

Results

Guideline X (heading)

Checkpoint: SC XX (subheading)

Result: pass/fail

Character: global/regional (or another wording) if regional: a list of pages where the problem exists

General information about this checkpoint: link to how to meet and to understanding this success criteria.

List of user agents, including assistive technologies that where used during the evaluation of the website and their versions.

List of pages in the sample

Option 2

Results

Guideline X (heading)

Checkpoint: SC XX (subheading)

Result: pass/fail

Character: global/regional (or another wording) if regional: a list of pages where the problem exists

Description of existing problems and barriers for users or link to descriptions on W3C/WAI website.

General information about this checkpoint: link to how to meet and to understanding this success criteria.

List of user agents, including assistive technologies that where used during the evaluation of the website and their versions.

List of pages in the sample

Option 3

Results

Guideline X (heading)

Checkpoint: SC XX (subheading)

Result: pass/fail

Character: global/regional (or another wording) if regional: a list of pages where the problem exists

Description of existing problems and barriers for users or link to descriptions on W3C/WAI website..

General information about this checkpoint: link to how to meet and to understanding this success criteria.

Action: Description of techniques for meeting the SC (could be techniques which are already in the techniques document or new techniques which are not in the document, but with which the SC can be met).

List of user agents, including assistive technologies that where used during the evaluation of the website and their versions.

List of pages in the sample