understanding/conformance.html

<!DOCTYPE html><html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head xmlns:wcag="https://www.w3.org/WAI/GL/">
   <meta charset="UTF-8"/>
   <title>Understanding Conformance</title>
   <link rel="stylesheet" type="text/css" href="../../css/sources.css" class="remove"/>
</head>
<body xmlns:wcag="https://www.w3.org/WAI/GL/">
   <h1>Understanding Conformance</h1>
   
   
   <p>All WCAG 2 success criteria are written as testable criteria for objectively determining
      if content satisfies them. Testing the success criteria would involve a combination
      of automated testing and human evaluation. The content should be tested by those who
      understand how people with different types of disabilities use the Web.
   </p>
   
   <p>Testing and testable in the context refer to functional testing, that is verifying
      that the content functions as expected, or in this case, that it satisfies the success criteria.
      Although content may satisfy all success criteria, the content may not always
      be usable by people with a wide variety of disabilities. Therefore, usability testing
      is recommended, in addition to the required functional testing. Usability testing
      aims to determine how well people can use the content for its intended purpose. It
      is recommended that users with disabilities be included in test groups when performing
      usability testing.
   </p>
   
   <section id="conformance-whatis">
      
      <h2>What does conformance mean?</h2>
      
      <p>Conformance to a standard means that you meet or satisfy the 'requirements' of the
         standard. In WCAG 2 the 'requirements' are the success criteria. To conform to WCAG
         2, you need to satisfy the success criteria, that is, there is no content which
         violates the success criteria.
      </p>
      
      <div class="note">
         
         <p>This means that if there is no content to which a success criterion applies, the success criterion is satisfied.
         </p>
         
      </div>
      
      <p>Most standards only have one level of conformance. In order to accommodate different
         situations that may require or allow greater levels of accessibility than others,
         WCAG 2 has three levels of conformance, and therefore, three levels of success criteria.
      </p>
      
   </section>
   
   <section id="conformance-requirements">
      
      <h2>Understanding Conformance Requirements</h2>
      
      <p>There are five requirements that must be met in order for content to be classified
         as 'conforming' to WCAG 2. This section provides brief notes on those requirements.
         This section will be expanded over time to address questions that may arise or to
         provide new examples of ways to meet the different conformance requirements.
      </p>
      
      <section id="conf-req1">
         
         <h3>Understanding Requirement 1</h3>
         
         <blockquote class="scquote" id="cc1">
         	<p><strong>Conformance Level</strong>: One of the following levels of conformance is met in full.</p>
         	<ul>
         		<li>For Level A conformance (the minimum level of conformance), the <a>Web page</a>
         			<a>satisfies</a> all the Level A success criteria, or a <a>conforming alternate version</a> is provided.</li>
         		<li>For Level AA conformance, the Web page satisfies all the Level A and Level AA success criteria, or a Level AA conforming alternate version is provided.</li>
         		<li>For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA success criteria, or a Level AAA conforming alternate version is provided.</li>
         	</ul>
         	<p class="note">Although conformance can only be achieved at the stated levels, authors are encouraged to report (in their claim) any progress toward meeting success criteria from all levels beyond the achieved level of conformance.</p>
         	<p class="note">It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.</p>
         	
         </blockquote>
         
         <p>The first requirement deals with the levels of conformance. It basically says that
            all information on a page conforms or has a 
            <a>conforming alternate version</a> that is available from the page. The requirement also explains that no conformance
            is possible without at least satisfying all of the Level A success criteria. 
         </p>
         
         <p>The note points out that authors are encouraged to go beyond conformance to a particular
            level and to complete, and report if they desire, any progress toward higher levels
            of conformance.
         </p>
         
         <p>See also 
            <a href="#conforming-alt-versions">Understanding Conforming Alternate Versions</a> which includes techniques for providing Conforming Alternate Versions.
         </p>
         
      </section>
      
      <section id="conf-req2">
         
         <h3>Understanding Requirement 2</h3>
         
         <blockquote class="scquote" id="cc2">
         	<p><strong>Full pages</strong>: <a>Conformance</a> (and conformance level) is for full <a>Web page(s)</a> only, and cannot be achieved if part of a Web page is excluded.</p>
         	<p class="note">For the purpose of determining conformance, alternatives to part of a page's content are considered part of the page when the alternatives can be obtained directly from the page, e.g., a long description or an alternative presentation of a video.</p>
         	<p class="note">Authors of Web pages that cannot conform due to content outside of the author's control may consider a <a href="#conformance-partial">Statement of Partial Conformance</a>.</p>
         	<p class="note">A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.</p>
         </blockquote>
         
         <p>This provision simply requires that the whole page conform. Statements about "part
            of a page conforming" cannot be made.
            
         </p>
         
         <p>Sometimes, supplemental information may be available from another page for information
            on a page. The longdesc attribute in HTML is an example. With longdesc, a long description of a graphic might be on a separate page that the user can jump
            to from the page with the graphic. This makes it clear that such content is considered
            part of the Web page, so that requirement #2 is satisfied for the combined set of
            Web pages considered as a single Web page. Alternatives can also be provided on the
            same page. For example creating an equivalent to a user interface control.
            
         </p>
         
         <div class="note">
            
            <p>Because of conformance requirement 5, a whole page may conform even if parts of the
               page use non accessibility-supported content technologies as long as they do not interfere
               with the rest of the page and all information and function is available elsewhere
               on or from the page.
            </p>
            
            <p>It is possible to include non-conforming content. See 
               <a href="#conf-req5">Understanding Conformance Requirement 5</a>.
            </p>
            
         </div>
         
      </section>
      
      <section id="conf-req3">
         
         <h3>Understanding Requirement 3</h3>
         
         <blockquote class="scquote" id="cc3">
         	<p><strong>Complete processes</strong>: When a <a>Web page</a> is one of a series of Web pages presenting a <a>process</a> (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.)</p>
         	<p class="example">An online store has a series of pages that are used to select and purchase products. All pages in the series from start to finish (checkout) conform in order for any page that is part of the process to conform.</p>
         </blockquote>
         
         <p>This provision prevents a Web page that is part of a larger process from being considered
            conforming if the process overall is not. This would prevent a shopping site from
            being classified as conforming if the checkout or other features of the site that
            are part of the shopping and buying process do not conform.
         </p>
         
      </section>
      
      <section id="conf-req4">
         
         <h3>Understanding Requirement 4</h3>
         
      	<blockquote class="scquote" id="cc4">
      		<p><strong>Only Accessibility-Supported Ways of Using Technologies</strong>: Only <a>accessibility-supported</a> ways of using <a>technologies</a> are <a>relied upon</a> to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported. (See <a href="#accessibility-support">Understanding accessibility support</a>.)</p></blockquote>
         
         <p>This conformance requirement is explained below under
            <a href="#accessibility-support">Understanding Accessibility Support</a>.
         </p>
         
      </section>
      
      <section id="conf-req5">
         
         <h3>Understanding Requirement 5</h3>
         
      	<blockquote class="scquote" id="cc5">
      		<p><strong>Non-Interference</strong>: If <a> technologies </a> are used in a way that is not <a>accessibility supported</a>, or if they are used in a non-conforming way, then they do not block the ability of users to access the rest of the page. In addition, the <a>Web page</a> as a whole continues to meet the conformance requirements under each of the following conditions:</p>
      		<ol>
      			<li>when any technology that is not <a>relied upon</a> is turned on in a user agent,</li>
      			<li>when any technology that is not relied upon is turned off in a user agent, and</li>
      			<li>when any technology that is not relied upon is not supported by a user agent</li>
      		</ol>
      		<p>In addition, the following success criteria apply to all content on the page, including content that is not otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of the page:</p>
      		<ul>
      			<li><strong>1.4.2 - Audio Control</strong>,</li>
      			<li><strong>2.1.2 - No Keyboard Trap</strong>,</li>
      			<li><strong>2.3.1 - Three Flashes or Below Threshold</strong>, and</li>
      			<li><strong>2.2.2 - Pause, Stop, Hide</strong>.</li>
      		</ul>
      		<p class="note">If a page cannot conform (for example, a conformance test page or an example page), it cannot be included in the scope of conformance or in a conformance claim.</p>
      	</blockquote>
         
         <p>This basically says that technologies that are 
            <strong>not accessibility supported</strong> can be used, as long as all the information is also available using technologies
            that 
            <strong>are accessibility supported</strong> and as long as the 
            <strong>non-accessibility-supported</strong> material does not interfere.
         </p>
         
         <p>Technologies that are not accessibility supported can be used, or technologies that
            are accessibility supported can be used in a non conforming manner, as long as all
            the information is also available using technologies that are accessibility supported,
            in a manner that does conform, and as long as the non-accessibility-supported material
            does not interfere.
         </p>
         
         <p>There are four provisions that particularly deal with issues of interference with
            use of the page. These four are included in a note here. A note on each of the provisions
            indicates that these success criteria need to be met for all content including content
            created using technologies that are not accessibility supported.
         </p>
         
         <div class="example">
            
            <p>A Web page incorporates a new interactive graphic technology called "ZAP". Although
               ZAP is not accessibility-supported, the information that is presented in ZAP is also presented
               on the page in HTML, so ZAP is not relied upon. So, this page would pass conformance
               requirement #1.  However, if the user tries to tab through the ZAP content, the focus
               drops into the ZAP object and gets stuck there.  Once inside, there is nothing the
               user can do to get the focus back out.  So keyboard users cannot use the bottom half
               of the page. The ZAP content also is continually flashing brightly at different rates
               and doesn't stop.   So, people with attention deficit are distracted and those with
               photosensitive seizure disorders may have seizures.  Conformance requirement #5 prevents
               situations like these from being possible on a conforming page. 
            </p>
            
         </div>
         
      </section>
      
   </section>
   
   <section id="conformance-claims">
      
      <h2>Understanding Conformance Claims</h2>
      
      <p>It is not required to make any conformance claim in order to conform. If one does
         make a claim, however, all the information required in a conformance claim must be provided. There are a number of ways this information can be provided. 
      </p>
      <p>Schema.org provides one such option for including discovery metadata within a Web page. A set of descriptive accessibility properties is available under the CreativeWork type which, among other uses, provides the ability to include a summary of the overall accessibility of the page (e.g., the WCAG conformance claim), describe the accessible features of the content (e.g., availability of alternative text, extended descriptions and captions), and alert users to potential hazards (e.g., flashing). This information can be embedded in the page using any of RDFa, JSON and microdata. More information about these properties and their expected values is also available on the Web Schemas wiki.</p>

     <p>Here is a claim which has been enhanced with schema.org metadata:</p>

     <pre xml:space="preserve">
