sidereior/wcg-standards-adherence huggingface dataset:
Web Content Accessibility Guidelines (WCAG) 2.2 Web Content Accessibility Guidelines (WCAG) 2.2 W3C Recommendation 05 October 2023 More details about this document This version: https://www.w3.org/TR/2023/REC-WCAG22-20231005/ Latest published version: https://www.w3.org/TR/WCAG22/ Latest editor's draft: https://w3c.github.io/wcag/guidelines/22/ History: https://www.w3.org/standards/history/WCAG22/ Commit history Implementation report: https://www.w3.org/WAI/WCAG22/implementation-report/ Previous Recommendation: https://www.w3.org/TR/WCAG21/ Editors: Alastair Campbell ( Nomensa ) Chuck Adams ( Oracle ) Rachael Bradley Montgomery ( Library of Congress ) Michael Cooper ( W3C ) Andrew Kirkpatrick ( Adobe ) Feedback: GitHub w3c/wcag ( pull requests , new issue , open issues ) Errata: Errata exists . See also translations . Copyright ©
    2020-2023 World Wide Web Consortium . W3C ® liability , trademark and document use rules apply. Abstract Web Content Accessibility Guidelines (WCAG) 2.2 covers a wide range of recommendations
            for making Web content more accessible.
Following these guidelines will make content
            more accessible to a wider range of people with disabilities, including accommodations
            for blindness and low vision, deafness and hearing loss, limited movement, speech
            disabilities, photosensitivity, and combinations of these, and some accommodation
            for learning disabilities and cognitive limitations; but will not address every user
            need for people with these disabilities. These guidelines address accessibility of
            web content on desktops, laptops, tablets, and mobile devices. Following these guidelines
            will also often make Web content more usable to users in general. WCAG 2.2 success criteria are written as testable statements that are not technology-specific.
            Guidance about satisfying the success criteria in specific technologies, as well as
            general information about interpreting the success criteria, is provided in separate
            documents. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction and links to WCAG technical and educational material.
WCAG 2.2 extends Web Content Accessibility Guidelines 2.1 [ WCAG21 ], which was published as a W3C Recommendation June 2018. Content that conforms
            to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1. The WG intends that for policies
            requiring conformance to WCAG 2.0 or WCAG 2.1, WCAG 2.2 can provide an alternate means
            of conformance. The publication of WCAG 2.2 does not deprecate or supersede WCAG 2.0
            or WCAG 2.1. While WCAG 2.0 and WCAG 2.1 remain W3C Recommendations, the W3C advises
            the use of WCAG 2.2 to maximize future applicability of accessibility efforts.
The W3C also encourages use of the most current version of WCAG when developing or updating
            Web accessibility policies. Status of This Document This section describes the status of this
      document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found
      in the W3C technical reports index at
      https://www.w3.org/TR/. To comment, file an issue in the W3C WCAG GitHub repository .
            Although the proposed Success Criteria in this document reference issues tracking
            discussion, the Working Group requests that public comments be filed as new issues,
            one issue per discrete comment. It is free to create a GitHub account to file issues.
            If filing issues in GitHub is not feasible, send email to public-agwg-comments@w3.org ( comment archive ).
This document was published by the Accessibility Guidelines Working Group as
    a Recommendation using the Recommendation track . W3C recommends the wide deployment of this specification as a standard for
      the Web. A W3C Recommendation is a specification that, after extensive
      consensus-building, is endorsed by W3C and its Members, and
      has commitments from Working Group members to royalty-free licensing for implementations. This document was produced by a group
        operating under the 1 August 2017 W3C Patent
          Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of
          the group; that page also includes
          instructions for disclosing a patent.
