diff --git a/README.md b/README.md index 0b7004e..ea38cec 100644 --- a/README.md +++ b/README.md @@ -3,9 +3,22 @@ [ウェブアクセシビリティ基盤委員会 (WAIC) 翻訳ワーキンググループ (WG4)](http://waic.jp/committee/wg4/) が管理する、WCAG 2.x とその関連文書について、W3Cのソースファイルを保管しているレポジトリです。 +## WCAG 2.2 + +WCAG 2.2に関連する翻訳文書のレポジトリは、[waic/wcag22](https://github.com/waic/wcag22)になります。 + +### Understanding（解説書）のコミット + +[gh-pages](https://github.com/w3c/wcag/tree/gh-pages)ブランチより入手 + +- 原レポジトリの[8ce579b](https://github.com/w3c/wcag/commit/8ce579b703805fdc7523c733566d31b876a61b3c) + - Updated 14 February 2024. + +## WCAG 2.1 + WCAG 2.1に関連する翻訳文書のレポジトリは、[waic/wcag21](https://github.com/waic/wcag21)になります。 -## Understanding（解説書）のコミット +### Understanding（解説書）のコミット - 433b1cf Understanding WCAG 2.1 2019年3月6日版 (Editor's Draft) - 1a05939 Understanding WCAG 2.1 2020年12月2日版 (Official Version) @@ -14,7 +27,7 @@ WCAG 2.1に関連する翻訳文書のレポジトリは、[waic/wcag21](https:/ なお、[433b1cf](https://github.com/waic/w3c-wcag/commit/433b1cf74f0cde0592aa06b0b3215c0ba4fbe5ae)のコミットは、[w3c/wcag](https://github.com/w3c)のコミット[dfad86](https://github.com/w3c/wcag/tree/dfad867083e7137d27e472e3b85aaac8cd2c2c77/understanding)と同一のファイルです。 -## Techniques（達成方法集）のコミット +### Techniques（達成方法集）のコミット - 868b7ca Techniques for WCAG 2.1 2019年10月1日版 (Editor's Draft) diff --git a/wcag22/understanding/abbreviations.html b/wcag22/understanding/abbreviations.html new file mode 100644 index 0000000..77f8445 --- /dev/null +++ b/wcag22/understanding/abbreviations.html @@ -0,0 +1,888 @@ + + + + + + Understanding Success Criterion 3.1.4: Abbreviations | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.1.4:Abbreviations (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can identify and learn what abbreviations mean.
+ +
What to do
+
Provide the expanded form of abbreviations to users.
+ +
Why it's important
+
Some people, including those with cognitive disabilities, may not understand the shortened + form of words. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that users can access the expanded + form of abbreviations. + +

+
+
+

Benefits

+

This Success Criterion may help people who:

+
    + + +
  • have difficulty decoding words;
    • + + +
  • rely on screen magnifiers (magnification may reduce contextual cues);
    • + + +
  • have limited memory;
    • + + +
  • have difficulty using context to aid understanding.
    • + + +
+

+ Abbreviations may confuse some readers in different ways: + +

+
    + + +
  • Some abbreviations do not look like normal words and cannot be pronounced according + to the usual rules of the language. For example, the English word "room" is abbreviated + as "rm," which does not correspond to any English word or phoneme. The user has to + know that "rm" is an abbreviation for the word "room" in order to say it correctly. + +
    • + + +
  • Sometimes, the same abbreviation means different things in different contexts. For + example, in the English sentence "Dr. Johnson lives on Boswell Dr.," the first "Dr." + is an abbreviation for "Doctor" and the second instance is an abbreviation for the + word "Drive" (a word that means "street"). Users must be able to understand the context + in order to know what the abbreviations mean. + +
    • + + +
  • Some acronyms spell common words but are used in different ways. For example, "JAWS" + is an acronym for a screen reader whose full name is "Job Access with Speech." It + is also a common English word referring to the part of the mouth that holds the teeth. + The acronym is used differently than the common word. + +
    • + + +
  • Some acronyms sound like common words but are spelled differently. For example, the + acronym for Synchronized Multimedia Integration Language, S M I L, is pronounced like + the English word "smile." + +
    • + + +
+

It would also help people with visual disabilities who:

+
    + + +
  • Lose context when zoomed-in with a screen magnifier
    • + + +
+
+
+

Examples

+
+ +
An abbreviation whose expansion is provided the first time the abbreviation appears + in the content +
+ +
The name, "World Wide Web Consortium," appears as the first heading on the organization's + home page. The abbreviation, "W3C," is enclosed in parentheses in the same heading. +
+ +
A dictionary search form
+ +
A Web site includes a search form provided by an on-line acronym service. Users enter + an acronym and the form returns a list of possible expansions from the sources that + it searched. +
+ +
A medical Web site
+ +
A medical Web site provides information for both doctors and patients. The site includes + a set of cascading dictionaries; a very specialized medical dictionary is first, + followed by a second medical dictionary for the general public. The cascade also includes + a list of acronyms and abbreviations that are unique to the site, and finally there + is a standard dictionary as well. The standard dictionary at the end of the list provides + definitions for most words in the text. The specialized medical dictionary yields + definitions of unusual medical terms. Definitions for words that appear in more than + one dictionary are listed in the order of the cascade. The meaning of acronyms and + abbreviations is provided by the list of acronyms and abbreviations. +
+ +
Expanded forms of Abbreviations
+ +
The expanded form of each abbreviation is available in a programmatically determinable + manner. User agents that speak the text can use the expanded form to announce the + abbreviation. Other user agents might make the expanded form available as a tooltip + or as contextual help for the abbreviation. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+
    + + +
  • + + Acronym finder - You can search with the exact acronym, the beginning of the acronym, wildcards + and reverse lookup. + +
    • + + +
  • + + Abbreviations.com. + + +
    • + + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If the abbreviation has only one meaning within the Web page: + + +

+ + + + + +
+
+ + +

Situation B: If the abbreviation means different things within the same Web page: + + +

+ + + + + +
+
+
+
+
+ +

Key Terms

+ +
abbreviation
+
+ + + +

shortened form of a word, phrase, or name where the abbreviation has not become part + of the language + +

+ + +
+

Note

+

This includes initialisms and acronyms where:

+
+ + +
    + + +
  1. + + +

    + initialisms are shortened forms of a name or phrase made from the initial letters of words or + syllables contained in that name or phrase + +

    + + +
    +

    Note

    +

    Not defined in all languages.

    +
    + + + + + + + + +
    2. + + +
  2. + + +

    + acronyms are abbreviated forms made from the initial letters or parts of other words (in a + name or phrase) which may be pronounced as a word + +

    + + + + + +
    3. + + +
+ + +
+

Note

+

Some companies have adopted what used to be an initialism as their company name. In + these cases, the new name of the company is the letters (for example, Ecma) and the + word is no longer considered an abbreviation. + +

+
+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/about.html b/wcag22/understanding/about.html new file mode 100644 index 0000000..b0803cc --- /dev/null +++ b/wcag22/understanding/about.html @@ -0,0 +1,659 @@ + + + + + + + + + + + + + + + + About WCAG Understanding Documents | WAI | W3C + + + + + + + + + + + + + Skip to content
+ +
+
+
+ +
+
+ + + +
+ + + + + +
+ + +

About WCAG Understanding Documents

+ + + + + +
+ + +

About WCAG

+ + +

Web Content Accessibility Guidelines (WCAG) provides requirements for making websites, + applications, and other digital content accessible to people with disabilities. For + an introduction to WCAG, supporting technical documents, and educational material, + see WCAG 2 Overview + + . + +

+ + +

There are additional resources that help you understand and implement WCAG. These + Understanding documents are one type of resource. Others are explained in the WCAG 2 Documents + + . + +

+ + +
+ + +
+ + +

About the Understanding Documents

+ + +

WCAG Understanding documents are guides to understanding and implementing WCAG. + They provide detailed explanations for + each guideline and each success criterion to help readers better understand the intent + of the success criteria. They include background information and technical details. + They include techniques that are examples of ways to meet the success criteria. Each technique is linked + to more details in a techniques page. Techniques are explained in Understanding Techniques for WCAG Success Criteria. + +

+ + +

WCAG Understanding documents are not introductory resources. They are for people + who want to understand WCAG more thoroughly. The WCAG Overview provides introductory information. + +

+ + +
+ + +

Structure of the Documents

+ + +

Understanding Guideline pages include: + +

+ + +
    + + +
  • The intent
    • + + +
  • Any advisory techniques that are related + to the guideline and not specifically related to any of its success criteria + +
    • + + +
+ + +

Understanding Success Criterion pages include: + +

+ + +
    + + +
  • The success criterion wording from WCAG
    • + + +
  • Intent of the success criterion
    • + + +
  • Benefits, how it helps people with disabilities
    • + + +
  • Examples
    • + + +
  • Related resources
    • + + +
  • Techniques + + +
      + + +
    • Sufficient techniques
      • + + +
    • Advisory techniques
      • + + +
    • Failures
      • + + +
    + + +
    • + + +
  • Key terms for this success criterion, from the WCAG Glossary
    • + + +
+ + +
+ + + +
+ + +
+ + +
+ + + + + +

Change Log

+ + + + + +

A list of significantly updated Understanding documents since WCAG 2.1 was published:

+ + +
    + + +
  1. + + + : Updated Understanding Non-text contrast, based on the changes from Pull request 550. + + +
    2. + + +
+ + +

For a more detailed view of recent changes to the informative documents see the github updates. + +

+ + + +
+ + +
+ + + +
+ + +
+ + + + +

Acknowledgements

+ + + +
+ +

Participants of the AG WG active in the development of this document:

+ +
    + +
  • Jake Abma (Invited Expert)
    • + +
  • Shadi Abou-Zahra (Amazon)
    • + +
  • Chuck Adams (Oracle Corporation)
    • + +
  • Amani Ali (Nomensa)
    • + +
  • Jim Allan (Invited Expert)
    • + +
  • Jon Avila (Level Access)
    • + +
  • Bruce Bailey (U.S. Access Board)
    • + +
  • Renaldo Bernard (University of Southampton)
    • + +
  • Dan Bjorge (Deque Systems, Inc.)
    • + +
  • Peter Bossley (Thomson Reuters)
    • + +
  • Rachael Bradley Montgomery (Library of Congress)
    • + +
  • Judy Brewer (W3C)
    • + +
  • Shari Butler (Pearson plc)
    • + +
  • Thaddeus Cambron (Invited Expert)
    • + +
  • Alastair Campbell (Nomensa)
    • + +
  • Laura Carlson (Invited Expert)
    • + +
  • Sukriti Chadha (Invited Expert)
    • + +
  • Rafal Charlampowicz (AccessibilityOZ)
    • + +
  • Michael Cooper (W3C)
    • + +
  • Jennifer Delisi (Invited Expert)
    • + +
  • Wayne Dick (Knowbility, Inc)
    • + +
  • Kim Dirks (Thomson Reuters)
    • + +
  • E.A. Draffan (University of Southampton)
    • + +
  • Eric Eggert (W3C)
    • + +
  • Michael Elledge (Invited Expert)
    • + +
  • Steve Faulkner (TPGi)
    • + +
  • David Fazio (Invited Expert)
    • + +
  • Wilco Fiers (Deque Systems, Inc.)
    • + +
  • Detlev Fischer (Invited Expert)
    • + +
  • John Foliot (Invited Expert)
    • + +
  • Matt Garrish (DAISY Consortium)
    • + +
  • Alistair Garrison (Level Access)
    • + +
  • Jaunita George (Navy Federal Credit Union)
    • + +
  • Michael Gower (IBM Corporation)
    • + +
  • Markku Hakkinen (Educational Testing Service)
    • + +
  • Charles Hall (Invited Expert)
    • + +
  • Katie Haritos-Shea (Knowbility, Inc)
    • + +
  • Dan Harper-Wain (HM Government)
    • + +
  • Shawn Henry (W3C)
    • + +
  • Sarah Horton (Invited Expert)
    • + +
  • Abi James (University of Southampton)
    • + +
  • Marc Johlic (IBM Corporation)
    • + +
  • Oliver Keim (SAP SE)
    • + +
  • Andrew Kirkpatrick (Adobe)
    • + +
  • John Kirkwood (Invited Expert)
    • + +
  • JaEun Jemma Ku (University of Illinois Chicago)
    • + +
  • Patrick H. Lauke (TetraLogical)
    • + +
  • Shawn Lauriat (Google, Inc.)
    • + +
  • Steve Lee (Invited Expert)
    • + +
  • Chris Loiselle (Invited Expert)
    • + +
  • David MacDonald (Invited Expert)
    • + +
  • Jan McSorley (Pearson plc)
    • + +
  • Rain Breaw Michaels (Google LLC)
    • + +
  • Neil Milliken (Unify Software and Solutions)
    • + +
  • Mary Jo Mueller (IBM Corporation)
    • + +
  • Jay Mullen (College Board)
    • + +
  • Brooks Newton (Thomson Reuters)
    • + +
  • Gundula Niemann (SAP SE)
    • + +
  • James Nurthen (Oracle Corporation)
    • + +
  • Lori Oakley (Oracle Corporation)
    • + +
  • Joshue O Connor (Invited Expert)
    • + +
  • Scott O'Hara (Microsoft)
    • + +
  • Sailesh Panchang (Deque Systems, Inc.)
    • + +
  • Kim Patch (Invited Expert)
    • + +
  • Melanie Philipp (Deque Systems, Inc.)
    • + +
  • Mike Pluke (Invited Expert)
    • + +
  • Ian Pouncey (TetraLogical)
    • + +
  • Ruoxi Ran (W3C)
    • + +
  • Stephen Repsher (Invited Expert)
    • + +
  • John Rochford (Invited Expert)
    • + +
  • Stefan Schnabel (SAP SE)
    • + +
  • Ayelet Seeman (Invited Expert)
    • + +
  • Lisa Seeman-Kestenbaum (Invited Expert)
    • + +
  • Glenda Sims (Deque Systems, Inc.)
    • + +
  • Avneesh Singh (DAISY Consortium)
    • + +
  • David Sloan (TPGi)
    • + +
  • Andrew Somers (Invited Expert)
    • + +
  • Jeanne Spellman (TetraLogical)
    • + +
  • Francis Storr (Intel)
    • + +
  • Poornima Badhan Subramanian (Invited Expert)
    • + +
  • Ben Tillyer (Invited Expert)
    • + +
  • Makoto Ueki (Invited Expert)
    • + +
  • Gregg Vanderheiden (Raising the Floor)
    • + +
  • Kathleen Wahlbin (Invited Expert)
    • + +
  • Léonie Watson (TetraLogical)
    • + +
  • Jason White (Educational Testing Service)
    • + +
  • White, Kevin (W3C Staff)
    • + +
  • Mark Wilcock (Unify Software and Solutions)
    • + +
+ +
+ + +
+ +

Other previously active WCAG WG participants and other contributors to WCAG 2.0, WCAG + 2.1, or supporting resources +

+ +

Paul Adam, Jenae Andershonis, Wilhelm Joys Andersen, Andrew Arch, Avi Arditti, Aries + Arditi, Tom Babinszki, Mark Barratt, Mike Barta, Sandy Bartell, Kynn Bartlett, Chris + Beer, Charles Belov, Marco Bertoni, Harvey Bingham, Chris Blouch, Paul Bohman, Frederick + Boland, Denis Boudreau, Patrice Bourlon, Andy Brown, Dick Brown, Doyle Burnett, Raven + Calais, Ben Caldwell, Tomas Caspers, Roberto Castaldo, Sofia Celic-Li, Sambhavi Chandrashekar, + Mike Cherim, Jonathan Chetwynd, Wendy Chisholm, Alan Chuter, David M Clark, Joe Clark, + Darcy Clarke, James Coltham, Earl Cousins, James Craig, Tom Croucher, Pierce Crowell, + Nir Dagan, Daniel Dardailler, Geoff Deering, Sébastien Delorme, Pete DeVasto, Iyad + Abu Doush, Sylvie Duchateau, Cherie Eckholm, Roberto Ellero, Don Evans, Gavin Evans, + Neal Ewers, Steve Faulkner, Bengt Farre, Lainey Feingold, Wilco Fiers, Michel Fitos, + Alan J. Flavell, Nikolaos Floratos, Kentarou Fukuda, Miguel Garcia, P.J. Gardner, + Alistair Garrison, Greg Gay, Becky Gibson, Al Gilman, Kerstin Goldsmith, Michael Grade, + Karl Groves, Loretta Guarino Reid, Jon Gunderson, Emmanuelle Gutiérrez y Restrepo, + Brian Hardy, Eric Hansen, Benjamin Hawkes-Lewis, Sean Hayes, Shawn Henry, Hans Hillen, + Donovan Hipke, Bjoern Hoehrmann, Allen Hoffman, Chris Hofstader, Yvette Hoitink, Martijn + Houtepen, Carlos Iglesias, Richard Ishida, Jonas Jacek, Ian Jacobs, Phill Jenkins, + Barry Johnson, Duff Johnson, Jyotsna Kaki, Shilpi Kapoor, Leonard R. Kasday, Kazuhito + Kidachi, Ken Kipness, Johannes Koch, Marja-Riitta Koivunen, Maureen Kraft, Preety + Kumar, Kristjan Kure, Andrew LaHart, Gez Lemon, Chuck Letourneau, Aurélien Levy, Harry + Loots, Scott Luebking, Tim Lacy, Jim Ley, Alex Li, William Loughborough, N Maffeo, + Mark Magennis, Erich Manser, Kapsi Maria, Luca Mascaro, Matt May, Sheena McCullagh, + Liam McGee, Jens Oliver Meiert, Niqui Merret, Jonathan Metz, Alessandro Miele, Steven + Miller, Mathew J Mirabella, Matt May, Marti McCuller, Sorcha Moore, Charles F. Munat, + Robert Neff, Charles Nevile, Liddy Nevile, Dylan Nicholson, Bruno von Niman, Tim Noonan, + Sebastiano Nutarelli, Graham Oliver, Sean B. Palmer, Charu Pandhi, evarshi Pant, Nigel + Peck, Anne Pemberton, David Poehlman, Ian Pouncey, Charles Pritchard, Kerstin Probiesch, + W Reagan, Adam Victor Reed, Chris Reeve, Chris Ridpath, Lee Roberts, Mark Rogers, + Raph de Rooij, Gregory J. Rosmaita, Matthew Ross, Sharron Rush, Joel Sanda, Janina + Sajka, Roberto Scano, Gordon Schantz, Tim van Schie, Wolf Schmidt, Stefan Schnabel, + Cynthia Shelly, Glenda Sims, John Slatin, Becky Smith, Jared Smith, Andi Snow-Weaver, + Neil Soiffer, Mike Squillace, Michael Stenitzer, Diane Stottlemyer, Christophe Strobbe, + Sarah J Swierenga, Jim Thatcher, Terry Thompson, Justin Thorp, David Todd, Mary Utt, + Jean Vanderdonckt, Carlos A Velasco, Eric Velleman, Gijs Veyfeyken, Dena Wainwright, + Paul Walsch, Daman Wandke, Richard Warren, Elle Waters, Takayuki Watanabe, Gian Wild, + David Wooley, Wu Wei, Kenny Zhang, Leona Zumbo. +

+ +
+ +
+ +

Enabling funders

+ +

This publication has been funded in part with U.S. Federal funds from the Health and + Human Services, National Institute on Disability, Independent Living, and Rehabilitation + Research (NIDILRR), initially under contract number ED-OSE-10-C-0067, then under contract + number HHSP23301500054C, and now under HHS75P00120P00168. The content of this publication + does not necessarily reflect the views or policies of the U.S. Department of Health + and Human Services or the U.S. Department of Education, nor does mention of trade + names, commercial products, or organizations imply endorsement by the U.S. Government. +

+ +
+ + + +
+ + +
+ + + +
+ + + Back to Top + + + +
+ + + + + + + + \ No newline at end of file diff --git a/wcag22/understanding/accessible-authentication-enhanced.html b/wcag22/understanding/accessible-authentication-enhanced.html new file mode 100644 index 0000000..07183a3 --- /dev/null +++ b/wcag22/understanding/accessible-authentication-enhanced.html @@ -0,0 +1,645 @@ + + + + + + Understanding Success Criterion 3.3.9: Accessible Authentication (Enhanced) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.3.9:Accessible Authentication (Enhanced) (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Make logins possible with less mental effort.
+ +
What to do
+
Don't make people recognize objects or user-supplied images and media to login.
+ +
Why it's important
+
Some people with cognitive disabilities can't do puzzles, including identifying objects + and non-text information they previously supplied. +
+ +
+
+
+

Intent

+

The purpose of this Success Criterion is to ensure there is an accessible, easy-to-use, + and secure method to log in, access content, and undertake tasks. This criterion is + the same as Accessible Authentication (Minimum) but without the exceptions for objects and user-provided content. +

+

Any required step of the authentication process:

+
    + +
  • cannot display a selection of images, videos, or audio clips, where users must choose + which image they provided; +
    • + +
  • cannot display a selection of images, where users must choose the images which contain + a specific object, such as a car. +
    • + +
+
+
+

Benefits

+

The benefits of this Success Criterion are the same as Accessible Authentication (Minimum). +

+

People with cognitive issues relating to memory, reading (for example, dyslexia), + numbers (for example, dyscalculia), or perception-processing limitations will be able + to authenticate irrespective of the level of their cognitive abilities. +

+
+
+

Examples

+

The examples of this Success Criterion are very similar to the Accessible Authentication (Minimum) examples. +

+
    + +
  • A web site uses a properly marked up username (or email) and password fields as the + login authentication (meeting Success Criterion 1.3.5 Input Purpose and Success Criterion 4.1.2: Name, Role, Value). The user's browser or integrated third-party password manager extension can identify + the purpose of the inputs and automatically fill in the username and password. +
    • + +
  • A web site does not block paste functionality. The user is able to use a third-party + password manager to store credentials, copy them, and paste them directly into a login + form. +
    • + +
  • A web site uses WebAuthn so the user can authenticate with their device instead of + username/password. The user's device could use any available modality. Common methods + on laptops and phones are facial-scan, fingerprint, and PIN (Personal Identification + Number). The web site is not enforcing any particular use; it is assumed a user will + set up a method that suits them. +
    • + +
  • A web site offers the ability to login with a third-party provider using the OAuth + method. +
    • + +
  • A web site that requires two-factor authentication allows for multiple options for + the 2nd factor, including a USB-based method where the user simply presses a button + to enter a time-based token. +
    • + +
  • A web site that requires two-factor authentication displays a QR code which can be + scanned by an app on a user's device to confirm identity. +
    • + +
  • A web site that requires two-factor authentication sends a notification to a user's + device. The user must use their device's authentication mechanism (for example, user-defined + PIN, fingerprint, facial recognition) to confirm identity. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
cognitive function test
+
+ + + + + +

A task that requires the user to remember, manipulate, or transcribe information. + Examples include, but are not limited to: +

+ +
    + +
  • memorization, such as remembering a username, password, set of characters, images, + or patterns. The common identifiers name, e-mail, and phone number are not considered + cognitive function tests as they are personal to the user and consistent across Web + sites; +
    • + +
  • transcription, such as typing in characters;
    • + +
  • use of correct spelling;
    • + +
  • performance of calculations;
    • + +
  • solving of puzzles.
    • + +
+ + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/accessible-authentication-minimum.html b/wcag22/understanding/accessible-authentication-minimum.html new file mode 100644 index 0000000..61e38eb --- /dev/null +++ b/wcag22/understanding/accessible-authentication-minimum.html @@ -0,0 +1,984 @@ + + + + + + Understanding Success Criterion 3.3.8: Accessible Authentication (Minimum) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.3.8:Accessible Authentication (Minimum) (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Make logins possible with less mental effort.
+ +
What to do
+
Don't make people solve, recall, or transcribe something to log in.
+ +
Why it's important
+
Some people with cognitive disabilities cannot solve puzzles, memorize a username + and password, or retype one-time passcodes. +
+ +
+
+
+

Intent

+

The purpose of this Success Criterion is to ensure there is an accessible, easy-to-use, + and secure method for users to authenticate when logging into an existing account. + As the most prevalent form of authentication, Web sites commonly rely on usernames + and passwords to log in. However, memorizing a username and password places a very + high or impossible burden upon people with certain cognitive disabilities, as do additional + steps often added to authentication processes. For instance, the need to transcribe + a one-time verification code or requiring a puzzle to be solved. +

+

While Web sites can use the recognition of objects or of non-text content provided + by the user to meet this Success Criterion, such techniques do not fully support the + cognitive accessibility community and should be avoided if possible. Refer to Accessible Authentication (Enhanced) for guidance to be more inclusive and accessible. +

+

This Success Criterion is focused on authentication of existing users. It does not cover creation of a username or initiation of an account. For many Web sites, establishing + an initial username and credentials may not differ greatly from logging in with that + username. The techniques used to satisfy this criterion (particularly allowing pasting + into inputs and not relying on transcription) can also reduce the cognitive burden + in account creation. However, the focus of the Success Criterion is on reducing the + ongoing need for users to recall previously supplied information each time they log + in or otherwise authenticate to an account. +

+
+ +

Cognitive Function Tests

+ + +

Remembering a site-specific password is a cognitive function test. Such tests are known to be problematic for many people with cognitive disabilities. + Whether it is remembering random strings of characters, or a pattern gesture to perform + on a touch screen, cognitive function tests will exclude some people. When a cognitive + function test is used, at least one other authentication method must be available + which is not a cognitive function test. +

+ + + +

Some CAPTCHA systems have an audio alternative of the visible text. If the user needs to transcribe + this audio, it cannot be used to meet the Alternative exception. +

+ + +

If there is more than one step in the authentication process, such as with multi-factor + authentication, all steps need to comply with this Success Criterion to pass. There + needs to be a path through authentication that does not rely on cognitive function + tests. +

+ + +

Being able to recover or change the email and password is an important part of authentication. + If the user is authenticating with alternative information in order to recover their + account, there needs to be a method that is not a cognitive function test. +

+ + +

Many organizations are required to use 2-factor authentication that combines independent + sources to confirm a user's identity. These sources can consist of combining authentication + through: +

+ + +
    + +
  • knowledge (e.g., password, letters in a passphrase or memorized swipe path);
    • + +
  • possession (e.g., a verification code generated or received on a device, or scanning + of a QR code on an external device); +
    • + +
  • biometrics (e.g., fingerprint scanning, facial recognition or keystroke dynamics).
    • + +
+ + +

Most knowledge-based authentication methods rely on a cognitive function test, so + mechanisms to assist users must be available. When authentication relies on performing + an action on a separate device, it should be possible to complete the action without + the need to transcribe information. It may not be possible to know what device-based + authentication methods are available to a user; offering a choice of methods can allow + them to choose the path that most suits them. +

+ +
+
+ +

Authentication Approaches

+ +

Web sites can employ username (or email) and password inputs as an authentication + method if the author enables the user agent (browsers and third-party password managers) + to fill in the fields automatically. Generally, if the login form meets Success Criterion 1.3.5 Input Purpose, and the form controls have an appropriate accessible name in accordance with Success Criterion 4.1.2 Name, Role, Value, the user agent should be able to reliably recognize the fields and automatically + fill them in. However, if the user agent is actively blocked from filling in the fields + (for instance, by a script), then the page would not pass this criterion because it + prevents the mechanism from working. +

+ +
+
+ +

Copy and paste

+ +

Copy and paste can be relied on to avoid transcription. Users can copy their login + credentials from a local source (such as a standalone third-party password manager) + and paste it into the username and password fields on a login form, or into a web-based + command line interfaces asking for a password. Blocking people from pasting into authentication + fields, or using a different format between the copied text and the input field (for + example, "Enter the 3rd, 4th, and 6th character of your password"), would force the + user to transcribe information and therefore fail this criterion, unless another method + is available. +

+ +
+
+ +

Two-factor authentication systems (verification codes)

+ +

Beyond usernames and passwords, some sites may use two-factor authentication, asking + the user to enter a verification code (also called a passcode or one-time password). + A service that requires manual transcription of a verification code is not compliant. As with usernames and passwords, + it must be possible for a user to at least paste the code (such as from a standalone + third-party password manager, text message application, or software-based security + key), or to allow user agents to fill in the fields automatically. +

+ +

There are scenarios where a verification code must be received or generated on a secondary + device. For example, authenticating in a web browser on a laptop requires a verification + code that is sent as an SMS text message to a mobile phone. However, in most cases, + it is possible for the code to then be sent directly to the primary device, where + it can then be copied and pasted (for example, by copying the code on the secondary + device and emailing it to the primary device, or through the use of a shared cross-device + clipboard where copying content on the secondary device makes it available to paste + on the primary device). Evaluating whether or not the code can be seamlessly transferred + from the secondary device to the primary device is outside of the scope for this Success Criterion. For the purpose of evaluating Web content that relies + on authentication using these types of secondary device systems, it is assumed that + provisions are in place that make the code available in the user's clipboard. Evaluating + this criterion therefore only requires verification that the web content does allow + pasting the clipboard content in the related authentication challenge field. +

+ +

Note that two-factor systems that do not rely on codes — including hardware authentication + devices (such as YubiKey), secondary applications (either on the same primary device, + or on a secondary device) that expect the user to confirm that it is indeed them trying + to log in, and authentication methods provided by the user's operating system (such + as Windows Hello, or Touch ID/Face ID on macOS and iOS) — are not a cognitive function test. +

+ +
+
+ +

Object Recognition

+ +

If a CAPTCHA is used as part of an authentication process, there must be a method that does not + include a cognitive function test, unless it meets the exception. If the test is based + on something the website has set such as remembering or transcribing a word, or recognizing + a picture the website provided, that would be a cognitive functional test. Recognizing + objects, or a picture the user has provided is a cognitive function test; however, + it is excepted at the AA level. +

+ + +

An object in this context means the general English definition ("a material thing + that can be seen and touched") and can include vehicles and animals. If the test goes + beyond recognition (e.g. multiply the number cats by the number of dogs), that does + not meet the exception. +

+ + +

Some forms of object recognition may require an understanding of a particular culture. + For example, taxis can appear differently in different locales. This is an issue for + many people, including people with disabilities, but it is not considered an accessibility-specific + issue. +

+ + +

Some CAPTCHAs and cognitive function tests used for authentication may only appear + in certain situations, such as when ad blockers are present, or after repeated incorrect + password entry. This criterion applies when these tests are used regardless of whether + they are used every time or only triggered by specific scenarios. +

+ + +

There are a number of technologies that can be employed to prevent scripted abuse + of the authentication process. +

+ + + + + +

None of these systems are 100% effective. However, they may reduce the likelihood + of a CAPTCHA being displayed. +

+ +
+
+ +

Personal Content

+ +

Personal content is sometimes used as a second factor for authentication. For example, + as part of account creation the user would upload a picture, and when logging in they + would be asked to select that picture from several possible alternatives. Care must + be taken to provide adequate security in this case, since non-legitimate users might + be able to guess the correct personal content when presented with a choice. +

+ + +

Text-based personal content does not qualify for this exception as it relies on recall + (rather than recognition), and transcription (rather than selecting an item). Whilst + picture-based personal content will still be a barrier for some people, text based + versions tend to be a much larger barrier. +

+ +
+
+ +

Hiding characters

+ +

Another factor that can contribute to cognitive load is hiding characters when typing. + Although this criterion requires that users do not have to type in (transcribe) a + password, there are scenarios where that is necessary such as creating a password + to be saved by a password manager. Providing a feature to optionally show a password + can improve the chance of success for some people with cognitive disabilities or those + who have difficulties with accurately typing. +

+ +
+
+
+

Benefits

+

People with cognitive issues relating to memory, reading (for example, dyslexia), + numbers (for example, dyscalculia), or perception-processing limitations will be able + to authenticate irrespective of the level of their cognitive abilities. +

+
+
+

Examples

+

The examples of this Success Criterion are the same as the Accessible Authentication (Enhanced) examples. +

+
    + +
  • A web site uses a properly marked up username (or email) and password fields as the + login authentication (meeting Success Criterion 1.3.5 Input Purpose and Success Criterion 4.1.2: Name, Role, Value). The user's browser or integrated third-party password manager extension can identify + the purpose of the inputs and automatically fill in the username and password. +
    • + +
  • A web site does not block paste functionality. The user is able to use a third-party + password manager to store credentials, copy them, and paste them directly into a login + form. +
    • + +
  • A web site uses WebAuthn so the user can authenticate with their device instead of + username/password. The user's device could use any available modality. Common methods + on laptops and phones are facial-scan, fingerprint, and PIN (Personal Identification + Number). The web site is not enforcing any particular use; it is assumed a user will + set up a method that suits them. +
    • + +
  • A web site offers the ability to login with a third-party provider using the OAuth + method. +
    • + +
  • A web site that requires two-factor authentication allows for multiple options for + the 2nd factor, including a USB-based method where the user simply presses a button + to enter a time-based token. +
    • + +
  • A web site that requires two-factor authentication displays a QR code which can be + scanned by an app on a user's device to confirm identity. +
    • + +
  • A web site that requires two-factor authentication sends a notification to a user's + device. The user must use their device's authentication mechanism (for example, user-defined + PIN, fingerprint, facial recognition) to confirm identity. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
ascii art
+
+ + + +

picture created by a spatial arrangement of characters or glyphs (typically from the + 95 printable characters defined by ASCII) + +

+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
cognitive function test
+
+ + + + + +

A task that requires the user to remember, manipulate, or transcribe information. + Examples include, but are not limited to: +

+ +
    + +
  • memorization, such as remembering a username, password, set of characters, images, + or patterns. The common identifiers name, e-mail, and phone number are not considered + cognitive function tests as they are personal to the user and consistent across Web + sites; +
    • + +
  • transcription, such as typing in characters;
    • + +
  • use of correct spelling;
    • + +
  • performance of calculations;
    • + +
  • solving of puzzles.
    • + +
+ + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
non-text content
+
+ + + +

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language + +

+ + +
+

Note

+

This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), + and images representing text + +

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/adaptable.html b/wcag22/understanding/adaptable.html new file mode 100644 index 0000000..bf0916e --- /dev/null +++ b/wcag22/understanding/adaptable.html @@ -0,0 +1,223 @@ + + + + + + Understanding Guideline 1.3: Adaptable | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 1.3:Adaptable +

+ +
+
+

Intent

+

The purpose of this guideline is to ensure that all information is available in a + form that can be perceived by all users, for example, spoken aloud, or presented in + a simpler visual layout. If all of the information is available in a form that can + be determined by software, then it can be presented to users in different ways (visually, + audibly, tactilely etc.). If information is embedded in a particular presentation + in such a way that the structure and information cannot be programmatically determined + by the assistive technology, then it cannot be rendered in other formats as needed + by the user. + +

+

The Success Criteria under this guideline all seek to ensure that different types + of information that are often encoded in presentation are also available so that they + can be presented in other modalities. + +

+
    + + +
  • + the way the parts of a Web page are organized in relation to each other; + and the way + a collection of Web pages is organized + + +
    • + + +
  • + rendering of the content in a form that can be perceived by users + + +
    • + + +
+
+
+

Success Criteria for this Guideline

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/animation-from-interactions.html b/wcag22/understanding/animation-from-interactions.html new file mode 100644 index 0000000..766baa3 --- /dev/null +++ b/wcag22/understanding/animation-from-interactions.html @@ -0,0 +1,377 @@ + + + + + + Understanding Success Criterion 2.3.3: Animation from Interactions | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.3.3:Animation from Interactions (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users are not harmed or distracted by motion.
+ +
What to do
+
Support user preferences for motion, and eliminate unnecessary motion effects.
+ +
Why it's important
+
People can get sick from motion effects.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to allow users to prevent animation from being + displayed on Web pages. Some users experience distraction or nausea from animated + content. For example, if scrolling a page causes elements to move (other than the + essential movement associated with scrolling) it can trigger vestibular disorders. + Vestibular (inner ear) disorder reactions include dizziness, nausea and headaches. + Another animation that is often non-essential is parallax scrolling. Parallax scrolling + occurs when backgrounds move at a different rate to foregrounds. Animation that is + essential to the functionality or information of a web page is allowed by this Success + Criterion. +

+

"Animation from interactions" applies when a user’s interaction initiates non-essential + animation. In contrast, 2.2.2 Pause, Stop, Hide applies when the web page initiates animation. +

+
+

Note

+

The impact of animation on people with vestibular disorders can be quite severe. Triggered + reactions include nausea, migraine headaches, and potentially needing bed rest to + recover. +

+
+

How can a website reduce the chances of triggering a vestibular disorder? Choose any one of the following solutions. Avoid using unnecessary animation. Provide + a control for users to turn off non-essential animations from user interaction. Take + advantage of the reduce motion feature in the user agent or operating system. +

+

What about movement caused by a user scrolling a page? Moving new content into the viewport is essential for scrolling. The user controls + the essential scrolling movement so it is allowed. Only add non-essential animation + to the scrolling interaction in a responsible way. Always give users the ability to + turn off unnecessary movement. +

+
+
+

Benefits

+
    + +
  • Vestibular Disorder + +
      + +
    • People with vestibular disorders need control over movement triggered by interactions. + Non-essential movement can trigger vestibular disorder reactions. Vestibular (inner + ear) disorder reactions include distraction, dizziness, headaches and nausea. +
      • + +
    • Persona Quote: "Stop that extra movement! You are making me so dizzy I cannot concentrate. + Now I have to turn off my computer and go lie down." +
      • + +
    + +
    • + +
+
+
+

Examples

+
    + +
  • Parallax scrolling with option to turn off unnecessary motion globally: + +
      + +
    • A site includes extra animations when the user scrolls. Decorative elements move in + and out of view horizontally when the essential page content is scrolled vertically. + A control at the top of each page allows the user to turn off unnecessary animations. + The ability to turn off non-essential animations is a site-wide setting. +
      • + +
    + +
    • + +
  • Transitions that support the reduce motion preference: + +
      + +
    • A site includes a non-essential transition when loading new content. The transition + is a page-flipping animation that respects the reduce-motion CSS media query. When + the user enables the reduce motion preference, the page-flipping animation is turned + off. +
      • + +
    + +
    • + +
  • Essential animation: + +
      + +
    • A web application provides a feature to author animated sequences. As part of this + tool the author needs to preview the animation. +
      • + +
    + +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+
+
+ +

Key Terms

+ +
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
motion animation
+
+ + + +

addition of steps between conditions to create the illusion of movement or to give + a sense of a smooth transition +

+ + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/audio-control.html b/wcag22/understanding/audio-control.html new file mode 100644 index 0000000..70a6679 --- /dev/null +++ b/wcag22/understanding/audio-control.html @@ -0,0 +1,605 @@ + + + + + + Understanding Success Criterion 1.4.2: Audio Control | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.2:Audio Control (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
A page that plays music or sounds doesn't disrupt people.
+ +
What to do
+
If you play audio content automatically, let people turn it down or off.
+ +
Why it's important
+
Sound distracts some people, and also interferes with screen readers.
+ +
+
+
+

Intent

+

Individuals who use screen reading software can find it hard to hear the speech output + if there is other audio playing at the same time. This difficulty is exacerbated when + the screen reader's speech output is software based (as most are today) and is controlled + via the same volume control as the sound. Therefore, it is important that the user + be able to turn off the background sound. + +

+

Having control of the volume includes + being able to reduce its volume to zero. Muting the system volume is not "pausing + or stopping" the autoplay audio. Both the "pause or stop" and control of audio volume + need to be independent of the overall system volume. + +

+
+

Note

+
+ + +

Playing audio automatically when landing on a page may affect a screen reader user's + ability to find the mechanism to stop it because they navigate by listening and automatically + started sounds might interfere with that navigation. Therefore, we discourage the + practice of automatically starting sounds (especially if they last more than 3 seconds), + and encourage that the sound be + started by an action initiated by the user after they reach the page, rather than requiring + that the sound be + stopped by an action of the user after they land on the page. + +

+ + +
+
+

See also + 1.4.7: Low or No Background Audio. + +

+
+
+

Benefits

+
    + + +
  • Individuals who use screen reading technologies can hear the screen reader without + other sounds playing. This is especially important for those who are hard of hearing + and for those whose screen readers use the system volume (so they cannot turn sound + down and screen reader up). + +
    • + + +
  • This Success Criterion also benefits people who have difficulty focusing on visual + content (including text) when audio is playing. + +
    • + + +
+
+
+

Examples

+
    + +
  • An audio file begins playing automatically when a page is opened. However, the audio + can be stopped by the user by selecting a "silent" link at the top of the page. + +
    • + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/audio-description-or-media-alternative-prerecorded.html b/wcag22/understanding/audio-description-or-media-alternative-prerecorded.html new file mode 100644 index 0000000..ba663a2 --- /dev/null +++ b/wcag22/understanding/audio-description-or-media-alternative-prerecorded.html @@ -0,0 +1,790 @@ + + + + + + Understanding Success Criterion 1.2.3: Audio Description or Media Alternative (Prerecorded) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.2.3:Audio Description or Media Alternative (Prerecorded) (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Prerecorded videos can be understood by more people.
+ +
What to do
+
Provide a description of the visual content in videos.
+ +
Why it's important
+
People who are blind or who cannot understand the visual content can have it described.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to provide people who are blind or visually + impaired access to the visual information in a synchronized media presentation. This + Success Criterion describes two approaches, either of which can be used. + +

+

One approach is to provide audio description of the video content. The audio description + augments the audio portion of the presentation with the information needed when the + video portion is not available. During existing pauses in dialogue, audio description + provides information about actions, characters, scene changes, and on-screen text + that are important and are not described or spoken in the main sound track. + +

+

The second approach involves providing all of the information in the synchronized + media (both visual and auditory) in text form. An alternative for time-based media + provides a running description of all that is going on in the synchronized media content. + The alternative for time-based media reads something like a screenplay or book. Unlike + audio description, the description of the video portion is not constrained to just + the pauses in the existing dialogue. Full descriptions are provided of all visual + information, including visual context, actions and expressions of actors, and any + other visual material. In addition, non-speech sounds (laughter, off-screen voices, + etc.) are described, and transcripts of all dialogue are included. The sequence of + description and dialogue transcripts are the same as the sequence in the synchronized + media itself. As a result, the alternative for time-based media can provide a much + more complete representation of the synchronized media content than audio description + alone. + +

+

If there is any interaction as part of the synchronized media presentation (e.g., + "press now to answer the question") then the alternative for time-based media would + provide hyperlinks or whatever is needed to provide the same functionality. + +

+
+

Note

+
+ + +

+ For 1.2.3, 1.2.5, and 1.2.7, if all of the information in the video track is already + provided in the audio track, no audio description is necessary. + + + +

+ + +

+ 1.2.3, 1.2.5, and 1.2.8 overlap somewhat with each other. This is to give the author + some choice at the minimum conformance level, and to provide additional requirements + at higher levels. At Level A in Success Criterion 1.2.3, authors do have the choice + of providing either an audio description or a full text alternative. If they wish + to conform at Level AA, under Success Criterion 1.2.5 authors must provide an audio + description - a requirement already met if they chose that alternative for 1.2.3, + otherwise an additional requirement. At Level AAA under Success Criterion 1.2.8 they + must provide an extended text description. This is an additional requirement if both + 1.2.3 and 1.2.5 were met by providing an audio description only. If 1.2.3 was met, + however, by providing a text description, and the 1.2.5 requirement for an audio description + was met, then 1.2.8 does not add new requirements. + +

+ + +
+
+

See also + 1.2.5 Audio Description (Prerecorded), + 1.2.7 Extended Audio Description (Prerecorded) and + 1.2.8 Media Alternative (Prerecorded). + +

+
+
+

Benefits

+
    + + +
  • This Success Criterion may help some people who have difficulty watching video or + other synchronized media content, including people who have difficulty perceiving + or understanding moving images. + +
    • + + +
+
+
+

Examples

+
+ +
A movie with audio description
+ +
+ +

+ Describer: A title, "Teaching Evolution Case Studies. Bonnie Chen." A teacher shows photographs + of birds with long, thin beaks. + +

+ + +

+ Bonnie Chen: "These photos were all taken at the Everglades." + +

+ + +

+ Describer: The teacher hands each student two flat, thin wooden sticks. + +

+ + +

+ Bonnie Chen: "Today you will pretend to be a species of wading bird that has a beak like this." + +

+ + +

+ Describer: The teacher holds two of the sticks to her mouth making the shape of a beak. + +

+ + +

Transcript of audio based on the first few minutes of "Teaching Evolution Case Studies, Bonnie Chen" (copyright WGBH and Clear Blue Sky Productions, Inc.) +

+ +
+ +
An alternative for time-based media for a training video
+ +
A company purchases a Training video for use by its employees and puts it on the companies + intranet. The video involves explaining use of a new technology and has a person talking + and showing things at the same time. Since there is no place to insert audio description + of the visual demonstrations during gaps in dialogue, the company provides an alternative + for time-based media that all employees, including those who cannot see the demonstrations, + can use to better understand what is being presented. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+
+
+ +

Key Terms

+ +
alternative for time-based media
+
+ + + +

document including correctly sequenced text descriptions of time-based visual and + auditory information and providing a means for achieving the outcomes of any time-based + interaction + +

+ + +
+

Note

+

A screenplay used to create the synchronized media content would meet this definition + only if it was corrected to accurately represent the final synchronized media after + editing. + +

+
+ + + +
+
audio
+
+ + + +

the technology of sound reproduction

+ + +
+

Note

+

Audio can be created synthetically (including speech synthesis), recorded from real + world sounds, or both. + +

+
+ + + +
+
audio description
+
+ + + +

narration added to the soundtrack to describe important visual details that cannot + be understood from the main soundtrack alone + +

+ + +
+

Note

+

Audio description of video provides information about actions, characters, scene changes, on-screen text, and + other visual content. + +

+
+ + +
+

Note

+

In standard audio description, narration is added during existing pauses in dialogue. + (See also extended audio description.) + +

+
+ + +
+

Note

+

Where all of the video information is already provided in existing audio, no additional audio description is necessary. + +

+
+ + +
+

Note

+

Also called "video description" and "descriptive narration."

+
+ + + +
+
extended audio description
+
+ + + +

audio description that is added to an audiovisual presentation by pausing the video so that there is time to add additional description + +

+ + +
+

Note

+

This technique is only used when the sense of the video would be lost without the additional audio description and the pauses between dialogue/narration are too short. + +

+
+ + + +
+
live
+
+ + + +

information captured from a real-world event and transmitted to the receiver with + no more than a broadcast delay + +

+ + +
+

Note

+

A broadcast delay is a short (usually automated) delay, for example used in order + to give the broadcaster time to cue or censor the audio (or video) feed, but not sufficient + to allow significant editing. + +

+
+ + +
+

Note

+

If information is completely computer generated, it is not live.

+
+ + + +
+
media alternative for text
+
+ + + +

media that presents no more information than is already presented in text (directly + or via text alternatives) + +

+ + +
+

Note

+

A media alternative for text is provided for those who benefit from alternate representations + of text. Media alternatives for text may be audio-only, video-only (including sign-language + video), or audio-video. + +

+
+ + + +
+
prerecorded
+
+ + + +

information that is not live + +

+ + + +
+
synchronized media
+
+ + + +

+ audio or video synchronized with another format for presenting information and/or with time-based + interactive components, unless the media is a media alternative for text that is clearly labeled as such + +

+ + + +
+
video
+
+ + + +

the technology of moving or sequenced pictures or images

+ + +
+

Note

+

Video can be made up of animated or photographic images, or both.

+
+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/audio-description-prerecorded.html b/wcag22/understanding/audio-description-prerecorded.html new file mode 100644 index 0000000..5d69ade --- /dev/null +++ b/wcag22/understanding/audio-description-prerecorded.html @@ -0,0 +1,681 @@ + + + + + + Understanding Success Criterion 1.2.5: Audio Description (Prerecorded) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.2.5:Audio Description (Prerecorded) (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Videos can be played with audio descriptions.
+ +
What to do
+
Provide a synchronized spoken description of the visual content in videos.
+ +
Why it's important
+
People who cannot see or understand the visual content can hear about it while playing + videos. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to provide people who are blind or visually + impaired access to the visual information in a synchronized media presentation. The + audio description augments the audio portion of the presentation with the information + needed when the video portion is not available. During existing pauses in dialogue, + audio description provides information about actions, characters, scene changes, and + on-screen text that are important and are not described or spoken in the main sound + track. + +

+
+

Note

+
+ + +

+ For 1.2.3, 1.2.5, and 1.2.7, if all of the information in the video track is already + provided in the audio track, no audio description is necessary. + + + +

+ + +

+ 1.2.3, 1.2.5, and 1.2.8 overlap somewhat with each other. This is to give the author + some choice at the minimum conformance level, and to provide additional requirements + at higher levels. At Level A in Success Criterion 1.2.3, authors do have the choice + of providing either an audio description or a full text alternative. If they wish + to conform at Level AA, under Success Criterion 1.2.5 authors must provide an audio + description - a requirement already met if they chose that alternative for 1.2.3, + otherwise an additional requirement. At Level AAA under Success Criterion 1.2.8 they + must provide an extended text description. This is an additional requirement if both + 1.2.3 and 1.2.5 were met by providing an audio description only. If 1.2.3 was met, + however, by providing a text description, and the 1.2.5 requirement for an audio description + was met, then 1.2.8 does not add new requirements. + +

+ + +
+
+
+
+

Benefits

+
    + + +
  • People who are blind or have low vision as well as those with cognitive limitations + who have difficulty interpreting visually what is happening benefit from audio description + of visual information. + +
    • + + +
+
+
+

Examples

+
+ +
A movie with audio description
+ +
+ +

+ Describer: A title, "Teaching Evolution Case Studies. Bonnie Chen." A teacher shows photographs + of birds with long, thin beaks. + +

+ + +

+ + Bonnie Chen: "These photos were all taken at the Everglades." + +

+ + +

+ + Describer: The teacher hands each student two flat, thin wooden sticks. + +

+ + +

+ + Bonnie Chen: "Today you will pretend to be a species of wading bird that has a beak like this." + +

+ + +

+ + Describer: The teacher holds two of the sticks to her mouth making the shape of a beak. + +

+ + +

Transcript of audio based on the first few minutes of "Teaching Evolution Case Studies, Bonnie Chen" (copyright WGBH and Clear Blue Sky Productions, Inc.) +

+ +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+
+
+ +

Key Terms

+ +
audio
+
+ + + +

the technology of sound reproduction

+ + +
+

Note

+

Audio can be created synthetically (including speech synthesis), recorded from real + world sounds, or both. + +

+
+ + + +
+
audio description
+
+ + + +

narration added to the soundtrack to describe important visual details that cannot + be understood from the main soundtrack alone + +

+ + +
+

Note

+

Audio description of video provides information about actions, characters, scene changes, on-screen text, and + other visual content. + +

+
+ + +
+

Note

+

In standard audio description, narration is added during existing pauses in dialogue. + (See also extended audio description.) + +

+
+ + +
+

Note

+

Where all of the video information is already provided in existing audio, no additional audio description is necessary. + +

+
+ + +
+

Note

+

Also called "video description" and "descriptive narration."

+
+ + + +
+
extended audio description
+
+ + + +

audio description that is added to an audiovisual presentation by pausing the video so that there is time to add additional description + +

+ + +
+

Note

+

This technique is only used when the sense of the video would be lost without the additional audio description and the pauses between dialogue/narration are too short. + +

+
+ + + +
+
live
+
+ + + +

information captured from a real-world event and transmitted to the receiver with + no more than a broadcast delay + +

+ + +
+

Note

+

A broadcast delay is a short (usually automated) delay, for example used in order + to give the broadcaster time to cue or censor the audio (or video) feed, but not sufficient + to allow significant editing. + +

+
+ + +
+

Note

+

If information is completely computer generated, it is not live.

+
+ + + +
+
media alternative for text
+
+ + + +

media that presents no more information than is already presented in text (directly + or via text alternatives) + +

+ + +
+

Note

+

A media alternative for text is provided for those who benefit from alternate representations + of text. Media alternatives for text may be audio-only, video-only (including sign-language + video), or audio-video. + +

+
+ + + +
+
prerecorded
+
+ + + +

information that is not live + +

+ + + +
+
synchronized media
+
+ + + +

+ audio or video synchronized with another format for presenting information and/or with time-based + interactive components, unless the media is a media alternative for text that is clearly labeled as such + +

+ + + +
+
video
+
+ + + +

the technology of moving or sequenced pictures or images

+ + +
+

Note

+

Video can be made up of animated or photographic images, or both.

+
+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/audio-only-and-video-only-prerecorded.html b/wcag22/understanding/audio-only-and-video-only-prerecorded.html new file mode 100644 index 0000000..e9b0368 --- /dev/null +++ b/wcag22/understanding/audio-only-and-video-only-prerecorded.html @@ -0,0 +1,653 @@ + + + + + + Understanding Success Criterion 1.2.1: Audio-only and Video-only (Prerecorded) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.2.1:Audio-only and Video-only (Prerecorded) (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Audio and video-only content can be understood by more people.
+ +
What to do
+
Provide an alternative when content is perceivable with only one sense.
+ +
Why it's important
+
People who can’t fully see or hear content can understand it.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to make information conveyed by prerecorded + audio-only and prerecorded video-only content available to all users. Alternatives + for time-based media that are text based make information accessible because text + can be rendered through any sensory modality (for example, visual, auditory or tactile) + to match the needs of the user. In the future, text could also be translated into + symbols, sign language or simpler forms of the language (future). + +

+

An example of pre-recorded video with no audio information or user interaction is + a silent movie. The purpose of the transcript is to provide an equivalent to what + is presented visually. For prerecorded video content, authors have the option to provide + an audio track. The purpose of the audio alternative is to be an equivalent to the + video. This makes it possible for users with and without vision impairment to review + content simultaneously. The approach can also make it easier for those with cognitive, + language and learning disabilities to understand the content because it would provide + parallel presentation. + +

+
+

Note

+
+ + +

A text equivalent is not required for audio that is provided as an equivalent for + video with no audio information. For example, it is not required to caption video + description that is provided as an alternative to a silent movie. + +

+ + +
+
+

See also + 1.2.4: Audio-only (Live) + + +

+
+
+

Benefits

+
    + + +
  • This Success Criterion helps people who have difficulty perceiving visual content. + Assistive technology can read text alternatives aloud, present them visually, or convert + them to braille. + +
    • + + +
  • Alternatives for timed-based media that are text based may help some people who have + difficulty understanding the meaning of prerecorded video content. + +
    • + + +
  • People who are deaf, are hard of hearing, or who are having trouble understanding + audio information for any reason can read the text presentation. Research is ongoing + regarding automatic translation of text into sign language. + +
    • + + +
  • People who are deaf-blind can read the text in braille.
    • + + +
  • Additionally, text supports the ability to search for non-text content and to repurpose + content in a variety of ways. + +
    • + + +
+
+
+

Examples

+
+ +
An audio recording of a speech
+ +
The link to an audio clip says, "Chairman's speech to the assembly." A link to a text + transcript is provided immediately after the link to the audio clip. +
+ +
An audio recording of a press conference
+ +
A Web page includes a link to an audio recording of a press conference that identifies + the audio recording. The page also links to a text transcript of the press conference. + The transcript includes a verbatim record of everything the speakers say. It identifies + who is speaking as well as noting other significant sounds that are part of the recording, + such as applause, laughter, questions from the audience, and so on. +
+ +
An animation that illustrates how a car engine works
+ +
An animation shows how a car engine works. There is no audio and the animation is + part of a tutorial that describes how an engine works. Since the text of the tutorial + already provides a full explanation, the media is an alternative for text and the + text alternative includes only a brief description of the animation and refers to + the tutorial text for more information. +
+ +
A video-only file with an audio track
+ +
A silent movie includes an audio track which includes a description of the action + in the video. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If the content is prerecorded audio-only:

+ + + + + +
+
+ + +

Situation B: If the content is prerecorded video-only:

+ + + + + +
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
alternative for time-based media
+
+ + + +

document including correctly sequenced text descriptions of time-based visual and + auditory information and providing a means for achieving the outcomes of any time-based + interaction + +

+ + +
+

Note

+

A screenplay used to create the synchronized media content would meet this definition + only if it was corrected to accurately represent the final synchronized media after + editing. + +

+
+ + + +
+
audio
+
+ + + +

the technology of sound reproduction

+ + +
+

Note

+

Audio can be created synthetically (including speech synthesis), recorded from real + world sounds, or both. + +

+
+ + + +
+
audio-only
+
+ + + +

a time-based presentation that contains only audio (no video and no interaction) + +

+ + + +
+
live
+
+ + + +

information captured from a real-world event and transmitted to the receiver with + no more than a broadcast delay + +

+ + +
+

Note

+

A broadcast delay is a short (usually automated) delay, for example used in order + to give the broadcaster time to cue or censor the audio (or video) feed, but not sufficient + to allow significant editing. + +

+
+ + +
+

Note

+

If information is completely computer generated, it is not live.

+
+ + + +
+
media alternative for text
+
+ + + +

media that presents no more information than is already presented in text (directly + or via text alternatives) + +

+ + +
+

Note

+

A media alternative for text is provided for those who benefit from alternate representations + of text. Media alternatives for text may be audio-only, video-only (including sign-language + video), or audio-video. + +

+
+ + + +
+
prerecorded
+
+ + + +

information that is not live + +

+ + + +
+
video
+
+ + + +

the technology of moving or sequenced pictures or images

+ + +
+

Note

+

Video can be made up of animated or photographic images, or both.

+
+ + + +
+
video-only
+
+ + + +

a time-based presentation that contains only video (no audio and no interaction) + +

+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/audio-only-live.html b/wcag22/understanding/audio-only-live.html new file mode 100644 index 0000000..734c07a --- /dev/null +++ b/wcag22/understanding/audio-only-live.html @@ -0,0 +1,440 @@ + + + + + + Understanding Success Criterion 1.2.9: Audio-only (Live) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.2.9:Audio-only (Live) (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Live audio can be understood by more people.
+ +
What to do
+
Provide a text equivalent for live audio-only content.
+ +
Why it's important
+
People who cannot hear or understand real-time audio can read an equivalent.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to make information conveyed by live audio, + such as web-based audio conferencing, live speeches and radio Webcasts, accessible + through the + use of a text alternative. A live text caption service will enable live audio to be + accessible to people who are deaf or hard of hearing, or who cannot otherwise hear + the audio. Such services use a trained human operator who listens in to what is being + said and uses a special keyboard to enter the text with only a small delay. They are + able to capture a live event with a high degree of fidelity, and also to insert notes + on any non spoken audio which is essential to understanding the event. A transcript + is sometimes a possibility if the live audio is following a set script; but a live + caption service is preferred because it plays out at the same pace as the audio itself, + and can adapt to any deviations from the script that might occur. + +

+

Using untrained operators, or providing a transcript which differs markedly from what + actually happens would not be considered meeting this Success Criterion. + +

+

This success criterion was intended to apply to broadcast of audio and is not intended + to require that two-way audio calls between two or more individuals through web apps + must be captioned regardless of the needs of users. Responsibility for providing captions + would fall to the content providers (the callers) or the “host” caller, and not the + application. + +

+
+
+

Examples

+
    + + +
  • A public relations firm uses Web based caption services to cover live events; the + output from the service is incorporated in a sub frame of the Web page which includes + the streaming audio control. + +
    • + + +
  • A live radio play of a fringe theatre group is being broadcast to the Web. As the + actors stick largely to a set script, and the budget for the program is small, the + producers provide a link (with the playwright's permission) to the script of the play. + +
    • + + +
  • A streaming audio server uses a technology which can also accommodate text and graphics, + such as HTML. A stenographer is used to create live captions at an + event, and these are mixed on the fly to produce live captions in the media stream + which can be viewed by the media player. + +
    • + + +
  • A CEO is to give a press release by telephone to the media in response to a breaking + news story, the audio is being recorded and streamed over the internet, but due to + time constraints a Web captioning service cannot be set up in time. As the press release + is a set statement which the CEO will be reading out, the company simultaneously provides + the transcript of the release. + +
    • + + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+
+
+ +

Key Terms

+ +
alternative for time-based media
+
+ + + +

document including correctly sequenced text descriptions of time-based visual and + auditory information and providing a means for achieving the outcomes of any time-based + interaction + +

+ + +
+

Note

+

A screenplay used to create the synchronized media content would meet this definition + only if it was corrected to accurately represent the final synchronized media after + editing. + +

+
+ + + +
+
audio
+
+ + + +

the technology of sound reproduction

+ + +
+

Note

+

Audio can be created synthetically (including speech synthesis), recorded from real + world sounds, or both. + +

+
+ + + +
+
audio-only
+
+ + + +

a time-based presentation that contains only audio (no video and no interaction) + +

+ + + +
+
live
+
+ + + +

information captured from a real-world event and transmitted to the receiver with + no more than a broadcast delay + +

+ + +
+

Note

+

A broadcast delay is a short (usually automated) delay, for example used in order + to give the broadcaster time to cue or censor the audio (or video) feed, but not sufficient + to allow significant editing. + +

+
+ + +
+

Note

+

If information is completely computer generated, it is not live.

+
+ + + +
+
video
+
+ + + +

the technology of moving or sequenced pictures or images

+ + +
+

Note

+

Video can be made up of animated or photographic images, or both.

+
+ + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/base.css b/wcag22/understanding/base.css new file mode 100644 index 0000000..b028c7b --- /dev/null +++ b/wcag22/understanding/base.css @@ -0,0 +1,17 @@ +.wcag21, .wcag22 { + background-color: #E9FBE9; + border-left: solid .5em #52E052; +} +span.wcag21, span.wcag22 { + margin-left: .25em; + padding-left: .25em; +} +div.wcag21, div.wcag22 { + margin: 1em auto; + padding: .5em; + page-break-inside: avoid; +} +.new-version { + font-size: smaller; + font-weight: bold; +} \ No newline at end of file diff --git a/wcag22/understanding/bypass-blocks.html b/wcag22/understanding/bypass-blocks.html new file mode 100644 index 0000000..59ba4f7 --- /dev/null +++ b/wcag22/understanding/bypass-blocks.html @@ -0,0 +1,820 @@ + + + + + + Understanding Success Criterion 2.4.1: Bypass Blocks | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.1:Bypass Blocks (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can more easily navigate by keyboard.
+ +
What to do
+
Provide a means of skipping repeating content.
+ +
Why it's important
+
Users reliant on the keyboard interface can move around pages efficiently.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to allow people who navigate sequentially + through content more direct access to the primary content of the Web page. Web pages + and applications often have content that appears on other pages or screens. Examples + of repeated blocks of content include but are not limited to navigation links, header + content, and advertising frames. Small repeated sections such as individual words, + phrases or single links are not considered blocks for the purposes of this provision. + +

+

Users who navigate sequentially through content will generally have to navigate through + repeated content on each page. This is in contrast to a sighted user's ability to + ignore + the repeated material either by focusing on the center of the screen (where main content + usually appears) or a mouse user's ability to select a link with a single mouse click + rather than encountering every link or form control that comes before the item they + want. + +

+

It is not the intent of this Success Criterion to require authors to provide methods + that are redundant to functionality provided by the user agent. Most web browsers + provide keyboard shortcuts to move the user focus to the top of the page, so if a + set of navigation links is provided at the bottom of a web page providing a "skip" + link may be unnecessary. + +

+
+

Note

+
+ + +

Although this Success Criterion deals with blocks of content that are repeated on + multiple pages, we also strongly promote structural markup on individual pages as + per Success Criteria 1.3.1. + + +

+ + +
+
+

Although the success criterion does not specifically use the term “within a set of + web pages”, the concept of the pages belonging to a set is implied. An author would + not be expected to avoid any possible duplication of content in any two pages that + are not in some way related to each other, and are not "Web pages that share a common + purpose and that are created by the same author, group or organization” (the definition + of set of web pages). + +

+
+

Note

+
+ + +

Even for web pages that are not in a set, if a web page has blocks of text that are + repeated within the page it may be helpful (but not required) to provide a means to + skip over them. + +

+ + +
+
+
+
+

Benefits

+

When this Success Criterion is not satisfied, it may be difficult for people with + some disabilities to reach the main content of a Web page quickly and easily: +

+
    + + + +
  • Screen reader users who visit several pages on the same site can avoid having to hear + all header content and dozens of navigation links on every page before the main + content is spoken. + +
    • + + +
  • People who use only the keyboard or a keyboard interface can reach content with fewer + keystrokes. Otherwise, they might have to make dozens of keystrokes before reaching + a link in the main content area. This can take a long time and may cause severe physical + pain for some users. + + +
    • + + +
  • People who use screen magnifiers do not have to search through the same header content + or + other blocks of information to find where the main content begins each time they enter + a new page. + +
    • + + +
  • People with cognitive limitations as well as people who use screen readers may benefit + when links are grouped into lists + +
    • + + +
+
+
+

Examples

+
    + + +
  • A news organization's home page contains a main story in the middle of the page, surrounded + by many blocks and sidebars for advertising, searching, and other services. There + is a link at the top of the page that jumps to the main story. Without using this + link, a keyboard user needs to tab through approximately 40 links to reach the main + story; the screen reader user has to listen to 200 words; and the screen magnifier + user must search around for the location of the main body. + +
    • + +
  • An e-commerce website includes a long list of filters prior to the search results + listing. + A link above the list enables users to skip the filters and get to the product results + quickly. +
    • + + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/captions-live.html b/wcag22/understanding/captions-live.html new file mode 100644 index 0000000..7dd25e6 --- /dev/null +++ b/wcag22/understanding/captions-live.html @@ -0,0 +1,881 @@ + + + + + + Understanding Success Criterion 1.2.4: Captions (Live) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.2.4:Captions (Live) (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Live videos have captions.
+ +
What to do
+
Provide synchronized text for audio content in real-time videos.
+ +
Why it's important
+
People who are deaf or hard of hearing can understand audio in real-time video content.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to enable people who are deaf or hard of hearing + to watch + real-time presentations. Captions provide the part of the content available via the audio track. + Captions not only include dialogue, but also identify who is speaking and notate sound + effects and other significant audio. + +

+

This success criterion was intended to apply to broadcast of synchronized media and + is not intended to require that two-way multimedia calls between two or more individuals + through web apps must be captioned regardless of the needs of users. Responsibility + for providing captions would fall to the content providers (the callers) or the “host” + caller, and not the application. + +

+
+
+

Benefits

+
    + + +
  • People who are deaf or have a hearing loss can access the auditory information in + the synchronized media content through captions. + +
    • + + +
+
+
+

Examples

+
+ +
A Web cast
+ +
A news organization provides a live, captioned Web cast.
+ +
A music Web cast
+ +
An orchestra provides Communication Access Realtime Translation (CART) captioning + of each real-time Web performance. The CART service captures lyrics and dialog as + well as identifies non-vocal music by title, movement, composer, and any information + that will help the user comprehend the nature of the audio. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+

Note

+
+ + +

Captions may be generated using real-time text translation service. + + + +

+ + +
+
+
+
+
+
+ +

Key Terms

+ +
ascii art
+
+ + + +

picture created by a spatial arrangement of characters or glyphs (typically from the + 95 printable characters defined by ASCII) + +

+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
audio
+
+ + + +

the technology of sound reproduction

+ + +
+

Note

+

Audio can be created synthetically (including speech synthesis), recorded from real + world sounds, or both. + +

+
+ + + +
+
audio description
+
+ + + +

narration added to the soundtrack to describe important visual details that cannot + be understood from the main soundtrack alone + +

+ + +
+

Note

+

Audio description of video provides information about actions, characters, scene changes, on-screen text, and + other visual content. + +

+
+ + +
+

Note

+

In standard audio description, narration is added during existing pauses in dialogue. + (See also extended audio description.) + +

+
+ + +
+

Note

+

Where all of the video information is already provided in existing audio, no additional audio description is necessary. + +

+
+ + +
+

Note

+

Also called "video description" and "descriptive narration."

+
+ + + +
+
captions
+
+ + + +

synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content + +

+ + +
+

Note

+

Captions are similar to dialogue-only subtitles except captions convey not only the + content of spoken dialogue, but also equivalents for non-dialogue audio information + needed to understand the program content, including sound effects, music, laughter, + speaker identification and location. + +

+
+ + +
+

Note

+

Closed Captions are equivalents that can be turned on and off with some players.

+
+ + +
+

Note

+

Open Captions are any captions that cannot be turned off. For example, if the captions + are visual equivalent images of text embedded in video. + +

+
+ + +
+

Note

+

Captions should not obscure or obstruct relevant information in the video.

+
+ + +
+

Note

+

In some countries, captions are called subtitles.

+
+ + +
+

Note

+

+ Audio descriptions can be, but do not need to be, captioned since they are descriptions of information + that is already presented visually. + +

+
+ + + +
+
extended audio description
+
+ + + +

audio description that is added to an audiovisual presentation by pausing the video so that there is time to add additional description + +

+ + +
+

Note

+

This technique is only used when the sense of the video would be lost without the additional audio description and the pauses between dialogue/narration are too short. + +

+
+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
image of text
+
+ + + +

text that has been rendered in a non-text form (e.g., an image) in order to achieve + a particular visual effect + +

+ + +
+

Note

+

This does not include text that is part of a picture that contains significant other visual content. + +

+
+ + + + + + +
+
live
+
+ + + +

information captured from a real-world event and transmitted to the receiver with + no more than a broadcast delay + +

+ + +
+

Note

+

A broadcast delay is a short (usually automated) delay, for example used in order + to give the broadcaster time to cue or censor the audio (or video) feed, but not sufficient + to allow significant editing. + +

+
+ + +
+

Note

+

If information is completely computer generated, it is not live.

+
+ + + +
+
media alternative for text
+
+ + + +

media that presents no more information than is already presented in text (directly + or via text alternatives) + +

+ + +
+

Note

+

A media alternative for text is provided for those who benefit from alternate representations + of text. Media alternatives for text may be audio-only, video-only (including sign-language + video), or audio-video. + +

+
+ + + +
+
non-text content
+
+ + + +

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language + +

+ + +
+

Note

+

This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), + and images representing text + +

+
+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
synchronized media
+
+ + + +

+ audio or video synchronized with another format for presenting information and/or with time-based + interactive components, unless the media is a media alternative for text that is clearly labeled as such + +

+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
text alternative
+
+ + + +

+ Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. + Programmatically associated text is text whose location can be programmatically determined + from the non-text content. + +

+ + + + + +
+

Note

+

Refer to Understanding Text Alternatives for more information. + +

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
video
+
+ + + +

the technology of moving or sequenced pictures or images

+ + +
+

Note

+

Video can be made up of animated or photographic images, or both.

+
+ + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/captions-prerecorded.html b/wcag22/understanding/captions-prerecorded.html new file mode 100644 index 0000000..5c02af5 --- /dev/null +++ b/wcag22/understanding/captions-prerecorded.html @@ -0,0 +1,1037 @@ + + + + + + Understanding Success Criterion 1.2.2: Captions (Prerecorded) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.2.2:Captions (Prerecorded) (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Videos can be played with captions.
+ +
What to do
+
Provide synchronized text for audio content in existing videos.
+ +
Why it's important
+
People who are deaf or hard of hearing can understand audio in videos.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to enable people who are deaf or hard of hearing + to watch synchronized media presentations. Captions provide the part of the content + available via the audio track. Captions not only include dialogue, but identify who + is speaking and include non-speech information conveyed through sound, including meaningful + sound effects. + +

+

It is acknowledged that at the present time there may be difficulty in creating captions + for time-sensitive material and this may result in the author being faced with the + choice of delaying the information until captions are available, or publishing time-sensitive + content that is inaccessible to the deaf, at least for the interval until captions + are available. Over time, the tools for captioning as well as building the captioning + into the delivery process can shorten or eliminate such delays. + + +

+

Captions are not needed when the synchronized media is, itself, an alternate presentation + of information that is also presented via text on the Web page. For example, if information + on a page is accompanied by a synchronized media presentation that presents no more + information than is already presented in text, but is easier for people with cognitive, + language, or learning disabilities to understand, then it would not need to be captioned + since the information is already presented on the page in text or in text alternatives + (e.g., for images). + + +

+

See also + 1.2.4: Captions (Live). + +

+
+
+

Benefits

+
    + + +
  • People who are deaf or have a hearing loss can access the auditory information in + the synchronized media content through captions. + +
    • + + +
+
+
+

Examples

+
    + +
  • + +

    A captioned tutorial

    + +

    A video clip shows how to tie a knot. The captions read,

    + +

    "(music)

    + +

    Using rope to tie knots was an important skill

    + +

    for the likes of sailors, soldiers and woodsmen.."

    + +

    From Sample Transcript Formatting by Whit Anderson.

    + +
    • + +
  • A complex legal document contains synchronized media clips for different paragraphs + that show a person speaking the contents of the paragraph. Each clip is associated + with its corresponding paragraph. No captions are provided for the synchronized media. +
    • + +
  • An instruction manual containing a description of a part and its necessary orientation + is accompanied by a synchronized media clip showing the part in its correct orientation. + No captions are provided for the synchronized media clip. +
    • + +
  • + +

    An orchestra provides captions for videos of performances. In addition to capturing + dialog and lyrics verbatim, captions identify non-vocal music by title, movement, + composer, and any information that will help the user comprehend the nature of the + audio. For instance captions read, +

    + +

    "[Orchestral Suite No. 3.2 in D major, BWV 1068, Air]

    + +

    [Johann Sebastian Bach, Composer]

    + +

    ♪ Calm melody with a slow tempo ♪"

    + +
    +

    Note

    +
    + +

    Style guides for captions may differ among different languages.

    + +
    +
    + +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+
+ + +

Guides to Captioning

+ + + + + +
+
+ + +

SMIL Resources

+ + + + + +
+
+ + +

Other Captioning Resources

+ + + + + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
ascii art
+
+ + + +

picture created by a spatial arrangement of characters or glyphs (typically from the + 95 printable characters defined by ASCII) + +

+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
audio
+
+ + + +

the technology of sound reproduction

+ + +
+

Note

+

Audio can be created synthetically (including speech synthesis), recorded from real + world sounds, or both. + +

+
+ + + +
+
audio description
+
+ + + +

narration added to the soundtrack to describe important visual details that cannot + be understood from the main soundtrack alone + +

+ + +
+

Note

+

Audio description of video provides information about actions, characters, scene changes, on-screen text, and + other visual content. + +

+
+ + +
+

Note

+

In standard audio description, narration is added during existing pauses in dialogue. + (See also extended audio description.) + +

+
+ + +
+

Note

+

Where all of the video information is already provided in existing audio, no additional audio description is necessary. + +

+
+ + +
+

Note

+

Also called "video description" and "descriptive narration."

+
+ + + +
+
captions
+
+ + + +

synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content + +

+ + +
+

Note

+

Captions are similar to dialogue-only subtitles except captions convey not only the + content of spoken dialogue, but also equivalents for non-dialogue audio information + needed to understand the program content, including sound effects, music, laughter, + speaker identification and location. + +

+
+ + +
+

Note

+

Closed Captions are equivalents that can be turned on and off with some players.

+
+ + +
+

Note

+

Open Captions are any captions that cannot be turned off. For example, if the captions + are visual equivalent images of text embedded in video. + +

+
+ + +
+

Note

+

Captions should not obscure or obstruct relevant information in the video.

+
+ + +
+

Note

+

In some countries, captions are called subtitles.

+
+ + +
+

Note

+

+ Audio descriptions can be, but do not need to be, captioned since they are descriptions of information + that is already presented visually. + +

+
+ + + +
+
extended audio description
+
+ + + +

audio description that is added to an audiovisual presentation by pausing the video so that there is time to add additional description + +

+ + +
+

Note

+

This technique is only used when the sense of the video would be lost without the additional audio description and the pauses between dialogue/narration are too short. + +

+
+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
image of text
+
+ + + +

text that has been rendered in a non-text form (e.g., an image) in order to achieve + a particular visual effect + +

+ + +
+

Note

+

This does not include text that is part of a picture that contains significant other visual content. + +

+
+ + + + + + +
+
live
+
+ + + +

information captured from a real-world event and transmitted to the receiver with + no more than a broadcast delay + +

+ + +
+

Note

+

A broadcast delay is a short (usually automated) delay, for example used in order + to give the broadcaster time to cue or censor the audio (or video) feed, but not sufficient + to allow significant editing. + +

+
+ + +
+

Note

+

If information is completely computer generated, it is not live.

+
+ + + +
+
media alternative for text
+
+ + + +

media that presents no more information than is already presented in text (directly + or via text alternatives) + +

+ + +
+

Note

+

A media alternative for text is provided for those who benefit from alternate representations + of text. Media alternatives for text may be audio-only, video-only (including sign-language + video), or audio-video. + +

+
+ + + +
+
non-text content
+
+ + + +

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language + +

+ + +
+

Note

+

This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), + and images representing text + +

+
+ + + +
+
prerecorded
+
+ + + +

information that is not live + +

+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
synchronized media
+
+ + + +

+ audio or video synchronized with another format for presenting information and/or with time-based + interactive components, unless the media is a media alternative for text that is clearly labeled as such + +

+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
text alternative
+
+ + + +

+ Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. + Programmatically associated text is text whose location can be programmatically determined + from the non-text content. + +

+ + + + + +
+

Note

+

Refer to Understanding Text Alternatives for more information. + +

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
video
+
+ + + +

the technology of moving or sequenced pictures or images

+ + +
+

Note

+

Video can be made up of animated or photographic images, or both.

+
+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/change-on-request.html b/wcag22/understanding/change-on-request.html new file mode 100644 index 0000000..3a0bbe1 --- /dev/null +++ b/wcag22/understanding/change-on-request.html @@ -0,0 +1,1048 @@ + + + + + + Understanding Success Criterion 3.2.5: Change on Request | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.2.5:Change on Request (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users have full control of major content changes.
+ +
What to do
+
Provide ways for users to trigger or turn off changes of context.
+ +
Why it's important
+
Content that behaves predictably is especially important to people with disabilities.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to encourage design of Web content that gives + users full control of changes of context. + This Success Criterion aims to eliminate potential confusion that may be caused by + unexpected changes of context such as automatic launching of new windows, automatic + submission of forms after selecting an item from a list, etcetera. + Such unexpected changes of context may cause difficulties for people with motor impairments, + people with low vision, people who are blind, and people with certain cognitive limitations. + + +

+

Some types of change of context are not disruptive to some users, or actively benefit + some users. For example, single-switch users rely on context changes that are animated + by the system, and the preferences of low-vision users may vary depending on how much + of the content they can see at once and how much of the session structure they can + retain in working memory. Some types of content, such as slide shows, require the + ability to change context in order to provide the intended user experience. Content + that initiates changes of context automatically only when user preferences allow can + conform to this Success Criterion. + + +

+
+

Note

+
+ + +

It is possible for more than one change of context to occur simultaneously. For example, + clicking on a link which automatically opens a new window is an example of two separate + changes of context related to the change in content and to the change in the viewport + (window). The change in the content in this case is initiated by user request when + they click on the link, but unless the user can be aware that the link will open in + a new window then that change of context cannot be regarded as user-initiated. + +

+ + +
+
+
+
+

Benefits

+
    + + +
  • + + +

    Individuals who are unable to detect changes of context or may not realize that the + context has changed are less likely to become disoriented while navigating a site. + For example: + +

    + + +
      + + +
    • individuals who are blind or have low vision may have difficulty knowing when a visual + context change has occurred, such as a new window popping up. In this case, warning + users of context changes in advance minimizes confusion when the user discovers that + the back button no longer behaves as expected. + + +
      • + + +
    + + +
    • + + +
  • Some individuals with low vision, with reading and intellectual disabilities, and + who have difficulty interpreting visual cues may benefit from additional cues in order + to detect changes of context. + +
    • + + +
  • People with certain + cognitive limitations do not get confused if automatic redirects are performed by the Web server instead + of the browser. + +
    • + + +
+
+
+

Examples

+
+ +
an "update now" button
+ +
Instead of automatically updating the content, the author provides an "Update now" + button that requests a refresh of the content. +
+ +
An automatic redirection
+ +
A user is automatically redirected from an old page to a new page in such a way that + he or she never realizes the redirect has occurred. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If the Web page allows automatic updates:

+ + + + + +
+
+ + +

Situation B: If automatic redirects are possible:

+ + + + + +
+
+ + +

Situation C: If the Web page uses pop-up windows:

+ + + + + +
+
+ + +

Situation D: If using an onchange event on a select element:

+ + + + + +
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
changes of context
+
+ + + +

major changes that, if made without user awareness, can disorient users who are not + able to view + the entire page simultaneously + +

+ + +

Changes in context include changes of:

+ + +
    + + +
  1. + user agent; + +
    2. + + +
  2. + viewport; + +
    3. + + +
  3. focus;
    4. + + +
  4. + content that changes the meaning of the Web page + +
    5. + + +
+ + +
+

Note

+

A change of content is not always a change of context. Changes in content, such as + an expanding outline, dynamic menu, or a tab control do not necessarily change the + context, unless they also change one of the above (e.g., focus). + +

+
+ + + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
viewport
+
+ + + +

object in which the user agent presents content

+ + +
+

Note

+

The user agent presents content through one or more viewports. Viewports include windows, frames, + loudspeakers, and virtual magnifying glasses. A viewport may contain another viewport + (e.g., nested frames). Interface components created by the user agent such as prompts, + menus, and alerts are not viewports. + +

+
+ + +
+

Note

+

This definition is based on User Agent Accessibility Guidelines 1.0 Glossary [[UAAG10]]. + +

+
+ + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/character-key-shortcuts.html b/wcag22/understanding/character-key-shortcuts.html new file mode 100644 index 0000000..5cd6d83 --- /dev/null +++ b/wcag22/understanding/character-key-shortcuts.html @@ -0,0 +1,697 @@ + + + + + + Understanding Success Criterion 2.1.4: Character Key Shortcuts | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.1.4:Character Key Shortcuts (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Reduce accidental activation of keyboard shortcuts.
+ +
What to do
+
Ensure character-only shortcut keys can be turned off or modified.
+ +
Why it's important
+
Character-key shortcuts are easy to accidentally trigger, especially with speech input.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to reduce accidental activation of keyboard + shortcuts. Character key shortcuts work well for many keyboard users, but are inappropriate + and frustrating for speech input users — whose means of input is strings of letters + — and for keyboard users who are prone to accidentally hit keys. + To rectify this issue, authors need to allow users to turn off or reconfigure shortcuts + that are made up of only character keys. + +

+

Note that this success criterion doesn't affect components such as listboxes and drop-down + menus. Although these components contain values (words) that may be selected by one + or more character keys, the shortcuts are only active when the components have focus. + Other components such as menus may be accessed or opened with a single non-character + shortcut (e.g., Alt or Alt+F) before pressing a single character key to select an + item. This makes the full path to invoking a menu a two-step shortcut that includes + a non-printable key. Accesskeys are also not affected because they include modifier keys. +

+

Speech Input users generally work in a single mode where they can use a mix of dictation + and speech commands. This works well because the user knows to pause before and after + commands, and commands are usually at least two words long. So, for instance, a user + might say a bit of dictation, such as "the small boat", then pause, and say a command + to delete that dictation, such as "Delete Line". In contrast, if the user were to + say the two phrases together without a pause, the whole phrase would come out as dictation + (i.e., "the small boat delete line"). Although speech input programs often include + modes that listen only for dictation or only for commands, most speech users use the + all-encompassing mode all the time because it is a much more efficient workflow. It + could decrease command efficiency significantly if users were to change to command + mode and back before and after issuing each command. +

+

Speech users can also speak most keyboard commands (e.g., "press Control Foxtrot") + without any problems. If the website or app is keyboard enabled, the speech user can + also write a native speech macro that calls the keyboard command, such as "This Print" + to carry out Ctrl+P. +

+

Single-key shortcuts are the exception. While using single letter keys as controls + might be appropriate and efficient for many keyboard users, single-key shortcuts are + disastrous for speech users. The reason for this is that when only a single key is + used to trip a command, a spoken word can become a barrage of single-key commands + if the cursor focus happens to be in the wrong place. +

+

For example, a speech-input user named Kim has her cursor focus in the main window + of a web mail application that uses common keyboard shortcuts to navigate ("k"), archive + ("y") and mute messages ("m"). A coworker named Mike enters her office and says "Hey + Kim" and her microphone picks that up. The Y of "hey" archives the current message. + K in "Kim" moves down one conversation and M mutes a message or thread. And, if Kim + looks up and says "Hey Mike" without remembering to turn off the microphone, the same + three things happen in a different sequence. +

+

A user interacting with a webpage or web app that doesn't use single-character shortcuts + doesn't have this problem. Inadvertent strings of characters from the speech application + are not interpreted as shortcuts if a modifier key is required. A speech user filling + in a text input form may find that a phrase that is accidentally picked up by the + speech microphone results in stray text being entered into the field, but that is + easily seen and undone. The Resources section of this page contains links to videos + demonstrating these types of issues. +

+
+
+

Benefits

+
    + +
  • Speech users will be able to turn off single-key shortcuts so they can avoid accidentally + firing batches of them at once. This will allow speech users to make full use of programs + that offer single-key shortcuts to keyboard users. +
    • + +
  • Keyboard-only users who have dexterity challenges can also be prone to accidentally + hitting keys. Those users would be able to avoid problematic single character shortcuts + by turning them off or modifying them to include at least one non-character key. +
    • + +
  • Allowing all shortcut keys to be remapped can help users with some cognitive disabilities, since + the same shortcuts can be assigned to perform the same actions across different applications. +
    • + +
+
+
+

Examples

+
+ + +

Disable Shortcuts

+ +

A mechanism is provided to allow users to disable character-key shortcuts. The character + key shortcuts are not the only way to carry out these commands. A speech user disables + the shortcuts and can prevent words that are picked up by the microphone from triggering + single-key shortcuts. +

+ +
+
+ + +

Alternate Control

+ + +

A keyboard-only user is in a long issues thread. While reading the thread she accidentally + hits the S key, which moves focus to the search bar at the top of the document. This + causes her to lose her place and her train of thought. However, a mechanism is provided + to allow users to change character-key shortcuts. She changes the shortcut to include + another key so she can avoid future interruptions. +

+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+

Web apps that use character-key shortcuts and allow users to disable and/or change + these shortcuts: +

+
    + +
  • Gmail
    • + +
  • WordPress
    • + +
+

Videos of speech user trouble with single character key shortcuts:

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
keyboard shortcut
+
+ + + +

alternative means of triggering an action by the pressing of one or more keys

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/compatible.html b/wcag22/understanding/compatible.html new file mode 100644 index 0000000..1feb4b0 --- /dev/null +++ b/wcag22/understanding/compatible.html @@ -0,0 +1,193 @@ + + + + + + Understanding Guideline 4.1: Compatible | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 4.1:Compatible +

+ +
+
+

Intent

+

The purpose of this guideline is to support compatibility with current and future + user agents, + especially assistive technologies (AT). This is done both by 1) ensuring that authors do not + do things that would break AT (e.g., poorly formed markup) or circumvent AT (e.g., + by using unconventional markup or code) and 2) exposing information in the content + in standard ways that assistive technologies can recognize and interact with. Since + technologies change quickly, and AT developers have much trouble keeping up with rapidly + changing technologies, it is important that content follow conventions and be compatible + with APIs so that AT can more easily work with new technologies as they evolve. + +

+
+
+

Success Criteria for this Guideline

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/concurrent-input-mechanisms.html b/wcag22/understanding/concurrent-input-mechanisms.html new file mode 100644 index 0000000..2b8772a --- /dev/null +++ b/wcag22/understanding/concurrent-input-mechanisms.html @@ -0,0 +1,340 @@ + + + + + + Understanding Success Criterion 2.5.6: Concurrent Input Mechanisms | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.5.6:Concurrent Input Mechanisms (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can choose different ways of inputting content.
+ +
What to do
+
Do not prevent users from switching their mode of input.
+ +
Why it's important
+
People may not be able to work using just one input method.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that people can use and switch between + different modes of input when interacting with web content. Users may employ a variety + of input mechanisms when interacting with web content. These may be a combination + of mechanisms such as a keyboard or keyboard-like interfaces and pointer devices like + a mouse, stylus or touchscreen. +

+

Even though a device may have a primary input mechanism, the user may choose to employ + alternative input mechanisms when interacting with the device. For example, the primary + mechanism for mobile phones and tablets is the touchscreen. The user of these devices + may choose to use a paired mouse or external keyboard as an alternative to using the + touchscreen. +

+

Users should be able to switch input mechanisms at any point should the user determine + that certain tasks and interactions are more easily accomplished by using an alternative + input mechanism. Content must not limit the user's interaction to any particular input + mechanism unless the restriction is essential, or is required to ensure the security + of the content or to respect user settings. +

+

Note: A touch-typing web application, which teaches users how to touch-type on a keyboard + and/or measures their proficiency and speed, would be an example of an essential limitation + to a particular input mechanism. +

+
+
+

Benefits

+
    + +
  • Users can interact with web content with whichever input mechanism is preferred and + available to them. +
    • + +
  • Users may switch between input mechanisms when they desire or the circumstances require + it. +
    • + +
  • Users are allowed to add and remove input mechanisms at any point, where supported + by the operating system. +
    • + +
+
+
+

Examples

+
    + +
  • A user with mobility impairment pairs a mouse and keyboard to her mobile phone with + a touchscreen. The phone can thereafter be operated by those input devices and the + content does not accept the touchscreen as the only input mechanism. +
    • + +
  • On a touch-enabled laptop with coarse precision, people who have difficulty activating + a small target because of hand tremors, limited dexterity or other reasons are still + able to interact with content using their keyboard and trackpad. +
    • + +
  • A user starts interacting with a page using a desktop keyboard, and then attaches + a secondary touch-enabled monitor. Content can be operated using this newly added + input mechanism and does not assume that the keyboard, the first input mechanism it + detected, is the only one in use. +
    • + +
  • A speech input user navigates content using voice commands which translate to simulate + mouse (and keyboard) commands. When talking with a colleague, however, the user turns + speech recognition off and uses the mouse instead. +
    • + +
  • A user opens a menu with a mouse, and then navigates between the menu items with arrow + keys. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+
    + +
  • Only using high-level, input-agnostic event handlers, such as focus, blur, click, in Javascript (Potential future technique). +
    • + +
  • Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously + in Javascript; see Example 1 in Pointer Events Level 2 (Potential future technique) +
    • + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/conformance.html b/wcag22/understanding/conformance.html new file mode 100644 index 0000000..c7a51df --- /dev/null +++ b/wcag22/understanding/conformance.html @@ -0,0 +1,2003 @@ + + + + + + Understanding Conformance | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding Conformance

+
+ + + + +

All WCAG 2.0 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. + +

+ + +

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. + +

+ + +
+ + +

What does conformance mean?

+ + +

Conformance to a standard means that you meet or satisfy the 'requirements' of the + standard. In WCAG 2.0 the 'requirements' are the Success Criteria. To conform to WCAG + 2.0, you need to satisfy the Success Criteria, that is, there is no content which + violates the Success Criteria. + +

+ + +
+

Note

+
+ + +

This means that if there is no content to which a success criterion applies, the success + criterion is satisfied. + +

+ + +
+
+ + +

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.0 has three levels of conformance, and therefore, three levels of Success Criteria. + +

+ + +
+ + +
+ + +

Understanding Conformance Requirements

+ + +

There are five requirements that must be met in order for content to be classified + as 'conforming' to WCAG 2.0. 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. + +

+ + +
+ + +

Understanding Requirement 1

+ + +
+ +

Conformance Level: One of the following levels of conformance is met in full. +

+ +
    + +
  • For Level A conformance (the minimum level of conformance), the Web page + satisfies all the Level A Success Criteria, or a conforming alternate version is provided. +
    • + +
  • 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. +
    • + +
  • 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. +
    • + +
+ +
+

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. +

+
+ +
+

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. +

+
+ + +
+ + +

The first requirement deals with the levels of conformance. It basically says that + all information on a page conforms or has a + conforming alternate version 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. + +

+ + +

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. + +

+ + +

See also + Understanding Conforming Alternate Versions which includes techniques for providing Conforming Alternate Versions. + +

+ + +
+ + +
+ + +

Understanding Requirement 2

+ + +
+ +

Full pages: Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded. +

+ +
+

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. +

+
+ +
+

Note

+

Authors of Web pages that cannot conform due to content outside of the author's control + may consider a Statement of Partial Conformance. +

+
+ +
+

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. +

+
+ +
+ + +

This provision simply requires that the whole page conform. Statements about "part + of a page conforming" cannot be made. + + +

+ + +

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. + + +

+ + +
+

Note

+
+ + +

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. + +

+ + +

It is possible to include non-conforming content. See + Understanding Conformance Requirement 5. + +

+ + +
+
+ + +
+ + +
+ + +

Understanding Requirement 3

+ + +
+ +

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

+ +

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. +

+ +
+ + +

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. + +

+ + +
+ + +
+ + +

Understanding Requirement 4

+ + +
+ +

Only Accessibility-Supported Ways of Using Technologies: Only accessibility-supported ways of using technologies are relied upon 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 Understanding accessibility support.) +

+
+ + +

This conformance requirement is explained below under + Understanding Accessibility Support. + +

+ + +
+ + +
+ + +

Understanding Requirement 5

+ + +
+ +

Non-Interference: If technologies are used in a way that is not accessibility supported, 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 Web page as a whole continues to meet the conformance requirements under each of the following + conditions: +

+ +
    + +
  1. when any technology that is not relied upon is turned on in a user agent, +
    2. + +
  2. when any technology that is not relied upon is turned off in a user agent, and
    3. + +
  3. when any technology that is not relied upon is not supported by a user agent
    4. + +
+ +

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: +

+ +
    + +
  • 1.4.2 - Audio Control, +
    • + +
  • 2.1.2 - No Keyboard Trap, +
    • + +
  • 2.3.1 - Three Flashes or Below Threshold, and +
    • + +
  • 2.2.2 - Pause, Stop, Hide. +
    • + +
+ +
+

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. +

+
+ +
+ + +

This basically says that technologies that are + not accessibility supported can be used, as long as all the information is also available using technologies + that + are accessibility supported and as long as the + non-accessibility-supported material does not interfere. + +

+ + +

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. + +

+ + +

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. + +

+ + +
+ + +

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. + +

+ + +
+ + +
+ + +
+ + +
+ + +

Understanding Conformance Claims

+ + +

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. + +

+ +

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. +

+ + +

Here is a claim which has been enhanced with schema.org metadata:

+ + 
+<div typeof="WebPage" vocab="http://schema.org/">
+    <p property="accessibilitySummary">On 23 March 2009, all content available on
+       the server at <a 
+         href="http://www.wondercall.example.com">http://www.wondercall.example.com</a>
+       conforms to Web Content Accessibility Guidelines 2.0 at <a 
+         href="https://www.w3.org/TR/2008/REC-WCAG20-20081211/"
+         >https://www.w3.org/TR/2008/REC-WCAG20-20081211/</a>.
+       Single-A conformance.</p>
+    <ul>
+        <li>The technology that this content "<a>relies upon</a>" 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>
+    <p>This page includes both <span property="accessMode" content="textual">text</span>
+       and <span property="accessMode" content="visual">images</span>.
+       <span property="accessibilityFeature" content="alternativeText">Alternative 
+       text</span> is included for all image content and <span 
+         property="accessibilityFeature" content="longDescription">long 
+         descriptions</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.</p>
+</div>
+
+ +

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. + +

+ + +
+

Note

+
+ + +

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.). + +

+ + +

Conformance claims are not usually located on each Web page within the scope of conformance.

+ + +
+
+ + +
+ + +

Partial conformance claims due to third party content

+ + +

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. + +

+ + +

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. + +

+ + +

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. + +

+ + +
+ + +
+ + +

Information about any additional steps taken that go beyond the Success Criteria

+ + +

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. + +

+ + +
+ + +
+ + +

Use of metadata to report conformance claims

+ + +

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. + +

+ + +

In addition, metadata can be used to report conformance to individual Success Criteria + once Level A conformance has been achieved. + +

+ + +

There are also programmatic reporting formats such as + Evaluation and Report Language (EARL) 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. + +

+ + +
+ + + + +
+ +

Techniques for Conformance Claims

+ +
+ + + +
+ + +
+ + +

Advisory Techniques for Conformance Claims

+ + +
    + + +
  • Expressing a conformance claim to WCAG 2.0 in Dublin Core elements (future link)
    • + + +
+ + +
+ + +
+ + +
+ + +
+ + +

Understanding Levels of Conformance

+ + +

First, there are a number of conditions that must be met for a Success Criterion to + be included at all. These include: + +

+ + +
    + + +
  1. All Success Criteria must be + important access issues for people with disabilities 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). + +
    2. + + +
  2. 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. + +
    3. + + +
+ + +

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: + +

+ + +
    + + +
  • whether the Success Criterion is + essential (in other words, if the Success Criterion isn't met, then even assistive technology + can't make content accessible) + +
    • + + +
  • whether it is possible to satisfy the Success Criterion for + all Web sites and types of content that the Success Criteria would apply to (e.g., different topics, types of content, + types of Web technology) + +
    • + + +
  • whether the Success Criterion requires skills that could + reasonably be achieved by the content creators (that is, the knowledge and skill to meet the Success Criteria could be acquired + in a week's training or less) + +
    • + + +
  • whether the Success Criterion would impose limits on the "look & feel" and/or function + of the Web page. (limits on function, presentation, freedom of expression, design + or aesthetic that the Success Criteria might place on authors) + +
    • + + +
  • whether there are no workarounds if the Success Criterion is not met
    • + + +
+ + +
+ + +
+ + +

Understanding Accessibility Support

+ + +

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." + +

+ + +

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. + +

+ + +

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. + +

+ + +

"Accessibility Supported" means that both of these have been done and that the technology will work with user + agents and assistive technologies. + +

+ + +
+ + +

Level of Assistive Technology Support Needed for "Accessibility Support"

+ + +

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: + +

+ + +
    + + +
  1. + + +

    Accessibility support of Web technologies varies by environment

    + + +
      + + +
    • 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). + +
      • + + +
    • Content posted to the public Web may need to work with a broader range of user agents + and assistive technologies, including older versions. + +
      • + + +
    + + +
    2. + + +
  2. + + +

    Accessibility support of Web technologies varies by language (and dialect)

    + + +
      + + +
    • There are different levels of older assistive technologies support in different languages + and even countries. Some environments or countries may provide free assistive technologies. + +
      • + + +
    + + +
    3. + + +
  3. + + +

    New technologies won't be supported in older assistive technologies

    + + +
      + + +
    • 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. + +
      • + + +
    + + +
    4. + + +
  4. + + +

    Support for a single older assistive technology is usually not sufficient

    + + +
      + + +
    • 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). + +
      • + + +
    + + +
    5. + + +
  5. + + +

    Currently assistive technology that is affordable by the general public is often very + poor + +

    + + +
      + + +
    • 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. + +
      • + + +
    + + +
    6. + + +
+ + +

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. + +

+ + +

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. + +

+ + +
+ + +
+ + +

Technical Definition of "Accessibility Support"

+ + +

Basically, a Web content technology is "accessibility supported" when users' assistive + technologies will work with the Web technologies + AND 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: + +

+ + +
accessibility supported
+
+ +

supported by users' assistive technologies as well as the accessibility features in browsers and other user agents

+ +

To qualify as an accessibility-supported use of a Web content technology (or feature + of a technology), both 1 and 2 must be satisfied for a Web content technology (or + feature): +

+ +
    + +
  1. + +

    The way that the Web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability + with users' assistive technology in the human language(s) of the content, +

    + +

    AND

    + +
    2. + +
  2. + +

    The Web content technology must have accessibility-supported user agents that are + available to users. This means that at least one of the following four statements is true: +

    + +
      + +
    1. + +

      The technology is supported natively in widely-distributed user agents that are also + accessibility supported (such as HTML and CSS); +

      + +

      OR

      +
      2. + +
    2. +

      The technology is supported in a widely-distributed plug-in that is also accessibility + supported; +

      + +

      OR

      +
      3. + +
    3. +

      The content is available in a closed environment, such as a university or corporate + network, where the user agent required by the technology and used by the organization + is also accessibility supported; +

      + +

      OR

      +
      4. + +
    4. +

      The user agent(s) that support the technology are accessibility supported and are + available for download or purchase in a way that: +

      + +
        + +
      • does not cost a person with a disability any more than a person without a disability + and
        • + +
      • is as easy to find and obtain for a person with a disability as it is for a person + without disabilities. +
        • + +
      + +
      5. + +
    + +
    3. + +
+ +

The Accessibility Guidelines Working Group and the W3C do not specify which or how much support by assistive + technologies there must be for a particular use of a Web technology in order for it + to be classified as accessibility supported. (See Level of Assistive Technology Support Needed for "Accessibility Support".) +

+ +

Web technologies can be used in ways that are not accessibility supported as long + as they are not relied upon and the page as a whole meets the conformance requirements, including Conformance Requirement 4 and Conformance Requirement 5. +

+ +

When a Web Technology is used in a way that is "accessibility supported," it does not imply that the entire + technology or all uses of the technology are supported. Most technologies, including + HTML, lack support for at least one feature or use. Pages conform to WCAG only if + the uses of the technology that are accessibility supported can be relied upon to + meet WCAG requirements. +

+ +

When citing Web content technologies that have multiple versions, the version(s) supported + should be specified. +

+ +

One way for authors to locate uses of a technology that are accessibility supported + would be to consult compilations of uses that are documented to be accessibility supported. + (See Understanding Accessibility-Supported Web Technology Uses.) Authors, companies, technology vendors, or others may document accessibility-supported + ways of using Web content technologies. However, all ways of using technologies in + the documentation would need to meet the definition of accessibility-supported Web + content technologies above. +

+ +
+
+ + +
+ + +
+ + +

Understanding Accessibility-Supported Web Technology Uses

+ + +

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. + +

+ + +

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). + +

+ + +

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 + Documenting Accessibility Support for Uses of a Web Technology. + + +

+ + +
+ + +
+ + +

Accessibility Support Statements

+ + +

Examples of ways in which a conformance claim might document its accessibility support + include: + +

+ + +
    + + +
  1. 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. + +
    2. + + +
  2. 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." + +
    3. + + +
  3. 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." + +
    4. + + +
  4. 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. + +
    5. + + +
+ + +
+ + +
+ + +
+ + +

Understanding "Programmatically Determined"

+ + +

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. + +

+ + +

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. + +

+ + +

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. + +

+ + +

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. + +

+ + +
+ + +

"Accessibility Supported" vs. "Programmatically Determined"

+ + +

"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.). + +

+ + +

"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. + +

+ + +

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. + +

+ + +
+ + +
+ + +
+ + +

Understanding Conforming Alternate Versions

+ + +

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: + +

+ + +
conforming alternate version
+
+ +

version that

+ +
    + +
  1. conforms at the designated level, and
    2. + +
  2. provides all of the same information and functionality in the same human language, and +
    3. + +
  3. is as up to date as the non-conforming content, and
    4. + +
  4. +

    for which at least one of the following is true:

    + +
      + +
    1. the conforming version can be reached from the non-conforming page via an accessibility-supported + mechanism, or +
      2. + +
    2. the non-conforming version can only be reached from the conforming version, or
      3. + +
    3. the non-conforming version can only be reached from a conforming page that also provides + a mechanism to reach the conforming version +
      4. + +
    + +
    5. + +
+ +

In this definition, "can only be reached" means that there is some mechanism, such + as a conditional redirect, that prevents a user from "reaching" (loading) the non-conforming + page unless the user had just come from the conforming version. +

+ +

The alternate version does not need to be matched page for page with the original + (e.g., the conforming alternate version may consist of multiple pages). +

+ +

If multiple language versions are available, then conforming alternate versions are + required for each language offered. +

+ +

Alternate versions may be provided to accommodate different technology environments + or user groups. Each version should be as conformant as possible. One version would + need to be fully conformant in order to meet conformance requirement 1. +

+ +

The conforming alternative version does not need to reside within the scope of conformance, + or even on the same Web site, as long as it is as freely available as the non-conforming + version. +

+ +

Alternate versions should not be confused with supplementary content, which support the original page and enhance comprehension. +

+ +

Setting user preferences within the content to produce a conforming version is an + acceptable mechanism for reaching another version as long as the method used to set + the preferences is accessibility supported. +

+ +

See Understanding Conforming Alternate Versions

+ +
+
+ + +

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. + +

+ + +

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"). +

+ + +
+ + +

Why permit alternate versions?

+ + +

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? + +

+ + +
    + + +
  • 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. + +
    • + + +
  • + + +

    For a variety of reasons, it may not be possible to modify some content on a Web page. + For instance, + +

    + + +
      + + +
    • It may be critical to include an exact visual copy of a document for legal or historical + reasons + +
      • + + +
    • 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 + +
      • + + +
    • The company may not legally be able to remove, or alter in any way, something that + was previously posted. + +
      • + + +
    • An author may not have permission to alter a document from another department, agency, + or company + +
      • + + +
    + + +
    • + + +
  • 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. + +
    • + + +
  • 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. + +
    • + + +
+ + +

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. + +

+ + +

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. + +

+ + +
+ + +
+ + +

Techniques for Providing a Conforming Alternate Version

+ + +

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. + +

+ + +

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. + +

+ + +
+ +

Sufficient Techniques for Providing Conforming Alternative Versions of Web pages

+ + +

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 + , particularly the "Other Techniques" section. + +

+ + +
    + + +
  1. + + G136: Providing a link at the beginning of a nonconforming Web page that points to a conforming + alternate version + + +
    2. + + +
  2. + + G190: Providing a link adjacent to or associated with a non-conforming object that links + to a conforming alternate version + + +
    3. + + +
  3. + + C29: Using a style switcher to provide a conforming alternate version + + +
    4. + + +
  4. + + SCR38: Creating a conforming alternate version for a web page designed with progressive enhancement + + +
    5. + + +
  5. + + SVR2: Using .htaccess to ensure that the only way to access non-conforming content is from + conforming content + + +
    6. + + +
  6. + + SVR3: Using HTTP referer to ensure that the only way to access non-conforming content is + from conforming content + + +
    7. + + +
  7. + + SVR4: Allowing users to provide preferences for the display of conforming alternate versions + + +
    8. + + +
+ + +
+ + +
+ +

Common Failures Identified by the Working Group

+ + + + + +
+ + +
+ +

Additional Techniques (Advisory) for providing conforming alternative versions of + Web pages + +

+ + +
    + + +
  • Providing reciprocal links between conforming and non-conforming versions (future + link) + +
    • + + +
  • Excluding non-conforming content from search results (future link)
    • + + +
  • Using content negotiation (future link)
    • + + +
  • Not displaying content that relies on technologies that are not accessibility-supported + when the technology is turned off or not supported. (future link) + +
    • + + +
  • Using metadata to allow location of a conforming alternative version from the URI + of a non-conforming page (future link) + +
    • + + +
+ + +
+ + +
+ +

Examples of Conforming Alternate Versions

+ + +
    + + +
  • + + +

    + + An intranet site with multiple versions. + + +

    + + +

    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. + + + +

    + + +
    • + + +
  • + + +

    + + An informational site ensuring backward compatibility. + + +

    + + +

    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. + +

    + + +
    • + + +
+ + +
+ + +
+ + +
+ + +
+ + +

Understanding "Web Page"

+ + +

The definition of a Web Page is:

+ + +
Web page
+
+ +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent

+ +

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. +

+ +

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. +

+ + + + + + + + + +
+
+ + +

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. + +

+ + +
+ + +
+ + +

Understanding "Text Alternatives"

+ + +

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. + +

+ + +

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. + +

+ + +

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). + +

+ + +
+ + + +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/consistent-help.html b/wcag22/understanding/consistent-help.html new file mode 100644 index 0000000..c16df9e --- /dev/null +++ b/wcag22/understanding/consistent-help.html @@ -0,0 +1,875 @@ + + + + + + Understanding Success Criterion 3.2.6: Consistent Help | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.2.6:Consistent Help (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Make it easier to find help and support.
+ +
What to do
+
Put help in the same place when it is on multiple pages.
+ +
Why it's important
+
People who need help can find it more easily if it's in the same place.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure users can find help for completing + tasks on a Web site, when it is available. When the placement of the help mechanism + is kept consistent across a set of pages, users looking for help will find it easier + to identify. This is distinct from interface-level help, such as contextual help, + features like spell checkers, and instructional text in a form. +

+

Locating the help mechanism in a consistent location across pages makes it easier + for users to find it. For example, when a mechanism or link is located in the header + of one Web page, it will be easier to find if it is in the header of other pages. + The help mechanism, such as a contact phone number, may be provided directly on the + page, or it may also be a direct link to a contact page. Regardless of which approach + is used, the mechanism must be located in the same relative order on each page within + the set of pages. +

+

When testing this Success Criterion, it is the help item which is relative to the + rest of the content. When testing a page, other content that is present across the + set of web pages and is before the help item should be before the help item on this + page. Items which are after the help item on other pages should be after the help + item on this page. +

+

If the help item is visually in a different location, but in the same serial order, + that is not helpful from a user's point of view, but it would not fail this criterion. +

+

When having problems completing a task on a Web site (or part of a Web site, what + we call a set of Web pages), people with some types of disabilities may not be able to work through the issue + without further help. Issues could include difficulty: + completing a form, or finding a document or page which provides information required + to complete a task. +

+

Without help, some users may abandon the task. They may also fail to correctly complete + a task, or they may require assistance from people who do not necessarily keep private + information secure. +

+
+ +

Limitations and Exceptions

+ + +

It is not the intent of this Success Criterion to require authors to provide help + or access to help. The Criterion only requires that when one of the listed forms of help is available across multiple pages that it be in + a consistent location. It does not require authors to provide help information on + PDFs or other static documents that may be available for viewing/download from the + Web pages. PDFs and other static documents are not considered part of the "set of web pages" from which they are downloaded. +

+ + +

It is also not the intent of this Success Criterion to require a human be available + at all times. Ideally, if the human contact is not available during certain hours + or certain days then information would be provided so the user can tell when it will + be available. +

+ + +

This Success Criterion only requires help mechanisms to be consistent within a particular set of web pages. Some complex Web sites consist of multiple different sets of web pages with different + purposes. For example, a web-based spreadsheet application might have one set of pages + for editing spreadsheets and a separate set of pages for marketing the application. + This Success Criterion would allow the different sets of web pages to use different + help mechanism locations. However, it is best if help mechanisms are located as consistently + as possible even among different related sets of web pages. +

+ + +

This Success Criterion contains an exception when "a change is initiated by the user." + This exception is intended to cover cases where a user performs an action with the + intent of changing the display or layout of a page, such as changing the zoom level, + orientation, or viewport size. Help mechanism locations may change in response to + such a user-initiated change; as the criterion's second note clarifies, "this criterion + is concerned with relative order across pages displayed in the same page variation + (e.g., same zoom level and orientation)." +

+ + +

This exception allows the location in a smaller viewport to be different than in a + larger viewport. However, it is best if the mechanism or link is consistent across + a set of web pages. A consistent location, both visually and programmatically, is + the most usable. +

+ + +

This exception is not intended to treat every action that a user might initiate as a "change"; to qualify + for the exception, the user must be initiating an action that would reasonably be + expected to change the relative order of components within a page. For example, merely + navigating between pages within a set of web pages is not a "change initiated by the + user" for the purposes of this exception. Similarly, logging into or out of a page + would not typically qualify, unless logging in would present the user with a distinct + set of web pages. +

+ +
+
+ +

Help Mechanisms

+ + +

Typical help mechanisms include:

+ +
    + +
  • Human contact details such as a phone number, email address, hours of operation.
    • + +
  • Human contact mechanism such as a messaging system, chat client, contact form, social + media channel. +
    • + +
  • Self-help option such as an up-to-date Frequently Asked Questions, How Do I page, + Support page. +
    • + +
  • A fully automated contact mechanism such as a chatbot.
    • + +
+ + +

The order of the types of help listed in the Success Criterion does not imply priority.

+ +
+
+ +

Support for people with cognitive and learning disabilities

+ + +

This section is not required by the Consistent Help success criterion, but provides + advice related to Making Content Usable for People with Cognitive and Learning Disabilities. +

+ + +

The human contact details enable users to connect with the organization or the part + of the organization that can assist with the content. For example, an online jobs + / recruitment portal may provide a contact method for the team that supports the recruitment + portal and not a catch-all for the entire company. Each layer of contact added prolongs + the time before the user will receive help. +

+ + +

The human contact mechanism enables a person to express what they are looking for + using their own words. For some with cognitive disabilities, this may be the best + way for them to find an answer to their problem. +

+ + +

For pages for which no human support is available it helps if a self-help option says + that no human support is available. Self-help options can go beyond allowing the user + to search within the site. Contextual help is still recommended (see Success Criterion 3.3.5 for more information), but a self-help option provides a single location that makes + it easier for people with cognitive disabilities to understand what help is available + without having to hunt for it. While some people may easily be able to identify that + no support would be available for a particular type of Web site, this may not be apparent + to some users with disabilities. +

+ + +

Chatbots can work for many people, and particularly for people with cognitive disabilities + if they: +

+ + +
    + +
  • recognize misspelled words,
    • + +
  • provide human contact details if the chatbot is unable to provide a satisfactory response + after 3 attempts, and +
    • + +
  • can be dismissed with a single interaction, and recalled using a link or button.
    • + +
+ + +

This criterion does not require that a site provide a help mechanism. However, when + help is available: +

+ +
    + +
  • People who may have difficulty locating help are more likely to find it and complete + their task. +
    • + +
  • Users that experience cognitive fatigue or cognitive shut down will be able to reserve + their energy for the task, instead of using it to find support. +
    • + +
  • Enabling users (especially those with cognitive disabilities) to find solutions while + expressing their question using their own words (for example by interacting with a + chatbot) increases their chances of success for completing a task. +
    • + +
+ + +

Self help methods beyond the site, such as using internet search to find the contact + information for an organization, can be too difficult. Further, the user's disability + may make it more difficult to find the help available (such as a "contact us" link, + phone number, or support page) if the information is not consistently present within + a few interactions (e.g., displayed in the header, or via a menu). In addition, for + some users with disabilities, struggling to complete a task on a site may cause additional + cognitive challenges when searching for help within the site. +

+ + +

When a user is quickly able to find help, they are able to complete the task even + if they encounter challenges. +

+ +
+
+
+

Benefits

+
    + +
  • People who may have difficulty locating help are more likely to find it when it is + consistently located. +
    • + +
+
+
+

Examples

+
    + +
  • On-line job application: Some of the application questions may be hard for new job + seekers to understand even after reading the contextual help. For example, the form + may request their identification number, but they may have several and not know which + one to enter. Consistently located contact information will enable them to use phone + or email so they can get an answer to their question. +
    • + +
  • Medical appointment scheduling form: When the service a patient is trying to book + is not easily findable within the interface, they may need human help. A consistently + located messaging option (chat client) enables them to quickly interact with a staff + person that can help, without requiring them to manage a second interface. +
    • + +
  • Finding a specific policy or procedure: An employee who needs to complete a work task + may have difficulty locating the specific policy or procedure document on their employer's + Web site. A consistently located "How Do I" page may include the information that + enables them to independently complete this task. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+
    + +
  1. G220: Provide a contact-us link in a consistent location
    2. + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+
    + +
  • Inconsistent Help Location + +
    • + +
+
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
set of web pages
+
+ + + +

collection of web pages that share a common purpose and that are created by the same author, group or organization + +

+ + + + + +
+

Note

+

Different language versions would be considered different sets of Web pages.

+
+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/consistent-identification.html b/wcag22/understanding/consistent-identification.html new file mode 100644 index 0000000..c788bfd --- /dev/null +++ b/wcag22/understanding/consistent-identification.html @@ -0,0 +1,665 @@ + + + + + + Understanding Success Criterion 3.2.4: Consistent Identification | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.2.4:Consistent Identification (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Actions are more predictable across pages.
+ +
What to do
+
Identify repeating functions consistently.
+ +
Why it's important
+
Consistently identified actions are especially important to people with disabilities.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure consistent identification of functional + components that appear repeatedly within a set of Web pages. A strategy that people + who use screen readers use when operating a Web site is to rely heavily on their familiarity + with functions that may appear on different Web pages. If identical functions have + different labels (or, more generally, a different accessible name) + on different Web pages, the site will be considerably more difficult + to use. It may also be confusing and increase the cognitive load for people with cognitive + limitations. Therefore, consistent labeling will help. + +

+

This consistency extends to the text alternatives. If icons or other non-text items + have the same functionality, then their text alternatives should be consistent as + well. + +

+

If there are two components on a web page that both have the same functionality as + a component on another page in a set of web pages, then all 3 must be consistent. + Hence the two on the same page will be consistent. + +

+

While it is desirable and best practice always to be consistent within a single web + page, 3.2.4 only addresses consistency within a set of web pages where something is + repeated on more than one page in the set. + +

+
+
+

Benefits

+
    + + +
  • People who learn functionality on one page on a site can find the desired functions + on other pages if they are present. + +
    • + + +
  • When non-text content is used in a consistent way to identify components with the + same functionality, people with difficulty reading text or detecting text alternatives + can interact with the Web without depending on text alternatives. + +
    • + + +
  • People who depend on text alternatives can have a more predictable experience. They + can also search for the component if it has a consistent label on different pages. + +
    • + + +
+
+
+

Examples

+
+ +
Example 1: Document Icon
+ +
A document icon is used to indicate document download throughout a site. The text + alternative for the icon always begins with the word “Download," followed by a shortened + form of the document title. Using different text alternatives to identify document + names for different documents is a consistent use of text alternatives. +
+ +
Example 2: Check Mark
+ +
A check mark icon functions as "approved", on one page but as "included" on another. + Since they serve different functions, they have different text alternatives. +
+ +
Example 3: Consistent references to other pages
+ +
A Web site publishes articles on-line. Each article spans multiple Web pages and + each page contains a link to the first page, the next page and the previous page of + the article. If the references to the next page read "page 2", "page 3", "page 4" + etcetera, the labels are not the same but they are consistent. Therefore, these references + are not failures of this Success Criterion. +
+ +
Example 4: Icons with similar functions
+ +
An e-commerce application uses a printer icon that allows the user to print receipts + and invoices. In one part of the application, the printer icon is labeled "Print receipt" + and is used to print receipts, while in another part it is labeled "Print invoice" + and is used to print invoices. The labeling is consistent ("Print x"), but the labels + are different to reflect the different functions of the icons. Therefore, this example + does not fail the Success Criterion. +
+ +
Example 5: Save icon
+ +
A common "save" icon is used through out the site where page save function is provided + on multiple Web pages. +
+ +
Example 6: Icon and adjacent link to same destination
+ +
An icon with alt text and a link are next to each other and go to the same location. + The best practice would be to group them into one link as per + H2: Combining adjacent image and text links for the same resource. However if they are visually positioned one above the other but separated in the + source, this may not be possible. To meet the Success Criterion, the link text for + these two links need only be consistent, not identical. But best practice is to have + identical text so that when users encounter the second one, it is clear that it goes + to the same place as the first. +
+ +
Example 7: Example of a Failure
+ +
A submit "search" button on one Web page and a "find" button on another Web page both + have a field to enter a term and list topics in the Web site related to the term submitted. + In this case, the buttons have the same functionality but are not labeled consistently. +
+ + +
Example 8: Failure primarily impacting assistive technology users
+ +
Two buttons with the same functionality visually have the same text, but have been + given + different aria-label="..." accessible names. For users of assistive technologies, + these two buttons will be announced differently and inconsistently. +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+

Note

+
+ + +

Text alternatives that are "consistent" are not always "identical." For instance, + you may have a graphical arrow at the bottom of a Web page that links to the next + Web page. The text alternative may say "Go to page 4." Naturally, it would not be + appropriate to repeat this exact text alternative on the next Web page. It would be + more appropriate to say "Go to page 5". Although these text alternatives would not + be identical, they would be consistent, and therefore would satisfy this Success Criterion. + +

+ + +

A single non-text-content-item may be used to serve different functions. In such + cases, different text alternatives are necessary and should be used. Examples can + be commonly found with the use of icons such as check marks, cross marks, and traffic + signs. Their functions can be different depending on the context of the Web page. + A check mark icon may function as "approved", "completed", or "included", to name + a few, depending on the situation. Using "check mark" as text alternative across all + Web pages does not help users understand the function of the icon. Different text + alternatives can be used when the same non-text content serves multiple functions. + +

+ + +
+
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
same functionality
+
+ + + +

same result when used

+ + + + + + +
+
set of web pages
+
+ + + +

collection of web pages that share a common purpose and that are created by the same author, group or organization + +

+ + + + + +
+

Note

+

Different language versions would be considered different sets of Web pages.

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/consistent-navigation.html b/wcag22/understanding/consistent-navigation.html new file mode 100644 index 0000000..8c5edc8 --- /dev/null +++ b/wcag22/understanding/consistent-navigation.html @@ -0,0 +1,638 @@ + + + + + + Understanding Success Criterion 3.2.3: Consistent Navigation | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.2.3:Consistent Navigation (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Content can be navigated more predictably.
+ +
What to do
+
Consistently order navigation that repeats across multiple pages.
+ +
Why it's important
+
Content that behaves predictably is especially important to people with disabilities.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to encourage the use of consistent presentation + and layout for users who interact with repeated content within + a set of Web pages and need to locate specific information or functionality more than + once. + Individuals with low vision who use screen magnification to display a small portion + of the screen at a time often use visual cues and page boundaries to quickly locate + repeated content. + Presenting repeated content in the same order is also important for visual users who + use spatial memory or visual cues within the design to locate repeated content. + + +

+

It is important to note that the use of the phrase "same order" in this section is + not meant to imply that subnavigation menus cannot be used or that blocks of secondary + navigation or page structure cannot be used. Instead, this Success Criterion is intended + to assist users who interact with repeated content across Web pages to be able to + predict the location of the content they are looking for and find it more quickly + when they encounter it again. + + +

+

Users may initiate a change in the order by using adaptive user agents or by setting + preferences so that the information is presented in a way that is most useful to them. + + + + +

+
+
+

Benefits

+
    + + +
  • Ensuring that repeated components occur in the same order on each page of a site helps + users become comfortable that they will able to predict where they can find things + on each page. This helps users with + cognitive limitations, users with + low vision, users with + intellectual disabilities, and also those who are + blind. + + +
    • + + +
+
+
+

Examples

+
+ +
A consistently located control
+ +
A search field is the last item on every Web page in a site. Users can quickly locate + the search function. +
+ +
An expanding navigation menu
+ +
A navigation menu includes a list of seven items with links to the main sections of + a site. + When a user selects one of these items, a list of sub-navigation items is inserted + into the top-level navigation menu. +
+ +
Consistently positioned skip navigation controls
+ +
A "skip navigation" (or "skip to main content") link is included as the first link + on every page in a Web site. The link allows users to quickly bypass heading information + and navigational content and begin interacting with the main content of a page. +
+ +
Skip to navigation link
+ +
Navigational content is consistently located at the end of each page in a set of Web + pages. A "skip to navigation" link is consistently located at the beginning of each + page so that keyboard users can easily locate it when needed. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
same relative order
+
+ + + +

same position relative to other items

+ + +
+

Note

+

Items are considered to be in the same relative order even if other items are inserted + or removed from the original order. For example, expanding navigation menus may insert + an additional level of detail or a secondary navigation section may be inserted into + the reading order. + +

+
+ + + +
+
set of web pages
+
+ + + +

collection of web pages that share a common purpose and that are created by the same author, group or organization + +

+ + + + + +
+

Note

+

Different language versions would be considered different sets of Web pages.

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/content-on-hover-or-focus.html b/wcag22/understanding/content-on-hover-or-focus.html new file mode 100644 index 0000000..c7f2db7 --- /dev/null +++ b/wcag22/understanding/content-on-hover-or-focus.html @@ -0,0 +1,880 @@ + + + + + + Understanding Success Criterion 1.4.13: Content on Hover or Focus | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.13:Content on Hover or Focus (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
More users can perceive and dismiss non-persistent content.
+ +
What to do
+
If hover or focus causes content changes, ensure interaction is predictable.
+ +
Why it's important
+
Unpredictable temporary content can be hard for some to consume and may disrupt others.
+ +
+
+
+

Intent

+

Additional content that appears and disappears in coordination with keyboard focus + or pointer hover often leads to accessibility issues. Reasons for such issues include: +

+
    + +
  1. the user may not have intended to trigger the interaction
    2. + +
  2. the user may not know new content has appeared
    3. + +
  3. the new content may intefere with a user's ability to do a task
    4. + +
+

Examples of such interactions can include custom tooltips, sub-menus and other nonmodal + popups which display on hover and focus. The intent of this success criterion is to + ensure that authors who cause additional content to appear and disappear in this manner + must design the interaction in such a way that users can: +

+
    + +
  • perceive the additional content AND
    • + +
  • dismiss it without disrupting their page experience.
    • + +
+

There are usually more predictable and accessible means of adding content to the page, + which authors are recommended to employ. If an author does choose to make additional content appear and disappear in coordination with hover + and keyboard focus, this success criterion specifies three conditions that must be + met: +

+
    + +
  • dismissable
    • + +
  • hoverable
    • + +
  • persistent
    • + +
+

Each of these is discussed in a separate section.

+
+ +

Dismissable

+ +

The intent of this condition is to ensure that the additional content does not interfere + with viewing or operating the page's original content. When magnified, the portion + of the page visible in the viewport can be significantly reduced. Mouse users frequently + move the pointer to pan the magnified viewport and display another portion of the + screen. However, almost the entire portion of the page visible in this restricted + viewport may trigger the additional content, making it difficult for a user to pan + without re-triggering the content. A keyboard means of dismissing the additional content + provides a workaround. +

+ +

Alternatively, low vision users who can only navigate via the keyboard do not want + the small area of their magnified viewport cluttered with hover text. They need a + keyboard method of dismissing something that is obscuring the current focal area. +

+ +

Two methods may be used to satisfy this condition and prevent such interference:

+ +
    + +
  1. Position the additional content so that it does not obscure any other content including + the trigger, with the exception of white space and purely decorative content, such + as a background graphic which provides no information. +
    2. + +
  2. Provide a mechanism to easily dismiss the additional content, such as by pressing + Escape. +
    3. + +
+ +

For most triggers of relatively small size, it is desirable for both methods to be + implemented. If the trigger is large, noticing the additional content may be of concern + if it appears away from the trigger. In those cases, only the second method may be + appropriate. +

+ +

The success criterion allows for input error messages to persist as there are cases + that require attention, explicit confirmation or remedial action. +

+ +
+
+ +

Hoverable

+ +

The intent of this condition is to ensure that additional content which may appear + on hover of a target may also be hovered itself. Content which appears on hover can + be difficult or impossible to perceive if a user is required to keep their mouse pointer + over the trigger. When the added content is large, magnified views may mean that the + user needs to scroll or pan to completely view it, which is impossible unless the + user is able to move their pointer off the trigger without the additional content + disappearing. +

+ +

Another common situation is when large pointers have been selected via platform settings + or assistive technology. Here, the pointer can obscure a significant area of the additional + content. A technique to view the content fully in both situations is to move the mouse + pointer directly from the trigger onto the new content. This capability also offers + significant advantages for users who utilize screen reader feedback on mouse interactions. + This condition generally implies that the additional content overlaps or is positioned + adjacent to the target. +

+ +
+
+ +

Persistent

+ +

The intent of this condition is to ensure users have adequate time to perceive the + additional content after it becomes visible. Users with disabilities may require + more time for many reasons, such as to change magnification, move the pointer, or + simply to bring the new content into their visual field. Once it appears, the content + should remain visible until: +

+ +
    + +
  • The user removes hover or focus from the trigger and the additional content, consistent + with the typical user experience; +
    • + +
  • The user dismisses the additional content via the mechanism provided to satisfy the + Dismissable condition; or +
    • + +
  • The information conveyed by the additional content becomes invalid, such as a 'busy' + message that is no longer valid. +
    • + +
+ +
+
+ +

Additional Notes

+ +
    + +
  • This criterion does not attempt to solve such issues when the appearance of the additional + content is completely controlled by the user agent. A prominent example is the common + behavior of browsers to display the title  attribute in HTML as a small tooltip. +
    • + +
  • Modal dialogs are out of scope for this criterion because they must take keyboard + focus and thus should not appear on hover or focus. Refer to Success Criterion 3.2.1, On Focus. +
    • + +
  • Content which can be triggered via pointer hover should also be able to be triggered + by keyboard focus. Refer to Success Criterion 2.1.1, Keyboard. +
    • + +
+ +
+
+
+

Benefits

+
    + +
  • Users with low vision who view content under magnification will be better able to + view content on hover or focus without reducing their desired magnification. +
    • + +
  • Users who increase the size of mouse cursors via platform settings or assistive technology + will be able to employ a technique to view obscured content on hover. +
    • + +
  • Users with low vision or cognitive disabilities will have adequate time to perceive + additional content appearing on hover or focus and to view the trigger content with + less distraction. +
    • + +
  • users with low pointer accuracy will be able to more easily dismiss unintentionally-triggered + additional content +
    • + +
+
+
+

Examples

+
+ +

Example 1: Dismissable Tooltip

+ +
+ Screenshot of a button with a mouse pointer over it, and a tooltip displayed below the button + Screenshot of a button with a mouse pointer over it, and no tooltip + +
Figure 1 A tooltip is displayed below a LVTF button on hover so as not to obscure the button + itself. It does however obscure content below the button (the next red button, called + ~comment-zoom-content). To meet the Dismissible requirement, a user can press the + Escape key to clear the tooltip without moving the mouse, as demonstrated in the second + image. +
+ +
+ +
+ Screenshot of a button with a focus indicator on it, and no tooltip + +
Figure 2 The button's tooltip also appears on focus and can be removed with the Escape key. + The screen shot shows the same LVTF button with focus, but the tooltip has been dismissed + and is no longer visible. +
+ +
+ +
+
+ +

Example 2: Hoverable Tooltip

+ +
+ Screenshot of a button with a large mouse pointer over it, and a tooltip displayed below the button which is obscured by the large pointer + Screenshot of a button with a tooltip below it, and a large mouse pointer at the bottom of the tooltip + +
Figure 3 A button's tooltip is displayed directly below it on mouse hover which can easily + be obscured by a large pointer. The tooltip itself is able to be hovered so the mouse + pointer can be moved down to its bottom edge in order to view the tooltip text. +
+ +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
input error
+
+ + + +

information provided by the user that is not accepted

+ + +
+

Note

+
+ +

This includes:

+ + +
    + + +
  1. Information that is required by the Web page but omitted by the user + +
    2. + + +
  2. Information that is provided by the user but that falls outside the required data + format or values + +
    3. + + +
+ +
+
+ + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/contrast-enhanced.html b/wcag22/understanding/contrast-enhanced.html new file mode 100644 index 0000000..a0fb9a6 --- /dev/null +++ b/wcag22/understanding/contrast-enhanced.html @@ -0,0 +1,1362 @@ + + + + + + Understanding Success Criterion 1.4.6: Contrast (Enhanced) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.6:Contrast (Enhanced) (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Text can be seen by people who need strong contrast.
+ +
What to do
+
Strongly contrast text against its background.
+ +
Why it's important
+
Some people cannot read text with minimum contrast.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to provide enough contrast between text and + its background so that it can be read by people with moderately low vision (who do + not use contrast-enhancing assistive technology). For people without color deficiencies, + hue and saturation have minimal or no effect on legibility as assessed by reading + performance (Knoblauch et al., 1991). Color deficiencies can affect luminance contrast + somewhat. Therefore, in the recommendation, the contrast is calculated in such a way + that color is not a key factor so that people who have a color vision deficit will + also have adequate contrast between the text and the background. + +

+

Text that is decorative and conveys no information is excluded. For example, if random + words are used to create a background and the words could be rearranged or substituted + without changing meaning, then it would be decorative and would not need to meet this + criterion. + +

+

Text that is larger and has wider character strokes is easier to read at lower contrast. + The contrast requirement for larger text is therefore lower. This allows authors to + use a wider range of color choices for large text, which is helpful for design of + pages, particularly titles. 18 point text or 14 point bold text is judged to be large + enough to require a lower contrast ratio. (See The American Printing House for the + Blind Guidelines for Large Printing and The Library of Congress Guidelines for Large + Print under + Resources). "18 point" and "bold" can both have different meanings in + different fonts but, except for very thin or unusual fonts, they should be sufficient. + Since there + are so many different fonts, the general measures are used and a note regarding thin + or unusual + fonts is included in the definition for large-scale text. + +

+
+

Note

+
+ +

When evaluating this Success Criterion, the font size in points should be obtained + from the user agent or calculated on font metrics in the way that user agents do. + Point sizes are based on the CSS pt size as defined in + CSS3 Values. The ratio between + sizes in points and CSS pixels is 1pt = 1.333px, therefore 14pt + and 18pt are equivalent to approximately 18.5px and 24px. + +

+ +

Because different image editing applications default to different pixel densities + (e.g., 72ppi or 96ppi), specifying point sizes for fonts from within an + image editing application can be unreliable when it comes to presenting text at a + specific size. + When creating images of large-scale text, authors should ensure that the text in the + resulting image is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the + default size for body text. For example, for a 72ppi image, an author would need + to use approximately 19pt and 24pt font sizes in order to successfully present images + of large-scale text to a user. + +

+ +

The 7:1 and 4.5:1 contrast ratios referenced in this Success Criterion are intended + to be + treated as threshold values. When comparing the computed contrast ratio to the Success + Criterion + ratio, the computed values should not be rounded (e.g., 4.499:1 would not meet the + 4.5:1 threshold). +

+ +
+
+
+

Note

+
+ +

Because authors do not have control over user settings for font smoothing/anti-aliasing, + when evaluating this + Success Criterion, refer to the foreground and background colors obtained from the + user agent, or the underlying + markup and stylesheets, rather than the text as presented on screen. +

+ +

Due to anti-aliasing, particularly thin or unusual fonts may be rendered by user agents + with a much fainter + color than the actual text color defined in the underlying CSS. This can lead to situations + where text has + a contrast ratio that nominally passes the Success Criterion, but has a much lower + contrast in practice. + In these cases, best practice would be for authors to choose a font with stronger/thicker + lines, + or to aim for a foreground/background color combination that exceeds the normative + requirements + of this Success Criterion. + +

+ +
+
+

The contrast requirements for text also apply to images of text + (text that has been rendered into pixels and then stored in an image format) - see + Success Criterion 1.4.5: Images of Text. + +

+

This requirement applies to situations in which images of text were intended to be + understood as text. Incidental text, such as in photographs that happen to include + a street sign, are not included. Nor is text that for some reason is designed to be + invisible to all viewers. Stylized text, such as in corporate logos, should be treated + in terms of its function on the page, which may or may not warrant including the content + in the text alternative. Corporate visual guidelines beyond logo and logotype are + not included in the exception. + + +

+

In this provision there is an exception that reads "that are part of a picture that + contains significant other visual content,". This exception is intended to separate + pictures that have text in them from images of text that are done to replace text + in order to get a particular look. + +

+
+

Note

+
+ + +

Images of text do not scale as well as text because they tend to pixelate. It is also + harder to change foreground and background contrast and color combinations for images + of text, which is necessary for some users. See 1.4.5: Images of Text. + + +

+ + +
+
+

This Success Criterion applies to text in the page, including + placeholder text and text that is shown when a pointer is hovering over an object + or when an object has keyboard focus. If any of these are used in a page, the text + needs to provide sufficient contrast. + +

+

Although this Success Criterion only applies to text, similar issues occur for content + presented + in charts, graphs, diagrams, and other non-text-based information, which is covered + by + Success Criterion 1.4.11 Non-Text Contrast. + +

+
+ + +

Rationale for the Ratios Chosen

+ + +

A contrast ratio of 3:1 is the minimum level recommended by [[ISO-9241-3]] and [[ANSI-HFES-100-1988]] + for standard text and vision. The 4.5:1 ratio is used in Success Criterion 1.4.3 to + account + for the loss in contrast that results from moderately low visual acuity, congenital + or acquired color deficiencies, or the loss of contrast sensitivity that typically + accompanies aging. + +

+ + +

The rationale is based on a) adoption of the 3:1 contrast ratio for minimum acceptable + contrast for normal observers, in the ANSI standard, and b) the empirical finding + that in the population, visual acuity of 20/40 is associated with a contrast sensitivity + loss of roughly 1.5 [[ARDITI-FAYE]]. A user with 20/40 would thus require a contrast + ratio of + 3 * 1.5 = 4.5 to 1. Following analogous empirical findings and the same logic, + the user with 20/80 visual acuity would require contrast of about 7:1. This ratio + is used in + this Success Criterion. + +

+ + +

Hues are perceived differently by users with color vision deficiencies (both congenital + and acquired) resulting in different colors and relative luminance contrasts than + for normally sighted users. Because of this, effective contrast and readability are + different for this population. However, color deficiencies are so diverse that prescribing + effective general use color pairs (for contrast) based on quantitative data is not + feasible. Requiring good luminance contrast accommodates this by requiring contrast + that is independent of color perception. Fortunately, most of the luminance contribution + is from the mid and long wave receptors which largely overlap in their spectral responses. + The result is that effective luminance contrast can generally be computed without + regard to specific color deficiency, except for the use of predominantly long wavelength + colors against darker colors (generally appearing black) for those who have protanopia. + (We provide an advisory technique on avoiding red on black for that reason). For more + information see [[ARDITI-KNOBLAUCH-1994]] + [[ARDITI-KNOBLAUCH-1996]] + [[ARDITI]]. + +

+ + +
+

Note

+
+ + +

Some people with cognitive disabilities require color combinations or hues that have + low contrast, and therefore we allow and encourage authors to provide mechanisms to + adjust the foreground and background colors of the content. Some of the combinations + that could be chosen may have contrast levels that will be lower than those + specified here. This is not a violation of this Success Criterion, provided + there is a mechanism that will return to the required values set out here. + +

+ + +
+
+ + +

The contrast ratio of 4.5:1 was chosen for level AA because it compensated for the + loss in contrast sensitivity usually experienced by users with vision loss equivalent + to approximately 20/40 vision. (20/40 calculates to approximately 4.5:1.) 20/40 is + commonly reported as typical visual acuity of elders at roughly age 80. [[GITTINGS-FOZARD]] + + +

+ + +

The contrast ratio of 7:1 was chosen for level AAA because it compensated for the + loss in contrast sensitivity usually experienced by users with vision loss equivalent + to approximately 20/80 vision. People with more than this degree of vision loss usually + use assistive technologies to access their content (and the assistive technologies + usually have contrast enhancing, as well as magnification capability built into them). + The 7:1 level therefore generally provides compensation for the loss in contrast sensitivity + experienced by users with low vision who do not use assistive technology and provides + contrast enhancement for color deficiency as well. + +

+ + +
+

Note

+
+ +

Calculations in [[ISO-9241-3]] and [[ANSI-HFES-100-1988]] are for body text. A relaxed + contrast + ratio is provided for text that is much larger. +

+ +
+
+ + +
+
+ + +

Notes on formula

+ + +

Conversion from nonlinear to linear RGB values is based on IEC/4WD 61966-2-1 [[IEC-4WD]].

+ + +

The formula (L1/L2) for contrast is based on [[ISO-9241-3]] and [[ANSI-HFES-100-1988]] standards. +

+ + +

The ANSI/HFS 100-1988 standard calls for the contribution from ambient light to be + included in the calculation of L1 and L2. The .05 value used is based on Typical Viewing + Flare from [[IEC-4WD]]. + +

+ + +

This Success Criterion and its definitions use the terms "contrast ratio" and "relative + luminance" rather than "luminance" to reflect the fact that Web content does not emit + light itself. The contrast ratio gives a measure of the relative luminance that would + result when displayed. (Because it is a ratio, it is dimensionless.) + +

+ + +
+

Note

+
+ +

+ Refer to + related resources for a list of tools that utilize the contrast ratio + to analyze the contrast of Web content. + +

+ +

See also + 2.4.7: Focus Visible for techniques for indicating keyboard focus. + +

+ +
+
+ + +
+
+ +

Inactive User Interface Components

+ + +

User Interface Components that are not available for user interaction (e.g., a disabled + control in HTML) are not required to meet contrast requirements. An inactive user + interface component is visible but not currently operable. An example would be a submit + button at the bottom of a form that is visible but cannot be activated until all the + required fields in the form are completed. +

+ +
+ Grey button with non-contrasting grey text. + +
Figure 1 An inactive button using default browser styles
+ +
+ +
+
+
+

Benefits

+
    + + +
  • People with low vision often have difficulty reading text that does not contrast with + its background. This can be exacerbated if the person has a color vision deficiency + that lowers the contrast even further. Providing a minimum luminance contrast ratio + between the text and its background can make the text more readable even if the person + does not see the full range of colors. It also works for the rare individuals who + see no color. + +
    • + + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: text is less than 18 point if not bold and less than 14 point if bold

+ + + + + +
+
+ + +

Situation B: text is as least 18 point if not bold and at least 14 point if bold

+ + + + + +
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
contrast ratio
+
+ + + +

(L1 + 0.05) / (L2 + 0.05), where

+ + + + + +
+

Note

+

Contrast ratios can range from 1 to 21 (commonly written 1:1 to 21:1).

+
+ + +
+

Note

+

Because authors do not have control over user settings as to how text is rendered + (for example font smoothing or anti-aliasing), the contrast ratio for text can be + evaluated with anti-aliasing turned off. + +

+
+ + +
+

Note

+

For the purpose of Success Criteria 1.4.3 and 1.4.6, contrast is measured with respect + to the specified background over which the text is rendered in normal usage. If no + background color is specified, then white is assumed. + +

+
+ + +
+

Note

+

Background color is the specified color of content over which the text is to be rendered + in normal usage. It is a failure if no background color is specified when the text + color is specified, because the user's default background color is unknown and cannot + be evaluated for sufficient contrast. For the same reason, it is a failure if no text + color is specified when a background color is specified. + +

+
+ + +
+

Note

+

When there is a border around the letter, the border can add contrast and would be + used in calculating the contrast between the letter and its background. A narrow border + around the letter would be used as the letter. A wide border around the letter that + fills in the inner details of the letters acts as a halo and would be considered background. + +

+
+ + +
+

Note

+

WCAG conformance should be evaluated for color pairs specified in the content that + an author would expect to appear adjacent in typical presentation. Authors need not + consider unusual presentations, such as color changes made by the user agent, except + where caused by authors' code. + +

+
+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
image of text
+
+ + + +

text that has been rendered in a non-text form (e.g., an image) in order to achieve + a particular visual effect + +

+ + +
+

Note

+

This does not include text that is part of a picture that contains significant other visual content. + +

+
+ + + + + + +
+
large scale
+
+ + + +

with at least 18 point or 14 point bold or font size that would yield equivalent size + for Chinese, Japanese and Korean (CJK) fonts + +

+ + +
+

Note

+

Fonts with extraordinarily thin strokes or unusual features and characteristics that + reduce the familiarity of their letter forms are harder to read, especially at lower + contrast levels. + +

+
+ + +
+

Note

+

Font size is the size when the content is delivered. It does not include resizing + that may be done by a user. + +

+
+ + +
+

Note

+

The actual size of the character that a user sees is dependent both on the author-defined + size and the user's display or user agent settings. For many mainstream body text + fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% + of the default size for body text (assuming that the body font is 100%), but authors + would need to check this for the particular fonts in use. When fonts are defined in + relative units, the actual point size is calculated by the user agent for display. + The point size should be obtained from the user agent, or calculated based on font + metrics as the user agent does, when evaluating this success criterion. Users who + have low vision would be responsible for choosing appropriate settings. + +

+
+ + +
+

Note

+

When using text without specifying the font size, the smallest font size used on major + browsers for unspecified text would be a reasonable size to assume for the font. If + a level 1 heading is rendered in 14pt bold or higher on major browsers, then it would + be reasonable to assume it is large text. Relative scaling can be calculated from + the default sizes in a similar fashion. + +

+
+ + +
+

Note

+

The 18 and 14 point sizes for roman texts are taken from the minimum size for large + print (14pt) and the larger standard font size (18pt). For other fonts such as CJK + languages, the "equivalent" sizes would be the minimum large print size used for those + languages and the next larger standard large print size. + +

+
+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
pure decoration
+
+ + + +

serving only an aesthetic purpose, providing no information, and having no functionality

+ + +
+

Note

+

Text is only purely decorative if the words can be rearranged or substituted without + changing their purpose. + +

+
+ + + + + + +
+
relative luminance
+
+ + + +

the relative brightness of any point in a colorspace, normalized to 0 for darkest + black and 1 for lightest white + +

+ + +
+

Note

+
+ +

For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 + * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as: + +

+ + +
    + + +
  • if RsRGB <= 0.04045 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
  • if GsRGB <= 0.04045 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
  • if BsRGB <= 0.04045 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
+ + +

and RsRGB, GsRGB, and BsRGB are defined as:

+ + +
    + + +
  • RsRGB = R8bit/255
    • + + +
  • GsRGB = G8bit/255
    • + + +
  • BsRGB = B8bit/255
    • + + +
+ + +

The "^" character is the exponentiation operator. (Formula taken from + [[SRGB]].) + +

+ + +
+
+ + +
+

Note

+

Before May 2021 the value of 0.04045 in the definition was different (0.03928). It + was taken from an older version of the specification and has been updated. It has + no practical effect on the calculations in the context of these guidelines. +

+
+ + +
+

Note

+

Almost all systems used today to view Web content assume sRGB encoding. Unless it + is known that another color space will be used to process and display the content, + authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3. + +

+
+ + +
+

Note

+

If dithering occurs after delivery, then the source color value is used. For colors + that are dithered at the source, the average values of the colors that are dithered + should be used (average R, average G, and average B). + +

+
+ + +
+

Note

+

Tools are available that automatically do the calculations when testing contrast and + flash. + +

+
+ + +
+

Note

+

A separate page giving the relative luminance definition using MathML to display the formulas is available. + +

+
+ + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/contrast-minimum.html b/wcag22/understanding/contrast-minimum.html new file mode 100644 index 0000000..68f23cb --- /dev/null +++ b/wcag22/understanding/contrast-minimum.html @@ -0,0 +1,1411 @@ + + + + + + Understanding Success Criterion 1.4.3: Contrast (Minimum) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.3:Contrast (Minimum) (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Text can be seen by more people.
+ +
What to do
+
Provide sufficient contrast between text and its background.
+ +
Why it's important
+
Some people cannot read faint text.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to provide enough contrast between text and + its background, so that it can be read by people with moderately low vision or impaired + contrast perception, without the use of contrast-enhancing assistive technology. + +

+

For all consumers of visual content, adequate light-dark contrast is needed between + the relative luminance of text and its background for good readability. + Many different visual impairments can substantially impact contrast sensitivity, requiring + more light-dark contrast, regardless of color (hue). + For people who are not able to distinguish certain shades of color (often referred + to as color blindness) hue and saturation have minimal or no effect on legibility as assessed by reading + performance. + Further, the inability to distinguish certain shades of color does not negatively + affect light-dark contrast perception. + Therefore, in the recommendation, contrast is calculated in such a way that color + (hue) is not a key factor. + +

+

Text that is decorative and conveys no information is excluded. For example, if random + words are used to create a background and the words could be rearranged or substituted + without changing meaning, then it would be decorative and would not need to meet this + criterion. + +

+

Text that is larger and has wider character strokes is easier to read at lower contrast. + The contrast requirement for larger text is therefore lower. This allows authors to + use a wider range of color choices for large text, which is helpful for design of + pages, particularly titles. 18 point text or 14 point bold text is judged to be large + enough to require a lower contrast ratio. (See The American Printing House for the + Blind Guidelines for Large Printing and The Library of Congress Guidelines for Large + Print under + Resources). "18 point" and "bold" can both have different meanings in + different fonts but, except for very thin or unusual fonts, they should be sufficient. + Since there + are so many different fonts, the general measures are used and a note regarding thin + or unusual + fonts is included in the definition for large-scale text. + +

+
+

Note

+
+ +

When evaluating this Success Criterion, the font size in points should be obtained + from the user agent or calculated on font metrics in the way that user agents do. + Point sizes are based on the CSS pt size as defined in + CSS3 Values. The ratio between + sizes in points and CSS pixels is 1pt = 1.333px, therefore 14pt + and 18pt are equivalent to approximately 18.5px and 24px. + +

+ +

Because different image editing applications default to different pixel densities + (e.g., 72ppi or 96ppi), specifying point sizes for fonts from within an + image editing application can be unreliable when it comes to presenting text at a + specific size. + When creating images of large-scale text, authors should ensure that the text in the + resulting image is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the + default size for body text. For example, for a 72ppi image, an author would need + to use approximately 19pt and 24pt font sizes in order to successfully present images + of large-scale text to a user. + +

+ +

The 3:1 and 4.5:1 contrast ratios referenced in this Success Criterion are intended + to be + treated as threshold values. When comparing the computed contrast ratio to the Success + Criterion + ratio, the computed values should not be rounded (e.g., 4.499:1 would not meet the + 4.5:1 threshold). +

+ +
+
+
+

Note

+
+ +

Because authors do not have control over user settings for font smoothing/anti-aliasing, + when evaluating this + Success Criterion, refer to the foreground and background colors obtained from the + user agent, or the underlying + markup and stylesheets, rather than the text as presented on screen. +

+ +

Due to anti-aliasing, particularly thin or unusual fonts may be rendered by user agents + with a much fainter + color than the actual text color defined in the underlying CSS. This can lead to situations + where text has + a contrast ratio that nominally passes the Success Criterion, but has a much lower + contrast in practice. + In these cases, best practice would be for authors to choose a font with stronger/thicker + lines, + or to aim for a foreground/background color combination that exceeds the normative + requirements + of this Success Criterion. + +

+ +
+
+

The contrast requirements for text also apply to images of text + (text that has been rendered into pixels and then stored in an image format) - see + Success Criterion 1.4.5: Images of Text. + +

+

This requirement applies to situations in which images of text were intended to be + understood as text. Incidental text, such as in photographs that happen to include + a street sign, are not included. Nor is text that for some reason is designed to be + invisible to all viewers. Stylized text, such as in corporate logos, should be treated + in terms of its function on the page, which may or may not warrant including the content + in the text alternative. Corporate visual guidelines beyond logo and logotype are + not included in the exception. + + +

+

In this provision there is an exception that reads "that are part of a picture that + contains significant other visual content,". This exception is intended to separate + pictures that have text in them from images of text that are done to replace text + in order to get a particular look. + +

+
+

Note

+
+ + +

Images of text do not scale as well as text because they tend to pixelate. It is also + harder to change foreground and background contrast and color combinations for images + of text, which is necessary for some users. Therefore, we suggest using text wherever + possible, and when not, consider supplying an image of higher resolution. + + +

+ + +
+
+

This Success Criterion applies to text in the page, including + placeholder text and text that is shown when a pointer is hovering over an object + or when an object has keyboard focus. If any of these are used in a page, the text + needs to provide sufficient contrast. + +

+

Although this Success Criterion only applies to text, similar issues occur for content + presented + in charts, graphs, diagrams, and other non-text-based information, which is covered + by + Success Criterion 1.4.11 Non-Text Contrast. + +

+

See also + 1.4.6: Contrast (Enhanced). + +

+
+ + +

Rationale for the Ratios Chosen

+ + +

A contrast ratio of 3:1 is the minimum level recommended by [[ISO-9241-3]] and [[ANSI-HFES-100-1988]] + for standard text and vision. The 4.5:1 ratio is used in this Success Criterion to + account + for the loss in contrast that results from moderately low visual acuity, congenital + or acquired color deficiencies, or the loss of contrast sensitivity that typically + accompanies aging. + +

+ + +

The rationale is based on a) adoption of the 3:1 contrast ratio for minimum acceptable + contrast for normal observers, in the ANSI standard, and b) the empirical finding + that in the population, visual acuity of 20/40 is associated with a contrast sensitivity + loss of roughly 1.5 [[ARDITI-FAYE]]. A user with 20/40 would thus require a contrast + ratio of + 3 * 1.5 = 4.5 to 1. Following analogous empirical findings and the same logic, + the user with 20/80 visual acuity would require contrast of about 7:1. This ratio + is used in + Success Criterion 1.4.6. + +

+ + +

Hues are perceived differently by users with color vision deficiencies (both congenital + and acquired) resulting in different colors and relative luminance contrasts than + for normally sighted users. Because of this, effective contrast and readability are + different for this population. However, color deficiencies are so diverse that prescribing + effective general use color pairs (for contrast) based on quantitative data is not + feasible. Requiring good luminance contrast accommodates this by requiring contrast + that is independent of color perception. Fortunately, most of the luminance contribution + is from the mid and long wave receptors which largely overlap in their spectral responses. + The result is that effective luminance contrast can generally be computed without + regard to specific color deficiency, except for the use of predominantly long wavelength + colors against darker colors (generally appearing black) for those who have protanopia. + (We provide an advisory technique on avoiding red on black for that reason). For more + information see [[ARDITI-KNOBLAUCH-1994]] + [[ARDITI-KNOBLAUCH-1996]] + [[ARDITI]]. + +

+ + +
+

Note

+
+ + +

Some people with cognitive disabilities require color combinations or hues that have + low contrast, and therefore we allow and encourage authors to provide mechanisms to + adjust the foreground and background colors of the content. Some of the combinations + that could be chosen may have contrast levels that will be lower than those those + specified here. This is not a violation of this Success Criterion, provided + there is a mechanism that will return to the required values set out here. + +

+ + +
+
+ + +

The contrast ratio of 4.5:1 was chosen for level AA because it compensated for the + loss in contrast sensitivity usually experienced by users with vision loss equivalent + to approximately 20/40 vision. (20/40 calculates to approximately 4.5:1.) 20/40 is + commonly reported as typical visual acuity of elders at roughly age 80. [[GITTINGS-FOZARD]] + + +

+ + +

The contrast ratio of 7:1 was chosen for level AAA because it compensated for the + loss in contrast sensitivity usually experienced by users with vision loss equivalent + to approximately 20/80 vision. People with more than this degree of vision loss usually + use assistive technologies to access their content (and the assistive technologies + usually have contrast enhancing, as well as magnification capability built into them). + The 7:1 level therefore generally provides compensation for the loss in contrast sensitivity + experienced by users with low vision who do not use assistive technology and provides + contrast enhancement for color deficiency as well. + +

+ + +
+

Note

+
+ +

Calculations in [[ISO-9241-3]] and [[ANSI-HFES-100-1988]] are for body text. A relaxed + contrast + ratio is provided for text that is much larger. +

+ +
+
+ + +
+
+ + +

Notes on formula

+ + +

Conversion from nonlinear to linear RGB values is based on IEC/4WD 61966-2-1 [[IEC-4WD]].

+ + +

The formula (L1/L2) for contrast is based on [[ISO-9241-3]] and [[ANSI-HFES-100-1988]] standards. +

+ + +

The ANSI/HFS 100-1988 standard calls for the contribution from ambient light to be + included in the calculation of L1 and L2. The .05 value used is based on Typical Viewing + Flare from [[IEC-4WD]]. + +

+ + +

This Success Criterion and its definitions use the terms "contrast ratio" and "relative + luminance" rather than "luminance" to reflect the fact that Web content does not emit + light itself. The contrast ratio gives a measure of the relative luminance that would + result when displayed. (Because it is a ratio, it is dimensionless.) + +

+ + +
+

Note

+
+ +

+ Refer to + related resources for a list of tools that utilize the contrast ratio + to analyze the contrast of Web content. + +

+ +

See also + 2.4.7: Focus Visible for techniques for indicating keyboard focus. + +

+ +
+
+ + +
+
+ +

Inactive User Interface Components

+ + +

User Interface Components that are not available for user interaction (e.g., a disabled + control in HTML) are not required to meet contrast requirements. An inactive user + interface component is visible but not currently operable. An example would be a submit + button at the bottom of a form that is visible but cannot be activated until all the + required fields in the form are completed. +

+ +
+ Grey button with non-contrasting grey text. + +
Figure 1 An inactive button using default browser styles
+ +
+ +
+
+
+

Benefits

+
    + + +
  • People with low vision often have difficulty reading text that does not contrast with + its background. This can be exacerbated if the person has a color vision deficiency + that lowers the contrast even further. Providing a minimum luminance contrast ratio + between the text and its background can make the text more readable even if the person + does not see the full range of colors. It also works for the rare individuals who + see no color. + +
    • + + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: text is less than 18 point if not bold and less than 14 point if bold

+ + + + + +
+
+ + +

Situation B: text is at least 18 point if not bold and at least 14 point if bold

+ + + + + +
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
contrast ratio
+
+ + + +

(L1 + 0.05) / (L2 + 0.05), where

+ + + + + +
+

Note

+

Contrast ratios can range from 1 to 21 (commonly written 1:1 to 21:1).

+
+ + +
+

Note

+

Because authors do not have control over user settings as to how text is rendered + (for example font smoothing or anti-aliasing), the contrast ratio for text can be + evaluated with anti-aliasing turned off. + +

+
+ + +
+

Note

+

For the purpose of Success Criteria 1.4.3 and 1.4.6, contrast is measured with respect + to the specified background over which the text is rendered in normal usage. If no + background color is specified, then white is assumed. + +

+
+ + +
+

Note

+

Background color is the specified color of content over which the text is to be rendered + in normal usage. It is a failure if no background color is specified when the text + color is specified, because the user's default background color is unknown and cannot + be evaluated for sufficient contrast. For the same reason, it is a failure if no text + color is specified when a background color is specified. + +

+
+ + +
+

Note

+

When there is a border around the letter, the border can add contrast and would be + used in calculating the contrast between the letter and its background. A narrow border + around the letter would be used as the letter. A wide border around the letter that + fills in the inner details of the letters acts as a halo and would be considered background. + +

+
+ + +
+

Note

+

WCAG conformance should be evaluated for color pairs specified in the content that + an author would expect to appear adjacent in typical presentation. Authors need not + consider unusual presentations, such as color changes made by the user agent, except + where caused by authors' code. + +

+
+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
image of text
+
+ + + +

text that has been rendered in a non-text form (e.g., an image) in order to achieve + a particular visual effect + +

+ + +
+

Note

+

This does not include text that is part of a picture that contains significant other visual content. + +

+
+ + + + + + +
+
large scale
+
+ + + +

with at least 18 point or 14 point bold or font size that would yield equivalent size + for Chinese, Japanese and Korean (CJK) fonts + +

+ + +
+

Note

+

Fonts with extraordinarily thin strokes or unusual features and characteristics that + reduce the familiarity of their letter forms are harder to read, especially at lower + contrast levels. + +

+
+ + +
+

Note

+

Font size is the size when the content is delivered. It does not include resizing + that may be done by a user. + +

+
+ + +
+

Note

+

The actual size of the character that a user sees is dependent both on the author-defined + size and the user's display or user agent settings. For many mainstream body text + fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% + of the default size for body text (assuming that the body font is 100%), but authors + would need to check this for the particular fonts in use. When fonts are defined in + relative units, the actual point size is calculated by the user agent for display. + The point size should be obtained from the user agent, or calculated based on font + metrics as the user agent does, when evaluating this success criterion. Users who + have low vision would be responsible for choosing appropriate settings. + +

+
+ + +
+

Note

+

When using text without specifying the font size, the smallest font size used on major + browsers for unspecified text would be a reasonable size to assume for the font. If + a level 1 heading is rendered in 14pt bold or higher on major browsers, then it would + be reasonable to assume it is large text. Relative scaling can be calculated from + the default sizes in a similar fashion. + +

+
+ + +
+

Note

+

The 18 and 14 point sizes for roman texts are taken from the minimum size for large + print (14pt) and the larger standard font size (18pt). For other fonts such as CJK + languages, the "equivalent" sizes would be the minimum large print size used for those + languages and the next larger standard large print size. + +

+
+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
pure decoration
+
+ + + +

serving only an aesthetic purpose, providing no information, and having no functionality

+ + +
+

Note

+

Text is only purely decorative if the words can be rearranged or substituted without + changing their purpose. + +

+
+ + + + + + +
+
relative luminance
+
+ + + +

the relative brightness of any point in a colorspace, normalized to 0 for darkest + black and 1 for lightest white + +

+ + +
+

Note

+
+ +

For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 + * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as: + +

+ + +
    + + +
  • if RsRGB <= 0.04045 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
  • if GsRGB <= 0.04045 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
  • if BsRGB <= 0.04045 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
+ + +

and RsRGB, GsRGB, and BsRGB are defined as:

+ + +
    + + +
  • RsRGB = R8bit/255
    • + + +
  • GsRGB = G8bit/255
    • + + +
  • BsRGB = B8bit/255
    • + + +
+ + +

The "^" character is the exponentiation operator. (Formula taken from + [[SRGB]].) + +

+ + +
+
+ + +
+

Note

+

Before May 2021 the value of 0.04045 in the definition was different (0.03928). It + was taken from an older version of the specification and has been updated. It has + no practical effect on the calculations in the context of these guidelines. +

+
+ + +
+

Note

+

Almost all systems used today to view Web content assume sRGB encoding. Unless it + is known that another color space will be used to process and display the content, + authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3. + +

+
+ + +
+

Note

+

If dithering occurs after delivery, then the source color value is used. For colors + that are dithered at the source, the average values of the colors that are dithered + should be used (average R, average G, and average B). + +

+
+ + +
+

Note

+

Tools are available that automatically do the calculations when testing contrast and + flash. + +

+
+ + +
+

Note

+

A separate page giving the relative luminance definition using MathML to display the formulas is available. + +

+
+ + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/distinguishable.html b/wcag22/understanding/distinguishable.html new file mode 100644 index 0000000..5594d67 --- /dev/null +++ b/wcag22/understanding/distinguishable.html @@ -0,0 +1,206 @@ + + + + + + Understanding Guideline 1.4: Distinguishable | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 1.4:Distinguishable +

+ +
+
+

Intent

+

While some guidelines are focused on making information available in a form that can + be presented in alternate formats, this guideline is concerned with making the default + presentation as easy to perceive as possible to people with disabilities. The primary + focus is on making it easier for users to separate foreground information from the + background. For visual presentations this involves making sure that information presented + on top of a background contrasts sufficiently with the background. For audio presentations + this involves making sure that foreground sounds are sufficiently louder than the + background sounds. Individuals with visual and hearing disabilities have much greater + difficulty separating foreground and background information. + +

+
+
+

Success Criteria for this Guideline

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/documenting-accessibility-support.html b/wcag22/understanding/documenting-accessibility-support.html new file mode 100644 index 0000000..3441379 --- /dev/null +++ b/wcag22/understanding/documenting-accessibility-support.html @@ -0,0 +1,306 @@ + + + + + + Documenting Accessibility Support for Uses of a Web Technology | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Documenting Accessibility Support for Uses of a Web Technology

+
+ + +

The documentation of accessibility support for uses of a Web technology provides the + information needed to determine whether it is possible to satisfy the WCAG 2.1 Success + Criteria for a particular environment. +

+ +

Accessibility Support documentation for uses of a Web technology includes the following + information: +

+ +
    + +
  • + +

    The version or versions of the technology

    + +
    • + +
  • + +

    For each user agent or plug-in that supports this version of the technology:

    + +
      + +
    • + +

      The version of the user agent or plug-in, including the operating system or platform + +

      + +
      • + +
    • + +

      Ways of using the technology that are supported by the user agent; ideally, there + are ways to meet all of the success criteria, but exceptions should be noted. +

      + +
      • + +
    • + +

      Known limitations of the user agent support for uses of the technology to meet Success + Criteria +

      + +
      • + +
    + +
    • + +
  • + +

    For each assistive technology that supports the Web technology:

    + +
      + +
    • + +

      The version of the assistive technology, including the operating system or platform + +

      + +
      • + +
    + +
    • + +
  • + +

    For each host user agent that is supported by this version of the assistive technology:

    + +
      + +
    • + +

      Ways of using the technology supported by the assistive technology for this user + agent +

      + +
      • + +
    • + +

      Known limitations in the support of uses of the technology to meet success criteria + when using the assistive technology with this user agent +

      + +
      • + +
    + +
    • + +
+ +

Target environments are defined by the user agents and assistive technologies available + to its users. Documentation of accessibility support involves detailed understanding + of the ways to use functionality of a technology to meet success criteria, and also + of user agents and assistive technology. Because of this, vendors and developers of + Web technologies and user agents are encouraged to provide this information about + the accessibility support of their products. Similarly, developers and vendors of + assistive technology are encouraged to provide this information about the ways to + use Web technologies that are supported by their products. Authors should need to + document the accessibility supported ways to use a technology only when there is not + reliable documentation available from vendors or testing groups for those uses. +

+ +

For a controlled environment, such as a corporate workplace, the user agents and assistive + technologies available may be a specific set of versions of user agents on a specific + set of platforms. To determine whether uses of a Web technology are accessibility + supported in a target environment, an author checks that the user agents and assistive + technologies available are in the set of supported user agents and assistive technologies + listed for those uses in the Accessibility Support documentation. +

+ +

For a target environment like the Internet, authors may need to consider a much larger + set of user agents, including older versions, and on a wider variety of platforms. + +

+ +

Environments that use different natural languages are different target environments. + For example, the accessibility-supported ways of using technologies for an English + language environment may differ from those for an Arabic language environment, since + there may be different user agents and assistive technologies that support these languages. +

+ +

The documentation includes version-specific information about all the assistive technologies + and all the user agents and the ways that they interact with one another. If support + in these user agents is similar, it will be straightforward for an author to decide + if a documented way of using a technology is accessibility supported. If the uses + supported are different in different versions, authors can only rely on the uses that + are supported in the versions available to their users in determining accessibility + support. +

+ +

If a way of using a technology is not relied upon for conformance, the absence of + accessibility support for that use does not prevent conformance of the Web page. So + if the unsupported use does not occur in the content, or if there is a conforming + version of that content available, the Web page still conforms. For instance, lack + of accessibility support for interactive controls in a Web technology would not prevent + uses of the Web technology for non-interactive content that are accessibility supported. + +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/dragging-movements.html b/wcag22/understanding/dragging-movements.html new file mode 100644 index 0000000..a68aebe --- /dev/null +++ b/wcag22/understanding/dragging-movements.html @@ -0,0 +1,626 @@ + + + + + + Understanding Success Criterion 2.5.7: Dragging Movements | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.5.7:Dragging Movements (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Don’t rely on dragging for user actions.
+ +
What to do
+
For any action that involves dragging, provide a simple pointer alternative.
+ +
Why it's important
+
Some people cannot use a mouse to drag items.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure functionality that uses a dragging + movement has another single pointer mode of operation without the need for the dexterity required to drag elements. +

+

Some people cannot perform dragging movements in a precise manner. Others use a specialized + or adapted input device, such as a trackball, head pointer, eye-gaze system, or speech-controlled + mouse emulator, which may make dragging cumbersome and error-prone. +

+

When an interface implements functionality that uses dragging movements, users perform + four discrete actions: +

+
    + +
  1. tap or click to establish a starting point, then
    2. + +
  2. press and hold that contact while...
    3. + +
  3. performing a repositioning of the pointer, before...
    4. + +
  4. releasing the pointer at the end point.
    5. + +
+

Not all users can accurately press and hold that contact while also repositioning + the pointer. An alternative method must be provided so that users with mobility impairments + who use a pointer (mouse, pen, or touch contact) can use the functionality. +

+

This requirement is separate from keyboard accessibility because people using a touch + screen device may not use a physical keyboard. Keyboard specific interactions such + as tabbing or arrow keys may not be possible when encountering a drag and drop control. + Note, however, that providing a text input can be an acceptable single-pointer alternative + to dragging. For example, an input beside a slider could allow any user to enter a + precise value for the slider. In such a situation, the on-screen keyboard that appears + for touch users offers a single-pointer means of entering an alphanumeric value. +

+

This criterion does not apply to scrolling enabled by the user-agent. Scrolling a + page is not in scope, nor is using a technique such as CSS overflow to make a section of content scrollable. +

+
+ + +

Relationship to other requirements

+ + +

Success Criteria 2.1.1 Keyboard and 2.1.3 Keyboard (No Exception) require dragging + features to be keyboard accessible. However, achieving keyboard equivalence for a + dragging operation does not automatically meet this Success Criterion. It is possible + to create an interface that works with dragging and keyboard controls that does not + work using only clicks or taps. While many designs can be created for a dragging alternative + which address both keyboard accessibility and operability by single pointer operation, + the two requirements should be assessed independently. +

+ + +

This Success Criterion applies to dragging movements as opposed to pointer gestures, + which are covered in Success Criterion 2.5.1 Pointer Gestures. Pointer gestures include directional path-based as well as multi-point gestures. + In contrast, for dragging movements, only the start and end point of the movement + matters, not the actual path. +

+ + +

Additional examples are selection rectangles that set the first x/y rectangle coordinate + at the pointer position via a pointer down-event, and the second x/y coordinate, after + a dragging movement, at the next up-event. A similar example is a connecting line + drawn between two different items on the screen, as in an allocation test where users + are required to draw a line between questions and corresponding answers. In these + cases, the dragging movement requires an alternative way to accomplish the same action + that does not rely on the dragging movement. For example, two separate single tap + or click actions may define the rectangle coordinates or the start and end points + of a connecting line. +

+ + +
+
+ +

Alternatives for dragging movements on the same page

+ + +

Where functionality can be executed via dragging movements and an equivalent option + exists that allows for single-pointer access without dragging, this Success Criterion + is passed. It does not have to be the same component, so long as the functionality + is equivalent. An example is a color wheel where a color can be changed by dragging + an indicator. In addition, text fields for the numerical input of color values allow + the definition of a color without requiring dragging movements. (Note that a text + input is considered device agnostic; although the purpose is to enter characters, + text entry can take place through voice, pointer or keyboard.) +

+ + +
+
+ +

Distinguishing dragging movements from path-based pointer gestures

+ + +

Dragging movements covered in this Success Criterion are pointer interactions where + only the start- and endpoints matter. Once the pointer engages with a target, the + direction of the dragging movement does not factor into the interaction until the + pointer disengages the target. Since the dragging movement does not have an intermediate + point, the dragging movement can go in any direction. Path-based gestures are covered + in Success Criterion 2.5.1 Pointer Gestures. For more details, refer to Understanding Success Criterion 2.5.1 Pointer Gestures

+ + +
+
+
+

Benefits

+
    + +
  • Users who struggle with performing dragging movements can still operate an interface + with a pointer interface. +
    • + +
+
+
+

Examples

+
    + +
  • A map allows users to drag the view of the map around, and the map has up/down/left/right + buttons to move the view as well. +
    • + +
  • A sortable list of elements may, after tapping or clicking on a list element, provide + adjacent controls for moving the element up or down in the list by simply tapping + or clicking on those controls. +
    • + +
  • A taskboard that allows users to drag and drop items between columns also provides + an additional pop-up menu after tapping or clicking on items for moving the selected + element to another column by tapping or clicking on pop-up menu entries. +
    • + +
  • A radial control widget (color wheel) where the value can be set by dragging the marker + for the currently selected color to another position, also allows picking another + color value by tapping or clicking on another place in the color wheel. +
    • + +
  • A linear slider control widget, where the value can be set by dragging the visual + indicator (thumb) showing the current value, allows tapping or clicking on any point + of the slider track to change the value and set the thumb to that position. +
    • + +
  • A widget where you can drag a gift to one person in a photo of a group of people also + has a menu alternative where users can select the person that should receive the gift + from the menu. +
    • + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+
    + +
  1. + G219: Ensuring that an alternative is available for dragging movements that operate on content + +
    2. + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
down-event
+
+ + +

platform event that occurs when the trigger stimulus of a pointer is depressed

+ +

The down-event may have different names on different platforms, such as "touchstart" + or "mousedown". +

+ + +
+
dragging movement
+
+ + + + +

an operation where the pointer engages with an element on the down-event and the element (or a representation of its position) follows the pointer until an + up-event + +

+ + +
+

Note

+

Examples of draggable elements include list items, text elements, and images.

+
+ + +
+
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
functionality
+
+ + + +

+ processes and outcomes achievable through user action + +

+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
single pointer
+
+ + + +

pointer input that operates with one point of contact with the screen, including single + taps and clicks, double-taps and clicks, long presses, and path-based gestures +

+ + + +
+
up-event
+
+ + +

platform event that occurs when the trigger stimulus of a pointer is released

+ +

The up-event may have different names on different platforms, such as "touchend" or + "mouseup". +

+ + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/enough-time.html b/wcag22/understanding/enough-time.html new file mode 100644 index 0000000..522a570 --- /dev/null +++ b/wcag22/understanding/enough-time.html @@ -0,0 +1,196 @@ + + + + + + Understanding Guideline 2.2: Enough Time | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 2.2:Enough Time +

+ +
+
+

Intent

+

Many users who have disabilities need more time to complete tasks than the majority + of users: they may take longer to physically respond, they may take longer to read + things, they may have low vision and take longer to find things or to read them, or + they may be accessing content through an assistive technology that requires more time. + This guideline focuses on ensuring that users are able to complete the tasks required + by the content with their own individual response times. The primary approaches deal + with eliminating time constraints or providing users enough additional time to allow + them to complete their tasks. Exceptions are provided for those cases where this is + not possible. + +

+
+
+

Success Criteria for this Guideline

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/error-identification.html b/wcag22/understanding/error-identification.html new file mode 100644 index 0000000..b6a592a --- /dev/null +++ b/wcag22/understanding/error-identification.html @@ -0,0 +1,768 @@ + + + + + + Understanding Success Criterion 3.3.1: Error Identification | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.3.1:Error Identification (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users know an error exists and what is wrong.
+ +
What to do
+
Provide descriptive notification of errors.
+ +
Why it's important
+
Flagging errors helps people with reduced sight and cognitive disabilities resolve + them. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that users are aware that an error + has occurred and can determine what is wrong. The error message should be as specific + as possible. + In the case of an unsuccessful form submission, re-displaying the form and indicating + the fields in error is insufficient for some users to perceive that an error has occurred. + Screen reader users, for example, will not know there was an error until they encounter + one of the indicators. They may abandon the form altogether before encountering the + error indicator, thinking that the page simply is not functional. Per the definition + in WCAG 2.0, an "input error" is information provided by the user + that is not accepted. This includes: + +

+
    + + +
  • information that is required by the web page but omitted by the user, or
    • + + +
  • information that is provided by the user but that falls outside the required data + format or allowed values. + +
    • + + +
+

For example:

+
    + + +
  • the user fails to enter the proper abbreviation in to state, province, region, etc. + field; + +
    • + + +
  • the user enters a state abbreviation that is not a valid state;
    • + + +
  • the user enters a non existent zip or postal code;
    • + + +
  • the user enters a birth date 2 years in the future;
    • + + +
  • the user enters alphabetic characters or parentheses into their phone number field + that only accepts numbers; + +
    • + + +
  • the user enters a bid that is below the previous bid or the minimum bid increment.
    • + + +
+
+

Note

+
+ + +

If a user enters a value that is too high or too low, and the coding on the page automatically + changes that value to fall within the allowed range, the user's error would still + need to be described to them as required by the success criterion. Such an error description + telling the person of the changed value would meet both this success criterion (Error + Identification) and + Success Criterion 3.3.3 (Error Suggestion). + +

+ + +
+
+

The identification and description of an error can be combined with programmatic information + that user agents or assistive technologies can use to identify an error and provide + error information to the user. For example, certain technologies can specify that + the user's input must not fall outside a specific range, or that a form field is required. + Currently, few technologies support this kind of programmatic information, but the + Success Criterion does not require, nor prevent it. + + +

+

It is perfectly acceptable to indicate the error in other ways such as image, color + etc, in addition to the text description. + + +

+

See also + 3.3.3: Error Suggestion. + +

+
+
+

Benefits

+
    + + +
  • Providing information about input errors in text allows users who are blind or colorblind + to perceive the fact that an error occurred. + +
    • + + +
  • + This Success Criterion may help people with cognitive, language, and learning disabilities + who have difficulty understanding the meaning represented by icons and other visual + cues. + + + +
    • + + +
+
+
+

Examples

+
+ +
Identifying errors in a form submission
+ +
+ +

An airline Web site offers a special promotion on discounted flights. The user is + asked to complete a simple form that asks for personal information such as name, address, + phone number, seating preference and e-mail address. If any of the fields of the form + are either not completed or completed incorrectly, an alert is displayed notifying + the user which field or fields were missing or incorrect. +

+ + +
+

Note

+
+ +

This Success Criterion does not mean that color or text styles cannot be used to indicate + errors. It simply requires that errors also be identified using text. In this example, + two asterisks are used in addition to color. + +

+ +
+
+ +
+ +
Providing multiple cues
+ +
The user fails to fill in two fields on the form. In addition to describing the error + and providing a unique character to make it easy to search for the fields, the fields + are highlighted in yellow to make it easier to visually search for them as well. +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If a form contains fields for which information from the user is mandatory.

+ + + + + +
+
+ + +

Situation B: If information provided by the user is required to be in a specific data + format or of certain values. + +

+ + + + + +
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
input error
+
+ + + +

information provided by the user that is not accepted

+ + +
+

Note

+
+ +

This includes:

+ + +
    + + +
  1. Information that is required by the Web page but omitted by the user + +
    2. + + +
  2. Information that is provided by the user but that falls outside the required data + format or values + +
    3. + + +
+ +
+
+ + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/error-prevention-all.html b/wcag22/understanding/error-prevention-all.html new file mode 100644 index 0000000..a930c06 --- /dev/null +++ b/wcag22/understanding/error-prevention-all.html @@ -0,0 +1,468 @@ + + + + + + Understanding Success Criterion 3.3.6: Error Prevention (All) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.3.6:Error Prevention (All) (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can avoid submitting incorrect information.
+ +
What to do
+
Provide ways for users to confirm, correct, or reverse any submissions.
+ +
Why it's important
+
People with disabilities may be more likely to make mistakes, or not notice them.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to help users with disabilities avoid consequences + that may result from making a mistake when submitting form data. This criterion builds + on + Success Criterion 3.3.4 in that it applies to all forms that require users to submit information. + +

+

Users with disabilities may be more likely to make mistakes and may have more difficulty + detecting or recovering from mistakes. People with reading disabilities may transpose + numbers and letters, and those with motor disabilities may hit keys by mistake. Providing + the ability to reverse actions allows users to correct a mistake. Providing the ability + to review and correct information gives the user an opportunity to detect a mistake + before taking an action. + +

+
+
+

Benefits

+
    + + +
  • + Providing safeguards to avoid consequences resulting from mistakes helps users with + all disabilities who may be more likely to make mistakes. + + +
    • + + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/error-prevention-legal-financial-data.html b/wcag22/understanding/error-prevention-legal-financial-data.html new file mode 100644 index 0000000..c375415 --- /dev/null +++ b/wcag22/understanding/error-prevention-legal-financial-data.html @@ -0,0 +1,680 @@ + + + + + + Understanding Success Criterion 3.3.4: Error Prevention (Legal, Financial, Data) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.3.4:Error Prevention (Legal, Financial, Data) (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can avoid submitting incorrect important information.
+ +
What to do
+
Provide ways for users to confirm, correct, or reverse important submissions.
+ +
Why it's important
+
People with disabilities may be more likely to make mistakes, or not notice them.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to help users with disabilities avoid serious + consequences as the result of a mistake when performing an action that cannot be reversed. + For example, purchasing non-refundable airline tickets or submitting an order to purchase + stock in a brokerage account are financial transactions with serious consequences. + If a user has made a mistake on the date of air travel, he or she could end up with + a ticket for the wrong day that cannot be exchanged. If the user made a mistake on + the number of stock shares to be purchased, he or she could end up purchasing more + stock than intended. Both of these types of mistakes involve transactions that take + place immediately and cannot be altered afterwards, and can be very costly. Likewise, + it may be an unrecoverable error if users unintentionally modify or delete data stored + in a database that they later need to access, such as their entire travel profile + in a travel services web site. When referring to modification or deletion of 'user + controllable' data, the intent is to prevent mass loss of data such as deleting a + file or record. It is not the intent to require a confirmation for each save command + or the simple creation or editing of documents, records or other data. + +

+

Users with disabilities may be more likely to make mistakes. People with reading disabilities + may transpose numbers and letters, and those with motor disabilities may hit keys + by mistake. Providing the ability to reverse actions allows users to correct a mistake + that could result in serious consequences. Providing the ability to review and correct + information gives the user an opportunity to detect a mistake before taking an action + that has serious consequences. + +

+

User-controllable data is user-viewable data that the user can change and/or delete + through an intentional action. Examples of the user controlling such data would be + updating the phone number and address for the user's account, or deleting a record + of past invoices from a website. It does not refer such things as internet logs and + search engine monitoring data that the user can't view or interact with directly. + + +

+
+
+

Benefits

+
    + + +
  • Providing safeguards to avoid serious consequences resulting from mistakes helps users + with all disabilities who may be more likely to make mistakes. + +
    • + + +
+
+
+

Examples

+
+ +
Order confirmation
+ +
A Web retailer offers on-line shopping for customers. When an order is submitted, + the order information—including items ordered, quantity of each ordered item, shipping + address, and payment method—are displayed so that the user can inspect the order for + correctness. The user can either confirm the order or make changes. +
+ +
Stock sale
+ +
A financial services Web site lets users buy and sell stock online. When a user submits + an order to buy or sell stock, the system checks to see whether or not the market + is open. If it is after hours, the user is alerted that the transaction will be an + after-hours transaction, is told about the risks of trading outside of regular market + hours, and given the opportunity to cancel or confirm the order. +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+ + + +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+ +
+ + + +

transactions where the person incurs a legally binding obligation or benefit

+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
user-controllable
+
+ + + +

data that is intended to be accessed by users

+ + +
+

Note

+

This does not refer to such things as Internet logs and search engine monitoring data.

+
+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/error-suggestion.html b/wcag22/understanding/error-suggestion.html new file mode 100644 index 0000000..2df4626 --- /dev/null +++ b/wcag22/understanding/error-suggestion.html @@ -0,0 +1,697 @@ + + + + + + Understanding Success Criterion 3.3.3: Error Suggestion | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.3.3:Error Suggestion (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users get suggestions on how to resolve errors.
+ +
What to do
+
Where errors are detected, suggest known ways to correct them.
+ +
Why it's important
+
People can address errors faster and with reduced effort.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that users receive appropriate suggestions + for correction of an input error if it is possible. The definition of "input error" + says that it is "information provided by the user that is not accepted" by + the system. Some examples of information that is not accepted include information + that is required but omitted by the user and information that is provided by the user + but that falls outside the required data format or allowed values. + +

+

Success Criterion 3.3.1 provides for notification of errors. However, persons with + cognitive limitations may find it difficult to understand how to correct the errors. + People with visual disabilities may not be able to figure out exactly how to correct + the error. In the case of an unsuccessful form submission, users may abandon the form + because they may be unsure of how to correct the error even though they are aware + that it has occurred. + +

+

The content author may provide the description of the error, or the user agent may + provide the description of the error based on technology-specific, programmatically + determined information. + + +

+
+
+

Benefits

+
    + +
  • Providing information about how to correct input errors allows users who have learning + disabilities to fill in a form successfully. +
    • + +
  • Users who are blind or have impaired vision understand more easily the nature of the + input error and how to correct it. +
    • + +
  • People with motion impairment can reduce the number of times they need to change an + input value. +
    • + +
+
+
+

Examples

+
+ +
Additional Help for Correcting An Input Error
+ +
The result of a form that was not successfully submitted describes an + input error in place in the page along with the correct input and offers additional + help for the form field that caused the input error. +
+ +
Suggestions from a Limited Set of Values
+ +
+ +

An input field requires that a month name be entered. If the user enters "12," suggestions + for correction may include: +

+ + +
    + +
  • A list of the acceptable values, e.g., "Choose one of: January, February, March, April, + May, June, July, August, September, October, November, December." + +
    • + +
  • The conversion of the input data interpreted as a different month format, e.g., "Do + you mean 'December'?" + +
    • + +
+ +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Note

+
+ + +

+ In some cases, more than one of these situations may apply. For example, when a mandatory + field also requires the data to be in a specific format. + + + +

+ + +
+
+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If information for a field is required to be in a specific data format:

+ + + + + +
+
+ + +

Situation B: Information provided by the user is required to be one of a limited set + of values: + +

+ + + + + +
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+ + +

Client-Side Scripting Techniques (Advisory)

+ + + + + +
+
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
input error
+
+ + + +

information provided by the user that is not accepted

+ + +
+

Note

+
+ +

This includes:

+ + +
    + + +
  1. Information that is required by the Web page but omitted by the user + +
    2. + + +
  2. Information that is provided by the user but that falls outside the required data + format or values + +
    3. + + +
+ +
+
+ + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/extended-audio-description-prerecorded.html b/wcag22/understanding/extended-audio-description-prerecorded.html new file mode 100644 index 0000000..f16556a --- /dev/null +++ b/wcag22/understanding/extended-audio-description-prerecorded.html @@ -0,0 +1,553 @@ + + + + + + Understanding Success Criterion 1.2.7: Extended Audio Description (Prerecorded) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.2.7:Extended Audio Description (Prerecorded) (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Videos can be played with more detailed audio descriptions.
+ +
What to do
+
Provide extended spoken descriptions of the visual content in videos.
+ +
Why it's important
+
People who are blind or who cannot understand the visual content can have it described + to them while playing videos. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to provide people who are blind or visually + impaired access to a synchronized media presentation beyond that which can be provided + by standard audio description. This is done by periodically freezing the synchronized + media presentation and playing additional audio description. The synchronized media + presentation is then resumed. + +

+

Because it disrupts viewing for those who do not need the additional description, + techniques that allow you to turn the feature on and off are often provided. Alternately, + versions with and without the additional description can be provided. + +

+
+
+

Benefits

+
    + + +
  • People who are blind, people with low vision who cannot see the screen, as well as + those with cognitive limitations who have difficulty interpreting visually what is + happening, often use audio description of the visual information. However, if there + is too much dialogue the audio description is insufficient. Extended audio description + can provide the additional information needed to understand the video. + +
    • + + +
+
+
+

Examples

+
    + + +
  • + Example 1. Video of a lecture. A physics professor is giving a lecture. He makes freehand sketches on the whiteboard, + speaking rapidly as he draws. As soon as he has finished discussing one problem, he + erases the drawing and makes another sketch while continuing to speak and gesture + with his other hand. The video is paused between problems, and extended audio description + of the professor's drawings and gestures is provided; the video is then resumed. + +
    • + + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+
+
+ +

Key Terms

+ +
audio
+
+ + + +

the technology of sound reproduction

+ + +
+

Note

+

Audio can be created synthetically (including speech synthesis), recorded from real + world sounds, or both. + +

+
+ + + +
+
audio description
+
+ + + +

narration added to the soundtrack to describe important visual details that cannot + be understood from the main soundtrack alone + +

+ + +
+

Note

+

Audio description of video provides information about actions, characters, scene changes, on-screen text, and + other visual content. + +

+
+ + +
+

Note

+

In standard audio description, narration is added during existing pauses in dialogue. + (See also extended audio description.) + +

+
+ + +
+

Note

+

Where all of the video information is already provided in existing audio, no additional audio description is necessary. + +

+
+ + +
+

Note

+

Also called "video description" and "descriptive narration."

+
+ + + +
+
extended audio description
+
+ + + +

audio description that is added to an audiovisual presentation by pausing the video so that there is time to add additional description + +

+ + +
+

Note

+

This technique is only used when the sense of the video would be lost without the additional audio description and the pauses between dialogue/narration are too short. + +

+
+ + + +
+
live
+
+ + + +

information captured from a real-world event and transmitted to the receiver with + no more than a broadcast delay + +

+ + +
+

Note

+

A broadcast delay is a short (usually automated) delay, for example used in order + to give the broadcaster time to cue or censor the audio (or video) feed, but not sufficient + to allow significant editing. + +

+
+ + +
+

Note

+

If information is completely computer generated, it is not live.

+
+ + + +
+
media alternative for text
+
+ + + +

media that presents no more information than is already presented in text (directly + or via text alternatives) + +

+ + +
+

Note

+

A media alternative for text is provided for those who benefit from alternate representations + of text. Media alternatives for text may be audio-only, video-only (including sign-language + video), or audio-video. + +

+
+ + + +
+
prerecorded
+
+ + + +

information that is not live + +

+ + + +
+
synchronized media
+
+ + + +

+ audio or video synchronized with another format for presenting information and/or with time-based + interactive components, unless the media is a media alternative for text that is clearly labeled as such + +

+ + + +
+
video
+
+ + + +

the technology of moving or sequenced pictures or images

+ + +
+

Note

+

Video can be made up of animated or photographic images, or both.

+
+ + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/focus-appearance.html b/wcag22/understanding/focus-appearance.html new file mode 100644 index 0000000..075c191 --- /dev/null +++ b/wcag22/understanding/focus-appearance.html @@ -0,0 +1,1718 @@ + + + + + + Understanding Success Criterion 2.4.13: Focus Appearance | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.13:Focus Appearance (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Make it easier to spot the keyboard focus.
+ +
What to do
+
Use a focus indicator of sufficient size and contrast.
+ +
Why it's important
+
Many people can't see small changes in visual appearance, including older people.
+ +
+
+
+

Intent

+

The purpose of this Success Criterion is to ensure a keyboard focus indicator is clearly + visible and discernible. Focus Appearance is closely related to 2.4.7 Focus Visible and 1.4.11 Non-text Contrast. Focus Visible requires that a visible focus indicator exists while a component has + keyboard focus; Focus Appearance defines a minimum level of visibility. Where Non-text + Contrast requires a component to have adequate contrast against the background in + each of its states, Focus Appearance requires sufficient contrast for the focus indicator + itself. +

+

For sighted people with mobility impairments who use a keyboard or a device that utilizes + the keyboard interface (such as a switch or voice input), knowing the current point of focus is very important. + Visible focus must also meet the needs of users with low vision, who may also rely + on the keyboard. +

+

A keyboard focus indicator can take different forms. This Success Criterion encourages + the use of a solid outline around the focused user interface component, but allows + other types of indicators that are at least as large. +

+

This Understanding document will elaborate on the minimum area requirement, color + contrast requirements, and finally list some user agent exceptions. +

+
+ +

Minimum area

+ + +

The first part of the Success Criterion specifies a minimum area for the focus indicator:

+ + +
+ +
    + +
  • is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component +
    • + +
+ +
+ + +

This only specifies a minimum area for the focus indicator. It does not require that + the focus indicator literally be a 2 CSS pixel thick outline, only that the indicator + be at least that large. +

+ + +

However, the simplest way to meet the size requirement is to use a focus indicator + which is a solid 2 CSS pixel thick perimeter. +

+ + +
+

Note

+

A CSS pixel is what developers use in CSS declarations like “width: 200px”. It is device-independent + and not to be confused with device pixels which vary depending on the physical pixel + density.
+ The rest of this document notates CSS pixels as “px”. + +

+
+ + +
+ +

Using a solid outline

+ + +

The easiest and most common way to meet this requirement is to use a solid outline + around the component. The outline must be at least 2px thick. The following illustration + shows a minimally thick focus indicator, where a 2px thick band of white pixels making up the page + background around an example button have been altered to black. +

+ + +
+ 2 blue buttons with a dark 2 pixel thick offset focus rectangle around the second + +
Figure 1 Passes: The focus indicator is a solid 2px thick outline.
+ +
+ + +

For non-rectangular components, the "perimeter" definition allows authors to use either + of the following types of outline: +

+ + +
    + +
  • a line which solidly encloses a shape, or
    • + +
  • a line which solidly encloses the minimum bounding box of a shape +
    • + +
+ + +

For example, a star-shaped button may use either a focus indicator that follows the + shape of the star or a focus indicator that follows the bounding box of the star. + In the following examples, the same three stars have already been selected, and focus + is on the third star. The first example uses a focus indicator which matches the star + shape of the focused star. The second uses a rectangular indicator. +

+ + +
+ Three of 5 stars are selected with a solid-line focus indicator in the shape of a star outlining the third + +
Figure 2 Passes: a solid outline indicator surrounds the third of five stars.
+ +
+ + +
+ 3 of 5 stars are selected with a solid-line rectangular focus indicator around the third + +
Figure 3 Passes: a solidly bound focus rectangle encloses the third of five stars.
+ +
+ + +

Offsetting indicators slightly from the focused component, as in the examples above, + is not required to meet the minimum area requirement of the success criterion, but + it can help make indicators more visible. In CSS, the outline and outline-offset properties are commonly used to achieve this. +

+ + +

The smallest possible 2 CSS pixel thick indicator that is still a "perimeter" is a + solid line that appears inside the component against the component's outer edge, for + example by using a CSS border property. Indicators that are inset further within the component (not directly against + the component's outer edge) need to be thicker than 2 CSS pixels to meet the minimum + size requirement. +

+ + +
+ a button along with 4 examples of different 2px solid focus indicators for it: offset outside the component, an outline around the boundary of the component, a border inside the boundary of the component, and inset inside the component + +
Figure 4 All four of these example focus indicators are 2px solid lines. The "outset", "outline", + and "border" indicators pass. The "inset" indicator does not meet the minimum area + requirement and fails; it would need to be at least 3px thick to pass. +
+ +
+ + +

Note that different Non-text Contrast requirements may apply depending on whether + the focus indicator is offset from, inset into, or against the edge of the component. + See the Relationship with Non-text Contrast section below. +

+ +
+ +
+ +

Other indicator shapes

+ + +

This Success Criterion does not require that focus indicators be solid outlines. Other + shapes may be used so long as they meet the minimum area requirement. +

+ + +

The minimum area of the focus indicator for a control is the area of a 2 CSS pixel + thick perimeter of the control (or its minimum bounding box) in the control's unfocused + state. For example, if a control is a rectangle 90px wide and 30px tall, the area + of a 2 CSS pixel thick perimeter is difference between the areas of: +

+ + +
    + +
  • A 92px by 32px rectangle (1px larger on all sides), and
    • + +
  • A 88px by 28px rectangle (1px smaller on all sides)
    • + +
+ + +

This results in a minimum area of (92px * 32px) - (88px * 28px) = 480px2. +

+ + +

Some general formulas for 2 CSS pixel thick perimeters of common shapes are:

+ + +
+ +
Rectangle with width w and height h
+ +
4h + 4w
+ +
Circle with radius r
+ +
4𝜋r
+ +
Rounded rectangle with width w, height h, and border radius r
+ +
4h + 4w - (16 - 4𝜋)r
+ +
+ + +
+

Note

+

If you need to use complex mathematics to work out if a focus indicator is large enough, + it is probably a sign that you should use a larger indicator instead. The bigger the + visible change when an item receives focus, the easier it is for someone to see. +

+
+ + +

The following 2 examples use a 90px wide by 30px tall button, with a minimum area + requirement of 480px2: +

+ + +
+ Three 90 by 30 pixel buttons. The middle button has a focus indicator which is a 3px thick outline inset by 3px inside the button + +
Figure 5 Passes: the inner outline is inset slightly from the outer edge of the component, + but compensates for this by being 3px thick. It has an area of 612px2, which exceeds the 480px2 minimum. +
+ +
+ + +
+ Three 90 by 30 pixel buttons. The middle button has a focus indicator which is two rectangles inside the button, one on either side + +
Figure 6 Passes: the indicator rectangles on either side of the focused button are each 9px + wide by 28px tall. In total, they are 504px2, which just barely meets the 480px2 minimum. +
+ +
+ + +
+

Note

+

Prefer using focus indicator techniques that scale with both the width and height + of the focused control. Otherwise, if controls change size across different variations + of a page (for example, in a responsive design), the indicator might meet the area + requirement in some variations but not others. For example, in the above figure, if + the width of the two highlight rectangles did not scale as the button grew wider, + it would stop meeting the minimum area requirement if the button needed to grow any + wider to accomodate a longer button label. +

+
+ + +

Another way of achieving the area requirement is to alter the appearance of the entire + component, for instance by changing its color – provided that the new color has a + contrast ratio of at least 3:1 against the original color. This can be effective in + a set of closely placed buttons. The following example demonstrates this with 5 rating + stars; the center star is filled in with a darker color to indicate focus. However, + it is much more difficult to detect such a focus indicator when components are not + near each other and so cannot be easily compared. For users using magnification, even + components relatively close together may be difficult to compare, so it is not considered + a best practice. +

+ + +
+ 3 of 5 stars are selected with the whole third star altered in color to indicate focus + +
Figure 7 Passes: a color change applies to the whole third star to indicate focus.
+ +
+ +
+ + + +
+
+ +

Change of contrast

+ + +

The second part of the Success Criterion's indicator requirements states that an area + of the indicator: +

+ + +
+ +
    + +
  • has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused + states +
    • + +
+ +
+ + +

This requirement measures the change of contrast between the same pixels in different + states. This is different from the Text Contrast and Non-text Contrast Success Criteria, + which measure the contrast between different adjacent pixels in a single state at + a time. +

+ + +

3:1 is the minimum allowable change-of-contrast ratio, but the greater the change of contrast between + states, the easier it is for users to see the focus indicator. Authors are encouraged + to make the change-of-contrast ratio as great as possible. +

+ + +

The following illustration shows a minimally contrasting focus indicator, where some of the white pixels making up the page background + have been altered to a mid-grey that has a 3:1 contrast ratio with the original white. + Authors are encouraged to exceed the minimum focus appearance. For instance, the dark + blue lines in figures 2 and 3 are much more visible. +

+ + +
+ Two orange-yellow five-pointed stars, one with a mid-gray focus rectangle + +
Figure 10 Passes: Two buttons in the shape of a star, with the second surrounded by a focus + indicator whose pixels contrast 3:1 between focused (light grey) and unfocused (white) + states. +
+ +
+ + +

When a component changes to include a focus indicator, that change can be measured + as a change of color contrast. For example, if a yellow outline is added to a button + on a blue background, the change of color is from blue to yellow. This change can + be measured whether the focus indicator is on the background around the component, + or the background within the component. +

+ + +
+ Three dark blue buttons on a white background. The middle button has a yellow inner border. + +
Figure 11 Passes: adding a yellow outline to a link is a change of color from blue to yellow. + That change has a contrast ratio of 12:1. +
+ +
+ + +

If a control receiving focus changes its background (fill color) to a color that contrasts + less than 3:1 with the original background, that would not pass the change of contrast. +

+ + +
+ Three black buttons with a dark background. The middle button has a dark grey background. + +
Figure 12 Fails: the second link has a dark-grey (#555) which fails this Success Criterion because the change from black-background to dark-grey background + does not meet 3:1. +
+ +
+ + +

If the background change is sufficient, it is a method of passing the criterion.

+ + +
+ Three black buttons with a dark border and two have a dark background. The middle button has a white background. + +
Figure 13 Passes: the second link has a white background (#fff) which passes this Success Criterion because the change from black-background to white-background + meets 3:1. +
+ +
+ + +
+ +

Partially contrasting indicators

+ + +

It is not necessary for the entire focus indicator to have a 3:1 change of contrast. It is sufficient for just a part + of the indicator to meet the change of contrast requirement, so long as the contrasting + part of the indicator meets the minimum area requirement. +

+ + +
+ A button whose focus indicator is two nested outlines: an inner 2px thick light gray outline with low contrast against the background, and an outer 2px thick black outline with high contrast + +
Figure 14 Passes: The black part of the indicator meets 3:1 contrast with the white background, + but the gray part does not. The black part is 2px thick, so it meets the minimum area + requirement on its own and the gray part can be ignored. +
+ +
+ + +
+ A button whose focus indicator is two nested outlines: an inner 1px thick light gray outline with low contrast against the background, and an outer 1px thick black outline with high contrast + +
Figure 15 Fails: The indicator as a whole is 2px thick, but the part of it that has sufficient + change-of-contrast is only 1px thick. The part of the indicator with sufficient change-of-contrast + does not meet the minimum area requirement. +
+ +
+ + +

When calculating whether a focus indicator meets the minimum area requirement, only + the part of the indicator which meets the change-of-contrast requirement should be + included in the calculation. +

+ +
+ + +
+ +

Gradients

+ + +

If a focus indicator has a gradient, the principle is to measure the contrast of the + changed area, and ignore any part of the gradient which has less than a 3:1 change-of-contrast + ratio. +

+ + +
+ Three buttons, the middle with a heavy drop-shadow indicating focus. + +
Figure 16 When a gradient is used on a focus indicator, the measure of surface area should only + include the area that has changed enough to meet the 3:1 contrast ratio. +
+ +
+ + +

If you eliminate the area which has less than 3:1 change-of-contrast, you can calculate + the area of the remaining parts of the indicator to determine whether the indicator + meets the minimum area requirement. +

+ + +
+ The middle button with the drop-shadow included, but the subtle grey areas removed to only show the contrasting area. + +
Figure 17 Passes: the same focused button with the non-contrasting areas removed. The contrasting + area is 6px thick along most of the bottom edge and 3-4px thick on the left and right + edges, which is enough to meet the minimum area requirement. +
+ +
+ + +
+

Note

+

Some of the examples in this document are screen-captured images of elements. Due + to loss of resolution in these images, the actual pixel color may not match the original. + As such, they are intended to be used for illustrative purposes, and should not be + inspected on a pixel-by-pixel basis for sufficient contrast. +

+
+ + +

Some designs have pages with a non-solid background image covering the whole (or part) + of the page or make use of parallax scrolling effects which result in a near-infinite + number of color combinations if a page is scrolled and/or changes are made to the + viewport size. +

+ + +

If the contrast of background colors that change are close enough to need to be tested + for each combination then they would likely not meet the user need of people with + low vision in certain scroll combinations and would likely fail in certain combinations + as well. In these cases it would be an easy solution to use a two-color focus indicator or some other mechanism to indicate focus such as a solid box with a border to guarantee + there is sufficient contrast across variations of background images or background + gradients. +

+ + +

It is possible to use visual patterns such as strips switching places to disguise + a change of focus indicator. However, this is not considered a visible indicator. +

+ +
+ +
+
+ +

Relationship with Non-text Contrast

+ + +

Focus indicators are visual information required to identify a state of a user interface + component. That means that they are subject to 1.4.11 Non-text Contrast, in addition to 2.4.13 Focus Appearance. +

+ + +

In combination with 2.4.7 Focus Visible, 1.4.11 Non-text Contrast requires that the visual focus indicator for a component must have sufficient contrast + against the adjacent colors when the component is focused, except where the appearance + of the component is determined by the user agent and not modified by the author. +

+ + +

The difference between the contrast requirements in Focus Appearance and Non-text + Contrast is: +

+ + +
    + +
  • Focus Appearance requires that focus indicators have a change of contrast between focused and non-focused states. +
    • + +
  • Non-text Contrast requires that focus indicators have adjacent contrast between the indicator (in the focused state) and adjacent non-indicator colors. +
    • + +
+ + +
+ A light blue button with a 3px thick border. The border is black in the unfocused state and light gray in the focused state. + +
Figure 18 This example passes Focus Appearance but fails Non-text Contrast; there is insufficient + adjacent contrast between the focus indicator and the adjacent colors. +
+ +
+ + +
+ A light blue button with a 3px thick border. The border is black in the unfocused state and dark gray in the focused state. + +
Figure 19 This example passes Non-text Contrast but fails Focus Appearance; there is insufficient + change of contrast between the focused and unfocused states. +
+ +
+ + +

Additionally, Non-text Contrast does not establish any size requirement and has slightly + different rules for when exceptions are allowed. +

+ + +

See the Relationship with Focus Visible section of Understanding 1.4.11 Non-text Contrast for more details and examples. +

+ +
+
+ +

Component keyboard focus

+ +

The preamble to this Success Criterion is "When a user interface component has keyboard + focus..." The keyboard focus is the point of interaction for someone using a keyboard. For environments with a + keyboard-operable interface, the keyboard focus can be moved around the interface + in order to interact with different components. Whichever component is being interacted + with has focus. +

+ + +

WCAG defines user interface component as "a part of the content that is perceived by users as a single control for a distinct + function." Because different users may perceive controls differently, there is a potential + for some variation when interpreting what constitutes both a single control and a distinct function. This is particularly the case when something visually presents in a way that may + differ from how it is programmatically created under the covers. Where there is not + a native HTML component upon which to base designs, there can be great variations + in how the components and their focus indicators are portrayed. Further, some components + have sub-components that can take focus, such as the menu items on a menu. +

+ + +

Nonetheless, consistent results from different testers were obtained for this Success + Criterion by using the focus indicator itself as the gauge of what constitutes the + component being interacted with. For complex components, the three typical focus indicators + are as follows: +

+ + +
    + +
  • Focus indicator around only the whole component
    • + +
  • Focus indicators around both the component and subcomponent
    • + +
  • Focus indicator around only the subcomponent
    • + +
+ + +

Each of these will be discussed, using a tablist as a familiar complex component.

+ + +

Focus indicator around only the whole component

+ +
+ Three tab buttons shown with a dark blue rectangle around all three tab buttons. + +
Figure 20 A tablist with a focus indicator around only the whole.
+ +
+ + +

When the focus indicator is shown only around the whole tablist, the user is guided + to considering the tablist as a single user component. The tab items within it are + visually distinguished between selected and unselected states (and visual indicators + of selection state must meet the criteria given in 1.4.11 Non-text Contrast). +

+ + +

Having a focus indicator only around the whole is possible where there is no need to have a selected sub-component + while another sub-component has focus. For a tablist which synchronizes its tab panel + content with whatever tab is active, only one tab item can be selected at a time, + and since whatever tab is selected is considered active, a separate focus indicator + is redundant. +

+ + +

Result: the group focus indicator must meet the requirements of this Success Criterion.

+ + +

A radio button group and a star-rating widget, which each use only a whole-component focus indicator, provide working examples + of different complex components that pass the primary requirements of this Success + Criterion. In the star ratings example, users can increment the rating by 1/2 stars. + Not only is a focus indicator for each 1/2 star unnecessary, but it would actually + be difficult to achieve without making the interaction confusing. +

+ + +

Focus indicators around both the component and subcomponent

+ + +
+ Three tab buttons shown with a dark blue rectangle around all three tab buttons, the first tab button also has a dark outline as well as a blue bar indicating it is selected. +
+ The same tab list showing except the first tab is selected, but the second has the focus outline. + +
Figure 21 The same tablist in two states. In the first, focus is around both the tablist and + the currently selected tab; in the second, focus is around both the tablist and an + unselected tab. +
+ +
+ + +

For a tablist which does not keep its tab panel content synchronized with whatever + tab is selected, there needs to be a focus indicator for the tab item subcomponent. + This is because the tab item with focus may be different than the selected item. +

+ +

The user can navigate to the tablist, which in this implementation has a focus rectangle + around the whole tablist as well as one around a tab item (conventionally the item + that is currently selected). The focus around the whole is helpful in cueing a keyboard + user that this is a complex component that has its own interaction. The user can then + move focus between the unselected and selected tab items -- each of which in turn + has its own focus indicator -- before activating one, which then makes it selected + as well as focused, and updates the tab panel to match. +

+ +

In this scenario, either the group focus indicator or the sub-component indicator + must meet the requirements of this Success Criterion. To avoid being overly prescriptive, + the Success Criterion allows authors to choose which makes the most sense. Generally, + if a sub-component focus is necessary, it should be assessed instead of the group + indicator. +

+ + +

Result: the focus indicator for the tab item meets the requirements of this Success + Criterion. The tablist focus indicator does not need to meet the requirements. +

+ + +

A slider to pick colors provides a working example of a different complex component that predominantly shows + focus for the subcomponent. In this case, the thumb slider sub-component has a focus + indicator of sufficient size and contrast to pass the sufficient area calculation. + There is also a subtle focus around the whole slider component, but it does not need + to be assessed to pass this Success Criterion. +

+ + +

Focus indicator around only the subcomponent

+ + +
+ Three tab buttons shown and the first button has a dark outline. + +
Figure 22 The same tabs as in the prior set, but the focus indicator around the whole is removed.
+ +
+ + +

The same unsynchronized tablist can also be implemented as something which only shows + focus on the tab items and not on the whole. The behaviour is the same as in the prior + example, but there is never a focus indicator placed around the tablist. This interaction + is acceptable, but it is not best practice since it demands more understanding from + the user with less information. For example, some visual cues for the tablist and + tab items (and tab panel) may not be clear. As well, keyboard users may not initially + understand the expected keyboard interaction. +

+ + +

Result: the focus indicator for the tab item must meet the requirements of this Success + Criterion, judging focus with both selected and unselected tab items. +

+ + +

A functional example of sub-component-only tab focus has an indicator that is large enough (at least four times the shortest side) with + sufficient contrast to pass the focus area language of this Success Criterion. +

+ + +

Where something with focus is not a user interface component

+ +

Some pages contain very large editing regions, such as web implementations of word + processors and code editors. Unlike a textarea element, which is a user interface component, these large editing regions do not + typically meet the definition of user interface components; they are not "perceived by users as a single control for a distinct function." Providing + focus indicators around such editing regions may still be beneficial to some; however, + where the region is not perceived as a single control, it is not covered by this Success + Criterion. The web page will still need to provide a insertion point (caret indicator) + in such editing regions in order to meet the requirements of 2.4.7 Focus Visible. +

+ + +

Some non-operable elements can take focus (such as a heading element that is the target + of a skip link). However, the preamble of this Success Criterion refers to user interface + components; it is only when the element with focus is operable by keyboard that this + Success Criterion applies. +

+ +
+
+ +

Exceptions

+ + +

There are two situations where the focus appearance does not need to be assessed:

+ + +
    + +
  • the focus indicator cannot be adjusted by the author
    • + +
  • the author has not modified the effects of the user agent default
    • + +
+ + +
+ +

First exception: the focus indicator cannot be adjusted by the author

+ + +
+

The focus indicator is determined by the user agent and cannot be adjusted by the + author +

+
+ + +

Some components or technologies may not allow the author to adjust the focus indicator. + This is the case with HTML select elements (both single and multi-select), where the visual treatments for selection + and focus cannot be adjusted by the author. In this case the Success Criterion does + not apply. +

+ + +
+ A country select element with Afghanistan selected and Albani with focus + +
Figure 23 Passes: The user agent's default select element presentation cannot be modified by the author, so it passes regardless of + the quality of the focus indicator +
+ +
+ +
+ + +
+ +

Second exception: the default indicator and background are not modified

+ + +
+

The focus indicator and the indicator's background color are not modified by the author

+
+ + +

If the focus indicator and the background behind the focus indicator are not modified + by the author, the Success Criterion does not apply. +

+ + +

The intent of this exception is to reduce burden on authors by allowing them to rely + on the default indicators provided by user agents (browsers). If all user agents provided + good focus indicators, authors would be able to concentrate efforts on other accessibility + considerations. Unfortunately, browser default focus indicators vary by component, + browser, and across devices and operating systems, and the default focus indicators + in some browsers can be difficult to see (such as a 1px dotted outline). For this + reason, most authors override browser defaults in order to overcome these deficiencies + and create a more uniform user experience, regardless of browser. +

+ + +

Some browser makers are improving their default focus indicators to make them more + visible. As more browsers adopt defaults that meet the primary bullets of this Success + Criterion, authors will be able to achieve improved focus indicators without customization. +

+ + +

Modifying the focus indicator background

+ + +

Browser default focus indicators can be made more difficult to see if the author modifies the pixels directly adjacent to the indicator + (commonly referred to as its background), such as by positioning a component on top + of an image or gradient background, or altering the page's default white background + color, for instance using a blue background in combination with a browser's blue default + indicator. For this reason, where the author alters the pixels directly adjacent to + the default focus indicator, the user agent exception does not apply, and the author + will need to verify they meet the size and contrast requirements of this Success Criterion. +

+ +
+

Note

+

Altering the body element's background-color attribute is one way of altering the pixels directly adjacent to the indicator in most implementations. + However, specifying a value of white (#FFFFFF) does not nullify this exception since, as established in the third note of the contrast ratio definition, the default ("unspecified") color is assumed to be white. +

+
+ + +

As well, if the browser provides an indicator within a component by default, then authors can potentially reduce the visibility by changing + the component color (which in such a scenario is the background color for the focus + indicator). For example, if the default indicator on a button uses a colored inner + border, authors can negatively affect the focus appearance by making the button or + its unfocused border color a similar-luminosity color. For this reason, this user + agent exception can only be met if the author both does not modify the default focus + indicator and does not modify its background. +

+ + +
+ A button with an author-customized blue border which looks very similar to the blue border used by a user agent default focus indicator + +
Figure 24 Fails: The middle button is focused using a browser's default focus indicator, but + it is very difficult to tell which button is focused because the custom blue border + on the unfocused button uses a similar color. +
+ +
+ +
+ +
+
+
+

Benefits

+
    + +
  • This Success Criterion helps anyone who relies on the keyboard to operate the page, + by letting them visually determine the component on which keyboard operations will + interact at any point in time. +
    • + +
  • People with attention limitations, short term memory limitations, or limitations in + executive processes benefit by being able to discover where the focus is located. +
    • + +
+
+
+

Examples

+
    + +
  • When links receive focus, an outline is displayed around the link that contrasts with + the background adjacent to the link. +
    • + +
  • When buttons receive focus, an outline is displayed within the button (around the + text) that contrasts with the button's background. +
    • + +
  • When text fields receive focus, an outline is displayed around the field, indicating + that the input has focus. +
    • + +
  • When radio buttons receive focus, an outline is displayed around the control, indicating + that the input has focus. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+
    + +
  1. + G195: Using an author-supplied, visible focus indicator + +
    2. + +
  2. + C40: Creating a two-color focus indicator to ensure sufficient contrast with all components + +
    3. + +
  3. + C41: Creating a strong focus indicator within the component + +
    4. + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+
    + +
  1. + Using a CSS border for inline text which can wrap (Potential future technique) + +
    2. + +
+
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
css pixel
+
+ + + +

visual angle of about 0.0213 degrees

+ + +

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. + This unit is density-independent, and distinct from actual hardware pixels present + in a display. User agents and operating systems should ensure that a CSS pixel is + set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [[css3-values]], which takes into account the physical dimensions of the display + and the assumed viewing distance (factors that cannot be determined by content authors). + +

+ + + +
+
focus indicator
+
+ + + + +

pixels that are changed to visually indicate when a user interface component is in a focused state + + +

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
minimum bounding box
+
+ + + +

the smallest enclosing rectangle aligned to the horizontal axis within which all the + points of a shape lie. For components which wrap onto multiple lines as part of a + sentence or block of text (such as hypertext links), the bounding box is based on + how the component would appear on a single line. +

+ + +
+
perimeter
+
+ + + +

continuous line forming the boundary of a shape not including shared pixels, or the + minimum bounding box, whichever is shortest. +

+ + + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
state
+
+ + + +

dynamic property expressing characteristics of a user interface component that may + change in response to user action or automated processes +

+ +

States do not affect the nature of the component, but represent data associated with + the component or user interaction possibilities. Examples include focus, hover, select, + press, check, visited/unvisited, and expand/collapse. +

+ + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/focus-not-obscured-enhanced.html b/wcag22/understanding/focus-not-obscured-enhanced.html new file mode 100644 index 0000000..ce5dde5 --- /dev/null +++ b/wcag22/understanding/focus-not-obscured-enhanced.html @@ -0,0 +1,363 @@ + + + + + + Understanding Success Criterion 2.4.12: Focus Not Obscured (Enhanced) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.12:Focus Not Obscured (Enhanced) (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Don't cover any part of the item with focus.
+ +
What to do
+
Ensure when an item gets keyboard focus, it is fully visible.
+ +
Why it's important
+
People who can't use a mouse need to see what has keyboard focus.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that the item receiving keyboard + focus is always visible in the user's viewport. For sighted people who rely on a keyboard + (or on a device that operates through the keyboard interface, such as a switch or + voice input), knowing the current point of focus is critical. The component with focus + signals the interaction point on the page. Where users cannot see the item with focus, + they may not know how to proceed, or may even think the system has become unresponsive. +

+

Typical types of content that can overlap focused items are sticky footers, sticky + headers, and non-modal dialogs. As a user tabs through the page, these layers of content + can hide the item receiving focus, along with its focus indicator. +

+

A notification implemented as sticky content, such as a cookie banner, will fail this + Success Criterion if it partially covers a component receiving focus. Ways of passing + include making the banner modal so the user has to dismiss the banner before navigating + through the page, or using scroll padding so the banner does not overlap other content. Notifications that do not require user + action could also meet this criterion by closing on loss of focus. +

+

Another form of obscuring can occur where light boxes or other semi-opaque effects + overlap the item with focus. This form of obscuring is not in scope for this Success Criterion. While less than 100 percent opacity is not causing + the component to be visually hidden, such semi-opaque overlaps may cause a failure of 2.4.11 Focus Appearance. When a focus indicator can be covered by a semi-opaque component, the the focus + indicator should be assessed against 2.4.11. The intention in both situations is that + the component receiving focus should never be obscured to the point a user cannot + tell which item has focus. +

+
+
+

Benefits

+
    + +
  • Sighted users who rely on a keyboard interface to operate the page will be able to + see the component which gets keyboard focus. Such users include those who rely on + devices which use the keyboard interface, including speech input, sip-and-puff software, + on-screen keyboards, scanning software, and a variety of assistive technologies and + alternate keyboards. +
    • + +
  • People with limited or low vision but who rely upon a pointing device (for viewport + orientation and repositioning) benefit from a clearly visible indication of the current + point of keyboard interaction, especially where magnification reduces the overall + useable portion of content. +
    • + +
  • People with attention limitations, short term memory limitations, or limitations in + executive processes benefit by being able to more easily discover where the focus + is located. +
    • + +
+
+
+

Examples

+
    + +
  • A page has a sticky footer (attached to the bottom of the viewport). When tabbing + down the page the focused item is not at all obscured by the footer because content + in the viewport scrolls up to always display the item with keyboard focus using scroll padding. +
    • + +
  • A page has a large (30% wide) cookie approval dialog. The dialog is modal, preventing + access to the other controls in the page until it has been dismissed. Focus is not + obscured because the cookie approval dialog (including the focus indicator) remains + on screen until selections are made and submitted. +
    • + +
  • A notification is implemented as a sticky header and the keyboard focus is moved to + the notification. The notification disappears when it loses focus, and does not obscure + any other controls (including the focus indicator visible prior to the notification). +
    • + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+
    + +
  1. C43: Using CSS scroll-padding to un-obscure content
    2. + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+
    + +
  • An interaction that causes content to appear over the component with keyboard focus, + visually covering part of the focus indicator. This behavior might be encountered + with advertising or promotional material meant to provide more information about a + product as the user navigates through a catalogue. +
    • + +
  • A page has a sticky footer (attached to the bottom of the viewport). When tabbing + down the page, a focused item is partially obscured by the footer because content + in the viewport scrolls without sufficient scroll padding. +
    • + +
+
+
+
+
+ +

Key Terms

+ +
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/focus-not-obscured-minimum.html b/wcag22/understanding/focus-not-obscured-minimum.html new file mode 100644 index 0000000..5dee54d --- /dev/null +++ b/wcag22/understanding/focus-not-obscured-minimum.html @@ -0,0 +1,647 @@ + + + + + + Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.11:Focus Not Obscured (Minimum) (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Keep the focused item visible.
+ +
What to do
+
Ensure when an item gets keyboard focus, it is at least partially visible.
+ +
Why it's important
+
People who can't use a mouse need to see what has keyboard focus.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that the item receiving keyboard + focus is always partially visible in the user's viewport. For sighted people who rely + on a keyboard (or on a device that operates through the keyboard interface, such as + a switch or voice input), knowing the current point of focus is critical. The component + with focus signals the interaction point on the page. Where users cannot see the item + with focus, they may not know how to proceed, or may even think the system has become + unresponsive. +

+

In recognition of the complex responsive designs common today, this AA criterion allows + for the component receiving focus to be partially obscured by other author-created content. A partly obscured component can still be + very visible, although the more of it that is obscured, the less easy it is to see. + For that reason, authors should attempt to design interactions to reduce the degree + and frequency with which the item receiving focus is partly obscured. For best visibility, + none of the component receiving focus should be obscured. This preferred outcome is covered + by the AAA criterion Focus Not Obscured (Enhanced). +

+

Typical types of content that can overlap focused items are sticky footers, sticky + headers, and non-modal dialogs. As a user tabs through the page, these layers of content + can obscure the item receiving focus, along with its focus indicator. +

+

A notification implemented as sticky content, such as a cookie banner, will fail this + Success Criterion if it entirely obscures a component receiving focus. Ways of passing + include making the banner modal so the user has to dismiss the banner before navigating + through the page, or using scroll padding so the banner does not overlap other content. Notifications that do not require user + action could also meet this criterion by closing on loss of focus. +

+

Another form of obscuring can occur where light boxes or other semi-opaque effects + overlap the item with focus. While less than 100 percent opacity is not causing the + component to be entirely obscured, such semi-opaque overlaps may cause a failure of 1.4.11 Non-text Contrast. When a focus indicator can be covered by a semi-opaque component, the ability of + the focus indicator to pass 1.4.11 should be evaluated (and pass) while the focus + indicator is under the semi-opaque component. The intention in both situations is + that the component receiving focus should never be obscured to the point a user cannot + tell which item has focus. +

+
+ +

User-movable content

+ +

This SC contains a note regarding content that can be repositioned. If users can move + content regions, then they can potentially position the movable content such that + it obscures other content that may receive focus. In such a case, the author is only + responsible for ensuring that the movable content in its initial position does not obscure the item receiving focus. +

+ +

This note is intended to accommodate a common interaction in complex applications + such as authoring tools, where the main editing region (also called a canvas) can + be enhanced by displaying toolbars or other panels, which can be repositioned around + the canvas. It is possible to design such toolbars so they do not obscure focus. Authors are encouraged to do so, as well as pursue techniques which + ensure equitable keyboard use of such toolbars. However, in recognition of the complexities + involved in responsive design as well as in supporting the ability to transform the + text size and spacing of content, only the starting position of such movable panels + is assessed. +

+ + + +
+
+ +

User-opened content

+ +

This SC contains a note regarding content that is opened or disclosed by the user. + One example of such content is a menu button opened by a user that opens a list of + choices over pre-existing content on the screen. Such content can obscure other information + on the screen, but it does not obscure an item receiving keyboard focus, because the + new content doesn't stay open through a change of focus. However, authors may create + user-opened content that is intentionally designed to persist until closed by the + user, such as a chat window. Such persistent content has the potential to fail Focus + Not Obscured (Minimum). Various types are described in this section. All can be designed + so that they pass this Success Criterion. +

+ + +

This section only applies to content that the user actively discloses. Content pre-positioned + by the author (such as a sticky footer), or content that appears without direct user + initiation, such as system warnings, must not prevent the item receiving focus from + being immediately visible in the viewport. Also, this note is not intended to apply + to disclosures that are by convention non-persistent. As discussed in the following + sub-section, an open dropdown that does not close when no longer focused is not following + this convention. +

+ + +
+ +

Non-persistent opened information

+ +

A number of components on the web open (or disclose) additional content (on activation + or on focus) intended for immediate user interaction or information. This new content + is often on top of other content, obscuring it. Examples of such components are menu + items, select element items, combobox lists (and other dropdown items), date picker + calendars, and tooltips. The common trait of all these components is that they are + not expected to persist after being acted on or once they are no longer the primary + point of user interaction. Such non-persistent disclosures do not fail this SC since + they do not obscure the item with focus. However, if an author allows such components + to persist after the user has 1) activated one of the opened items or 2) moved the focus away + from the triggering item and the additional content, it is at risk of failing this + criterion by obscuring the item with focus. +

+ + + +
+ + +
+ +

User openable, persistent disclosures

+ +

Some disclosure patterns provide a mechanism for the user to open additional content + that remains open until intentionally closed by the user. Accordions are a simple + example of such a pattern. Chatbots and expandable side navigation are more complex + examples. All of these patterns can be implemented so they are not at risk of failing + this SC. Some possible approaches are: +

+ + +
    + +
  • When the additional content appears, it displaces existing content. An accordion is an example of this. When an accordion is opened, the disclosed content + shifts existing content further down the page. Since the new content does not obscure + existing content, it cannot obscure the item with focus. + + + +
    • + + +
  • When the additional content appears, existing content reflows. The popout sidebar on the WCAG standard is an example of this pattern. When the side menu is activated, it opens a new section + of information along the left side of the page. The main content area is reduced horizontally + to accommodate the new content, and the existing content reflows to fit in the thinner + space. As a result, there is no overlapping content between the two sections; the + item receiving focus, whether in the left navigation or in the main content, will + not be obscured by the other section. + + + +
    • + +
  • + When the additional content is opened, it takes focus and the tab ring is constrained + to the new content until it is dismissed. This modality is somewhat like a dialog, in that a user cannot navigate beyond the + opened content by keyboard without dismissing it first (typically by pressing Esc). + However, unlike in a modal dialog, in some implementations a pointer user may be able + to interact with content outside the opened section without dismissing it. Since this + pattern potentially creates an inequitable experience between keyboard and pointer + users, it should be used cautiously. That said, it does prevent the opened content + from obscuring the keyboard focus in the main content, and thus should pass this SC. + This is described and demonstrated in a short video in the Knowbility article in the + reference section, under the section heading Keep keyboard focus in the slide-out navigation until it's closed. + + + +
    • + +
  • + The disclosure expands into an area of the page containing no other content. Many pages are designed with wide margins, providing significant white space into + which new content can be opened. Many chatbots and toast notifications are designed + to 'slide up' into the right unpopulated side of a page. Where authors are careful + to ensure content is not obscured at each breakpoint in a responsive design, no obscuring + of other operable content need occur. + + + +
    • + +
  • + When focus leaves the additional content, the additional content is automatically + hidden or collapsed, or the content can be hidden or collapsed by use of a dedicated + keyboard command (for example, the Escape key.) This is very similar to patterns discussed previously under Non-persistent opened + information. A distinguishing factor can be that the user's last point of interaction + in the disclosure is preserved (it persists) even though it may be hidden until a + user returns. Some trees and left navigation patterns behave this way. + + + +
    • + +
+ + +

In recognition of more complex interfaces and user needs there is a note: Content opened by the user may obscure the component receiving focus. If the user can bring the item with focus into view using a method without having + to navigate back to the user-opened content to dismiss it, this criterion would be + passed. For example, keyboard actions that may allow the item with focus to be revealed + include: + +

+ + +
    + +
  • using the Escape key to dismiss the obscuring content; +
    • + +
  • using keys to scroll the content in the viewport to reveal the item with focus;
    • + +
  • issuing a key to move between overlays.
    • + +
+ + +

For example:

+ + +
    + +
  • A user opens a chat interface, which is a popover non-modal dialog. This results in + some content of the underlying page being fully obscured. The user navigates away + from the chat interface by use of the tab key, focusing onto a link that has been fully obscured by the dialog. The user presses + the Escape key to close the chat interface, which un-obscures the link. +
    • + +
  • A user expands a fixed-position page feedback component at the bottom of a Web page. + They then use their keyboard to navigate to a link that's fully obscured by the expanded + component and press the down arrow or space key on their keyboard to scroll the content on the page, un-obscuring the link. +
    • + +
  • A user opens a web-based multi-user authoring application. An overlay appears displaying + a list of people who have contributed to the document. The user tabs through the list + of contributors and activates one of them. The application displays a new overlay, + which obscures the first one, that displays that person's recent contributions. The + user presses the F6 key to toggle the stacking order of the two overlays. +
    • + +
+ + +
+ +
+
+ +

Modal dialogs

+ + +

A properly constructed modal dialog will always pass this SC. Even if it appears directly + on top of an item with focus, the dialog takes focus on appearance, and thus the item + receiving focus -- the dialog or one of its components -- is visible. A properly constructed + modal maintains that focus and prevents interaction outside the modal until it is + dismissed. +

+ +

A dialog-like overlay that does not take focus on appearance and does not either constrain + interaction to the overlay or dismiss itself on loss of focus (thus allowing focus + to exit into the content behind it) will be at risk of failing this SC, where it is + positioned such that it can obscure other focusable items. +

+ +
+
+
+

Benefits

+
    + +
  • Sighted users who rely on a keyboard interface to operate the page will be able to + see the component which gets keyboard focus. Such users include those who rely on + a keyboard or on devices which use the keyboard interface, including speech input, + sip-and-puff software, onscreen keyboards, scanning software, and a variety of assistive + technologies and alternate keyboards. +
    • + +
  • People with limited or low vision, who may primarily user a pointer for screen orientation + and repositioning, nonetheless benefit from a visible indication of the current point + of keyboard interaction, especially where magnification reduces the overall viewing + portion of the screen. +
    • + +
  • People with attention limitations, short term memory limitations, or limitations in + executive processes benefit by being able to discover where the focus is located. +
    • + +
+
+
+

Examples

+
    + +
  • A page has a sticky footer (attached to the bottom of the viewport). When tabbing + down the page the focused item is not completely visually obscured by the footer because + content in the viewport scrolls up to always display the item with keyboard focus + using scroll padding. +
    • + +
  • A page has a full-width cookie approval dialog. The dialog is modal, preventing access + to the other controls in the page until it has been dismissed. Focus is not obscured + because the major portion of the cookie approval dialog remains on screen (until selections + are made and submitted), and so the major portion of the keyboard focus indicator + remains visible. +
    • + +
  • A notification is implemented as a sticky header and the keyboard focus is moved to + the notification so at least part of the focus indicator is in view. The notification + disappears when it loses focus so it does not obscure any other controls, and part + of the prior keyboard focus indicator is visible. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+
    + +
  1. + C43: Using CSS scroll-padding to un-obscure content + +
    2. + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+
    + +
  1. + F110: Failure of Success Criterion 2.4.12 Focus Not Obscured (Minimum) due to a sticky footer + or header completely hiding focused elements + +
    2. + +
+
+
+
+
+ +

Key Terms

+ +
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/focus-order.html b/wcag22/understanding/focus-order.html new file mode 100644 index 0000000..dc9f967 --- /dev/null +++ b/wcag22/understanding/focus-order.html @@ -0,0 +1,768 @@ + + + + + + Understanding Success Criterion 2.4.3: Focus Order | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.3:Focus Order (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Keyboard users navigate content in a correct order.
+ +
What to do
+
Elements receive focus in an order that preserves meaning.
+ +
Why it's important
+
Navigating a site or application with only the keyboard will make sense.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that when users navigate sequentially + through content, they encounter information in an order that is consistent with the + meaning of the content and can be operated from the keyboard. This reduces confusion + by letting users form a consistent mental model of the content. There may be different + orders that reflect logical relationships in the content. For example, moving through + components in a table one row at a time or one column at a time both reflect the logical + relationships in the content. Either order may satisfy this Success Criterion. + +

+

The way that sequential navigation order is determined in Web content is defined by + the technology of the content. For example, simple HTML defines sequential navigation + via the notion of tabbing order. Dynamic HTML may modify the navigation sequence using + scripting along with the addition of a tabindex attribute to allow focus to additional + elements. If no scripting or tabindex attributes are used, the navigation order is + the order that components appear in the content stream. (See HTML 4.01 Specification, + section 17.11, "Giving focus to an element"). + +

+

An example of keyboard navigation that is not the sequential navigation addressed + by this Success Criterion is using arrow key navigation to traverse a tree component. + The user can use the up and down arrow keys to move from tree node to tree node. Pressing + the right arrow key may expand a node, then using the down arrow key, will move into + the newly expanded nodes. This navigation sequence follows the expected sequence for + a tree control - as additional items get expanded or collapsed, they are added or + removed from the navigation sequence. + +

+

The focus order may not be identical to the programmatically determined reading order + (see Success Criterion 1.3.2) as long as the user can still understand and operate + the Web page. Since there may be several possible logical reading orders for the content, + the focus order may match any of them. However, when the order of a particular presentation + differs from the programmatically determined reading order, users of one of these + presentations may find it difficult to understand or operate the Web page. Authors + should carefully consider all these users as they design their Web pages. + +

+

For example, a screen reader user interacts with the programmatically determined reading + order, while a sighted keyboard user interacts with the visual presentation of the + Web page. Care should be taken so that the focus order makes sense to both of these + sets of users and does not appear to either of them to jump around randomly. + +

+

For clarity:

+
    + + +
  • Focusable components need to receive focus in an order that preserves meaning and + operability only when navigation sequences affect meaning and operability. + +
    • + + +
  • In those cases where it is required, there may be more than one order that will preserve + meaning and operability. + +
    • + + +
  • If there is more than one order that preserves meaning and operability, only one of + them needs to be provided. + +
    • + + +
+
+
+

Benefits

+

These techniques benefit keyboard users who navigate documents sequentially and expect + the focus order to be consistent with the sequential reading order. + +

+
    + + +
  • People with mobility impairments who must rely on keyboard access for operating a + page benefit from a logical, usable focus order. + +
    • + + +
  • People with disabilities that make reading difficult can become disoriented when tabbing + takes focus someplace unexpected. They benefit from a logical focus order. + +
    • + + +
  • People with visual impairments can become disoriented when tabbing takes focus someplace + unexpected or when they cannot easily find the content surrounding an interactive + element. + +
    • + + +
  • Only a small portion of the page may be visible to an individual using a screen magnifier + at a high level of magnification. Such a user may interpret a field in the wrong context + if the focus order is not logical. + +
    • + + +
+
+
+

Examples

+
    + + +
  • On a web page that contains a tree of interactive controls, the user can use the up + and down arrow keys to move from tree node to tree node. Pressing the right arrow + key expands a node, then using the down arrow key moves into the newly expanded nodes. + +
    • + + +
  • A Web page implements modeless dialogs via scripting. When the trigger button is activated, + a dialog opens. The interactive elements in the dialog are inserted in the focus order + immediately after the button. When the dialog is open, the focus order goes from the + button to the elements of the dialog, then to the interactive element following the + button. When the dialog is closed, the focus order goes from the button to the following + element. + +
    • + + +
  • A Web page implements modal dialogs via scripting. When the trigger button is activated, + a dialog opens and focus is set within the dialog. As + long as the dialog is open, focus is limited to the elements of the dialog. When the + dialog is dismissed, focus returns to the button or the element following the button. + +
    • + + +
  • + + +

    An HTML Web page is created with the left hand navigation occurring in the HTML after + the main body content, and styled with CSS to appear on the left hand side of the + page. This is done to allow focus to move to the main body content first without requiring + tabIndex attributes or JavaScript. + +

    + + +
    +

    Note

    +
    + + +

    While this example passes the Success Criterion, it is not necessarily true that all + CSS positioning would. More complex positioning examples may or may not preserve meaning + and operability + +

    + + +
    +
    + + +
    • + + +
  • + + +

    The following example fails to meet the Success Criterion: +

    + + +

    A company's Web site includes a form that collects marketing data and allows users + to subscribe to several newsletters published by the company. The section of the form + for collecting marketing data includes fields such as name, street address, city, + state or province, and postal code. Another section of the form includes several checkboxes + so that users can indicate newsletters they want to receive. However, the tab order + for the form skips between fields in different sections of the form, so that focus + moves from the name field to a checkbox, then to the street address, then to another + checkbox. +

    + +
    • + + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
keyboard interface
+
+ + + +

interface used by software to obtain keystroke input

+ + +
+

Note

+
+ +

A keyboard interface allows users to provide keystroke input to programs even if the + native technology does not contain a keyboard. +

+ + + + +
+
+ + +
+

Note

+

Operation of the application (or parts of the application) through a keyboard-operated + mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard + interface because operation of the program is through its pointing device interface, + not through its keyboard interface. + +

+
+ + + +
+
navigated sequentially
+
+ + + +

navigated in the order defined for advancing focus (from one element to the next) + using a keyboard interface + +

+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/focus-visible.html b/wcag22/understanding/focus-visible.html new file mode 100644 index 0000000..297096f --- /dev/null +++ b/wcag22/understanding/focus-visible.html @@ -0,0 +1,367 @@ + + + + + + Understanding Success Criterion 2.4.7: Focus Visible | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.7:Focus Visible (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users know which element has keyboard focus.
+ +
What to do
+
Ensure each item receiving focus has a visible indicator.
+ +
Why it's important
+
Without a focus indicator, sighted keyboard users cannot operate the page.
+ +
+
+
+

Intent

+

The purpose of this success criterion is to help a person know which element has the + keyboard focus. + +

+

“Mode of operation” accounts for user agents which may not always show a focus indicator, + or only show the focus indicator when the keyboard is used. User agents may optimise + when the focus indicator is shown, such as only showing it when a keyboard is used. + Authors are responsible for providing at least one mode of operation where the focus + is visible. In most cases there is only one mode of operation so this success criterion + applies. The focus indicator must not be time limited, when the keyboard focus is + shown it must remain. +

+

Note that a keyboard focus indicator can take different forms. New in WCAG 22: While Focus Visible does not specify what that form is, 2.4.13 Focus Appearance (Level AAA) provides guidance on creating a consistent, visible indicator.

+
+
+

Benefits

+
    + +
  • This Success Criterion helps anyone who relies on the keyboard to operate the page, + by letting them visually determine the component on which keyboard operations will + interact at any point in time. + +
    • + +
  • People with attention limitations, short term memory limitations, or limitations in + executive processes benefit by being able to discover where the focus is located. + +
    • + +
+
+
+

Examples

+
    + +
  • When text fields receive focus, a vertical bar is displayed in the field, indicating + that the user can insert text, OR all of the text is highlighted, indicating that + the user can type over the text. + +
    • + +
  • When a user interface control receives focus, a visible border is displayed around + it. + +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/headings-and-labels.html b/wcag22/understanding/headings-and-labels.html new file mode 100644 index 0000000..d556168 --- /dev/null +++ b/wcag22/understanding/headings-and-labels.html @@ -0,0 +1,824 @@ + + + + + + Understanding Success Criterion 2.4.6: Headings and Labels | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.6:Headings and Labels (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
A page's content is described in headings and labels
+ +
What to do
+
Provide descriptive headings and labels
+ +
Why it's important
+
People can orient themselves, especially those with cognitive or visual disabilities.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to help users understand what information + is contained in Web pages and how that information is organized. When headings are + clear and descriptive, users can find the information they seek more easily, and they + can understand the relationships between different parts of the content more easily. + Descriptive labels help users identify specific components within the content. + +

+

Labels and headings do not need to be lengthy. A word, or even a single character, + may suffice if it provides an appropriate cue to finding and navigating content. + +

+

This Success Criterion does not require headings or labels. This Success Criterion + requires that if headings or labels are provided, they be descriptive. This Success + Criterion also + does not require that content acting as a heading or label be correctly marked up + or + identified – this aspect is covered separately by + 1.3.1: Info and Relationships. It is possible for content + to pass this Success Criterion (providing descriptive content that acts as headings + or labels) while failing + Success Criterion 1.3.1 (if the headings or labels aren't correctly marked up/identified). + Conversely, + it is also possible for content to pass Success Criterion 1.3.1 (with headings or + labels correctly + marked up or identified), while failing this Success Criterion (if those headings + or labels are not + sufficiently clear or descriptive). + +

+

Further, in the case of labels, this Success Criterion does not take into consideration + whether or not + alternative methods of providing an accessible name for form controls and inputs has + been + used – this aspect is covered separately by 4.1.2: Name, Role and Value. It is possible + for controls and inputs to have an appropriate accessible name (e.g. using aria-label="…") + and therefore pass Success Criterion 4.1.2, but to still fail this Success Criterion + (if the label is not + sufficiently clear or descriptive). + +

+

This success criterion does not require the use of labels; however, it does require + that if labels are present, they must be sufficiently clear or descriptive. Please + see 3.3.2: Labels or Instructions for more information on the use of labels. + +

+
+
+

Benefits

+
    + +
  • Descriptive headings are especially helpful for users who have disabilities that make + reading slow and for people with limited short-term memory. These people benefit when + section titles make it possible to predict what each section contains. +
    • + +
  • Form input controls with labels that clearly describe the content that is expected + to be + entered helps users know how to successfully complete the form. +
    • + +
  • When headings and labels are also correctly marked up and identified in accordance + with + 1.3.1: Info and Relationships, this Success Criterion + helps people who use screen readers by ensuring that labels and headings are clearer + when + presented in a different format – for example, in an automatically generated list + of + headings, a table of contents, or when jumping from heading to heading within a page. +
    • + +
+
+
+

Examples

+
+ +
A news site
+ +
The home page of a news site lists the headlines for the top stories of the hour. + Under each heading are the first 35 words of the story and a link to the full article. + Each headline gives a clear idea of the article's subject. +
+ +
A guide on how to write well
+ +
A guide on writing contains the following section titles: How To Write Well, + Cut Out Useless Words, Identify Unnecessary Words, and so on. + The section headings are clear and concise and the structure of the information is + reflected in the structure of the headings. +
+ +
Consistent headings in different articles
+ +
A Web site contains papers from a conference. Submissions to the conference are required + to have the following organization: Summary, Introduction, [other sections unique + to this article], Conclusion, Author Biography, Glossary, and Bibliography. + The title of each Web page clearly identifies the article it contains, creating a + useful balance + between the uniqueness of the articles and the consistency of the section headings. +
+ +
A form asking for the name of the user
+ +
A form asks for the name of the user. It consists of two input fields to ask for the + first + and last name. The first field is labeled First name, the second is labeled Last name. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+
    + +
  1. + G130: Providing descriptive headings + +
    2. + +
  2. + G131: Providing descriptive labels + +
    3. + +
+
+

Note

+
+ + +

+ Headings and labels must be programmatically determined, per + Success Criterion 1.3.1. + +

+ + +
+
+
+
+
+
+ +

Key Terms

+ +
ascii art
+
+ + + +

picture created by a spatial arrangement of characters or glyphs (typically from the + 95 printable characters defined by ASCII) + +

+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
label
+
+ + + +

+ text or other component with a text alternative that is presented to a user to identify a component within Web content + +

+ + +
+

Note

+

A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases + the name and the label are the same. + +

+
+ + +
+

Note

+

The term label is not limited to the label element in HTML.

+
+ + + +
+
name
+
+ + + +

text by which software can identify a component within Web content to the user

+ + +
+

Note

+

The name may be hidden and only exposed by assistive technology, whereas a label is presented to all users. In many (but not all) cases, the label and the name are + the same. + +

+
+ + +
+

Note

+

This is unrelated to the name attribute in HTML.

+
+ + + +
+
non-text content
+
+ + + +

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language + +

+ + +
+

Note

+

This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), + and images representing text + +

+
+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
text alternative
+
+ + + +

+ Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. + Programmatically associated text is text whose location can be programmatically determined + from the non-text content. + +

+ + + + + +
+

Note

+

Refer to Understanding Text Alternatives for more information. + +

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/help.html b/wcag22/understanding/help.html new file mode 100644 index 0000000..b0a9abc --- /dev/null +++ b/wcag22/understanding/help.html @@ -0,0 +1,384 @@ + + + + + + Understanding Success Criterion 3.3.5: Help | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.3.5:Help (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can avoid making mistakes.
+ +
What to do
+
Provide help to users on the function currently being performed.
+ +
Why it's important
+
People with cognitive or other disabilities can complete their tasks more easily.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to help users avoid making mistakes. Some + users with disabilities may be more likely to make mistakes than users without disabilities. + Using context-sensitive help, users find out how to perform an operation without losing + track of what they are doing. + +

+

Context-sensitive help only needs to be provided when the label is not + sufficient to describe all functionality. The existence of context-sensitive help + should be obvious to the user and they should be able to obtain it whenever they require + it. + + +

+

The content author may provide the help text, or the user agent may provide the help + text based on technology-specific, programmatically determined information. + + +

+
+
+

Benefits

+
    + + +
  • Assistance for text input helps individuals with writing disabilities and people with + reading and intellectual disabilities who often have difficulty writing text in forms + or other places that need text input. + +
    • + + +
  • Additionally, these kinds of assistance help people who are aging and have the same + difficulty in text input and/or mouse operation. + +
    • + + +
+
+
+

Examples

+
+ +
on-line job application
+ +
Some of the questions may be hard for new job seekers to understand. A help link + next to each question provides instructions and explanations for each question. +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If a form requires text input:

+ + + + + +
+
+ + +

Situation B: If a form requires text input in an expected data format:

+ + + + + +
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+
+
+ +

Key Terms

+ +
context-sensitive help
+
+ + + +

help text that provides information related to the function currently being performed

+ + +
+

Note

+

Clear labels can act as context-sensitive help.

+
+ + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/identify-input-purpose.html b/wcag22/understanding/identify-input-purpose.html new file mode 100644 index 0000000..dc017fd --- /dev/null +++ b/wcag22/understanding/identify-input-purpose.html @@ -0,0 +1,523 @@ + + + + + + Understanding Success Criterion 1.3.5: Identify Input Purpose | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.3.5:Identify Input Purpose (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
It is easier to fill out forms.
+ +
What to do
+
Use code to indicate the purpose of common inputs, where technology allows.
+ +
Why it's important
+
Some people with cognitive disabilities may not understand the input's purpose from + the label alone. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that the purpose of a form input + collecting information about the user can be programmatically determined, so that + user agents can extract and present this purpose to users using different modalities. + The ability to programmatically declare the specific kind of data expected in a particular + field makes filling out forms easier, especially for people with certain cognitive + disabilities. +

+

Appropriate visible labels and instruction can help users understand the purpose of + form input fields, but users may benefit from having fields that collect specific + types of information be rendered in an unambiguous, consistent, and possibly customized + way for different modalities - either through defaults in their user agent, or through + the aid of assistive technologies. +

+

For some input fields, the type attribute already offers a way to broadly specify the intention of the input field, + for example, <input type="tel">, <input type="email">, or <input type="password">. However, these are only very broad categories, describing the type of input, but + not necessarily its purpose, especially as it relates to user-specific input fields. + As an example, type="email" indicates that the field is for an e-mail address but does not clarify if the purpose + is for entering the user's e-mail address or some other person's e-mail. +

+

This success criterion defines the types of user interface component input purposes, + found in Section 7 of the WCAG 2.1 Recommendation, that must be programmatically identifiable. When these user input purposes are present, + and if the technology supports doing so, the field purpose must be programmatically + identifiable. +

+

The HTML autocomplete attribute only accepts a certain number of specific well-defined fixed values. This + allows a more fine-grained definition or identification of purpose than the type attribute, + for example, by allowing the author to specify a specific type of name: Name (autocomplete="name"), Given Name (autocomplete="given-name"), Family Name (autocomplete="family-name"), as well as Username (autocomplete="username"), and Nickname (autocomplete="nickname"). +

+

By adopting and repurposing this predefined taxonomy of definitions, user agents and + assistive technologies can now present the purpose of the inputs to users in different + modalities. For example, assistive technologies may display familiar icons next to + input fields to help users who have difficulties reading. An icon of a birthday cake + may be shown in front of an input field with autocomplete="bday", or the icon of a telephone in front of an input field with autocomplete="tel". +

+

In addition to repurposing this taxonomy, when the autocomplete attribute technique + is used to meet this Success Criterion, browsers and other user-agents can suggest + and 'autofill' the right content by autocompleting these fields based on past user + input stored in the browser. By defining more granular definitions of common input + purposes, for example “Birthday” (autocomplete="bday"), browsers can store personalized values for each of these fields (the user's birthday + date). The user is relieved of having to type the information and can instead confirm + or, if needed, change the value of the field, a significant benefit for users with + memory issues, dyslexia, and other disabilities. Because the autocomplete values are independent of language, users that may not be familiar with the text + used to visually identify user input fields (the label) can still have that purpose + consistently identified to them due to the fixed taxonomy of terms. +

+

If an input field accepts two different types of input purpose (as in combined user + name/user email fields) and the technology used does not allow multiple purpose values + to be defined, it is valid to provide either one or the other value or leave out the + designation of input purpose altogether. +

+

When the user agent and assistive technology support for other metadata formats matures, + metadata schemes like the WAI-Adapt: Symbols Module may be used in addition or instead of the HTML autocomplete attribute to identify + the purpose of input fields. They can also support automated adaptations that identify + and match author-provided input labels to defined vocabularies or symbols that are + used instead for labelling inputs. +

+
+
+

Benefits

+
    + +
  • People with language and memory related disabilities or disabilities that affects + executive function and decision-making benefit from the browser auto-filling personal + information (such as name or address) when the autocomplete attribute is used to meet + this Success Criterion, which means information does not need to be remembered by + the user. +
    • + +
  • People with cerebral palsy, stroke, head injury, motor neuron disease or learning + disability sometimes prefer images for communication. They can employ assistive technology + which adds icons to input fields to communicate the purpose of the fields visually. +
    • + +
  • People with motor impairments also benefit from reducing the need for manual input + when filling out forms. +
    • + +
+
+
+

Examples

+
+ +
A contact form using autofill
+ +
A contact form auto-fills in the fields for name, street, post code, city, telephone + number and email address from autofill values stored in the user's browser. Assistive + technology can offer a customized way of identifying particular input fields, for + example drawing on a set of symbols / icons that is familiar to the user, to communicate + the purpose of the fields visually. +
+ +
An order form with separate billing and shipping address
+ +
A product order form fills in the address fields for billing address and a separate + set of address fields for the shipping address, using the autofill detail tokens 'billing' + and 'shipping' +
+ +
A contact form using icons
+ +
A browser plugin to add icons inserts icons representing the person's name, home address, + telephone number and email address to identify the input purpose visually. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/identify-purpose.html b/wcag22/understanding/identify-purpose.html new file mode 100644 index 0000000..eb922c3 --- /dev/null +++ b/wcag22/understanding/identify-purpose.html @@ -0,0 +1,556 @@ + + + + + + Understanding Success Criterion 1.3.6: Identify Purpose | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.3.6:Identify Purpose (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
It is easier to operate and navigate content.
+ +
What to do
+
Use code to indicate the meaning of all controls and other key information, where + available. +
+ +
Why it's important
+
Some people with cognitive disabilities may not understand a control's purpose from + the name alone. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that the purpose of many elements + on a page can be programmatically determined, so that user agents can extract and + present that purpose to users using different modalities. +

+

Many users with limited vocabularies rely on familiar terms or symbols in order to + use the web. However, what is familiar to one user may not be familiar to another. + When authors indicate the purpose, users can take advantage of personalization and + user preferences to load a set of symbols or vocabulary familiar to them. +

+

This Success Criterion requires the author to programmatically associate the purpose + of icons, regions and components (such as buttons, links, and fields) so that user + agents can determine the purpose of each and adapt indicators or terminology to make + them understandable for the user. It is achieved by adding semantics or metadata that + provide this context. It is similar to adding role information (as required by 4.1.2) + but instead of providing information about what the UI component is (such as an image) + it provides information about what the component represents (such as a link to the + home page). +

+

Identifying regions of the page allows people to remove or highlight regions with + their user agent. +

+

Products for people who are non-vocal often use symbols to help users communicate. + These symbols are in fact people's language. Unfortunately, many of these symbols + are both subject to copyright and not interoperable. That means end users can only + use one device, and cannot use content, apps, or assistive technologies that have + not been made by a single company. +

+

This Success Criterion enables symbols to be interoperable so that symbol users can + understand different content that was not just made by one company. When users' symbols + are mapped to the same nodes, then user agents can load the user-understandable symbol. + People can then buy the symbols and use them across different devices or applications. + (Note that the symbols would still be proprietary, but they could then be interoperable.) +

+
+
+

Benefits

+

People who benefit have many different cognitive disabilities including:

+
    + +
  • Memory
    • + +
  • Focus and attention
    • + +
  • Language-related
    • + +
  • Executive function and decision making.
    • + +
+

Meeting this Success Criterion helps users who need extra support or a familiar interface, + including the need for: +

+
    + +
  • Symbols and graphics with which users are familiar
    • + +
  • Fewer features and less cognitive overload
    • + +
  • Keyboard shortcuts
    • + +
+
+
+

Examples

+
    + +
  • A website uses ARIA landmarks to identify the regions of the page, and users can hide areas that do not have a + role of main. +
    • + +
  • The links in the navigation of a website are marked up so that users can add their + own icons. +
    • + +
  • Icons on a website are marked up so that users can substitute their own icon sets + into the page. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+
    + +
  • Enabling user agents to find the version of the content that best fits their needs
    • + +
  • Using semantics to identify important features (e.g., coga-simplification="simplest") +
    • + +
  • Using aria-invalid and aria-required
    • + +
+
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
region
+
+ + +

perceivable, programmatically determined section of content

+ +
+

Note

+

In HTML, any area designated with a landmark role would be a region.

+
+ + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/images-of-text-no-exception.html b/wcag22/understanding/images-of-text-no-exception.html new file mode 100644 index 0000000..0803944 --- /dev/null +++ b/wcag22/understanding/images-of-text-no-exception.html @@ -0,0 +1,739 @@ + + + + + + Understanding Success Criterion 1.4.9: Images of Text (No Exception) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.9:Images of Text (No Exception) (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can always adjust how text is presented.
+ +
What to do
+
Do not use pictures of text unless there is no other way to present information.
+ +
Why it's important
+
People cannot alter how text looks in images.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to enable people who require a particular + visual presentation of text to be able to adjust the text presentation as required. + This includes people who require the text in a particular font size, foreground and + background color, font family, line spacing or alignment. + +

+

This means implementing the text in a manner that allows its presentation to be changed + or providing a mechanism by which users can select an alternate presentation. Using + images of text is an example of an implementation that does not allow users to alter + the presentation of the text within it. + +

+

In some situations, a particular visual presentation of the text is essential to the + information being conveyed. This means that information would be lost without that + particular visual presentation. In this case implementing the text in a manner that + allows its presentation to be changed is not required. This includes text that demonstrates + a particular visual aspect of the text, such as a particular font family, or text + that conveys an identity, such as text within a company logo. + +

+

Text that is decorative does not require implementing the text in a manner that allows + its presentation to be changed. + +

+

The definition of image of text contains the note: Note: This does not include text + that is part of a picture that contains significant + other visual content. Examples of such pictures include graphs, screenshots, and diagrams + which visually + convey important information through more than just text. + +

+
+
+

Benefits

+
    + + +
  • People with low vision (who may have trouble reading the text with the authored font + family, size and/or color). + +
    • + + +
  • People with visual tracking problems (who may have trouble reading the text with the + authored line spacing and/or alignment). + +
    • + + +
  • People with cognitive disabilities that affect reading.
    • + + +
+
+
+

Examples

+
+ +
A quote
+ +
A Web page contains a quote. The quote itself is presented as italicized text, indented + from the left margin. The name of the person to whom the quote is attributed is below + the quote with 1.5x the line space and further indented from the left margin. CSS + is used to position the text; set the spacing between lines; as well as display the + text's font family, size, color and decoration. +
+ +
Navigation items
+ +
A Web page contains a menu of navigation links that have both an icon and text to + describe their target. CSS is used to display the text's font family, size and foreground + and background colors; as well as the spacing between the navigation links. +
+ +
A logo containing text
+ +
A Web site contains the organization's logo in the top left corner of each Web page. + The logo contains logotype (text as part, or all, of the logo). The visual presentation + of the text is essential to the identity of the logo and is included as a gif image + which does not allow the text characteristics to be changed. The image has a text + alternative. +
+ +
Representation of a font family
+ +
A Web page contains information about a particular font family. Substituting the font + family with another font would defeat the purpose of the representation. The representation + is included as a jpeg image which does not allow the text characteristics to be changed. + The image has a text alternative. +
+ +
A representation of a letter
+ +
A Web page contains a representation of an original letter. The depiction of the letter + in its original format is essential to information being conveyed about the time period + in which it was written. The letter is included as a gif image which does not allow + the text characteristics to be changed. The image has a text alternative. +
+ +
Symbolic text characters
+ +
A form allows users to enter blocks of text. The form provides a number of buttons, + including functions to style the text and check spelling. Some of the buttons use + text characters that do not form a sequence that expresses something in human language. + For example "B" to increase font weight, "I" to italicize the text and "ABC" to check + the spelling. The symbolic text characters are included as gif images which do not + allow the text characteristics to be changed. The buttons have text alternatives. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
image of text
+
+ + + +

text that has been rendered in a non-text form (e.g., an image) in order to achieve + a particular visual effect + +

+ + +
+

Note

+

This does not include text that is part of a picture that contains significant other visual content. + +

+
+ + + + + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
pure decoration
+
+ + + +

serving only an aesthetic purpose, providing no information, and having no functionality

+ + +
+

Note

+

Text is only purely decorative if the words can be rearranged or substituted without + changing their purpose. + +

+
+ + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/images-of-text.html b/wcag22/understanding/images-of-text.html new file mode 100644 index 0000000..30a2d3d --- /dev/null +++ b/wcag22/understanding/images-of-text.html @@ -0,0 +1,792 @@ + + + + + + Understanding Success Criterion 1.4.5: Images of Text | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.5:Images of Text (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can adjust how text is presented.
+ +
What to do
+
Use text instead of pictures of text.
+ +
Why it's important
+
People cannot alter how text looks in images.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to encourage authors, who are using technologies + which are capable of achieving their desired default visual presentation, to enable + people who require a particular visual presentation of text to be able to adjust the + text presentation as needed. This includes people who require the text in a particular + font size, foreground and background color, font family, line spacing or alignment. + +

+

If an author can use text to achieve the same visual effect, he or she should present + the information as text rather than using an image. If for any reason, the author + cannot format the text to get the same effect, the effect won't be reliably presented + on the commonly available user agents, or using a technology to meet this criterion + would interfere with meeting other criteria such as 1.4.4, then an image of text can + be used. This includes instances where a particular presentation of text is essential + to the information being conveyed, such as type samples, logotypes, branding, etc. + Images of text may also be used in order to use a particular font that is either not + widely deployed or which the author doesn't have the right to redistribute, or to + ensure that the text would be anti-aliased on all user agents. + +

+

Images of text can also be used where it is possible for users to customize the image + of text to match their requirements. + +

+

The definition of image of text contains the note: Note: This does not include text + that is part of a picture that contains significant + other visual content. Examples of such pictures include graphs, screenshots, and diagrams + which visually + convey important information through more than just text. + +

+

Techniques for satisfying this Success Criterion are the same as those for Success + Criterion 1.4.9, except that they only need to apply if the visual presentation can + be achieved with the technologies that the author is using. For Success Criterion + 1.4.9, the sufficient techniques would be applied only when the user can customize + the output. + +

+

See also + 1.4.9: Images of Text (No Exception). + +

+
+
+

Benefits

+
    + + +
  • People with low vision (who may have trouble reading the text with the authored font + family, size and/or color). + +
    • + + +
  • People with visual tracking problems (who may have trouble reading the text with the + authored line spacing and/or alignment). + +
    • + + +
  • People with cognitive disabilities that affect reading.
    • + + +
+
+
+

Examples

+
+ +
Styled Headings
+ +
Rather than using bitmap images to present headings in a specific font and size, an + author uses CSS to achieve the same result. +
+ +
Dynamically Generated Images
+ +
A Web page uses server-side scripting to present text as an an image. The page includes + controls that allow the user to adjust the font size and foreground and background + colors of the generated image. +
+ +
A quote
+ +
A Web page contains a quote. The quote itself is presented as italicized text, indented + from the left margin. The name of the person to whom the quote is attributed is below + the quote with 1.5x the line space and further indented from the left margin. CSS + is used to position the text; set the spacing between lines; as well as display the + text's font family, size, color and decoration. +
+ +
Navigation items
+ +
A Web page contains a menu of navigation links that have both an icon and text to + describe their target. CSS is used to display the text's font family, size and foreground + and background colors; as well as the spacing between the navigation links. +
+ +
A logo containing text
+ +
A Web site contains the organization's logo in the top left corner of each Web page. + The logo contains logotype (text as part, or all, of the logo). The visual presentation + of the text is essential to the identity of the logo and is included as a gif image + which does not allow the text characteristics to be changed. The image has a text + alternative. +
+ +
Representation of a font family
+ +
A Web page contains information about a particular font family. Substituting the font + family with another font would defeat the purpose of the representation. The representation + is included as a jpeg image which does not allow the text characteristics to be changed. + The image has a text alternative. +
+ +
A representation of a letter
+ +
A Web page contains a representation of an original letter. The depiction of the letter + in its original format is essential to information being conveyed about the time period + in which it was written. The letter is included as a gif image which does not allow + the text characteristics to be changed. The image has a text alternative. +
+ +
Symbolic text characters
+ +
A form allows users to enter blocks of text. The form provides a number of buttons, + including functions to style the text and check spelling. Some of the buttons use + text characters that do not form a sequence that expresses something in human language. + For example "B" to increase font weight, "I" to italicize the text and "ABC" to check + the spelling. The symbolic text characters are included as gif images which do not + allow the text characteristics to be changed. The buttons have text alternatives. +
+ +
Customizable font settings in images of text
+ +
A Web site allows users to specify font settings and all images of text on the site + are then provided based on those settings. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+
+ + +

CSS Techniques

+ + + + + +
+
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
image of text
+
+ + + +

text that has been rendered in a non-text form (e.g., an image) in order to achieve + a particular visual effect + +

+ + +
+

Note

+

This does not include text that is part of a picture that contains significant other visual content. + +

+
+ + + + + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
visually customized
+
+ + + +

the font, size, color, and background can be set

+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/img/button-background.png b/wcag22/understanding/img/button-background.png new file mode 100644 index 0000000..fae0722 Binary files /dev/null and b/wcag22/understanding/img/button-background.png differ diff --git a/wcag22/understanding/img/button-example2.png b/wcag22/understanding/img/button-example2.png new file mode 100644 index 0000000..2067cd7 Binary files /dev/null and b/wcag22/understanding/img/button-example2.png differ diff --git a/wcag22/understanding/img/button-focus-dark-border.png b/wcag22/understanding/img/button-focus-dark-border.png new file mode 100644 index 0000000..70275c0 Binary files /dev/null and b/wcag22/understanding/img/button-focus-dark-border.png differ diff --git a/wcag22/understanding/img/button-focus-indicator.png b/wcag22/understanding/img/button-focus-indicator.png new file mode 100644 index 0000000..98e3eb1 Binary files /dev/null and b/wcag22/understanding/img/button-focus-indicator.png differ diff --git a/wcag22/understanding/img/button-focus-outlines.png b/wcag22/understanding/img/button-focus-outlines.png new file mode 100644 index 0000000..96e598d Binary files /dev/null and b/wcag22/understanding/img/button-focus-outlines.png differ diff --git a/wcag22/understanding/img/button-pointer-below-tooltip.png b/wcag22/understanding/img/button-pointer-below-tooltip.png new file mode 100644 index 0000000..77f30d3 Binary files /dev/null and b/wcag22/understanding/img/button-pointer-below-tooltip.png differ diff --git a/wcag22/understanding/img/button-pointer-on-tooltip.png b/wcag22/understanding/img/button-pointer-on-tooltip.png new file mode 100644 index 0000000..e9c8b94 Binary files /dev/null and b/wcag22/understanding/img/button-pointer-on-tooltip.png differ diff --git a/wcag22/understanding/img/button-pointer-tooltip.png b/wcag22/understanding/img/button-pointer-tooltip.png new file mode 100644 index 0000000..1077019 Binary files /dev/null and b/wcag22/understanding/img/button-pointer-tooltip.png differ diff --git a/wcag22/understanding/img/button-pointer.png b/wcag22/understanding/img/button-pointer.png new file mode 100644 index 0000000..4eb8fb7 Binary files /dev/null and b/wcag22/understanding/img/button-pointer.png differ diff --git a/wcag22/understanding/img/buttons-text-symbols.png b/wcag22/understanding/img/buttons-text-symbols.png new file mode 100644 index 0000000..31e6453 Binary files /dev/null and b/wcag22/understanding/img/buttons-text-symbols.png differ diff --git a/wcag22/understanding/img/checkbox-example1.png b/wcag22/understanding/img/checkbox-example1.png new file mode 100644 index 0000000..ea5fddd Binary files /dev/null and b/wcag22/understanding/img/checkbox-example1.png differ diff --git a/wcag22/understanding/img/checkbox-example2.png b/wcag22/understanding/img/checkbox-example2.png new file mode 100644 index 0000000..3edf1b5 Binary files /dev/null and b/wcag22/understanding/img/checkbox-example2.png differ diff --git a/wcag22/understanding/img/checkbox-example3.png b/wcag22/understanding/img/checkbox-example3.png new file mode 100644 index 0000000..fca5879 Binary files /dev/null and b/wcag22/understanding/img/checkbox-example3.png differ diff --git a/wcag22/understanding/img/checkbox-example4.png b/wcag22/understanding/img/checkbox-example4.png new file mode 100644 index 0000000..a190351 Binary files /dev/null and b/wcag22/understanding/img/checkbox-example4.png differ diff --git a/wcag22/understanding/img/checkbox-example5.png b/wcag22/understanding/img/checkbox-example5.png new file mode 100644 index 0000000..1ec8e43 Binary files /dev/null and b/wcag22/understanding/img/checkbox-example5.png differ diff --git a/wcag22/understanding/img/checkbox-purple.png b/wcag22/understanding/img/checkbox-purple.png new file mode 100644 index 0000000..1eca069 Binary files /dev/null and b/wcag22/understanding/img/checkbox-purple.png differ diff --git a/wcag22/understanding/img/checkbox.png b/wcag22/understanding/img/checkbox.png new file mode 100644 index 0000000..99cf15e Binary files /dev/null and b/wcag22/understanding/img/checkbox.png differ diff --git a/wcag22/understanding/img/component-complex-both-unselected.png b/wcag22/understanding/img/component-complex-both-unselected.png new file mode 100644 index 0000000..8c68c31 Binary files /dev/null and b/wcag22/understanding/img/component-complex-both-unselected.png differ diff --git a/wcag22/understanding/img/component-complex-both.png b/wcag22/understanding/img/component-complex-both.png new file mode 100644 index 0000000..771af99 Binary files /dev/null and b/wcag22/understanding/img/component-complex-both.png differ diff --git a/wcag22/understanding/img/component-complex-sub.png b/wcag22/understanding/img/component-complex-sub.png new file mode 100644 index 0000000..9df2499 Binary files /dev/null and b/wcag22/understanding/img/component-complex-sub.png differ diff --git a/wcag22/understanding/img/component-complex-whole.png b/wcag22/understanding/img/component-complex-whole.png new file mode 100644 index 0000000..1d0b6d7 Binary files /dev/null and b/wcag22/understanding/img/component-complex-whole.png differ diff --git a/wcag22/understanding/img/contrast-currency-down.png b/wcag22/understanding/img/contrast-currency-down.png new file mode 100644 index 0000000..ffbf54f Binary files /dev/null and b/wcag22/understanding/img/contrast-currency-down.png differ diff --git a/wcag22/understanding/img/contrast-gradient.png b/wcag22/understanding/img/contrast-gradient.png new file mode 100644 index 0000000..52f150c Binary files /dev/null and b/wcag22/understanding/img/contrast-gradient.png differ diff --git a/wcag22/understanding/img/contrast-magnet.png b/wcag22/understanding/img/contrast-magnet.png new file mode 100644 index 0000000..6abf276 Binary files /dev/null and b/wcag22/understanding/img/contrast-magnet.png differ diff --git a/wcag22/understanding/img/contrast-phone.png b/wcag22/understanding/img/contrast-phone.png new file mode 100644 index 0000000..33713e3 Binary files /dev/null and b/wcag22/understanding/img/contrast-phone.png differ diff --git a/wcag22/understanding/img/css-pixel-by-device.png b/wcag22/understanding/img/css-pixel-by-device.png new file mode 100644 index 0000000..4f03bf4 Binary files /dev/null and b/wcag22/understanding/img/css-pixel-by-device.png differ diff --git a/wcag22/understanding/img/double-space.gif b/wcag22/understanding/img/double-space.gif new file mode 100644 index 0000000..454ad01 Binary files /dev/null and b/wcag22/understanding/img/double-space.gif differ diff --git a/wcag22/understanding/img/dropdown.png b/wcag22/understanding/img/dropdown.png new file mode 100644 index 0000000..8c7cf92 Binary files /dev/null and b/wcag22/understanding/img/dropdown.png differ diff --git a/wcag22/understanding/img/dropdown2.png b/wcag22/understanding/img/dropdown2.png new file mode 100644 index 0000000..68446c9 Binary files /dev/null and b/wcag22/understanding/img/dropdown2.png differ diff --git a/wcag22/understanding/img/dynamic-pie-chart.png b/wcag22/understanding/img/dynamic-pie-chart.png new file mode 100644 index 0000000..df1e31a Binary files /dev/null and b/wcag22/understanding/img/dynamic-pie-chart.png differ diff --git a/wcag22/understanding/img/first-button-example.png b/wcag22/understanding/img/first-button-example.png new file mode 100644 index 0000000..dad977c Binary files /dev/null and b/wcag22/understanding/img/first-button-example.png differ diff --git a/wcag22/understanding/img/focus-indicator-background-passing.png b/wcag22/understanding/img/focus-indicator-background-passing.png new file mode 100644 index 0000000..cefbb10 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-background-passing.png differ diff --git a/wcag22/understanding/img/focus-indicator-background.png b/wcag22/understanding/img/focus-indicator-background.png new file mode 100644 index 0000000..67562d3 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-background.png differ diff --git a/wcag22/understanding/img/focus-indicator-basic.png b/wcag22/understanding/img/focus-indicator-basic.png new file mode 100644 index 0000000..0966659 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-basic.png differ diff --git a/wcag22/understanding/img/focus-indicator-box-shadow-only.png b/wcag22/understanding/img/focus-indicator-box-shadow-only.png new file mode 100644 index 0000000..bedf2aa Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-box-shadow-only.png differ diff --git a/wcag22/understanding/img/focus-indicator-box-shadow.png b/wcag22/understanding/img/focus-indicator-box-shadow.png new file mode 100644 index 0000000..bb6bc7d Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-box-shadow.png differ diff --git a/wcag22/understanding/img/focus-indicator-browser-defaults-modified-background.png b/wcag22/understanding/img/focus-indicator-browser-defaults-modified-background.png new file mode 100644 index 0000000..fdb1c6f Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-browser-defaults-modified-background.png differ diff --git a/wcag22/understanding/img/focus-indicator-browser-defaults-unmodified.png b/wcag22/understanding/img/focus-indicator-browser-defaults-unmodified.png new file mode 100644 index 0000000..f240bb4 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-browser-defaults-unmodified.png differ diff --git a/wcag22/understanding/img/focus-indicator-browser-defaults.html b/wcag22/understanding/img/focus-indicator-browser-defaults.html new file mode 100644 index 0000000..e865ec7 --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-browser-defaults.html @@ -0,0 +1,37 @@ + + + Figure source: Focus Indicator Custom Shapes + + +
+

Figure source: Focus Indicator Browser Defaults

+
+

Unmodified indicator background

+ + + +
+
+

Blue indicator background

+ + + +
+
+ + diff --git a/wcag22/understanding/img/focus-indicator-checkboxs.png b/wcag22/understanding/img/focus-indicator-checkboxs.png new file mode 100644 index 0000000..933ef99 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-checkboxs.png differ diff --git a/wcag22/understanding/img/focus-indicator-checked.png b/wcag22/understanding/img/focus-indicator-checked.png new file mode 100644 index 0000000..438f490 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-checked.png differ diff --git a/wcag22/understanding/img/focus-indicator-circle.png b/wcag22/understanding/img/focus-indicator-circle.png new file mode 100644 index 0000000..61fccb8 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-circle.png differ diff --git a/wcag22/understanding/img/focus-indicator-custom-shapes-inset.png b/wcag22/understanding/img/focus-indicator-custom-shapes-inset.png new file mode 100644 index 0000000..7068585 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-custom-shapes-inset.png differ diff --git a/wcag22/understanding/img/focus-indicator-custom-shapes-side-highlights.png b/wcag22/understanding/img/focus-indicator-custom-shapes-side-highlights.png new file mode 100644 index 0000000..4c46f12 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-custom-shapes-side-highlights.png differ diff --git a/wcag22/understanding/img/focus-indicator-custom-shapes.html b/wcag22/understanding/img/focus-indicator-custom-shapes.html new file mode 100644 index 0000000..25f4a1a --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-custom-shapes.html @@ -0,0 +1,71 @@ + + + Figure source: Focus Indicator Custom Shapes + + +
+

Figure source: Focus Indicator Custom Shapes

+

All examples are 90px x 30px buttons, so have 480px2 minimum indicator area.

+
+

Passes: 3px inset, 3px thick

+

Indicator area = (84 * 24) - (78 * 18) = 612px2 > 480px2

+ + + +
+
+

Passes: 2 28px x 9px rectangles

+

Indicator area = 2 * 28 * 9 = 504px2 > 480px2

+ + + +
+
+ + diff --git a/wcag22/understanding/img/focus-indicator-extra-outline.png b/wcag22/understanding/img/focus-indicator-extra-outline.png new file mode 100644 index 0000000..1810f48 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-extra-outline.png differ diff --git a/wcag22/understanding/img/focus-indicator-good-adjacent-bad-change.png b/wcag22/understanding/img/focus-indicator-good-adjacent-bad-change.png new file mode 100644 index 0000000..b2fbb27 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-good-adjacent-bad-change.png differ diff --git a/wcag22/understanding/img/focus-indicator-good-change-bad-adjacent.png b/wcag22/understanding/img/focus-indicator-good-change-bad-adjacent.png new file mode 100644 index 0000000..49fc670 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-good-change-bad-adjacent.png differ diff --git a/wcag22/understanding/img/focus-indicator-group-and-star.svg b/wcag22/understanding/img/focus-indicator-group-and-star.svg new file mode 100644 index 0000000..f73f7c2 --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-group-and-star.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/focus-indicator-group-outline.svg b/wcag22/understanding/img/focus-indicator-group-outline.svg new file mode 100644 index 0000000..860e856 --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-group-outline.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/focus-indicator-icon.png b/wcag22/understanding/img/focus-indicator-icon.png new file mode 100644 index 0000000..28d8903 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-icon.png differ diff --git a/wcag22/understanding/img/focus-indicator-innerline-strong.png b/wcag22/understanding/img/focus-indicator-innerline-strong.png new file mode 100644 index 0000000..0bca39f Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-innerline-strong.png differ diff --git a/wcag22/understanding/img/focus-indicator-innerline.png b/wcag22/understanding/img/focus-indicator-innerline.png new file mode 100644 index 0000000..10168a6 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-innerline.png differ diff --git a/wcag22/understanding/img/focus-indicator-inside.png b/wcag22/understanding/img/focus-indicator-inside.png new file mode 100644 index 0000000..1ab9cfd Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-inside.png differ diff --git a/wcag22/understanding/img/focus-indicator-non-contrast.png b/wcag22/understanding/img/focus-indicator-non-contrast.png new file mode 100644 index 0000000..c4cabe3 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-non-contrast.png differ diff --git a/wcag22/understanding/img/focus-indicator-non-text-contrast.html b/wcag22/understanding/img/focus-indicator-non-text-contrast.html new file mode 100644 index 0000000..6f2e850 --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-non-text-contrast.html @@ -0,0 +1,47 @@ + + + Figure source: Focus Indicator Custom Shapes + + +
+

Figure source: Focus Indicator Relationship with Non-text Contrast

+
+

Passes Focus Appearance, fails Non-text Contrast

+ + + +
+
+

Passes Non-text Contrast, fails Focus Appearance

+ + + +
+
+ + diff --git a/wcag22/understanding/img/focus-indicator-ntc-comparison1.png b/wcag22/understanding/img/focus-indicator-ntc-comparison1.png new file mode 100644 index 0000000..fc0a1fa Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-ntc-comparison1.png differ diff --git a/wcag22/understanding/img/focus-indicator-offset-types.html b/wcag22/understanding/img/focus-indicator-offset-types.html new file mode 100644 index 0000000..8f3d1e4 --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-offset-types.html @@ -0,0 +1,91 @@ + + + Figure source: Focus Indicator Offset Types + + +
+

Figure source: Focus Indicator Offset Types

+
+ +
+
+ + + + +
+
+ + diff --git a/wcag22/understanding/img/focus-indicator-offset-types.png b/wcag22/understanding/img/focus-indicator-offset-types.png new file mode 100644 index 0000000..2ba4289 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-offset-types.png differ diff --git a/wcag22/understanding/img/focus-indicator-outerline.png b/wcag22/understanding/img/focus-indicator-outerline.png new file mode 100644 index 0000000..63fa999 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-outerline.png differ diff --git a/wcag22/understanding/img/focus-indicator-select.png b/wcag22/understanding/img/focus-indicator-select.png new file mode 100644 index 0000000..089e1d6 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-select.png differ diff --git a/wcag22/understanding/img/focus-indicator-solid-border.png b/wcag22/understanding/img/focus-indicator-solid-border.png new file mode 100644 index 0000000..7f8e0f1 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-solid-border.png differ diff --git a/wcag22/understanding/img/focus-indicator-solid-border.svg b/wcag22/understanding/img/focus-indicator-solid-border.svg new file mode 100644 index 0000000..ce4f806 --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-solid-border.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/focus-indicator-solid-outline.png b/wcag22/understanding/img/focus-indicator-solid-outline.png new file mode 100644 index 0000000..dcadc0b Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-solid-outline.png differ diff --git a/wcag22/understanding/img/focus-indicator-solid-outline.svg b/wcag22/understanding/img/focus-indicator-solid-outline.svg new file mode 100644 index 0000000..856bb01 --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-solid-outline.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/focus-indicator-star-shadow.png b/wcag22/understanding/img/focus-indicator-star-shadow.png new file mode 100644 index 0000000..8717f26 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-star-shadow.png differ diff --git a/wcag22/understanding/img/focus-indicator-star-with-abutted-line.png b/wcag22/understanding/img/focus-indicator-star-with-abutted-line.png new file mode 100644 index 0000000..f466e7c Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-star-with-abutted-line.png differ diff --git a/wcag22/understanding/img/focus-indicator-star-with-abutted-line.svg b/wcag22/understanding/img/focus-indicator-star-with-abutted-line.svg new file mode 100644 index 0000000..595e447 --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-star-with-abutted-line.svg @@ -0,0 +1,7 @@ + + + + + + + \ No newline at end of file diff --git a/wcag22/understanding/img/focus-indicator-star-with-focus.png b/wcag22/understanding/img/focus-indicator-star-with-focus.png new file mode 100644 index 0000000..e1c82cb Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-star-with-focus.png differ diff --git a/wcag22/understanding/img/focus-indicator-star-with-focus.svg b/wcag22/understanding/img/focus-indicator-star-with-focus.svg new file mode 100644 index 0000000..496f754 --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-star-with-focus.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/focus-indicator-star-with-light-focus.png b/wcag22/understanding/img/focus-indicator-star-with-light-focus.png new file mode 100644 index 0000000..3865620 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-star-with-light-focus.png differ diff --git a/wcag22/understanding/img/focus-indicator-star-with-light-focus.svg b/wcag22/understanding/img/focus-indicator-star-with-light-focus.svg new file mode 100644 index 0000000..67f43dd --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-star-with-light-focus.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/focus-indicator-star-without-focus.png b/wcag22/understanding/img/focus-indicator-star-without-focus.png new file mode 100644 index 0000000..74ad660 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-star-without-focus.png differ diff --git a/wcag22/understanding/img/focus-indicator-star-without-focus.svg b/wcag22/understanding/img/focus-indicator-star-without-focus.svg new file mode 100644 index 0000000..67157b1 --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-star-without-focus.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/focus-indicator-strong-dashed-border.png b/wcag22/understanding/img/focus-indicator-strong-dashed-border.png new file mode 100644 index 0000000..12589b0 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-strong-dashed-border.png differ diff --git a/wcag22/understanding/img/focus-indicator-strong-dashed-border.svg b/wcag22/understanding/img/focus-indicator-strong-dashed-border.svg new file mode 100644 index 0000000..8852e04 --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-strong-dashed-border.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/focus-indicator-strong.png b/wcag22/understanding/img/focus-indicator-strong.png new file mode 100644 index 0000000..0042c31 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-strong.png differ diff --git a/wcag22/understanding/img/focus-indicator-thick-non-contrast.png b/wcag22/understanding/img/focus-indicator-thick-non-contrast.png new file mode 100644 index 0000000..43f0d7f Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-thick-non-contrast.png differ diff --git a/wcag22/understanding/img/focus-indicator-thick-short-side.png b/wcag22/understanding/img/focus-indicator-thick-short-side.png new file mode 100644 index 0000000..b72d6de Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-thick-short-side.png differ diff --git a/wcag22/understanding/img/focus-indicator-thin-non-contrast.png b/wcag22/understanding/img/focus-indicator-thin-non-contrast.png new file mode 100644 index 0000000..865cad2 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-thin-non-contrast.png differ diff --git a/wcag22/understanding/img/focus-indicator-two-color-thick.png b/wcag22/understanding/img/focus-indicator-two-color-thick.png new file mode 100644 index 0000000..aea1463 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-two-color-thick.png differ diff --git a/wcag22/understanding/img/focus-indicator-two-color-thin.png b/wcag22/understanding/img/focus-indicator-two-color-thin.png new file mode 100644 index 0000000..8d5ff4d Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-two-color-thin.png differ diff --git a/wcag22/understanding/img/focus-indicator-two-color.html b/wcag22/understanding/img/focus-indicator-two-color.html new file mode 100644 index 0000000..5f145c3 --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-two-color.html @@ -0,0 +1,46 @@ + + + Figure source: Focus Indicator Two Color + + +
+

Figure source: Focus Indicator Two Color

+
+

Passes: the 2px thick black line passes

+ + +
+
+

Fails: the indicator is 2px thick, but the part of the indicator meeting change contrast is only 1px thick

+ + +
+
+ + diff --git a/wcag22/understanding/img/focus-indicator-underline.png b/wcag22/understanding/img/focus-indicator-underline.png new file mode 100644 index 0000000..ebebb58 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-underline.png differ diff --git a/wcag22/understanding/img/focus-indicator-weak-dashed-border.png b/wcag22/understanding/img/focus-indicator-weak-dashed-border.png new file mode 100644 index 0000000..08cde7c Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-weak-dashed-border.png differ diff --git a/wcag22/understanding/img/focus-indicator-weak-dashed-border.svg b/wcag22/understanding/img/focus-indicator-weak-dashed-border.svg new file mode 100644 index 0000000..1600f1f --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-weak-dashed-border.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/focus-indicator-whole-star.png b/wcag22/understanding/img/focus-indicator-whole-star.png new file mode 100644 index 0000000..ae6def8 Binary files /dev/null and b/wcag22/understanding/img/focus-indicator-whole-star.png differ diff --git a/wcag22/understanding/img/focus-indicator-whole-star.svg b/wcag22/understanding/img/focus-indicator-whole-star.svg new file mode 100644 index 0000000..c01d55a --- /dev/null +++ b/wcag22/understanding/img/focus-indicator-whole-star.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/focus-indicators-passing.png b/wcag22/understanding/img/focus-indicators-passing.png new file mode 100644 index 0000000..01fb353 Binary files /dev/null and b/wcag22/understanding/img/focus-indicators-passing.png differ diff --git a/wcag22/understanding/img/focus-inline-link-outline.png b/wcag22/understanding/img/focus-inline-link-outline.png new file mode 100644 index 0000000..8012eed Binary files /dev/null and b/wcag22/understanding/img/focus-inline-link-outline.png differ diff --git a/wcag22/understanding/img/focus-inline-link.png b/wcag22/understanding/img/focus-inline-link.png new file mode 100644 index 0000000..67579be Binary files /dev/null and b/wcag22/understanding/img/focus-inline-link.png differ diff --git a/wcag22/understanding/img/graphics-contrast_pie-chart_fail.png b/wcag22/understanding/img/graphics-contrast_pie-chart_fail.png new file mode 100644 index 0000000..66eec6e Binary files /dev/null and b/wcag22/understanding/img/graphics-contrast_pie-chart_fail.png differ diff --git a/wcag22/understanding/img/graphics-contrast_pie-chart_na.png b/wcag22/understanding/img/graphics-contrast_pie-chart_na.png new file mode 100644 index 0000000..4af9619 Binary files /dev/null and b/wcag22/understanding/img/graphics-contrast_pie-chart_na.png differ diff --git a/wcag22/understanding/img/graphics-contrast_pie-chart_pass.png b/wcag22/understanding/img/graphics-contrast_pie-chart_pass.png new file mode 100644 index 0000000..bfea036 Binary files /dev/null and b/wcag22/understanding/img/graphics-contrast_pie-chart_pass.png differ diff --git a/wcag22/understanding/img/graphics-contrast_text-size-stroke.png b/wcag22/understanding/img/graphics-contrast_text-size-stroke.png new file mode 100644 index 0000000..325012e Binary files /dev/null and b/wcag22/understanding/img/graphics-contrast_text-size-stroke.png differ diff --git a/wcag22/understanding/img/inactive-button.png b/wcag22/understanding/img/inactive-button.png new file mode 100644 index 0000000..49beef3 Binary files /dev/null and b/wcag22/understanding/img/inactive-button.png differ diff --git a/wcag22/understanding/img/infographic-fail.png b/wcag22/understanding/img/infographic-fail.png new file mode 100644 index 0000000..0a4dd18 Binary files /dev/null and b/wcag22/understanding/img/infographic-fail.png differ diff --git a/wcag22/understanding/img/infographic-pass.png b/wcag22/understanding/img/infographic-pass.png new file mode 100644 index 0000000..caeca73 Binary files /dev/null and b/wcag22/understanding/img/infographic-pass.png differ diff --git a/wcag22/understanding/img/link-outline-example.png b/wcag22/understanding/img/link-outline-example.png new file mode 100644 index 0000000..8f6b09c Binary files /dev/null and b/wcag22/understanding/img/link-outline-example.png differ diff --git a/wcag22/understanding/img/link-text-default.png b/wcag22/understanding/img/link-text-default.png new file mode 100644 index 0000000..7ff267e Binary files /dev/null and b/wcag22/understanding/img/link-text-default.png differ diff --git a/wcag22/understanding/img/link-text-focus.png b/wcag22/understanding/img/link-text-focus.png new file mode 100644 index 0000000..2d2dd98 Binary files /dev/null and b/wcag22/understanding/img/link-text-focus.png differ diff --git a/wcag22/understanding/img/link-text-styled-default.png b/wcag22/understanding/img/link-text-styled-default.png new file mode 100644 index 0000000..938502b Binary files /dev/null and b/wcag22/understanding/img/link-text-styled-default.png differ diff --git a/wcag22/understanding/img/link-text-styled-focus.png b/wcag22/understanding/img/link-text-styled-focus.png new file mode 100644 index 0000000..69b45fd Binary files /dev/null and b/wcag22/understanding/img/link-text-styled-focus.png differ diff --git a/wcag22/understanding/img/minimal-button.png b/wcag22/understanding/img/minimal-button.png new file mode 100644 index 0000000..7e6e962 Binary files /dev/null and b/wcag22/understanding/img/minimal-button.png differ diff --git a/wcag22/understanding/img/ntc-focus-background.png b/wcag22/understanding/img/ntc-focus-background.png new file mode 100644 index 0000000..dae21c6 Binary files /dev/null and b/wcag22/understanding/img/ntc-focus-background.png differ diff --git a/wcag22/understanding/img/ntc-focus-border.png b/wcag22/understanding/img/ntc-focus-border.png new file mode 100644 index 0000000..f938ca1 Binary files /dev/null and b/wcag22/understanding/img/ntc-focus-border.png differ diff --git a/wcag22/understanding/img/ntc-focus-inner-border.png b/wcag22/understanding/img/ntc-focus-inner-border.png new file mode 100644 index 0000000..8501907 Binary files /dev/null and b/wcag22/understanding/img/ntc-focus-inner-border.png differ diff --git a/wcag22/understanding/img/ntc-focus-inner-outer.png b/wcag22/understanding/img/ntc-focus-inner-outer.png new file mode 100644 index 0000000..5e931a0 Binary files /dev/null and b/wcag22/understanding/img/ntc-focus-inner-outer.png differ diff --git a/wcag22/understanding/img/ntc-focus-inner-white.png b/wcag22/understanding/img/ntc-focus-inner-white.png new file mode 100644 index 0000000..9b4bcfd Binary files /dev/null and b/wcag22/understanding/img/ntc-focus-inner-white.png differ diff --git a/wcag22/understanding/img/ntc-focus-inner.png b/wcag22/understanding/img/ntc-focus-inner.png new file mode 100644 index 0000000..ae5ff9d Binary files /dev/null and b/wcag22/understanding/img/ntc-focus-inner.png differ diff --git a/wcag22/understanding/img/ntc-focus-outer-green.png b/wcag22/understanding/img/ntc-focus-outer-green.png new file mode 100644 index 0000000..6a660f9 Binary files /dev/null and b/wcag22/understanding/img/ntc-focus-outer-green.png differ diff --git a/wcag22/understanding/img/ntc-focus-outer-yellow.png b/wcag22/understanding/img/ntc-focus-outer-yellow.png new file mode 100644 index 0000000..3360426 Binary files /dev/null and b/wcag22/understanding/img/ntc-focus-outer-yellow.png differ diff --git a/wcag22/understanding/img/path-based-gesture-1.png b/wcag22/understanding/img/path-based-gesture-1.png new file mode 100644 index 0000000..e83f8c5 Binary files /dev/null and b/wcag22/understanding/img/path-based-gesture-1.png differ diff --git a/wcag22/understanding/img/path-based-gesture-2.png b/wcag22/understanding/img/path-based-gesture-2.png new file mode 100644 index 0000000..87b2742 Binary files /dev/null and b/wcag22/understanding/img/path-based-gesture-2.png differ diff --git a/wcag22/understanding/img/path-based-gesture-3.png b/wcag22/understanding/img/path-based-gesture-3.png new file mode 100644 index 0000000..87b2742 Binary files /dev/null and b/wcag22/understanding/img/path-based-gesture-3.png differ diff --git a/wcag22/understanding/img/pointer-target-example1-full.png b/wcag22/understanding/img/pointer-target-example1-full.png new file mode 100644 index 0000000..df1ce58 Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example1-full.png differ diff --git a/wcag22/understanding/img/pointer-target-example1.png b/wcag22/understanding/img/pointer-target-example1.png new file mode 100644 index 0000000..8b8fff1 Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example1.png differ diff --git a/wcag22/understanding/img/pointer-target-example2.png b/wcag22/understanding/img/pointer-target-example2.png new file mode 100644 index 0000000..4822923 Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example2.png differ diff --git a/wcag22/understanding/img/pointer-target-example3-v2.png b/wcag22/understanding/img/pointer-target-example3-v2.png new file mode 100644 index 0000000..d9de5cf Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example3-v2.png differ diff --git a/wcag22/understanding/img/pointer-target-example3.png b/wcag22/understanding/img/pointer-target-example3.png new file mode 100644 index 0000000..d81f881 Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example3.png differ diff --git a/wcag22/understanding/img/pointer-target-example3a.png b/wcag22/understanding/img/pointer-target-example3a.png new file mode 100644 index 0000000..d5a1a4e Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example3a.png differ diff --git a/wcag22/understanding/img/pointer-target-example4-v2.png b/wcag22/understanding/img/pointer-target-example4-v2.png new file mode 100644 index 0000000..135e0a1 Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example4-v2.png differ diff --git a/wcag22/understanding/img/pointer-target-example4.jpg b/wcag22/understanding/img/pointer-target-example4.jpg new file mode 100644 index 0000000..c47331b Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example4.jpg differ diff --git a/wcag22/understanding/img/pointer-target-example4.png b/wcag22/understanding/img/pointer-target-example4.png new file mode 100644 index 0000000..0342f9c Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example4.png differ diff --git a/wcag22/understanding/img/pointer-target-example4a.png b/wcag22/understanding/img/pointer-target-example4a.png new file mode 100644 index 0000000..5d3edcd Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example4a.png differ diff --git a/wcag22/understanding/img/pointer-target-example5-revised.png b/wcag22/understanding/img/pointer-target-example5-revised.png new file mode 100644 index 0000000..d120779 Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example5-revised.png differ diff --git a/wcag22/understanding/img/pointer-target-example5.png b/wcag22/understanding/img/pointer-target-example5.png new file mode 100644 index 0000000..be4456a Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example5.png differ diff --git a/wcag22/understanding/img/pointer-target-example6-inline-links.png b/wcag22/understanding/img/pointer-target-example6-inline-links.png new file mode 100644 index 0000000..7fe439a Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example6-inline-links.png differ diff --git a/wcag22/understanding/img/pointer-target-example7-stacked-links.png b/wcag22/understanding/img/pointer-target-example7-stacked-links.png new file mode 100644 index 0000000..9c942b3 Binary files /dev/null and b/wcag22/understanding/img/pointer-target-example7-stacked-links.png differ diff --git a/wcag22/understanding/img/primary-button-example.png b/wcag22/understanding/img/primary-button-example.png new file mode 100644 index 0000000..d34d18f Binary files /dev/null and b/wcag22/understanding/img/primary-button-example.png differ diff --git a/wcag22/understanding/img/radio-custom.png b/wcag22/understanding/img/radio-custom.png new file mode 100644 index 0000000..8e72aba Binary files /dev/null and b/wcag22/understanding/img/radio-custom.png differ diff --git a/wcag22/understanding/img/rich-text-editor-detail.png b/wcag22/understanding/img/rich-text-editor-detail.png new file mode 100644 index 0000000..4e49ff4 Binary files /dev/null and b/wcag22/understanding/img/rich-text-editor-detail.png differ diff --git a/wcag22/understanding/img/simple-line-graph.png b/wcag22/understanding/img/simple-line-graph.png new file mode 100644 index 0000000..0df127d Binary files /dev/null and b/wcag22/understanding/img/simple-line-graph.png differ diff --git a/wcag22/understanding/img/single-space.gif b/wcag22/understanding/img/single-space.gif new file mode 100644 index 0000000..27755d2 Binary files /dev/null and b/wcag22/understanding/img/single-space.gif differ diff --git a/wcag22/understanding/img/space-and-a-half.gif b/wcag22/understanding/img/space-and-a-half.gif new file mode 100644 index 0000000..cff522c Binary files /dev/null and b/wcag22/understanding/img/space-and-a-half.gif differ diff --git a/wcag22/understanding/img/spacing_cutoff_fail_horizontal.png b/wcag22/understanding/img/spacing_cutoff_fail_horizontal.png new file mode 100644 index 0000000..9eefac3 Binary files /dev/null and b/wcag22/understanding/img/spacing_cutoff_fail_horizontal.png differ diff --git a/wcag22/understanding/img/spacing_cutoff_fail_vertical.png b/wcag22/understanding/img/spacing_cutoff_fail_vertical.png new file mode 100644 index 0000000..3369a0e Binary files /dev/null and b/wcag22/understanding/img/spacing_cutoff_fail_vertical.png differ diff --git a/wcag22/understanding/img/spacing_overlap_fail.png b/wcag22/understanding/img/spacing_overlap_fail.png new file mode 100644 index 0000000..2862491 Binary files /dev/null and b/wcag22/understanding/img/spacing_overlap_fail.png differ diff --git a/wcag22/understanding/img/star-examples-fail.png b/wcag22/understanding/img/star-examples-fail.png new file mode 100644 index 0000000..623f10a Binary files /dev/null and b/wcag22/understanding/img/star-examples-fail.png differ diff --git a/wcag22/understanding/img/star-examples-pass.png b/wcag22/understanding/img/star-examples-pass.png new file mode 100644 index 0000000..74d3054 Binary files /dev/null and b/wcag22/understanding/img/star-examples-pass.png differ diff --git a/wcag22/understanding/img/stroke-comparisons.png b/wcag22/understanding/img/stroke-comparisons.png new file mode 100644 index 0000000..a228e9d Binary files /dev/null and b/wcag22/understanding/img/stroke-comparisons.png differ diff --git a/wcag22/understanding/img/target-dropdown.afdesign b/wcag22/understanding/img/target-dropdown.afdesign new file mode 100644 index 0000000..1c8e08e Binary files /dev/null and b/wcag22/understanding/img/target-dropdown.afdesign differ diff --git a/wcag22/understanding/img/target-dropdown.png b/wcag22/understanding/img/target-dropdown.png new file mode 100644 index 0000000..cd1ec5a Binary files /dev/null and b/wcag22/understanding/img/target-dropdown.png differ diff --git a/wcag22/understanding/img/target-dropdown.svg b/wcag22/understanding/img/target-dropdown.svg new file mode 100644 index 0000000..69c14bc --- /dev/null +++ b/wcag22/understanding/img/target-dropdown.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/target-large-small-clipping.afdesign b/wcag22/understanding/img/target-large-small-clipping.afdesign new file mode 100644 index 0000000..7147bb9 Binary files /dev/null and b/wcag22/understanding/img/target-large-small-clipping.afdesign differ diff --git a/wcag22/understanding/img/target-large-small-clipping.png b/wcag22/understanding/img/target-large-small-clipping.png new file mode 100644 index 0000000..cbb4c39 Binary files /dev/null and b/wcag22/understanding/img/target-large-small-clipping.png differ diff --git a/wcag22/understanding/img/target-large-small-clipping.svg b/wcag22/understanding/img/target-large-small-clipping.svg new file mode 100644 index 0000000..7513c40 --- /dev/null +++ b/wcag22/understanding/img/target-large-small-clipping.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/target-large-small-touching.afdesign b/wcag22/understanding/img/target-large-small-touching.afdesign new file mode 100644 index 0000000..43afbd3 Binary files /dev/null and b/wcag22/understanding/img/target-large-small-touching.afdesign differ diff --git a/wcag22/understanding/img/target-large-small-touching.png b/wcag22/understanding/img/target-large-small-touching.png new file mode 100644 index 0000000..d54240b Binary files /dev/null and b/wcag22/understanding/img/target-large-small-touching.png differ diff --git a/wcag22/understanding/img/target-large-small-touching.svg b/wcag22/understanding/img/target-large-small-touching.svg new file mode 100644 index 0000000..8a05adb --- /dev/null +++ b/wcag22/understanding/img/target-large-small-touching.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/target-size-basic.afdesign b/wcag22/understanding/img/target-size-basic.afdesign new file mode 100644 index 0000000..533abaf Binary files /dev/null and b/wcag22/understanding/img/target-size-basic.afdesign differ diff --git a/wcag22/understanding/img/target-size-basic.png b/wcag22/understanding/img/target-size-basic.png new file mode 100644 index 0000000..92dc95b Binary files /dev/null and b/wcag22/understanding/img/target-size-basic.png differ diff --git a/wcag22/understanding/img/target-size-basic.svg b/wcag22/understanding/img/target-size-basic.svg new file mode 100644 index 0000000..274c233 --- /dev/null +++ b/wcag22/understanding/img/target-size-basic.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/target-size-bounding-boxes.afdesign b/wcag22/understanding/img/target-size-bounding-boxes.afdesign new file mode 100644 index 0000000..378e821 Binary files /dev/null and b/wcag22/understanding/img/target-size-bounding-boxes.afdesign differ diff --git a/wcag22/understanding/img/target-size-bounding-boxes.png b/wcag22/understanding/img/target-size-bounding-boxes.png new file mode 100644 index 0000000..35f8b9a Binary files /dev/null and b/wcag22/understanding/img/target-size-bounding-boxes.png differ diff --git a/wcag22/understanding/img/target-size-bounding-boxes.svg b/wcag22/understanding/img/target-size-bounding-boxes.svg new file mode 100644 index 0000000..9aca20c --- /dev/null +++ b/wcag22/understanding/img/target-size-bounding-boxes.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/target-size-minimum-diagram.png b/wcag22/understanding/img/target-size-minimum-diagram.png new file mode 100644 index 0000000..5615ada Binary files /dev/null and b/wcag22/understanding/img/target-size-minimum-diagram.png differ diff --git a/wcag22/understanding/img/target-size-minimum.png b/wcag22/understanding/img/target-size-minimum.png new file mode 100644 index 0000000..99ce8e9 Binary files /dev/null and b/wcag22/understanding/img/target-size-minimum.png differ diff --git a/wcag22/understanding/img/target-size-overlaps.jpg b/wcag22/understanding/img/target-size-overlaps.jpg new file mode 100644 index 0000000..66a982e Binary files /dev/null and b/wcag22/understanding/img/target-size-overlaps.jpg differ diff --git a/wcag22/understanding/img/target-size-requirement.png b/wcag22/understanding/img/target-size-requirement.png new file mode 100644 index 0000000..33e9a6a Binary files /dev/null and b/wcag22/understanding/img/target-size-requirement.png differ diff --git a/wcag22/understanding/img/target-size-requirement2.png b/wcag22/understanding/img/target-size-requirement2.png new file mode 100644 index 0000000..d33daa9 Binary files /dev/null and b/wcag22/understanding/img/target-size-requirement2.png differ diff --git a/wcag22/understanding/img/target-size-requirement3.png b/wcag22/understanding/img/target-size-requirement3.png new file mode 100644 index 0000000..5c0725f Binary files /dev/null and b/wcag22/understanding/img/target-size-requirement3.png differ diff --git a/wcag22/understanding/img/target-size-skewed.afdesign b/wcag22/understanding/img/target-size-skewed.afdesign new file mode 100644 index 0000000..5061a64 Binary files /dev/null and b/wcag22/understanding/img/target-size-skewed.afdesign differ diff --git a/wcag22/understanding/img/target-size-skewed.png b/wcag22/understanding/img/target-size-skewed.png new file mode 100644 index 0000000..22153e6 Binary files /dev/null and b/wcag22/understanding/img/target-size-skewed.png differ diff --git a/wcag22/understanding/img/target-size-skewed.svg b/wcag22/understanding/img/target-size-skewed.svg new file mode 100644 index 0000000..9f69876 --- /dev/null +++ b/wcag22/understanding/img/target-size-skewed.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/target-size-undersized-rounded.afdesign b/wcag22/understanding/img/target-size-undersized-rounded.afdesign new file mode 100644 index 0000000..0d14bf9 Binary files /dev/null and b/wcag22/understanding/img/target-size-undersized-rounded.afdesign differ diff --git a/wcag22/understanding/img/target-size-undersized-rounded.png b/wcag22/understanding/img/target-size-undersized-rounded.png new file mode 100644 index 0000000..3d92a1b Binary files /dev/null and b/wcag22/understanding/img/target-size-undersized-rounded.png differ diff --git a/wcag22/understanding/img/target-size-undersized-rounded.svg b/wcag22/understanding/img/target-size-undersized-rounded.svg new file mode 100644 index 0000000..a308f28 --- /dev/null +++ b/wcag22/understanding/img/target-size-undersized-rounded.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/target-spacing-toolbar.afdesign b/wcag22/understanding/img/target-spacing-toolbar.afdesign new file mode 100644 index 0000000..bf90181 Binary files /dev/null and b/wcag22/understanding/img/target-spacing-toolbar.afdesign differ diff --git a/wcag22/understanding/img/target-spacing-toolbar.png b/wcag22/understanding/img/target-spacing-toolbar.png new file mode 100644 index 0000000..895e340 Binary files /dev/null and b/wcag22/understanding/img/target-spacing-toolbar.png differ diff --git a/wcag22/understanding/img/target-spacing-toolbar.svg b/wcag22/understanding/img/target-spacing-toolbar.svg new file mode 100644 index 0000000..d488b49 --- /dev/null +++ b/wcag22/understanding/img/target-spacing-toolbar.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/target-text-buttons-single-row.afdesign b/wcag22/understanding/img/target-text-buttons-single-row.afdesign new file mode 100644 index 0000000..a6d9f87 Binary files /dev/null and b/wcag22/understanding/img/target-text-buttons-single-row.afdesign differ diff --git a/wcag22/understanding/img/target-text-buttons-single-row.png b/wcag22/understanding/img/target-text-buttons-single-row.png new file mode 100644 index 0000000..d1971fe Binary files /dev/null and b/wcag22/understanding/img/target-text-buttons-single-row.png differ diff --git a/wcag22/understanding/img/target-text-buttons-single-row.svg b/wcag22/understanding/img/target-text-buttons-single-row.svg new file mode 100644 index 0000000..5d2dbfb --- /dev/null +++ b/wcag22/understanding/img/target-text-buttons-single-row.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/target-text-buttons-two-rows.afdesign b/wcag22/understanding/img/target-text-buttons-two-rows.afdesign new file mode 100644 index 0000000..a9f3d1d Binary files /dev/null and b/wcag22/understanding/img/target-text-buttons-two-rows.afdesign differ diff --git a/wcag22/understanding/img/target-text-buttons-two-rows.png b/wcag22/understanding/img/target-text-buttons-two-rows.png new file mode 100644 index 0000000..bb78992 Binary files /dev/null and b/wcag22/understanding/img/target-text-buttons-two-rows.png differ diff --git a/wcag22/understanding/img/target-text-buttons-two-rows.svg b/wcag22/understanding/img/target-text-buttons-two-rows.svg new file mode 100644 index 0000000..9f856f9 --- /dev/null +++ b/wcag22/understanding/img/target-text-buttons-two-rows.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/wcag22/understanding/img/text-input-background-border.png b/wcag22/understanding/img/text-input-background-border.png new file mode 100644 index 0000000..45051d8 Binary files /dev/null and b/wcag22/understanding/img/text-input-background-border.png differ diff --git a/wcag22/understanding/img/text-input-background-focus.png b/wcag22/understanding/img/text-input-background-focus.png new file mode 100644 index 0000000..02be16d Binary files /dev/null and b/wcag22/understanding/img/text-input-background-focus.png differ diff --git a/wcag22/understanding/img/text-input-background.png b/wcag22/understanding/img/text-input-background.png new file mode 100644 index 0000000..8776771 Binary files /dev/null and b/wcag22/understanding/img/text-input-background.png differ diff --git a/wcag22/understanding/img/text-input-default.png b/wcag22/understanding/img/text-input-default.png new file mode 100644 index 0000000..033604e Binary files /dev/null and b/wcag22/understanding/img/text-input-default.png differ diff --git a/wcag22/understanding/img/text-input-focus.png b/wcag22/understanding/img/text-input-focus.png new file mode 100644 index 0000000..1946ee5 Binary files /dev/null and b/wcag22/understanding/img/text-input-focus.png differ diff --git a/wcag22/understanding/img/text-input-minimal.png b/wcag22/understanding/img/text-input-minimal.png new file mode 100644 index 0000000..5fff64b Binary files /dev/null and b/wcag22/understanding/img/text-input-minimal.png differ diff --git a/wcag22/understanding/img/toggle.png b/wcag22/understanding/img/toggle.png new file mode 100644 index 0000000..d3a825e Binary files /dev/null and b/wcag22/understanding/img/toggle.png differ diff --git a/wcag22/understanding/img/visibe-control-meeting-control-hidden.png b/wcag22/understanding/img/visibe-control-meeting-control-hidden.png new file mode 100644 index 0000000..870c55a Binary files /dev/null and b/wcag22/understanding/img/visibe-control-meeting-control-hidden.png differ diff --git a/wcag22/understanding/img/visible-control-edit-menu-hidden.png b/wcag22/understanding/img/visible-control-edit-menu-hidden.png new file mode 100644 index 0000000..47d0fc8 Binary files /dev/null and b/wcag22/understanding/img/visible-control-edit-menu-hidden.png differ diff --git a/wcag22/understanding/index.html b/wcag22/understanding/index.html new file mode 100644 index 0000000..2c28b40 --- /dev/null +++ b/wcag22/understanding/index.html @@ -0,0 +1,569 @@ + + + + + + + + + + + + + + + + Understanding WCAG 2.2 | WAI | W3C + + + + + + + + + + + + Skip to content
+ +
+
+
+ +
+
+ + + + +
+ + + + + + +
+ + + +

All WCAG 2.2 Understanding Docs

+ + + + + +
+ +

Perceivable

+ +
+ +

1.1 Text Alternatives

+ + + +
+ +
+ +

1.2 Time-based Media

+ + + +
+ +
+ +

1.3 Adaptable

+ + + +
+ +
+ +

1.4 Distinguishable

+ + + +
+ +
+ +
+ +

Operable

+ +
+ +

2.1 Keyboard Accessible

+ + + +
+ +
+ +

2.2 Enough Time

+ + + +
+ +
+ +

2.3 Seizures and Physical Reactions

+ + + +
+ + + +
+ +

2.5 Input Modalities

+ + + +
+ +
+ +
+ +

Understandable

+ +
+ +

3.1 Readable

+ + + +
+ +
+ +

3.2 Predictable

+ + + +
+ +
+ +

3.3 Input Assistance

+ + + +
+ +
+ +
+ +

Robust

+ +
+ +

4.1 Compatible

+ + + +
+ +
+ +
+ +

Other Understanding documents

+ + + +
+ + + +
+ + + Back to Top + + + +
+ + + + + + + + \ No newline at end of file diff --git a/wcag22/understanding/info-and-relationships.html b/wcag22/understanding/info-and-relationships.html new file mode 100644 index 0000000..c7be64b --- /dev/null +++ b/wcag22/understanding/info-and-relationships.html @@ -0,0 +1,1224 @@ + + + + + + Understanding Success Criterion 1.3.1: Info and Relationships | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.3.1:Info and Relationships (Level A) +

+ +
+
+

In Brief

+
+ + +
Goal
+
Information about content structure is available to more people.
+ +
What to do
+
Use code to reinforce relationships and information conveyed through presentation.
+ +
Why it's important
+
People can adapt the presentation to suit their needs while preserving the original + meaning. +
+ + +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that information and relationships + that are implied by visual or auditory formatting are preserved when the presentation + format changes. For example, the presentation format changes when the content is read + by a screen reader or when a user style sheet is substituted for the style sheet provided + by the author. + +

+

+ Sighted users perceive structure and relationships through various visual cues + — headings are often in a larger, bold font separated from paragraphs by blank lines; + list items are preceded by a bullet and perhaps indented; paragraphs are separated + by a blank line; items that share a common characteristic are organized into tabular + rows and columns; form fields may be positioned as groups that share text labels; + a different background color may be used to indicate that several items are related + to each other; words that have special status are indicated by changing the font family + and /or bolding, italicizing, or underlining them; items that share a common characteristic + are organized into a table where the relationship of cells sharing the same row or + column and the relationship of each cell to its row and/or column header are necessary + for understanding; and so on. Having these structures and these relationships programmatically + determined or available in text ensures that information important for comprehension + will be perceivable to all. + + +

+

Auditory cues may be used as well. For example, a chime might indicate the beginning + of a new section; a change in voice pitch or speech rate may be used to emphasize + important information or to indicate quoted text; etc. + +

+

+ When such relationships are perceivable to one set of users, those relationships can + be made to be perceivable to all. One method of determining whether or not information + has been properly provided to all users is to access the information serially in different + modalities. + + +

+

If links to glossary items are implemented using anchor elements (or the proper link + element for the technology in use) and identified using a different font face, a screen + reader user will hear that the item is a link when the glossary term is encountered + even though they may not receive information about the change in font face. An on-line + catalog may indicate prices using a larger font colored red. A screen reader or person + who cannot perceive red, still has the information about the price as long as it is + preceded by the currency symbol. + +

+

Some technologies do not provide a means to programmatically determine some types + of information and relationships. In that case then there should be a text description + of the information and relationships. For instance, "all required fields are marked + with an asterisk (*)". The text description should be near the information it is describing + (when the page is linearized), such as in the parent element or in the adjacent element. + +

+

There may also be cases where it may be a judgment call as to whether the relationships + should be programmatically determined or be presented in text. However, when technologies + support programmatic relationships, it is strongly encouraged that information and + relationships be programmatically determined rather than described in text. + +

+
+

Note

+
+ + +

It is not required that color values be programmatically determined. The information + conveyed by color cannot be adequately presented simply by exposing the value. Therefore, + + Success Criterion 1.4.1 + + addresses the specific case of color, rather than Success Criterion 1.3.1. + + +

+ + +
+
+
+
+

Benefits

+
    + + +
  • This Success Criterion helps people with different disabilities by allowing user agents + to adapt content according to the needs of individual users. + + +
    • + + +
  • Users who are blind (using a screen reader) benefit when information conveyed through + color is also available in text (including text alternatives for images that use color + to convey information). + +
    • + + +
  • Users who are deaf-blind using braille (text) refreshable displays may be unable to + access color-dependent information. + +
    • + + +
+
+
+

Examples

+
+ +
A form with required fields
+ +
A form contains several required fields. The labels for the required fields are displayed + in red. In addition, at the end of each label is an asterisk character, *. The instructions + for completing the form indicate that "all required fields are displayed in red and + marked with an asterisk *", followed by an example. +
+ +
A form that uses color and text to indicate required fields
+ +
A form contains both required and optional fields. Instructions at the top of the + form explain that required fields are labeled with red text and also with an icon + whose text alternative says, "Required." Both the red text and the icon are programmatically + associated with the appropriate form fields so that assistive technology users can + determine the required fields. +
+ +
A bus schedule table where the headers for each cell can be programmatically determined
+ +
A bus schedule consists of a table with the bus stops listed vertically in the first + column and the different buses listed horizontally across the first row. Each cell + contains the time when the bus will be at that bus stop. The bus stop and bus cells + are identified as headers for their corresponding row or column so that assistive + technology can programmatically determine which bus and which bus stop are associated + with the time in each cell. +
+ +
A form where the labels for the checkboxes can be programmatically determined
+ +
In a form, the labels for each checkbox can be programmatically determined by assistive + technology. +
+ +
A text document
+ +
A simple text document is formatted with double blank lines before titles, asterisks + to indicate list items and other standard formatting conventions so that its structure + can be programmatically determined. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: The technology provides semantic structure to make information and relationships + conveyed through presentation programmatically determinable: + +

+ + + + + +
+
+ + +

Situation B: The technology in use does NOT provide the semantic structure to make + the information and relationships conveyed through presentation programmatically determinable: + +

+ + + + + +
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
relationships
+
+ + + +

meaningful associations between distinct pieces of content

+ + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/input-assistance.html b/wcag22/understanding/input-assistance.html new file mode 100644 index 0000000..604003c --- /dev/null +++ b/wcag22/understanding/input-assistance.html @@ -0,0 +1,197 @@ + + + + + + Understanding Guideline 3.3: Input Assistance | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 3.3:Input Assistance +

+ +
+
+

Intent

+

Everyone makes mistakes. However, people with some disabilities have more difficulty + creating error-free input. In addition, it may be harder for them to detect that they + have made an error. Typical error indication methods may not be obvious to them because + of a limited field of view, limited color perception, or use of assistive technology. + This guideline seeks to reduce the number of serious or irreversible errors that are + made, increase the likelihood that all errors will be noticed by the user, and help + users understand what they should do to correct an error. + +

+
+
+

Success Criteria for this Guideline

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/input-modalities.html b/wcag22/understanding/input-modalities.html new file mode 100644 index 0000000..e36be14 --- /dev/null +++ b/wcag22/understanding/input-modalities.html @@ -0,0 +1,209 @@ + + + + + + Understanding Guideline 2.5: Input Modalities | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 2.5:Input Modalities +

+ +
+
+

Intent

+

All functionality should be accessible via pointer input devices, for example, via + a mouse pointer, a finger interacting with a touch screen, an electronic pencil/stylus, + or a laser pointer. +

+

People operating pointer input devices may not be able to carry out timed or complex + gestures. Examples are drag-and-drop gestures and on touch screens, swiping gestures, + split taps, or long presses. This Guideline does not discourage the provision of complex + and timed gestures by authors. However, where they are used, an alternative method + of input should be provided to enable users with motor impairments to interact with + content via single untimed pointer gestures. +

+

Often, people use devices that offer several input methods, for example, mouse input, + touch input, keyboard input, and speech input. These should be supported concurrently + as users may at any time swich preferred input methods due to situational circumstances, + for example, the availability of a flat support for mouse operation, or situational + impediments through motion or changes of ambient light. +

+

A common requirement for pointer interaction is the ability of users to position the + pointer over the target. With touch input, the pointer (the finger) is larger and + less precise than a mouse cursor. For people with motor impairments, a larger target + makes it easier to successfully position the pointer and activate the target. +

+
+
+

Success Criteria for this Guideline

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/interruptions.html b/wcag22/understanding/interruptions.html new file mode 100644 index 0000000..29f6dac --- /dev/null +++ b/wcag22/understanding/interruptions.html @@ -0,0 +1,341 @@ + + + + + + Understanding Success Criterion 2.2.4: Interruptions | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.2.4:Interruptions (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users are not interrupted.
+ +
What to do
+
Let people delay or turn off updates, except in emergencies.
+ +
Why it's important
+
Updates distract and disrupt assistive technology users and people with attention + deficits. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to allow users to turn off updates from the + author/server except in emergencies. Emergencies would include civil emergency alert + messages or any other messages that warn of danger to health, safety, or property, + including data loss, loss of connection, etcetera. + +

+

This allows access by people with cognitive limitations or attention disorders by + enabling them to focus on the content. It also allows users who are blind or have + low vision to keep their "viewing" focus on the content they are currently reading. + +

+
+
+

Benefits

+
    + + +
  • Individuals with attention deficit disorders can focus on content without distraction.
    • + + +
  • Individuals with low vision or who use screen readers will not have content updated + while they are viewing it (which can lead to discontinuity and misunderstanding if + they start reading in one topic and finish in another). + +
    • + + +
+
+
+

Examples

+
+ +
Example 1. Setting user preferences
+ +
The preferences page of a Web portal includes an option to postpone all updates and + alerts until the end of the current session, except for alerts concerning emergencies. +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
emergency
+
+ + + +

a sudden, unexpected situation or occurrence that requires immediate action to preserve + health, safety, or property + +

+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/intro.html b/wcag22/understanding/intro.html new file mode 100644 index 0000000..f3e7aa8 --- /dev/null +++ b/wcag22/understanding/intro.html @@ -0,0 +1,447 @@ + + + + + + Introduction to Understanding WCAG | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Introduction to Understanding WCAG

+
+ + +

Understanding WCAG 2.1 is an essential guide to understanding and using "Web Content Accessibility Guidelines 2.1". Although the normative definition and requirements for WCAG 2.1 can all be found + in the WCAG 2.1 document itself, the concepts and provisions may be new to some people. + Understanding WCAG 2.1 provides a non-normative extended commentary on each guideline + and each Success Criterion to help readers better understand the intent and how the + guidelines and Success Criteria work together. It also provides examples of techniques + or combinations of techniques that the Working Group has identified as being sufficient + to meet each Success Criterion. Links are then provided to write-ups for each of the + techniques. +

+ +

This is not an introductory document. It is a detailed technical description of the + guidelines and their Success Criteria. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction to WCAG, supporting technical documents, and educational material. + +

+ +

Understanding WCAG 2.1 is organized by guideline. There is an Understanding Guideline X.X section for each guideline. The intent and any advisory techniques that are related + to the guideline but not specifically related to any of its Success Criteria are listed + there as well. +

+ +

The Understanding Guidelines X.X section is then followed by a Understanding Success Criterion X.X.X section for each Success Criterion of that guideline. These sections each contain: +

+ +
    + +
  • + +

    The Success Criterion as it appears in WCAG 2.1

    + +
    • + +
  • + +

    Intent of the Success Criterion

    + +
    • + +
  • + +

    Benefits (how the Success Criterion helps people with disabilities)

    + +
    • + +
  • + +

    Examples

    + +
    • + +
  • + +

    Related Resources

    + +
    • + +
  • + +

    Techniques or combinations of techniques that are sufficient to meet the guidelines

    + +
    • + +
  • + +

    Common failures of this Success Criterion

    + +
    • + +
  • + +

    Additional advisory techniques that go beyond what is required to meet the Success + Criterion but can be used to make some or all types of content more accessible. Use + of advisory techniques does not impact the level of conformance claimed. +

    + +
    • + +
  • + +

    Key terms for this Success Criterion (taken from the WCAG 2.1 Glossary)

    + +
    • + +
+ +

Links are provided from each Guideline in WCAG 2.1 directly to each Understanding Guideline X.X in this document. Similarly, there is a link from each Success Criterion in WCAG + 2.1 to the Understanding Success Criterion X.X.X section in this document. +

+ +

For information about individual techniques, follow the links throughout this document + to the techniques of interest in the Techniques for WCAG 2.1 document. +

+ +

For links to information on different disabilities and assistive technologies see + Disabilities on Wikipedia. +

+ +
+ +

Understanding the Four Principles of Accessibility

+ +

The guidelines and Success Criteria are organized around the following four principles, + which lay the foundation necessary for anyone to access and use Web content. Anyone + who wants to use the Web must have content that is: +

+ +
    + +
  1. + +

    Perceivable - Information and user interface components must be presentable to users + in ways they can perceive. +

    + +
      + +
    • + +

      This means that users must be able to perceive the information being presented (it + can't be invisible to all of their senses) +

      + +
      • + +
    + +
    2. + +
  2. + +

    Operable - User interface components and navigation must be operable.

    + +
      + +
    • + +

      This means that users must be able to operate the interface (the interface cannot + require interaction that a user cannot perform) +

      + +
      • + +
    + +
    3. + +
  3. + +

    Understandable - Information and the operation of user interface must be understandable.

    + +
      + +
    • + +

      This means that users must be able to understand the information as well as the operation + of the user interface (the content or operation cannot be beyond their understanding) +

      + +
      • + +
    + +
    4. + +
  4. + +

    Robust - Content must be robust enough that it can be interpreted reliably by a wide + variety of user agents, including assistive technologies. +

    + +
      + +
    • + +

      This means that users must be able to access the content as technologies advance (as + technologies and user agents evolve, the content should remain accessible) +

      + +
      • + +
    + +
    5. + +
+ +

If any of these are not true, users with disabilities will not be able to use the + Web. +

+ +

Under each of the principles are guidelines and Success Criteria that help to address + these principles for people with disabilities. There are many general usability guidelines + that make content more usable by all people, including those with disabilities. However, + in WCAG 2.1, we only include those guidelines that address problems particular to + people with disabilities. This includes issues that block access or interfere with + access to the Web more severely for people with disabilities. +

+ +
+ +
+ +

Layers of Guidance

+ +
+ +

The Guidelines

+ +

Under each principle there is a list of guidelines that address the principle. There + are a total of 12 guidelines. A convenient list of just the guidelines can be found + in the WCAG 2.1 table of contents. One of the key objectives of the guidelines is to ensure that content is directly + accessible to as many people as possible, and capable of being re-presented in different + forms to match different peoples' sensory, physical and cognitive abilities. +

+ +
+ +
+ +

Success Criteria

+ +

Under each guideline, there are Success Criteria that describe specifically what must + be achieved in order to conform to this standard. They are similar to the "checkpoints" in WCAG 1.0. Each Success + Criterion is written as a statement that will be either true or false when specific + Web content is tested against it. The Success Criteria are written to be technology + neutral. +

+ +

All WCAG 2.1 Success Criteria are written as testable criteria for objectively determining + if content satisfies the Success Criteria. While some of the testing can be automated + using software evaluation programs, others require human testers for part or all of + the test. +

+ +

Although content may satisfy the Success Criteria, the content may not always be usable + by people with a wide variety of disabilities. Professional reviews utilizing recognized + qualitative heuristics are important in achieving accessibility for some audiences. + In addition, usability testing is recommended. Usability testing aims to determine + how well people can use the content for its intended purpose. +

+ +

The content should be tested by those who understand how people with different types + of disabilities use the Web. It is recommended that users with disabilities be included + in test groups when performing human testing. +

+ +

Each Success Criterion for a guideline has a link to the section of the How to Meet + document that provides: +

+ +
    + +
  • + +

    sufficient techniques for meeting the Success Criterion,

    + +
    • + +
  • + +

    optional advisory techniques, and

    + +
    • + +
  • + +

    descriptions of the intent of the Success Criteria, including benefits, and examples.

    + +
    • + +
+ +
+ +
+ +

Sufficient Techniques, Advisory Techniques, and Failures

+ +

The next section, Understanding Techniques for WCAG Success Criteria, provides important information about the techniques. +

+ +
+ +
+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/keyboard-accessible.html b/wcag22/understanding/keyboard-accessible.html new file mode 100644 index 0000000..b498657 --- /dev/null +++ b/wcag22/understanding/keyboard-accessible.html @@ -0,0 +1,302 @@ + + + + + + Understanding Guideline 2.1: Keyboard Accessible | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 2.1:Keyboard Accessible +

+ +
+
+

Intent

+

If all + functionality can be achieved using the keyboard, it can be accomplished by keyboard users, by + speech input (which creates keyboard input), by mouse (using on-screen keyboards), + and by a wide variety of assistive technologies that create simulated keystrokes as + their output. No other input form has this flexibility or is universally supported + and operable by people with different disabilities, as long as the keyboard input + is not time-dependent. + +

+

Note that providing universal keyboard input does not mean that other types of input + should not be supported. Optimized speech input, optimized mouse/pointer input, etc., + are also good. The key is to provide keyboard input and control as well. + +

+

Some devices do not have native keyboards—for example, a PDA or cell phone. If these + devices have a Web browsing capability, however, they will have some means of generating + text or "keystrokes". This guideline uses the term " + keyboard interface" to acknowledge that Web content should be controlled from keystrokes that may come + from a keyboard, keyboard emulator, or other hardware or software that generates keyboard + or text input. + +

+
+
+

Success Criteria for this Guideline

+ +
+
+
+ +

Key Terms

+ +
functionality
+
+ + + +

+ processes and outcomes achievable through user action + +

+ + + +
+
keyboard interface
+
+ + + +

interface used by software to obtain keystroke input

+ + +
+

Note

+
+ +

A keyboard interface allows users to provide keystroke input to programs even if the + native technology does not contain a keyboard. +

+ + + + +
+
+ + +
+

Note

+

Operation of the application (or parts of the application) through a keyboard-operated + mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard + interface because operation of the program is through its pointing device interface, + not through its keyboard interface. + +

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/keyboard-no-exception.html b/wcag22/understanding/keyboard-no-exception.html new file mode 100644 index 0000000..39a9437 --- /dev/null +++ b/wcag22/understanding/keyboard-no-exception.html @@ -0,0 +1,367 @@ + + + + + + Understanding Success Criterion 2.1.3: Keyboard (No Exception) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.1.3:Keyboard (No Exception) (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Everything can be done with a keyboard.
+ +
What to do
+
Ensure all pointer actions have a keyboard equivalent.
+ +
Why it's important
+
People who can only use the keyboard interface need to be able to accomplish everything.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that + all content is operable from the keyboard. This is the same as Success Criterion 2.1.1, + except that no exceptions are allowed. This does not mean that content where the underlying + function requires input that depends on the path of the user's movement and not just + the endpoints (excluded from the requirements of 2.1.1) must be made keyboard accessible. + Rather, it means that content that uses path-dependent input cannot conform to this + Success Criterion and therefore cannot meet Guideline 2.1 at Level AAA. + +

+
+

Note

+
+ +

Platforms and user agents usually have conventions for how web content or + applications are controlled with a keyboard interface. If content does not follow + the platform/user agent conventions it may be difficult to use, as users will need + to learn different interaction methods. As a best practice, content + should follow the platform/user agent conventions. However, deviating from these + conventions does not fail the normative requirement of this Success Criterion. +

+ +

+ For instance, buttons that have focus can generally be activated using both the + Enter key and the Space bar. If a custom button control + in a web application instead only reacts to Enter + (or even a completely custom key or key combination), this still + satisfies the requirements of this Success Criterion. + +

+ +
+
+
+

Note

+
+ +

This Success Criterion does not require that every visible control that can be activated + using a pointer (such as a mouse or touch screen input) must also be focusable and + actionable using the keyboard. + The normative requirement is only that there must be a way for keyboard interface + users to perform + the same, or comparable, actions and to operate the content. Generally, the easiest + way + to achieve this is to provide controls that can be operated with all possible input + devices; + however, if a web application implements a separate mode of operation for keyboard + interface users, + it will not fail the Success Criterion. + +

+ +
+
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+
+
+ +

Key Terms

+ +
functionality
+
+ + + +

+ processes and outcomes achievable through user action + +

+ + + +
+
keyboard interface
+
+ + + +

interface used by software to obtain keystroke input

+ + +
+

Note

+
+ +

A keyboard interface allows users to provide keystroke input to programs even if the + native technology does not contain a keyboard. +

+ + + + +
+
+ + +
+

Note

+

Operation of the application (or parts of the application) through a keyboard-operated + mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard + interface because operation of the program is through its pointing device interface, + not through its keyboard interface. + +

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/keyboard.html b/wcag22/understanding/keyboard.html new file mode 100644 index 0000000..11d830c --- /dev/null +++ b/wcag22/understanding/keyboard.html @@ -0,0 +1,659 @@ + + + + + + Understanding Success Criterion 2.1.1: Keyboard | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.1.1:Keyboard (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Everything can be done with a keyboard except freehand movements.
+ +
What to do
+
Ensure pointer actions have a keyboard equivalent.
+ +
Why it's important
+
Many people rely on the keyboard interface, including blind and some mobility impaired + people. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that, wherever possible, content + can be operated through a keyboard or keyboard interface (so an alternate keyboard + can be used). When content can be operated through a keyboard or alternate keyboard, + it is operable by people with no vision (who cannot use devices such as mice that + require eye-hand coordination) as well as by people who must use alternate keyboards + or input devices that act as keyboard emulators. Keyboard emulators include speech + input software, sip-and-puff software, on-screen keyboards, scanning software and + a variety of assistive technologies and alternate keyboards. Individuals with low + vision also may have trouble tracking a pointer and find the use of software much + easier (or only possible) if they can control it from the keyboard. + +

+

Examples of "specific timings for individual keystrokes" include situations where + a user would be required to repeat or execute multiple keystrokes within a short period + of time or where a key must be held down for an extended period before the keystroke + is registered. + + +

+

The phrase "except where the underlying function requires input that depends on the + path of the user's movement and not just the endpoints" is included to separate those + things that cannot reasonably be controlled from a keyboard. + +

+

Most actions carried out by a pointing device can also be done from the keyboard (for + example, clicking, selecting, moving, sizing). However, there is a small class of + input that is done with a pointing device that cannot be done from the keyboard in + any known fashion without requiring an inordinate number of keystrokes. Free hand + drawing, or watercolor painting require path dependent input. Drawing straight lines, + regular geometric shapes, re-sizing windows and dragging objects to a location (when + the path to that location is not relevant) do not require path dependent input. + + +

+

The use of MouseKeys would not satisfy this Success Criterion because it is not a + keyboard equivalent to the application; it is a mouse equivalent (i.e., it looks like + a mouse to the application). + +

+

It is assumed that the design of user input features takes into account that operating + system keyboard accessibility features may be in use. For example, modifier key locking + may be turned on. Content continues to function in such an environment, not sending + events that would collide with the modifier key lock to produce unexpected results. + + +

+
+

Note

+
+ +

Platforms and user agents usually have conventions for how web content or + applications are controlled with a keyboard interface. If content does not follow + the platform/user agent conventions it may be difficult to use, as users will need + to learn different interaction methods. As a best practice, content + should follow the platform/user agent conventions. However, deviating from these + conventions does not fail the normative requirement of this Success Criterion. +

+ +

+ For instance, buttons that have focus can generally be activated using both the + Enter key and the Space bar. If a custom button control + in a web application instead only reacts to Enter + (or even a completely custom key or key combination), this still + satisfies the requirements of this Success Criterion. + +

+ +
+
+
+

Note

+
+ +

This Success Criterion does not require that every visible control that can be activated + using a mouse or touch screen must also be focusable and actionable using the keyboard. + The normative requirement is only that there must be a way for keyboard interface + users to perform + the same, or comparable, actions and to operate the content. Generally, the easiest + way + to achieve this is to provide controls that can be operated with all possible input + devices; + however, if a web application implements a separate mode of operation for keyboard + interface users, + it will not fail the Success Criterion. + +

+ +
+
+
+
+

Benefits

+
    + + +
  • People who are blind (who cannot use devices such as mice that require eye-hand coordination)
    • + + +
  • People with low vision (who may have trouble finding or tracking a pointer indicator + on screen) + +
    • + + +
  • + Some people with hand tremors find using a mouse very difficult and therefore usually + use a keyboard + + + +
    • + + +
+
+
+

Examples

+
+ +
Example 1: A drawing Program
+ +
A drawing program allows users to create, size, position and rotate objects from the + keyboard. +
+ +
Example 2: A drag and Drop Feature
+ +
An application that uses drag and drop also supports "cut" and "paste" or form controls + to move objects. +
+ +
Example 3: Moving between and connecting discrete points
+ +
A connect-the-dots program allows the user to move between dots on a screen and use + the spacebar to connect the current dot to the previous one. +
+ +
Example 4: Exception - Painting Program
+ +
A watercolor painting program passes as an exception because the brush strokes vary + depending on the speed and duration of the movements. +
+ +
Example 5: Exception - Model helicopter flight training simulator
+ +
A model helicopter flight training simulator passes as an exception because the nature + of the simulator is to teach real-time behavior of a model helicopter. +
+ +
Example 6: A PDA with an optional keyboard
+ +
A PDA device that is usually operated via a stylus has an optional keyboard that can + be attached. The keyboard allows full Web browsing in standard fashion. The Web + content is operable because it was designed to work with keyboard-only access. +
+ +
Example 7: Simple search form with pointer-operable submit button
+ +
A search form includes a text input field followed by a submit button. The submit + button itself + has been coded so that it does not receive focus, and can only be activated using a pointer input. + However, since keyboard users can submit the search by pressing Enter in the text input + after typing their search terms, the form passes this Success Criterion. +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
functionality
+
+ + + +

+ processes and outcomes achievable through user action + +

+ + + +
+
keyboard interface
+
+ + + +

interface used by software to obtain keystroke input

+ + +
+

Note

+
+ +

A keyboard interface allows users to provide keystroke input to programs even if the + native technology does not contain a keyboard. +

+ + + + +
+
+ + +
+

Note

+

Operation of the application (or parts of the application) through a keyboard-operated + mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard + interface because operation of the program is through its pointing device interface, + not through its keyboard interface. + +

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/label-in-name.html b/wcag22/understanding/label-in-name.html new file mode 100644 index 0000000..47370f6 --- /dev/null +++ b/wcag22/understanding/label-in-name.html @@ -0,0 +1,1048 @@ + + + + + + Understanding Success Criterion 2.5.3: Label in Name | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.5.3:Label in Name (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
The visual label for controls is a trigger for speech activation.
+ +
What to do
+
Where practical, make the control’s text label and name match.
+ +
Why it's important
+
People who operate with voice interaction use the visible labels in their commands.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that the words which visually label + a component are also the words associated with the component programmatically. This + helps ensure that people with disabilities can rely on visible labels as a means to + interact with the components. +

+

Most controls are accompanied by a visible text label. Those same controls have a programmatic name, also known as the Accessible Name. Users typically have a much better experience if the words and characters in the + visible label of a control match or are contained within the accessible name. When + these match, speech-input users (i.e., users of speech recognition applications) can + navigate by speaking the visible text labels of components, such as menus, links, + and buttons, that appear on the screen. Sighted users who use text-to-speech (e.g., + screen readers) will also have a better experience if the text they hear matches the + text they see on the screen. +

+

Note that where a visible text label does not exist for a component, this Success + Criterion does not apply to that component. +

+

Where text labels exist and are properly linked to the user interface components through + established authoring practices, the label and name will normally match. When they + don't match, speech-input users who attempt to use the visible text label as a means + of navigation or selection (e.g., "move to Password") will be unsuccessful. The speech-based + navigation fails because the visible label spoken by the users does not match (or + is not part of) the accessible name that is enabled as a speech-input command. In + addition, when the accessible name is different from the visible label, it may function + as a hidden command that can be accidentally activated by speech-input users. +

+

Mismatches between visible labels and programmatic names for controls are even more + of an issue for speech-input and text-to-speech users who also have cognitive challenges. + Mismatches create an extra cognitive load for speech-input users, who must remember + to say a speech command that is different from the visible label they see on a control. + It also creates extra cognitive load for a text-to-speech user to absorb and understand + speech output that does not match the visible label. +

+

In order for the label text and accessible name to be matched, it is first necessary + to determine which text on the screen should be considered a label for any given control. + There are often multiple text strings in a user interface that may be relevant to + a control. However, there are reasons why it is best to conservatively interpret the + label as being only the text in close proximity. +

+

Conventionally the label for user interface components is the adjacent text string. + The typical positioning for left to right languages is: +

+
    +
  • immediately to the left of comboboxes, dropdown lists, text inputs, and other widgets + (or in the absence of left-side labels, immediately above and aligned with the left + edge of each input) +
    • + +
  • immediately to the right of checkboxes and radio buttons
    • + +
  • inside buttons and tabs or immediately below icons serving as buttons
    • + +
+

The rationale for some of these conventions is explained in G162: Positioning labels to maximize predictability of relationships. + +

+

It is important to bias towards treating only the adjacent text as a label because + liberal interpretations of what constitutes a text label can jeopardize the value + of this Success Criterion (SC) by lessening predictability. Isolating the label to + the single string in close proximity to the component makes it easier for developers, + testers, and end users to identify the label targeted for evaluation in this SC. Predictable + interpretation of labeling allows users of speech recognition technologies to interact + with the element via its conventionally positioned label, and allows users of screen + reading technologies to enjoy consistency between the nearby visible label and the + announced name of the component. +

+

Note that placeholder text within an input field is not considered an appropriate + means of providing a label. The HTML5 specification states The placeholder attribute should not be used as an alternative to a <label>. However, it is worth noting that "label" in that HTML5 statement is in code brackets + and links to the label element. For the purposes of this Label in Name Success Criterion, "label" is not + used in such a programmatic sense but is simply referring to a text string in close + visual proximity to a component. As such, in the absence of any other nearby text + string (as described in the preceding list), if an input contains placeholder text, + such text may be a candidate for Label in Name. This is supported both through the + accessible name calculation (discussed later) and from the practical sense that where + a visible label is not otherwise provided, it is likely that a speech-input user may + attempt to use the placeholder text value as a means of interacting with the input. +

+
+ +

Text labels "express something in human language"

+ +
+ +

Symbolic text characters

+ +

For the purposes of this SC, text should not be considered a visible label if it is + used in a symbolic manner, rather than directly expressing something in human language as per the definition of text in WCAG. For example, 1.4.5 Images of Text describes considerations for "symbolic text characters." In the images of text example + "B", "I", and "ABC" appear on icons in a text editor, where they are meant to symbolize + the functions for Bold, Italics, and Spelling, respectively. In such a case, the accessible + name should be the function the button serves (e.g., "Spell check" or "Check spelling"), + not the visible symbolic characters. A similar text editor is shown in the figure + below. +

+ +
+ Icons for transforming text, including heading, bold, italic, quote, code, and link, along with icons for ordered and unordered lists and other controls + +
Figure 1 A detail of the rich text editor in Github, showing a variety of unlabeled icons, + including icons resembling text characters. +
+ +
+ +

Likewise, where an author has used a greater-than symbol (">") to mimic the appearance + of the right-facing arrow, the text does not convey something in human language. It + is a symbol, in this scenario likely meant to mimic the icons used for a "Play" button + or a "Next" arrow. +

+ +

Punctuation and capitalization

+ +
+ +
+ +

The use of punctuation and capitalization in labels may also be considered optional for the same reason. For example, the colon conventionally + added at the end of input labels does not express something in human language, and + capitals on the first letter of each word in a label do not normally alter the words' + meaning. This is particularly relevant in the context of this SC, since it is primarily + aimed at users of speech recognition; capitals and most punctuation are frequently + ignored when a user speaks a label as a means of interacting with a control. +

+ +

While it is certainly not an error to include the colon and capitalization in the + accessible name, a computed name of "First name" should not be considered a failure + of "First Name:".
+
+ Likewise, "Next…" visibly shown on a button could have "Next" as the accessible name. + When in doubt, where a meaningful visible label exists, match the string exactly for + the accessible name.
+

+ +
+ +
+ + +

Mathematical expressions and formulae

+ +

Mathematical expressions are an exception to the previous subsection about symbolic + characters. Math symbols can be used as labels; for example "11×3=33" and "A>B" convey + meaning. The label should not be overwritten in the accessible name, and substitutions + of words where a formula is used should be avoided since there are multiple ways to + express the same equation. For example, making the name "eleven multiplied by three + is equivalent to thirty-three" might mean a user who said "eleven times three equals + thirty-three" may not match. It is best to leave the formulas as used in the label + and count on the user's familiarity with their speech software to achieve a match. + Further, converting a mathematical formula label into an accessible name that is a + spelled-out equivalent may create issues for translation. The name should match the + label's formula text. Note that a consideration for authors is to use the proper symbol + in the formula. For instance 11x3 (with a lower or upper case letter X), 11*3 (with + the asterisk symbol), and 11×3 (with the &times; symbol) are all easy for sighted users to interpret as meaning the same formula, + but may not all be matched to "11 times 3" by the speech recognition software. The + proper operator symbol (in this case the times symbol) should be used.
+ + + +

+ +
+ +
+
+ + +

Accessible Name and Description Computation specification

+ +

It is important to understand how the accessible name is derived. The Accessible Name and Description Computation 1.1 and the HTML Accessibility API Mappings 1.0 describe how the accessible name is computed, including which attributes are considered + in its calculation, and in what order of preference. If a component has multiple possible + attribute values that could be used for its accessible name, only the most preferred + of those values will be computed. None of the other, less preferred values will be + part of the name. For the most part, existing established programmatic relationships + between labels and controls are reinforced by the specification. +

+ +

Other text displayed on the screen that is correctly coded to meet 1.3.1: Info and + Relationships is not normally factored into the calculation for the accessible name of a UI component + without author intervention (via ARIA labeling techniques). The most common of these + are: +

+ +
    + +
  • headings and instructions
    • + +
  • group labels for sets of components (i.e., used with legend/fieldset or with role of group or radiogroup) +
    • + +
+ +

Such textual information may constitute part of the component's description. So from both a programmatic viewpoint, and from the conservative tactic of only + considering a label to be "adjacent text," neither headings, instructions, nor group + 'labels' should normally be considered labels for the purpose of this Success Criterion. +

+ +

It is important to note that the specification allows authors to override the name + calculated through native semantics. Both aria-label and aria-labelledby take precedence in the name calculation, overriding the visible text as the accessible + name even when the visible text label is programmatically associated with the control. + For this reason, when a visible label already exists, aria-label should be avoided or used carefully, and aria-labelledby should be used as a supplement with care. +

+ +

Finally, aria-describedby is not included in the Accessible Name computation (instead it is part of the Accessible + Description computation). By convention, text associated with a control through aria-describedby is announced immediately after the accessible name by screen readers. Therefore, + the context of headings, instructions, and group labels can be provided through the + accessible description to assist users of screen readers without affecting the experience + of those who navigate using speech recognition software. +

+ +
+
+
+

Benefits

+
    + +
  • Speech-input users can directly activate controls on a page with fewer surprising + changes of focus. +
    • + +
  • Text-to-speech users will have a better experience because the labels that they hear + match the visible text labels that + they see on the screen. +
    • + +
+
+
+

Examples

+
    + +
  • Accessible name matches visible label: The accessible name and visible label of a control match. +
    • + +
  • Accessible name starts with visible label: The accessible name "Search for a value" begins with the text of the visible label, + "Search". +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. + +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+
    + +
  • F96: Failure due to the accessible name not containing the visible label text
    • + +
  • Accessible name contains the visible label text, but the words of the visible label + are not in the same order as they are in the visible label text (Potential future + technique) +
    • + +
  • Accessible name contains the visible label text, but one or more other words are interspersed + in the label (Potential future technique) +
    • + +
+
+
+
+
+ +

Key Terms

+ +
ascii art
+
+ + + +

picture created by a spatial arrangement of characters or glyphs (typically from the + 95 printable characters defined by ASCII) + +

+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
image of text
+
+ + + +

text that has been rendered in a non-text form (e.g., an image) in order to achieve + a particular visual effect + +

+ + +
+

Note

+

This does not include text that is part of a picture that contains significant other visual content. + +

+
+ + + + + + +
+
label
+
+ + + +

+ text or other component with a text alternative that is presented to a user to identify a component within Web content + +

+ + +
+

Note

+

A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases + the name and the label are the same. + +

+
+ + +
+

Note

+

The term label is not limited to the label element in HTML.

+
+ + + +
+
name
+
+ + + +

text by which software can identify a component within Web content to the user

+ + +
+

Note

+

The name may be hidden and only exposed by assistive technology, whereas a label is presented to all users. In many (but not all) cases, the label and the name are + the same. + +

+
+ + +
+

Note

+

This is unrelated to the name attribute in HTML.

+
+ + + +
+
non-text content
+
+ + + +

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language + +

+ + +
+

Note

+

This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), + and images representing text + +

+
+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
text alternative
+
+ + + +

+ Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. + Programmatically associated text is text whose location can be programmatically determined + from the non-text content. + +

+ + + + + +
+

Note

+

Refer to Understanding Text Alternatives for more information. + +

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/labels-or-instructions.html b/wcag22/understanding/labels-or-instructions.html new file mode 100644 index 0000000..ca97001 --- /dev/null +++ b/wcag22/understanding/labels-or-instructions.html @@ -0,0 +1,963 @@ + + + + + + Understanding Success Criterion 3.3.2: Labels or Instructions | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.3.2:Labels or Instructions (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users know what information to enter.
+ +
What to do
+
Provide labels or instructions for inputs.
+ +
Why it's important
+
Everyone, especially those with cognitive disabilities, will know how to respond.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to have content authors present instructions + or labels that identify the controls in a form so that users know what input data + is expected. In the case of radio buttons, checkboxes, comboboxes, or similar controls + that provide users with options, each option must have an appropriate label so that + users know what they are actually selecting. + Instructions or labels may also specify data formats for data entry fields, especially + if they are out of the customary formats or if there are specific rules for correct + input. Content authors may also choose to make such instructions available to users + only when the individual control has focus especially when instructions are long and + verbose. + +

+

The intent of this Success Criterion is not to clutter the page with unnecessary information + but to provide important cues and instructions that will benefit people with disabilities. + Too much information or instruction can be just as harmful as too little. + The goal is to make certain that enough information is provided for the user to accomplish + the task without undue confusion or navigation. + +

+

This Success Criterion does not require that labels or instructions be correctly marked + up, + identified, or associated with their respective controls - this aspect is covered + separately by + 1.3.1: Info and Relationships. It is possible for content + to pass this Success Criterion (providing relevant labels and instructions) while + failing + Success Criterion 1.3.1 (if the labels or instructions aren't correctly marked up, + identified, or associated). + +

+

Further, this Success Criterion does not take into consideration whether or not alternative + methods of + providing an accessible name or description for form controls and inputs has been + used - this aspect is + covered separately by 4.1.2: Name, Role and Value. It is possible + for controls and inputs to have an appropriate accessible name or description (e.g. + using aria-label="...") + and therefore pass Success Criterion 4.1.2, but to still fail this Success Criterion + (if the labels or instructions + aren't presented to all users, not just those using assistive technologies). + +

+

This Success Criterion does not apply to links or other controls (such as an expand/collapse + widget, or similar + interactive components) that are not associated with data entry. + +

+

While this Success Criterion requires that controls and inputs have labels or instructions, + whether or + not labels (if used) are sufficiently clear or descriptive is covered separately by + 2.4.6: Headings and Labels. + +

+
+
+

Benefits

+
    + + +
  • Providing labels and instructions (including examples of expected + data formats) helps all users - but particularly those with cognitive, language, and + learning + disabilities - to enter information correctly. + +
    • + + +
  • Providing labels and instructions (including identification of required + fields) can prevent users from making incomplete or incorrect form submissions, which + prevents + users from having to navigate once more through a page/form in order to fix submission + errors. + +
    • + + +
+
+
+

Examples

+
    + + +
  • A field which requires the user to enter the two character abbreviation for a US state + has a link next to it which will popup an alphabetized list of state names and the + correct abbreviation. + +
    • + + +
  • A field for entering a date contains initial text which indicates the correct format + for the date. + +
    • + + +
  • To enter their name, users are provided with two separate text fields. Rather than + having a single label "Name" (which would appear to leave the second text field unlabelled), + each field is given an explicit label - "Given Name" and "Family Name". + +
    • + + +
  • A U.S. phone number separates the area code, exchange, and number into three fields. + Parentheses surround the area code field, and a dash separates the exchange and number + fields. While the punctuation provides visual clues to those familiar with the U.S. + telephone number format, the punctuation is not sufficient to label the fields. The + single "Phone number" label also cannot label all three fields. To address this, the + three fields are grouped in a fieldset with the legend "Phone number". Visual labels + for + the fields (beyond the punctuation) cannot be provided + in the design, so invisible labels are provided with the "title" attribute to each + of the three fields. The value of this attribute for the three fields are, respectively, + "Area Code", "Exchange", and "Number". + +
    • + + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+

Note

+
+ + +

The techniques at the end of the above list should be considered "last resort" and + only used when the other techniques cannot be applied to the page. The earlier techniques + are preferred because they increase accessibility to a wider user group. + + +

+ + +
+
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
ascii art
+
+ + + +

picture created by a spatial arrangement of characters or glyphs (typically from the + 95 printable characters defined by ASCII) + +

+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
label
+
+ + + +

+ text or other component with a text alternative that is presented to a user to identify a component within Web content + +

+ + +
+

Note

+

A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases + the name and the label are the same. + +

+
+ + +
+

Note

+

The term label is not limited to the label element in HTML.

+
+ + + +
+
name
+
+ + + +

text by which software can identify a component within Web content to the user

+ + +
+

Note

+

The name may be hidden and only exposed by assistive technology, whereas a label is presented to all users. In many (but not all) cases, the label and the name are + the same. + +

+
+ + +
+

Note

+

This is unrelated to the name attribute in HTML.

+
+ + + +
+
non-text content
+
+ + + +

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language + +

+ + +
+

Note

+

This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), + and images representing text + +

+
+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
text alternative
+
+ + + +

+ Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. + Programmatically associated text is text whose location can be programmatically determined + from the non-text content. + +

+ + + + + +
+

Note

+

Refer to Understanding Text Alternatives for more information. + +

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/language-of-page.html b/wcag22/understanding/language-of-page.html new file mode 100644 index 0000000..8d6d793 --- /dev/null +++ b/wcag22/understanding/language-of-page.html @@ -0,0 +1,635 @@ + + + + + + Understanding Success Criterion 3.1.1: Language of Page | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.1.1:Language of Page (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Assistive technology can determine the language of a page.
+ +
What to do
+
Indicate the predominant language on a page.
+ +
Why it's important
+
People using assistive technology get information in the correct language.
+ +
+
+
+

Intent

+

+ The intent of this Success Criterion is to ensure that content developers provide + information in the Web page that user agents need to present text and other linguistic + content correctly. Both assistive technologies and conventional user agents can render + text more accurately when the language of the Web page is identified. Screen readers + can load the correct pronunciation rules. Visual browsers can display characters and + scripts correctly. Media players can show captions correctly. As a result, users with + disabilities will be better able to understand the content. + + +

+

The default human language of the Web page is the default text-processing language + as discussed in + Internationalization Best Practices: Specifying Language in XHTML & HTML Content. When a Web page uses several languages, the default text-processing language is + the language which is used most. (If several languages are used equally, the first + language used should be chosen as the default human language.) + + +

+
+

Note

+
+ + +

+ For multilingual sites targeting Conformance Level A, the Working Group strongly encourages + developers to follow Success Criterion 3.1.2 as well even though that is a Level AA + Success Criterion. + + + +

+ + +
+
+
+
+

Benefits

+

This Success Criterion helps:

+
    + + +
  • people who use screen readers or other technologies that convert text into synthetic + speech; + +
    • + + +
  • people who find it difficult to read written material with fluency and accuracy, such + as recognizing characters and alphabets or decoding words; + +
    • + + +
  • people with certain cognitive, language and learning disabilities who use text-to-speech + software + + +
    • + + +
  • people who rely on captions for synchronized media.
    • + + +
+
+
+

Examples

+
+ +
Example 1. A Web page with content in two languages
+ +
A Web page produced in Germany and written in HTML includes content in both German + and English, but most of the content is in German. The default human language is identified + as German (de) by the lang attribute on the html element. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/language-of-parts.html b/wcag22/understanding/language-of-parts.html new file mode 100644 index 0000000..0b7d460 --- /dev/null +++ b/wcag22/understanding/language-of-parts.html @@ -0,0 +1,628 @@ + + + + + + Understanding Success Criterion 3.1.2: Language of Parts | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.1.2:Language of Parts (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Assistive technology can identify the languages used within a page.
+ +
What to do
+
Indicate when words are in a different language.
+ +
Why it's important
+
People using assistive technology get information in the correct language.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that user agents can correctly present + phrases, passages, and in some cases words written in multiple languages. This makes + it possible for user agents and + assistive technologies to present content according to the presentation and pronunciation + rules for that language. This applies to graphical browsers as well as screen readers, + braille displays, and other voice browsers. + +

+

Both assistive technologies and conventional user agents can render text more accurately + if the language of each passage of text is identified. Screen readers can use the + pronunciation rules of the language of the text. Visual browsers can display characters + and scripts in appropriate ways. This is especially important when switching between + languages that read from left to right and languages that read from right to left, + or when text is rendered in a language that uses a different alphabet. Users with + disabilities who know all the languages used in the Web page will be better able to + understand the content when each passage is rendered appropriately. + +

+

When no other language has been specified for a phrase or passage of text, its human + language is the default human language of the Web page (see Success Criterion 3.1.1). So the human language of all content in single language documents can be programmatically + determined. + +

+

Individual words or phrases in one language can become part of another language. For + example, "rendezvous" is a French word that has been adopted in English, appears in + English dictionaries, and is properly pronounced by English screen readers. Hence + a passage of English text may contain the word "rendezvous" without specifying that + its human language is French and still satisfy this Success Criterion. Frequently, + when the human language of text appears to be changing for a single word, that word + has become part of the language of the surrounding text. Because this is so common + in some languages, single words should be considered part of the language of the surrounding + text unless it is clear that a change in language was intended. If there is doubt + whether a change in language is intended, consider whether the word would be pronounced + the same (except for accent or intonation) in the language of the immediately surrounding + text. + +

+

Most professions require frequent use of technical terms which may originate from + a foreign language. Such terms are usually not translated to all languages. The universal + nature of technical terms also facilitate communication between professionals. + +

+

Some common examples of technical terms include: Homo sapiens, Alpha Centauri, hertz, + and habeas corpus. + +

+

Identifying changes in language is important for a number of reasons:

+
    + + +
  • It allows braille translation software to follow changes in language, e.g., substitute + control codes for accented characters, and insert control codes necessary to prevent + erroneous creation of Grade 2 braille contractions. + +
    • + + +
  • Speech synthesizers that support multiple languages will be able to speak the text + in the appropriate accent with proper pronunciation. If changes are not marked, the + synthesizer will try its best to speak the words in the default language it works + in. Thus, the French word for car, "voiture" would be pronounced "voyture" by a speech + synthesizer that uses English as its default language. + +
    • + + +
  • Marking changes in language can benefit future developments in technology, for example + users who are unable to translate between languages themselves will be able to use + machines to translate unfamiliar languages. + +
    • + + +
  • Marking changes in language can also assist user agents in providing definitions using + a dictionary. + +
    • + + +
+
+
+

Benefits

+

This Success Criterion helps:

+
    + +
  • people who use screen readers or other technologies that convert text into synthetic + speech; + +
    • + + +
  • people who find it difficult to read written material with fluency and accuracy, such + as recognizing characters and alphabets, decoding words, and understanding words and + phrases; + +
    • + + +
  • people with certain cognitive, language and learning disabilities who use text-to-speech + software; + + +
    • + + +
  • people who rely on captions to recognize language changes in the soundtrack of synchronized + media content. + +
    • + + +
+
+
+

Examples

+
    + +
  • + +

    + A German phrase in an English sentence. + +

    + +

    In the sentence, "He maintained that the DDR (German Democratic Republic) was just + a 'Treppenwitz der Weltgeschichte'," the German phrase 'Treppenwitz der Weltgeschichte' is marked as German. Depending on the markup language, English may either be marked + as the language for the entire document except where specified, or marked at the paragraph + level. When a screen reader encounters the German phrase, it changes pronunciation + rules from English to German to pronounce the word correctly. + +

    + +
    • + +
  • + +

    + Alternative language links + +

    + +

    An HTML Web page includes links to versions of the page in other languages (e.g., + Deutsch, Français, Nederlands, Catalan, etc.). The text of each link is the name of the language, in that language. The + language of each link is indicated via a lang attribute. + +

    + 
    <ul>
+  <li><a href="..." lang="de">Deutsch</a></li>
+  <li><a href="..." lang="it">Italiano</a></li>
+  <li><a href="..." lang="fr">Français</a></li>
+  ...
+  <li><a href="..." lang="zh-hant">繁體中文</a></li>
+</ul>
    +
    • + +
  • + +

    + "Podcast" used in a French sentence. + +

    + +

    Because "podcast" is part of the vernacular of the immediately surrounding text in + the following excerpt, "À l'occasion de l'exposition "Energie éternelle. 1500 ans d'art indien", le Palais + des Beaux-Arts de Bruxelles a lancé son premier podcast. Vous pouvez télécharger ce + podcast au format M4A et MP3", no indication of language change is required. + +

    + +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/link-purpose-in-context.html b/wcag22/understanding/link-purpose-in-context.html new file mode 100644 index 0000000..380f808 --- /dev/null +++ b/wcag22/understanding/link-purpose-in-context.html @@ -0,0 +1,1590 @@ + + + + + + Understanding Success Criterion 2.4.4: Link Purpose (In Context) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.4:Link Purpose (In Context) (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users understand what each link will do.
+ +
What to do
+
Provide descriptive names or context for all links.
+ +
Why it's important
+
People with visual and cognitive disabilities can navigate more easily.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to help users understand the purpose of each + link so they can decide whether they want to follow the link. Whenever possible, provide + link text that identifies the purpose of the link without needing additional context. + Assistive technology has the ability to provide users with a list of links that are + on the Web page. Link text that is as meaningful as possible will aid users who want + to choose from this list of links. Meaningful link text also helps those who wish + to tab from link to link. Meaningful links help users choose which links to follow + without requiring complicated strategies to understand the page. + +

+

The text of, or associated with, the link is intended to describe the purpose of the + link. In cases where the link takes one to a document or a web application, the name + of the document or web application would be sufficient to describe the purpose of + the link (which is to take you to the document or web application). Note that it is + not required to use the name of the document or web application; other things may + also describe the purpose of the link. + +

+

+ + Success Criterion 2.4.2 deals with the titles of pages. Here also, the name of a document or web application + being presented on the page would be sufficient to describe the purpose of the page. + Having the link and the title agree, or be very similar, is good practice and provides + continuity between the link 'clicked on' and the web page that the user lands on. + + +

+

In some situations, authors may want to provide part of the description of the link + in logically related text that provides the context for the link. In this case the + user should be able to identify the purpose of the link without moving focus from + the link. In other words, they can arrive on a link and find out more about it without + losing their place. This can be achieved by putting the description of the link in + the same sentence, paragraph, list item, or table cell as the link, or in the table + header cell for a link in a data table, because these are directly associated with + the link itself. Alternatively, authors may choose to use an ARIA technique to associate + additional + text on the page with the link. + +

+

This context will be most usable if it precedes the link. (For instance, if you must + use ambiguous link text, it is better to put it at the end of the sentence that describes + its destination, rather than putting the ambiguous phrase at the beginning of the + sentence.) If the description follows the link, there can be confusion and difficulty + for screen reader users who are reading through the page in order (top to bottom). + + +

+

It is a best practice for links with the same destination to have consistent text + (and this is a requirement per + Success Criterion 3.2.4 for pages in a set). It is also a best practice for links with different purposes + and destinations to have different link text. + +

+

A best practice for links to conforming alternate versions is to ensure that the link text to the conforming alternate version indicates in + link text that the page it leads to represents the more accessible version. This information + may also be provided in text - the goal is to ensure that the end user knows what + the purpose of the link is. +

+

The Success Criterion includes an exception for links for which the purpose of the + link cannot be determined from the information on the Web page. In this situation, + the person with the disability is not at a disadvantage; there is no additional context + available to understand the link purpose. However, whatever amount of context is available + on the Web page that can be used to interpret the purpose of the link must be made + available in the link text or programmatically associated with the link to satisfy + the Success Criterion. + +

+
+

Note

+
+ + +

There may be situations where the purpose of the link is is supposed to be unknown + or obscured. For instance, a game may have links identified only as door #1, door + #2, and door #3. This link text would be sufficient because the purpose of the links + is to create suspense for all users. + +

+ + +
+
+

See also + 2.4.9: Link Purpose (Link Only). + +

+
+
+

Benefits

+
    + + +
  • This Success Criterion helps people with motion impairment by letting them skip links + that they are not interested in, avoiding the keystrokes needed to visit the referenced + content and then returning to the current content. + +
    • + + +
  • People with cognitive limitations will not become disoriented by multiple means of + navigation to and from content they are not interested in. + +
    • + + +
  • + People with visual disabilities will be able to determine the purpose of a link by + exploring the link's context. + + + +
    • + + +
+
+
+

Examples

+
+ +
A link contains text that gives a description of the information at that URI
+ +
A page contains the sentence "There was much bloodshed during the Medieval period + of history." Where "Medieval period of history" is a link. +
+ +
A link is preceded by a text description of the information at that URI
+ +
A page contains the sentence "Learn more about the Government of Ireland's Commission + on Electronic Voting at Go Vote!" where "Go Vote!" is a link. +
+ +
Both an icon and text are included in the same link
+ +
An icon of a voting machine and the text "Government of Ireland's Commission of Electronic + Voting" are combined to make a single link. The alt text for the icon is null, since + the purpose of the link is already described by the text of the link next to the icon. +
+ +
A list of book titles
+ +
A list of books is available in three formats: HTML, PDF, and mp3 (a recording of + a person reading the book). To avoid hearing the title of each book three times (once + for each format), the first link for each book is the title of the book, the second + link says "PDF" and the third says, "mp3." +
+ +
News article summaries
+ +
A Web page contains a collection of news articles. The main page lists the first few + sentences of each article, followed by a "Read more" link. A screen reader command + to read the current paragraph provides the context to interpret the purpose of the + link. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
accessibility supported
+
+ + + +

supported by users' assistive technologies as well as the accessibility features in browsers and other user agents + +

+ + +

To qualify as an accessibility-supported use of a Web content technology (or feature + of a technology), both 1 and 2 must be satisfied for a Web content technology (or + feature): + +

+ + +
    + + +
  1. + + +

    + The way that the Web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability + with users' assistive technology in the human language(s) of the content, + +

    + + +

    + AND + +

    + + +
    2. + + +
  2. + + +

    + The Web content technology must have accessibility-supported user agents that are + available to users. This means that at least one of the following four statements is true: + +

    + + +
      + + +
    1. + + +

      The technology is supported natively in widely-distributed user agents that are also + accessibility supported (such as HTML and CSS); + +

      + + +

      + OR + +

      + +
      2. + + +
    2. + +

      The technology is supported in a widely-distributed plug-in that is also accessibility + supported; + +

      + + +

      + OR + +

      + +
      3. + + +
    3. + +

      The content is available in a closed environment, such as a university or corporate + network, where the user agent required by the technology and used by the organization + is also accessibility supported; + +

      + + +

      + OR + +

      + +
      4. + + +
    4. + +

      The user agent(s) that support the technology are accessibility supported and are + available for download or purchase in a way that: + +

      + + +
        + + +
      • does not cost a person with a disability any more than a person without a disability + and + +
        • + + +
      • is as easy to find and obtain for a person with a disability as it is for a person + without disabilities. + +
        • + + +
      + + +
      5. + + +
    + + +
    3. + + +
+ + +
+

Note

+

The Accessibility Guidelines Working Group and the W3C do not specify which or how + much support by assistive + technologies there must be for a particular use of a Web technology in order for it + to be classified as accessibility supported. (See Level of Assistive Technology Support Needed for "Accessibility Support".) + +

+
+ + +
+

Note

+

Web technologies can be used in ways that are not accessibility supported as long + as they are not relied upon and the page as a whole meets the conformance requirements, including Conformance Requirement 4 and Conformance Requirement 5. + +

+
+ + +
+

Note

+

When a Web Technology is used in a way that is "accessibility supported," it does not imply that the entire + technology or all uses of the technology are supported. Most technologies, including + HTML, lack support for at least one feature or use. Pages conform to WCAG only if + the uses of the technology that are accessibility supported can be relied upon to + meet WCAG requirements. + +

+
+ + +
+

Note

+

When citing Web content technologies that have multiple versions, the version(s) supported + should be specified. + +

+
+ + +
+

Note

+

One way for authors to locate uses of a technology that are accessibility supported + would be to consult compilations of uses that are documented to be accessibility supported. + (See Understanding Accessibility-Supported Web Technology Uses.) Authors, companies, technology vendors, or others may document accessibility-supported + ways of using Web content technologies. However, all ways of using technologies in + the documentation would need to meet the definition of accessibility-supported Web + content technologies above. + +

+
+ + + +
+
ambiguous to users in general
+
+ + + +

the purpose cannot be determined from the link and all information of the Web page + presented to the user simultaneously with the link (i.e., readers without disabilities + would not know what a link would do until they activated it) + +

+ + + + + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
conforming alternate version
+
+ + + +

version that

+ + +
    + + +
  1. conforms at the designated level, and
    2. + + +
  2. provides all of the same information and functionality in the same human language, and + +
    3. + + +
  3. is as up to date as the non-conforming content, and
    4. + + +
  4. + +

    for which at least one of the following is true:

    + + +
      + + +
    1. the conforming version can be reached from the non-conforming page via an accessibility-supported + mechanism, or + +
      2. + + +
    2. the non-conforming version can only be reached from the conforming version, or
      3. + + +
    3. the non-conforming version can only be reached from a conforming page that also provides + a mechanism to reach the conforming version + +
      4. + + +
    + + +
    5. + + +
+ + +
+

Note

+

In this definition, "can only be reached" means that there is some mechanism, such + as a conditional redirect, that prevents a user from "reaching" (loading) the non-conforming + page unless the user had just come from the conforming version. + +

+
+ + +
+

Note

+

The alternate version does not need to be matched page for page with the original + (e.g., the conforming alternate version may consist of multiple pages). + +

+
+ + +
+

Note

+

If multiple language versions are available, then conforming alternate versions are + required for each language offered. + +

+
+ + +
+

Note

+

Alternate versions may be provided to accommodate different technology environments + or user groups. Each version should be as conformant as possible. One version would + need to be fully conformant in order to meet conformance requirement 1. + +

+
+ + +
+

Note

+

The conforming alternative version does not need to reside within the scope of conformance, + or even on the same Web site, as long as it is as freely available as the non-conforming + version. + +

+
+ + +
+

Note

+

Alternate versions should not be confused with supplementary content, which support the original page and enhance comprehension. + +

+
+ + +
+

Note

+

Setting user preferences within the content to produce a conforming version is an + acceptable mechanism for reaching another version as long as the method used to set + the preferences is accessibility supported. + +

+
+ + +

See Understanding Conforming Alternate Versions + +

+ + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
functionality
+
+ + + +

+ processes and outcomes achievable through user action + +

+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+ +
+ + + +

nature of the result obtained by activating a hyperlink

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+ +
+ + + +

additional information that can be programmatically determined from relationships with a link, combined with the link text, and presented to users in different modalities + +

+ + + + + +
+

Note

+

Since screen readers interpret punctuation, they can also provide the context from + the current sentence, when the focus is on a link in that sentence. + +

+
+ + + +
+
relationships
+
+ + + +

meaningful associations between distinct pieces of content

+ + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
supplemental content
+
+ + + +

additional content that illustrates or clarifies the primary content + +

+ + + + + + + + + + + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/link-purpose-link-only.html b/wcag22/understanding/link-purpose-link-only.html new file mode 100644 index 0000000..7536940 --- /dev/null +++ b/wcag22/understanding/link-purpose-link-only.html @@ -0,0 +1,840 @@ + + + + + + Understanding Success Criterion 2.4.9: Link Purpose (Link Only) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.9:Link Purpose (Link Only) (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users understand what each link will do.
+ +
What to do
+
Provide descriptive names for all links.
+ +
Why it's important
+
Descriptive link text is more understandable for all users, especially when using + assistive technology. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to help users understand the purpose of each + link in the content, so they can decide whether they want to follow it. Best practice + is that links with the same destination would have the same descriptions, but links + with different purposes and destinations would have different descriptions (see also + + Success Criterion 3.2.4 which calls for consistency in identifying components that have the same functionality). + Because the purpose of a link can be identified from its link text, links can be understood + when they are out of context, such as when the user agent provides a list of all the + links on a page. + +

+

The text in the link is intended to describe the purpose of the link. In cases where + the link takes one to a document or a web application, the name of the document or + web application would be sufficient to describe the purpose of the link (which is + to take you to the document or web application). Note that it is not required to use + the name of the document or web application; other things may also describe the purpose + of the link. + +

+

+ + Success Criterion 2.4.2 deals with the titles of pages. Here also, the name of a document or web application + being presented on the page would be sufficient to describe the purpose of the page. + Having the link and the title agree, or be very similar, is good practice and provides + continuity between the link 'clicked on' and the web page that the user lands on. + + +

+

The Success Criterion includes an exception for links for which the purpose of the + link cannot be determined from the information on the Web page. In this situation, + the person with the disability is not at a disadvantage; there is no additional context + available to understand the link purpose. However, whatever amount of context is available + on the Web page that can be used to interpret the purpose of the link must be made + available in the link text to satisfy the Success Criterion. + +

+

The word "mechanism" is used to allow authors to either make all links fully understandable + out of context by default or to provide a way to make them this way. This is done + because for some pages, making the links all unambiguous by themselves makes the pages + easier for some users and harder for others. Providing the ability to make the links + unambiguous (by them selves) or not provides both users with disabilities with the + ability to use the page in the format that best meets their needs. + +

+

For example: A page listing 100 book titles along with links to download the books + in HTML, PDF, DOC, TXT, MP3, or AAC might ordinarily be viewed as the title of the + book as a link with the words "in HTML" after it. then the sentence "Also available + in: " followed by a series of short links with text of "HTML", "PDF", "DOC", "TXT", + "MP3", and "AAC". At Level 3, some users could opt to view the page this way - because + they would find the page harder to understand or slower to use if the full title of + the book were included in each of the links. Others could opt to view the page with + the full title as part of each of the links so that each link was understandable in + itself. Both the former and the latter groups could include people with visual or + cognitive disabilities that used different techniques to browse or that had different + types or severities of disability. + +

+
+
+

Benefits

+
    + + +
  • This Success Criterion helps people with motion impairment by letting them skip Web + pages that they are not interested in, avoiding the keystrokes needed to visit the + referenced content and then return to the current content. + +
    • + + +
  • People with cognitive limitations will not become disoriented by extra navigation + to and from content they are not interested in. + +
    • + + +
  • People with visual disabilities will benefit from not losing their place in the content + when they return to the original page. The screen reader's list of links is more useful + for finding information because the target of the links are described. + +
    • + + +
+
+
+

Examples

+
+ +
Both an icon and text are included in the same link
+ +
An icon of a voting machine and the text "Government of Ireland's Commission of Electronic + Voting" are combined to make a single link. +
+ +
A list of book titles
+ +
A list of books is available in three formats: HTML, PDF, and mp3 (a recording of + a person reading the book). The title of the book is followed by links to the different + formats. The rendered text for each link is just the format type, but the text associated + with each link includes the title as well as the format; for instance, "Gulliver's + Travels, MP3." +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
ambiguous to users in general
+
+ + + +

the purpose cannot be determined from the link and all information of the Web page + presented to the user simultaneously with the link (i.e., readers without disabilities + would not know what a link would do until they activated it) + +

+ + + + + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/location.html b/wcag22/understanding/location.html new file mode 100644 index 0000000..0ea6283 --- /dev/null +++ b/wcag22/understanding/location.html @@ -0,0 +1,575 @@ + + + + + + Understanding Success Criterion 2.4.8: Location | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.8:Location (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users know where they are in a set of pages.
+ +
What to do
+
Use breadcrumbs, site maps, or other indicators to give context.
+ +
Why it's important
+
Location indicators reduce confusion for people with cognitive disabilities.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to provide a way for the user to orient herself + within a set of Web pages, a Web site, or a Web application and find related information. + +

+
+
+

Benefits

+
    + + +
  • This Success Criterion is helpful for people with a short attention span who may become + confused when following a long series of navigation steps to a Web page. It is also + helpful when a user follows a link directly to a page deep within a set of Web pages + and needs to navigate that Web site to understand the content of that page or to find + more related information. + +
    • + + +
+
+
+

Examples

+
+ +
Links to help user determine their location in a site
+ +
A research group is part of an educational department at a university. The group's + home page links to the department home page and the university's home page. +
+ +
A breadcrumb trail
+ +
A portal Web site organizes topics into categories. As the user navigates through + categories and subcategories, a breadcrumb trail shows the current location in the + hierarchy of categories. Each page also contains a link to the portal home page. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
set of web pages
+
+ + + +

collection of web pages that share a common purpose and that are created by the same author, group or organization + +

+ + + + + +
+

Note

+

Different language versions would be considered different sets of Web pages.

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/low-or-no-background-audio.html b/wcag22/understanding/low-or-no-background-audio.html new file mode 100644 index 0000000..95913ae --- /dev/null +++ b/wcag22/understanding/low-or-no-background-audio.html @@ -0,0 +1,450 @@ + + + + + + Understanding Success Criterion 1.4.7: Low or No Background Audio | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.7:Low or No Background Audio (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Prerecorded speech is not disrupted by background sound.
+ +
What to do
+
Avoid or lessen background sound, or let users turn it off.
+ +
Why it's important
+
People who are hard of hearing may have difficulty distinguishing speech from music + and other sounds. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that any non-speech sounds are low + enough that a user who is hard of hearing can separate the speech from background + sounds or other noise foreground speech content. + + + +

+

The value of 20 dB was chosen based on Large area assistive listening systems (ALS): + Review and recommendations [[LAALS]] and In-the-ear measurements of interference in + hearing aids from digital wireless + telephones [[HEARING-AID-INT]] + + +

+
+
+

Benefits

+
    + + +
  • People who are hard of hearing often have great difficulty separating speech from + background sound. + +
    • + + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+
+
+ +

Key Terms

+ +
audio
+
+ + + +

the technology of sound reproduction

+ + +
+

Note

+

Audio can be created synthetically (including speech synthesis), recorded from real + world sounds, or both. + +

+
+ + + +
+
audio-only
+
+ + + +

a time-based presentation that contains only audio (no video and no interaction) + +

+ + + +
+
captcha
+
+ + + +

initialism for "Completely Automated Public Turing test to tell Computers and Humans + Apart" + +

+ + +
+

Note

+

CAPTCHA tests often involve asking the user to type in text that is displayed in an + obscured image or audio file. + +

+
+ + +
+

Note

+

A Turing test is any system of tests designed to differentiate a human from a computer. + It is named after famed computer scientist Alan Turing. The term was coined by researchers + at Carnegie Mellon University. + +

+
+ + + +
+
live
+
+ + + +

information captured from a real-world event and transmitted to the receiver with + no more than a broadcast delay + +

+ + +
+

Note

+

A broadcast delay is a short (usually automated) delay, for example used in order + to give the broadcaster time to cue or censor the audio (or video) feed, but not sufficient + to allow significant editing. + +

+
+ + +
+

Note

+

If information is completely computer generated, it is not live.

+
+ + + +
+
prerecorded
+
+ + + +

information that is not live + +

+ + + +
+
video
+
+ + + +

the technology of moving or sequenced pictures or images

+ + +
+

Note

+

Video can be made up of animated or photographic images, or both.

+
+ + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/meaningful-sequence.html b/wcag22/understanding/meaningful-sequence.html new file mode 100644 index 0000000..455a3b0 --- /dev/null +++ b/wcag22/understanding/meaningful-sequence.html @@ -0,0 +1,608 @@ + + + + + + Understanding Success Criterion 1.3.2: Meaningful Sequence | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.3.2:Meaningful Sequence (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
The order of content can be understood by more people.
+ +
What to do
+
Use code to preserve meaningful content order.
+ +
Why it's important
+
Assistive technology can present content to users in the proper order.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to enable a user agent to provide an alternative + presentation of content while preserving the reading order needed to understand the + meaning. It is important that it be possible to programmatically determine at least + one sequence of the content that makes sense. Content that does not meet this Success + Criterion may confuse or disorient users when assistive technology reads the content + in the wrong order, or when alternate style sheets or other formatting changes are + applied. + + +

+

A sequence is + meaningful if the order of content in the sequence cannot be changed without affecting its meaning. + + For example, if a page contains two independent articles, the relative order of the + articles may not affect their meaning, as long as they are not interleaved. In such + a situation, the articles themselves may have meaningful sequence, but the container + that contains the articles may not have a meaningful sequence. + +

+

The semantics of some elements define whether or not their content is a meaningful + sequence. For instance, in HTML, text is always a meaningful sequence. Tables and + ordered lists are meaningful sequences, but unordered lists are not. + +

+

The order of content in a sequence is not always meaningful. For example, the relative + order of the main section of a Web page and a navigation section does not affect their + meaning. They could occur in either order in the programmatically determined reading + sequence. As another example, a magazine article contains several callout sidebars. + The order of the article and the sidebars does not affect their meaning. In these + cases there are a number of different reading orders for a Web page that can satisfy + the Success Criterion. + + +

+

For clarity:

+
    + + +
  • Providing a particular linear order is only required where it affects meaning.
    • + + +
  • There may be more than one order that is "correct" (according to the WCAG 2.0 definition).
    • + + +
  • Only one correct order needs to be provided.
    • + + +
+
+
+

Benefits

+
    + + +
  • This Success Criterion may help people who rely on assistive technologies that read + content aloud. The meaning evident in the sequencing of the information in the default + presentation will be the same when the content is presented in spoken form. + + +
    • + + +
+
+
+

Examples

+
    + + +
  • + + Example 1: In a multi-column document, the linear presentation of the content flows from the + top of a column to the bottom of the column, then to the top of the next column. + +
    • + + +
  • + + Example 2: CSS is used to position a navigation bar, the main story on a page, and a side story. + The visual presentation of the sections does not match the programmatically determined + order, but the meaning of the page does not depend on the order of the sections. + +
    • + + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
correct reading sequence
+
+ + + +

any sequence where words and paragraphs are presented in an order that does not change + the meaning of the content + +

+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/media-alternative-prerecorded.html b/wcag22/understanding/media-alternative-prerecorded.html new file mode 100644 index 0000000..530d596 --- /dev/null +++ b/wcag22/understanding/media-alternative-prerecorded.html @@ -0,0 +1,1030 @@ + + + + + + Understanding Success Criterion 1.2.8: Media Alternative (Prerecorded) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.2.8:Media Alternative (Prerecorded) (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Precorded videos can be understood by more people.
+ +
What to do
+
Provide a text equivalent for all content in videos.
+ +
Why it's important
+
More people, including those who are deaf-blind, can better understand the content + at their own pace. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to make audio visual material available to + individuals whose vision is too poor to reliably read + captions and whose hearing is too poor to reliably hear dialogue and + audio description. This is done by providing an alternative for time-based media. + + +

+

This approach involves providing all of the information in the synchronized media + (both visual and auditory) in text form. An alternative for time-based media provides + a running description of all that is going on in the synchronized media content. The + alternative for time-based media reads something like a book. Unlike audio description, + the description of the video portion is not constrained to just the pauses in the + existing dialogue. Full descriptions are provided of all visual information, including + visual context, actions and expressions of actors, and any other visual material. + In addition, non-speech sounds (laughter, off-screen voices, etc.) are described, + and transcripts of all dialogue are included. The sequence of descriptions and dialogue + transcripts is the same as the sequence in the synchronized media itself. As a result, + the alternative for time-based media can provide a much more complete representation + of the synchronized media content than audio description alone. + +

+

If there is any interaction as part of the synchronized media presentation (e.g., + "press now to answer the question") then the alternative for time-based media would + provide hyperlinks or whatever is needed to provide parallel functionality. + +

+

Individuals whose vision is too poor to reliably read captions and whose hearing is + too poor to reliably hear dialogue can access the alternative for time-based media + by using a refreshable braille display. + +

+
+

Note

+
+ + +

+ For 1.2.3, 1.2.5, and 1.2.7, if all of the information in the video track is already + provided in the audio track, no audio description is necessary. + + + +

+ + +

+ 1.2.3, 1.2.5, and 1.2.8 overlap somewhat with each other. This is to give the author + some choice at the minimum conformance level, and to provide additional requirements + at higher levels. At Level A in Success Criterion 1.2.3, authors do have the choice + of providing either an audio description or a full text alternative. If they wish + to conform at Level AA, under Success Criterion 1.2.5 authors must provide an audio + description - a requirement already met if they chose that alternative for 1.2.3, + otherwise an additional requirement. At Level AAA under Success Criterion 1.2.8 they + must provide an extended text description. This is an additional requirement if both + 1.2.3 and 1.2.5 were met by providing an audio description only. If 1.2.3 was met, + however, by providing a text description, and the 1.2.5 requirement for an audio description + was met, then 1.2.8 does not add new requirements. + +

+ + +
+
+
+
+

Benefits

+
    + + +
  • People who are deaf-blind, who cannot see well or at all, and who also cannot hear + well or at all can get + access to information in audio-visual presentations. + +
    • + + +
+
+
+

Examples

+
+ +
Example 1. alternative for time-based media for a training video
+ +
A community center purchases a Training video for use by its clients and puts it on + the center's intranet. The video involves explaining use of a new technology and has + a person talking and showing things at the same time. The community center provides + an alternative for time-based media that all clients, including those who can neither + see the demonstrations nor hear the explanations in the synchronized media, can use + to better understand what is being presented. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If the content is prerecorded synchronized media:

+ + + + + +
+
+ + +

Situation B: If the content is prerecorded video-only:

+ + + + + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
alternative for time-based media
+
+ + + +

document including correctly sequenced text descriptions of time-based visual and + auditory information and providing a means for achieving the outcomes of any time-based + interaction + +

+ + +
+

Note

+

A screenplay used to create the synchronized media content would meet this definition + only if it was corrected to accurately represent the final synchronized media after + editing. + +

+
+ + + +
+
ascii art
+
+ + + +

picture created by a spatial arrangement of characters or glyphs (typically from the + 95 printable characters defined by ASCII) + +

+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
audio
+
+ + + +

the technology of sound reproduction

+ + +
+

Note

+

Audio can be created synthetically (including speech synthesis), recorded from real + world sounds, or both. + +

+
+ + + +
+
audio description
+
+ + + +

narration added to the soundtrack to describe important visual details that cannot + be understood from the main soundtrack alone + +

+ + +
+

Note

+

Audio description of video provides information about actions, characters, scene changes, on-screen text, and + other visual content. + +

+
+ + +
+

Note

+

In standard audio description, narration is added during existing pauses in dialogue. + (See also extended audio description.) + +

+
+ + +
+

Note

+

Where all of the video information is already provided in existing audio, no additional audio description is necessary. + +

+
+ + +
+

Note

+

Also called "video description" and "descriptive narration."

+
+ + + +
+
captions
+
+ + + +

synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content + +

+ + +
+

Note

+

Captions are similar to dialogue-only subtitles except captions convey not only the + content of spoken dialogue, but also equivalents for non-dialogue audio information + needed to understand the program content, including sound effects, music, laughter, + speaker identification and location. + +

+
+ + +
+

Note

+

Closed Captions are equivalents that can be turned on and off with some players.

+
+ + +
+

Note

+

Open Captions are any captions that cannot be turned off. For example, if the captions + are visual equivalent images of text embedded in video. + +

+
+ + +
+

Note

+

Captions should not obscure or obstruct relevant information in the video.

+
+ + +
+

Note

+

In some countries, captions are called subtitles.

+
+ + +
+

Note

+

+ Audio descriptions can be, but do not need to be, captioned since they are descriptions of information + that is already presented visually. + +

+
+ + + +
+
extended audio description
+
+ + + +

audio description that is added to an audiovisual presentation by pausing the video so that there is time to add additional description + +

+ + +
+

Note

+

This technique is only used when the sense of the video would be lost without the additional audio description and the pauses between dialogue/narration are too short. + +

+
+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
image of text
+
+ + + +

text that has been rendered in a non-text form (e.g., an image) in order to achieve + a particular visual effect + +

+ + +
+

Note

+

This does not include text that is part of a picture that contains significant other visual content. + +

+
+ + + + + + +
+
live
+
+ + + +

information captured from a real-world event and transmitted to the receiver with + no more than a broadcast delay + +

+ + +
+

Note

+

A broadcast delay is a short (usually automated) delay, for example used in order + to give the broadcaster time to cue or censor the audio (or video) feed, but not sufficient + to allow significant editing. + +

+
+ + +
+

Note

+

If information is completely computer generated, it is not live.

+
+ + + +
+
media alternative for text
+
+ + + +

media that presents no more information than is already presented in text (directly + or via text alternatives) + +

+ + +
+

Note

+

A media alternative for text is provided for those who benefit from alternate representations + of text. Media alternatives for text may be audio-only, video-only (including sign-language + video), or audio-video. + +

+
+ + + +
+
non-text content
+
+ + + +

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language + +

+ + +
+

Note

+

This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), + and images representing text + +

+
+ + + +
+
prerecorded
+
+ + + +

information that is not live + +

+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
synchronized media
+
+ + + +

+ audio or video synchronized with another format for presenting information and/or with time-based + interactive components, unless the media is a media alternative for text that is clearly labeled as such + +

+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
text alternative
+
+ + + +

+ Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. + Programmatically associated text is text whose location can be programmatically determined + from the non-text content. + +

+ + + + + +
+

Note

+

Refer to Understanding Text Alternatives for more information. + +

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
video
+
+ + + +

the technology of moving or sequenced pictures or images

+ + +
+

Note

+

Video can be made up of animated or photographic images, or both.

+
+ + + +
+
video-only
+
+ + + +

a time-based presentation that contains only video (no audio and no interaction) + +

+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/motion-actuation.html b/wcag22/understanding/motion-actuation.html new file mode 100644 index 0000000..37e15ab --- /dev/null +++ b/wcag22/understanding/motion-actuation.html @@ -0,0 +1,909 @@ + + + + + + Understanding Success Criterion 2.5.4: Motion Actuation | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.5.4:Motion Actuation (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Content is not dependent on a user's ability to move a device.
+ +
What to do
+
Don't rely solely on device motion to control page content.
+ +
Why it's important
+
Some people cannot hold or move a device steadily.
+ +
+
+
+

Intent

+

The intent of this success criterion is to ensure that functions triggered by moving + a device (for example, shaking or tilting) or by gesturing towards the device (so + that sensors like a camera can pick up and interpret the gesturing), can also be operated + by more conventional user interface components. +

+
+

Note

+

This criterion concerns input through sensors which respond directly to motions such + as gesturing towards, tilting or shaking a device. It does not cover the movement + of users through space as registered by geolocation sensors or beacons, or events + observed by the device other than intentional gesturing by the user. It also does + not cover incidental motion associated with operating a keyboard, pointer, or assistive + technology. +

+
+

Devices often have sensors that can act as inputs, such as accelerometer and gyroscope + sensors on a phone or tablet device. These sensors can allow the user to control something + by simply changing the orientation or moving the device in particular ways. In other + situations, web content can interpret user gestures via the camera or other sensors + to actuate functions. For example, shaking the device might issue an "Undo" command, + or a gentle hand wave might be used to move forward or backward in a sequence of pages. + Some users with disabilities are not able to operate these device sensors (either + not at all, or not precisely enough) because the device is on a fixed mount (perhaps + a wheelchair) or due to motor impairments. Therefore, functionality offered through + motion must also be available by another mechanism. +

+

In addition, some users may accidentally activate sensors due to tremors or other + motor impairments. The user must have the ability to turn off motion actuation to + prevent such accidental triggering of functions. Applications may be able to meet + this requirement by supporting operating system settings which allow the user to disable + motion detection at the system level. +

+

There is an exception where motion is essential for the function or not using motions + or gestures would invalidate the activity. Some applications are specifically created + to use device sensor data. Examples of content that are exempt from this requirement + include a pedometer that relies on device motion to count steps. +

+
+
+

Benefits

+
    + +
  • This Success Criterion helps people who may be unable to perform particular motions + (such as tilting, shaking, or gesturing) because the device may be mounted or users + may be physically unable to perform the necessary movement. This success criterion + ensures that users can still operate all functionality by other means such as touch + or via assistive technologies. +
    • + +
  • Other users will benefit in situations where they are unable to move their devices.
    • + +
+
+
+

Examples

+
    + +
  • A user can choose an application setting which turns off Shake to Undo and other motion-activated + features. +
    • + +
  • After text is input in a field, shaking a device shows a dialog offering users to + undo the input. A cancel button next to the text field offers the same functionality. +
    • + +
  • A user can tilt a device to advance to the next or a previous page. Buttons are also + provided to perform the same function. +
    • + +
  • A user can move or pan a device to change the view in an interactive photo. A control + is also available to perform these same functions. +
    • + +
  • A user can gesture towards the device to navigate content. Controls are also available + to navigate. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
accessibility supported
+
+ + + +

supported by users' assistive technologies as well as the accessibility features in browsers and other user agents + +

+ + +

To qualify as an accessibility-supported use of a Web content technology (or feature + of a technology), both 1 and 2 must be satisfied for a Web content technology (or + feature): + +

+ + +
    + + +
  1. + + +

    + The way that the Web content technology is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability + with users' assistive technology in the human language(s) of the content, + +

    + + +

    + AND + +

    + + +
    2. + + +
  2. + + +

    + The Web content technology must have accessibility-supported user agents that are + available to users. This means that at least one of the following four statements is true: + +

    + + +
      + + +
    1. + + +

      The technology is supported natively in widely-distributed user agents that are also + accessibility supported (such as HTML and CSS); + +

      + + +

      + OR + +

      + +
      2. + + +
    2. + +

      The technology is supported in a widely-distributed plug-in that is also accessibility + supported; + +

      + + +

      + OR + +

      + +
      3. + + +
    3. + +

      The content is available in a closed environment, such as a university or corporate + network, where the user agent required by the technology and used by the organization + is also accessibility supported; + +

      + + +

      + OR + +

      + +
      4. + + +
    4. + +

      The user agent(s) that support the technology are accessibility supported and are + available for download or purchase in a way that: + +

      + + +
        + + +
      • does not cost a person with a disability any more than a person without a disability + and + +
        • + + +
      • is as easy to find and obtain for a person with a disability as it is for a person + without disabilities. + +
        • + + +
      + + +
      5. + + +
    + + +
    3. + + +
+ + +
+

Note

+

The Accessibility Guidelines Working Group and the W3C do not specify which or how + much support by assistive + technologies there must be for a particular use of a Web technology in order for it + to be classified as accessibility supported. (See Level of Assistive Technology Support Needed for "Accessibility Support".) + +

+
+ + +
+

Note

+

Web technologies can be used in ways that are not accessibility supported as long + as they are not relied upon and the page as a whole meets the conformance requirements, including Conformance Requirement 4 and Conformance Requirement 5. + +

+
+ + +
+

Note

+

When a Web Technology is used in a way that is "accessibility supported," it does not imply that the entire + technology or all uses of the technology are supported. Most technologies, including + HTML, lack support for at least one feature or use. Pages conform to WCAG only if + the uses of the technology that are accessibility supported can be relied upon to + meet WCAG requirements. + +

+
+ + +
+

Note

+

When citing Web content technologies that have multiple versions, the version(s) supported + should be specified. + +

+
+ + +
+

Note

+

One way for authors to locate uses of a technology that are accessibility supported + would be to consult compilations of uses that are documented to be accessibility supported. + (See Understanding Accessibility-Supported Web Technology Uses.) Authors, companies, technology vendors, or others may document accessibility-supported + ways of using Web content technologies. However, all ways of using technologies in + the documentation would need to meet the definition of accessibility-supported Web + content technologies above. + +

+
+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
functionality
+
+ + + +

+ processes and outcomes achievable through user action + +

+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/multiple-ways.html b/wcag22/understanding/multiple-ways.html new file mode 100644 index 0000000..080cd6e --- /dev/null +++ b/wcag22/understanding/multiple-ways.html @@ -0,0 +1,645 @@ + + + + + + Understanding Success Criterion 2.4.5: Multiple Ways | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.5:Multiple Ways (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can get to content in multiple ways.
+ +
What to do
+
Provide at least two options for reaching the same content.
+ +
Why it's important
+
Not everyone can navigate content in the same way.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to make it possible for users to locate content + in a manner that best meets their needs. Users may find one technique easier or more + comprehensible to use than another. + +

+

Even small sites should provide users some means of orientation. For a three or four + page site, with all pages linked from the home page, it may be sufficient simply to + provide links from and to the home page where the links on the home page can also + serve as a site map. + +

+
+
+

Benefits

+
    + + +
  • Providing an opportunity to navigate sites in more than one manner can help people + find information faster. Users with visual impairments may find it easier to navigate + to the correct part of the site by using a search, rather than scrolling through a + large navigation bar using a screen magnifier or screen reader. A person with cognitive + disabilities may prefer a table of contents or site map that provides an overview + of the site rather than reading and traversing through several Web pages. Some users + may prefer to explore the site in a sequential manner, moving from Web page to Web + page in order to best understand the concepts and layout. + +
    • + + +
  • Individuals with cognitive limitations may find it easier to use search features than + to use a hierarchical navigation scheme that may be difficult to understand. + +
    • + + +
+
+
+

Examples

+
+ +
A search mechanism
+ +
A large food processing company provides a site containing recipes created using its + products. The site provides a search mechanism to search for recipes using a particular + ingredient. In addition, it provides a list box that lists several categories of foods. + A user may type "soup" in to the search engine or may select "soup" from the list + box to go to a page with a list of recipes made from the company's soup products. +
+ +
Links between Web pages
+ +
A local hair salon has created a Web site to promote its services. The site contains + only five Web pages. There are links on each Web page to sequentially move forward + or backward through the Web pages. In addition, each Web page contains a list of links + to reach each of the other Web pages. +
+ +
Where content is a result of a process or task - Funds transfer confirmation
+ +
An on-line banking site allows fund transfer between accounts via the Web. There is + no other way to locate the confirmation of fund transfer until the account owner completes + the transfer. +
+ +
Where content is a result of a process or task - Search engine results
+ +
A search engine provides the search results based on user input. There is no other + way to locate the search results except to perform the search process itself. +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
set of web pages
+
+ + + +

collection of web pages that share a common purpose and that are created by the same author, group or organization + +

+ + + + + +
+

Note

+

Different language versions would be considered different sets of Web pages.

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/name-role-value.html b/wcag22/understanding/name-role-value.html new file mode 100644 index 0000000..d6d926c --- /dev/null +++ b/wcag22/understanding/name-role-value.html @@ -0,0 +1,1198 @@ + + + + + + Understanding Success Criterion 4.1.2: Name, Role, Value | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 4.1.2:Name, Role, Value (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
People using assistive technology understand all components.
+ +
What to do
+
Give components correct names, roles, states, and values.
+ +
Why it's important
+
Assistive technology only works well when code is done properly.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that Assistive Technologies (AT) + can gather appropriate information about, activate (or set) and keep up to date on + the status of + user interface controls in the content. + +

+

When standard controls from accessible technologies are used, this process is straightforward. + If the user interface elements are used according to specification the conditions + of this provision will be met. (See examples of Success Criterion 4.1.2 below) + +

+

If custom controls are created, however, or interface elements are programmed (in + code or script) to have a different role and/or function than usual, then additional + measures need to be taken to ensure that the controls provide important and appropriate + information + to assistive technologies and allow themselves to be controlled by assistive technologies. + +

+

What roles and states are appropriate to convey to assistive technology will depend + on what the control represents. Specifics about such information are defined by other + specifications, such as WAI-ARIA, or the + relevant platform standards. Another factor to consider is whether there is sufficient + accessibility support + with assistive technologies to convey the information as specified. + +

+

A particularly important state of a user interface control is whether or not it has + focus. The focus state of a control can be programmatically determined, and notifications + about change of focus are sent to user agents and assistive technology. Other examples + of user interface control state are whether or not a checkbox or radio button has + been selected, or whether or not a collapsible tree or list node is expanded or collapsed. + +

+
+

Note

+
+ + +

Success Criterion 4.1.2 requires a programmatically determinable name for all user + interface components. Names may be visible or invisible. Occasionally, the name needs + to be visible, in which case it is identified as a label. Refer to the definition + of + name and label in the glossary for more information. + +

+ + +
+
+
+
+

Benefits

+
    + + +
  • Providing role, state, and value information on all user interface components enables + compatibility with assistive technology, such as screen readers, screen magnifiers, + and speech recognition software, used by people with disabilities. + +
    • + + +
+
+
+

Examples

+
+ +
Accessible APIs
+ +
A Java applet uses the accessibility API defined by the language.
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If using a standard user interface component in a markup language (e.g., + HTML): + +

+ + + + + +
+
+ + +

Situation B: If using script or code to re-purpose a standard user interface component + in a markup language: + +

+ + + + + +
+
+ + +

Situation C: If using a standard user interface component in a programming technology:

+ + + + + +
+
+ + +

Situation D: If creating your own user interface component in a programming language:

+ + + + + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
ascii art
+
+ + + +

picture created by a spatial arrangement of characters or glyphs (typically from the + 95 printable characters defined by ASCII) + +

+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
label
+
+ + + +

+ text or other component with a text alternative that is presented to a user to identify a component within Web content + +

+ + +
+

Note

+

A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases + the name and the label are the same. + +

+
+ + +
+

Note

+

The term label is not limited to the label element in HTML.

+
+ + + +
+
name
+
+ + + +

text by which software can identify a component within Web content to the user

+ + +
+

Note

+

The name may be hidden and only exposed by assistive technology, whereas a label is presented to all users. In many (but not all) cases, the label and the name are + the same. + +

+
+ + +
+

Note

+

This is unrelated to the name attribute in HTML.

+
+ + + +
+
non-text content
+
+ + + +

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language + +

+ + +
+

Note

+

This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), + and images representing text + +

+
+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
programmatically set
+
+ + + +

set by software using methods that are supported by user agents, including assistive + technologies + +

+ + + +
+
role
+
+ + + +

text or number by which software can identify the function of a component within Web + content + +

+ + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
text alternative
+
+ + + +

+ Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. + Programmatically associated text is text whose location can be programmatically determined + from the non-text content. + +

+ + + + + +
+

Note

+

Refer to Understanding Text Alternatives for more information. + +

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/navigable.html b/wcag22/understanding/navigable.html new file mode 100644 index 0000000..13e06a1 --- /dev/null +++ b/wcag22/understanding/navigable.html @@ -0,0 +1,229 @@ + + + + + + Understanding Guideline 2.4: Navigable | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 2.4:Navigable +

+ +
+
+

Intent

+

The intent of this guideline is to help users find the content they need and allow + them to keep track of their location. These tasks are often more difficult for people + with disabilities. For finding, navigation, and orientation, it is important that + the user can find out what the current location is. For navigation, information about + the possible destinations needs to be available. Screen readers convert content to + synthetic speech which, because it is audio, must be presented in linear order. + Some Success Criteria in this guideline explain what provisions need to be taken to + ensure that screen reader users can successfully navigate the content. Others allow + users to more easily recognize navigation bars and page headers and to bypass this + repeated content. Unusual user interface features or behaviors may confuse people + with cognitive disabilities. + + + +

+

Navigation has two main functions:

+
    + + +
  • to tell the user where they are
    • + + +
  • to enable the user to go somewhere else
    • + + +
+

This guideline works closely with + Guideline 1.3, which ensures that any structure in the content can be perceived, a key to navigation + as well. Headings are particularly important mechanisms for helping users orient themselves + within content and navigate through it. Many users of assistive technologies rely + on appropriate headings to skim through information and easily locate the different + sections of content. Satisfying + Success Criterion 1.3.1 + + for headings also addresses some aspects of Guideline 2.4. + +

+
+
+

Success Criteria for this Guideline

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/no-keyboard-trap.html b/wcag22/understanding/no-keyboard-trap.html new file mode 100644 index 0000000..1931bf2 --- /dev/null +++ b/wcag22/understanding/no-keyboard-trap.html @@ -0,0 +1,368 @@ + + + + + + Understanding Success Criterion 2.1.2: No Keyboard Trap | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.1.2:No Keyboard Trap (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Keyboard users don't get stuck.
+ +
What to do
+
Ensure users always know how to navigate away from components.
+ +
Why it's important
+
People who rely on the keyboard often have no other means to navigate.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that that content does not "trap" + keyboard focus within subsections of content on a Web page. This is a common problem + when multiple formats are combined within a page and rendered using plug-ins or embedded + applications. + +

+

There may be times when the functionality of the Web page restricts the focus to a + subsection of the content, as long as the user knows how to leave that state and "untrap" + the focus. + +

+
+
+

Benefits

+
    + + +
  • People who rely on a keyboard or keyboard interface to use the Web including people + who are blind and people with physical disabilities. + +
    • + + +
+
+
+

Examples

+
+ +
A calendar widget
+ +
A calendar widget allows users to add, remove or update items in their calendar using + the keyboard. The controls in the widget are part of the tab order within the Web + page, allowing users to tab through the controls in the widget as well as to any links + or controls that follow. +
+ +
A puzzle applet
+ +
Once a user tabs into an applet, further tabs and other keystrokes are handled by + the applet. Instructions describing the keystroke used to exit the applet are provided + prior to the applet as well as within the applet itself. +
+ +
A modal dialog box
+ +
A Web application brings up a dialog box. At the bottom of the dialog are two buttons, + Cancel and OK. When the dialog has been opened, focus is trapped within the dialog; + tabbing from the last control in the dialog takes focus to the first control in the + dialog. The dialog is dismissed by activating the Cancel button or the OK button. +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
keyboard interface
+
+ + + +

interface used by software to obtain keystroke input

+ + +
+

Note

+
+ +

A keyboard interface allows users to provide keystroke input to programs even if the + native technology does not contain a keyboard. +

+ + + + +
+
+ + +
+

Note

+

Operation of the application (or parts of the application) through a keyboard-operated + mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard + interface because operation of the program is through its pointing device interface, + not through its keyboard interface. + +

+
+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/no-timing.html b/wcag22/understanding/no-timing.html new file mode 100644 index 0000000..f952fcf --- /dev/null +++ b/wcag22/understanding/no-timing.html @@ -0,0 +1,415 @@ + + + + + + Understanding Success Criterion 2.2.3: No Timing | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.2.3:No Timing (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users do not face time limits.
+ +
What to do
+
Do not use time limits, except for video and live events.
+ +
Why it's important
+
People with disabilities often need more time to complete actions.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to minimize the occurrence of content that + requires timed interaction. This enables people with blindness, low vision, cognitive + limitations, or motor impairments to interact with content. This differs from the + Level A Success Criterion in that the only exception is for real-time events. + +

+
+

Note

+
+ + +

Video only, such as sign language, is covered in + Guideline 1.1. + + +

+ + +
+
+
+
+

Benefits

+
    + + +
  • People with physical disabilities often need more time to react, to type and to complete + activities. People with low vision need more time to locate things on screen and + to read. People who are blind and using screen readers may need more time to understand + screen layouts, to find information and to operate controls. People who have cognitive + or language limitations need more time to read and to understand. People who are + deaf and communicate in sign language may need more time to read information printed + in text (which may be a second language for some). + +
    • + + +
  • In circumstances where a sign-language interpreter may be relating audio content to + a user who is deaf, control over time limits is also important. + +
    • + + +
+
+
+

Examples

+
+ +
A test is designed so that time to complete the test does not affect the scoring
+ +
Rather than calibrating an on-line test using a time limit, the test is calibrated + based on scores when users have no time limits. +
+ +
A game is designed so that users take turns rather than competing in real-time
+ +
One party can pause the game without invalidating the competitive aspect of it.
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+
+
+ +

Key Terms

+ +
audio
+
+ + + +

the technology of sound reproduction

+ + +
+

Note

+

Audio can be created synthetically (including speech synthesis), recorded from real + world sounds, or both. + +

+
+ + + +
+
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
media alternative for text
+
+ + + +

media that presents no more information than is already presented in text (directly + or via text alternatives) + +

+ + +
+

Note

+

A media alternative for text is provided for those who benefit from alternate representations + of text. Media alternatives for text may be audio-only, video-only (including sign-language + video), or audio-video. + +

+
+ + + +
+
real-time event
+
+ + + +

event that a) occurs at the same time as the viewing and b) is not completely generated + by the content + +

+ + + + + + + + + + + + +
+
synchronized media
+
+ + + +

+ audio or video synchronized with another format for presenting information and/or with time-based + interactive components, unless the media is a media alternative for text that is clearly labeled as such + +

+ + + +
+
video
+
+ + + +

the technology of moving or sequenced pictures or images

+ + +
+

Note

+

Video can be made up of animated or photographic images, or both.

+
+ + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/non-text-content.html b/wcag22/understanding/non-text-content.html new file mode 100644 index 0000000..f235600 --- /dev/null +++ b/wcag22/understanding/non-text-content.html @@ -0,0 +1,1987 @@ + + + + + + Understanding Success Criterion 1.1.1: Non-text Content | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.1.1:Non-text Content (Level A) +

+ +
+
+

In Brief

+
+ + +
Goal
+
Non-text information is available to more people.
+ +
What to do
+
Create a text alternative for visual and auditory content.
+ +
Why it's important
+
People who can’t fully see or hear content can understand it.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to make information conveyed by non-text content + accessible through the use of a text alternative. Text alternatives are a primary + way for making information accessible because they can be rendered through any sensory + modality (for example, visual, auditory or tactile) to match the needs of the user. + Providing text alternatives allows the information to be rendered in a variety of + ways by a variety of user agents. For example, a person who cannot see a picture can + have the text alternative read aloud using synthesized speech. A person who cannot + hear an audio file can have the text alternative displayed so that he or she can read + it. In the future, text alternatives will also allow information to be more easily + translated into sign language or into a simpler form of the same language. + +

+
+ + +

+ Note on CAPTCHA + + +

+ + +

+ CAPTCHAs are a controversial topic in the accessibility community. As is described + in the + paper + Inaccessibility of CAPTCHA, CAPTCHAs intrinsically push the edges of human abilities in an attempt to defeat + automated processes. Every type of CAPTCHA will be unsolvable by users with certain + disabilities. However, they are widely used, and the Web Content Accessibility Guidelines + Working Group believes that if CAPTCHAs were forbidden outright, Web sites would choose + not to conform to WCAG rather than abandon CAPTCHA. This would create barriers for + a great many more users with disabilities. For this reason the Working Group has chosen + to structure the requirement about CAPTCHA in a way that meets the needs of most people + with disabilities, yet is also considered adoptable by sites. Requiring two different + forms of CAPTCHA on a given site ensures that most people with disabilities will find + a form they can use. + +

+ + +

Because some users with disabilities will still not be able to access sites that meet + the minimum requirements, the Working Group provides recommendations for additional + steps. Organizations motivated to conform to WCAG should be aware of the importance + of this topic and should go as far beyond the minimum requirements of the guidelines + as possible. Additional recommended steps include: + +

+ + +
    + + +
  • Providing more than two modalities of CAPTCHAs
    • + + +
  • Providing access to a human customer service representative who can bypass CAPTCHA
    • + + +
  • Not requiring CAPTCHAs for authorized users
    • + + +
+ + +
+
+ + +

Additional information

+ + +

Non-text content can take a number of forms, and this Success Criterion specifies + how each is to be handled. + +

+ + +

+ + + For non-text content that is not covered by one of the other situations listed below, + + such as charts, diagrams, audio recordings, pictures, and animations, text alternatives + can make the same information available in a form that can be rendered through any + modality (for example, visual, auditory or tactile). Short and long text alternatives + can be used as needed to convey the information in the non-text content. Note that + + + prerecorded + audio-only + and + + prerecorded + video-only + files are covered here. + + Live-audio-only + and + + Live-video-only + files are covered below (see 3rd paragraph following this one). + +

+ + +

+ + + For non-text content that is a control or accepts user input + , such as images used as submit buttons, image maps or complex animations, a name + is provided to describe the purpose of the non-text content so that the person at + least knows what the non-text content is and why it is there. + +

+ + +

+ + + Non-text content that is time-based media + + is made accessible through + 1.2: Time-Based Media. However, it is important that users know what it is when they encounter it on a + page so they can decide what action if any they want to take with it. A text alternative + that describes the time-based media and/or gives its title is therefore provided. + + +

+ + +

+ + + For Live Audio-only and live video-only content + , it can be much more difficult to provide text alternatives that provide equivalent + information as live audio-only and live video-only content. For these types of non-text + content, text alternatives provide a descriptive label. + + +

+ + +

+ + + Sometimes a test or exercise must be partially or completely presented in non-text + format. + Audio or visual information is provided that cannot be changed to text because the + test or exercise must be conducted using that sense. For example, a hearing test + would be invalid if a text alternative were provided. A visual skill development + exercise would similarly make no sense in text form. And a spelling test with text + alternatives would not be very effective. For these cases, text alternatives should + be provided to describe the purpose of the non-text content; of course, the text alternatives + would not provide the same information needed to pass the test. + +

+ + +

+ + + Sometimes content is primarily intended to create a specific sensory experience + that words cannot fully capture. Examples include a symphony performance, works of + visual art etc. For such content, text alternatives at least identify the non-text + content with a descriptive label and where possible, additional descriptive text. + If the reason for including the content in the page is known and can be described + it is helpful to include that information. + +

+ + +

+ + Sometimes there are non-text exercises that are used to prove you are human. To avoid spam robots and other software from gaining access to a site a device called + a CAPTCHA is used. These usually involve visual or auditory tasks that are beyond + the current capabilities of Web robots. Providing a text alternative to them would + however make them operable by Robots, thus defeating their purpose. In this case a + text alternative would describe the purpose of the CAPTCHA, and alternate forms using + different modalities would be provided to address the needs of people with different + disabilities. + +

+ + +

+ + + Sometimes there is non-text content that really is not meant to be seen or understood + by the user. + Transparent images used to move text over on a page; an invisible image that is used + to track usage statistics; and a swirl in the corner that conveys no information but + just fills up a blank space to create an aesthetic effect are all examples of this. + Putting alternative text on such items just distracts people using screen readers + from the content on the page. Not marking the content in any way, though, leaves users + guessing what the non-text content is and what information they may have missed (even + though they have not missed anything in reality). This type of non-text content, therefore, + is marked or implemented in a way that assistive technologies (AT) will ignore it + and not present anything to the user. + +

+ + +
+
+
+

Benefits

+
    + + +
  • This Success Criterion helps people who have difficulty perceiving visual content. + Assistive technology can read text aloud, present it visually, or convert it to braille. + +
    • + + +
  • Text alternatives may help some people who have difficulty understanding the meaning + of photographs, drawings, and other images (e.g., line drawings, graphic designs, + paintings, three-dimensional representations), graphs, charts, animations, etc. + + +
    • + + +
  • + People who are deaf, are hard of hearing, or who are having trouble understanding + audio information for any reason can read the text presentation. Research is ongoing + regarding automatic translation of text into sign language. + + +
    • + + +
  • + People who are deaf-blind can read the text in braille. + + +
    • + + +
  • + Additionally, text alternatives support the ability to search for non-text content + and to repurpose content in a variety of ways. + + +
    • + + +
+
+
+

Examples

+
+ +
A data chart
+ +
A bar chart compares how many widgets were sold in June, July, and August. The short + label says, "Figure one - Sales in June, July and August." The longer description + identifies the type of chart, provides a high-level summary of the data, trends and + implications comparable to those available from the chart. Where possible and practical, + the actual data is provided in a table. +
+ +
An audio recording of a speech
+ +
The link to an audio clip says, "Chairman's speech to the assembly." A link to a text + transcript is provided immediately after the link to the audio clip. +
+ +
An animation that illustrates how a car engine works
+ +
An animation shows how a car engine works. There is no audio and the animation is + part of a tutorial that describes how an engine works. Since the text of the tutorial + already provides a full explanation, the image is an alternative for text and the + text alternative includes only a brief description of the animation and refers to + the tutorial text for more information. +
+ +
A traffic Web camera
+ +
A Web site allows users to select from a variety of Web cameras positioned throughout + a major city. After a camera is selected, the image updates every two minutes. A short + text alternative identifies the Web camera as "traffic Web camera." The site also + provides a table of travel times for each of the routes covered by the Web cameras. + The table is also updated every two minutes. +
+ +
A photograph of an historic event in a news story
+ +
A photograph of two world leaders shaking hands accompanies a news story about an + international summit meeting. The text alternative says, "President X of Country X + shakes hands with Prime Minister Y of country Y." +
+ +
A photograph of a historic event in content discussing diplomatic relationships
+ +
The same image is used in a different context intended to explain nuances in diplomatic + encounters. The image of the president shaking hands with the prime minister appears + on a Web site discussing intricate diplomatic relationships. The first text alternative + reads, "President X of country X shakes hands with Prime Minister Y of country Y on + January 2, 2009." An additional text alternative describes the room where the leaders + are standing as well as the expressions on the leaders' faces, and identifies the + other people in the room. The additional description might be included on the same + page as the photograph or in a separate file associated with the image through a link + or other standard programmatic mechanism. +
+ +
An audio recording of a press conference
+ +
A Web page includes a link to an audio recording of a press conference. The link text + identifies the audio recording. The page also links to a text transcript of the press + conference. The transcript includes a verbatim record of everything the speakers say. + It identifies who is speaking as well as noting other significant sounds that are + part of the recording, such as applause, laughter, questions from the audience, and + so on. +
+ +
An e-learning application
+ +
An e-learning application uses sound effects to indicate whether or not the answers + are correct. The chime sound indicates that the answer is correct and the beep sound + indicates that the answer is incorrect. A text description is also included so that + people who can't hear or understand the sound understand whether the answer is correct + or incorrect. +
+ +
A linked thumbnail image
+ +
A thumbnail image of the front page of a newspaper links to the home page of the "Smallville + Times". The text alternative says "Smallville Times". +
+ +
The same image used on different sites
+ +
Different alternatives for an image of the world: An image of the world that is used + on a travel site as a link to the International Travel section has the text alternative + "International Travel". The same image is used as a link on a university Web site + with the text alternative "International Campuses". +
+ +
An image map
+ +
An image of a building floor plan is interactive, allowing the user to select a + particular room and navigate to a page containing information about that room. + The short text alternative describes the image and its interactive purpose: + "Building floor plan. Select a room for more information." +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If a short description can serve the same purpose and present the same + information as the non-text content: + +

+ + + + + +

+ + Short text alternative techniques for Situation A: + +

+ + + + + +
+
+ + +

Situation B: If a short description can + not serve the same purpose and present the same information as the non-text content (e.g., + a chart or diagram): + +

+ + + + + +

+ + Short text alternative techniques for Situation B: + +

+ + + + + +

+ + Long text alternative techniques for Situation B: + +

+ + + + + +
+
+ + +

Situation C: If non-text content is a control or accepts user input:

+ + + + + +

+ + Text alternative techniques for controls and input for Situation C: + +

+ + + + + +
+
+ + +

Situation D: If non-text content is time-based media (including live video-only and + live audio-only); a test or exercise that would be invalid if presented in text; or + primarily intended to create a specific sensory experience: + +

+ + + + + +

+ + Short text alternative techniques for Situation D: + +

+ + + + + +
+
+ + +

Situation E: If non-text content is a CAPTCHA:

+ + + + + +
+
+ + +

Situation F: If the non-text content should be ignored by assistive technology:

+ + + + + +

+ + Techniques to indicate that text alternatives are not required for Situation F: + +

+ + + + + +
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+
+ + +

CSS Techniques (Advisory)

+ + + + + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
ascii art
+
+ + + +

picture created by a spatial arrangement of characters or glyphs (typically from the + 95 printable characters defined by ASCII) + +

+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
captcha
+
+ + + +

initialism for "Completely Automated Public Turing test to tell Computers and Humans + Apart" + +

+ + +
+

Note

+

CAPTCHA tests often involve asking the user to type in text that is displayed in an + obscured image or audio file. + +

+
+ + +
+

Note

+

A Turing test is any system of tests designed to differentiate a human from a computer. + It is named after famed computer scientist Alan Turing. The term was coined by researchers + at Carnegie Mellon University. + +

+
+ + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
label
+
+ + + +

+ text or other component with a text alternative that is presented to a user to identify a component within Web content + +

+ + +
+

Note

+

A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases + the name and the label are the same. + +

+
+ + +
+

Note

+

The term label is not limited to the label element in HTML.

+
+ + + +
+
name
+
+ + + +

text by which software can identify a component within Web content to the user

+ + +
+

Note

+

The name may be hidden and only exposed by assistive technology, whereas a label is presented to all users. In many (but not all) cases, the label and the name are + the same. + +

+
+ + +
+

Note

+

This is unrelated to the name attribute in HTML.

+
+ + + +
+
non-text content
+
+ + + +

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language + +

+ + +
+

Note

+

This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), + and images representing text + +

+
+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
pure decoration
+
+ + + +

serving only an aesthetic purpose, providing no information, and having no functionality

+ + +
+

Note

+

Text is only purely decorative if the words can be rearranged or substituted without + changing their purpose. + +

+
+ + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
specific sensory experience
+
+ + + +

a sensory experience that is not purely decorative and does not primarily convey important + information or perform a function + +

+ + + + + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
text alternative
+
+ + + +

+ Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. + Programmatically associated text is text whose location can be programmatically determined + from the non-text content. + +

+ + + + + +
+

Note

+

Refer to Understanding Text Alternatives for more information. + +

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/non-text-contrast.html b/wcag22/understanding/non-text-contrast.html new file mode 100644 index 0000000..6d47927 --- /dev/null +++ b/wcag22/understanding/non-text-contrast.html @@ -0,0 +1,2105 @@ + + + + + + Understanding Success Criterion 1.4.11: Non-text Contrast | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.11:Non-text Contrast (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Important visual information meets the same minimum contrast required for larger text.
+ +
What to do
+
Ensure meaningful visual cues achieve 3:1 against the background.
+ +
Why it's important
+
Some people cannot see elements with low contrast.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that user interface components (i.e., + controls) and meaningful graphics are distinguishable by people with moderately low + vision. The requirements and rationale are similar to those for large text in 1.4.3 Contrast (Minimum). Note that this requirement does not apply to inactive user interface components. +

+

Low contrast controls are more difficult to perceive, and may be completely missed + by people with a visual impairment. Similarly, if a graphic is needed to understand + the content or functionality of the webpage then it should be perceivable by people + with low vision or other impairments without the need for contrast-enhancing assistive + technology. +

+
+

Note

+
+ +

The 3:1 contrast ratios referenced in this Success Criterion is intended to be treated + as threshold values. When comparing the computed contrast ratio to the Success Criterion + ratio, the computed values should not be rounded (e.g. 2.999:1 would not meet the + 3:1 threshold). +

+ +
+
+
+

Note

+
+ +

Because authors do not have control over user settings for font smoothing and anti-aliasing, + when evaluating this + Success Criterion, refer to the colors obtained from the user agent, or the + underlying + markup and stylesheets, rather than the non-text elements as presented on screen. +

+ +

Due to anti-aliasing, particularly thin lines and shapes of non-text elements may + be rendered by user agents with + a much fainter color than the actual color defined in the underlying CSS. This + can lead to situations where + non-text elements have a contrast ratio that nominally passes the Success Criterion, + but have a much lower contrast + in practice. In these cases, best practice would be for authors to avoid particularly + thin lines and shapes, + or to use a combination of colors that exceeds the normative requirements of + this Success Criterion. + +

+ +
+
+
+ +

User Interface Components

+ + +

Unless the control is inactive, any visual information provided that is necessary for a user to identify that a + control is present and how to operate it must have a minimum 3:1 contrast ratio with + the adjacent colors. Also, any visual information necessary to indicate state, such + as whether a component is selected or focused must also ensure that the information + used to identify the control in that state has a minimum 3:1 contrast ratio. +

+ + +

This Success Criterion does not require that changes in color that differentiate between + states of an individual component meet the 3:1 contrast ratio when they do not appear + next to each other. For example, there is not a new requirement that visited links + contrast with the default color, or that mouse hover indicators contrast with the + default state. However, the component must not lose contrast with the adjacent colors, + and non-text indicators such as the check in a checkbox, or an arrow graphic indicating + a menu is selected or open must have sufficient contrast to the adjacent colors. +

+ + +

Boundaries

+ + +

This success criterion does not require that controls have a visual boundary indicating + the hit area, but if the visual indicator of the control is the only way to identify + the control, then that indicator must have sufficient contrast. If text (or an icon) + within a button or placeholder text inside a text input is visible and there is no + visual indication of the hit area then the Success Criterion is passed. If a button + with text also has a colored border, since the border does not provide the only indication + there is no contrast requirement beyond the text contrast (1.4.3 Contrast (Minimum)). Note that for people with cognitive disabilities it is recommended to delineate + the boundary of controls to aid in the recognition of controls and therefore the completion + of activities. +

+ + +
+ Two buttons, the first with no visual indicator except text saying 'button'. The second is the same but with an added grey border. + +
Figure 1 A button without a visual boundary, and the same button with a focus indicator that + is a defined visual boundary of grey (#949494) adjacent to white. +
+ +
+ + +

Adjacent colors

+ +

For user interface components 'adjacent colors' means the colors adjacent to the component. + For example, if an input has a white internal background, dark border, and white external + background the 'adjacent color' to the component would be the white external background. +

+ +
+ Standard text input with a label, white internal and external background with a dark border. + +
Figure 2 A standard text input with a grey border (#767676) and white adjacent color outside + the component +
+ +
+ + +

If components use several colors, any color which does not interfere with identifying + the component can be ignored for the purpose of measuring contrast ratio. For example, + a 3D drop-shadow on an input, or a dark border line between contrasting backgrounds + is considered to be subsumed into the color closest in brightness (perceived luminance). +

+ + +

The following example shows an input that has a light background on the inside and + a dark background around it. The input also has a dark grey border which is considered + to be subsumed into the dark background. The border does not interfere with identifying + the component, so the contrast ratio is taken between the white background and dark + blue background. +

+ + +
+ A text box with a dark background and light border, with a white background. + +
Figure 3 The contrast of the input background (white) and color adjacent to the control (dark + blue #003366) is sufficient. There is also a border (silver) on the component that + is not required to contrast with either. +
+ +
+ + +

For visual information required to identify a state, such as the check in a checkbox + or the thumb of a slider, that part might be within the component so the adjacent + color might be another part of the component. +

+ + +
+ A purple box with a light grey check. + +
Figure 4 A customized checkbox with light grey check (#E5E5E5), which has a contrast ratio + of 5.6:1 with the purple box (#6221EA). +
+ +
+ + +

It is possible to use a flat design where the status indicator fills the component + and does not contrast with the component, but does contrast with the colors adjacent + to the component. +

+ + + +
+ Four radio buttons, the first is a plain circle labelled 'Not selected'. The second shows the circle filled with a darker color than the border. The third is filled with the same color as the border. The fourth has an inner filled circle with a gap between it and the outer border. + +
Figure 5 The first radio button shows the default state with a grey (#949494) circle. The second + and third show the radio button selected and filled with a color that contrasts with + the color adjacent to the component. The last example shows the state indicator contrasting + with the component colors. +
+ +
+ + +

Relationship with Use of Color

+ + +

The Use of Color success criterion addresses changing only the color (hue) of an object or text without otherwise altering the object's form. The principle + is that contrast ratio (the difference in brightness) can be used to distinguish text + or graphics. For example, G183: Using a contrast ratio of 3:1 with surrounding text and providing additional visual + cues on hover for links or controls where color alone is used to identify them is a technique to use a contrast ratio of 3:1 with surrounding text to distinguish + links and controls. In that case the Working Group regards a link color that meets + the 3:1 contrast ratio relative to the non-linked text color as satisfying the Success + Criterion 1.4.1 Use of color since it is relying on contrast ratio as well as color (hue) to convey that the text + is a link. +

+ + +

Non-text information within controls that uses a change of hue alone to convey the + value or state of an input, such as a 1-5 star indicator with a black outline for + each star filled with either yellow (full) or white (empty) is likely to fail the + Use of color criterion rather than this one. +

+ + +
+ Two star ratings, one uses a black outline (on white) with a black fill to indicate it is checked. The second has a yellow fill and a thicker dark border. + +
Figure 6 + Two examples which pass this success criterion, using either a solid fill to + indicate a checked-state that has contrast, or a thicker border as well as yellow + fill. + +
+ +
+ +
+ Two star ratings, the first uses 5 stars with a black outline and a yellow or white fill, where yellow indicates checked. The second uses only pale yellow stars on white. + +
Figure 7 + Two examples which fail a success criterion, the first fails the Use of color + criterion due to relying on yellow and white hues. The second example fails the Non-text + contrast criterion due to the yellow (#FFF000) to white contrast ratio of 1.2:1. + +
+ +
+ + +

Using a change of contrast for focus and other states is a technique to differentiate + the states. This is the basis for G195: Using an author-supplied, visible focus indicator, and more techniques are being added. +

+ + + +

Relationship with Focus Visible

+ + +

In combination with 2.4.7 Focus Visible, the visual focus indicator for a component must have sufficient contrast against the adjacent background when the component is focused, + except where the appearance of the component is determined by the user agent and not + modified by the author. +

+ + +

Most focus indicators appear outside the component - in that case it needs to contrast + with the background that the component is on. Other cases include focus indicators + which are: +

+ + +
    + +
  • only inside the component and need to contrast with the adjacent color(s) within the + component. +
    • + +
  • the border of the component (inside the component and adjacent to the outside) and + need to contrast with both adjacent colours. +
    • + +
  • partly inside and partly outside, where either part of the focus indicator can contrast + with the adjacent colors. +
    • + +
+ + +
+ Three blue buttons, the middle has a thick yellow outline well inside the border of the button. + +
Figure 8 + The internal yellow indicator (#FFFF00) contrasts with the blue button background + (#4189B9), passing the criterion. + +
+ +
+ + + +
+ Three blue buttons on a white background, the middle has a light yellow outline outside of the botton's non-focused boundary. + +
Figure 9 + The external yellow indicator (#FFFF00) does not contrast with the white background + (#FFF) which the component is on, failing the criterion. + +
+ +
+ + +
+ Three blue buttons on a white background, the middle has a dark green outline outside of the botton's non-focused boundary. + +
Figure 10 + The external green indicator (#008000) does contrast with the white background + (#FFF) which the component is on, passing the criterion. It does not need to contrast with both the component background and + the component. + +
+ +
+ +

Although the figure above with a dark outline passes non-text contrast, it is not + a good indicator unless it is very thick. New in WCAG 22: There is a criterion in WCAG 2.2 that addresses this aspect, Focus Appearance.

+ +

If an indicator is partly inside and partly outside the component, either part of + the indicator could provide contrast. +

+ + +
+ Three blue buttons on a white background, the middle has the outline of a yellow rectangle that is partly inside the button's boundary, and partly outside on the white background. + +
Figure 11 + The focus indicator is partially inside, partially outside the button. The internal + part of the yellow indicator (#FFFF00) contrasts with the blue button background (#4189B9), + passing the criterion. + +
+ +
+ + +

If the focus indicator changes the border of the component within the visible boundary + it must contrast with the component. Typically an outline goes around (outside) the + visible boundary of the component, in this case changing the border is just inside + the visible edge of the component. +

+ + +
+ Three blue buttons on a white background, the center button has a green border exactly on the outer boundary of the button. + +
Figure 12 + The border of the control changes from blue (#4189B9) to green (#4B933A). This + is within the component and does not contrast with the inside background of the component + therefore fails non-text contrast. + +
+ +
+ + +
+ Three blue buttons with a black border on a white background, the center button has a green border inside, adjacent to the inner background and black border. + +
Figure 13 + An inner border of dark green (#008000) does contrast with the black border, + but does not contrast with the blue component background, therefore fails non-text contrast. + +
+ +
+ + +
+ Three blue buttons with a black border on a white background, the center button has a white border inside, adjacent to the inner background and black border. + +
Figure 14 + An inner border of white contrasts with the black border and the blue component + background, therefore passes non-text contrast. + +
+ +
+ + +

Note that this Success Criterion does not directly compare the focused and unfocused + states of a control - if the focus state relies on a change of color (e.g., changing + only the background color of a button), this Success Criterion does not define any requirement + for the difference in contrast between the two states. +

+ + +
+ Three blue buttons, the center button is a lighter blue than the others. + +
Figure 15 + The change of background within the component is not in scope of non-text contrast. + However, this would not pass Use of color. + +
+ +
+ + +
+ +

User Interface Component Examples

+ +

For designing focus indicators, selection indicators and user interface components + that need to be perceived clearly, the following are examples that have sufficient + contrast. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ User Interface Component Examples + +
TypeDescriptionExamples
Link TextDefault link text is in the scope of 1.4.3 Contrast (Minimum), and the underline is sufficient to indicate the link. + A browser-default styled link, blue with an underline.
Default focus styleLinks are required to have a visible focus indicator by 2.4.7 Focus Visible. Where the focus style of the user-agent is not adjusted on interactive controls + (such as links, form fields or buttons) by the website (author), the default focus + style is exempt from contrast requirements (but must still be visible). + A browser-default styled link, with a black dotted outline around the link.
ButtonsA button which has a distinguishing indicator such as position, text style, or context + does not need a contrasting visual indicator to show that it is a button, although some users are likely to identify + a button with an outline that meets contrast requirements more easily. + Button with a faint blue background.
Text input (minimal)Where a text-input has a visual indicator to show it is an input, such as a bottom + border (#767676), that indicator must meet 3:1 contrast ratio. + + A label with a text input shown by a bottom border and faint grey background. + +
Text inputWhere a text-input has an indicator such as a complete border (#767676), that indicator + must meet 3:1 contrast ratio. + + A label with a text input shown by a complete border. + +
Text input focus styleA focus indicator is required. While in this case the additional gray (#CCC) outline + has an insufficient contrast of 1.6:1 against the white (#FFF) background, the cursor/caret + which is displayed when the input receives focus does provide a sufficiently strong visual indication. + + A label with a text input with a faint gray outline and a visible cursor/caret. + +
Text input using background colorText inputs that have no border and are differentiated only by a background color + must have a 3:1 contrast ratio to the adjacent background (#043464). + + A label with a text input shown by a dark blue page background, and white box. + +
Toggle buttonThe toggle button's internal background (#070CD5) has a good contrast with the external + white background. Also, the round toggle within (#7AC2FF) contrasts with the internal + background. + Dark blue oval toggle button with light blue internal indicator.
Dropdown indicatorThe down-arrow is required to understand that there is drop-down functionality, it + has a contrast of 4.7:1 for the white icon on dark gray (#6E747B). + Button with the word Menu, and a down-arrow icon next to it.
Dropdown indicatorThe down-arrow is required to understand that there is drop-down functionality, it + has a contrast of 21:1 for the black icon on white. + Text with the word Menu, and a down-arrow icon next to it.
Checkbox - emptyA black border on a white background indicates the checkbox.Black square border with a text label.
Checkbox - checkedA black border on a white background indicates the checkbox, the black tick shape + indicates the state of checked. + Black square border with a tick inside, and a text label.
Checkbox - FailThe grey border color of the checkbox (#9D9D9D) has a contrast ratio of 2.7:1 with + the white background, which is not sufficient for the visual information required + to identify the checkbox. + Grey box on a white background with a black tick in the middle.
Checkbox - Subtle hover styleA black border on a white background indicates the checkbox, when the mouse pointer + activates the subtle hover state adds a grey background (#DEDEDE). The black border + has a 15:1 contrast ratio with the grey background. + Blackbox on a circular grey background next to a text label.
Checkbox - Subtle focus style - failA focus indicator is required. If the focus indicator is styled by the author, it + must meet the 3:1 contrast ratio with adjacent colors. In this case, the gray (#AAA) + indicator has an insufficient ratio of 2.3:1 with the white (#FFF) adjacent background. + + Unchecked checkbox with a thick gray additional outline as focus indication. + +
+ + +
+ +
+ +

Inactive User Interface Components

+ + +

User Interface Components that are not available for user interaction (e.g., a disabled + control in HTML) are not required to meet contrast requirements. An inactive user + interface component is visible but not currently operable. An example would be a submit + button at the bottom of a form that is visible but cannot be activated until all the + required fields in the form are completed. +

+ +
+ Grey button with non-contrasting grey text. + +
Figure 16 An inactive button using default browser styles
+ +
+ +

Inactive components, such as disabled controls in HTML, are not available for user + interaction. The decision to exempt inactive controls from the contrast requirements + was based on a number of considerations. Although it would be beneficial to some people + to discern inactive controls, a one-size-fits-all solution has been very difficult + to establish. A method of varying the presentation of disabled controls, such as adding + an icon for disabled controls, based on user preferences is anticipated as an advancement + in the future. +

+ +
+ +
+
+ +

Graphical Objects

+ + + +

The term "graphical object" applies to stand-alone icons such as a print icon (with + no text), and the important parts of a more complex diagram such as each line in a + graph. For simple graphics such as single-color icons the entire image is a graphical + object. Images made up of multiple lines, colors and shapes will be made of multiple + graphical objects, some of which are required for understanding. +

+ + +

Not every graphical object needs to contrast with its surroundings - only those that + are required for a user to understand what the graphic is conveying. Gestalt principles such as the "law of continuity" can be used to ignore minor overlaps with other graphical + objects or colors. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ImageNotes
An orange circle with a white telephone icon in the middle. +

The phone icon is a simple shape within the orange (#E3660E) circle. The meaning can + be understood from that icon alone, the background behind the circle is irrelevant. + The orange background and the white icon have a contrast ration greater than 3:1, + which passes. +

+ +

The graphical object is the white phone icon.

+ +
A red magnet with grey tips and a black outline. +

A magnet can be understood by the "U" shape with lighter colored tips. Therefore to + understand this graphic you should be able to discern the overall shape (against the + background) and the lighter colored tips (against the rest of the U shape and the + background). +

+ +

The graphical objects are the "U" shape (by outline or by the solid red color #D0021B), + and each tip of the magnet. +

+ +
A yellow arrow pointing down with a pound sign (currency) in the middle. +

The symbol to show a currency (the £) going down can be understood with recognition + of the shape (down arrow) and the currency symbol (pound icon with the shape which + is part of the graphic). To understand this graphic you need to discern the arrow + shape against the white background, and the pound icon against the yellow background + (#F5A623). +

+ +

The graphical objects are the shape and the currency symbol.

+ +
+ + A line chart of votes across a region, with 4 lines of different colors tracking over time. +

In order to understand the graph you need to discern the lines and shapes for each + condition. To perceive the values of each line along the chart you need to discern + the grey lines marking the graduated 100 value increments. +

+ +

The graphical objects are the lines in the graph, including the background lines for + the values, and the colored lines with shapes. +

+ +

The lines should have 3:1 contrast against their background, but as there is little + overlap with other lines they do not need to contrast with each other or the graduated + lines. (See the testing principles below.) +

+ +
A pie chart with small gaps between each slice showing the white background, and a dark outline around light colored slices. +

To understand the pie chart you have to discern each slice of the pie chart from the + others. +

+ +

The graphical objects are the slices of the pie (chart).

+ +

Note: If the values of the pie chart slices were also presented in a conforming manner + (see the Pie Charts example for details), the slices would not be required for understanding. +

+ +
+ + +

Taking the magnet image above as an example, the process for establishing the graphical + object(s) is to: +

+ +
    + +
  • Assess what part of each image is needed to understand what it represents.
    + The magnet's "U" shape can be conveyed by the outline or by the red background + (either is acceptable). The white tips are also important (otherwise it would be a + horseshoe), which needs to contrast with the red background. +
    • + +
  • Assume that the user could only see those aspects. Do they contrast with the adjacent + colors?
    + The outline of the magnet contrasts with the surrounding text (black/white), + and the red and white between the tips also has sufficient contrast. +
    • + +
+ + +

Due to the strong contrast of the red and white, it would also be possible to only + put the outline around the white tips of the magnet and it would still conform. +

+ + +
+ +

Required for Understanding

+ + +

The term "required for understanding" is used in the Success Criterion as many graphics + do not need to meet the contrast requirements. If a person needs to perceive a graphic, + or part of a graphic (a graphical object) in order to understand the content it should + have sufficient contrast. However, that is not a requirement when: +

+ +
    + +
  • + +

    A graphic with text embedded or overlayed conveys the same information, such as labels + and values on a chart. +

    + +
    +

    Note

    +

    Text within a graphic must meet 1.4.3 Contrast (Minimum). +

    +
    + +
    • + +
  • The graphic is for aesthetic purposes that does not require the user to see or understand + it to understand the content or use the functionality. +
    • + +
  • The information is available in another form, such as in a table that follows the + graph, which becomes visible when a "Long Description" button is pressed. +
    • + +
  • The graphic is part of a logo or brand name (which is considered "essential" to its + presentation). +
    • + +
+ +
+ +
+ +

Gradients

+ + +

Gradients can reduce the apparent contrast between areas, and make it more difficult + to test. The general principles is to identify the graphical object(s) required for + understanding, and take the central color of that area. If you remove the adjacent + color which does not have sufficient contrast, can you still identify and understand + the graphical object? +

+ +
+ Two versions of a blue circle with an 'i' indicating information. The first example has a blue gradient background, the second is missing the upper half of the background which obscures the i. + +
Figure 17 Removing the background which does not have sufficient contrast highlights that the + graphical object (the "i") is not then understandable. +
+
+ +
+ +
+ +

Dynamic Examples

+ + +

Some graphics may have interactions that either vary the contrast, or display the + information as text when you mouseover/tap/focus each graphical object. In order for + someone to discern the graphics exist at all, the unfocused default version must already + have sufficiently contrasting colors or text. For the area that receives focus, information + can then be made available dynamically as pop-up text, or be foregrounded dynamically + by increasing the contrast. +

+ + + + +
+ A pie chart with one slice highlighted and a box hovering next to it that shows the data and indicates the source in the key. + +
Figure 18 A dynamic chart where the current 'slice' is hovered or focused, which activates the + associated text display of the values and highlights the series +
+ +
+ +
+ +
+ +

Infographics

+ + +

Infographics can mean any graphic conveying data, such as a chart or diagram. On the + web it is often used to indicate a large graphic with lots of statements, pictures, + charts or other ways of conveying data. In the context of graphics contrast, each + item within such an infographic should be treated as a set of graphical objects, regardless + of whether it is in one file or separate files. +

+ + +

Infographics often fail to meet several WCAG level AA criteria including:

+ + + + + +

An infographic can use text which meets the other criteria to minimise the number + of graphical objects required for understanding. For example, using text with sufficient + contrast to provide the values in a chart. A long description would also be sufficient + because then the infograph is not relied upon for understanding. +

+ + +
+ + +
+ +

Symbolic text characters

+ +

When text characters are used as symbols – used for their visual appearance, rather + than expressing something in human language – they fall under the definition of non-text content. +

+ +
+ A button using an uppercase 'X' and a button with a greater-than character + +
Figure 19 Even though the two buttons use text characters — an uppercase X, often used for "Close" buttons, and a > character, to act as a right-pointing arrow — they count as non-text characters/symbols. + Their contrast ratio of just above 3:1 passes this Success Criterion. +
+ +
+ +
+ + +
+ +

Essential Exception

+ + +

Graphical objects do not have to meet the contrast requirements when "a particular + presentation of graphics is essential to the information being conveyed". The Essential + exception is intended to apply when there is no way of presenting the graphic with + sufficient contrast without undermining the meaning. For example: +

+ +
    + +
  • Logotypes and flags: The brand logo of an organization or product is the representation of that organization + and therefore exempt. Flags may not be identifiable if the colors are changed to have + sufficient contrast. +
    • + +
  • Sensory: There is no requirement to change pictures of real life scenes such as photos of + people or scenery. +
    • + +
  • Representing other things: If you cannot represent the graphic in any other way, it is essential. Examples + include: + + + +
    • + +
+ +
+ + +
+ +

Testing Principles

+ +

A summary of the high-level process for finding and assessing non-text graphics on + a web page: +

+ +
    + +
  • Identify each user-interface component (link, button, form control) on the page and: + +
      + +
    • Identify the visual (non-text) indicators of the component that are required to identify + that a control exists, and indicate the current state. In the default (on page load) + state, test the contrast ratio against the adjacent colors. +
      • + +
    • Test those contrast indicators in each state.
      • + +
    + +
    • + +
  • Identify each graphic on the page that includes information required for understanding + the content (i.e. excluding graphics which have visible text for the same information, + or are decorative) and: + +
      + +
    • Check the contrast of the graphical object against its adjacent colors;
      • + +
    • If there are multiple colors and/or a gradient, choose the least contrasting area + to test; +
      • + +
    • If it passes, move to the next graphical object;
      • + +
    • If the least-contrasting area is less than 3:1, assume that area is invisible, is + the graphical object still understandable? +
      • + +
    • If there is enough of the graphical object to understand, it passes, else fail.
      • + +
    + +
    • + +
+ +

The techniques below each have testing criteria, and the related criteria for Focus visible (2.4.7), Use of color (1.4.1), and Contrast minimum also have techniques. +

+ +
+ + +
+
+
+

Benefits

+

People with low vision often have difficulty perceiving graphics that have insufficient + contrast. This can be exacerbated if the person has a color vision deficiency that + lowers the contrast even further. Providing a relative luminance (lightness difference) of 3:1 or greater can make these items more distinguishable + when the person does not see a full range of colors. +

+
+
+

Examples

+
    + +
  • Status icons on an application's dashboard (without associated text) have a 3:1 minimum + contrast ratio. +
    • + +
  • A text input has a dark border around the white editable area.
    • + +
  • A graph uses a light background and ensures that the colors for each line have a 3:1 + contrast ratio against the background. +
    • + +
+
+ +

Pie Charts

+ +

Pie charts make a good case study for the graphical objects part of this success criterion, + the following pie charts are intended to convey the proportion of market share each + browser has. Please Note: The actual figures are made up, these are not actual market + shares. +

+ +
+ Failing pie chart + +
Figure 20 + +

Fail: The pie chart has labels for each slice (so passes 1.4.1 Use of Color), but in order + to understand the proportions of the slices you must discern the edges of the slices + (the graphical objects conveying essential information), and the contrast between + the slices is not 3:1 or greater. +

+ +
+ +
+ +
+ Not applicable pie chart + +
Figure 21 + +

Not applicable: The pie chart has visible labels and values that convey equivalent information to the graphical objects (the pie slices). + +

+ +
+ +
+ +
+ Passing pie chart + +
Figure 22 + +

Pass: The pie chart has visible labels, and sufficient contrast around and between the + slices of the pie chart (the graphical objects). A darker border has been added around + the yellow slice in order to achieve the contrast level. +

+ +
+ +
+ +
+
+ +

Infographics

+ +
+ An infographic showing lightly colored circles of various sizes to indicate the size of five different social networks + +
Figure 23 + +

Fail: Discerning the circles is required to understand the size of network and discerning + the icons in each circle is required to identify which network it shows. +

+ +
+ +
+ +

The graphical objects are the circles (measured against the background) and the icons + in each circle (measured against the circle's background). +

+ +
+ The same infographic with contrasting text, dark borders around the circles, and contrasting icons. + +
Figure 24 + +

Pass: The circles have contrasting borders and the icons are a contrasting dark color against + the light circle backgrounds. +

+ +
+ +
+ +

There are many possible solutions to ensuring contrast, the example shows the use + of borders. Other techniques are to use darker colors for the circle backgrounds, + or to add text labels & values for each item. +

+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ +

Situation A: Color is used to identify user interface components or used to identify + user interface component states +

+ + + +
+
+ +

Situation B: Color is required to understand graphical content

+ + + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
ascii art
+
+ + + +

picture created by a spatial arrangement of characters or glyphs (typically from the + 95 printable characters defined by ASCII) + +

+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
contrast ratio
+
+ + + +

(L1 + 0.05) / (L2 + 0.05), where

+ + + + + +
+

Note

+

Contrast ratios can range from 1 to 21 (commonly written 1:1 to 21:1).

+
+ + +
+

Note

+

Because authors do not have control over user settings as to how text is rendered + (for example font smoothing or anti-aliasing), the contrast ratio for text can be + evaluated with anti-aliasing turned off. + +

+
+ + +
+

Note

+

For the purpose of Success Criteria 1.4.3 and 1.4.6, contrast is measured with respect + to the specified background over which the text is rendered in normal usage. If no + background color is specified, then white is assumed. + +

+
+ + +
+

Note

+

Background color is the specified color of content over which the text is to be rendered + in normal usage. It is a failure if no background color is specified when the text + color is specified, because the user's default background color is unknown and cannot + be evaluated for sufficient contrast. For the same reason, it is a failure if no text + color is specified when a background color is specified. + +

+
+ + +
+

Note

+

When there is a border around the letter, the border can add contrast and would be + used in calculating the contrast between the letter and its background. A narrow border + around the letter would be used as the letter. A wide border around the letter that + fills in the inner details of the letters acts as a halo and would be considered background. + +

+
+ + +
+

Note

+

WCAG conformance should be evaluated for color pairs specified in the content that + an author would expect to appear adjacent in typical presentation. Authors need not + consider unusual presentations, such as color changes made by the user agent, except + where caused by authors' code. + +

+
+ + + +
+
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
non-text content
+
+ + + +

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language + +

+ + +
+

Note

+

This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), + and images representing text + +

+
+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
relative luminance
+
+ + + +

the relative brightness of any point in a colorspace, normalized to 0 for darkest + black and 1 for lightest white + +

+ + +
+

Note

+
+ +

For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 + * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as: + +

+ + +
    + + +
  • if RsRGB <= 0.04045 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
  • if GsRGB <= 0.04045 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
  • if BsRGB <= 0.04045 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
+ + +

and RsRGB, GsRGB, and BsRGB are defined as:

+ + +
    + + +
  • RsRGB = R8bit/255
    • + + +
  • GsRGB = G8bit/255
    • + + +
  • BsRGB = B8bit/255
    • + + +
+ + +

The "^" character is the exponentiation operator. (Formula taken from + [[SRGB]].) + +

+ + +
+
+ + +
+

Note

+

Before May 2021 the value of 0.04045 in the definition was different (0.03928). It + was taken from an older version of the specification and has been updated. It has + no practical effect on the calculations in the context of these guidelines. +

+
+ + +
+

Note

+

Almost all systems used today to view Web content assume sRGB encoding. Unless it + is known that another color space will be used to process and display the content, + authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3. + +

+
+ + +
+

Note

+

If dithering occurs after delivery, then the source color value is used. For colors + that are dithered at the source, the average values of the colors that are dithered + should be used (average R, average G, and average B). + +

+
+ + +
+

Note

+

Tools are available that automatically do the calculations when testing contrast and + flash. + +

+
+ + +
+

Note

+

A separate page giving the relative luminance definition using MathML to display the formulas is available. + +

+
+ + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
state
+
+ + + +

dynamic property expressing characteristics of a user interface component that may + change in response to user action or automated processes +

+ +

States do not affect the nature of the component, but represent data associated with + the component or user interaction possibilities. Examples include focus, hover, select, + press, check, visited/unvisited, and expand/collapse. +

+ + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/on-focus.html b/wcag22/understanding/on-focus.html new file mode 100644 index 0000000..124409e --- /dev/null +++ b/wcag22/understanding/on-focus.html @@ -0,0 +1,750 @@ + + + + + + Understanding Success Criterion 3.2.1: On Focus | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.2.1:On Focus (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Content can be navigated more predictably.
+ +
What to do
+
Do not change a user's context when items get focus.
+ +
Why it's important
+
Content that behaves predictably is especially important to people with disabilities.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that functionality is predictable + as visitors navigate their way through a document. Any component that is able to trigger + an event when it receives focus must not change the context. Examples of + changing context when a component receives focus include, but are not limited to: + + +

+
    + + +
  • forms submitted automatically when a component receives focus;
    • + + +
  • new windows launched when a component receives focus;
    • + + +
  • focus is changed to another component when that component receives focus;
    • + + +
+

Focus may be moved to a control either via the keyboard (e.g. tabbing to a control) + or the mouse (e.g. clicking on a text field). Moving the mouse over a control does + not move the focus + unless scripting implements this behavior. Note that for some types of controls, clicking + on a control may also activate the control (e.g. button), which may, in turn, initiate + a change in context. + + +

+
+

Note

+
+ + +

What is meant by "component" here is also sometimes called "user interface element" + or "user interface component". + +

+ + +
+
+
+
+

Benefits

+
    + + +
  • This Success Criterion helps people with visual disabilities, cognitive limitations, + and motor impairments by reducing the chance that a change of context will occur unexpectedly. + +
    • + + +
+
+
+

Examples

+
+ +
Example 1: A dropdown menu
+ +
A dropdown menu on a page allows users to choose between jump destinations. If the + person uses the keyboard to move down to a choice and activates it (with a spacebar + or enter key) it will jump to a new page. However, if the person moves down to a + choice and either hits the escape or the tab key to move out of the pulldown menu + – it does not jump to a new screen as the focus shifts out of the dropdown menu. +
+ +
Example of a Failure: A help dialog
+ +
When a field receives focus, a help dialog window describing the field and providing + options opens. As a keyboard user tabs through the Web page, the dialog opens, moving + the keyboard focus away from the control every time the user attempts to tab past + the field. +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+

Note

+
+ + +

A change of content is not always a + change of context. This success criterion is automatically met if changes in content are not also changes + of context. + +

+ + +
+
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
changes of context
+
+ + + +

major changes that, if made without user awareness, can disorient users who are not + able to view + the entire page simultaneously + +

+ + +

Changes in context include changes of:

+ + +
    + + +
  1. + user agent; + +
    2. + + +
  2. + viewport; + +
    3. + + +
  3. focus;
    4. + + +
  4. + content that changes the meaning of the Web page + +
    5. + + +
+ + +
+

Note

+

A change of content is not always a change of context. Changes in content, such as + an expanding outline, dynamic menu, or a tab control do not necessarily change the + context, unless they also change one of the above (e.g., focus). + +

+
+ + + + + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
viewport
+
+ + + +

object in which the user agent presents content

+ + +
+

Note

+

The user agent presents content through one or more viewports. Viewports include windows, frames, + loudspeakers, and virtual magnifying glasses. A viewport may contain another viewport + (e.g., nested frames). Interface components created by the user agent such as prompts, + menus, and alerts are not viewports. + +

+
+ + +
+

Note

+

This definition is based on User Agent Accessibility Guidelines 1.0 Glossary [[UAAG10]]. + +

+
+ + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/on-input.html b/wcag22/understanding/on-input.html new file mode 100644 index 0000000..7267f91 --- /dev/null +++ b/wcag22/understanding/on-input.html @@ -0,0 +1,852 @@ + + + + + + Understanding Success Criterion 3.2.2: On Input | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.2.2:On Input (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Content can be operated more predictably.
+ +
What to do
+
Forewarn users if their context will change based on their input.
+ +
Why it's important
+
Content that behaves predictably is especially important to people with disabilities.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that entering data or selecting + a form control has predictable effects. Changing the setting of any user interface + component is changing some aspect in the control that will persist when the user is + no longer interacting with it. So checking a checkbox, entering text into a text field, + or changing the selected option in a list control changes its setting, but activating + a link or a button does not. Changes in context can confuse users who do not easily + perceive the change or are easily distracted by changes. Changes of context are appropriate + only when it is clear that such a change will happen in response to the user's action. + + + +

+
+

Note

+
+ + +

This Success Criterion covers changes in context due to changing the setting of a + control. Clicking on links or tabs in a tab control is activating the control, not + changing the setting of that control. + +

+ + +
+
+
+

Note

+
+ + +

What is meant by "component" and "user interface component" here is also sometimes + called "user interface element". + +

+ + +
+
+
+
+

Benefits

+
    + + +
  • This Success Criterion helps users with disabilities by making interactive content + more predictable. Unexpected changes of context can be so disorienting for users with + visual disabilities or cognitive limitations that they are unable to use the content. + + + +
    • + + +
  • + + +

    Individuals who are unable to detect changes of context are less likely to become + disoriented while navigating a site. For example: + + +

    + + +
      + + +
    • Individuals who are blind or have low vision may have difficulty knowing when a visual + context change has occurred, such as a new window popping up. In this case, warning + users of context changes in advance minimizes confusion when the user discovers that + the back button no longer behaves as expected. + + +
      • + + +
    + + +
    • + + +
  • Some individuals with low vision, with reading and intellectual disabilities, and + others who have difficulty interpreting visual cues may benefit from additional cues + in order to detect changes of context. + +
    • + + +
+
+
+

Examples

+
    + + +
  • + A form is provided for creating calendar entries in a Web based calendaring and scheduling + application. Along with the standard fields for subject, time and location, there + is a set of radio buttons to select the type of calendar entry to create. The calendar + entry type can be meeting, appointment or reminder. If the user selects the radio + for meeting, additional fields are displayed on the page for entering the meeting + participants. Different fields appear if the reminder button is chosen. Because only + parts of the entry change and the overall structure remains the same the basic context + remains for the user. + + +
    • + + +
  • + A form contains fields representing US phone numbers. All of the numbers have a three + digit area code followed by a three digit prefix and finally a four digit number, + and each part of the phone number is entered into a separate field. When the user + completes the entry of one field the focus automatically moves to the next field of + the phone number. This behavior of phone fields is described for the user at the beginning + of the form. + + +
    • + + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+

Note

+
+ + +

A change of content is not always a + change of context. This success criterion is automatically met if changes in content are not also changes + of context. + +

+ + +
+
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
changes of context
+
+ + + +

major changes that, if made without user awareness, can disorient users who are not + able to view + the entire page simultaneously + +

+ + +

Changes in context include changes of:

+ + +
    + + +
  1. + user agent; + +
    2. + + +
  2. + viewport; + +
    3. + + +
  3. focus;
    4. + + +
  4. + content that changes the meaning of the Web page + +
    5. + + +
+ + +
+

Note

+

A change of content is not always a change of context. Changes in content, such as + an expanding outline, dynamic menu, or a tab control do not necessarily change the + context, unless they also change one of the above (e.g., focus). + +

+
+ + + + + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
viewport
+
+ + + +

object in which the user agent presents content

+ + +
+

Note

+

The user agent presents content through one or more viewports. Viewports include windows, frames, + loudspeakers, and virtual magnifying glasses. A viewport may contain another viewport + (e.g., nested frames). Interface components created by the user agent such as prompts, + menus, and alerts are not viewports. + +

+
+ + +
+

Note

+

This definition is based on User Agent Accessibility Guidelines 1.0 Glossary [[UAAG10]]. + +

+
+ + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/orientation.html b/wcag22/understanding/orientation.html new file mode 100644 index 0000000..49330d3 --- /dev/null +++ b/wcag22/understanding/orientation.html @@ -0,0 +1,380 @@ + + + + + + Understanding Success Criterion 1.3.4: Orientation | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.3.4:Orientation (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Devices can be used in any orientation.
+ +
What to do
+
Don't lock content to either portrait or landscape presentation.
+ +
Why it's important
+
Wheelchair users and others may have devices mounted in a fixed orientation.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that content displays in the orientation + (portrait or landscape) preferred by the user. Some websites and applications automatically + set and restrict the screen to a particular display orientation and expect + that users will respond by rotating their device to match, but this can create + problems. Some users have their devices mounted + in a fixed orientation (e.g. on the arm of a power wheelchair). Therefore, websites + and applications need to support both orientations + by not restricting the orientation. Changes in content or functionality due to + the size of display are not covered by this criterion which is focused on restrictions + of orientation. +

+

Historically, devices tended to have a fixed-orientation display, and all content + was created to match that display orientation. Today, most handhelds and many other + devices (e.g., monitors) have a hardware-level ability to dynamically adjust default + display orientation based on sensor information. The goal of this Success Criterion + is that authors should never restrict content's orientation, thus ensuring that it + always match the device display orientation. +

+

It is important to distinguish between an author's responsibility not to restrict + content to a specific orientation, and device-specific settings governing the locking + of display orientation. +

+

Many hand-held devices offer a mechanical switch or a system setting (or both) to + allow the user to lock the device display to a specific orientation. Where a user + decides to lock their entire device to an orientation, all applications are expected + to pick up that setting and to display content accordingly. +

+

This Success Criterion complements device "lock orientation" settings. A web page + that does not restrict its display orientation will always support the system-level + orientation setting, since the system setting is picked up by the user agent. Alternatively, + where a device-level orientation lock is not in place, the user agent should display + the page according to the orientation of the device (either its default, or the current + orientation determined by any device sensors). +

+

The exception for things considered essential is aimed at situations where the content + would only be understood in a particular orientation, or where the technology restricts + the possible orientations. If content is aimed at a specific environment which is + only available in one orientation (such as a television) then the content can restrict + the orientation. Technologies such as virtual reality use screens within goggles that + cannot change orientation relative to the user's eyes. +

+
+
+

Benefits

+
    + +
  • Users with dexterity impairments, who have a mounted device will be able to use the + content in their fixed orientation. +
    • + +
  • Users with low-vision will be able to view content in the orientation that works best + for them, for example to increase the text size by viewing content in landscape. +
    • + +
+
+
+

Examples

+
    + +
  • Example 1: Online video site
    + A video is shown in either portrait or in landscape based on the user's chosen + orientation. +
    • + +
  • Example 2: Messaging website
    + A messaging website can display messages in both portrait and landscape orientations. + +
    • + +
  • Example 3: eReader web app
    + An eReader web app can display the contents of a book in both portrait and landscape + orientation. +
    • + +
  • Example 4: Check deposit in banking app
    + An example where orientation is essential could be a banking app that requires + the device be in landscape mode to easily and accurately capture an image of a check + for deposit. These paper forms are typically about twice as wide as they are high. +
    • + +
  • Example 5: Piano app
    + An example where orientation is essential could be a piano app that requires the + device to be in landscape mode to allow room for enough of the piano keys to be functionally + usable. Since a piano app is emulating a physical piano keyboard that needs to retain + relative physical characteristics between keys, either too few keys would be available, + or the keys would be much too narrow. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/page-titled.html b/wcag22/understanding/page-titled.html new file mode 100644 index 0000000..4473acb --- /dev/null +++ b/wcag22/understanding/page-titled.html @@ -0,0 +1,652 @@ + + + + + + Understanding Success Criterion 2.4.2: Page Titled | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.2:Page Titled (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Each web page has a meaningful title.
+ +
What to do
+
Provide a descriptive page title using appropriate technology.
+ +
Why it's important
+
Page titles help users identify and distinguish different pages.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to help users find content and orient themselves + within it by ensuring that each Web page has a descriptive title. Titles identify + the current location without requiring users to read or interpret page content. When + titles appear in site maps or lists of search results, users can more quickly identify + the content they need. User agents make the title of the page easily available to + the user for identifying the page. For instance, a user agent may display the page + title in the window title bar or as the name of the tab containing the page. + +

+

In cases where the page is a document or a web application, the name of the document + or web application would be sufficient to describe the purpose of the page. Note that + it is not required to use the name of the document or web application; other things + may also describe the purpose or the topic of the page. + +

+

In cases such as Single Page Applications (SPAs), where various distinct pages/views + are + all nominally served from the same URI and the content of the page is changed dynamically, + the title of the page should also be changed dynamically to reflect the content or + topic of + the current view. + +

+

+ + Success Criteria 2.4.4 and + 2.4.9 deal with the purpose of links, many of which are links to web pages. Here also, + the name of a document or web application being linked to would be sufficient to describe + the purpose of the link. Having the link and the title agree, or be very similar, + is good practice and provides continuity between the link 'clicked on' and the web + page that the user lands on. + +

+
+
+

Benefits

+
    + + +
  • + This criterion benefits all users in allowing users to quickly and easily identify + whether the information contained in the Web page is relevant to their needs. + + +
    • + + +
  • + People with visual disabilities will benefit from being able to differentiate content + when multiple Web pages are open. + + +
    • + + +
  • + People with cognitive disabilities, limited short-term memory and reading disabilities + also benefit from the ability to identify content by its title. + + +
    • + + +
  • + This criterion also benefits people with severe mobility impairments whose mode of + operation relies on audio when navigating between Web pages. + + +
    • + + +
+
+
+

Examples

+
+ +
An HTML Web page
+ +
The descriptive title of an HTML Web page is marked up with the <title> element so + that it will be displayed in the title bar of the user agent. +
+ +
A document collection
+ +
+ +

The title of Understanding WCAG 2.1 + is "Understanding WCAG 2.1." +

+ +
    + +
  • The introduction page has the title "Introduction to Understanding WCAG 2.0."
    • + +
  • Major sections of the document are pages titled "Understanding Guideline X" and "Understanding + Success Criterion X." + +
    • + +
  • Appendix A has the title "Glossary."
    • + +
  • Appendix B has the title "Acknowledgements."
    • + +
  • Appendix C has the title "References."
    • + +
+ +
+ +
A Web application
+ +
A banking application lets users inspect their bank accounts, view past statements, + and perform transactions. The Web application dynamically generates titles for each + Web page, e.g., "Bank XYZ, accounts for Alex Smith" "Bank XYZ, December 2005 statement + for Account 1234-5678". +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/parsing.html b/wcag22/understanding/parsing.html new file mode 100644 index 0000000..70cb6b3 --- /dev/null +++ b/wcag22/understanding/parsing.html @@ -0,0 +1,423 @@ + + + + + + Understanding Success Criterion 4.1.1: Parsing (Obsolete and removed) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 4.1.1:Parsing (Obsolete and removed) (Level ) +

+ +
+
+

In Brief

+
+ +
Goal
+
Assistive technology can properly present page content.
+ +
What to do
+
Create web pages according to specifications.
+ +
Why it's important
+
People can browse web content more easily with their assistive technology.
+ +
+
+
+

Intent

+
New in WCAG 22: + +

This criterion has been removed from WCAG 2.2.

+ + +

The intent of this Success Criterion was to ensure that user-agents, including assistive + technologies, can accurately interpret and parse content. Since WCAG 2.0 was published, + the specifications (such as HTML) and browsers have improved their handling of parsing + errors. It is also the case that assistive technology used to do their own parsing + of markup, but now rely on the browser. For that reason this success criterion has + been removed. Many issues that would have failed this criterion will fail Info and Relationships or Name, Role, Value. Other issues are excepted by the "except where the specification allow these features" + part of the criterion. +

+ + +

The following content is left for historical purposes to show the original intent.

+ + +
+ + +
+ +

Success Criterion 4.1.1 Parsing (Level A): In content implemented using markup languages, elements have complete + start and end + tags, elements are nested according to their specifications, elements do not contain + duplicate attributes, and any IDs are unique, except where the specifications allow + these features. + +

+ +
+

Note

+

Start and end tags that are missing a critical character in their formation, such + as a closing angle bracket or a mismatched attribute value quotation mark are not + complete. + +

+
+ +
+ +
+

+ The intent of this Success Criterion is to ensure that user agents, including assistive + technologies, can accurately interpret and parse content. If the content cannot be + parsed into a data structure, then different user agents may present it differently + or be completely unable to parse it. Some user agents use "repair techniques" to render + poorly coded content. + +

+

Since repair techniques vary among user agents, authors cannot assume that content + will be accurately parsed into a data structure or that it will be rendered correctly + by specialized user agents, including assistive technologies, unless the content is + created according to the rules defined in the formal grammar for that technology. + In markup languages, errors in element and attribute syntax and + failure to provide properly nested start/end tags lead to errors that + prevent user agents from parsing the content reliably. + Therefore, the Success Criterion requires that the content can be parsed using only + the rules of the formal grammar. + + +

+
+

Note

+
+ + +

The concept of "well formed" is close to what is required here. However, exact parsing + requirements vary amongst markup languages, and most non XML-based languages do not + explicitly define requirements for well formedness. Therefore, it was necessary to + be more explicit in the Success Criterion in order to be generally applicable to markup + languages. Because the term "well formed" is only defined in XML, and (because end + tags are sometimes optional) valid HTML does not require well formed code, the term + is not used in this Success Criterion. + +

+ + +

With the exception of one Success Criterion ( + 1.4.4: Resize Text, which specifically mentions that the effect specified by the Success Criterion must + be achieved without relying on an assistive technology) authors can meet the Success + Criteria with content that assumes use of an assistive technology (or access features + in use agents) by the user, where such assistive technologies (or access features + in user agents) exist and are available to the user. + +

+ + +
+
+
+
+

Benefits

+
    + + +
  • Ensuring that Web pages have complete start and end tags and are nested according + to specification + helps ensure that assistive technologies can parse the content accurately and without + crashing. + +
    • + + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/pause-stop-hide.html b/wcag22/understanding/pause-stop-hide.html new file mode 100644 index 0000000..50018c1 --- /dev/null +++ b/wcag22/understanding/pause-stop-hide.html @@ -0,0 +1,946 @@ + + + + + + Understanding Success Criterion 2.2.2: Pause, Stop, Hide | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.2.2:Pause, Stop, Hide (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Fewer users are distracted by content that updates or moves.
+ +
What to do
+
Let users control content changes that occur in parallel with other content.
+ +
Why it's important
+
Some people with cognitive disabilities and attention deficits cannot concentrate + with continual movement. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to avoid distracting users during their interaction + with a Web page. + +

+

"Moving, blinking and scrolling" refers to content in which the visible content conveys + a sense of motion. Common examples include motion pictures, synchronized media presentations, + animations, real-time games, and scrolling stock tickers. "Auto-updating" refers to + content that updates or disappears based on a preset time interval. Common time-based + content includes audio, automatically updated weather information, news, stock price + updates, and auto-advancing presentations and messages. The requirements for moving, + blinking and scrolling content and for auto-updating content are the same except that: + +

+
    + + +
  • authors have the option of providing the user with a means to control the frequency + of updates when content is auto-updating and + +
    • + + +
  • there is no five second exception for auto-updating since it makes little sense to + auto-update for a few seconds and then stop + +
    • + + +
+

Content that moves or auto-updates can be a barrier to anyone who has trouble reading + stationary text quickly as well as anyone who has trouble tracking moving objects. + It can also cause problems for screen readers. + +

+

Moving content can also be a severe distraction for some people. Certain groups, particularly + those with attention deficit disorders, find blinking content distracting, making + it difficult for them to concentrate on other parts of the Web page. Five seconds + was chosen because it is long enough to get a user's attention, but not so long that + a user cannot wait out the distraction if necessary to use the page. + +

+

Content that is paused can either resume in real-time or continue playing from the + point in the presentation where the user left off. + +

+
    + + +
  • + + +

    Pausing and resuming where the user left off is best for users who want to pause to + read content and works best when the content is not associated with a real-time event + or status. + +

    + + +
    +

    Note

    +
    + + +

    See + 2.2.1: Timing Adjustable for additional requirements related to time-limits for reading. + +

    + + +
    +
    + + +
    • + + +
  • + + +

    Pausing and jumping to current display (when pause is released) is better for information + that is real-time or "status" in nature. For example, weather radar, a stock ticker, + a traffic camera, or an auction timer, would present misleading information if a pause + caused it to display old information when the content was restarted. + +

    + + +
    +

    Note

    +
    + + +

    Hiding content would have the same result as pausing and jumping to current display + (when pause is released). + +

    + + +
    +
    + + +
    • + + +
+

For a mechanism to be considered "a mechanism for the user to pause," it must provide + the user with a means to pause that does not tie up the user or the focus so that + the page cannot be used. The word "pause" here is meant in the sense of a "pause + button" although other mechanisms than a button can be used. Having an animation + stop only so long as a user has focus on it (where it restarts as soon as the user + moves the focus away) would not be considered a "mechanism for the user to pause" + because it makes the page unusable in the process and would not meet this SC. + +

+

It is important to note that the terms "blinking" and "flashing" can sometimes refer + to the same content. + +

+
    + + +
  • "Blinking" refers to content that causes a distraction problem. Blinking can be allowed + for a short time as long as it stops (or can be stopped) + +
    • + + +
  • "Flashing" refers to content that can trigger a seizure (if it is more than 3 per + second and large and bright enough). This cannot be allowed even for a second or it + could cause a seizure. And turning the flash off is also not an option since the seizure + could occur faster than most users could turn it off. + +
    • + + +
  • Blinking usually does not occur at speeds of 3 per second or more, but it can. If + blinking occurs faster than 3 per second, it would also be considered a flash. + +
    • + + +
+
+
+

Benefits

+
    + + +
  • Providing content that stops blinking after five seconds or providing a mechanism + for users to stop blinking content allows people with certain disabilities to interact + with the Web page. + +
    • + + +
  • One use of content that blinks is to draw the visitor's attention to that content. + Although this is an effective technique for all users with vision, it can be a problem + for some users if it persists. For certain groups, including people with low literacy, + reading and intellectual disabilities, and people with attention deficit disorders, + content that blinks may make it difficult or even impossible to interact with the + rest of the Web page. + + +
    • + + +
+
+
+

Examples

+
+ +
An essential animation can be paused without affecting the activity
+ +
A Web site helps users understand 'how things work' through animations that demonstrate + processes. Animations have "pause" and "restart" buttons. +
+ +
A stock ticker
+ +
A stock ticker has "pause" and "restart" buttons. Pausing the ticker causes it to + pause on the currently displayed stock. Restarting causes the ticker to resume from + the stopped point but with a notice that the display is delayed. Since the intent + of the stock ticker is usually to provide realtime information, there might also be + a button that would advance the ticker to the most recently traded stock. +
+ +
A game is designed so that users take turns rather than competing in real-time
+ +
One party can pause the game without invalidating the competitive aspect of it.
+ +
A Web advertisement
+ +
An advertisement blinks to get viewers attention but stops after 5 seconds
+ +
A form prompt
+ +
A form blinks an arrow near the submit button if a user finishes filling out the form + but does not activate the submit button. The blinking stops after 5 seconds. +
+ +
An animation
+ +
An animation runs in the upper portion of the page but has a "freeze animation" button + near the bottom of the animation. +
+ +
A "loading" animation
+ +
A preloader animation is shown on a page which requires a certain percentage of a + large file to be downloaded before playback can begin. The animation is the only content + on the page and instructs the user to please wait while the video loads. Because the + moving content is not presented in parallel with other content, no mechanism to pause, + stop or hide it needs to be provided, even though the animation may run for more than + 5 seconds for users with slower connections. +
+ +
A full-page advertisement
+ +
A site requires that all users view a 15 second advertisement before they can access + free content available from their site. Because viewing the advertisement is a requirement + for all users and because it is not presented in parallel with other content, no mechanism + to pause, stop or hide it needs to be provided. +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
blinking
+
+ + + +

switch back and forth between two visual states in a way that is meant to draw attention

+ + +
+

Note

+

See also flash. It is possible for something to be large enough and blink brightly enough at the + right frequency to be also classified as a flash. + +

+
+ + + +
+
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
flash
+
+ + + +

a pair of opposing changes in relative luminance that can cause seizures in some people if it is large enough and in the right frequency + range + +

+ + +
+

Note

+

See general flash and red flash thresholds for information about types of flash that are not allowed. + +

+
+ + +
+

Note

+

See also blinking. + +

+
+ + + +
+
general flash and red flash thresholds
+
+ + + +

a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of the following are true: + +

+ + +
    + + +
  1. there are no more than three general flashes and / or no more than three red flashes within any one-second period; or + +
    2. + + +
  2. the combined area of flashes occurring concurrently occupies no more than a total + of .006 steradians within any 10 degree visual field on the screen (25% of any 10 + degree visual field on the screen) at typical viewing distance + +
    3. + + +
+ + +

where:

+ + +
    + + +
  • A general flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance (1.0) where the relative luminance + of + the darker image is below 0.80; and where "a pair of opposing changes" is an increase + followed by a decrease, or a decrease followed by an increase, and + +
    • + + +
  • A red flash is defined as any pair of opposing transitions involving a saturated red + +
    • + + +
+ + +

+ Exception: Flashing that is a fine, balanced, pattern such as white noise or an alternating + checkerboard pattern with "squares" smaller than 0.1 degree (of visual field at typical + viewing distance) on a side does not violate the thresholds. + +

+ + +
+

Note

+

For general software or Web content, using a 341 x 256 pixel rectangle anywhere on + the displayed screen area when the content is viewed at 1024 x 768 pixels will provide + a good estimate of a 10 degree visual field for standard screen sizes and viewing + distances (e.g., 15-17 inch screen at 22-26 inches). This resolution of 75 - 85 ppi + is known to be lower, and thus more conservative than the nominal CSS pixel resolution + of 96 ppi in CSS specifications. Higher resolutions displays showing the same rendering + of the content yield smaller and safer images so it is lower resolutions that are + used to define the thresholds. + +

+
+ + +
+

Note

+

A transition is the change in relative luminance (or relative luminance/color for + red flashing) between adjacent peaks and valleys in a plot of relative luminance (or + relative luminance/color for red flashing) measurement against time. A flash consists + of two opposing transitions. + +

+
+ + +
+

Note

+

The new working definition in the field for "pair of opposing transitions involving a saturated red" (from WCAG 2.2) is a pair of opposing transitions where, one transition is either + to or from a state with a value R/(R + G + B) that is greater than or equal to 0.8, + and the difference between states is more than 0.2 (unitless) in the CIE 1976 UCS + chromaticity diagram. [[ISO_9241-391]] +

+
+ + +
+

Note

+

Tools are available that will carry out analysis from video screen capture. However, + no tool is necessary to evaluate for this condition if flashing is less than or equal + to 3 flashes in any one second. Content automatically passes (see #1 and #2 above). + +

+
+ + + +
+
paused
+
+ + + +

stopped by user request and not resumed until requested by user

+ + + +
+
relative luminance
+
+ + + +

the relative brightness of any point in a colorspace, normalized to 0 for darkest + black and 1 for lightest white + +

+ + +
+

Note

+
+ +

For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 + * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as: + +

+ + +
    + + +
  • if RsRGB <= 0.04045 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
  • if GsRGB <= 0.04045 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
  • if BsRGB <= 0.04045 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
+ + +

and RsRGB, GsRGB, and BsRGB are defined as:

+ + +
    + + +
  • RsRGB = R8bit/255
    • + + +
  • GsRGB = G8bit/255
    • + + +
  • BsRGB = B8bit/255
    • + + +
+ + +

The "^" character is the exponentiation operator. (Formula taken from + [[SRGB]].) + +

+ + +
+
+ + +
+

Note

+

Before May 2021 the value of 0.04045 in the definition was different (0.03928). It + was taken from an older version of the specification and has been updated. It has + no practical effect on the calculations in the context of these guidelines. +

+
+ + +
+

Note

+

Almost all systems used today to view Web content assume sRGB encoding. Unless it + is known that another color space will be used to process and display the content, + authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3. + +

+
+ + +
+

Note

+

If dithering occurs after delivery, then the source color value is used. For colors + that are dithered at the source, the average values of the colors that are dithered + should be used (average R, average G, and average B). + +

+
+ + +
+

Note

+

Tools are available that automatically do the calculations when testing contrast and + flash. + +

+
+ + +
+

Note

+

A separate page giving the relative luminance definition using MathML to display the formulas is available. + +

+
+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/pointer-cancellation.html b/wcag22/understanding/pointer-cancellation.html new file mode 100644 index 0000000..450946a --- /dev/null +++ b/wcag22/understanding/pointer-cancellation.html @@ -0,0 +1,744 @@ + + + + + + Understanding Success Criterion 2.5.2: Pointer Cancellation | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.5.2:Pointer Cancellation (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Reduce accidental activation of controls by mouse or touch.
+ +
What to do
+
Make pointer cancellation predictable and consistent.
+ +
Why it's important
+
Make it easier for anyone to recover from something they didn’t mean to do.
+ +
+
+
+

Intent

+

The intent of this success criterion is to make it easier for users to prevent accidental + or erroneous pointer input. People with various disabilities can inadvertently initiate + touch or mouse events with unwanted results. Each of the following subsections roughly + aligns with the bullets of this Success Criterion, and outlines a means of allowing + users to cancel pointer operations. +

+
+ +

Up-Event activation or completion

+ +

The most accessible way to incorporate pointer cancellation is to make activation + occur on the up-event. +

+ + +

Up-event activation refers to the activation of a target when the pointer is released. + In a touchscreen interaction, when the finger touches a target, the up-event activation + only occurs when the finger is lifted while still being within the target boundary. + Similarly in mouse interaction, the up-event occurs when the mouse button is released + while the cursor is still within the boundary of the initial target set when the mouse + button was pressed. +

+ +

Authors can reduce the problem of users inadvertently triggering an action by using + generic platform activation/click events that activate functionality on the up-event. + For example, the click event in JavaScript triggers on release of the primary mouse button, and is an example + of an implicit up-event. Despite its name, the click event is device-independent and also works for touch and keyboard interaction. +

+ +

The preference for up-events is implicit in the Success Criterion wording of the first + bullet: The down-event of the pointer is not used to execute any part of the function. Authors meet the first bullet by using only the up-event. +

+ +
+
+ +

Up-Event Abort or Undo

+ +

Where the interaction is equivalent to a simple "click", up-event activation has a + built-in ability to cancel. There is a distinction between when someone touches a + screen and when they remove their finger. Similarly, in mouse interaction, there is + a difference between pressing and releasing the mouse button. When activation occurs + only as the pointer is released, users have the opportunity to Abort (cancel) the + activation. Users who have difficulty accurately using a mouse or touchscreen benefit + greatly from this basic behaviour. They normally receive visual feedback when an item + is pressed. If they discover they have selected the wrong item, they can cancel the + action by moving their pointer or finger away from the target before releasing. +

+ + +

For more complex interactions, such as drag and drop, the down- and up-events may + initiate and end a series of actions to complete a process. For example, with drag + and drop, the item may be: +

+ +
    + +
  1. selected with a press (down-event),
    2. + +
  2. moved to a new location, while still being depressed, and
    3. + +
  3. released (up-event) to conclude the drop action.
    4. + +
+ +

In such a complex action, the need for an Abort or Undo function increases. Designers + may elect to confirm the move through something like a confirmation dialog or an undo + button, giving the user the ability to Undo the process just completed. Alternatively, + the ability to Abort the action can be achieved if, before completing step 3, the + user returns the selected item to its original location and concludes the process + there. If other parts of the screen disallow a move, the user can conclude the drag + and drop there, effectively nullifying the operation. +

+ +
+
+ +

Up Reversal

+ +

In other interactions, the down-event may trigger a behaviour which can be reversed + when the up-event concludes. Examples of this include press-and-hold actions such + as where a transient popup appears (or a video plays) when the user presses on an + object (down-event), but the popup (or video) disappears as soon as the user releases + the pointer (up-event). Since the up-event reverses the preceding down event, the + user is returned to their prior point, and has effectively cancelled the operation. +

+ +
+
+ +

Down-Event

+ +

Completing the function on the down-event is only permitted when it is essential that + the up-event not be used. +

+ +

The most prevalent essential down-event activation occurs in keyboard emulation. On + a physical keyboard, keys by default activate on the down-event -- a letter appears + when the key is pressed. If a software keyboard emulator tried to override this expected + behaviour by making letters appear when the key is released, the behaviour would be + unexpected and would adversely affect expected interaction. +

+ +

Note that a keyboard has a built-in Backspace or Delete button, which effectively + provides an Undo option. Undo is not a requirement of the down-event Essential exception; + however, providing an easy way for users to undo any action is a recommended practice + (and may be a functional necessity), even where it is not a requirement of this Success + Criterion. +

+ +

Other examples where the timing of an activation is essential and requires the down-event + would be: +

+ +
    + +
  • An activity that emulates a physical on-press trigger, such as when playing an on-screen + piano keyboard. Activation on the up-event would significantly alter the desired behaviour. +
    • + +
  • A program for shooting skeets where waiting for the "up" event would invalidate the + precise timing necessary for the activation. +
    • + +
+ +
+
+
+

Benefits

+
    + +
  • Makes it easier for all users to recover from hitting the wrong target.
    • + +
  • Helps people with visual disabilities, cognitive limitations, and motor impairments + by reducing the chance that a control will be accidentally activated or an action + will occur unexpectedly, and also ensures that where complex controls are activated, + a means of Undoing or Aborting the action is available. +
    • + +
  • Individuals who are unable to detect changes of context are less likely to become + disoriented while navigating a site. +
    • + +
+
+
+

Examples

+
    + +
  • For interface elements that have a single tap or long press as input, the corresponding + event is triggered when the finger is lifted inside that element. +
    • + + +
  • A drag-and-drop interface allows users to sort vertically stacked cards by picking + up one card with the pointer (down-event), move it to a new position, and insert it + at the new location when the pointer is released (up-event). Releasing the pointer + outside the drop target area reverts the action, i.e., it moves the card back to the + old position before the interaction started. +
    • + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
down-event
+
+ + +

platform event that occurs when the trigger stimulus of a pointer is depressed

+ +

The down-event may have different names on different platforms, such as "touchstart" + or "mousedown". +

+ + +
+
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
functionality
+
+ + + +

+ processes and outcomes achievable through user action + +

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
single pointer
+
+ + + +

pointer input that operates with one point of contact with the screen, including single + taps and clicks, double-taps and clicks, long presses, and path-based gestures +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
up-event
+
+ + +

platform event that occurs when the trigger stimulus of a pointer is released

+ +

The up-event may have different names on different platforms, such as "touchend" or + "mouseup". +

+ + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/pointer-gestures.html b/wcag22/understanding/pointer-gestures.html new file mode 100644 index 0000000..987e03e --- /dev/null +++ b/wcag22/understanding/pointer-gestures.html @@ -0,0 +1,524 @@ + + + + + + Understanding Success Criterion 2.5.1: Pointer Gestures | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.5.1:Pointer Gestures (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Let users operate touchscreens with one finger and reduced gestures.
+ +
What to do
+
Provide single-point operation for all functions.
+ +
Why it's important
+
Not everyone can perform complex and multi-touch gestures.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that content can be controlled with + a range of pointing devices, abilities, and assistive technologies. Some people cannot + perform gestures in a precise manner, or they may use a specialized or adapted input + device such as a head pointer, eye-gaze system, or speech-controlled mouse emulator. + Some pointing methods lack the capability or accuracy to perform multipoint or path-based + gestures. +

+

A path-based gesture involves an interaction where not just the endpoints matter, but how the pointer + moves between these points. +

+

If the gesture is only recognised if the user moves in a (mostly) straight line from + the start point to the end point, it is an example of a path-based gesture. +

+
+ Hand showing a starting touch, 1. Moving in a straight line to a second point, 2. + +
Figure 1 A path-based gesture where pointer movement is only allowed in a straight line from the start-point to + the end-point. If the user strays from the straight directional path, the gesture + is not recognised, has no effect, or is aborted. +
+ +
+

If going through an intermediate point (usually near the start of the gesture) affects + its meaning, then it is a path-based gesture. The user engages a pointer (starting point), carries out a movement that goes through + at least one intermediate-point before disengaging the pointer (end point). The intermediate + point defines the gesture as requiring a specific path, even if the complete path + is not defined. +

+
+ Hand showing a starting touch, 1. Moving through a second point, 2. Going to one of several points,3. + +
Figure 2 A path-based gesture involves starting a pointer movement that goes through at least one intermediate + point before the end-point. The end-point may be a continuation, or allow for various + movements. +
+ +
+

Examples of path-based gestures include swiping, sliders and carousels dependent on + the direction of interaction, and other gestures which trace a prescribed path such + as drawing a specific shape. Such paths may be drawn with a finger or stylus on a + touchscreen, graphics tablet, or trackpad, or with a mouse, joystick, or similar pointer + device. +

+

Dragging is a movement where the user picks up an object with a pointer (such as mouse + cursor or a finger) and moves it to some other position. This movement from start + point to end point does not require the user to follow any particular path or direction. + Dragging is therefore not path-based. In contrast, a path-based pointer gesture requires + the traversal of an intermediate point, which is a technical way of expressing that + the directionality and possibly speed of the gesture communicates a particular command + to the system. Dragging motions are covered in Success Criterion 2.5.7: Dragging. +

+
+ Hand showing a starting touch, 1. Going to a second point, 2. It follows a very random path. + +
Figure 3 A free-form gesture does not require any particular path before the end-point, only the start and (optionally) + the end point matter. This is not path-based
+ +
+
+

Note

+

Any movement of a pointer could be difficult or impossible to use for someone who + cannot perform precise movements, therefore alternative forms of interaction are always + recommended. This success criterion is scoped to path-based gestures as it may be difficult or impossible to provide an alternative for free-form gestures. +

+
+

Examples of multipoint gestures include a two-finger pinch zoom, a split tap where one finger rests on the + screen and a second finger taps, or a two- or three-finger tap or swipe. Users may + find it difficult or impossible to accomplish these if they type and point with a + single finger or stick. +

+

Authors must ensure that their content can be operated without multipoint or path-based + gestures. Multipoint or path-based gestures can be used so long as the functionality + can also be operated by another method, such as a tap, click, double tap, double click, + long press, or click & hold. +

+

This Success Criterion applies to gestures in the author-provided content, not gestures + defined by the operating system, user agent, or assistive technology. Examples of + operating system gestures would be swiping down to see system notifications and gestures + for built-in assistive technologies (AT). Examples of user agent-implemented gestures + would be horizontal swiping implemented by browsers for navigating within the page + history, or vertical swiping to scroll page content. +

+

There are times when a component requires a path-based gesture for touch screen devices + but not with a mouse. Taking an example of a generic slider: +

+
    + +
  • Using a mouse: If the user clicks on the thumb control of the slider and moves vertically, the slider + will respond by moving to the right or left, even if the movement is mostly upwards. + There will be no page scrolling as a result of the vertical movement as long as they + drag with focus on the slider. Therefore, the slider does not require a path-based + gesture with mouse pointer. +
    • + +
  • Using a touch-screen: If the user puts their finger on the thumb control of the slider and moves upwards + more than sideways, the slider may not respond because the browser takes control of + the swipe and interprets it as a scroll, and will move the page up and down. Moving + left or right on the slider thumb engages the slider and then the user can vary their + vertical movement. This implementation has the 3-point requirement to work with a + finger on a touch screen device so is a path-based gesture. +
    • + +
+

As touch screen devices can apply default gestures it is important to test with them + if you are unsure whether a particular component does require a path-based gesture. +

+

Browsers on a touch screen device generally provide some default gestures that impact + whether a path-based gesture is needed. For example, a web browser on a touch-screen + devices might detect a vertical gesture and scroll the page. If a user places their + finger on a slider thumb and moves up (to scroll down) that might not activate the + slider (depending on implementation). If the user moves horizontally first then the + slider could capture that gesture and ignore vertical movement, resulting in a path-based + gesture. If you include touch-screen devices as accessibility supported then these + types of interaction need testing with a touch screen as using a mouse in a similar + way would not trigger the same browser behavior. +

+

This Success Criterion does not require all functionality to be available through + pointing devices, but if it is available to pointer devices then it should not require + path-based gestures. While content authors generally need to provide keyboard commands + or other non-pointer mechanisms that perform actions equivalent to complex gestures + (see Success Criterion 2.1.1 Keyboard), this is not sufficient to conform to this + Success Criterion. That is because some users rely entirely on pointing devices, or + find simple pointer inputs much easier to perform and understand than alternatives. + For example, a user relying on a head-pointer would find clicking a control to be + much more convenient than activating an on-screen keyboard to emulate a keyboard shortcut, + and a person who has difficulty memorizing a series of keys (or gestures) may find + it much easier to simply click on a labeled control. Therefore, if one or more pointer-based + mechanisms are supported, then their benefits should be afforded to users through + simple, single-point actions alone. +

+

Single pointer operations include taps and clicks, double-taps and double-clicks, + long presses, swiping, dragging, and path-based gestures. Gestures such as "pinch + to zoom" or two-finger swipes are multipoint gestures, as they require two or more pointer inputs - in this case, two fingers + on a touchscreen. +

+

An exception is made for functionality that is inherently and necessarily based on + complex paths or multipoint gestures. For example, entering your signature may be + inherently path-based (although acknowledging something or confirming your identity + need not be). +

+

This Success Criterion does not apply to gestures that involve dragging in any direction because only the start and end + points matter in a dragging operation. However, such gestures do require fine motor + control. Authors are encouraged to provide non-dragging methods, for instance, a drag + and drop operation could also be achieved by selecting an item (with a tap or keyboard + interaction) and then selecting its destination as a second step. +

+
+
+

Benefits

+
    + +
  • +

    Users who cannot (accurately) perform path-based pointer gestures - on a touchscreen, + or with a mouse - will have alternative means for operating the content. +

    +
    • + +
  • +

    Users who cannot perform multi-pointer gestures on a touchscreen (for instance, because + they are operating the touchscreen with an alternative input such as a head pointer) + will have a single-pointer alternative for operating the content. +

    +
    • + +
  • +

    Users who may not understand the custom gesture interaction intended by the author + will be able to rely on simple, frequently used gestures to interact. This can be + especially beneficial for users with cognitive or learning disabilities. +

    +
    • + +
+
+
+

Examples

+
    + +
  • +

    A web site includes a map view that supports the pinch gesture to zoom into the map + content. User interface controls offer the operation using plus and minus buttons + to zoom in and out. +

    +
    • + +
  • +

    A web site includes a map view that supports the pinch gesture to zoom into the map + content. As an single-pointer alternative, the map also allows users to double-tap, + hold, and then move the pointer up or down to zoom in or out. +

    +
    • + +
  • +

    A news site has a horizontal content slider with hidden news teasers that can moved + into the viewport via a fast horizontal swipe/flicking motion. It also offers forward + and backward arrow buttons for single-point activation to navigate to adjacent slider + content. +

    +
    • + +
  • +

    A kanban widget with several vertical areas representing states in a defined process + allows the user to right- or left-swipe elements to move them to an adjacent silo. + The user can also accomplish this by selecting the element with a single tap or click, + and then activating an arrow button to move the selected element. +

    +
    • + +
  • +

    A custom slider requires movement in a strict left/right direction when operated by + dragging the thumb control. Buttons on both sides of the slider increment and decrement + the selected value and update the thumb position. +

    +
    • + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
functionality
+
+ + + +

+ processes and outcomes achievable through user action + +

+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
single pointer
+
+ + + +

pointer input that operates with one point of contact with the screen, including single + taps and clicks, double-taps and clicks, long presses, and path-based gestures +

+ + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/predictable.html b/wcag22/understanding/predictable.html new file mode 100644 index 0000000..9654a17 --- /dev/null +++ b/wcag22/understanding/predictable.html @@ -0,0 +1,225 @@ + + + + + + Understanding Guideline 3.2: Predictable | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 3.2:Predictable +

+ +
+
+

Intent

+

The intent of this Guideline is to help users with disabilities by presenting content + in a predictable order from Web page to Web page and by making the behavior of functional + and interactive components predictable. It is difficult for some users to form an + overview of the Web page: screen readers present content as a one-dimensional stream + of synthetic speech that makes it difficult to understand spatial relationships. Users + with cognitive limitations may become confused if components appear in different places + on different pages. + +

+

For example, people who use screen magnifiers see only part of the screen at any point + in time; a consistent layout makes it easier for them to find navigation bars and + other components. Placing repeated components in the same relative order within a + set of Web pages allows users with reading disabilities to focus on an area of the + screen rather than spending additional time decoding the text of each link. Users + with limited use of their hands can more easily determine how to complete their tasks + using the fewest keystrokes. + +

+
+
+

Advisory Techniques

+

Specific techniques for meeting each Success Criterion for this guideline are listed + in the understanding sections for each Success Criterion (listed below). If there + are techniques, however, for addressing this guideline that do not fall under any + of the success criteria, they are listed here. These techniques are not required or + sufficient for meeting any success criteria, but can make certain types of Web content + more accessible to more people. +

+
    + + +
  • + Positioning labels to maximize predictability of relationships + + + +
    • + + +
+
+
+

Success Criteria for this Guideline

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/pronunciation.html b/wcag22/understanding/pronunciation.html new file mode 100644 index 0000000..685bf8e --- /dev/null +++ b/wcag22/understanding/pronunciation.html @@ -0,0 +1,610 @@ + + + + + + Understanding Success Criterion 3.1.6: Pronunciation | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.1.6:Pronunciation (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can identify the pronunciation of ambiguous words.
+ +
What to do
+
Indicate how to pronounce a word, where its meaning is otherwise unclear.
+ +
Why it's important
+
Some people, including those with cognitive disabilities, may not understand the meaning + of content. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to help people who are blind, people who have + low vision, and people with reading disabilities to understand content in cases where + meaning depends on pronunciation. Often words or characters have different meanings, + each with its own pronunciation. The meaning of such words or characters can usually + be determined from the context of the sentence. However, for more complex or ambiguous + sentences, or for some languages, the meaning of the word cannot be easily determined + or determined at all without knowing the pronunciation. When the sentence is read + aloud and the screen reader reads the word using the wrong pronunciation, it can be + even more difficult to understand than when read visually. When words are ambiguous + or indeterminate unless the pronunciation is known, then providing some means of determining + the pronunciation is needed. + +

+

+ For example, in the English language heteronyms are words that are spelled the same + but have different pronunciations and meanings, such as the words desert (abandon) + and desert (arid region). If the proper pronunciation can be determined from the context + of the sentence, then nothing is required. If it cannot then some mechanism for determining + the proper pronunciation would be required. Additionally, in some languages certain + characters can be pronounced in different ways. In Japanese, for example, there are + characters like Han characters(Kanji) that have multiple pronunciations. Screen readers + may speak the characters incorrectly without the information on pronunciation. When + read incorrectly, the content will not make sense to users. + +

+
+
+

Benefits

+

This Success Criterion may help people who: + + +

+
    + + +
  • have difficulty decoding words
    • + + +
  • have difficulty using context to aid understanding
    • + + +
  • use technologies that read the words aloud
    • + + +
+
+
+

Examples

+
+ +
Giving the reading of a person's name
+ +
Web content in Japanese provides kana (Japanese phonetic syllabary characters) written + next to Han characters (Kanji) show the pronunciation of a person's name. The kana + is provided to users in parentheses right after the word. Giving the reading of the + words written in Han characters (Kanji) allows both sighted users and screen readers + to read/pronounce the words correctly. Note that screen readers will speak the word + twice: the Han characters (Kanji) that can be pronounced in a wrong way are read first + and then kana is spoken in order to provide the correct reading. +
+ +
Showing the reading of the words by ruby element
+ +
Web content using XHTML 1.1 provides kana (phonetic syllabary characters) written + above the characters to show the reading (pronunciation) of the words by using the + ruby element. +
+ +
Providing sound files of the pronunciation
+ +
A document includes some words whose meaning cannot be determined without knowing + the correct pronunciation. Each word is linked to a sound file that gives the correct + pronunciation. Users can select these links to find out how to pronounce the words. +
+ +
Including pronunciation information in the glossary
+ +
A Web page includes a glossary section. Some items in the glossary include pronunciation + information as well as definitions. Words in the content whose meaning cannot be determined + without knowing their pronunciation are linked to the appropriate entries in the glossary. +
+ +
Text that includes pronunciation information for characters shared by several languages + but pronounced differently in each language +
+ +
A Japanese university Web site includes several short phrases quoted from scholarly + texts in Chinese and Korean. The quotations are written using the same script as the + Japanese text. Pronunciation information is provided to show the correct reading of + the Chinese and Korean characters. +
+ +
+
+

Note

+
+ + +

For Japanese, the ruby element is used for showing the "reading" rather than "pronunciation." + + +

+ + +
+
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/re-authenticating.html b/wcag22/understanding/re-authenticating.html new file mode 100644 index 0000000..d819772 --- /dev/null +++ b/wcag22/understanding/re-authenticating.html @@ -0,0 +1,360 @@ + + + + + + Understanding Success Criterion 2.2.5: Re-authenticating | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.2.5:Re-authenticating (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users do not lose information or context due to reauthentication.
+ +
What to do
+
Preserve users' prior activity and data through reauthentication.
+ +
Why it's important
+
Some people may require additional time to complete an activity.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to allow all users to complete authenticated + transactions that have inactivity time limits or other circumstances that would cause + a user to be logged out while in the midst of completing the transaction. + +

+

For security reasons, many sites implement an authentication time limit after a certain + period of inactivity. These time limits may cause problems for persons with disabilities + because it may take longer for them to complete the activity. + +

+

Other sites will log a person out of a session if a person logs in on the Web site + from another computer or if other activities arise that make the site suspicious of + whether the person is still the same legitimate person who logged in originally. When + users are logged out while still in the midst of a transaction - it is important that + they be given the ability to re-authenticate and continue with the transaction without + the loss of any data already entered. + + +

+
+
+

Benefits

+
    + + +
  • This Success Criterion benefits people who may require additional time to complete + an activity. People with cognitive limitations may read slowly and require additional + time to read and respond to a questionnaire. Users interacting via a screen reader + may need extra time to navigate and complete a complicated form. + A person with motor impairments or who navigates with an alternative input device + may require additional time to navigate through or complete input within a form. + +
    • + + +
  • In circumstances where a sign-language interpreter may be relating audio content to + a user who is deaf, control over time limits is also important. + +
    • + + +
+
+
+

Examples

+
+ +
A shopping site checkout
+ +
A user with extremely limited use of the hands is logged into a shopping site. It + takes so long to enter credit card information into the application that a time limit + occurs while the user is performing the checkout process. When the user returns to + the checkout process and submits the form, the site returns a login screen to re-authenticate. + After the user logs in, the check out process is restored with the same information + and at the same stage. The user did not lose any data because the server had temporarily + accepted and stored the submission even though the session had timed out and restored + the user to the same state after re-authentication was completed. +
+ +
Authentication in an email program
+ +
An email program has an authentication time-out after 30 minutes. The program prompts + the user several minutes before the time-out occurs and provides a link to open a + new window in order to re-authenticate. The original window with the in-progress email + remains intact and, after re-authentication, the user may send that data. +
+ +
A questionnaire with a time limit
+ +
A long questionnaire provided within a single Web page has information at the beginning + that indicates that the session will time out after 15 minutes. The user is also informed + that the questionnaire can be saved at any point and completed at a later time. Within + the Web page there are several buttons provided to save the partially completed form. + In addition, with JavaScript in the list of accessibility-supported content technologies + that are relied upon, the user can elect to be alerted via a pop-up if the session + is close to timing out. +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+

Note

+
+ + +

Refer to + Techniques for Addressing Success Criterion 2.2.1 for techniques related to providing notifications about time limits. + + +

+ + +
+
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/readable.html b/wcag22/understanding/readable.html new file mode 100644 index 0000000..688066d --- /dev/null +++ b/wcag22/understanding/readable.html @@ -0,0 +1,206 @@ + + + + + + Understanding Guideline 3.1: Readable | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 3.1:Readable +

+ +
+
+

Intent

+

The intent of this guideline is to allow text content to be read by users and by assistive + technology, and to ensure that information necessary for understanding it is available. + +

+

People with disabilities experience text in many different ways. For some the experience + is visual; for some it is auditory; for some it is tactile; for still others it is + both visual and auditory. Some users experience great difficulty in recognizing written + words yet understand extremely complex and sophisticated documents when the text is + read aloud, or when key processes and ideas are illustrated visually or interpreted + as sign language. For some users, it is difficult to infer the meaning of a word or + phrase from context, especially when the word or phrase is used in an unusual way + or has been given a specialized meaning; for these users the ability to read and understand + may depend on the availability of specific definitions or the expanded forms of acronyms + or abbreviations. User agents, including speech-enabled as well as graphical applications, + may be unable to present text correctly unless the language and direction of the text + are identified; while these may be minor problems for most users, they can be enormous + barriers for users with disabilities. In cases where meaning cannot be determined + without pronunciation information (for example, certain Japanese Kanji characters), + pronunciation information must be available as well + +

+
+
+

Success Criteria for this Guideline

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/reading-level.html b/wcag22/understanding/reading-level.html new file mode 100644 index 0000000..e597b7a --- /dev/null +++ b/wcag22/understanding/reading-level.html @@ -0,0 +1,959 @@ + + + + + + Understanding Success Criterion 3.1.5: Reading Level | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.1.5:Reading Level (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can get a simplified version of complex information.
+ +
What to do
+
When text information becomes complex, create a more easily understood version.
+ +
Why it's important
+
More people, especially those with cognitive disabilities, can understand the meaning + of content. +
+ +
+
+
+

Intent

+

+ Content should be written as clearly and simply as possible. The intent of this Success + Criterion is: + +

+
    + + +
  • to ensure that additional content is available to aid the understanding of difficult + or complex text; + +
    • + + +
  • to establish a testable measure indicating when such additional content is required.
    • + + +
+

This Success Criterion helps people with reading disabilities while also allowing + authors to publish difficult or complex Web content. Text difficulty is described + in terms of the level of education required to read the text. Education levels are + defined according to the International Standard Classification of Education [[UNESCO]], + which was created to allow international comparison among systems of education. + + +

+

Difficult or complex text may be appropriate for most members of the intended audience + (that is, most of the people for whom the content has been created). But there are + people with disabilities, including reading disabilities, even among highly educated + users with specialized knowledge of the subject matter. It may be possible to accommodate + these users by making the text more readable. If the text cannot be made more readable, + then supplemental content is needed. Supplemental content is required when text demands + reading ability more advanced than the lower secondary education level—that is, more + than nine years of school. Such text presents severe obstacles to people with reading + disabilities and is considered difficult even for people without disabilities who + have completed upper secondary education. + +

+

Reading disabilities such as dyslexia make it difficult to recognize written or printed + words and associate them with the correct sounds. This is called "decoding" the text. + Decoding must be automatic in order for people to read fluently. The act of decoding + text word by word consumes much of the mental energy that most people are able to + use for understanding what they read. + Text that uses short, common words and short sentences is easier to decode and usually + requires less advanced reading ability than text that uses long sentences and long + or unfamiliar words. + +

+

The education level required to read text content (also called "readability") is measured + by analyzing selected passages of text from the Web page. If the Web page includes + text written for different purposes or different styles are used, the selected passages + include samples of the types of content in the Web page and the different styles in + which the content is written. (In many cases, the Web page contains only one kind + of text content—e.g., technical documentation, a legal notice, marketing material, + etc.—and all the content uses the same style.) + +

+

Educators can also measure the education level required to read text content. For + example, qualified teachers can evaluate text according to local education standards + to determine if it requires reading ability beyond what is expected for students in + the last year of lower secondary education. + +

+

Because people's names, the names of cities or other proper names cannot be changed + to shorter names with fewer syllables, and because doing so or just referring to everyone + by pronouns can make sentences harder to understand, the success criterion specifies + that proper names can be ignored or removed from the text before assessing whether + it meets the reading ability requirement. Titles refer to the name of documents, books, + movies, etc. Titles are removed or ignored for the analysis because changing the words + in titles might make the titles easier to read but would make it impossible to understand + the item to which the title refers. This would make it harder to read and understand + the content. (e.g., a book, academic paper, article, etc.). Therefore, titles are + also exempted specifically. + +

+

When a Web page contains multiple languages, a readability result should be calculated + for each language that constitutes at least 5% of the content and that is used in + full sentences or paragraphs (not just individual words or phrases). The overall readability + of the page should be judged on the language that yields the worst readability results. + + +

+

The readability of content may also be determined by applying a readability formula + to the selected passage. Many (though not all) readability formulas base their calculations + on passages of 100 words. Such formulas have been developed for many languages. The + number of words in the passage is counted and the length of the words is determined + by counting either the number of syllables or the number of characters. Most readability + formulas also count the number and length of sentences. The average length of words + and sentences in the content is then used to calculate a readability score. (Some + languages, such as Japanese, may include multiple scripts within the same passage. + Readability formulas for these languages may use the number and length of such "runs" + in their calculations.) The result may be presented as a number (for example, on + a scale from 0-100) or as a grade level. These results can then be interpreted using + the education levels described in the International Standard Classification of Education. + Readability formulas are available for at least some languages when running the spell + checkers in popular software if you specify in the options of this engine that you + want to have the statistics when it has finished checking your documents. + +

+
+ +
Primary education
+ +
First 6 years of school
+ +
Lower secondary education
+ +
7-9 years of school
+ +
Upper secondary education
+ +
10-12 years of school
+ +
Advanced education
+ +
More than 12 years of school
+ +
+

Adapted from International Standard Classification of Education (UNESCO). +

+
+

Note

+
+ + +

According to the Open Society Mental Health Initiative, the concept of Easy to Read + cannot be universal, and it will not be possible to write a text that will suit the + abilities of all people with literacy and comprehension problems. Using the clearest + and simplest language appropriate is highly desirable, but the WCAG Working Group + could not find a way to test whether this had been achieved. The use of reading level + is a way to introduce testability into a Success Criterion that encourages clear writing. + Supplementary content can be a powerful technique for people with some classes of + cognitive disability. + + +

+ + +
+
+
+
+

Benefits

+

This Success Criterion may help people who:

+
    + + +
  • Have difficulty comprehending and interpreting written language (e.g., articles, instructions, + or newspapers in text or braille), for the purpose of obtaining general knowledge + or specific information + +
    • + + +
+
+
+

Examples

+
+ +
A scientific journal including readable summaries of complex research articles
+ +
A scientific journal includes articles written in highly technical language aimed + at specialists in the field. The journal's Table of Contents page includes a plain-language + summary of each article. The summaries are intended for a general audience with eight + years of school. The metadata for the journal uses the Dublin Core specification to + identify the education level of the articles' intended audience as "advanced," and + the education level of the intended audience for the summaries as "lower secondary + education." +
+ +
Medical information for members of the public
+ +
A medical school operates a Web site that explains recent medical and scientific discoveries. + The articles on the site are written for people without medical training. Each article + uses the Dublin Core metadata specification to identify the education level of the + intended audience as "lower secondary education" and includes the Flesch Reading Ease + score for the article. A link on each page displays the education level and other + metadata. No supplemental content is required because people who read at the lower + secondary education level can read the articles. +
+ +
An e-learning application
+ +
An on-line course about Spanish cultural history includes a unit on Moorish architecture. + The unit includes text written for students with different reading abilities. Photographs + and drawings of buildings illustrate architectural concepts and styles. Graphic organizers + are used to illustrate complex relationships, and an audio version using synthetic + speech is available. The metadata for each version describes the academic level of + the content and includes a readability score based on formulas developed for Spanish-language + text. The learning application uses this metadata and metadata about the students + to provide versions of instructional content that match the needs of individual students. +
+ +
Science information that requires a reading ability at the lower secondary education + level +
+ +
+ +

The text below (116 words total) requires a reading ability of grade 4.2 in the United + States according to the Flesch-Kincaid formula. In the US, grade 4.2 is at the primary + education level. +

+ +

Science is about testing — and about looking closely. Some scientists use microscopes + to take a close look. We're going to use a simple piece of paper. +

+ +

Here's what you do: Print this page and cut out the square to make a "window" one + inch square. (It's easiest to fold the page in half before you cut.) +

+ +

Choose something interesting: a tree trunk, a leaf, flower, the soil surface, or a + slice of soil from a shovel. +

+ +

Put your window over the thing and look at it closely. Take your time — this is not + a race. +

+ +

To help you see more details, draw a picture of what's inside your square.

+ +

Now let's think about what you've found.

+ +

(Source: Howard Hughes Medical Institute "CoolScience for Kids" Project)

+ +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+

Note

+
+ + +

Different sites may address this Success Criterion in different ways. An audio version + of the content may be helpful to some users. For some people who are deaf, a sign + language version of the page may be easier to understand than a written language version + since sign language may be their first language. + Some sites may decide to do both or other combinations. No technique will help all + users who have difficulty. So different techniques are provided as sufficient techniques + here for authors trying to make their sites more accessible. Any numbered technique + or combination above can be used by a particular site and it is considered sufficient + by the Working Group. + +

+ + +
+
+
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
lower secondary education level
+
+ + + +

the two or three year period of education that begins after completion of six years + of school and ends nine years after the beginning of primary education + +

+ + +
+

Note

+

This definition is based on the International Standard Classification of Education + [[UNESCO]]. + +

+
+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
primary education level
+
+ + + +

six year time period that begins between the ages of five and seven, possibly without + any previous education + +

+ + +
+

Note

+

This definition is based on the International Standard Classification of Education + [[UNESCO]]. + +

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
supplemental content
+
+ + + +

additional content that illustrates or clarifies the primary content + +

+ + + + + + + + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/redundant-entry.html b/wcag22/understanding/redundant-entry.html new file mode 100644 index 0000000..1433c43 --- /dev/null +++ b/wcag22/understanding/redundant-entry.html @@ -0,0 +1,418 @@ + + + + + + Understanding Success Criterion 3.3.7: Redundant Entry | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.3.7:Redundant Entry (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Make it easier for users to complete multi-step processes.
+ +
What to do
+
Don't ask for the same information twice in the same session.
+ +
Why it's important
+
Some people with cognitive disabilities have difficulty remembering what they entered + before. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that users can successfully complete + multi-step processes. It reduces cognitive effort where information is asked for more + than once during a process. It also reduces the need to recall information provided + in a previous step. +

+

Information that is required to be remembered for input can pose a significant barrier + to users with cognitive or memory difficulties. All users experience a natural gradual + mental fatigue as they proceed through steps in a process. This fatigue is accelerated + by the stress of recalling information from short-term working memory. Users with + learning, and cognitive disabilities are highly susceptible to mental fatigue. +

+

Requiring people to recall information previously entered can cause them to give up + or re-enter the same information incorrectly. The autocomplete feature of browsers + is not considered sufficient because it is the content (the web site) that needs to + provide the stored information for a redundant entry, or avoid asking for the same + information again. +

+

This Success Criterion does not add a requirement to store information between sessions. + A process is defined on the basis of an activity and is not applicable when a user returns + after closing a session or navigating away. However, a process can run across different + domains, so if a check-out process includes a 3rd party payment provider, that would + be in scope. +

+

The term "available to select" is not prescriptive. The term allows authors to develop + techniques where auto-population is not possible. It can include allowing the user + to: +

+
    + +
  • select and populate a field, including from a drop-down;
    • + +
  • select text from the page and copy it into an input;
    • + +
  • tick a checkbox to populate inputs with the same values as previously entered (e.g., + my billing address is the same as my shipping address). +
    • + +
+

Data which is "available to select" would need to be on the same page. Ideally, it + would be visible by default and closely associated with the input where the data is + required. However, it could be elsewhere on a page, including within a show/hide component. +

+

This Success Criterion does not apply if data is provided by the user with a different + method, such as uploading a resume in a document format. +

+

This Success Criterion does not impact Accessible Authentication (Minimum), for which allowing auto-filling of passwords is a sufficient technique. In that + case the filling is performed by the user's browser. Redundant Entry is asking for + the website content to make the previous entry available, but not between sessions + or for essential purposes such as asking for a password. +

+

This criterion does not include requirements or exceptions specific to privacy or + personally identifiable information (PII), but when implementing techniques such as + auto-population, authors should ensure data protection when storing information even + temporarily during a process. It is possible to eliminate redundant entry in ways + that do not introduce additional privacy risks, but it is also possible that a poor + implementation (for meeting this criterion) could leak additional PII. +

+

There are exceptions for:

+
    + +
  • Essential uses of input re-entry for things like memory games which would be invalidated + if the previous answers were supplied. +
    • + +
  • Security measures such as preventing a password string from being shown or copied. + When creating a password, it should be a unique and complex string and therefore cannot + be validated by the author. If the system requires the user to manually create a password + that is not displayed, having users re-validate their new string is allowed as an + exception. +
    • + +
  • When the previously entered information is no longer valid, it can be requested that + the user enter that information again. +
    • + +
+
+
+

Benefits

+
    + +
  • Users with cognitive disabilities experience short-term, working memory difficulty. + Not having to repeatedly remember particular information reduces stress and the likelihood + of mistakes. +
    • + +
  • Users who experience difficulty forming new memories, recalling information, and other + functions related to cognition can complete processes without having to unnecessarily + rely on their memory. +
    • + +
  • Users with mobility impairments, for example using switch control or voice input, + benefit from a reduced need for text entry. +
    • + +
+
+
+

Examples

+
    + +
  • A form requests the user’s corporate identification number (ID) in the first step + of a process to purchase a new computer. In the 3rd step the user is asked to confirm + that the computer will belong to the user (rather than a colleague), and re-shows + the ID. It allows the user to change the ID, but defaults to the previously entered + one. +
    • + +
  • A form on an e-commerce website allows the user to confirm that the billing address + and delivery address are the same address. +
    • + +
  • A search results page pre-fills the search input with the previously entered search + term in the same process. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+
+
+ +

Key Terms

+ +
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/refer-to-wcag.html b/wcag22/understanding/refer-to-wcag.html new file mode 100644 index 0000000..8d96f0f --- /dev/null +++ b/wcag22/understanding/refer-to-wcag.html @@ -0,0 +1,318 @@ + + + + + + How to Refer to WCAG from Other Documents | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

How to Refer to WCAG from Other Documents

+
+ + +

The following examples show how to reference WCAG 2.1 in various situations. For additional + guidance, see Referencing and Linking to WAI Guidelines and Technical Documents. +

+ +

Please note that the following language for referencing WCAG 2.1 can be inserted + into your own documents. +

+ +
+ +

Information references

+ +

When referencing WCAG 2.1 in an informational fashion, the following format can be + used. +

+ +

Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation + XX Month Year (https://www.w3.org/TR/YYYY/REC-WCAG21-YYYYMMDD/, Latest version at + https://www.w3.org/TR/WCAG21/)

+ +
+ +
+ +

When referring to WCAG 2.1 from another standard with a "should" statement

+ +

When referencing WCAG 2.1 from within a should statement in a standard (or advisory statement in a regulation), then the full WCAG + 2.1 should be referenced. This would mean that all three levels of WCAG 2.1 should + be considered but that none are required. The format for referencing WCAG 2.1 from + a "should" statement therefore, is: +

+ +

Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation + XX Month Year. (https://www.w3.org/TR/YYYY/REC-WCAG21-YYYYMMDD/)

+ +
+ +
+ +

When referring to WCAG 2.1 from another standard with a "shall or must" statement

+ +

When citing WCAG 2.1 as part of a requirement (e.g., a shall or must statement in a standard or regulation), the reference must include the specific parts + of WCAG 2.1 that are intended to be required. When referencing WCAG 2.1 in this manner, + the following rules apply: +

+ +
    + +
  1. + +

    Conformance at any level of WCAG 2.1 requires that all of the Level A Success Criteria + be met. References to WCAG 2.1 conformance cannot be for any subset of Level A. +

    + +
    2. + +
  2. + +

    Beyond Level A, a "shall or must" reference may include any subset of provisions in + Levels AA and AAA. For example, "all of Level A and [some specific list of Success Criteria in Level AA and Level AAA]" be met. +

    + +
    3. + +
  3. + +

    If Level AA conformance to WCAG 2.1 is specified, then all Level A and all Level AA + Success Criteria must be met. +

    + +
    4. + +
  4. + +

    If Level AAA conformance to WCAG 2.1 is specified, then all Level A, all Level AA, + and all Level AAA Success Criteria must be met. +

    + +

    Note 1: It is not recommended that Level AAA conformance ever be required for entire sites + as a general policy because it is not possible to satisfy all Level AAA Success Criteria + for some content. +

    + +

    Note 2: The sets of Success Criteria defined in WCAG are interdependent and individual Success + Criteria rely on each other's definitions in ways which may not be immediately obvious + to the reader. Any set of Success Criteria must include all of the Level A provisions. +

    + +
    5. + +
+ +
+ +
+ +

Examples

+ +

To cite only the Level A Success Criteria (Single-A conformance):

+ +

Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation + XX Month Year, Level A Success Criteria. (https://www.w3.org/TR/YYYY/REC-WCAG21-YYYYMMDD/)

+ +

To cite the Levels A and AA Success Criteria (Double-A conformance):

+ +

Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation + XX Month Year, Level A & Level AA Success Criteria. (https://www.w3.org/TR/YYYY/REC-WCAG21-YYYYMMDD/)

+ +

To cite Level A Success Criteria and selected Success Criteria from Level AA and Level + AAA:

+ +

Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation + XX Month Year, Level A Success Criteria plus Success Criteria 1.x.x, 2.y.y, … 3.z.z. + (https://www.w3.org/TR/YYYY/REC-WCAG21-YYYYMMDD/)

+ +

Example of use of a WCAG reference in a "shall or must" statement.

+ +

All Web content on publicly available Web sites shall conform to Web Content Accessibility + Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level + A Success Criteria plus Success Criteria 1.2.3, 2.4.5-6, 3.1.2 (https://www.w3.org/TR/YYYY/REC-WCAG21-YYYYMMDD/) +

+ +
+ +
+ +

Referring to content from WCAG support documents

+ +

Techniques, which are listed in Understanding WCAG 2.1 and described in other supporting + documents, are not part of the normative WCAG 2.1 Recommendation and should not be + cited using the citation for the WCAG 2.1 Recommendation itself. References to techniques + in support documents should be cited separately. +

+ +

Techniques can be cited based on the individual Technique document or on the master + WCAG 2.1 Techniques document. For example, the technique "Using alt attributes on + img elements" could be cited as +

+ +

"Using alt attributes on img elements," W3C World Wide Web Consortium Note. (URI: + {URI of technique})

+ +

or

+ +

W3C World Wide Web Consortium (200x): WCAG2.0 HTML Techniques (URI: {URI of HTML Techniques})

+ +

Techniques are not designed to be referenced as "required" from any standard or regulation.Standards and regulations should not make any specific + technique mandatory, though they may choose to recommend techniques. +

+ +
+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/reflow.html b/wcag22/understanding/reflow.html new file mode 100644 index 0000000..6883a98 --- /dev/null +++ b/wcag22/understanding/reflow.html @@ -0,0 +1,575 @@ + + + + + + Understanding Success Criterion 1.4.10: Reflow | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.10:Reflow (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Content can be enlarged without increasing line length.
+ +
What to do
+
Make lines of text reflow within the viewport.
+ +
Why it's important
+
People who need bigger text find it difficult if they must scroll to read long lines.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to support people with low vision who need + to enlarge text and read it in a single column. When the browser zoom is used to + scale content to 400%, it reflows - i.e., it is presented in one column so that scrolling + in more than one direction is not necessary. +

+

For people with low vision, both enlarging and reflowing text are critical to reading. + Enlarging text enables the perception of characters. Reflowing text enables users + to track from the end of one line to the beginning of the next line. +

+

Avoiding the need to scroll in the direction of reading in order to reveal lines that + are cut off by the viewport is important, because such scrolling significantly increases + the effort required to read. It is also important that content is not hidden off-screen. + For example, zooming into a vertically scrolling page should not cause content to + be hidden to one side. +

+
+ +

How reflow works

+ +

User agents for technologies such as HTML/CSS, PDF, and ePub have methods for reflowing + content to fit the width of the window (viewport). When appropriately authored, page + content can reflow (wrap) to stay within the window's boundaries (viewport) when users + zoom in to enlarge the size of content. Spatial relationships of content may change + when users zoom, but all information and functionality should continue to be available. +

+ +

Supporting the reflow of content is also known as 'Responsive Web Design'. It is enabled + by CSS media queries which reformat the web content for different viewport widths + (at particular break points) in order to provide optimised layouts for mobile devices + such as tablets or smartphones. Importantly, these breakpoints are not only triggered + by narrower viewports, but also when users employ the browser zoom function to zoom + into the page. +

+ +

In a desktop browser at 100% (default) scale, typical web pages that support reflow + display content in two, three or more columns. Zooming in will at some point trigger + a change of layout, so content will now be displayed in fewer columns. At a higher + magnification scale of 200% or more, content will usually be rendered in a single + column. Parts of content that were in the marginal columns, like a navigation menu + or supplementary content, will now typically appear on top of or below the main content. +

+ +
+
+ +

Viewing distance and display resolution

+ +

The value of 320 CSS pixels was chosen as a reasonable minimum size that authors can + achieve. This value lines up with the reported viewport width of small displays of + common mobile devices. The width of 320 CSS pixels exactly corresponds to a desktop + browser window set to a width of 1280px and zoomed in to 400%. It should be noted + that 400% applies to the dimension, not the area. It means four times the default + width and four times the default height. +

+ +
Diagram showing the size of character needed by viewing distance to make the same image on the retina with small screen devices close, large screen devices further away. + +
Figure 1 A letter of the same CSS pixel size on different displays with different resolutions
+ +
+ +

When we read, the size of the print is not as important as the image it projects on + the retina of our eye. Phones are designed for close viewing while desktops are designed + for viewing farther away. As a consequence 16px print on a phone is physically smaller + than 16px print on a desktop. This is not a problem because both print sizes cast + the same image on our retina if they are viewed at their intended distance. +

+ +
+
+ +

Visibility and availability of content

+ +

How much of the content is visible may change at different scales. For example, navigation + menus that are fully visible in the desktop layout are often collapsed into fewer + items, or even into a single menu button (the 'hamburger' icon pattern) so they take + up less screen space. +

+ +

The Success Criterion is met as long as all content and functionality are still fully + available - either directly, or revealed via accessible controls, or accessible via + direct links. +

+ +
+
+ + +

Content exceptions for reflow

+ +

Content which requires two-dimensional layout for usage or meaning cannot reflow without + loss of meaning, and is therefore excepted from the need to be presented without two-dimensional + scrolling. For example, graphics and video are by their nature two-dimensional. Cutting + up an image and stacking the blocks would render the content unusable. However, it + is possible to have these elements stay within the bounds of viewport even as other + content zooms to 400% (see advisory techniques). +

+ +

Data tables have a two-dimensional relationship between the headings and data cells. + This relationship is essential to convey the content. This Success Criterion therefore + exempts data tables from needing to display without scrolling in the direction of + text (e.g., horizontally in a vertically scrolling page). However, cells within data + tables are not excepted unless the cell contains types of content that also requires + two-dimensional layout for usage or meaning. +

+ +

Interfaces which provide toolbars to edit content need to show both the content and + the toolbar in the viewport. Depending on the number of toolbar buttons, the toolbar + may need to scroll in the direction of text. +

+ +
+
+ +

Responsive web design and other ways to meet this Success Criterion

+ +

Using the responsive web design approach is the most effective method of achieving + the goal of allowing people to zoom in to 400%. Each variation (CSS break point) of + the page at the same URL should conform (compare Conformance for WCAG 2.1). +

+ +

For organisations which are using legacy systems or are not able to update their layout + methods for some reason, an alternative conforming version could be a mobile site + which has a fixed 320px wide layout. The user should be able to find that version + from the default website. +

+ +
+
+ +

Avoiding scrolling in horizontally and vertically written languages

+ +

The success Criterion applies to both horizontally and vertically written languages. + Zooming the page for horizontally written languages where pages scroll vertically + by default (e.g. English) should not require horizontal scrolling. Zooming the page + for vertically written languages which scroll horizontally by default should not require + vertical scrolling. +

+ +
+
+ +

The relation of Reflow to the Success Criterion 1.4.4 Resize Text

+ +

The focus of the Reflow Success Criterion is to enable users to zoom in without having + to scroll in two directions. Success Criterion 1.4.4 Resize Text also applies, so it should be possible to increase the size of all text to at least + 200% while simultaneously meeting the reflow requirement. For most implementations, + the text is expected to continue to enlarge as the magnification increases, so that + users can magnify text up to (and beyond) 400%. In an implementation where text does + not consistently increase its size as people zoom in (such as when it is transformed + based on a media query to adapt to small-screen usage), it must still be possible + to get to 200% enlargement in order to satisfy the Resize Text criterion. +

+ +

For example, if at the default browser setting of 100% zoom, text is set at 20px when + the window is 1280px wide, the same 20px at 200% zoom would mean a text size of 200%. + At 400% zoom, the author may decide to set the text size to 10px: the text would now + still be enlarged to 200% compared to the default browser setting of 100% zoom. It + is not required to achieve 200% text enlargement at every breakpoint, but it should + be possible to get 200% text enlargement in some way. +

+ +
+
+ +

Browsers on mobile operating systems

+ +

Most browsers on mobile operating systems do not combine reflow and zoom in the same + way as on desktop browsers. These mobile browsers normally support reflow when changing + the orientation of the device -- content will be adjusted to the new viewport width. + However, these mobile browsers can only magnify content to achieve 1.4.4. Resize Text + in manners which do not constrain reflow to a single dimension, for example by using + a pinch gesture to scale up content or a double tap on a particular column to make + it fill the viewport width. This means that zoomed content in most mobile browsers + involves two-dimensional scrolling regardless of what an author does. +

+ +

Mobile user agents can offer reflow when users zoom into content, as evidenced by the Dolphin browser for + Android. The lack of magnified reflow support in browsers on mobile operating systems + can therefore be regarded as a user agent support issue. +

+ +
+
+
+

Benefits

+
    + +
  • This Success Criterion helps people with low vision who require text enlargement by + enabling them to read the content seamlessly, eliminating the necessity to scroll + in multiple directions. +
    • + +
+
+
+

Examples

+
    + +
  • + One column view in responsive design + +

    + +

    + +

    Note that as the zoom percentage increases, the navigation changes first to hide options + behind a "More" dropdown menu. As zooming continues, most navigation options are eventually + behind a "hamburger" menu button. All the information and functionality is still available + from this web page. There is no horizontal scrolling. +

    + +
    • + +
  • + PDF offering reflow + +

    In a PDF created to conform to PDF/Universal Accessibility (ISO 14289), the content + can be reflowed and zoomed in to make reading possible for someone with low-vision. +

    + +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
css pixel
+
+ + + +

visual angle of about 0.0213 degrees

+ + +

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. + This unit is density-independent, and distinct from actual hardware pixels present + in a display. User agents and operating systems should ensure that a CSS pixel is + set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [[css3-values]], which takes into account the physical dimensions of the display + and the assumed viewing distance (factors that cannot be determined by content authors). + +

+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/resize-text.html b/wcag22/understanding/resize-text.html new file mode 100644 index 0000000..2390e93 --- /dev/null +++ b/wcag22/understanding/resize-text.html @@ -0,0 +1,1058 @@ + + + + + + Understanding Success Criterion 1.4.4: Resize Text | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.4:Resize Text (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Text can be enlarged.
+ +
What to do
+
Ensure text can be doubled in size.
+ +
Why it's important
+
Some people can only read text when it is bigger.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that visually rendered text, including + text-based controls (text characters that have been displayed so that they can be + seen [vs. text characters that are still in data form such as ASCII]) can be scaled + successfully so that it can be read directly by people with mild visual disabilities, + without requiring the use of assistive technology such as a screen magnifier. Users + may benefit from scaling all content on the Web page, but text is most critical. + +

+

The scaling of content is primarily a user agent responsibility. User agents that + satisfy + UAAG 1.0 Checkpoint 4.1 allow users to configure text scale. The author's responsibility is to create Web + content that does not prevent the user agent from scaling the content effectively. + Authors may satisfy this Success Criterion by verifying that content does not interfere + with user agent support for resizing text, including text-based controls, or by providing + direct support for resizing text or changing the layout. An example of direct support + might be via server-side script that can be used to assign different style sheets. + +

+

If the author is using a technology whose user agents do not provide zoom support, + the author is responsible for providing this type of functionality directly or for + providing content that works with the type of functionality available in the user + agent. + If the user agent doesn't provide zoom functionality but does let the user change + the + text size, the author is responsible for ensuring that the content remains usable + when the text is resized. + +

+

Some user interface components that function as a label and require activation by + the user to access content are not wide enough to accommodate the label's content. + For example, in Web mail applications the subject column may not be wide enough to + accommodate every possible subject header, but activating the subject header takes + the user to the full message with the full subject header. In Web-based spreadsheets, + cell content that is too long to be displayed in a column can be truncated, and the + full content of the cell is available to the user when the cell receives focus. The + content of a user interface component may also become too wide in user interfaces + where the user can resize the column width. In this type of user interface component, + line wrapping is not required; truncation is acceptable if the component's full content + is available on focus or after user activation and an indication that this information + can be accessed, is provided to the user in some way besides the fact that it is truncated. + +

+

Content satisfies the Success Criterion if it can be scaled up to 200%, that is, up + to twice the width and height. Authors may support scaling beyond that limit, however, + as scaling becomes more extreme, adaptive layouts may introduce usability problems. + For example, words may be too wide to fit into the horizontal space available to them, + causing them to be truncated; layout constraints may cause text to overlap with other + content when it is scaled larger; or only one word of a sentence may fit on each line, + causing the sentence to be displayed as a vertical column of text that is difficult + to read. + +

+

The working group feels that 200% is a reasonable accommodation that can support a + wide range of designs and layouts, and complements older screen magnifiers that provide + a minimum magnification of 200%. Above 200%, zoom (which resizes text, images, and + layout regions and creates a larger canvas that may require both horizontal and vertical + scrolling) may be more effective than text resizing. Assistive technology dedicated + to zoom support would usually be used in such a situation and may provide better accessibility + than attempts by the author to support the user directly. + +

+
+

Note

+
+ + +

Images of text do not scale as well as text because they tend to pixelate, and therefore + we suggest using text wherever possible. It is also harder to change foreground and + background contrast and color combinations for images of text, which are necessary + for some users. + + +

+ + +
+
+

See also + 1.4.3: Visual Presentation. + +

+
+
+

Benefits

+
    + + +
  • + This Success Criterion helps people with low vision by letting them increase text + size in content so that they can read it. + + +
    • + + +
+
+
+

Examples

+
    + + +
  • + A user with vision impairments increases the text size on a Web page in a browser + from 1 em to 1.2 ems. While the user could not read the text at the smaller size, + she can read the larger text. All the information on the page is still displayed when + the larger font is used for the text. + + +
    • + + +
  • + A Web page contains a control for changing the scale of the page. Selecting different + settings changes the layout of the page to use the best design for that scale. + + +
    • + + +
  • + A user uses a zoom function in his user agent to change the scale of the content. + All the content scales uniformly, and the user agent provides scroll bars, if necessary. + + +
    • + + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
ascii art
+
+ + + +

picture created by a spatial arrangement of characters or glyphs (typically from the + 95 printable characters defined by ASCII) + +

+ + + +
+
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
audio
+
+ + + +

the technology of sound reproduction

+ + +
+

Note

+

Audio can be created synthetically (including speech synthesis), recorded from real + world sounds, or both. + +

+
+ + + +
+
audio description
+
+ + + +

narration added to the soundtrack to describe important visual details that cannot + be understood from the main soundtrack alone + +

+ + +
+

Note

+

Audio description of video provides information about actions, characters, scene changes, on-screen text, and + other visual content. + +

+
+ + +
+

Note

+

In standard audio description, narration is added during existing pauses in dialogue. + (See also extended audio description.) + +

+
+ + +
+

Note

+

Where all of the video information is already provided in existing audio, no additional audio description is necessary. + +

+
+ + +
+

Note

+

Also called "video description" and "descriptive narration."

+
+ + + +
+
captions
+
+ + + +

synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content + +

+ + +
+

Note

+

Captions are similar to dialogue-only subtitles except captions convey not only the + content of spoken dialogue, but also equivalents for non-dialogue audio information + needed to understand the program content, including sound effects, music, laughter, + speaker identification and location. + +

+
+ + +
+

Note

+

Closed Captions are equivalents that can be turned on and off with some players.

+
+ + +
+

Note

+

Open Captions are any captions that cannot be turned off. For example, if the captions + are visual equivalent images of text embedded in video. + +

+
+ + +
+

Note

+

Captions should not obscure or obstruct relevant information in the video.

+
+ + +
+

Note

+

In some countries, captions are called subtitles.

+
+ + +
+

Note

+

+ Audio descriptions can be, but do not need to be, captioned since they are descriptions of information + that is already presented visually. + +

+
+ + + +
+
extended audio description
+
+ + + +

audio description that is added to an audiovisual presentation by pausing the video so that there is time to add additional description + +

+ + +
+

Note

+

This technique is only used when the sense of the video would be lost without the additional audio description and the pauses between dialogue/narration are too short. + +

+
+ + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
image of text
+
+ + + +

text that has been rendered in a non-text form (e.g., an image) in order to achieve + a particular visual effect + +

+ + +
+

Note

+

This does not include text that is part of a picture that contains significant other visual content. + +

+
+ + + + + + +
+
non-text content
+
+ + + +

any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language + +

+ + +
+

Note

+

This includes ASCII Art (which is a pattern of characters), emoticons, leetspeak (which uses character substitution), + and images representing text + +

+
+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
text alternative
+
+ + + +

+ Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. + Programmatically associated text is text whose location can be programmatically determined + from the non-text content. + +

+ + + + + +
+

Note

+

Refer to Understanding Text Alternatives for more information. + +

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
video
+
+ + + +

the technology of moving or sequenced pictures or images

+ + +
+

Note

+

Video can be made up of animated or photographic images, or both.

+
+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/section-headings.html b/wcag22/understanding/section-headings.html new file mode 100644 index 0000000..40b8587 --- /dev/null +++ b/wcag22/understanding/section-headings.html @@ -0,0 +1,420 @@ + + + + + + Understanding Success Criterion 2.4.10: Section Headings | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.4.10:Section Headings (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users understand how content is organized in sections.
+ +
What to do
+
Where content is organized in sections, provide section headings.
+ +
Why it's important
+
People can orient themselves, especially those with cognitive or visual disabilities.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to provide headings for sections of a Web + page, when the page is organized into sections. For instance, long documents are often + divided into a variety of chapters, chapters have subtopics, etc. When such sections + exist, + they need to have headings that introduce them. This clearly indicates the organization + of the content, facilitates navigation within the content, and provides mental "handles" + that aid in comprehension of the content. Other page elements may complement headings + to improve presentation (e.g., horizontal rules and boxes), but visual presentation + is not sufficient to identify document sections. + +

+

This provision is included at Level AAA because it cannot be applied to all types + of content and it may not always be possible to insert headings. For example, when + posting a pre-existing document to the Web, headings that an author did not include + in the original document cannot be inserted. Or, a long letter would often cover different + topics, but putting headings into a letter would be very strange. However, if a document + can be broken up into sections with headings, it facilitates both understanding and + navigation. + +

+
+
+

Benefits

+
    + + +
  • People who are blind will know when they have moved from one section of a Web page + to another and will know the purpose of each section. + +
    • + + +
  • People with some learning disabilities will be able to use the headings to understand + the overall organization of the page content more easily. + +
    • + + +
  • People who navigate content by keyboard will be able to jump the focus from heading + to heading, enabling them to find quickly content of interest. + +
    • + + +
  • In pages where content in part of the page updates, headings can be used to quickly + access updated content. + +
    • + + +
+
+
+

Examples

+
    + + +
  • A menu contains different sections for different courses. Each section has a heading: + Appetizers, Salad, Soup, Entree, Dessert. + +
    • + + +
  • A Web application contains a settings page that is divided into groups of related + settings. Each section contains a heading describing the class of settings. + +
    • + + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+
+
+ +

Key Terms

+ +
section
+
+ + + +

a self-contained portion of written content that deals with one or more related topics + or thoughts + +

+ + +
+

Note

+

A section may consist of one or more paragraphs and include graphics, tables, lists + and sub-sections. + +

+
+ + + +
+
user interface component
+
+ + + +

a part of the content that is perceived by users as a single control for a distinct + function + +

+ + +
+

Note

+

Multiple user interface components may be implemented as a single programmatic element. + "Components" here is not tied to programming techniques, but rather to what the user + perceives as separate controls. + +

+
+ + +
+

Note

+

User interface components include form elements and links as well as components generated + by scripts. + +

+
+ + +
+

Note

+

What is meant by "component" or "user interface component" here is also sometimes + called "user interface element". + +

+
+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/seizures-and-physical-reactions.html b/wcag22/understanding/seizures-and-physical-reactions.html new file mode 100644 index 0000000..c03a236 --- /dev/null +++ b/wcag22/understanding/seizures-and-physical-reactions.html @@ -0,0 +1,216 @@ + + + + + + Understanding Guideline 2.3: Seizures and Physical Reactions | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 2.3:Seizures and Physical Reactions +

+ +
+
+

Intent

+

Some people with seizure disorders can have a seizure triggered by flashing visual + content. Most people are unaware that they have this disorder until it strikes. In + 1997, a cartoon on television in Japan sent over 700 children to the hospital, including + about 500 who had seizures. Warnings do not work well because they are often missed, + especially by children + who may in fact not be able to read them. + +

+

The objective of this guideline is to ensure that content that is marked as conforming + to WCAG 2.0 avoids the types of flash that are most likely to cause seizure when viewed + even for a second or two. + +

+
+
+

Advisory Techniques

+

Specific techniques for meeting each Success Criterion for this guideline are listed + in the understanding sections for each Success Criterion (listed below). If there + are techniques, however, for addressing this guideline that do not fall under any + of the success criteria, they are listed here. These techniques are not required or + sufficient for meeting any success criteria, but can make certain types of Web content + more accessible to more people. +

+
    + + +
  • + Ensuring that content does not violate spatial pattern thresholds (future link) + + +
    • + + +
+
+
+

Success Criteria for this Guideline

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/sensory-characteristics.html b/wcag22/understanding/sensory-characteristics.html new file mode 100644 index 0000000..e09ff99 --- /dev/null +++ b/wcag22/understanding/sensory-characteristics.html @@ -0,0 +1,351 @@ + + + + + + Understanding Success Criterion 1.3.3: Sensory Characteristics | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.3.3:Sensory Characteristics (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Instructions are understandable by more people.
+ +
What to do
+
Describe controls by name, not just by appearance or location.
+ +
Why it's important
+
People who are blind or have low vision need non-visual instructions.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that all users can access instructions + for using the content, even when they cannot perceive shape or size or use information + about spatial location or orientation. + Some content relies on knowledge of the shape or position of objects that are not + available from the structure of the content (for example, "round button" or "button + to the right"). + Some users with disabilities are not able to perceive shape or position due to the + nature of the assistive technologies they use. + This Success Criterion requires that additional information be provided to clarify + instructions that are dependent on this kind of information. + +

+

Providing information using shape and/or location, however, is an effective method + for many users including those with cognitive limitations. + This provision should not discourage those types of cues as long as the information + is also provided in other ways. + +

+

In some languages, it is commonly understood that "above" refers to the content previous + to that point in the content and "below" refers to the content after that point. In + such languages, if the content being referenced is in the appropriate place in the + reading order and the references are unambiguous, statements such as "choose one of + the links below" or "all of the above" would conform to this Success Criterion. + +

+

WCAG was designed to apply only to controls that were displayed on a web page. The + intent was to avoid describing controls solely via references to visual or auditory + cues. When applying this to instructions for operating physical hardware controls + (e.g. a web kiosk with dedicated content), tactile cues on the hardware might be described + (e.g. the arrow shaped key, the round key on the right side). This success criterion + is not intended to prevent the use of tactile cues in instructions. + +

+
+
+

Benefits

+
    + + +
  • People who are blind and people who have low vision may not be able to understand + instructions if they rely only on a description of the shape and/or location of content. + Providing additional information in any instructions other than shape and/or location + will allow users to understand the instructions even if they cannot perceive shape + and/or location. + +
    • + + +
+
+
+

Examples

+
+ +
Example 1: Instructions for interpreting a schedule of competitive events references + colored icons in different shapes to indicate the venue for each event +
+ +
A table presents a list of times across the top row and a list of events in the first + vertical column and instructions are provided under the table: "Events marked with + a + blue diamond are played on field A and events marked with a green circle are played + on field B." The instructions rely on color and shape only and result in a failure + of + this criterion. +
+ +
Example 2: An online multi-page survey
+ +
An online multi-page survey uses a link implemented as a green arrow icon placed + in the lower right hand corner of the content to move from one survey page to the + next. The arrow is clearly labeled with "Next" and the instructions state, "To move + to the next section of the survey, select the green arrow icon labeled 'Next' in the + lower right corner below the last survey question." + The instruction uses positioning and color to help identify the icon; + the instruction does not rely on these sensory characteristics since it also refers + to + the label, so it passes this criterion. +
+ +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/sign-language-prerecorded.html b/wcag22/understanding/sign-language-prerecorded.html new file mode 100644 index 0000000..d141a07 --- /dev/null +++ b/wcag22/understanding/sign-language-prerecorded.html @@ -0,0 +1,541 @@ + + + + + + Understanding Success Criterion 1.2.6: Sign Language (Prerecorded) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.2.6:Sign Language (Prerecorded) (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Videos can be accompanied by sign language.
+ +
What to do
+
Provide sign language interpretation for audio content in existing videos.
+ +
Why it's important
+
People who are deaf or hard of hearing have more ways to understand multimedia content.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to enable people who are deaf or hard of hearing + and who are fluent in a sign language to understand the content of the audio track + of synchronized media presentations. Written text, such as that found in captions, + is often a second language. Because sign language provides the ability to provide + intonation, emotion and other audio information that is reflected in sign language + interpretation, but not in captions, sign language interpretation provides richer + and more equivalent access to synchronized media. People who communicate extensively + in sign language are also faster in sign language and synchronized media is a time-based + presentation. + + + +

+
+
+

Benefits

+
    + + +
  • People whose human language is a sign language sometimes have limited reading ability. + These individuals may not be able to read and comprehend the captions and thus require + a sign language interpretation to gain access to the synchronized media content. + +
    • + + +
+
+
+

Examples

+
    + + +
  • + + Example 1. A corporation is making an important announcement to all of its employees. The announcement + will be held in the main headquarters and later streamed to the Web. A sign language + interpreter + is provided at the announcement location for the employees that are present in the + meeting room. For the Web version of + the announcement, the sign language interpreter is shown/superimposed in the corner + of the display. + +
    • + + +
  • + + Example 2. A university is providing an online version of a particular lecture by creating + a synchronized media presentation of the professor delivering the lecture. The presentation + includes video of the professor speaking and demonstrating a science experiment. A + sign language interpretation of the lecture is created after the lecture and presented + on the Web with + the synchronized media version. + +
    • + + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+
+
+ +

Key Terms

+ +
audio
+
+ + + +

the technology of sound reproduction

+ + +
+

Note

+

Audio can be created synthetically (including speech synthesis), recorded from real + world sounds, or both. + +

+
+ + + +
+
live
+
+ + + +

information captured from a real-world event and transmitted to the receiver with + no more than a broadcast delay + +

+ + +
+

Note

+

A broadcast delay is a short (usually automated) delay, for example used in order + to give the broadcaster time to cue or censor the audio (or video) feed, but not sufficient + to allow significant editing. + +

+
+ + +
+

Note

+

If information is completely computer generated, it is not live.

+
+ + + +
+
media alternative for text
+
+ + + +

media that presents no more information than is already presented in text (directly + or via text alternatives) + +

+ + +
+

Note

+

A media alternative for text is provided for those who benefit from alternate representations + of text. Media alternatives for text may be audio-only, video-only (including sign-language + video), or audio-video. + +

+
+ + + +
+
prerecorded
+
+ + + +

information that is not live + +

+ + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
sign language interpretation
+
+ + + +

translation of one language, generally a spoken language, into a sign language + +

+ + +
+

Note

+

True sign languages are independent languages that are unrelated to the spoken language(s) + of the same country or region. + +

+
+ + + +
+
synchronized media
+
+ + + +

+ audio or video synchronized with another format for presenting information and/or with time-based + interactive components, unless the media is a media alternative for text that is clearly labeled as such + +

+ + + +
+
video
+
+ + + +

the technology of moving or sequenced pictures or images

+ + +
+

Note

+

Video can be made up of animated or photographic images, or both.

+
+ + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/slicenav.css b/wcag22/understanding/slicenav.css new file mode 100644 index 0000000..38f1e59 --- /dev/null +++ b/wcag22/understanding/slicenav.css @@ -0,0 +1,22 @@ + +/* tabbed styles - repeated here to keep cover sheets consistent with /TR/ style */ + /* Navigation styles originally from Eric Meyer */ +/* http://www.complexspiral.com/events/archive/2003/seybold/cssnav.html */ +/* Revised by Liam McGee */ +/* tabbed styles */ +#navigation, #navigationbottom {padding: 3px 0 0.5em 0; margin: 0 0.25em 0; border-bottom: 2px solid #778; float: left; width: 100%; clear: both;} +#navigation li, #navigationbottom li {list-style: none; margin: 0; display: inline; float: left; font-size: 0.8125em;} +#navigation li a, #navigationbottom li a {padding: 3px 0.5em; margin-left: 3px; border: 1px solid #778; background: #dde; text-decoration: none; float: left} +#navigation li a:link, #navigationbottom li a:link {color: #404040} +#navigation li a:visited, #navigationbottom li a:visited {color: #404040} +#navigation li a:hover, #navigationbottom li a:hover, #navigation li a:focus, #navigation li a:active {color: #000; background: #aae; border-color: #227; float: left} + + /* page contents */ +.navtoc {float:right; margin: 1.25em 0 1em 1em; border: 1px solid #aab} +.navtoc p {color: #005a9c; font-size: 0.8125em; padding: 0.25em; margin: 0; font-weight: bold} + +/* page contents highlighting and border effects */ +#navbar {padding: 0; margin: 0; font-weight: bold; background: #fff} +#navbar li {list-style: none; margin: 0; padding: 0; font-size: 0.75em} +#navbar li a {display: block; margin: 0; padding: 0.25em; border-left: 1em solid #aab; text-decoration: none; width: 100%; color: #000; border-top: solid #ccc 1px; width: 12em} +#navbar li a:hover, #navbar li a:focus, #navbar li a:active {border-color: #66c; color: #000; background: #eee} diff --git a/wcag22/understanding/status-messages.html b/wcag22/understanding/status-messages.html new file mode 100644 index 0000000..90b6186 --- /dev/null +++ b/wcag22/understanding/status-messages.html @@ -0,0 +1,1044 @@ + + + + + + Understanding Success Criterion 4.1.3: Status Messages | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 4.1.3:Status Messages (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Make users aware of important changes in content.
+ +
What to do
+
Let assistive technology notify users about status changes that don't take focus.
+ +
Why it's important
+
People who do not see messages need to be informed about them.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to make users aware of important changes in + content that are not given focus, and to do so in a way that doesn't unnecessarily + interrupt their work. +

+

The intended beneficiaries are blind and low vision users of assistive technologies + with screen reader capabilities. An additional benefit is that assistive technologies + for users with cognitive disabilities may achieve an alternative means of indicating + (or even delaying or supressing) status messages, as preferred by the user. +

+

The scope of this Success Criterion is specific to changes in content that involve + status messages. A status message is a defined term in WCAG. There are two main criteria that determine whether something + meets the definition of a status message: +

+
    + +
  • the message provides information to the user on the success or results of an action, on the waiting + state of an application, on the progress of a process, or on the existence of errors;
    • + +
  • the message is not delivered via a change in context.
    • + +
+

Information can be added to pages which does not meet the definition of a status message. + For example, the list of results obtained from a search are not considered a status + update and thus are not covered by this Success Criterion. However, brief text messages + displayed about the completion or status of the search, such as "Searching...", "18 results returned" + or "No results returned" would be status updates if they do not take focus. Examples + of status messages are given in the section titled Status Message Examples below. +

+

This Success Criterion specifically addresses scenarios where new content is added + to the page without changing the user's context. Changes of context, by their nature, interrupt the user by taking focus. They are already surfaced by + assistive technologies, and so have already met the goal to alert the user to new + content. As such, messages that involve changes of context do not need to be considered + and are not within the scope of this Success Criterion. Examples of scenarios that + add new content by changing the context are given in the section titled Examples of Changes That Are Not Status Messages below. +

+
+
+

Benefits

+
    + +
  • When appropriate roles or properties are assigned to status messages, the new content + is spoken by screen readers in such a way as to assist blind and low vision users. + Most sighted users can observe text peripherally added to the viewport. Such content + provides additional information without affecting the user's current point of regard. + The ability of an assistive technology to announce such new important text content + allows more users to benefit from an awareness of the information in an equivalent + manner. +
    • + +
  • Assigning proper roles or properties to status messages provides possible future uses + and personalization opportunities, such as the potential to be exploited by assistive + technologies created for users with some cognitive disabilities. Where page authors + elect to design additions to the screen which do not change the user's context (i.e., take focus), the information is arguably of less + importance than something presented using a modal dialog, which must be acknowledged + by the user. As such, depending on the user's preferences, an assistive technology + may choose to delay, suppress, or transform such messages so a user is not unnecessarily + interrupted; or conversely the assistive technology may highlight such messages where + the user finds it optimal to do so. +
    • + +
+
+
+

Examples

+
+ +

Status Message Examples

+ + +
    + +
  • After a user presses a Search button, the page content is updated to include the results + of the search, which are displayed in a section below the Search button. The change + to content also includes the message "5 results returned" near the top of this new + content. This text is given an appropriate role for a status message. A screen reader + announces, "Five results returned". +
    • + +
  • After a user presses an Add to Shopping Cart button, a section of content near the + Shopping Cart icon adds the text "5 items". A screen reader announces "Five items" + or "Shopping cart, five items". +
    • + +
  • After a user enters incorrect text in an input called Postal Code, a message appears + above the input reading "Invalid entry". The screen reader announces, "Invalid entry" + or "Postal code, invalid entry". +
    • + +
  • After a user activates a process, an icon symbolizing 'busy' appears on the screen. + The screen reader announces "application busy". +
    • + +
  • An application displays a progressbar to indicate the status of an upgrade. The element + is assigned a suitable role. The screen reader provides intermittent announcements + of the progress. +
    • + +
  • After a user submits a form, text is added to the existing form which reads, "Your + form was successfully submitted." The screen reader announces the same message. +
    • + +
  • After a user unsuccessfully fills in a form because some of the data is in the incorrect + format, text is added to the existing form which reads "5 errors on page". The screen + reader announces the same message. +
    • + +
  • After a user puts a photo in an album in an online photo app, a snackbar displays the message "Saved in 'Wedding' album", which is also read by a screen reader. +
    • + +
+ +
+
+ +

Examples of Status Messages that Do Not Add New Text to the Screen

+ +

This Success Criterion was intentionally worded to apply primarily when visible text + is added to (or becomes visible on) the page. The reason for this is that where new + text is displayed, it is intended to be visible to all users. By providing a programmatic + means of ensuring the text is also surfaced through assistive technologies, the Success + Criterion provides the same information to users who cannot or may not see it. However, + not all changes to content involve the addition of text to the screen. The following + are all considerations relevant to this Success Criterion: +

+ +
    + +
  • Non-displayed text specific to AT users;
    • + + +
  • Modification of status text;
    • + +
  • Removal of status text; and
    • + +
  • Non-textual status content, such as images.
    • + +
+ +
+ +

Non-displayed text specific to AT users

+ + +

There may be cases where the addition of visible text does not by itself convey sufficient + information to the user of assistive technology. For example, the proximity of new + content to other pieces of information on the screen may provide a visual context + that is lacking in the text alone. +

+ +

In such cases, authors may wish to designate additional content for inclusion in the + status message, including non-displayed text which can be provided to the assistive + technologies, for added context. Important considerations regarding the appropriate + use of such techniques are further discussed in the Sufficient Techniques. +

+ +
+ +
+ +

Modification of status text

+ +

If a status message persists on the page, modifications to this text are usually equivalent + to a new status message. An example would be a shopping cart which updates text from + reading "0 items" to "3 items". Typical methods of writing such changes in the page + content result in the entire modified text string being considered a new change, and + thus read by assistive technologies. However, where only the number in this string + was coded as an updated chunk of content, the resulting experience for screen reader + users could be to only hear "three", which may not be sufficient information to provide + context for the user. In such situations, marking the entire "3 items" string as the + status text would normally be a better solution. See Sufficient Techniques for more + discussion, including the use of aria-atomic. In this case it would also be a courtesy to add offscreen text such as "in shopping + cart" to the message. +

+ +
+ +
+ +

Removal of status text

+ +

In situations where status text is entirely removed, its absence may itself convey + information about the status. The most obvious example of this is where a message + is displayed that the system is "busy" or "waiting". For a sighted user, when this + text disappears, it is normally an indication that the state is now available. However + non-sighted users would be unaware of this change, unless the end of the waiting state + results in a change of context for the user. Where updating the visible message (e.g., + to "system available") is not feasible, the use of a non-visible status message, such + as "system available", ensures equivalent status information is provided. See Sufficient + Techniques for more discussion. +

+ +
+ +
+ +

Non-textual status content

+ +

Changes in content are not restricted to text changes. Where an icon or sound indicates + a status message, this information will be surfaced by the screen reader through a + combination of two things: 1) existing WCAG requirements governing text alternatives + (under SC 1.1.1 Non-Text Content), and 2) the requirement of this current Success + Criterion to supply an appropriate role. +

+ +
+ +
+
+ +

Examples of Changes That Are Not Status Messages

+ + +

The following examples identify situations where no additional author action is necessary. + All cases are excepted from this Success Criterion since they do not meet the definition + of "status messages." +

+ +
    + +
  • +

    An author displays an error message in a dialog.

    + +

    Since the dialog takes focus, it is defined as a change of context and does not meet + the definition of a status message. As a result of taking focus, the new change of + context is already announced by the screen reader, and thus does not need to be included + in the scope of this Success Criterion. +

    + +
    • + +
  • + +

    Content is exposed or hidden when a user interacts with a user interface component, + for example expanding components such as a menu, select, accordion or tree, or selecting + a different tab item in a tablist. +

    + +

    None of the resulting changes to content meet the definition of status messages. Further, + all components that meet the definition of a user interface component already have + requirements specified under 4.1.2 Name, Role, Value, including the need to make notifications of changes to values and states available + to user agents, including assistive technologies. As a result, changes in state, such + as "expanded" or "collapsed," would be announced by the screen reader, and thus the + user would be alerted to the 'addition' or 'removal' of content. As such, such content + does not need to be addressed by this Success Criterion. +

    + + +
    • + +
  • + +

    After a user completes a survey question which indicates they are unhappy, a series + of new questions are added to the page about customer satisfaction. +

    + +

    The new inputs do not meet the definition of status message. They do not "provide + information to the user on the success or results of an action, on the waiting state + of an application, on the progress of a process or on the existence of errors," and + so are not required to meet this Success Criterion. +

    + +
    +

    Note

    +

    Creating a status message about these questions being added, or notifying the user + in advance that content changes may take place based on the user's response, are best + practices but are not requirements in this scenario. +

    +
    + +
    • + + +
+ +
+
+ +

Other uses of live regions or alerts

+ + +

Live regions and alerts can be usefully applied in many situations where a change + of content takes place which does not constitute a status message, as defined in this + Success Criterion. However, there is a risk of making an application too "chatty" + for a screen reader user. User testing should be carried out to ensure the appropriate + level of feedback is achieved. The Advisory Techniques provide examples of how alerts + or live regions can enhance the user experience. +

+ +
+

Note

+

The purpose of this success criterion is not to force authors to generate new status + messages. Its intent is to ensure that when status messages are displayed, they are programmatically identified in a way that allows assistive technologies + to present them to the user. +

+
+ + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If a status message advises on the success or results of an action, or + the state of an application: +

+ + + +
+
+ + +

Situation B: If a status message conveys a suggestion, or a warning on the existence + of an error: +

+ + + + +
+

Note

+

Not all examples in the preceding general techniques use status messages to convey + warnings or errors to users. A role of "alert" is only necessary where a change of + context does not take place. +

+
+ + +
+
+ + +

Situation C: If a status message conveys information on the progress of a process:

+ + + +
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
changes of context
+
+ + + +

major changes that, if made without user awareness, can disorient users who are not + able to view + the entire page simultaneously + +

+ + +

Changes in context include changes of:

+ + +
    + + +
  1. + user agent; + +
    2. + + +
  2. + viewport; + +
    3. + + +
  3. focus;
    4. + + +
  4. + content that changes the meaning of the Web page + +
    5. + + +
+ + +
+

Note

+

A change of content is not always a change of context. Changes in content, such as + an expanding outline, dynamic menu, or a tab control do not necessarily change the + context, unless they also change one of the above (e.g., focus). + +

+
+ + + + + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
role
+
+ + + +

text or number by which software can identify the function of a component within Web + content + +

+ + + + + + +
+
status message
+
+ + + +

change in content that is not a change of context, and that provides information to the user on the success or results of an action, + on the waiting state of an application, on the progress of a process, or on the existence + of errors +

+ + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
viewport
+
+ + + +

object in which the user agent presents content

+ + +
+

Note

+

The user agent presents content through one or more viewports. Viewports include windows, frames, + loudspeakers, and virtual magnifying glasses. A viewport may contain another viewport + (e.g., nested frames). Interface components created by the user agent such as prompts, + menus, and alerts are not viewports. + +

+
+ + +
+

Note

+

This definition is based on User Agent Accessibility Guidelines 1.0 Glossary [[UAAG10]]. + +

+
+ + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/target-size-enhanced.html b/wcag22/understanding/target-size-enhanced.html new file mode 100644 index 0000000..67f936c --- /dev/null +++ b/wcag22/understanding/target-size-enhanced.html @@ -0,0 +1,440 @@ + + + + + + Understanding Success Criterion 2.5.5: Target Size (Enhanced) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.5.5:Target Size (Enhanced) (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Controls can be operated more easily, especially on touch screens.
+ +
What to do
+
Make custom targets at least 44 by 44 pixels.
+ +
Why it's important
+
Some people cannot tap small objects.
+ +
+
+
+

Intent

+

The intent of this success criterion is to help users who may have trouble activating + a small target because of hand tremors, limited dexterity or other reasons. If the + target is too small, it may be difficult to aim at the target. Mice and similar pointing + devices can be hard to use for these users, and a larger target will help them greatly + in having positive outcomes on the web page. +

+

Touch is particularly problematic as it is an input mechanism with coarse precision. + Users lack the same level of fine control as on inputs such as a mouse or stylus. + A finger is larger than a mouse pointer, and generally obstructs the user's view of + the precise location on the screen that is being touched/activated. +

+

The issue can be further complicated for responsive/mobile sites which need to accommodate + different types of fine and coarse inputs (e.g. a site that can be accessed both on + a traditional desktop/laptop with a mouse, as well as on a tablet or mobile phone + with a touch screen). +

+

While this criterion defines a minimum target size, it is recommended that larger + sizes are used to reduce the possibility of unintentional actions. This is particularly + relevant if any of the following are true: +

+
    + +
  • the control is used frequently;
    • + +
  • the result of the interaction cannot be easily undone;
    • + +
  • the control is positioned where it will be difficult to reach, or is near the edge + of the screen; +
    • + +
  • the control is part of a sequential task.
    • + +
+
+
+

Benefits

+
    + +
  • Users who use a mobile device where touch screen is the primary mode of interaction
    • + +
  • Users with mobility impairments, such as hand tremors
    • + +
  • Users who find fine motor movements difficult
    • + +
  • Users who access a device using one hand
    • + +
  • Users with large fingers, or who are operating the device with only a part of their + finger or knuckle +
    • + +
  • Users who have low vision may better see the target
    • + +
+
+
+

Examples

+
    + +
  • Example 1: Buttons
    + Three buttons are on-screen and the target area of each button is 44 by 44 + CSS pixels. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ +
    + +
  • Ensuring that targets are at least 44 by 44 CSS pixels.
    • + +
  • Ensuring inline links provide sufficiently large activation target.
    • + +
+ +
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+
    + +
  • none documented
    • + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+
    + +
  • Failure of success criterion 2.5.5 due to target being less than 44 by 44 CSS pixels.
    • + +
+
+
+
+
+ +

Key Terms

+ +
css pixel
+
+ + + +

visual angle of about 0.0213 degrees

+ + +

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. + This unit is density-independent, and distinct from actual hardware pixels present + in a display. User agents and operating systems should ensure that a CSS pixel is + set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [[css3-values]], which takes into account the physical dimensions of the display + and the assumed viewing distance (factors that cannot be determined by content authors). + +

+ + + +
+
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
pointer input
+
+ + + +

input from a device that can target a specific coordinate (or set of coordinates) + on a screen, + such as a mouse, pen, or touch contact + +

+ +
+

Note

+

See the Pointer Events + definition for "pointer" [[pointerevents]]. +

+
+ + + +
+
target
+
+ + + +

region of the display that will accept a pointer action, such as the interactive area + of a user interface component +

+ +
+

Note

+

If two or more targets are overlapping, the overlapping area should not be included + in the measurement of the target size, except when the overlapping targets perform + the same action or open the same page. +

+
+ + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/target-size-minimum.html b/wcag22/understanding/target-size-minimum.html new file mode 100644 index 0000000..81f50d9 --- /dev/null +++ b/wcag22/understanding/target-size-minimum.html @@ -0,0 +1,980 @@ + + + + + + Understanding Success Criterion 2.5.8: Target Size (Minimum) | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.5.8:Target Size (Minimum) (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Make controls easier to activate.
+ +
What to do
+
Ensure targets meet a minimum size or have sufficient spacing around them.
+ +
Why it's important
+
Some people with physical impairments cannot click small buttons that are close together.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to help ensure targets can be easily activated + without accidentally activating an adjacent target. Users with dexterity limitations + and those who have difficulty with fine motor movement find it difficult to accurately + activate small targets when there are other targets that are too close. Providing + sufficient size, or sufficient spacing between targets, will reduce the likelihood + of accidentally activating the wrong control. +

+

Disabilities addressed by this requirement include hand tremors, spasticity, and quadriplegia. + Some people with disabilities use specialized input devices instead of a computer + mouse or trackpad. Typically these types of input device do not provide as much accuracy + as mainstream pointing devices. Meeting this requirement also ensures that touchscreen + interfaces are easier to use. +

+
+

Note

+

This Success Criterion defines a minimum size and, if this can't be met, a minimum spacing. It is still possible to have very small, and difficult to activate, targets and + meet the requirements of this Success Criterion, provided that the targets don't have + any adjacent targets that are too close. However, using larger target sizes will help + many people use targets more easily. As a best practice it is recommended to at least meet the minimum size requirement of the Success Criterion, regardless of spacing. For important links/controls, + consider aiming for the stricter 2.5.5 Target Size (Enhanced). +

+
+
+ +

Exceptions

+ +

The requirement is for targets to be at least 24 by 24 CSS pixels in size. There are + five exceptions: +

+ + +
    + +
  • Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if + a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized + target. +
    • + +
  • Equivalent: In cases where a target does not have a size equivalent to 24 by 24 CSS pixels, but + there is another control that can achieve the underlying function that does meet the minimum size, the target can be excepted based on the "Equivalent" exception. +
    • + +
  • Inline: The Success Criterion does not apply to inline targets in sentences, or where the + size of the target is constrained by the line-height of non-target text. This exception + is allowed because text reflow based on viewport size makes it impossible for authors + to anticipate where links may be positioned relative to one another. When multiple + links are embedded in blocks of texts in smaller text sizes, guaranteeing that undersized + links in adjacent lines of text fulfill the spacing exception (their 24 CSS pixel + diameter circle don't intersect any other links or their circles) would require a + large line height which can be undesirable in many design contexts. +
    • + +
  • User agent control: Browsers have default renderings of some controls, such as the days of the month + calendar in an <input type="date">. As long as the author has not modified the user agent default, the target size for + a User agent control is excepted. +
    • + +
  • Essential: If the size and spacing of the targets is fundamental to the information being conveyed, + the Essential exception applies. For example, in digital maps, the position of pins is analogous + to the position of places shown on the map. If there are many pins close together, + the spacing between pins and neighboring pins will often be below 24 CSS pixels. It + is essential to show the pins at the correct map location, therefore the Essential + exception applies. A similar example is an interactive data visualization where targets + are necessarily dense. Another example is where jurisdictions legally require online + forms to replicate paper forms, which can impose constraints on the size of targets. + In such jurisdictions, any legal requirement to replicate small targets can be considered + essential. When the essential exception is applicable, authors are strongly encouraged + to provide equivalent functionality through alternative means to the extent practical. +
    • + +
+ +
+
+ +

Size requirement

+ + +

For a target to be "at least 24 by 24 CSS pixels", it must be possible to draw a solid + 24 by 24 CSS pixel square, aligned to the horizontal and vertical axis such that the + square is completely within the target (does not extend outside the target's area). +

+ + +
+ Three square boxes next to each other, each with a height and width of 24px + +
Figure 1 Where targets are a 24 by 24px square (and larger is better), they meet the size requirement + of the criterion and pass (image shown to scale - see the scalable original version) +
+ +
+ + +

The 24 by 24px square has to be aligned with the page, although the target itself + could be skewed. +

+ + +
+ A skewed rectangle that includes a 24 by 24px square within it. + +
Figure 2 So long as there is a solid 24 by 24px square within the target, it meets the size + requirement of the criterion and passes (image shown to scale - see the scalable original version) +
+ +
+ + +

If a target is not large enough to allow for a 24 by 24px square to be drawn inside + it, it is considered undersized, and does not pass the size requirement of the Success Criterion. However, if it + has sufficient space around it without adjacent targets, it may still pass the criterion + thanks to the spacing exception (below). +

+ + +
+ A circle with a diameter of 24px, but not filling up a 24px square. + +
Figure 3 The rounded corners do not leave sufficient space to draw a 24 by 24px square inside + the target, making the target undersized. Depending on the spacing to other targets, it may still pass if it has sufficient + clearance (image shown at 1:1 and 2:1 scale - see the scalable original version) +
+ +
+ + +

The requirement is independent of the zoom factor of the page; when users zoom in + the CSS pixel size of elements does not change. This means that authors cannot meet + it by claiming that the target will have enough spacing or sufficient size if the + user zooms into the page. +

+ + +

The requirement does not apply to targets while they are obscured by content displayed + as a result of a user interaction or scripted behavior of content, for example: +

+ + +
    + +
  • interacting with a combobox shows a dropdown list of suggestions
    • + +
  • activating a button displays a modal dialog
    • + +
  • content displays a cookie banner after page load
    • + +
  • content displays a "Take a survey" dialog after some period of user inactivity
    • + +
+ +

The requirement does however apply to targets in any new content that appears on top + of other content. +

+ + +

While the Success Criterion primarily helps touch users by providing target sizing + to prevent accidental triggering of adjacent targets, it is also useful for mouse + or pen users. It reduces the chances of erroneous activation due to either a tremor + or reduced precision, whether because of reduced fine motor control or input imprecision. +

+ + +
+
+ +

Spacing

+ + +

When the minimum size for a target is not met, spacing can at least improve the user + experience. There is less chance of accidentally activating a neighboring target if + a target is not immediately adjacent to another. Touchscreen devices and user agents + generally have internal heuristics to identify which link or control is closest to + a user's touch interaction - this means that sufficient spacing between targets can + work as effectively as a larger target size itself. +

+ + +

When a target is smaller than 24 by 24 CSS pixels, it is undersized. In this case, we check if it at least has sufficient spacing by drawing a 24 CSS pixel diameter circle over the undersized target, centered on + the target's bounding box. For rectangular targets, the bounding box coincides with the target itself – thus, + the circle is placed on the center of the target. If the target is not rectangular – for instance, if the target is clipped, has rounded corners, or if + it's a more complex clickable SVG shape – we need to first determine the bounding + box, and then find the box's center. Note that for concave shapes, the center of the + bounding box may be outside of the target itself. Now, we center the circle on the + center of the bounding box. +

+ + +
+ Three undersized targets - a square target, a convex target, and a concave target; the concave and convex targets have a bounding box around them; all three targets have a 24 CSS pixel circle centered on the center of their bounding box + +
Figure 4 For a square/rectangular target, the 24 CSS pixel diameter circle is centered on the + target itself. For convex and concave targets, it is centered on the bounding box + of the shape. Note the concave target, where in this case the center of the bounding + box is outside of the actual target (image shown to scale - see the scalable original version) +
+ +
+ + +

We repeat this process for all adjacent undersized targets. To determine if an undersized + target has sufficient spacing (to pass this Success Criterion's spacing exception), + we check that the 24 CSS pixel diameter circle of the target does not intersect another + target or the circle of any other adjacent undersized targets. +

+ + +

The following example shows three versions of a horizontal row of six icon-based buttons. + In the top row, the dimensions of each target are 24 by 24 CSS pixels, passing this + Success Criterion. In the second row, the same targets are only 20 by 20 CSS pixels, + but have a 4 CSS pixel space between them – as the target size is below 24 by 24 CSS + pixels, these need to be evaluated against the Success Criterion's spacing exception, + and they pass. In the last row, the targets are again 20 by 20 CSS pixels, but have + no space between them – these fail the spacing exception, because when drawing the + 24 CSS pixel diameter circles over the targets, the circles intersect. +

+ + +
+ The first toolbar's targets have a dimension of 24 by 24 CSS pixels, so pass. The second toolbar, with smaller targets, shows 24 CSS pixel circles drawn on each target for assessment. The circles do not intersect and so the targets have enough space to pass. The third toolbar shows similar circles on the targets, but the circles intersect due to the lack of spacing between targets, so the toolbar fails. + +
Figure 5 Three rows of targets, illustrating two ways of meeting this Success Criterion and + one way of failing it (image shown to scale - see the scalable original version) +
+ +
+ +

The next two illustrations show sets of buttons which are only 16 CSS pixels tall. + In the first set, there are no targets immediately above or below the buttons, so + they pass. In the second illustration, there are further buttons, and they have been + stacked on top of one another, resulting in a fail. +

+ +
+ A row of buttons which are more than 44px wide and 16 CSS pixels high. There are no close targets above or below. The buttons are overlaid with the 24 CSS pixel diameter circles, and do not intersect each other nor any other targets. + +
Figure 6 While the height of the targets is only 16 CSS pixels, the lack of adjacent targets + above and below means that the targets pass this Success Criterion (image shown to + scale - see the scalable original version) +
+ +
+ + +
+ Two rows of buttons only 16 CSS pixels high, with no spacing between them. The buttons are overlaid with the 24 CSS pixel diameter circles, and all the circles either overlap another circle, or another target. + +
Figure 7 Two rows of buttons, both with a height of only 16 CSS pixels. The rows are close, + with only a 1 CSS pixel gap between them, which means that the 24 CSS pixel spacing + circles of the targets in one row will intersect the targets (and their circles, depending + on their respective widths) in the other line, thus failing the Success Criterion + (image shown to scale - see the scalable original version) +
+ +
+ +

The following two illustrations show how menu items can be adjusted to properly meet + this requirement. In the first illustration, the About us menu has been activated, showing that each of the menu item targets (text and padding) + has a 24 CSS pixel height. In the second illustration, the same menu is expanded, + but the menu items only achieve 18 CSS pixels in height. +

+ +
+ Two examples of a dropdown menu - a pass example with menu items 24 CSS pixels high, and a fail example with menu items only 18 CSS pixels high. One item has a 24 CSS pixel diameter circle which intersects adjacent targets. + +
Figure 8 The menu items with a height of 24 CSS pixels pass. For the menu items that are only + 18 CSS pixels high, the 24 CSS pixel spacing circles of the targets in one row will + intersect the adjacent menu item targets and circles, and fail (image shown to scale + - see the scalable original version) +
+ +
+ + +

The following example has one large target (an image that links to a new page related + to that image) and a very small second target (a control with a magnifier icon, to + open a zoomed-in preview, possibly in a modal, of the image itself). In the top row, + the small target overlaps - or, to be more technically accurate, clips - the large + target. The small target itself has a size of 24 by 24 CSS pixels, so passes. In the + second row, we see that if the second target is any smaller – in this case 16 by 16 + CSS pixels – it fails the criterion, as the circle with a 24 CSS pixel diameter we + draw over the small target will intersect the large target itself. +

+ + +
+ Two rows showing a small target clipping a large target + +
Figure 9 The 24 by 24 CSS pixel small target passes, while the 16 by 16 CSS pixel small target + fails, since the 24 CSS pixel diameter circle used for undersized targets intersect + the large target (image shown to scale - see the scalable original version) +
+ +
+ + +

In the following example, we have the same two targets – a large target and a small + target. This time, the small target touches/abuts the large target. If the small target + is smaller than 24 by 24 CSS pixels, the circle with a 24 CSS pixel diameter we draw + over the small target will intersect the large target itself, failing the requirement. + The undersized target must be spaced further away from the large target until its + circle doesn't intersect the large target. +

+ + +
+ Two rows showing a small target and a large target touching/abutting + +
Figure 10 In the first row, the 16 by 16 CSS pixel target touching/abutting the large target + fails, as its 24 CSS pixel diameter circle used for undersized targets intersects + the large target. In the second row we see that the only way the undersized target + can pass is by adding a 4 CSS pixel spacing gap between the targets (image shown to + scale - see the scalable original version) +
+ +
+ + +
+

Note

+

Users with different disabilities have different needs for control sizes. It can be + beneficial to provide an option to increase the active target area without increasing + the visible target size. Another option is to provide a mechanism to control the density + of layout and thereby change target size or spacing, or both. This can be beneficial + for a wide range of users. For example, users with visual field loss may prefer a + more condensed layout with smaller sized controls while users with other forms of + low vision may prefer large controls. +

+
+ +
+
+
+

Benefits

+

Having targets with sufficient size - or at least sufficient target spacing - can + help all users who may have difficulty in confidently targeting or operating small + controls. Users who benefit include, but are not limited to: +

+
    + +
  • People who use a mobile device where the touch screen is the primary mode of interaction;
    • + +
  • People using mouse, stylus or touch input who have mobility impairments such as hand + tremors; +
    • + +
  • People using a device in environments where they are exposed to shaking such as public + transportation; +
    • + +
  • Mouse users who have difficulty with fine motor movements;
    • + +
  • People who access a device using one hand;
    • + +
  • People with large fingers, or who are operating the device with only a part of their + finger or knuckle. +
    • + +
+
+
+

Examples

+
    + +
  • Three buttons are on-screen and the target size of each button is 24 by 24 CSS pixels. + Since the target size itself is 24 by 24 CSS pixels, no additional spacing is required, + the Success Criterion passes. +
    • + +
  • A row of buttons, each of which has a horizontal width of more than 24 CSS pixels, + a height of only 20 CSS pixels, and vertical margin of 4 CSS pixels above and below + the row of buttons. Since there is sufficient spacing both above and below the row + of buttons, the Success Criterion passes. +
    • + +
  • Links within a paragraph of text have varying target dimensions. Links within paragraphs + of text do not need to meet the 24 by 24 CSS pixels requirements, so the Success Criterion + passes. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+
    + +
  1. + C42: Using min-height and min-width to ensure sufficient target spacing + +
    2. + +
+
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
content
+
+ + + +

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions + +

+ + + +
+
css pixel
+
+ + + +

visual angle of about 0.0213 degrees

+ + +

A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. + This unit is density-independent, and distinct from actual hardware pixels present + in a display. User agents and operating systems should ensure that a CSS pixel is + set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [[css3-values]], which takes into account the physical dimensions of the display + and the assumed viewing distance (factors that cannot be determined by content authors). + +

+ + + +
+
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
minimum bounding box
+
+ + + +

the smallest enclosing rectangle aligned to the horizontal axis within which all the + points of a shape lie. For components which wrap onto multiple lines as part of a + sentence or block of text (such as hypertext links), the bounding box is based on + how the component would appear on a single line. +

+ + +
+
pointer input
+
+ + + +

input from a device that can target a specific coordinate (or set of coordinates) + on a screen, + such as a mouse, pen, or touch contact + +

+ +
+

Note

+

See the Pointer Events + definition for "pointer" [[pointerevents]]. +

+
+ + + +
+
presentation
+
+ + + +

rendering of the content in a form to be perceived by users + +

+ + + +
+
structure
+
+ + + +
    + + +
  1. The way the parts of a Web page are organized in relation to each other; and + +
    2. + + +
  2. The way a collection of Web pages is organized + +
    3. + + +
+ + + +
+
target
+
+ + + +

region of the display that will accept a pointer action, such as the interactive area + of a user interface component +

+ +
+

Note

+

If two or more targets are overlapping, the overlapping area should not be included + in the measurement of the target size, except when the overlapping targets perform + the same action or open the same page. +

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/text-alternatives.html b/wcag22/understanding/text-alternatives.html new file mode 100644 index 0000000..d179ded --- /dev/null +++ b/wcag22/understanding/text-alternatives.html @@ -0,0 +1,416 @@ + + + + + + Understanding Guideline 1.1: Text Alternatives | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 1.1:Text Alternatives +

+ +
+
+

Intent

+

The purpose of this guideline is to ensure that all non-text content is also available + in + text. "Text" refers to electronic text, not an image of text. Electronic text has the + unique advantage that it is presentation neutral. That is, it + can be rendered visually, auditorily, tactilely, or by any combination. As a result, + information rendered in electronic text can be presented in whatever form best meets + the needs of the user. It can also be easily enlarged, spoken aloud so that it is + easier for people with reading disabilities to understand, or rendered in whatever + tactile form best meets the needs of a user. + +

+
+

Note

+
+ + +

While changing the content into symbols includes changing it into graphic symbols + for people with developmental disorders and speech comprehension difficulties, it + is not limited to this use of symbols. + +

+ + +
+
+
+
+

Success Criteria for this Guideline

+ +
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/text-spacing.html b/wcag22/understanding/text-spacing.html new file mode 100644 index 0000000..93045ec --- /dev/null +++ b/wcag22/understanding/text-spacing.html @@ -0,0 +1,888 @@ + + + + + + Understanding Success Criterion 1.4.12: Text Spacing | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.12:Text Spacing (Level AA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can adjust text spacing to make it easier to read.
+ +
Author task
+
Ensure content adapts to user-defined text settings.
+ +
Why it's important
+
Some people need text with different spacing or font characteristics.
+ +
+
+
+

Intent

+

The intent of this Success Criterion (SC) is to ensure that when people override author + specified text spacing to improve their reading experience, content is still readable + and operable. Each of the requirements stipulated in the SC's four bullets helps ensure + text styling can be adapted by the user to suit their needs. +

+

The specified metrics set a minimum baseline. The values in between the author's metrics + and the metrics specified in this SC should not have loss of content or functionality. +

+

This SC focuses on the adaptability of content to an increase in spacing between lines, + words, letters, and paragraphs. Any combination of these may assist a user with effectively + reading text. As well, ensuring that content correctly adapts when users override + author settings for spacing also significantly increases the likelihood other style + preferences can be set by the user. For example, a user may need to change to a wider + font family than the author has set in order to effectively read text. +

+
+ +

Author Responsibility

+ +

This SC does not dictate that authors must set all their content to the specified + metrics, nor does the SC intend to imply that all users will adjust the specified + metrics. Rather, it specifies that should a user choose to set any of these metrics + they can do so without any loss of content or functionality. The author requirement + is both to not interfere with a user's ability to override the author settings, and + to ensure that content thus modified does not break content in the manners shown in + figures 1 through 3 in Effects of Not Allowing for Spacing Override. +

+ + +

In some human languages and scripts, some of the metrics specified by the SC are inapplicable. + For example, languages such as Japanese do not use spacing following paragraphs, meaning + that users are unlikely to make any paragraph spacing changes in practice. The exception + in this SC allows authors to ignore text style properties which are inapplicable to + the combination of language and script being used. +

+ + +

It is beneficial for users if authors use any locally available guidance for improving + readability in the local language or writing system. If the user chooses to go beyond + the metrics specified, any resulting loss of content or functionality is the user's + responsibility. +

+ + +

Further, this SC is not concerned with how users change the line height and spacing metrics. It does not require that content + implement its own mechanisms to allow users to do this. It is not a failure of the + content if a user agent or platform does not provide a way for users to do this. Content + does not fail this SC if the method chosen by the user - for instance, the use of + an extension or bookmarklet - fails to correctly set the line height and spacing text + properties on the content (provided that the content is not actively and purposely + preventing the properties from being added). +

+ +
+ +

Applicability

+ +

If the markup-based technologies being used are capable of overriding text to the + Success Criterion's metrics, then this SC is applicable. For instance Cascading Style + Sheet/HTML technologies are quite able to allow for the specified spacing metrics. + Plugin technologies would need to have a built-in ability to modify styles to the + specified metrics. Currently, this SC does not apply to PDF as it is not implemented + using markup. +

+ +

Examples of text that are typically not affected by style properties and not expected to adapt are: +

+ +
    + +
  • Video captions embedded directly into the video frames and not provided as an associated + caption file +
    • + +
  • Images of text
    • + +
+ +

For this SC, canvas implementations of text are considered to be images of text. +

+ +
+ +
+ +

Use of ellipses

+ +

There may be regions of a page where text containers cannot expand due to design constraints + (such as a maximum width for the left navigation or table column headers). A common + convention if text exceeds its space is to replace truncated text with an ellipsis. + Where ellipses appear as a result of modifying text style properties, the page can + still meet the Text Spacing requirements, so long as the content is still available. + For example: +

+ +
    + +
  • a mechanism is provided to reveal the truncated text on the page (for instance, the + text appears on focus or on activation) +
    • + +
  • where the ellipsis is part of a section of + content which includes a link, the truncated text is revealed on the linked page +
    • + +
+ + +

Where text is not truncated but it is when text is spaced, if there is no mechanism + to show the truncated text, it fails this Success Criterion. +

+ +
+ +
+
+ +

User Responsibility

+ +

The ability to read and derive meaning from the overridden spacing rests with the + user. The user may choose to exceed the spacing adjustments in the SC. If the increased + spacing causes loss of content or functionality, the user will adjust or return to + the author’s original spacing or spacing within the bounds of the SC. Regardless, + the user needs the flexibility to adjust spacing within the bounds set in the SC without + loss of content or functionality. Such changes may be achieved via user stylesheet, + bookmarklet, extension, or application. +

+ +
+
+ +

Effects of Not Allowing for Spacing Override

+ +

The following images show some types of failures when authors do not take into consideration + that users may override spacing to the metrics specified in this Success Criterion. +

+ +
+ +

Text Cut Off

+ +

The bottom portion of the words "Your Needs" is cut off in a heading making that text + unreadable in Figure 1. It should read "We Provide a Mobile Application Service to + Meet Your Needs." +

+ +
+ +
Figure 1 Vertical text cut off is a failure.
+ Heading text truncated vertically. + +
+ +

In Figure 2 the last portion of text is cut off in 3 side-by-side headings. The 1st + heading should read "A cog in the wheel." But it reads "A cog in the whe". Only half + of the second "e" is visible and the letter "l" is completely missing. The 2nd heading + should read "A penny for your thoughts". But it reads "A penny for your". The 3rd + should read "Back to the drawing board." But it reads "Back to the drawi". +

+ +
+ +
Figure 2 Horizontal text cut off is a failure.
+ 3 side-by-side headings with truncated text. + +
+ +
+ +
+ +

Text Overlap

+ +

In Figure 3 the last 3 words "Groups and Programs" of the heading "Technologists Seeking + Input from Groups and Programs" overlap the following sentence. That sentence should + read, "You are invited to share ideas and areas of interest related to the integration + of technology from a group or program perspective." But the words "You are invited + to share ideas" are obscured and unreadable. +

+ +
+ +
Figure 3 Overlapping text is a failure.
+ Heading text overlaps part of paragraph text. + +
+ +
+ +
+
+
+

Benefits

+
    + +
  • People with low vision who require increased space between lines, words, and letters + are able to read text. +
    • + +
  • People with dyslexia may increase space between lines, words, and letters to increase + reading speed. +
    • + +
  • Although not required by this SC, white space between blocks of text can help people + with cognitive disabilities discern sections and call out boxes. +
    • + +
+
+
+

Examples

+

When spacing is being overridden to the SC's metrics:

+
    + +
  1. Text fits within the bounds of its containing box without being cut off.
    2. + +
  2. Text fits within the bounds of its containing box without overlapping other boxes.
    3. + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+
+ +

Research

+ +

The grounds for this SC are based on research. The metrics chosen as measures are based on the McLeish study. She ran from .04 to .25 em tests. McLeish found an increasing curve in reading + speed of actual materials up to .25, but it started to flatten at .20. Previous studies + that reported no improvement started at .5em. Right at the flat point. Wayne E. Dick, Ph.D. analyzed the McLeish study and translated from points. Dr. Dick recommended the metrics that the Working Group + adopted. +

+ +
+ +

Languages and Scripts

+ +

Roughly 480 different languages and scripts have been tested. Maximum spacing adjustments allowed by the SC were set on the following 3 pages: +

+ +
    + +
  1. Languages in their own writing systems
    2. + +
  2. Online Encyclopedia of writing systems and languages – language names
    3. + +
  3. Universal Declaration of Human Rights (Article 1)
    4. + +
+ +
+ +
+ +

Results

+ +

No adverse effects occurred. The following are the specific findings:

+ +
+ +
Character Spacing
+ +
Individual characters in words remained intact though they were spaced a bit further + apart. +
+ +
Word Spacing
+ +
Words were spaced farther apart. In languages that do not have words (e.g. Japanese) + applying word spacing had no effect. This is expected. +
+ +
Line Height
+ +
Changing line height did not separate diacritics from characters, nor did it adversely + impact ascenders or descenders. +
+ +
+ +

As previously discussed, the ability to read text with adjusted spacing is a user + responsibility. This is true no matter the language. +

+ +

The SC's exception addresses cases where a text style property is not used in a language + or script. In such cases, authors are only required to ensure relevant properties + do not break the layout. +

+ +
+ +
+
+ +

Other references

+ + + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
human language
+
+ + + +

language that is spoken, written or signed (through visual or tactile means) to communicate + with humans + +

+ + +
+

Note

+

See also sign language. + +

+
+ + + +
+
image of text
+
+ + + +

text that has been rendered in a non-text form (e.g., an image) in order to achieve + a particular visual effect + +

+ + +
+

Note

+

This does not include text that is part of a picture that contains significant other visual content. + +

+
+ + + + + + +
+
programmatically determined
+
+ + + +

determined by software from author-supplied data provided in a way that different + user agents, including assistive technologies, can extract and present this information to users in different modalities + +

+ + + + + + + + + +
+
sign language
+
+ + + +

a language using combinations of movements of the hands and arms, facial expressions, + or body positions to convey meaning + +

+ + + +
+
style property
+
+ + +

property whose value determines the presentation (e.g. font, color, size, location, + padding, volume, synthesized speech prosody) of + content elements as they are rendered (e.g. onscreen, via loudspeaker, via braille + display) by user agents +

+ +

Style properties can have several origins:

+ +
    + +
  • User agent default styles: The default style property values applied in the absence + of any author or user styles. Some web content technologies specify a default rendering, + others do not; +
    • + +
  • Author styles: Style property values that are set by the author as part of the content + (e.g. in-line styles, author style + sheets); +
    • + +
  • User styles: Style property values that are set by the user (e.g. via user agent interface + settings, user style sheets) +
    • + +
+ + +
+
text
+
+ + + +

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language + +

+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/three-flashes-or-below-threshold.html b/wcag22/understanding/three-flashes-or-below-threshold.html new file mode 100644 index 0000000..4e3b59e --- /dev/null +++ b/wcag22/understanding/three-flashes-or-below-threshold.html @@ -0,0 +1,972 @@ + + + + + + Understanding Success Criterion 2.3.1: Three Flashes or Below Threshold | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.3.1:Three Flashes or Below Threshold (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Content does not trigger seizures.
+ +
What to do
+
Avoid content that flashes, or keep it under thresholds.
+ +
Why it's important
+
Flashing content can cause migraines, dizziness, nausea, and seizures.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to allow users to access the full content + of a site without inducing seizures due to photosensitivity. + +

+

Individuals who have photosensitive seizure disorders can have a seizure triggered + by content that flashes at certain frequencies for more than a few flashes. People + are even more sensitive to red flashing than to other colors, so a special test is + provided for saturated red flashing. These guidelines were originally based on guidelines + for + the broadcasting industry as adapted for desktop monitors, where content is viewed + from a closer distance (using a larger angle of vision). + +

+

Flashing can be caused by the display, the computer rendering the image or by the + content being rendered. The author has no control of the first two. They can be addressed + by the design and speed of the display and computer. The intent of this criterion + is to ensure that flicker that violates the flash thresholds is not caused by the + content itself. For example, the content could contain a video clip or animated image + of a series of strobe flashes, or close-ups of rapid-fire explosions. + + +

+

This Success Criterion replaces a much more restrictive criterion in WCAG 1.0 that + did not allow any flashing (even of a single pixel) within a broad frequency range + (3 to 50 Hz). This Success Criterion is based on existing specifications in use in + the UK and by others for television broadcast and has been adapted for computer display + viewing. In WCAG 2.0, a 1024 x 768 screen was used as the reference screen resolution + for the + evaluation. The 341 x 256 pixel block represents a 10 degree viewport at a typical + viewing distance. (The 10 degree field is taken from the original specifications and + represents the central vision portion of the eye, where people are most susceptible + to photo stimuli.) + +

+

With the proliferation of devices of varying screen sizes (from small hand-helds to + large living room displays), as well as the adoption of CSS pixels as a density-independent unit of measurement, the prior assessment criteria may seem + outdated. However, an image of a consistent size uses up relatively the same percentage + of a user's visual field on any device. On a large screen, the image takes up less + size, but the large screen takes up a larger part of the visual field. On a mobile + screen, the image may take up most or all of the screen; however, the mobile screen + itself takes up a smaller portion of the user's visual field. So the same dimension + of the flashing content, represented in CSS pixels can still provide a consistent + means of assessment. Substituting CSS pixels for the original pixel block means that + the combined area of flashing becomes 341 x 256 CSS pixels, or a flashing area of + 87,296 CSS pixels. +

+

Content should be analyzed at the largest scale at which a user may view the content, + and at the standard zoom level of the user agent. For example, with a video that may + play in an area of a web page and also at full screen, the video should be analyzed + for risks at full screen. +

+

Where video content is provided in color spaces other than sRGB, the version provided + with the highest dynamic range should be tested. In such cases the industry standard + definition of a general flash is a change in luminance of 20 cd/m2 or more where the + darker image is below 160 cd/m2. (ITU-R BT.1702.) This is applicable for standard dynamic range (SDR) and high dynamic range (HDR) + content. For HDR content when the darker state is 160 cd/m2 or more, a general flash + is one where the Michelson contrast is 1/17 or greater — where the Michelson contrast + is calculated as (LHigh - LLow) / (LHigh + LLow), and where LHigh and LLow are the + luminance of the high and low luminance states, respectively. +

+

For short clips that might be looped (such as GIF animations), the content should + be analyzed while looping. +

+
+

Note

+

The specification cannot account for the actual viewing distance that a person chooses. + Users that are closer to their screens than the idealized viewing distance will be + affected by flashing areas that normatively pass. The same problem applies to users + who rely on zoom or screen magnification. Conversely, users who are further away from + the screen than the idealized distance should be able to tolerate flashing areas that + are larger than the threshold. +

+
+

The combined area of flashes occurring concurrently and contiguously means the total + area that is actually flashing at the same time. It is calculated by adding up the + contiguous area that is flashing simultaneously within any 10 degree angle of view. + +

+
+

Note

+
+ + +

The terms "blinking" and "flashing" can sometimes refer to the same content.

+ + +
    + + +
  • "Blinking" refers to content that causes a distraction problem. Blinking can be allowed + for a short time as long as it stops (or can be stopped) + +
    • + + +
  • "Flashing" refers to content that can trigger a seizure (if it is more than 3 per + second and large and bright enough). This cannot be allowed even for a second or it + could cause a seizure. And turning the flash off is also not an option since the seizure + could occur faster than most users could turn it off. + +
    • + + +
  • Blinking usually does not occur at speeds of 3 per second or more, but it can. If + blinking occurs faster than 3 per second, it would also be considered a flash. + +
    • + + +
+ + +
+
+
+

Note

+
+ +

The new (in WCAG 2.2) working definition in the field for "pair of opposing transitions involving a saturated red" is a pair of opposing transitions where, one transition is either to or from a state + with a value R/(R + G + B) that is greater than or equal to 0.8, and the difference + between states is more than 0.2 (unitless) in the CIE 1976 UCS chromaticity diagram. + [ISO 9241-391] +

+ +

The chromaticity difference is calculated as:

+ +
    + +
  • SQRT( (u'1 - u'2)^2 + (v'1 - v'2)^2 )
    • + +
+ +

where u'1 and v'1 are chromaticity coordinates of State 1 and u'2 and v'2 are chromaticity + coordinates of State 2. The 1976 UCS chromaticity coordinates of u' and v' are calculated + as: +

+ +
    + +
  • u' = 4 * X / (X + 15 * Y + 3 * Z)
    • + +
  • v' = 9 * Y / (X + 15 * Y + 3 * Z)
    • + +
+ +

where X, Y, and Z are the tristimulus values of a color in the CIE XYZ colorspace, + which can be calculated as: +

+ +
    + +
  • X = 0.4124564 * R + 0.3575761 * G + 0.1804375 * B
    • + +
  • Y = 0.2126729 * R + 0.7151522 * G + 0.0721750 * B
    • + +
  • Z = 0.0193339 * R + 0.1191920 * G + 0.9503041 * B
    • + +
+ +

where R, G, & B are values that range from 0-1 as specified in “relative luminance” + definition. +

+ +
+
+
+
+

Benefits

+
    + + +
  • Individuals who have seizures when viewing flashing material will be able to view + all of the material on a site without having a seizure and without having to miss + the full experience of the content by being limited to text alternatives. This includes + people with photosensitive epilepsy as well as other photosensitive seizure disorders. + +
    • + + +
+
+
+

Examples

+
    + + +
  • + A Web site has video of muzzle flash of machine gun fire, but limits the size of the + flashing image to a small portion of the screen below the flash threshold size. + + + +
    • + + +
  • A movie with a scene involving very bright lightning flashes is edited so that the + lightning only flashes three times in any one second period. + + + +
    • + + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
blinking
+
+ + + +

switch back and forth between two visual states in a way that is meant to draw attention

+ + +
+

Note

+

See also flash. It is possible for something to be large enough and blink brightly enough at the + right frequency to be also classified as a flash. + +

+
+ + + +
+
flash
+
+ + + +

a pair of opposing changes in relative luminance that can cause seizures in some people if it is large enough and in the right frequency + range + +

+ + +
+

Note

+

See general flash and red flash thresholds for information about types of flash that are not allowed. + +

+
+ + +
+

Note

+

See also blinking. + +

+
+ + + +
+
general flash and red flash thresholds
+
+ + + +

a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of the following are true: + +

+ + +
    + + +
  1. there are no more than three general flashes and / or no more than three red flashes within any one-second period; or + +
    2. + + +
  2. the combined area of flashes occurring concurrently occupies no more than a total + of .006 steradians within any 10 degree visual field on the screen (25% of any 10 + degree visual field on the screen) at typical viewing distance + +
    3. + + +
+ + +

where:

+ + +
    + + +
  • A general flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance (1.0) where the relative luminance + of + the darker image is below 0.80; and where "a pair of opposing changes" is an increase + followed by a decrease, or a decrease followed by an increase, and + +
    • + + +
  • A red flash is defined as any pair of opposing transitions involving a saturated red + +
    • + + +
+ + +

+ Exception: Flashing that is a fine, balanced, pattern such as white noise or an alternating + checkerboard pattern with "squares" smaller than 0.1 degree (of visual field at typical + viewing distance) on a side does not violate the thresholds. + +

+ + +
+

Note

+

For general software or Web content, using a 341 x 256 pixel rectangle anywhere on + the displayed screen area when the content is viewed at 1024 x 768 pixels will provide + a good estimate of a 10 degree visual field for standard screen sizes and viewing + distances (e.g., 15-17 inch screen at 22-26 inches). This resolution of 75 - 85 ppi + is known to be lower, and thus more conservative than the nominal CSS pixel resolution + of 96 ppi in CSS specifications. Higher resolutions displays showing the same rendering + of the content yield smaller and safer images so it is lower resolutions that are + used to define the thresholds. + +

+
+ + +
+

Note

+

A transition is the change in relative luminance (or relative luminance/color for + red flashing) between adjacent peaks and valleys in a plot of relative luminance (or + relative luminance/color for red flashing) measurement against time. A flash consists + of two opposing transitions. + +

+
+ + +
+

Note

+

The new working definition in the field for "pair of opposing transitions involving a saturated red" (from WCAG 2.2) is a pair of opposing transitions where, one transition is either + to or from a state with a value R/(R + G + B) that is greater than or equal to 0.8, + and the difference between states is more than 0.2 (unitless) in the CIE 1976 UCS + chromaticity diagram. [[ISO_9241-391]] +

+
+ + +
+

Note

+

Tools are available that will carry out analysis from video screen capture. However, + no tool is necessary to evaluate for this condition if flashing is less than or equal + to 3 flashes in any one second. Content automatically passes (see #1 and #2 above). + +

+
+ + + +
+
relative luminance
+
+ + + +

the relative brightness of any point in a colorspace, normalized to 0 for darkest + black and 1 for lightest white + +

+ + +
+

Note

+
+ +

For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 + * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as: + +

+ + +
    + + +
  • if RsRGB <= 0.04045 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
  • if GsRGB <= 0.04045 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
  • if BsRGB <= 0.04045 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
+ + +

and RsRGB, GsRGB, and BsRGB are defined as:

+ + +
    + + +
  • RsRGB = R8bit/255
    • + + +
  • GsRGB = G8bit/255
    • + + +
  • BsRGB = B8bit/255
    • + + +
+ + +

The "^" character is the exponentiation operator. (Formula taken from + [[SRGB]].) + +

+ + +
+
+ + +
+

Note

+

Before May 2021 the value of 0.04045 in the definition was different (0.03928). It + was taken from an older version of the specification and has been updated. It has + no practical effect on the calculations in the context of these guidelines. +

+
+ + +
+

Note

+

Almost all systems used today to view Web content assume sRGB encoding. Unless it + is known that another color space will be used to process and display the content, + authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3. + +

+
+ + +
+

Note

+

If dithering occurs after delivery, then the source color value is used. For colors + that are dithered at the source, the average values of the colors that are dithered + should be used (average R, average G, and average B). + +

+
+ + +
+

Note

+

Tools are available that automatically do the calculations when testing contrast and + flash. + +

+
+ + +
+

Note

+

A separate page giving the relative luminance definition using MathML to display the formulas is available. + +

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/three-flashes.html b/wcag22/understanding/three-flashes.html new file mode 100644 index 0000000..48ba8d9 --- /dev/null +++ b/wcag22/understanding/three-flashes.html @@ -0,0 +1,814 @@ + + + + + + Understanding Success Criterion 2.3.2: Three Flashes | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.3.2:Three Flashes (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Content does not trigger seizures.
+ +
What to do
+
Do not flash content more than 3 times a second.
+ +
Why it's important
+
Flashing content can cause migraines, dizziness, nausea, and seizures.
+ +
+
+
+

Intent

+

The purpose of this Success Criterion is to further reduce the chance of seizures. + Seizures cannot be completely eliminated since some people are so sensitive. However, + by eliminating all 3-per-second flashing over any area of the screen, the chances + of a person having a seizure are further reduced than when just meeting the measures + ordinarily used today in standards internationally, as we do at Level A. + + +

+

Whereas + Success Criterion 2.3.1 allows flashing if it is dim enough or has a small enough area, Success Criterion + 2.3.2 does not allow flashing greater than 3 per second, regardless of brightness + or size. As a result, even a single flashing pixel would violate this criterion. The + intent is to guard against flashing larger than a single pixel, but since an unknown + amount of magnification or high contrast setting may be applied, the prohibition is + against any flashing. + +

+
+

Note

+
+ + +

In some cases, what we refer to as "blinking" and what we refer to as "flashing" may + overlap slightly. We are using different terms for the two because "blinking" causes + a distraction problem which you can allow for a short time as long as it stops (or + can be stopped) whereas "flashing" is a seizure trigger and cannot be allowed or it + will cause a seizure. The seizure would occur faster than most users could turn it + off. "Blink" therefore refers to slow repeating changes that would distract. "Flash" + refers to changes that could cause a seizure if they were bright enough or persisted + long enough. Blinking usually doesn't occur at speeds of 3 per second or more so blink + and flash do not overlap. However, blinking can occur faster than 3 per second so + there could be an overlap. See + 2.2.2: Pause, Stop, Hide for more information on blink. + + +

+ + +
+
+
+
+

Benefits

+
    + + +
  • Individuals who have seizures when viewing flashing material will be able to view + all of the material on a site without having a seizure and without having to miss + the full experience of the content by being limited to text alternatives. This includes + people with photosensitive epilepsy as well as other photosensitive seizure disorders. + +
    • + + +
+
+
+

Examples

+
    + + +
  • A movie with a scene involving very bright lightning flashes is edited so that the + lightning only flashes three times in any one second period. + + +
    • + + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
blinking
+
+ + + +

switch back and forth between two visual states in a way that is meant to draw attention

+ + +
+

Note

+

See also flash. It is possible for something to be large enough and blink brightly enough at the + right frequency to be also classified as a flash. + +

+
+ + + +
+
flash
+
+ + + +

a pair of opposing changes in relative luminance that can cause seizures in some people if it is large enough and in the right frequency + range + +

+ + +
+

Note

+

See general flash and red flash thresholds for information about types of flash that are not allowed. + +

+
+ + +
+

Note

+

See also blinking. + +

+
+ + + +
+
general flash and red flash thresholds
+
+ + + +

a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of the following are true: + +

+ + +
    + + +
  1. there are no more than three general flashes and / or no more than three red flashes within any one-second period; or + +
    2. + + +
  2. the combined area of flashes occurring concurrently occupies no more than a total + of .006 steradians within any 10 degree visual field on the screen (25% of any 10 + degree visual field on the screen) at typical viewing distance + +
    3. + + +
+ + +

where:

+ + +
    + + +
  • A general flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance (1.0) where the relative luminance + of + the darker image is below 0.80; and where "a pair of opposing changes" is an increase + followed by a decrease, or a decrease followed by an increase, and + +
    • + + +
  • A red flash is defined as any pair of opposing transitions involving a saturated red + +
    • + + +
+ + +

+ Exception: Flashing that is a fine, balanced, pattern such as white noise or an alternating + checkerboard pattern with "squares" smaller than 0.1 degree (of visual field at typical + viewing distance) on a side does not violate the thresholds. + +

+ + +
+

Note

+

For general software or Web content, using a 341 x 256 pixel rectangle anywhere on + the displayed screen area when the content is viewed at 1024 x 768 pixels will provide + a good estimate of a 10 degree visual field for standard screen sizes and viewing + distances (e.g., 15-17 inch screen at 22-26 inches). This resolution of 75 - 85 ppi + is known to be lower, and thus more conservative than the nominal CSS pixel resolution + of 96 ppi in CSS specifications. Higher resolutions displays showing the same rendering + of the content yield smaller and safer images so it is lower resolutions that are + used to define the thresholds. + +

+
+ + +
+

Note

+

A transition is the change in relative luminance (or relative luminance/color for + red flashing) between adjacent peaks and valleys in a plot of relative luminance (or + relative luminance/color for red flashing) measurement against time. A flash consists + of two opposing transitions. + +

+
+ + +
+

Note

+

The new working definition in the field for "pair of opposing transitions involving a saturated red" (from WCAG 2.2) is a pair of opposing transitions where, one transition is either + to or from a state with a value R/(R + G + B) that is greater than or equal to 0.8, + and the difference between states is more than 0.2 (unitless) in the CIE 1976 UCS + chromaticity diagram. [[ISO_9241-391]] +

+
+ + +
+

Note

+

Tools are available that will carry out analysis from video screen capture. However, + no tool is necessary to evaluate for this condition if flashing is less than or equal + to 3 flashes in any one second. Content automatically passes (see #1 and #2 above). + +

+
+ + + +
+
relative luminance
+
+ + + +

the relative brightness of any point in a colorspace, normalized to 0 for darkest + black and 1 for lightest white + +

+ + +
+

Note

+
+ +

For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 + * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as: + +

+ + +
    + + +
  • if RsRGB <= 0.04045 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
  • if GsRGB <= 0.04045 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
  • if BsRGB <= 0.04045 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4 + +
    • + + +
+ + +

and RsRGB, GsRGB, and BsRGB are defined as:

+ + +
    + + +
  • RsRGB = R8bit/255
    • + + +
  • GsRGB = G8bit/255
    • + + +
  • BsRGB = B8bit/255
    • + + +
+ + +

The "^" character is the exponentiation operator. (Formula taken from + [[SRGB]].) + +

+ + +
+
+ + +
+

Note

+

Before May 2021 the value of 0.04045 in the definition was different (0.03928). It + was taken from an older version of the specification and has been updated. It has + no practical effect on the calculations in the context of these guidelines. +

+
+ + +
+

Note

+

Almost all systems used today to view Web content assume sRGB encoding. Unless it + is known that another color space will be used to process and display the content, + authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3. + +

+
+ + +
+

Note

+

If dithering occurs after delivery, then the source color value is used. For colors + that are dithered at the source, the average values of the colors that are dithered + should be used (average R, average G, and average B). + +

+
+ + +
+

Note

+

Tools are available that automatically do the calculations when testing contrast and + flash. + +

+
+ + +
+

Note

+

A separate page giving the relative luminance definition using MathML to display the formulas is available. + +

+
+ + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
web page
+
+ + + +

a non-embedded resource obtained from a single URI using HTTP plus any other resources + that are used in the rendering or intended to be rendered together with it by a user agent + +

+ + +
+

Note

+

Although any "other resources" would be rendered together with the primary resource, + they would not necessarily be rendered simultaneously with each other. + +

+
+ + +
+

Note

+

For the purposes of conformance with these guidelines, a resource must be "non-embedded" + within the scope of conformance to be considered a Web page. + +

+
+ + + + + + + + + + + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/time-based-media.html b/wcag22/understanding/time-based-media.html new file mode 100644 index 0000000..f7feb45 --- /dev/null +++ b/wcag22/understanding/time-based-media.html @@ -0,0 +1,264 @@ + + + + + + Understanding Guideline 1.2: Time-based Media | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + Guideline 1.2:Time-based Media +

+ +
+
+

Intent

+

The purpose of this guideline is to provide access to time-based and synchronized + media.This includes media that is: + +

+
    + + +
  • audio-only
    • + + +
  • video-only
    • + + +
  • audio-video
    • + + +
  • audio and/or video combined with interaction
    • + + +
+

To make it easy for authors to quickly determine which success criteria apply to their + content, the type of media each success criterion applies to is included in its short + name. + +

+

For + audio-only or + video-only media, you only need to apply the success criteria that say " + audio-only" or " + video-only" in their short name. If your media is not + audio-only or + video-only, then all the rest of the success criteria apply. + +

+

Media can also be + live or + prerecorded. Each of the success criterion short names clearly tells you if the success criterion + applies to + live or + prerecorded media. + +

+

+ Synchronized media is defined in the glossary as: + +

+

+

Note that an audio file accompanied by interaction is covered here, as is a video-only + file that involves interaction. These are covered because interaction must take place + at a particular time. Having a text transcript that said, "for more information, click + now," would not be very helpful since the reader would have no idea when the audio + said, "now." As a result, synchronized captions would be needed. + +

+

Sometimes, there is so much dialogue that audio description cannot fit into existing + pauses in the dialogue. The option at Level A to provide an alternative for time-based + media instead of audio description for synchronized media would allow access to all + of the information in the synchronized media. This option also allows access to the + visual information in non-visual form when audio description is not provided for some + other reason. + +

+

For synchronized media that includes interaction, interactive elements (for example + links) could be embedded in the alternative for time-based media. + +

+

This guideline also includes (at Level AAA) sign language interpretation for synchronized + media as well as an approach called extended audio description. In extended audio + description, the video is frozen periodically to allow more audio description to take + place than is possible in the existing pauses in the dialogue. This is a case where + higher-level Success Criteria build upon the requirements of lower-level Success Criterion + with the intention of having cumulative, progressively stronger, requirements. + + + +

+
+
+

Success Criteria for this Guideline

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/timeouts.html b/wcag22/understanding/timeouts.html new file mode 100644 index 0000000..da14601 --- /dev/null +++ b/wcag22/understanding/timeouts.html @@ -0,0 +1,339 @@ + + + + + + Understanding Success Criterion 2.2.6: Timeouts | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.2.6:Timeouts (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users do not lose data due to unknown timeouts.
+ +
Author task
+
Tell users how long their session can be inactive before they may lose information.
+ +
Why it's important
+
People with disabilities may need more time to complete actions.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that when a timeout is used, users + know what duration of inactivity will cause the page to time out and result in lost + data. The use of timed events can present significant barriers for users with cognitive + disabilities, as these users may require more time to read content or to perform functions, + such as completing an online form. +

+

During the completion of an online process, such as to reserve a hotel room or purchase + a plane ticket, a user with a cognitive impairment may become overwhelmed with lengthy + instructions and data input required to complete the process. The user may not be + able to complete the process in one sitting and may need to take a break. Users should + be able to leave a process without losing their current place within the process, + and without losing information that has already been entered. If users cannot take + a break and check their work, many will often be unable to complete a task correctly. +

+

This Success Criterion works in tandem with Success Criterion 2.2.1 Timing Adjustable, + but is specifically focused on notification of timeouts related to user inactivity. +

+

The best way to conform to this success criterion is to keep the user data for at + least 20 hours. This enables the user with disabilities and the aging community to + start and finish a task, taking breaks as needed. However, when it is not practical + to save the user data the author must warn the user about the duration of inactivity + which will result in a timeout. Timeouts should be displayed to the user once at the + beginning of the related task or process and not at each step. +

+

This success criterion only applies to timeouts that are within the content provider's + knowledge or control. For example, if the user closes a web browser or device and + loses content in an open page that has not yet been submitted, the success criterion + has not been violated. +

+

Examples of privacy regulations mentioned in the Success Criterion note, and related + compliance standards, are PCI DSS (Payment Card Industry Data Security Standard) and + HIPAA (Health Insurance Portability and Accountability Act of 1996). +

+
+
+

Benefits

+

This Success Criterion helps users by ensuring they are notified about timeouts related + to inactivity. +

+

When a user knows how much time they are allowed for a task, they will know whether + they can take a needed break and resume their work without needing to start again. + This enables many users to complete tasks online that they otherwise could not do. + If a situation exists where a timeout is necessary, the user is warned at the start + of the task about the length of inactivity that would generate a timeout. The user can + then decide if they can manage this task or not in the given time, or if they need + to prepare materials in advance of starting a process. This will reduce the frustration + of losing work due to a timeout. +

+

This Success Criterion helps people with many different cognitive disabilities, including + people with: +

+
    + +
  • language-related disabilities;
    • + +
  • memory-related disabilities;
    • + +
  • focus-and-attention-related disabilities; and
    • + +
  • disabilities that affect executive function and decision making.
    • + +
+
+
+

Examples

+
    + +
  • While making a purchase on an e-commerce Web site, the information input by the user + is stored for more than 20 hours. This helps ensure that if they need to stop working + for a while that they are more likely to be able to continue the purchase when they + return. +
    • + +
  • A web application allowing people to file tax returns provides a notice that the application + will time out for security purposes. The notice indicates that a lack of activity + for a continuous period of time that is greater than an hour will trigger initiate + the time out process. +
    • + +
  • An online contact form does not implement any type of time out process. Information + entered into the contact form can be submitted at any time and would only be lost + if the user closes their browser window. +
    • + +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+
    + +
  • Setting a session timeout to occur following at least 20 hours of inactivity.
    • + +
  • Store user data for more than 20 hours.
    • + +
  • Provide a warning of the duration of user inactivity at the start of a process.
    • + +
+
+
+
+
+ +

Key Terms

+ +
user inactivity
+
+ + +

any continuous period of time where no user actions occur

+ +

The method of tracking will be determined by the web site or application.

+ + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/timing-adjustable.html b/wcag22/understanding/timing-adjustable.html new file mode 100644 index 0000000..1b1f88b --- /dev/null +++ b/wcag22/understanding/timing-adjustable.html @@ -0,0 +1,711 @@ + + + + + + Understanding Success Criterion 2.2.1: Timing Adjustable | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 2.2.1:Timing Adjustable (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users have adequate time to complete tasks.
+ +
What to do
+
Let users turn off, adjust, or extend time limits.
+ +
Why it's important
+
People with disabilities may need more time to complete activities.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that users with disabilities are + given adequate time to interact with Web content whenever possible. People with disabilities + such as blindness, low vision, dexterity impairments, and cognitive limitations may + require more time to read content or to perform functions such as filling out on-line + forms. If Web functions are time-dependent, it will be difficult for some users to + perform the required action before a time limit occurs. This may render the service + inaccessible to them. Designing functions that are not time-dependent will help people + with disabilities succeed at completing these functions. Providing options to disable + time limits, customize the length of time limits, or request more time before a time + limit occurs helps those users who require more time than expected to successfully + complete tasks. These options are listed in the order that will be most helpful for + the user. Disabling time limits is better than customizing the length of time limits, + which is better than requesting more time before a time limit occurs. + +

+

Any process that happens without user initiation after a set time or on a periodic + basis is a time limit. This includes partial or full updates of content (for example, + page refresh), changes to content, or the expiration of a window of opportunity for + a user to react to a request for input. + +

+

It also includes content that is advancing or updating at a rate beyond the user's + ability to read and/or understand it. In other words, animated, moving or scrolling + content introduces a time limit on a users ability to read content. +

+

This success criterion is generally not applicable when the content repeats or is + synchronized with other content, so long as the information and data is adjustable + or otherwise under the control of the end user. Examples of time limits for which + this success criterion is not applicable include scrolling text that repeats, captioning, + and carousels. These are situations which do include time limits, but the content is still available + to the user because it has controls for accessing it, as specified in 2.2.2 Pause, Stop, Hide. +

+

In some cases, however, it is not possible to change the time limit (for example, + for an auction or other real-time event) and exceptions are therefore provided for + those cases. +

+

Content that operates on a timer does not need to be time adjustable if there is an + alternative that does not rely on a timer. For example, a web application such as + an email client provides notification of new email arriving with a temporary message + (such as a 'toast' message) in the lower right-hand side of the interface, and the + message disappears after 5 seconds. Users are able to identify the arrival of email + through other means, such as viewing the Inbox, so the disappearance of the message + does not set a time limit on the their ability to determine if new mail has arrived. + If the user has no other means of discovering the same information (or performing + the same function), then each message would need to meet this Success Criterion in + order to provide users with sufficient time to access the information. +

+

+ + Notes regarding server time limits + + +

+
    + + +
  • Timed server redirects can be found below under Common Failures.
    • + + +
  • Non-timed server redirects (e.g., 3xx response codes) are not applicable because there + is no time limit: they work instantly. + +
    • + + +
  • This Success Criterion applies only to time limits that are set by the content itself. + For example, if a time limit is included in order to address security concerns, it + would be considered to have been set by the content because it is designed to be + part of the presentation and interaction experience for that content. Time limits + set externally to content, such as by the user agent or by factors intrinsic to the + Internet are not under the author's control and not subject to WCAG conformance requirements. + Time limits set by Web servers should be under the author's/organization's control + and are covered. (Success Criteria + 2.2.3, + 2.2.4 and + 2.2.5 may also apply.) + +
    • + + +
  • Ten times the default was chosen based on clinical experience and other guidelines. + For example, if 15 seconds is allowed for a user to respond and hit a switch, 150 + seconds would be sufficient to allow almost all users to hit a switch even if they + had trouble. + + +
    • + + +
  • 20 seconds was also based on clinical experience and other guidelines. 20 seconds + to hit 'any switch' is sufficient for almost all users including those with spasticity. + Some would fail, but some would fail all lengths of time. A reasonable period for + requesting more time is required since an arbitrarily long time can provide security + risks to all users, including those with disabilities, for some applications. For + example, with kiosks or terminals that are used for financial transactions, it is + quite common for people to walk away without signing off. This leaves them vulnerable + to those walking up behind them. Providing a long period of inactivity before asking, + and then providing a long period for the person to indicate that they are present + can leave terminals open for abuse. If there is no activity the system should ask + if the user is there. It should then ask for an indication that a person is there + ('hit any key') and then wait long enough for almost anyone to respond. For "hit any + key," 20 seconds would meet this. If the person indicates that they are still present, + the device should return the user to the exact condition that existed before it asked + the question. + + +
    • + + +
  • 20 hours was chosen as an upper limit because it is longer than a full waking day. + + +
    • + + +
+

In cases where timing is not an intrinsic requirement but giving users control over + timed events would invalidate the outcome, a third party can control the time limits + for the user (for example, granting double time on a test). + + +

+

See also + 2.2.3: No Timing. + +

+
+
+

Benefits

+
    + + +
  • People with physical disabilities often need more time to react, to type and to complete + activities. People with low vision need more time to locate things on screen and + to read. People who are blind and using screen readers may need more time to understand + screen layouts, to find information and to operate controls. People who have cognitive + or language limitations need more time to read and to understand. People who are + deaf and communicate in sign language may need more time to read information printed + in text (which may be a second language for some). + +
    • + + +
  • In circumstances where a sign-language interpreter may be relating audio content to + a user who is deaf, control over time limits is also important. + +
    • + + +
  • People with reading disabilities, cognitive limitations, and learning disabilities + who may need more time to read or comprehend information can have additional time + to read the information by pausing the content. + +
    • + + +
+
+
+

Examples

+
    + + +
  • A Web site uses a client side time limit to help protect users who may step away from + their computer. After a period of inactivity the Web page asks if the user needs + more time. If it doesn't get a response – it times out. + +
    • + + +
  • A Web page has a field that automatically updates with the latest headlines in a rotating + fashion. There is an interactive control that allows the user to extend the length + of time between each update to as much as ten times the default. The control can be + operated with either a mouse or a keyboard. + + +
    • + + +
  • A Web page includes an animation which includes text that appears and disappears throughout. + In some cases, the text is scrolling across the screen and in others, it is only displayed + for a short time before it fades into the background. The page includes a pause button + so that users who have trouble reading the text before it disappears can read it. + +
    • + + +
  • In an auction, there is a time limit on the amount of time a user has to submit a + bid. Since the time limit applies to all users who want to bid on a particular item, + it would be unfair to extend the time limit for any one particular user. Therefore, + a time limit is required for this type of activity and no extension, adjustment, or + deactivation of the time limit is required by this Success Criterion. + + +
    • + + +
  • An on-line ticket-purchasing site gives the user two minutes to confirm a purchase + before the seats are returned to the general pool. Because tickets on such sites can + sell out quickly, holding a ticket longer than that may invalidate the nature of the + site, so this is a case in which the timing is essential and cannot be extended without + invalidating the activity. However, the site does move as much of the process out + of the time-critical period as possible, for instance allowing users to provide necessary + information like name, payment method, etc., before entering the time-critical stage. + + +
    • + + +
  • A ticket-purchasing site allows the user two minutes to confirm purchase of selected + seats, but warns the user when their time is almost out and allows the user to extend + this time limit some number of times with a simple action such as clicking a "Extend + time limit" button. + + +
    • + + +
+
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If there are session time limits:

+ + + + + +
+
+ + +

Situation B: If a time limit is controlled by a script on the page:

+ + + + + +
+
+ + +

Situation C: If there are time limits on reading:

+ + + + + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
essential
+
+ + + +

if removed, would fundamentally change the information or functionality of the content, + and information and functionality cannot be achieved in another way that would conform + +

+ + + +
+
+
+
+

Test Rules

+

The following are Test Rules for certain aspects of this Success Criterion. It is + not necessary to use these particular Test Rules to check for conformance with WCAG, + but they are defined and approved test methods. For information on using Test Rules, + see Understanding Test Rules for WCAG Success Criteria. +

+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/understanding-act-rules.html b/wcag22/understanding/understanding-act-rules.html new file mode 100644 index 0000000..c7fe7f9 --- /dev/null +++ b/wcag22/understanding/understanding-act-rules.html @@ -0,0 +1,335 @@ + + + + + + Understanding Test Rules for WCAG Success Criteria | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding Test Rules for WCAG Success Criteria

+
+ + + +

Test Rules provide guidance for developers of automated testing tools and manual testing + methodologies, to help ensure consistent interpretation of WCAG Success Criteria. +

+ +

W3C's List of Test Rules for WCAG 2 is updated periodically. They are developed according to the Accessibility Conformance Testing (ACT) Rules Format 1.0 standard. +

+ +

Understanding Conformance provides related information, including on understanding accessibility support. +

+ + +
+ +

Test Rules Rules are Informative

+ +

Test Rules are informative — that means they are not required for determining conformance. + The basis for determining conformance to WCAG is the success criteria from the WCAG + standard — not the Test Rules.

+ +

While W3C's List of Test Rules for WCAG 2 are reviewed by the W3C Accessibility Guidelines Working Group (AGWG), they are not + vetted to the same degree as the W3C Web Content Accessibility Guidelines (WCAG) standard + (called W3C Recommendation). The WCAG standard is the normative reference on determining conformance. +

+ +
+ + +
+ +

Test Rules are Partial Checks

+ +

Test Rules typically check specific aspects of WCAG success criteria. For example, + that a table cell has a header rather than the entire WCAG 2.2 success criterion 1.3.1 + "Info and Relationships", which applies to many more information structures on a web + page. In fact, this example rule would not even check the validity of the table header, + only if the header exists for a given table cell. +

+ +

Test Rules are also technology-specific. For example, the aforementioned table header + example would be specific to HTML, possibly enriched with WAI-ARIA roles and properties, + but not to other formats with tables. WCAG 2.2 success criteria are designed to be + technology-agnostic and applicable to all web technologies. +

+ +
+ + +
+ +

Test Rules Check for Failures

+ +

Test Rules are designed to check failures in satisfying WCAG success criteria. That + is, when content fails Test Rules, it means that the content does not satisfy the + corresponding success criteria. However, when content passes Test Rules, it means + that no corresponding failures were detected — it does not necessarily mean that the + content satisfies all aspects of the corresponding success criteria. +

+ +

The reason for this is because WCAG success criteria typically cover several aspects + and technologies, while Test Rules only check specific aspects. Checking that content + satisfies all aspects of WCAG success criteria typically requires further verification + by human testers. +

+ +
+

Note

+

WCAG 2 Conformance Requirement 1 allows for "conforming alternate versions". That means that content may still conform + to WCAG 2, even when content fails Test Rules, thus does not satisfy the corresponding + success criteria. +

+
+ +
+ + + + + +
+ +

Structure of Test Rules

+ +

Test Rules conform to the Accessibility Conformance Testing (ACT) Rules Format 1.0 standard. They include the following parts: +

+ +
    + +
  • Descriptive Title – title for the Test Rule, which should describe the rule +
    • + +
  • Rule Identifier – identifier for the Test Rule; the W3C rules use alphanumeric strings +
    • + +
  • Rule Type – there are two basic types of Test Rules, depending on what is being tested: + +
      + +
    • Atomic Rule – test one specific situation, which may be part of a composite rule +
      • + +
    • Composite Rule – combine outcome from multiple atomic rules to one outcome +
      • + +
    + +
    • + +
  • Accessibility Requirements Mapping – maps the Test Rule to particular accessibility requirements; in this suite of rules + we use Web Content Accessibility Guidelines (WCAG) 2 Success Criteria +
    • + +
  • Rule Input – describes the scope of input into Test Rules, which is one of the following: + +
      + +
    • Input Aspects – input into atomic rules, such as DOM Tree and CSS Styling etc. +
      • + +
    • Input Rules – input into the composite rules, which are the atomic rules in scope +
      • + +
    + +
    • + +
  • Applicability – description of the specific parts of the content, for which the rule applies +
    • + +
  • Expectations – description of the expected characteristics of the applicable rule content +
    • + +
  • Assumptions – assumptions made, such as specific interpretations of the requirements +
    • + +
  • Accessibility Support – known limitations regarding browsers and assistive technology +
    • + +
  • Test Cases – sample code demonstrating passed, failed, and inapplicable rule conditions +
    • + +
  • Change Log – history of changes for the Test Rules, to support backward compatibility +
    • + +
  • Glossary – list of key terms defined by the Test Rule or used by the specific Test Rule +
    • + +
  • Issues List (Optional) – list of known issues or bugs for the particular Test Rule, if any +
    • + +
  • Background (Optional) – relevant background, such as additional documentation, if any +
    • + +
  • Acknowledgements (Optional) – such as rule writers, reviewers, and other contributors +
    • + +
+ +
+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/understanding-metadata.html b/wcag22/understanding/understanding-metadata.html new file mode 100644 index 0000000..468b2f6 --- /dev/null +++ b/wcag22/understanding/understanding-metadata.html @@ -0,0 +1,277 @@ + + + + + + Understanding Metadata | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding Metadata

+
+ + +

This section discusses metadata techniques that can be employed to satisfy WCAG 2.1 + Success Criteria. For more information about metadata see resources below. +

+ +

At its most basic level, metadata is essentially 'data about data' and is used to + both describe and find resources. +

+ +

Metadata is a powerful tool that can be used for describing Web pages and accessible + components of Web pages as well as associating alternate versions of Web content to + each other. These descriptions in turn allows users to locate specific information + they need or prefer. +

+ +

In conjunction with WCAG, metadata can play a number of roles including:

+ +
    + +
  1. + +

    Metadata can be used to associate conforming alternate versions of Web pages with + Web pages which do not conform, in order to allow users to find the conforming alternate + version when they land on a non-conforming page that they cannot use. +

    + +
    2. + +
  2. + +

    Metadata can be used to locate and also to describe alternate pages where there are + multiple versions of a page which have been developed, especially where the alternate + pages are optimized for individuals with different disabilities. The user can use + the metadata both to locate the alternate versions and to identify characteristics + of the versions, so that they can find the one that best meets their needs. +

    + +
    3. + +
  3. + +

    In addition to being used for whole pages (as in #1 and #2 above), metadata can be + used to describe alternate versions of subcomponents of a page. Again, the metadata + can be used to find alternate versions of a Web page component as well as to get descriptions + of the alternate versions (if there are several) in order to determine which one would + best meet the user's needs. +

    + +
    4. + +
+ +
+ +

Metadata Resources

+ +

Metadata descriptions often provide values from defined, agreed vocabularies such + as the resource's subject matter or its date of publication, and are machine readable + - software that understands the metadata scheme in use can do useful tasks not feasible + otherwise. Typically, an object having metadata may have one or more such metadata + descriptions. +

+ +

Well-known specifications (schemas) for metadata include:

+ + + +

There are some tools available to provide resource descriptions, or they can be provided + manually. The more easily the metadata can be created and collected at point of creation + of a resource or at point of publication, the more efficient the process and the more + likely it is to take place. +

+ +

Some examples include:

+ + + +

Accessibility metadata implementations include:

+ + + +
+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/understanding-techniques.html b/wcag22/understanding/understanding-techniques.html new file mode 100644 index 0000000..916b95a --- /dev/null +++ b/wcag22/understanding/understanding-techniques.html @@ -0,0 +1,623 @@ + + + + + + Understanding Techniques for WCAG Success Criteria | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding Techniques for WCAG Success Criteria

+
+ + +

WCAG 2.1 guidelines and success criteria are designed to be broadly applicable to + current and future web technologies, including dynamic applications, mobile, digital + television, etc. They are stable and do not change. +

+ +

Specific guidance for authors and evaluators on meeting the WCAG success criteria + is provided in techniques, which include code examples, resources, and tests. W3C's + Techniques for WCAG 2.1 document is updated periodically, about twice per year, to cover more current best + practices and changes in technologies and tools. +

+ +

The three types of guidance in Techniques for WCAG 2.1 are explained below: +

+ +
    + +
  • + +

    Sufficient techniques

    + +
    • + +
  • + +

    Advisory techniques

    + +
    • + +
  • + +

    Failures

    + +
    • + +
+ +

Also explained below:

+ +
    + +
  • + +

    General and technology-specific techniques - which can be sufficient or advisory

    + +
    • + +
  • + +

    Other techniques - beyond what is in W3C's published document

    + +
    • + +
  • + +

    Technique tests

    + +
    • + +
  • + +

    User agent and assistive technology support

    + +
    • + +
  • + +

    Using the techniques - with important considerations

    + +
    • + +
+ +

Understanding Conformance provides related information, including on understanding accessibility support. +

+ +
+ +

Techniques are Informative

+ +

Techniques are informative—that means they are not required. The basis for determining + conformance to WCAG 2.1 is the success criteria from the WCAG 2.1 standard—not the + techniques.

+ +

Note 1: W3C cautions against requiring W3C's sufficient techniques. The only thing that should + be required is meeting the WCAG 2.1 success criteria. To learn more, see: +

+ + + +

Note 2: Techniques for WCAG 2.1 uses the words "must" and "should" only to clarify guidance within the techniques, + not to convey requirements for WCAG. +

+ +
+ +
+ +

Sufficient Techniques

+ +

Sufficient techniques are reliable ways to meet the success criteria. +

+ +
    + +
  • + +

    From an author's perspective: If you use the sufficient techniques for a given criterion + correctly and it is accessibility-supported for your users, you can be confident that you met the success criterion. +

    + +
    • + +
  • + +

    From an evaluator's perspective: If web content implements the sufficient techniques + for a given criterion correctly and it is accessibility-supported for the content's users, it conforms to that success criterion. (The converse is + not true; if content does not implement these sufficient techniques, it does not necessarily + fail the success criteria, as explained in Testing Techniques below.) +

    + +
    • + +
+ +

There may be other ways to meet success criteria besides the sufficient techniques + in W3C's Techniques for WCAG 2.1 document, as explained in Other Techniques below. (See also Techniques are Informative above.)

+ +
+ +

Numbered Lists, "AND"

+ +

The W3C-documented sufficient techniques are provided in a numbered list where each + list item provides a technique or combination of techniques that can be used to meet + the success criterion. Where there are multiple techniques on a numbered list item + connected by "AND" then all of the techniques must be used to be sufficient. For example, + Sufficient Techniques for 1.3.1 has: "G115: Using semantic elements to mark up structure AND H49: Using semantic + markup to mark emphasized or special text (HTML)". +

+ +
+ +
+ +
+ +

Advisory Techniques

+ +

Advisory techniques are suggested ways to improve accessibility. They are often very helpful to some + users, and may be the only way that some users can access some types of content. +

+ +

Advisory techniques are not designated as sufficient techniques for various reasons + such as: +

+ +
    + +
  • + +

    they may not be sufficient to meet the full requirements of the success criteria;

    + +
    • + +
  • + +

    they may be based on technology that is not yet stable;

    + +
    • + +
  • + +

    they may not be accessibility supported in many cases (for example, assistive technologies do not work with them yet); +

    + +
    • + +
  • + +

    they may not be testable;

    + +
    • + +
  • + +

    in some circumstances they may not be applicable or practical, and may even decrease + accessibility for some users while increasing it for others; +

    + +
    • + +
  • + +

    they may not address the success criterion itself, and instead provide related accessibility + benefits. +

    + +
    • + +
+ +

Authors are encouraged to apply all of the techniques where appropriate to best address + the widest range of users' needs. +

+ +
+ +
+ +

Failures

+ +

Failures are things that cause accessibility barriers and fail specific success criteria. + The documented failures are useful for: +

+ +
    + +
  • + +

    Authors to know what to avoid,

    + +
    • + +
  • + +

    Evaluators to use for checking if content does not meet WCAG success criteria.

    + +
    • + +
+ +

Content that has a failure does not meet WCAG success criteria, unless an alternate version is provided without + the failure. +

+ +

If anyone identifies a situation where a documented failure is not correct, please + report the situation as a WCAG comment so that it can be corrected or deleted as appropriate. +

+ +
+ +
+ +

General and Technology-specific Techniques

+ +

General techniques describe basic practices that apply to all technologies. Technology-specific techniques apply to a specific technology. +

+ +

Some success criteria do not have technology-specific techniques and are covered only + with general techniques. Therefore, both the general techniques and the relevant technology-specific + techniques should be considered. +

+ +

Publication of techniques for a specific technology does not imply that the technology + can be used in all situations to create content that meets WCAG 2.1 success criteria + and conformance requirements. Developers need to be aware of the limitations of specific + technologies and provide content in a way that is accessible to people with disabilities. +

+ +
+ +
+ +

Other Techniques

+ +

In addition to the techniques in W3C's Techniques for WCAG 2.1 document, there are other ways to meet WCAG success criteria. W3C's techniques are not comprehensive and may not cover newer technologies and + situations. +

+ +

Web content does not have to use W3C's published techniques in order to conform to + WCAG 2.1.(See also Techniques are Informative above.)

+ +

Content authors can develop different techniques. For example, an author could develop + a technique for HTML5, WAI-ARIA, or other new technology. Other organizations may develop sets of techniques to meet + WCAG 2.1 success criteria. +

+ +

Any techniques can be sufficient if:

+ + + +
+ +

Submitting Techniques

+ +

The WCAG Working Group encourages people to submit new techniques so that they can + be considered for inclusion in updates of the Techniques for WCAG 2.1 document. Please submit techniques for consideration using the Techniques Submission Form. +

+ +
+ +
+ +
+ +

Testing Techniques

+ +

Each technique has tests that help:

+ +
    + +
  • + +

    authors verify that they implemented the technique properly, and

    + +
    • + +
  • + +

    evaluators determine if web content meets the technique.

    + +
    • + +
+ +

The tests are only for a technique, they are not tests for conformance to WCAG success + criteria. +

+ +
    + +
  • + +

    Failing a technique test does not necessarily mean failing WCAG, because the techniques + are discrete (that is, they address one specific point) and they are not required. +

    + +
    • + +
  • + +

    Content can meet WCAG success criteria in different ways other than W3C's published + sufficient techniques. +

    + +
    • + +
  • + +

    Content that passes the sufficient techniques for a specific technology does not necessarily + meet all WCAG success criteria. Some success criteria have only general techniques, + not technology-specific techniques. +

    + +
    • + +
  • + +

    The content must be accessibility supported for the content's users. Some sufficient techniques require browser, assistive technology, + or other support that some users might not have. +

    + +
    • + +
+ +

Thus while the techniques are useful for evaluating content, evaluations must go beyond + just checking the sufficient technique tests in order to evaluate how content conforms + to WCAG success criteria. +

+ +

Failures are particularly useful for evaluations because they do indicate non-conformance + (unless an alternate version is provided without the failure). +

+ +
+ +
+ +

User Agent and Assistive Technology Support Notes

+ +

Some techniques require that web content users have specific browsers or assistive + technologies in order for the technique to be accessibility-supported. The User Agent and Assistive Technology Support Notes sections of individual techniques include some information to help determine accessibility + support. +

+ +
+ +

Support Notes Change Over Time

+ +

As time passes, the versions of user agents (browsers, etc.) or assistive technologies + listed may not be the current versions. The Working Group may not update most of these + notes as new versions are released. Authors should test techniques with the user agents + and assistive technologies currently available to their users. See also Understanding Accessibility Support. +

+ +
+ +
+ +
+ +

Using the Techniques

+ +

Techniques for WCAG 2.1 is not intended to be used as a stand-alone document. Instead, it is expected that + content authors will usually use How to Meet WCAG 2.1: A customizable quick reference to read the WCAG success criteria, and follow links from there to specific topics + in Understanding WCAG 2.1 and to specific techniques. +

+ +
+ +

Alternatives must meet success criteria

+ +

Some techniques describe how to provide alternate ways for users to get content. For + example, G73: Providing a long description in another location with a link to it that is immediately + adjacent to the non-text content mentions a transcript as an alternative for an audio file. Some alternatives must + also conform to WCAG. For example, the transcript itself must meet all relevant success + criteria. +

+ +
+ +
+ +

Example Code

+ +

The code examples in the techniques are intended to demonstrate only the specific + point discussed in the technique. They might not demonstrate best practice for other + aspects of accessibility, usability, or coding not related to the technique. They + are not intended to be copied and used as the basis for developing web content. +

+ +

Many techniques point to "working examples" that are more robust and may be appropriate + for copying and integrating into web content. +

+ +
+ +
+ +
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/understanding.css b/wcag22/understanding/understanding.css new file mode 100644 index 0000000..f505c2d --- /dev/null +++ b/wcag22/understanding/understanding.css @@ -0,0 +1,201 @@ +/* custom styles for Understanding WCAG 2.0 */ + +body { + max-width: 75em; + } +code { + font-family: monospace; + } +h3.section, h3.terms {font-weight: normal; margin-top: 1.5em; color: #000000; background: inherit;} +h4 {font-weight: bold; margin-bottom: 0; color: #333; background: inherit;} + +.boxed {border: solid #ccc 1px; padding: 0 0 1em; margin: 1em 2em 0 2em} +.boxed p {margin-left: 1em; margin-right: 1em} +.boxed div {margin-left: 0.5em;} +.boxed h4 {font-weight: bold; padding: 0.5em 1em; color: #000000; background: #f0f0f0; margin: 0 0 1em} +.boxed h5 {font-weight: bold; padding: 0.5em; margin: 0} + +div.boxed h3, div.div2 h2, .div3 h3 {color:#000000; font-size: 1.2em;} + +.div3head, .div2head {color:#000000;} + +.resources h3 {margin-bottom: .25em;} + + +dl {margin-left: 0.5em;} +dt {font-weight: bold; margin: .5em 0 0 0} +dd {margin-left: 1em} +dd p {margin-top: 0} + +div.constraint, div.issue, div.note, div.notice, div.example { + margin-left: 1em; + margin-bottom: 0.5em; + margin-top: 0; + padding-top:0; + } + +dl div.note, dl div.example { + margin-top: 0.25em; + margin-left: 0.5em; + } + +ol.enumar { + list-style-type: decimal; + margin-top: 0; + margin-bottom: .25em; + } + +ol.enumla { + list-style-type: lower-alpha; + } + +ol.enumlr { + list-style-type: lower-roman; + } + +ol.enumua { + list-style-type: upper-alpha; + } + +ol.enumur { + list-style-type: upper-roman; + } + +div.div2 dl, dl.keyterms { + margin-left: 1.5em; + } + +p, td { + line-height: 1.4; + margin-left: .5em; + color: #000; + background: inherit; + font-weight: normal; + } + +li { + margin-top: 0; + margin-bottom: 0.25em; + padding-top: 0; + padding-bottom: 0; + } + +li p, dd p { + margin-top: 0; + margin-bottom: 0; + padding-top: 0; + padding-bottom: 0 + } + + + +strong.sc-handle { + font-size: 1em; + } + +dd.prefix p { + margin-bottom: 0; + } + +div.head dt { + margin-top: 0.25em; + } + +dt.label { + padding-top: .5em; + } + +dd p { + margin-left: 0; + } + +div.sc ul, div.sc ol, div.sc div.note, div.div3 ul, div.div3 ol { + display: block; + margin-top: 0; + margin-bottom: 0; +} + +div.sc li, div.sc li p { + padding: 0; + margin: 0; + } + +div.sc { + margin-left: 0; + margin-bottom: 1.5em !important;} + +.termref { + text-decoration:none; + color:#000000; + border-bottom:dotted #585858 1px; /* de-emphasize glossary links */ + background-color: #fff; + } + +a.termref:link, a.termref:visited { + color:#000000; + background : inherit; + } + + a.termref:hover, .termref:active, a.termref:focus { + color:#0000CC; + background : inherit; + } +.sorethumb { + color: red; background: inherit; + } + +a.HTMlink, a.HTMlink:visited, a.HTMlink:hover, a.HTMlink:focus { + font-size: 0.8125em; + padding: 0; + font-weight: normal; + } + +p.prefix { + margin: 0.25em 0 0.5em 0; + padding:0; + } + +div.sc div.note p.prefix { + margin-bottom: 0; +} + + +span.screenreader {position: absolute; left: -10000px} + + div.footer {margin-top: 1em;} + + div.toc hr {display:block;} + hr.divider {display: block; margin-top: 2em;} + + /* Underline headings with .section class */ + +.section, .terms { +border-bottom:thin solid #666666; +display:block; +padding-bottom:0.25em; +} + +p.revnote, div.revnote { +margin:0; +padding:0em; +} +.revnote { +background-color:#F0F8F8; +border:thin solid #A7ABBF; +color:black; +page-break-inside:avoid; +} + +/* @@ copy to slicenav + +*/ + +blockquote.scquote, blockquote.glquote {margin: 1em; border: solid #ccc 1px; background: #f0f0f0; color: #000; padding: 1em;} +blockquote.scquote p, blockquote.glquote p, blockquote.scquote dl, blockquote.glquote dl {font-size: 0.9em} +blockquote.scquote ul li {font-size: 1em;} +blockquote.scquote a:active, blockquote.scquote a:hover, blockquote.scquote a:focus, blockquote.glquote a:active, blockquote.glquote a:hover, blockquote.glquote a:focus {background: #ffa;} + +p.sctxt { + margin: 0.5em 0 0 0.5em; + padding: 0; + } diff --git a/wcag22/understanding/unusual-words.html b/wcag22/understanding/unusual-words.html new file mode 100644 index 0000000..45537ef --- /dev/null +++ b/wcag22/understanding/unusual-words.html @@ -0,0 +1,915 @@ + + + + + + Understanding Success Criterion 3.1.3: Unusual Words | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 3.1.3:Unusual Words (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Users can identify and learn what unusual words mean.
+ +
What to do
+
Provide definitions for technical jargon and unusual terms.
+ +
Why it's important
+
More people, especially those with cognitive disabilities, can understand the meaning + of content. +
+ +
+
+
+

Intent

+

Certain disabilities make it difficult to understand nonliteral word usage and specialized + words or usage. Certain disabilities make it difficult to understand figurative language + or specialized usage. Providing such mechanisms is vital for these audiences. Specialized + information intended for non-specialist readers is encouraged to satisfy this Success + Criterion, even when claiming only Single-A or Double-A conformance. + + + +

+
+
+

Benefits

+

This Success Criterion may help people with cognitive, language and learning disabilities + who: + +

+
    + + +
  • have difficulty decoding words
    • + + +
  • have difficulty understanding words and phrases
    • + + +
  • have difficulty using context to aid understanding
    • + + +
+

It would also help people with visual disabilities who:

+
    + + +
  • lose context when zoomed-in with a screen magnifier
    • + + +
+
+
+

Examples

+
+ +
Text that includes a definition for a word used in an unusual way
+ +
Organize the list or "cascade" of dictionaries and other resources so that the definition + search will find the intended definitions instead of displaying definitions from other + sources in the "cascade." (The "cascade" lists the dictionaries and other reference + materials in the order most likely to bring up the right definition. This controls + the order to follow when searching for definitions.) +
+ +
Including definitions in the glossary
+ +
WCAG 2.0 uses the word "text" in a specific way. Thus, when the word "text" is used + within WCAG 2.0 it is linked to the definition of "text" provided in a glossary within + the same Web page. +
+ +
The specific definition of a word is provided at the bottom of the page
+ +
The internal link from the word to the corresponding definition is also provided within + the page. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+
+

Note

+
+ + +

The inclusion of a product or vendor name in the list below does not constitute an + endorsement by the Web Content Accessibility Guidelines Working Group or the Web Accessibility + Initiative of the World Wide Web Consortium. This list is provided simply for convenience + and to give users an idea of what resources may be available + +

+ + +
+
+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If the word or phrase has a unique meaning within the Web page:

+ + + + + +
+
+ + +

Situation B: If the word or phrase means different things within the same Web page:

+ + + + + +
+
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
idiom
+
+ + + +

phrase whose meaning cannot be deduced from the meaning of the individual words and + the specific words cannot be changed without losing the meaning + +

+ + +
+

Note

+

Idioms cannot be translated directly, word for word, without losing their (cultural + or language-dependent) meaning. + +

+
+ + + + + + + + + + + + +
+
jargon
+
+ + + +

words used in a particular way by people in a particular field

+ + + + + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
used in an unusual or restricted way
+
+ + + +

words used in such a way that requires users to know exactly which definition to apply + in order to understand the content correctly + +

+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/use-of-color.html b/wcag22/understanding/use-of-color.html new file mode 100644 index 0000000..fbcf45b --- /dev/null +++ b/wcag22/understanding/use-of-color.html @@ -0,0 +1,649 @@ + + + + + + Understanding Success Criterion 1.4.1: Use of Color | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.1:Use of Color (Level A) +

+ +
+
+

In Brief

+
+ +
Goal
+
Color is not the only way of distinguishing information.
+ +
What to do
+
Use information in addition to color, such as shape or text, to convey meaning.
+ +
Why it's important
+
Not everyone sees colors or sees them the same way.
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that all sighted users can access + information + that is conveyed by color differences, that is, by the use of color where each color + has a meaning assigned to it. If the information is conveyed through color differences + in an image (or other non-text format), the color may not be seen by users with color + deficiencies. In this case, providing the information conveyed with color through + another visual means ensures users who cannot see color can still perceive the information. + +

+

Color is an important asset in design of Web content, enhancing its aesthetic appeal, + its usability, and its accessibility. However, some users have difficulty perceiving + color. People with partial sight often experience limited color vision, and many older + users do not see color well. In addition, people using limited-color or + monochrome displays and browsers will be unable to access information that is presented + only in color. + +

+

Examples of information conveyed by color differences: “required fields are red", + “error is shown in red", and “Mary's sales are in red, Tom's are in blue". Examples + of indications of an action include: using color to indicate that a link will open + in a new window or that a database entry has been updated successfully. An example + of prompting a response would be: using highlighting on form fields to indicate that + a required field had been left blank. + +

+
+

Note

+
+ + +

This should not in any way discourage the use of color on a page, or even color coding + if it is complemented by other visual indication. + +

+ + +
+
+
+

Note

+
+ + +

If content is conveyed through the use of colors that differ not only in their hue, + but that also have a significant difference in lightness, then this counts as an additional + visual distinction, as long as the difference in relative luminance between the colors + leads + to a contrast ratio of 3:1 or greater. + For example, a light green and a dark red differ both by color (hue) + and by lightness, so they would pass if the contrast ratio is at least 3:1. + Similarly, if content is distinguished by inverting an element's foreground and background + colors, + this would pass (again, assuming that the foreground and background colors have a + sufficient contrast). + +

+ +

However, if content relies on the user's ability to accurately perceive or differentiate + a particular color + an additional visual indicator will be required regardless of the contrast ratio between + those colors. For example, + knowing whether an outline is green for valid or red for invalid. + +

+ + +
+
+
+

Note

+
+ + +

This criterion does not apply to situations where color has not been used to convey information, indicate an action, + prompt a response or distinguish a visual element. For instance, a hyperlink which + has been styled to appear no different than neighboring + static text would not fail this success criterion, as there would be no color differentiation + between the actionable hyperlink text + and the adjacent static text. Such lack of styling differentiation could result in + poor usability for anyone looking at the interface, regardless of disability. + +

+ + +
+
+
+

Note

+
+ + +

This criterion does not directly address the needs of users with assistive technologies. + It aims to ensure that sighted users who cannot distinguish between some colors can + still + understand content. + How information is conveyed to assistive technology users is covered separately in + other + criteria, including (but not limited to) + 1.1.1 Non-text Content, + 1.3.1 Info and Relationships, and + 4.1.2 Name, Role, Value. + +

+ +

Conversely, even if information that is conveyed by color differences is appropriately + conveyed + to assistive technologies, it does not necessarily pass this criterion, as sighted + users who cannot + distinguish between certain color may not necessarily be using any assistive technologies. + This + criterion requires a visible alternative to color. + +

+ + +
+
+
+

Note

+
+ + +

Most user agents provide users with a color-only cue that a link has been previously + activated by them ("visited"). However, several technical constraints result in authors + having very limited control over these color-only indications of visited links. The + technical constraints are as follows: +

+ + +
    + +
  1. + User agents constrain the exposure of a link's visited state due to privacy concerns. Author queries to user agents will indicate all links have not been visited. + +
    2. + +
  2. + Any available information on the visited state of a link would be inaccurate since + it is both user and browser-dependent. Even if an author could accurately get information + on previously activated links by a certain user, the author would be constrained to + the current browser's preserved history, and would be unable to determine if the user + had visited the page using a different browser (or if the history was not preserved, + either from cache clearing or use of private sessions). + +
    3. + +
  3. + Authors can only use color to modify the :visited CSS pseudoclass style. The technology constrains any non-color styling. Due to palette + limitations, an author cannot use color alone to achieve 3:1 contrast between link + and non-link text as well as between visited and unvisited links while also achieving + 4.5:1 contrast for all link and non-link text. + +
    4. + +
  4. + Authors also cannot set the visited state of links. The anchor element does not include + a "visited" attribute; therefore the author has no ability to alter the state through + an attribute setting. As such, authors cannot achieve 1.3.1 Info and Relationships or + 4.1.2 Name, Role, Value in regard to visited links. + +
    5. + +
+ + +

For these reasons, setting or conveying a link's visited status is not an author responsibility. + Where color alone distinguishes between visited and unvisited links, it does not result + in a failure of this Success Criterion, even where the contrast between the two link + colors is below 3:1. Note that authors must continue to ensure that all text links + meet contrast minimums against the page background (SC 1.4.3). +

+ +
+
+
+
+

Benefits

+
    + + +
  • Users with partial sight often experience limited color vision.
    • + + +
  • Some older users may not be able to see color well.
    • + + +
  • Users who have color-blindness benefit when information conveyed by color is available + in other visual ways. + +
    • + + +
  • People using limited color monochrome displays may be unable to access + color-dependent information. + +
    • + + +
  • Users who have problems distinguishing between colors can look or listen for text + cues. + +
    • + + +
+
+
+

Examples

+
+ +
A form that uses color and text to indicate required fields
+ +
A form contains both required and optional fields. Instructions at the top of the + form explain that required fields are labeled with red text and also with an icon. + Users who cannot perceive the difference between the optional field labels and the + red labels for the required fields will still be able to see the icon next to the + red labels. +
+ +
An examination
+ +
Students view an SVG image of a chemical compound and identify the chemical elements + present based both on the colors used, as well as numbers next to each + element. A legend shows the color and number for each type of element. Sighted users + who + cannot perceive all the color differences can still understand the image by relying + on + the numbers. +
+ +
+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

Select the situation below that matches your content. Each situation includes techniques + or combinations of techniques that are known and documented to be sufficient for that + situation. +

+
+ + +

Situation A: If the color of particular words, backgrounds, or other content is used + to indicate information: + +

+ + + + + +
+
+ + +

Situation B: If color is used within an image to convey information:

+ + + + + +
+
+
+

Advisory Techniques

+

Although not required for conformance, the following additional techniques should + be considered in order to make content more accessible. Not all techniques can be + used or would be effective in all situations. +

+ +
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file diff --git a/wcag22/understanding/visual-presentation.html b/wcag22/understanding/visual-presentation.html new file mode 100644 index 0000000..f04b828 --- /dev/null +++ b/wcag22/understanding/visual-presentation.html @@ -0,0 +1,1065 @@ + + + + + + Understanding Success Criterion 1.4.8: Visual Presentation | WAI | W3C + + + + Skip to content
+ +
+
+
+ +
+
+
+ +
+

Understanding + SC 1.4.8:Visual Presentation (Level AAA) +

+ +
+
+

In Brief

+
+ +
Goal
+
Text appearance can be altered by users to meet preferences.
+ +
What to do
+
Meet text display requirements or allow users to adjust them.
+ +
Why it's important
+
Some text formats are more readable for people with cognitive disabilities and low + vision. +
+ +
+
+
+

Intent

+

The intent of this Success Criterion is to ensure that visually rendered text is + presented in such a manner that it can be perceived without its layout interfering + with its readability. People with some cognitive, language and learning disabilities + and some low vision users cannot perceive the text and/or lose their reading place + if the text is presented in a manner that is difficult for them to read. + +

+

People with some visual or cognitive disabilities need to be able to select the color + of text and the color of the background. They sometimes choose combinations that + seem unintuitive to someone without that disability. Sometimes these combinations + have very low contrast. Sometimes only very specific color combinations work for + them. Control of color or other aspects of text presentation makes a huge difference + to their comprehension. + +

+

For people with some reading or vision disabilities, long lines of text can become + a significant barrier. They have trouble keeping their place and following the flow + of text. Having a narrow block of text makes it easier for them to continue on to + the next line in a block. Lines should not exceed 80 characters or glyphs (40 if + CJK), where glyphs are the element of writing in the writing system for the text. + Studies + have shown that Chinese, Japanese and Korean (CJK) characters are approximately twice + as wide as non-CJK characters when both types of characters are displayed with characteristics + that achieve the same readability, so the maximum line width for CJK characters is + half that of non-CJK characters. + +

+

People with some cognitive disabilities find it difficult to track text where the + lines are close together. Providing extra space between lines and paragraphs allows + them to better track the next line and to recognize when they have reached the end + of a paragraph. It is best if there are several different options, for instance, space-and-a-half + and double spacing for line spacing. By space and a half within paragraphs we mean + that top of one line is 150% further from the top of the line below it than would + be true when the text is 'single spaced' (the default spacing for the font). By Paragraph + spacing that is 1.5 times larger than the line spacing we mean that the spacing from + the top of the last line of 1 paragraph is 250% farther from the Top of the first + line of the next paragraph (i.e., that there is a blank line between the two paragraphs + that is 150% of the single space blank line). + +

+

People with certain cognitive disabilities have problems reading text that is both + left and right justified. The uneven spacing between words in fully justified text + can cause "rivers of white" space to run down the page making reading difficult and + in some cases impossible. Text justification can also cause words to be spaced closely + together, so that it is difficult for them to locate word boundaries. + +

+

The resizing provision ensures that visually rendered text (text characters that have + been displayed so that they can be seen [vs. text characters that are still in data + form such as ASCII]) can be scaled successfully without requiring that the user + scroll left and right to see all of the content. When the content has been authored + so that this is possible, the content is said to reflow. This permits people with + low vision and people with cognitive disabilities to increase the size of the text + without becoming disoriented. + +

+

The scaling of content is primarily a user agent responsibility. User agents that + satisfy UAAG 1.0 Checkpoint 4.1 allow users to configure text scale. The author's + responsibility is to create Web content that does not prevent the user agent from + scaling the content and that allows the reflow of the content within the current + width of the viewport. See + 1.4.4: Resize Text for additional discussion of resizing text. + +

+

The horizontal scrolling requirement is not intended to apply to small-screen devices + where long words may be displayed on a single line and require users to scroll horizontally. + For the purposes of this requirement, authors should ensure that content meets this + requirement on standard desktop/laptop displays with the browser window maximized. + Since people generally keep their computers for several years, it is best not to rely + on the latest desktop/laptop display resolutions but to consider the common desktop/laptop + display resolutions over the course of several years when making this evaluation. + +

+

Wrapping should always be possible as long as words are not so long that a single + word is more than half the width of a full screen. Very long URIs may run off the + side of an enlarged screen, but they would not be considered text + for "reading" and, therefore, would not violate this provision. + +

+

This provision does not mean that a user would never need to use horizontal scrolling. + It only means that they would not need to use horizontal scrolling back and forth + to read a line of text. For example, if a page consisted of two equal sized columns + of text, it would automatically meet this provision. Enlarging the page would mean + that the first column was completely on screen and the user could just scroll vertically + down the page to read it. To read the second column, they would horizontally scroll + to the right, where the right hand column would then fit entirely within the width + of the screen, and read that column without further horizontal scrolling. + + +

+
+
+

Benefits

+

This Success Criterion helps low vision users by letting them see text without distracting + presentational features. It lets them configure text in ways that will be easier + for them to see by letting them control the color and size of blocks of text. + +

+

This Success Criterion helps people with cognitive, language and learning disabilities + perceive text and track their location within blocks of text. + +

+
    + + +
  • People with some cognitive disabilities can read text better when they select their + own foreground and background color combinations. + +
    • + + +
  • People with some cognitive disabilities can track their locations more easily when + blocks of text are narrow and when they can configure the amount of space between + lines and paragraphs. + +
    • + + +
  • People with some cognitive disabilities can read text more easily when the spacing + between words is regular. + +
    • + + +
+
+
+

Examples

+
+ +
Figure 1 The following images show examples of single-spacing, space-and-a-half and double-spaced + text in a paragraph. +
+ Example of single-spaced text. (no space between each line of text) + Example of space-and-a-half text. (a space equal to half the height of a line of text line) + Example of double-spaced text. (a space equal to the height of a line of text between each line) + +
+

Examples of glyphs include "A", "→" (an arrow symbol), and "さ" (a Japanese character).

+
+
+

Related Resources

+

Resources are for information purposes only, no endorsement implied.

+ +
+
+

Techniques

+

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 Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section. +

+
+

Sufficient Techniques

+

+ + Instructions: Since this is a multi-part success criterion, you must satisfy one of the numbered + items for each of the requirements below. + +

+
+ + + + + + +
+
+ + + + + + +
+
+ + + + + + +
+
+ + + + + + +
+
+ + + + + + +
+
+
+

Failures

+

The following are common mistakes that are considered failures of this Success Criterion + by the WCAG Working Group. +

+ +
+
+
+
+ +

Key Terms

+ +
assistive technology
+
+ + + +

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements + of users with disabilities that go beyond those offered by mainstream user agents + +

+ + +
+

Note

+

Functionality provided by assistive technology includes alternative presentations + (e.g., as synthesized speech or magnified content), alternative input methods (e.g., + voice), additional navigation or orientation mechanisms, and content transformations + (e.g., to make tables more accessible). + +

+
+ + +
+

Note

+

Assistive technologies often communicate data and messages with mainstream user agents + by using and monitoring APIs. + +

+
+ + +
+

Note

+

The distinction between mainstream user agents and assistive technologies is not absolute. + Many mainstream user agents provide some features to assist individuals with disabilities. + The basic difference is that mainstream user agents target broad and diverse audiences + that usually include people with and without disabilities. Assistive technologies + target narrowly defined populations of users with specific disabilities. The assistance + provided by an assistive technology is more specific and appropriate to the needs + of its target users. The mainstream user agent may provide important functionality + to assistive technologies like retrieving Web content from program objects or parsing + markup into identifiable bundles. + +

+
+ + + + + +
+
blocks of text
+
+ + + +

more than one sentence of text

+ + + +
+
conformance
+
+ + + +

satisfying all the requirements of a given standard, guideline or specification

+ + + +
+
mechanism
+
+ + + +

+ process or technique for achieving a result + +

+ + +
+

Note

+

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies. + +

+
+ + +
+

Note

+

The mechanism needs to meet all success criteria for the conformance level claimed.

+
+ + + +
+
on a full-screen window
+
+ + + +

on the most common sized desktop/laptop display with the viewport maximized

+ + +
+

Note

+

Since people generally keep their computers for several years, it is best not to rely + on the latest desktop/laptop display resolutions but to consider the common desktop/laptop + display resolutions over the course of several years when making this evaluation. + +

+
+ + + +
+
process
+
+ + + +

series of user actions where each action is required in order to complete an activity

+ + + + + + + + + +
+
relied upon
+
+ + + +

the content would not conform if that technology is turned off or is not supported + +

+ + + +
+
technology
+
+ + + +

+ mechanism for encoding instructions to be rendered, played or executed by user agents + +

+ + +
+

Note

+

As used in these guidelines "Web Technology" and the word "technology" (when used + alone) both refer to Web Content Technologies. + +

+
+ + +
+

Note

+

Web content technologies may include markup languages, data formats, or programming + languages that authors may use alone or in combination to create end-user experiences + that range from static Web pages to synchronized media presentations to dynamic Web + applications. + +

+
+ + + + + + +
+
user agent
+
+ + + +

any software that retrieves and presents Web content for users

+ + + + + + +
+
+
+ Back to Top +
+ +
+ + + + + \ No newline at end of file