&lt;div typeof="WebPage" vocab="http://schema.org/">
    &lt;p property="accessibilitySummary">On 23 March 2009, all content available on
       the server at &lt;a 
         href="http://www.wondercall.example.com">http://www.wondercall.example.com&lt;/a>
       conforms to Web Content Accessibility Guidelines 2.0 at &lt;a 
         href="https://www.w3.org/TR/2008/REC-WCAG20-20081211/"
         >https://www.w3.org/TR/2008/REC-WCAG20-20081211/&lt;/a>.
       Single-A conformance.&lt;/p>
    &lt;ul>
        &lt;li>The technology that this content "&lt;a>relies upon&lt;/a>" is: 
            HTML 4.01.&lt;/li>
        &lt;li>The technologies that this content "&lt;strong>uses but does not rely 
            upon&lt;/strong>" are: CSS2, and gif.&lt;/li>
        &lt;li>This content was tested using the following user agents and assistive 
            technologies: Firefox 1.5 on Windows Vista with Screenreader X 4.0, 
            Firefox 1.5 on Windows XP SP 2 with Screenreader X 3.5, IE 6.0 on Windows 
            2000 SP4 with Screenreader Y 5.0, IE 6.0 on Windows 2000 SP4 with
            Screenreader Z 2.0, and Firefox 1.5 on Windows XP SP2 with Screenreader
            X 4.0, Safari 2.0 with OS X 10.4.&lt;/li>
    &lt;/ul>
    &lt;p>This page includes both &lt;span property="accessMode" content="textual">text&lt;/span>
       and &lt;span property="accessMode" content="visual">images&lt;/span>.
       &lt;span property="accessibilityFeature" content="alternativeText">Alternative 
       text&lt;/span> is included for all image content and &lt;span 
         property="accessibilityFeature" content="longDescription">long 
         descriptions&lt;/span> are also provided for images that require more 
       than simple alternate text. All content is available in text, which 
       can be accessed by assistive technology.&lt;/p>