An individual who has actual
          knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy . This document is governed by the 12 June 2023 W3C Process Document . Table of Contents Abstract Status of This Document Introduction Background on WCAG 2 WCAG 2 Layers of Guidance WCAG 2.2 Supporting Documents Requirements for WCAG 2.2 Comparison with WCAG 2.1 New Features in WCAG 2.2 Numbering in WCAG 2.2 Conformance to WCAG 2.2 Later Versions of Accessibility Guidelines 1. Perceivable 1.1 Text Alternatives 1.1.1 Non-text Content 1.2 Time-based Media 1.2.1 Audio-only and Video-only (Prerecorded) 1.2.2 Captions (Prerecorded) 1.2.3 Audio Description or Media Alternative (Prerecorded) 1.2.4 Captions (Live) 1.2.5 Audio Description (Prerecorded) 1.2.6 Sign Language (Prerecorded) 1.2.7 Extended Audio Description (Prerecorded) 1.2.8 Media Alternative (Prerecorded) 1.2.9 Audio-only (Live) 1.3 Adaptable 1.3.1 Info and Relationships 1.3.2 Meaningful Sequence 1.3.3 Sensory Characteristics 1.3.4 Orientation 1.3.5 Identify Input Purpose 1.3.6 Identify Purpose 1.4 Distinguishable 1.4.1 Use of Color 1.4.2 Audio Control 1.4.3 Contrast (Minimum) 1.4.4 Resize Text 1.4.5 Images of Text 1.4.6 Contrast (Enhanced) 1.4.7 Low or No Background Audio 1.4.8 Visual Presentation 1.4.9 Images of Text (No Exception) 1.4.10 Reflow 1.4.11 Non-text Contrast 1.4.12 Text Spacing 1.4.13 Content on Hover or Focus 2. Operable 2.1 Keyboard Accessible 2.1.1 Keyboard 2.1.2 No Keyboard Trap 2.1.3 Keyboard (No Exception) 2.1.4 Character Key Shortcuts 2.2 Enough Time 2.2.1 Timing Adjustable 2.2.2 Pause, Stop, Hide 2.2.3 No Timing 2.2.4 Interruptions 2.2.5 Re-authenticating 2.2.6 Timeouts 2.3 Seizures and Physical Reactions 2.3.1 Three Flashes or Below Threshold 2.3.2 Three Flashes 2.3.3 Animation from Interactions 2.4 Navigable 2.4.1 Bypass Blocks 2.4.2 Page Titled 2.4.3 Focus Order 2.4.4 Link Purpose (In Context) 2.4.5 Multiple Ways 2.4.6 Headings and Labels 2.4.7 Focus Visible 2.4.8 Location 2.4.9 Link Purpose (Link Only) 2.4.10 Section Headings 2.4.11 Focus Not Obscured (Minimum) 2.4.12 Focus Not Obscured (Enhanced) 2.4.13 Focus Appearance 2.5 Input Modalities 2.5.1 Pointer Gestures 2.5.2 Pointer Cancellation 2.5.3 Label in Name 2.5.4 Motion Actuation 2.5.5 Target Size (Enhanced) 2.5.6 Concurrent Input Mechanisms 2.5.7 Dragging Movements 2.5.8 Target Size (Minimum) 3.
Understandable 3.1 Readable 3.1.1 Language of Page 3.1.2 Language of Parts 3.1.3 Unusual Words 3.1.4 Abbreviations 3.1.5 Reading Level 3.1.6 Pronunciation 3.2 Predictable 3.2.1 On Focus 3.2.2 On Input 3.2.3 Consistent Navigation 3.2.4 Consistent Identification 3.2.5 Change on Request 3.2.6 Consistent Help 3.3 Input Assistance 3.3.1 Error Identification 3.3.2 Labels or Instructions 3.3.3 Error Suggestion 3.3.4 Error Prevention (Legal, Financial, Data) 3.3.5 Help 3.3.6 Error Prevention (All) 3.3.7 Redundant Entry 3.3.8 Accessible Authentication (Minimum) 3.3.9 Accessible Authentication (Enhanced) 4. Robust 4.1 Compatible 4.1.1 Parsing (Obsolete and removed) 4.1.2 Name, Role, Value 4.1.3 Status Messages 5. Conformance 5.1 Interpreting Normative Requirements 5.2 Conformance Requirements 5.2.1 Conformance Level 5.2.2 Full pages 5.2.3 Complete processes 5.2.4 Only Accessibility-Supported Ways of Using Technologies 5.2.5 Non-Interference 5.3 Conformance Claims (Optional) 5.3.1 Required Components of a Conformance Claim 5.3.2 Optional Components of a Conformance Claim 5.4 Statement of Partial Conformance - Third Party Content 5.5 Statement of Partial Conformance - Language 5.6 Privacy Considerations 5.7 Security Considerations 6. Glossary 7. Input Purposes for User Interface Components A.
Change Log B. Acknowledgments B.1 Participants of the AG WG active in the development of this document: B.2 Other previously active WCAG WG participants and other contributors to WCAG 2.0, WCAG 2.1, or supporting resources B.3 Enabling funders C. References C.1 Informative references Introduction This section is non-normative. Background on WCAG 2 Web Content Accessibility Guidelines (WCAG) 2.2 defines how to make Web content more
               accessible to people with disabilities. Accessibility involves a wide range of disabilities,
               including visual, auditory, physical, speech, cognitive, language, learning, and neurological
               disabilities.
Although these guidelines cover a wide range of issues, they are not
               able to address the needs of people with all types, degrees, and combinations of disability.
               These guidelines also make Web content more usable by older individuals with changing
               abilities due to aging and often improve usability for users in general. WCAG 2.2 is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of
               providing a shared standard for Web content accessibility that meets the needs of
               individuals, organizations, and governments internationally. WCAG 2.2 builds on WCAG
               2.0 [ WCAG20 ] and WCAG 2.1 [ WCAG21 ], which in turn built on WCAG 1.0 [ WAI-WEBCONTENT ]
               and is designed to apply broadly to different Web technologies now and in the future,
               and to be testable with a combination of automated testing and human evaluation. For
               an introduction to WCAG, see the Web Content Accessibility Guidelines (WCAG) Overview . Significant challenges were encountered in defining additional criteria to address
               cognitive, language, and learning disabilities, including a short timeline for development
               as well as challenges in reaching consensus on testability, implementability, and
               international considerations of proposals.
Work will carry on in this area in future
               versions of WCAG. We encourage authors to refer to our supplemental guidance on improving inclusion for people with disabilities, including learning and cognitive
                  disabilities, people with low-vision, and more . Web accessibility depends not only on accessible content but also on accessible Web
               browsers and other user agents. Authoring tools also have an important role in Web
               accessibility. For an overview of how these components of Web development and interaction
               work together, see: Essential Components of Web Accessibility User Agent Accessibility Guidelines (UAAG) Overview Authoring Tool Accessibility Guidelines (ATAG) Overview Where this document refers to WCAG 2 it is intended to mean any and all versions of WCAG that start with 2.
WCAG 2 Layers of Guidance The individuals and organizations that use WCAG vary widely and include Web designers
               and developers, policy makers, purchasing agents, teachers, and students. In order
               to meet the varying needs of this audience, several layers of guidance are provided
               including overall principles , general guidelines , testable success criteria and a rich collection of sufficient techniques , advisory techniques , and documented common failures with examples, resource links and code. Principles - At the top are four principles that provide the foundation for Web accessibility: perceivable, operable, understandable, and robust . See also Understanding the Four Principles of Accessibility . Guidelines - Under the principles are guidelines.
The 13 guidelines provide the basic goals
                     that authors should work toward in order to make content more accessible to users
                     with different disabilities. The guidelines are not testable, but provide the framework
                     and overall objectives to help authors understand the success criteria and better
                     implement the techniques. Success Criteria - For each guideline, testable success criteria are provided to allow WCAG 2.2 to
                     be used where requirements and conformance testing are necessary such as in design
                     specification, purchasing, regulation, and contractual agreements. In order to meet
                     the needs of different groups and different situations, three levels of conformance
                     are defined: A (lowest), AA, and AAA (highest). Additional information on WCAG levels
                     can be found in Understanding Levels of Conformance .
Sufficient and Advisory Techniques - For each of the guidelines and success criteria in the WCAG 2.2 document itself, the working group has also documented a wide variety
                     of techniques . The techniques are informative and fall into two categories: those that are sufficient for meeting the success criteria and those that are advisory . The advisory techniques go beyond what is required by the individual success criteria
                     and allow authors to better address the guidelines. Some advisory techniques address
                     accessibility barriers that are not covered by the testable success criteria. Where
                     common failures are known, these are also documented.
See also Sufficient and Advisory Techniques in Understanding WCAG 2.2 . All of these layers of guidance (principles, guidelines, success criteria, and sufficient
               and advisory techniques) work together to provide guidance on how to make content
               more accessible. Authors are encouraged to view and apply all layers that they are
               able to, including the advisory techniques, in order to best address the needs of
               the widest possible range of users. Note that even content that conforms at the highest level (AAA) will not be accessible
               to individuals with all types, degrees, or combinations of disability, particularly
               in the cognitive, language, and learning areas. Authors are encouraged to consider
               the full range of techniques, including the advisory techniques, Making Content Usable for People with Cognitive and Learning Disabilities , as well as to seek relevant advice about current best practice to ensure that Web
               content is accessible, as far as possible, to this community.
Metadata may assist users in finding content most suitable for their needs. WCAG 2.2 Supporting Documents The WCAG 2.2 document is designed to meet the needs of those who need a stable, referenceable
               technical standard. Other documents, called supporting documents, are based on the
               WCAG 2.2 document and address other important purposes, including the ability to be
               updated to describe how WCAG would be applied with new technologies. Supporting documents
               include: How to Meet WCAG 2.2 - A customizable quick reference to WCAG 2.2 that includes all of the guidelines,
                     success criteria, and techniques for authors to use as they are developing and evaluating
                     Web content. This includes content from WCAG 2.0, 2.1 2.2 and can be filtered in many
                     ways to help authors focus on relevant content.