&lt;/div>
     </pre>
    
  <p>Sometimes, one may want to make a claim for just the content that was added after
         a certain date. Or, one may want to claim WCAG 1.0 conformance for content up to a
         date and WCAG 2.0 for content that was created or modified after that date. There
         are no prohibitions in WCAG 2.0 to any of these practices as long as it is clear which
         pages are claiming conformance to which version of WCAG.
      </p>
      
      <div class="note">
         
         <p>When talking about technologies that are "relied upon," we're talking about Web content
            technologies (HTML, CSS, JavaScript, etc.), not user agents (browsers, assistive technologies,
            etc.).
         </p>
         
         <p>Conformance claims are not usually located on each Web page within the scope of conformance.</p>
         
      </div>
      
      <section id="partial-third">
         
         <h3>Partial conformance claims due to third party content</h3>
         
         <p>When an author makes a decision to use a third party implementation, they should choose
            products that meet WCAG requirements. If all content on a page, including third party
            content, meets all WCAG success criteria then the page conforms to WCAG. However,
            if the page does not conform to WCAG only for reasons that are legitimately outside
            the author's control then the author can make a claim of partial conformance. It is
            important to recognize that this is a statement of non-conformance and there are users
            who may not be able to access some of the content this page.
         </p>
         
         <p>One reason that content may be outside the author's control is because it is being
            provided by a third party (blogs, portals, news sites). Web pages may also include
            content via third party libraries, plugins, or widgets.
         </p>
         
         <p>Be sure to monitor any content that can change without approval from the web page
            author, as a page which once conformed may suddenly fail to conform. If it is not
            possible to monitor and repair the third party content, it is necessary to identify
            the non-conforming parts of the page for users. If the rest of the web page conforms
            to WCAG, such a page qualifies for a statement of partial conformance, third party
            content.
         </p>
         
      </section>
      
      <section>
         
         <h3>Information about any additional steps taken that go beyond the success criteria</h3>
         
         <p>One of the optional components of a conformance claim is "Information about any additional
            steps taken that go beyond the success criteria to enhance accessibility." This can
            include additional success criteria that have been met, advisory techniques that were
            implemented, information about any additional protocols used to aid access for people
            with particular disabilities or needs, etc. Any information that would be useful to
            people in understanding the accessibility of the pages may be included.
         </p>
         
      </section>
      
      <section id="meta-claims">
         
         <h3>Use of metadata to report conformance claims</h3>
         
         <p>The most useful way of attaching conformance claims to content would be to do so in
            standard machine readable form. When this practice is widespread, search tools or
            special user agents will be able to make use of this information to find and provide
            content that is more accessible or so the user agents can adjust to the content. There
            are a number of metadata based options under development for making claims, and authors
            and tool developers are encouraged to support them.
         </p>
         
         <p>In addition, metadata can be used to report conformance to individual success criteria
            once Level A conformance has been achieved.
         </p>
         
         <p>There are also programmatic reporting formats such as 
            <a href="https://www.w3.org/WAI/intro/earl.php">Evaluation and Report Language (EARL)</a> that are being developed that could provide machine readable formats for detailed
            conformance information. As the reporting formats are formalized and support for them
            develops, they will be documented here.
         </p>
         
      </section>
      
      <section id="examples">
         
         <h3>Examples of Conformance Claims</h3>
         
         <section>
            
            <h4>Examples of Required Components of Conformance Claims </h4>
            
            <div class="example">
               
               <p>On 20 September 2009, all Web pages at http://www.example.com conform to Web Content
                  Accessibility Guidelines 2.0 at https://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level
                  A conformance. 
               </p>
               
               <ul>
                  
                  <li>The documented set of accessibility-supported content technologies 
                     <strong>relied upon</strong> for this claim is a subset of ISA- AsCTset#1-2008 at http://ISA.example.gov/AsCTsets/AS2-2008.
                     
                  </li>
                  
               </ul>
               
               <p>(using a regular expression) On 12 August 2009, pages matching the pattern http://www.example.com/(marketing|sales|contact)/.*
                  conform to Web Content
                  Accessibility Guidelines 2.0 at https://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level
                  AA conformance. 
               </p>
               
               <ul>
                  
                  <li>The technologies that this content "
                     <strong>relies upon</strong>" is: XHTML 1.0 Transitional, CSS 2.0 and JavaScript 1.2. 
                  </li>
                  
               </ul>
               
               <p>(using boolean logic) On 6 January 2009, http://example.com/ AND NOT
                  (http://example.com/archive/ OR http://example.com/publications/archive/)
                  conforms to Web Content Accessibility Guidelines 2.0 at
                  https://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level AA conformance. 
               </p>
               
               <ul>
                  
                  <li>The documented set of accessibility-supported content technologies
                     
                     <strong>relied upon</strong> for this claim includes XHTML 1.0 and SMIL from ISA- AsCTset#1-2008 at
                     http://ISA.example.gov/AsCTsets/AS2-2008.
                     
                  </li>
                  
               </ul>
               
            </div>
            
         </section>
         
         <section>
            
            <h4>Examples of Conformance Claims including optional components</h4>
            
            <div class="example">
               
               <p>On 5 May 2009, the page 
                  "G7: An Introduction" http://telcor.example.com/nav/G7/intro.html conforms to Web
                  Content Accessibility Guidelines 2.0 at https://www.w3.org/TR/2008/REC-WCAG20-20081211/.
                  Level AA conformance. 
               </p>
               
               <ul>
                  
                  <li>The following additional success criteria have also been met: 1.1.2, 1.2.5, and 1.4.3.
                     
                  </li>
                  
                  <li>The documented set of accessibility-supported content technologies used for this claim
                     is AsCTset#1-2006 at http://UDLabs.org/AsCTset#1-2006.html. 
                  </li>
                  
                  <li>The technologies that this content "
                     <strong>relies upon</strong>" is: XHTML 1.0 (Strict), and Real Video. 
                  </li>
                  
                  <li>The technologies that this content "
                     <strong>uses but does not rely upon</strong>" are: JavaScript 1.2, CSS2.
                  </li>
                  
               </ul>
               
               <p>On 21 June 2009, all content beginning with the URI 
                  http://example.com/nav and http://example.com/docs conform to Web Content Accessibility
                  Guidelines 2.0 at https://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level AAA conformance.
                  
               </p>
               
               <ul>
                  
                  <li>The documented set of accessibility-supported content technologies used for this claim
                     is SMITH- AsCTset#2-2008 at http://smithreports.example.com/AsCTsets/AS2-2008. 
                  </li>
                  
                  <li>The technologies that this content "
                     <strong>relies upon</strong>" are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, JPEG, PNG. 
                  </li>
                  
                  <li> The user agents, including assistive technologies, that this content has been tested
                     with can be found at http://example.com/docs/WCAG20/test/technologies.html.
                  </li>
                  
               </ul>
               
               <p>On 23 March 2009, all content available on the server at 
                  http://www.wondercall.example.com conforms to Web Content Accessibility Guidelines
                  2.0 at https://www.w3.org/TR/2008/REC-WCAG20-20081211/. Single-A conformance. 
               </p>
               
               <ul>
                  
                  <li>The technology that this content "
                     <strong>relies upon</strong>" is: HTML 4.01. 
                  </li>
                  
                  <li>The technologies that this content "
                     <strong>uses but does not rely upon</strong>" are: CSS2, and gif. 
                  </li>
                  
                  <li>This content was tested using the following user agents and assistive technologies:
                     Firefox 1.5 on Windows Vista with Screenreader X 4.0, Firefox 1.5 on Windows XP SP
                     2 with Screenreader X 3.5, IE 6.0 on Windows 2000 SP4 with Screenreader Y 5.0, IE
                     6.0 on Windows 2000 SP4 with Screenreader Z 2.0, and Firefox 1.5 on Windows XP SP2
                     with Screenreader X 4.0, Safari 2.0 with OS X 10.4.
                  </li>
                  
               </ul>
               
            </div>
            
         </section>
         
      </section>
      
      <section id="conformance-claims-techniques">
      	<h2>Techniques for Conformance Claims</h2>
         <section id="conformance-claims-sufficient">
         	<ul>
           <li>   
               <a href="../Techniques/client-side-script/SCR38" class="script"></a>
           </li>         
           <li>   
               <a href="../Techniques/server-side-script/SVR2" class="script"></a>
           </li>         
           <li>   
               <a href="../Techniques/server-side-script/SVR3" class="script"></a>
           </li>         
           <li>   
               <a href="../Techniques/server-side-script/SVR4" class="script"></a>
           </li>         
           <li>   
               <a href="../Techniques/css/C29" class="css"></a>
           </li>         
           <li>   
               <a href="../Techniques/failures/F19" class="failure"></a>
           </li>         
           <li>   
               <a href="../Techniques/general/G136" class="general"></a>
           </li>         
           <li>   
               <a href="../Techniques/general/G190" class="general"></a>
           </li>         
           </ul>
         </section>
   
         <section id="conformance-claims-advisory">
            
         	<h3>Advisory Techniques for Conformance Claims</h3>
            
            <ul>
               
               <li>Expressing a conformance claim to WCAG 2.0 in Dublin Core elements (future link)</li>
               
            </ul>
            
         </section>
         
      </section>
      
   </section>
   
   <section id="levels">
      
      <h2>Understanding Levels of Conformance</h2>
      
      <p>First, there are a number of conditions that must be met for a success criterion to
         be included at all. These include:
      </p>
      
      <ol>
         
         <li>All success criteria must be 
            <strong>important access issues for people with disabilities</strong> that address problems beyond the usability problems that might be faced by all users.
            In other words, the access issue must cause a proportionately greater problem for
            people with disabilities than it causes people without disabilities in order to be
            considered an accessibility issue (and covered under these accessibility guidelines).
         </li>
         
         <li>All success criteria must also be testable. This is important since otherwise it would
            not be possible to determine whether a page met or failed to meet the success criteria.
            The success criteria can be tested by a combination of machine and human evaluation
            as long as it is possible to determine whether a success criterion has been satisfied
            with a high level of confidence.
         </li>
         
      </ol>
      
      <p>The success criteria were assigned to one of the three levels of conformance by the
         working group after taking into consideration a wide range of interacting issues.
         Some of the common factors evaluated when setting the level included:
      </p>
      
      <ul>
         
         <li>whether the success criterion is 
            <strong>essential</strong> (in other words, if the success criterion isn't met, then even assistive technology
            can't make content accessible)
         </li>
         
         <li>whether it is possible to satisfy the success criterion for 
            <strong>all Web sites and types of content</strong> that the success criterion would apply to (e.g., different topics, types of content,
            types of Web technology)
         </li>
         
         <li>whether the success criterion requires skills that could 
            <strong>reasonably be achieved by the content creators</strong> (that is, the knowledge and skill to meet the success criterion could be acquired
            in a week's training or less)
         </li>
         
         <li>whether the success criterion would impose limits on the "look &amp; feel" and/or function
            of the Web page. (limits on function, presentation, freedom of expression, design
            or aesthetic that the success criterion might place on authors)
         </li>
         
         <li>whether there are no workarounds if the success criterion is not met</li>
         
      </ul>
      
   </section>
   
   <section id="accessibility-support">
      
      <h2>Understanding Accessibility Support</h2>
      
      <p>Many of the success criteria deal with providing accessibility through assistive technologies
         or special accessibility features in mainstream user agents (for example, a 'show
         captions' option in a media player). That is, the success criteria require that something
         be done in the Web content that would make it possible for assistive technologies
         to successfully present the content's information to the user. For example, a picture
         that you were supposed to click on to go to a topic would not be accessible to a person
         who was blind unless text alternatives for the picture were provided in a way that
         user agents including assistive technologies can find and display them. The key here
         is that the text alternative must be included in a way that user agents including
         assistive technologies can understand and use – in a way that is "Accessibility Supported."
      </p>
      
      <p>Another example would be a custom control that is included on a Web page. In this
         case, a standard user agent would not ordinarily be able to present an alternative
         to the user. If, however, information about the control including its name, role,
         value, how to set it etc. are provided in a way that assistive technologies can understand
         and control them, then users with assistive technologies will be able to use these
         controls.
      </p>
      
      <p>When new technologies are introduced, two things must happen in order for people using
         assistive technologies to be able to access them. First, the technologies must be
         designed in a way that user agents including assistive technologies could access all
         the information they need to present the content to the user. Secondly, the user agents
         and assistive technologies may need to be redesigned or modified to be able to actually
         work with these new technologies.
      </p>
      
      <p>"<strong>Accessibility Supported</strong>" means that both of these have been done and that the technology will work with user
         agents and assistive technologies.
      </p>
      
      <section id="support-level">
         
         <h3>Level of Assistive Technology Support Needed for "Accessibility Support"</h3>
         
         <p>This topic raises the question of how many or which assistive technologies must support
            a Web technology in order for that Web technology to be considered "accessibility
            supported". The WCAG Working group and the W3C do not specify which or how many assistive
            technologies must support a Web technology in order for it to be classified as accessibility
            supported. This is a complex topic and one that varies both by environment and by
            language. There is a need for an external and international dialogue on this topic.
            Some notes to help in understanding and exploring this topic are:
         </p>
         
         <ol>
            
            <li>
               
               <p>Accessibility support of Web technologies varies by environment</p>
               
               <ul>
                  
                  <li>Web technologies may only need to be supported by those specific user agents and assistive
                     technologies deployed at a company. (These may be older versions of user agents and
                     assistive technologies or the very newest versions).
                  </li>
                  
                  <li>Content posted to the public Web may need to work with a broader range of user agents
                     and assistive technologies, including older versions.
                  </li>
                  
               </ul>
               
            </li>
            
            <li>
               
               <p>Accessibility support of Web technologies varies by language (and dialect)</p>
               
               <ul>
                  
                  <li>There are different levels of older assistive technologies support in different languages
                     and even countries. Some environments or countries may provide free assistive technologies.
                  </li>
                  
               </ul>
               
            </li>
            
            <li>
               
               <p>New technologies won't be supported in older assistive technologies</p>
               
               <ul>
                  
                  <li>Clearly, a new technology cannot be supported by all past assistive technologies,
                     so requiring that a technology be supported by all assistive technologies is not possible.
                  </li>
                  
               </ul>
               
            </li>
            
            <li>
               
               <p>Support for a single older assistive technology is usually not sufficient</p>
               
               <ul>
                  
                  <li>Support by just one assistive technology (for a given disability) would not usually
                     be enough, especially if most users who need it in order to access content do not
                     have and cannot afford that assistive technology. The exception here would be information
                     distributed to company employees only where they all have one assistive technology
                     (of that type).
                  </li>
                  
               </ul>
               
            </li>
            
            <li>
               
               <p>Currently assistive technology that is affordable by the general public is often very
                  poor
               </p>
               
               <ul>
                  
                  <li>Creating content that can't be used by the general public with disabilities should
                     be avoided. In many cases, the cost of assistive technologies is too high for users
                     who need it. Also, the capabilities of free or low cost AT is often so poor today
                     that Web content cannot be realistically restricted to this lowest (or even middle)
                     common denominator. This creates a very difficult dilemma that needs to be addressed.
                  </li>
                  
               </ul>
               
            </li>
            
         </ol>
         
         <p>The Working Group, therefore, limited itself to defining what constituted support
            and defers the judgment of how much, how many, or which AT must support a technology
            to the community and to entities closer to each situation that set requirements for
            an organization, purchase, community, etc.
         </p>
         
         <p>The Working Group encourages more discussion of this topic in the general forum of
            society since this lack of generally available yet robust assistive technologies is
            a problem that affects users, technology developers and authors negatively.
         </p>
         
      </section>
      
      <section id="accessibility-supported-definition">
         
         <h3>Technical Definition of "Accessibility Support"</h3>
         
         <p>Basically, a Web content technology is "accessibility supported" when users' assistive
            technologies will work with the Web technologies 
            <strong>AND</strong> when the accessibility features of mainstream technologies will work with the technology.
            Specifically, to qualify as an accessibility-supported technology, the following must
            be true for a technology:
         </p>
         
      	<blockquote class="scquote" data-include="../guidelines/terms/20/accessibility-supported.html">accessibility supported</blockquote>
         
      </section>
      
      <section id="documented-lists">
         
         <h3>Understanding Accessibility-Supported Web Technology Uses</h3>
         
         <p>Individual authors will not usually be able to do all of the testing necessary to
            determine which ways of using which Web technologies are actually supported by which
            versions of assistive technologies and user agents. Authors may therefore rely on
            publicly documented compilations that document which assistive technologies support
            which ways of using which Web technologies. By public, we do not mean that the compilation
            and its documentation are necessarily generated by a public agency, only that they
            are available to the public. Anyone can create publicly documented compilations of
            "Web Technology Uses and their Accessibility Support." People may create compilations
            and give them names that authors can refer to them by. As long as they are publicly
            documented, authors or customers etc. can easily select uses that meet their needs.
            Customers or others can pick technologies that fit their environment or language at
            any point in time and specify those to be used in creating their content. Authors
            are strongly encouraged to use sources that have an established reputation for accuracy
            and usefulness. Technology developers are strongly encouraged to provide information
            about the accessibility support for their technologies. The Working Group anticipates
            that only documents that provide accurate information and benefit both authors and
            users will achieve market recognition in the long term.
         </p>
         
         <p>There is no requirement in WCAG that a publicly documented compilation be used or
            that only technology uses from such a compilation be used. The publicly documented
            compilations are described only as a method to make an otherwise critical, but somewhat
            complicated, aspect of conformance easier for authors who are not themselves experts
            on assistive technology support (or who just don't have the time to keep up with advances
            in mainstream and assistive technology support for each other).
         </p>
         
         <p>Authors, companies or others may wish to create and use their own compilations of
            accessibility-supported technology uses and this is allowed in meeting WCAG. Customers,
            companies or others may, however, specify that technology uses from a custom or public
            compilation be used. See 
            <a href="documenting-accessibility-support">Documenting Accessibility Support for Uses of a Web Technology</a>.
            
         </p>
         
      </section>
      
      <section id="support-statements">
         
         <h3>Accessibility Support Statements</h3>
         
         <p>Examples of ways in which a conformance claim might document its accessibility support
            include: 
         </p>
         
         <ol>
            
            <li>This conformance claim meets the accessibility support requirement based on testing
               content in language(s) of the content with User Agents A, B, and  C,  and Assistive
               Technologies X, Y, and Z.    This means that we were able to pass all of the success
               criteria for level A of WCAG 2.0 using these products.
            </li>
            
            <li>This conformance claim meets the accessibility support requirement for the language(s)
               of the content based on the use of techniques and user agent notes documented in Techniques
               for WCAG 2.0.  It is also based on the accessibility support documentation for the
               technologies (that we relied upon for conformance), which is available in " XYZ Organization's
               Documentation of Accessibility Support."
            </li>
            
            <li>This conformance claim meets the accessibility support requirement for the language(s)
               of the content based on the use of technology Z as documented in "Technology Z accessibility
               supported techniques for WCAG 2.0."
            </li>
            
            <li>This conformance claim meets the accessibility support requirement for the language
               of the content based on the use of Accessibility Guidelines for Technology A and Accessibility
               Guidelines for Technology B. User agent and assistive technology support information
               can be found in "Product XYZ Accessibility Support Requirements", which are documented
               in these guidelines. 
            </li>
            
         </ol>
         
      </section>
      
   </section>
   
   <section id="programmatically-determined">
      
      <h2>Understanding "Programmatically Determined"</h2>
      
      <p>Several success criteria require that content (or certain aspects of content) can
         be "programmatically determined." This means that the content is authored in such
         a way that user agents, including assistive technologies, can access the information.
      </p>
      
      <p>In order for content created with Web technologies (such as HTML, CSS, PDF, GIF, MPEG, etc.) to be accessible to people with different types of disabilities, it is
         essential that the technologies used work with the accessibility features of browsers
         and other user agents, including assistive technologies. In order for something to
         meet a success criterion that requires it to be "programmatically determined," it
         would need to be implemented using a technology that has assistive technology support.
      </p>
      
      <p>Content that can be "programmatically determined" can be transformed (by user agents
         including AT) into different sensory formats (e.g., visual, auditory) or styles of
         presentation need by individual users. If existing assistive technologies cannot do
         this, then the information cannot be said to be programmatically determined.
      </p>
      
      <p>The term was created in order to allow the working group to clearly identify those
         places where information had to be accessible to assistive technologies (and other
         user agents acting as accessibility aids) without specifying exactly how this needed
         to be done. This is important because of the continually changing nature of the technologies.
         The term allows the guidelines to identify what needs to be "programmatically determined"
         in order to meet the guidelines, and then have separate documents (the How to Meet,
         Understanding, and Technique documents), which can be updated over time, list the
         specific techniques that will work and be sufficient at any point in time based on
         user agent and assistive technology support.
      </p>
      
      <section id="ASvsPD">
         
         <h3>"Accessibility Supported" vs. "Programmatically Determined"</h3>
         
         <p>"Accessibility supported" relates to support by user agents (including assistive technologies)
            of particular ways of using Web technologies. Uses of Web technologies that are accessibility
            supported will work with assistive technologies and access features in mainstream
            user agents (browsers and players etc.).
         </p>
         
         <p>"Programmatically determined" relates to the information in Web Content. If technologies
            that are accessibility supported are used properly, then assistive technologies and
            user agents can access the information in the content (i.e., programmatically determine
            the information in the content) and present it to the user.
         </p>
         
         <p>The two concepts work together to ensure that information can be presented to the
            user by user agents including assistive technologies. Authors must rely only on uses
            of technologies that are accessibility-supported — and must use them properly in order
            for the information to be programmatically determinable — and hence presentable, by
            assistive technologies and user agents to users with disabilities.
         </p>
         
      </section>
      
   </section>
   
   <section id="conforming-alt-versions">
      
      <h2>Understanding Conforming Alternate Versions</h2>
      
      <p>Conformance requirement #1 allows non-conforming pages to be included within the scope
         of conformance as long as they have a "conforming alternate version". The conforming
         alternative version is defined as:
      </p>
      
   	<blockquote class="scquote" data-include="../guidelines/terms/20/conforming-alternate-version.html">conforming alternate version</blockquote>
      
      <p>This ensures that all of the information and all of the functionality that is on the
         pages inside of the scope of conformance is available on conforming Web pages.
      </p>
     
     <p>Authors relying on conforming alternate versions must make end users aware that a conforming alternate version is available. This may be accomplished by providing a link to a more accessible version, identified clearly by link text. Alternatively a link to instructions may be provided which documents how to access a more accessible version as well as the specific ways the alternate version is more accessible (e.g. a "high contrast version").</p>
      
      <section id="whypermit">
         
         <h3>Why permit alternate versions?</h3>
         
         <p>Why does WCAG permit conforming alternate versions of Web pages to be included in
            conformance claims? That is, why include pages that do not satisfy the success criteria
            for a conformance level in the scope of conformance or a claim?
         </p>
         
         <ul>
            
            <li>Sometimes, pages use technologies that are not yet accessibility supported. When a
               new technology emerges, assistive technology support may lag behind, or may only be
               available to some target audiences. So authors may not be able to rely on the new
               technology for all users. However, there may be other benefits to using the new technology,
               e.g., better performance, a wider range of modalities available, etc. The alternate
               version requirement allows authors to include such Web pages in their Web site by
               providing an accessible alternative page in technologies that are accessibility supported.
               Users for whom the new technology is adequately supported get the benefits of the
               new version. Authors who look ahead to future accessibility support can satisfy the
               success criteria now with the alternate version page, and also work with the other
               page to build in future access when assistive technology (AT) support is available.
            </li>
            
            <li>
               
               <p>For a variety of reasons, it may not be possible to modify some content on a Web page.
                  For instance,
               </p>
               
               <ul>
                  
                  <li>It may be critical to include an exact visual copy of a document for legal or historical
                     reasons
                  </li>
                  
                  <li>The Web page may be included in a site but the site owner may not have the legal rights
                     to modify the content on the original page
                  </li>
                  
                  <li>The company may not legally be able to remove, or alter in any way, something that
                     was previously posted.
                  </li>
                  
                  <li>An author may not have permission to alter a document from another department, agency,
                     or company
                  </li>
                  
               </ul>
               
            </li>
            
            <li>Sometimes, the best experience for users with certain types of disabilities is provided
               by tailoring a Web page specifically to accommodate that disability. In such a situation,
               it may not be possible or practical to make the Web page accommodate all disabilities
               by satisfying all of the success criteria. The alternate versions requirement permits
               such specialized pages to be included within a conformance claim as long as there
               is a fully conformant 'alternate version' page.
            </li>
            
            <li>Many sites which are committed to accessibility have large quantities of legacy documents.
               While the information has been made available in accessible formats, there would be
               significant institutional resistance and procedural obstacles to removing these files
               en mass. Some organizations, especially governmental bodies, give precedence to traditional
               print-oriented processes. Even as these organizations have adapted to Internet publishing
               and embraced the need for accessible formats, they still retain a paper mindset and
               often insist on formats designed for hard copy as the "primary" version (even for
               documents that are only ever "published" electronically). Although the Working Group
               feels these approaches should be deprecated it does not feel they can be forbidden
               so long as accessible versions are readily available.
            </li>
            
         </ul>
         
         <p>A concern when permitting Web pages that do not satisfy the success criteria is that
            people with disabilities will encounter these non-conforming pages, not be able to
            access their content, and not be able to find the “conforming alternate version."
            A key part of the alternate versions provision, therefore, is the ability to find
            the conforming page (the alternate version) from the non-conforming page when it is
            encountered. The conformance requirement that permits alternate pages, therefore,
            also requires a way for users to find the accessible version among the alternate versions.
         </p>
         
         <p>Note that providing an alternate version is a fallback option for conformance to WCAG
            and the preferred method of conformance is to make all content directly accessible.
         </p>
         
      </section>
      
      <section id="techsaltver">
         
         <h3>Techniques for Providing a Conforming Alternate Version</h3>
         
         <p>The most important part of providing a conforming alternate version is providing a
            mechanism to find it from the non-conforming version. A number of different methods
            for doing this have been identified since particular techniques may not always be
            possible for specific technologies or situations. For example, if the author has control
            of the server there are some powerful techniques that will allow users to always have
            the choice up front. In many cases however the author may not have control of the
            services on their Web server. In these cases other techniques are provided. A link
            on the non-conforming page is another powerful technique but not all non-conforming
            technologies support hypertext links.
         </p>
         
         <p>Below are the techniques that have been identified to date. We expect that additional
            techniques will also be developed over time and they will be added here as they arise
            and the support for these approaches by user agents including assistive technologies
            can be demonstrated. For example a developer of a new technology that some assistive
            technologies cannot access might build in a feature that would allow those technologies
            to automatically present a link to users that could take them to an alternate version.
         </p>
         
      	<section id="techsaltver-sufficient">
            <h4>Sufficient Techniques for Providing Conforming Alternative Versions of Web pages</h4>
            
            <p>Each numbered item in this section represents a technique or combination of techniques
               that the WCAG Working Group deems sufficient for meeting this success criterion. However, it is
               not necessary to use these particular techniques. For information on using other techniques,
               see 
               <a href="understanding-techniques"></a>, particularly the "Other Techniques" section.
            </p>
            
            <ol>
               
               <li>
                  										                    
                  <a href="../Techniques/general/G136">Providing a link at the beginning of the nonconforming content that points to an alternate
                     version that does meet WCAG 2.0 Level A Success Criteria
                  </a>
                  									                  
               </li>
               
               <li>
                  										                    
                  <a href="../Techniques/general/G190">Providing a link adjacent to or associated with a non-conforming object that links
                     to a conforming alternate version
                  </a>
                  									                  
               </li>
               
               <li>
                  										                    
                  <a href="../Techniques/css/C29">C29: Using a style switcher to provide a conforming alternate version</a>
                  									                  
               </li>
               
               <li>
                  										                    
                  <a href="../Techniques/client-side-script/SCR38">SCR38: Creating a conforming alternate version for a web page designed with progressive
                     enhancement
                  </a>
                  									                  
               </li>
               
               <li>
                  										                    
                  <a href="../Techniques/server-side-script/SVR2">Using .htaccess to ensure that the only way to access non-conforming content is from
                     conforming content
                  </a>
                  									                  
               </li>
               
               <li>
                  										                    
                  <a href="../Techniques/server-side-script/SVR3">SVR3: Using HTTP referer to ensure that the only way to access non-conforming content
                     is from conforming content
                  </a>
                  									                  
               </li>
               
               <li>
                  										                    
                  <a href="../Techniques/server-side-script/SVR4">Allowing users to provide preferences for the display of conforming alternate versions</a>
                  									                  
               </li>
               
            </ol>
            
         </section>
         
      	<section id="techsaltver-failure">
            <h4>Common Failures Identified by the Working Group</h4>
            
            <ul>
               
               <li>
                  										                    
                  <a href="../Techniques/failures/F19">F19: Failure of Conformance Requirement 1 due to not providing a method for the user
                     to find the alternative conforming version of a non-conforming Web page
                  </a>
                  									                  
               </li>
               
            </ul>
            
         </section>
         
      	<section id="techsaltver-advisory">
            <h4>Additional Techniques (Advisory) for providing conforming alternative versions of
               Web pages
            </h4>
            
            <ul>
               
               <li>Providing reciprocal links between conforming and non-conforming versions (future
                  link)
               </li>
               
               <li>Excluding non-conforming content from search results (future link)</li>
               
               <li>Using content negotiation (future link)</li>
               
               <li>Not displaying content that relies on technologies that are not accessibility-supported
                  when the technology is turned off or not supported. (future link)
               </li>
               
               <li>Using metadata to allow location of a conforming alternative version from the URI
                  of a non-conforming page (future link)
               </li>
               
            </ul>
            
         </section>
         
      	<section id="techsaltver-examples">
            <h4>Examples of Conforming Alternate Versions</h4>
            
            <ul>
               
               <li>
                  
                  <p>
                     										                    
                     <strong>An intranet site with multiple versions. </strong>
                     									                  
                  </p>
                  
                  <p>A large company was concerned that the use of emerging Web technologies on an intranet
                     site might limit their ability to address the needs of diverse office locations that
                     have different technology bases and individual employees who use a wide variety of
                     user agents and assistive technologies. To address these concerns, the company created
                     an alternate version of the content that met all Level A success criteria using a
                     more limited set of uses of accessibility-supported content technologies. 
                     The two versions link to each other.
                     
                     
                  </p>
                  
               </li>
               
               <li>
                  
                  <p>
                     										                    
                     <strong>An informational site ensuring backward compatibility.</strong>
                     									                  
                  </p>
                  
                  <p>An information site covers a wide variety of subjects and wants to enable visitors
                     to quickly find the topics they are looking for. To do this, the site has implemented
                     an interactive menu system that is only supported in the most recent version of two
                     popular user agents. To ensure that visitors who do not use these specific user agents
                     are still able to effectively use the site, a navigation mechanism that does not depend
                     on the interactive menu system is presented to user agents that do not support the
                     newer technology.
                  </p>
                  
               </li>
               
            </ul>
            
         </section>
         
      </section>
      
   </section>
   
   <section id="web-page">
      
      <h2>Understanding "Web Page"</h2>
      
      <p>The definition of a Web Page is:</p>
      
   	<blockquote class="scquote" data-include="../guidelines/terms/20/web-page.html">web page</blockquote>
      
      <p>It is important to note that, in this standard, the term "Web page" includes much
         more than static HTML pages. The term 'Web Page' was used in these guidelines to allow
         the guidelines to be more understandable. But the term has grown in meaning with advancing
         technologies to encompass a wide range of technologies, many of which are not at all
         'page-like'. It also includes the increasingly dynamic Web pages that are emerging
         on the Web, including "pages" that can present entire virtual interactive communities.
         For example, the term "Web page" would include an immersive interactive movie-like
         experience that you find at a single URI.
      </p>
      
   </section>
   
   <section id="text-alternatives">
      
      <h2>Understanding "Text Alternatives"</h2>
      
      <p>A text alternative is text that is used in place of non-text content for those who
         cannot view the non-text content. Non-text content includes  such things as pictures,
         charts, applets, audio files, etc. People who cannot see for example would not be
         able to see information presented in a picture or chart. A text alternative is therefore
         provided that allows the user to be able to convert the information (the text) into
         speech. In the future, having the information in text also makes it possible to translate
         the information into sign language, into pictures, or into a simpler form of writing.
      </p>
      
      <p> In order for people with disabilities to be able to use this text - the text must
         be "programmatically determinable."  This means that the text must be able to be read
         and used by the assistive technologies (and the accessibility features in browsers)
         that people with disabilities use.
      </p>
      
      <p>It must also be possible for people using assistive technologies to find these text
         alternatives when they encounter non-text content that they cannot use. To accomplish
         this, we say that the text must be "programmatically associated" with the non-text
         content.  This means that the user must be able to use their assistive technology
         to find the alternative text (that they can use) when they land on the non-text content
         (that they can't use).
      </p>
      
   </section>
   
   
</body></html>