Understanding WCAG 2.2 - A guide to understanding and implementing WCAG 2.2. There is a short "Understanding"
                     document for each guideline and success criterion in WCAG 2.2 as well as key topics. Techniques for WCAG 2.2 - A collection of techniques and common failures, each in a separate document that
                     includes a description, examples, code and tests. The WCAG 2 Documents - A brief introduction to the WCAG 2 supporting documents and supplemental guidance. What's New in WCAG 2.2 introduces the new success criteria with persona quotes that illustrate the accessibility
                     issues.
See Web Content Accessibility Guidelines (WCAG) Overview for a description of the WCAG 2.2 supporting material, including education resources
               related to WCAG 2. Additional resources covering topics such as the business case
               for Web accessibility, planning implementation to improve the accessibility of Web
               sites, and accessibility policies are listed in WAI Resources . Requirements for WCAG 2.2 WCAG 2.2 meets a set of requirements for WCAG 2.2 which, in turn, inherit requirements from previous WCAG 2 versions. Requirements
               structure the overall framework of guidelines and ensure backwards compatibility.
               The Working Group also used a less formal set of acceptance criteria for success criteria,
               to help ensure success criteria are similar in style and quality to those in WCAG
               2.0. These requirements constrained what could be included in WCAG 2.2.
This constraint
               was important to preserve its nature as a dot-release of WCAG 2. Comparison with WCAG 2.1 WCAG 2.2 was initiated with the goal to continue the work of WCAG 2.1: Improving accessibility
               guidance for three major groups: users with cognitive or learning disabilities, users
               with low vision, and users with disabilities on mobile devices. Many ways to meet
               these needs were proposed and evaluated, and a set of these were refined by the Working
               Group. Structural requirements inherited from WCAG 2.0, clarity and impact of proposals,
               and timeline led to the final set of success criteria included in this version. The
               Working Group considers that WCAG 2.2 incrementally advances web content accessibility
               guidance for all these areas, but underscores that not all user needs are met by these
               guidelines.
WCAG 2.2 builds on and is backwards compatible with WCAG 2.1, meaning web pages that
               conform to WCAG 2.2 are at least as accessible as pages that conform to WCAG 2.1.
               Requirements have been added that build on 2.1 and 2.0. WCAG 2.2 has removed one success
               criterion, 4.1.1 Parsing . Authors that are required by policy to conform with WCAG 2.0 or 2.1 will be able
               to update content to WCAG 2.2, but may need to continue to test and report 4.1.1.
               Authors following more than one version of the guidelines should be aware of the following
               additions. New Features in WCAG 2.2 WCAG 2.2 extends WCAG 2.1 by adding new success criteria, definitions to support them,
                  and guidelines to organize the additions. This additive approach helps to make it
                  clear that sites which conform to WCAG 2.2 also conform to WCAG 2.1.
The Accessibility
                  Guidelines Working Group recommends that sites adopt WCAG 2.2 as their new conformance
                  target, even if formal obligations mention previous versions, to provide improved
                  accessibility and to anticipate future policy changes. The following success criteria are new in WCAG 2.2: 2.4.11 Focus Not Obscured (Minimum) (AA) 2.4.12 Focus Not Obscured (Enhanced) (AAA) 2.4.13 Focus Appearance (AAA) 2.5.7 Dragging Movements (AA) 2.5.8 Target Size (Minimum) (AA) 3.2.6 Consistent Help (A) 3.3.7 Redundant Entry (A) 3.3.8 Accessible Authentication (Minimum) (AA) 3.3.9 Accessible Authentication (Enhanced) (AAA) The new success criteria may reference new terms that have also been added to the
                  glossary and form part of the normative requirements of the success criteria. WCAG 2.2 also introduces new sections detailing aspects of the specification which
                  may impact privacy and security . Numbering in WCAG 2.2 In order to avoid confusion for implementers for whom backwards compatibility to WCAG
                  2 versions is important, new success criteria in WCAG 2.2 have been appended to the
                  end of the set of success criteria within their guideline. This avoids the need to
                  change the section number of success criteria from WCAG 2, which would be caused by
                  inserting new success criteria between existing success criteria in the guideline,
                  but it means success criteria in each guideline are no longer grouped by conformance
                  level.
The order of success criteria within each guideline does not imply information
                  about conformance level; only the conformance level indicator (A / AA / AAA) on the
                  success criterion itself indicates this. The WCAG 2.2 Quick Reference will provide a way to view success criteria grouped by conformance level, along with
                  many other filter and sort options. Conformance to WCAG 2.2 WCAG 2.2 uses the same conformance model as WCAG 2.0. It is intended that sites that
                  conform to WCAG 2.2 also conform to WCAG 2.0 and WCAG 2.1, which means they meet the
                  requirements of any policies that reference WCAG 2.0 or WCAG 2.1, while also better
                  meeting the needs of users on the current Web. Later Versions of Accessibility Guidelines In parallel with WCAG 2.2, the Accessibility Guidelines Working Group is developing
               another major version of accessibility guidelines.
The result of this work is expected
               to be a more substantial restructuring of web accessibility guidance than would be
               realistic for dot-releases of WCAG 2. The work follows a research-focused, user-centered
               design methodology to produce the most effective and flexible outcome, including the
               roles of content authoring, user agent support, and authoring tool support. This is
               a multi-year effort, so WCAG 2.2 is needed as an interim measure to provide updated
               web accessibility guidance to reflect changes on the web since the publication of
               WCAG 2.0. The Working Group might also develop additional interim versions, continuing
               with WCAG 2.2, on a similar short timeline to provide additional support while the
               major version is completed. 1.
Perceivable Information and user interface components must be presentable to users in ways they
            can perceive. Guideline 1.1 Text Alternatives Understanding Text Alternatives | How to Meet Text Alternatives Provide text alternatives for any non-text content so that it can be changed into
               other forms people need, such as large print, braille, speech, symbols or simpler
               language. Success Criterion 1.1.1 Non-text Content Understanding Non-text Content | How to Meet Non-text Content (Level A) All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. Controls, Input If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.) Time-Based Media If non-text content is time-based media, then text alternatives at least provide descriptive
            identification of the non-text content.
(Refer to Guideline 1.2 for additional requirements for media.) Test If non-text content is a test or exercise that would be invalid if presented in text , then text alternatives at least provide descriptive identification of the non-text
            content. Sensory If non-text content is primarily intended to create a specific sensory experience , then text alternatives at least provide descriptive identification of the non-text
            content. CAPTCHA If the purpose of non-text content is to confirm that content is being accessed by
            a person rather than a computer, then text alternatives that identify and describe
            the purpose of the non-text content are provided, and alternative forms of CAPTCHA
            using output modes for different types of sensory perception are provided to accommodate
            different disabilities. Decoration, Formatting, Invisible If non-text content is pure decoration , is used only for visual formatting, or is not presented to users, then it is implemented
            in a way that it can be ignored by assistive technology . Guideline 1.2 Time-based Media Understanding Time-based Media | How to Meet Time-based Media Provide alternatives for time-based media.
Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded) Understanding Audio-only and Video-only (Prerecorded) | How to Meet Audio-only and Video-only (Prerecorded) (Level A) For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such: Prerecorded Audio-only An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content. Prerecorded Video-only Either an alternative for time-based media or an audio track is provided that presents
            equivalent information for prerecorded video-only content. Success Criterion 1.2.2 Captions (Prerecorded) Understanding Captions (Prerecorded) | How to Meet Captions (Prerecorded) (Level A) Captions are provided for all prerecorded audio content in synchronized media , except when the media is a media alternative for text and is clearly labeled as such. Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded) Understanding Audio Description or Media Alternative (Prerecorded) | How to Meet Audio Description or Media Alternative (Prerecorded) (Level A) An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media , except when the media is a media alternative for text and is clearly labeled as such. Success Criterion 1.2.4 Captions (Live) Understanding Captions (Live) | How to Meet Captions (Live) (Level AA) Captions are provided for all live audio content in synchronized media .
Success Criterion 1.2.5 Audio Description (Prerecorded) Understanding Audio Description (Prerecorded) | How to Meet Audio Description (Prerecorded) (Level AA) Audio description is provided for all prerecorded video content in synchronized media . Success Criterion 1.2.6 Sign Language (Prerecorded) Understanding Sign Language (Prerecorded) | How to Meet Sign Language (Prerecorded) (Level AAA) Sign language interpretation is provided for all prerecorded audio content in synchronized media . Success Criterion 1.2.7 Extended Audio Description (Prerecorded) Understanding Extended Audio Description (Prerecorded) | How to Meet Extended Audio Description (Prerecorded) (Level AAA) Where pauses in foreground audio are insufficient to allow audio descriptions to convey the sense of the video, extended audio description is provided for all prerecorded video content in synchronized media . Success Criterion 1.2.8 Media Alternative (Prerecorded) Understanding Media Alternative (Prerecorded) | How to Meet Media Alternative (Prerecorded) (Level AAA) An alternative for time-based media is provided for all prerecorded synchronized media and for all prerecorded video-only media. Success Criterion 1.2.9 Audio-only (Live) Understanding Audio-only (Live) | How to Meet Audio-only (Live) (Level AAA) An alternative for time-based media that presents equivalent information for live audio-only content is provided.
Guideline 1.3 Adaptable Understanding Adaptable | How to Meet Adaptable Create content that can be presented in different ways (for example simpler layout)
               without losing information or structure. Success Criterion 1.3.1 Info and Relationships Understanding Info and Relationships | How to Meet Info and Relationships (Level A) Information, structure , and relationships conveyed through presentation can be programmatically determined or are available in text. Success Criterion 1.3.2 Meaningful Sequence Understanding Meaningful Sequence | How to Meet Meaningful Sequence (Level A) When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined . Success Criterion 1.3.3 Sensory Characteristics Understanding Sensory Characteristics | How to Meet Sensory Characteristics (Level A) Instructions provided for understanding and operating content do not rely solely on
      sensory characteristics of components such as shape, color, size, visual location, orientation,
      or sound. Note For requirements related to color, refer to Guideline 1.4 .
Success Criterion 1.3.4 Orientation Understanding Orientation | How to Meet Orientation (Level AA) Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential . Note Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation. Success Criterion 1.3.5 Identify Input Purpose Understanding Identify Input Purpose | How to Meet Identify Input Purpose (Level AA) The purpose of each input field collecting information about the user can be programmatically determined when: The input field serves a purpose identified in the Input Purposes for user interface components section ; and The content is implemented using technologies with support for identifying the expected meaning for form input data. Success Criterion 1.3.6 Identify Purpose Understanding Identify Purpose | How to Meet Identify Purpose (Level AAA) In content implemented using markup languages, the purpose of user interface components , icons, and regions can be programmatically determined . Guideline 1.4 Distinguishable Understanding Distinguishable | How to Meet Distinguishable Make it easier for users to see and hear content including separating foreground from
               background.
Success Criterion 1.4.1 Use of Color Understanding Use of Color | How to Meet Use of Color (Level A) Color is not used as the only visual means of conveying information, indicating an
      action, prompting a response, or distinguishing a visual element. Note This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding. Success Criterion 1.4.2 Audio Control Understanding Audio Control | How to Meet Audio Control (Level A) If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio
      volume independently from the overall system volume level. Note Since any content that does not meet this success criterion can interfere with a user's
      ability to use the whole page, all content on the Web page (whether or not it is used
      to meet other success criteria) must meet this success criterion.
See Conformance Requirement 5: Non-Interference . Success Criterion 1.4.3 Contrast (Minimum) Understanding Contrast (Minimum) | How to Meet Contrast (Minimum) (Level AA) The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: Large Text Large-scale text and images of large-scale text have a contrast ratio of at least 3:1; Incidental Text or images of text that are part of an inactive user interface component , that are pure decoration , that are not visible to anyone, or that are part of a picture that contains significant
            other visual content, have no contrast requirement. Logotypes Text that is part of a logo or brand name has no contrast requirement. Success Criterion 1.4.4 Resize Text Understanding Resize Text | How to Meet Resize Text (Level AA) Except for captions and images of text , text can be resized without assistive technology up to 200 percent without loss of content or functionality. Success Criterion 1.4.5 Images of Text Understanding Images of Text | How to Meet Images of Text (Level AA) If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: Customizable The image of text can be visually customized to the user's requirements; Essential A particular presentation of text is essential to the information being conveyed.
Note Logotypes (text that is part of a logo or brand name) are considered essential. Success Criterion 1.4.6 Contrast (Enhanced) Understanding Contrast (Enhanced) | How to Meet Contrast (Enhanced) (Level AAA) The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following: Large Text Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1; Incidental Text or images of text that are part of an inactive user interface component , that are pure decoration , that are not visible to anyone, or that are part of a picture that contains significant
            other visual content, have no contrast requirement. Logotypes Text that is part of a logo or brand name has no contrast requirement. Success Criterion 1.4.7 Low or No Background Audio Understanding Low or No Background Audio | How to Meet Low or No Background Audio (Level AAA) For prerecorded audio-only content that (1) contains primarily speech in the foreground, (2) is not an audio CAPTCHA or audio logo, and (3) is not vocalization intended to be primarily musical expression
      such as singing or rapping, at least one of the following is true: No Background The audio does not contain background sounds. Turn Off The background sounds can be turned off.
20 dB The background sounds are at least 20 decibels lower than the foreground speech content,
            with the exception of occasional sounds that last for only one or two seconds. Note Per the definition of "decibel," background sound that meets this requirement will
            be approximately four times quieter than the foreground speech content. Success Criterion 1.4.8 Visual Presentation Understanding Visual Presentation | How to Meet Visual Presentation (Level AAA) For the visual presentation of blocks of text , a mechanism is available to achieve the following: Foreground and background colors can be selected by the user. Width is no more than 80 characters or glyphs (40 if CJK). Text is not justified (aligned to both the left and the right margins).
Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing. Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window . Note 1 Content is not required to use these values. The requirement is that a mechanism is available for users to change these presentation aspects. The mechanism can be provided by the browser or other user agent.
Content is not required to provide the mechanism. Note 2 Writing systems for some languages use different presentation aspects to improve readability and legibility. If a presentation aspect in this success criterion is not used in a writing system, content in that writing system does not need to use that presentation setting and can conform without it. Authors are encouraged to follow guidance for improving readability and legibility of text in their writing system. Success Criterion 1.4.9 Images of Text (No Exception) Understanding Images of Text (No Exception) | How to Meet Images of Text (No Exception) (Level AAA) Images of text are only used for pure decoration or where a particular presentation of text is essential to the information being conveyed.
Note Logotypes (text that is part of a logo or brand name) are considered essential. Success Criterion 1.4.10 Reflow Understanding Reflow | How to Meet Reflow (Level AA) Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for: Vertical scrolling content at a width equivalent to 320 CSS pixels ; Horizontal scrolling content at a height equivalent to 256 CSS pixels . Except for parts of the content which require two-dimensional layout for usage or meaning. Note 1 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom.
Note 2 Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content. Success Criterion 1.4.11 Non-text Contrast Understanding Non-text Contrast | How to Meet Non-text Contrast (Level AA) The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s): User Interface Components Visual information required to identify user interface components and states , except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author; Graphical Objects Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed. Success Criterion 1.4.12 Text Spacing Understanding Text Spacing | How to Meet Text Spacing (Level AA) In content implemented using markup languages that support the following text style properties , no loss of content or functionality occurs by setting all of the following and by changing no other style property: Line height (line spacing) to at least 1.5 times the font size; Spacing following paragraphs to at least 2 times the font size; Letter spacing (tracking) to at least 0.12 times the font size; Word spacing to at least 0.16 times the font size. Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.
Note 1 Content is not required to use these text spacing values. The requirement is to ensure that when a user overrides the authored text spacing, content or functionality is not lost. Note 2 Writing systems for some languages use different text spacing settings, such as paragraph start indent. Authors are encouraged to follow locally available guidance for improving readability and legibility of text in their writing system. Success Criterion 1.4.13 Content on Hover or Focus Understanding Content on Hover or Focus | How to Meet Content on Hover or Focus (Level AA) Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true: Dismissible A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content; Hoverable If pointer hover can trigger the additional content, then the pointer can be moved  over the additional content without the additional content disappearing; Persistent The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.
Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author. Note 1 Examples of additional content controlled by the user agent include browser tooltips created through use of the HTML title attribute [ HTML ]. Note 2 Custom tooltips, sub-menus, and other nonmodal popups that display on hover and focus are examples of additional content covered by this criterion. Note 3 This criterion applies to content that appears in addition to the triggering component itself. Since hidden components that are made visible on keyboard focus (such as links used to skip to another part of a page) do not present additional content they are not covered by this criterion.
2. Operable User interface components and navigation must be operable. Guideline 2.1 Keyboard Accessible Understanding Keyboard Accessible | How to Meet Keyboard Accessible Make all functionality available from a keyboard. Success Criterion 2.1.1 Keyboard Understanding Keyboard | How to Meet Keyboard (Level A) All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying
      function requires input that depends on the path of the user's movement and not just
      the endpoints. Note 1 This exception relates to the underlying function, not the input technique.
For example,
      if using handwriting to enter text, the input technique (handwriting) requires path-dependent
      input but the underlying function (text input) does not. Note 2 This does not forbid and should not discourage providing mouse input or other input
      methods in addition to keyboard operation. Success Criterion 2.1.2 No Keyboard Trap Understanding No Keyboard Trap | How to Meet No Keyboard Trap (Level A) If keyboard focus can be moved to a component of the page using a keyboard interface , then focus can be moved away from that component using only a keyboard interface,
      and, if it requires more than unmodified arrow or tab keys or other standard exit
      methods, the user is advised of the method for moving focus away. Note Since any content that does not meet this success criterion can interfere with a user's
      ability to use the whole page, all content on the Web page (whether it is used to
      meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference .
Success Criterion 2.1.3 Keyboard (No Exception) Understanding Keyboard (No Exception) | How to Meet Keyboard (No Exception) (Level AAA) All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. Success Criterion 2.1.4 Character Key Shortcuts Understanding Character Key Shortcuts | How to Meet Character Key Shortcuts (Level A) If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true: Turn off A mechanism is available to turn the shortcut off; Remap A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt); Active only on focus The keyboard shortcut for a user interface component is only active when that component has focus. Guideline 2.2 Enough Time Understanding Enough Time | How to Meet Enough Time Provide users enough time to read and use content. Success Criterion 2.2.1 Timing Adjustable Understanding Timing Adjustable | How to Meet Timing Adjustable (Level A) For each time limit that is set by the content, at least one of the following is true: Turn off The user is allowed to turn off the time limit before encountering it; or Adjust The user is allowed to adjust the time limit before encountering it over a wide range
            that is at least ten times the length of the default setting; or Extend The user is warned before time expires and given at least 20 seconds to extend the
            time limit with a simple action (for example, "press the space bar"), and the user
            is allowed to extend the time limit at least ten times; or Real-time Exception The time limit is a required part of a real-time event (for example, an auction),
            and no alternative to the time limit is possible; or Essential Exception The time limit is essential and extending it would invalidate the activity; or 20 Hour Exception The time limit is longer than 20 hours. Note This success criterion helps ensure that users can complete tasks without unexpected
      changes in content or context that are a result of a time limit.
This success criterion
      should be considered in conjunction with Success Criterion 3.2.1 , which puts limits on changes of content or context as a result of user action. Success Criterion 2.2.2 Pause, Stop, Hide Understanding Pause, Stop, Hide | How to Meet Pause, Stop, Hide (Level A) For moving, blinking , scrolling, or auto-updating information, all of the following are true: Moving, blinking, scrolling For any moving, blinking or scrolling information that (1) starts automatically, (2)
            lasts more than five seconds, and (3) is presented in parallel with other content,
            there is a mechanism for the user to pause , stop, or hide it unless the movement, blinking, or scrolling is part of an activity
            where it is essential ; and Auto-updating For any auto-updating information that (1) starts automatically and (2) is presented
            in parallel with other content, there is a mechanism for the user to pause, stop,
            or hide it or to control the frequency of the update unless the auto-updating is part
            of an activity where it is essential. Note 1 For requirements related to flickering or flashing content, refer to Guideline 2.3 . Note 2 Since any content that does not meet this success criterion can interfere with a user's
      ability to use the whole page, all content on the Web page (whether it is used to
      meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference .
Note 3 Content that is updated periodically by software or that is streamed to the user agent
      is not required to preserve or present information that is generated or received between
      the initiation of the pause and resuming presentation, as this may not be technically
      possible, and in many situations could be misleading to do so. Note 4 An animation that occurs as part of a preload phase or similar situation can be considered
      essential if interaction cannot occur during that phase for all users and if not indicating
      progress could confuse users or cause them to think that content was frozen or broken. Success Criterion 2.2.3 No Timing Understanding No Timing | How to Meet No Timing (Level AAA) Timing is not an essential part of the event or activity presented by the content, except for non-interactive synchronized media and real-time events . Success Criterion 2.2.4 Interruptions Understanding Interruptions | How to Meet Interruptions (Level AAA) Interruptions can be postponed or suppressed by the user, except interruptions involving
      an emergency . Success Criterion 2.2.5 Re-authenticating Understanding Re-authenticating | How to Meet Re-authenticating (Level AAA) When an authenticated session expires, the user can continue the activity without
      loss of data after re-authenticating.
Success Criterion 2.2.6 Timeouts Understanding Timeouts | How to Meet Timeouts (Level AAA) Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions. Note Privacy regulations may require explicit user consent before user identification has been authenticated and before user data is preserved. In cases where the user is a minor, explicit consent may not be solicited in most jurisdictions, countries or regions. Consultation with privacy professionals and legal counsel is advised when considering data preservation as an approach to satisfy this success criterion. Guideline 2.3 Seizures and Physical Reactions Understanding Seizures and Physical Reactions | How to Meet Seizures and Physical Reactions Do not design content in a way that is known to cause seizures or physical reactions.