From 719d2425a234df457c9986902ea124003fb2ad99 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Tue, 17 Feb 2026 23:16:38 +0000 Subject: [PATCH 1/8] Don't just refer to SCs by their number, don't use colon For consistency: * don't use a colon between the SC number and its title * don't just refer to SCs by number alone --- 11ty/README.md | 12 ++++++------ README.md | 2 +- guidelines/relative-luminance.html | 2 +- guidelines/sc/20/non-text-content.html | 2 +- guidelines/sc/20/section-headings.html | 2 +- guidelines/sc/20/timing-adjustable.html | 2 +- guidelines/terms/20/contrast-ratio.html | 6 +++--- guidelines/terms/20/relative-luminance.html | 2 +- techniques/client-side-script/SCR29.html | 2 +- techniques/css/C30.html | 2 +- techniques/failures/F103.html | 2 +- techniques/failures/F105.html | 2 +- techniques/failures/F107.html | 2 +- techniques/failures/F109.html | 4 ++-- techniques/failures/F112.html | 2 +- techniques/failures/F23.html | 4 ++-- techniques/failures/F37.html | 2 +- techniques/failures/F42.html | 4 ++-- techniques/failures/F46.html | 2 +- techniques/failures/F54.html | 4 ++-- techniques/failures/F70.html | 2 +- techniques/failures/F75.html | 2 +- techniques/failures/F77.html | 2 +- techniques/failures/F83.html | 4 ++-- techniques/failures/F84.html | 2 +- techniques/failures/F86.html | 2 +- techniques/failures/F94.html | 2 +- techniques/flash/FLASH5.html | 2 +- techniques/general/G1.html | 2 +- techniques/general/G103.html | 2 +- techniques/general/G126.html | 2 +- techniques/general/G134.html | 2 +- techniques/general/G139.html | 2 +- techniques/general/G141.html | 2 +- techniques/general/G167.html | 2 +- techniques/general/G174.html | 6 +++--- techniques/general/G182.html | 3 +-- techniques/general/G183.html | 4 ++-- techniques/general/G192.html | 4 ++-- techniques/general/G211.html | 4 ++-- techniques/general/G62.html | 2 +- techniques/html/H2.html | 2 +- techniques/html/H70.html | 2 +- techniques/html/H74.html | 2 +- techniques/html/H75.html | 2 +- techniques/html/H93.html | 2 +- techniques/html/H94.html | 2 +- techniques/html/H95.html | 2 +- ...description-or-media-alternative-prerecorded.html | 4 +++- understanding/20/audio-description-prerecorded.html | 4 +++- .../20/audio-only-and-video-only-prerecorded.html | 2 +- understanding/20/captions-live.html | 2 +- understanding/20/captions-prerecorded.html | 2 +- understanding/20/consistent-identification.html | 4 ++-- understanding/20/contrast-enhanced.html | 8 ++++---- understanding/20/contrast-minimum.html | 6 +++--- understanding/20/error-identification.html | 4 ++-- understanding/20/error-prevention-all.html | 3 ++- understanding/20/error-suggestion.html | 2 +- understanding/20/focus-order.html | 3 ++- understanding/20/headings-and-labels.html | 8 ++++---- understanding/20/info-and-relationships.html | 5 ++--- understanding/20/labels-or-instructions.html | 6 +++--- understanding/20/language-of-page.html | 2 +- understanding/20/language-of-parts.html | 2 +- understanding/20/link-purpose-in-context.html | 8 +++++--- understanding/20/link-purpose-link-only.html | 6 ++++-- understanding/20/media-alternative-prerecorded.html | 4 +++- understanding/20/name-role-value.html | 4 ++-- understanding/20/navigable.html | 5 ++--- understanding/20/page-titled.html | 5 +++-- understanding/20/parsing.html | 2 +- understanding/20/pause-stop-hide.html | 2 +- understanding/20/resize-text.html | 2 +- understanding/20/three-flashes.html | 7 ++++--- understanding/20/timing-adjustable.html | 2 +- understanding/20/visual-presentation.html | 2 +- understanding/21/identify-input-purpose.html | 2 +- understanding/21/pointer-gestures.html | 2 +- .../22/accessible-authentication-enhanced.html | 2 +- .../22/accessible-authentication-minimum.html | 2 +- understanding/22/consistent-help.html | 2 +- understanding/22/focus-appearance.html | 4 ++-- understanding/22/focus-not-obscured-enhanced.html | 2 +- understanding/22/focus-not-obscured-minimum.html | 2 +- understanding/understanding-techniques.html | 2 +- 86 files changed, 139 insertions(+), 128 deletions(-) diff --git a/11ty/README.md b/11ty/README.md index 9f4b64074f..43a2ab025b 100644 --- a/11ty/README.md +++ b/11ty/README.md @@ -71,14 +71,14 @@ The following list outlines properties available on each technique object: - May be empty string (`""`), in which case the subsequent "of" is dropped - `usingPrefix` - Adds text to appear before `usingConjunction` - `skipUsingPhrase` - Omits the entire "... using ... of the following techniques" phrase - - This is mainly an escape hatch for rare instances where a child list is used but no "using" phrase appears at all (e.g. in 1.4.4: Resize Text) + - This is mainly an escape hatch for rare instances where a child list is used but no "using" phrase appears at all (e.g. in 1.4.4 Resize Text) Typically, either `id` or `title` is required. If `id` is specified, then `prefix` and/or `suffix` may also be specified (with HTML flow content allowed in each), resulting in "{prefix} {linked technique title} {suffix}". In extremely rare cases, `using` may be specified alone without either `id` or `title`, -e.g. for top-level "Using two or more of the following" in 2.4.5: Multiple Ways. +e.g. for top-level "Using two or more of the following" in 2.4.5 Multiple Ways. #### Conjunctions @@ -87,7 +87,7 @@ To represent multiple parallel techniques, an `and` key may be specified instead - `and` - an array of technique objects or shorthand strings (as described above) - `using` and its related fields (seen above) may optionally be specified alongside `and` - `andConjunction` may optionally be specified alongside `and`, - to override the default `"AND"` phrasing (e.g. in 4.1.3: Status Messages) + to override the default `"AND"` phrasing (e.g. in 4.1.3 Status Messages) - Techniques listed _within_ `and` should be flat, never containing `and` or `using` ### Situations or Other Subsections (Sufficient only) @@ -96,19 +96,19 @@ The top level of the `sufficient` array may consist entirely of either technique or subsection entries. It should not contain a mix of both. Subsections are typically used to define multiple "situations", where each title begins with "Situation A:", "Situation B:", etc.; -in rare cases it is used for other purposes, e.g. in 1.4.8: Visual Presentation. +in rare cases it is used for other purposes, e.g. in 1.4.8 Visual Presentation. Subsection entries contain the following: - `title` (required, HTML allowed) - `techniques` (required) - array of technique entries (see above) -- `note` (optional, HTML allowed) - content to appear in a Note at the end of the subsection (e.g. in 4.1.3: Status Messages) +- `note` (optional, HTML allowed) - content to appear in a Note at the end of the subsection (e.g. in 4.1.3 Status Messages) - `groups` (optional) - array of objects with `id`, `title`, `techniques`; see more below - `techniques` within `groups` are not expected to involve `and` or `using` #### Groups within Situations -Most of the situations in 1.1.1: Non-text Content include groupings which start with a boldface paragraph (not a heading), +Most of the situations in 1.1.1 Non-text Content include groupings which start with a boldface paragraph (not a heading), and are referenced one or more times within preceding "using" clauses. Groups can be defined at the top level of each situation/section entry as mentioned above. Defining `groups` automatically implies a "using" relationship, without explicitly defining `using` for each technique. diff --git a/README.md b/README.md index cabe160a62..f237ac1788 100644 --- a/README.md +++ b/README.md @@ -178,7 +178,7 @@ Obsolete techniques should not be removed from the repository. Instead, they can --- obsoleteSince: 22 obsoleteMessage: | - This failure relates to 4.1.1: Parsing, which was removed as of WCAG 2.2. + This failure relates to 4.1.1 Parsing, which was removed as of WCAG 2.2. --- ``` diff --git a/guidelines/relative-luminance.html b/guidelines/relative-luminance.html index 634fbcb7ad..17d0400e63 100644 --- a/guidelines/relative-luminance.html +++ b/guidelines/relative-luminance.html @@ -342,7 +342,7 @@

MathML version of the relative luminance definition

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. + authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3 Contrast (Minimum).

Note

If dithering occurs after delivery, then the source color value is used. For colors diff --git a/guidelines/sc/20/non-text-content.html b/guidelines/sc/20/non-text-content.html index bc59554336..cb1fc458b6 100644 --- a/guidelines/sc/20/non-text-content.html +++ b/guidelines/sc/20/non-text-content.html @@ -13,7 +13,7 @@

Non-text Content

-

If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.) +

If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 Name, Role, for additional requirements for controls and content that accepts user input.)

diff --git a/guidelines/sc/20/section-headings.html b/guidelines/sc/20/section-headings.html index 82a672677c..e7266e432f 100644 --- a/guidelines/sc/20/section-headings.html +++ b/guidelines/sc/20/section-headings.html @@ -11,7 +11,7 @@

Section Headings

heading to different types of content.

-

This success criterion covers sections within writing, not user interface components. User interface components are covered under Success Criterion 4.1.2. +

This success criterion covers sections within writing, not user interface components. User interface components are covered under Success Criterion 4.1.2 Name, Role, Value.

diff --git a/guidelines/sc/20/timing-adjustable.html b/guidelines/sc/20/timing-adjustable.html index cb371fa19b..6c0c3f26c9 100644 --- a/guidelines/sc/20/timing-adjustable.html +++ b/guidelines/sc/20/timing-adjustable.html @@ -68,7 +68,7 @@

Timing Adjustable

This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion - should be considered in conjunction with Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action. + should be considered in conjunction with Success Criterion 3.2.1 On Focus, which puts limits on changes of content or context as a result of user action.

diff --git a/guidelines/terms/20/contrast-ratio.html b/guidelines/terms/20/contrast-ratio.html index 66a1d522e9..2a4a2cd7c8 100644 --- a/guidelines/terms/20/contrast-ratio.html +++ b/guidelines/terms/20/contrast-ratio.html @@ -20,9 +20,9 @@ evaluated with anti-aliasing turned off.

-

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

For the purpose of Success Criteria 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced), + 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.

Background color is the specified color of content over which the text is to be rendered diff --git a/guidelines/terms/20/relative-luminance.html b/guidelines/terms/20/relative-luminance.html index a071088136..a5c539db6b 100644 --- a/guidelines/terms/20/relative-luminance.html +++ b/guidelines/terms/20/relative-luminance.html @@ -45,7 +45,7 @@

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. + authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3 Contrast (Minimum).

If dithering occurs after delivery, then the source color value is used. For colors diff --git a/techniques/client-side-script/SCR29.html b/techniques/client-side-script/SCR29.html index 732db394ae..348a7c6b28 100644 --- a/techniques/client-side-script/SCR29.html +++ b/techniques/client-side-script/SCR29.html @@ -21,7 +21,7 @@

Description

When the tabindex attribute has the value 0, the element can be focused via the keyboard and is included in the tab order of the document. When the tabindex attribute has the value -1, the element cannot be tabbed to, but focus can be set programmatically, using element.focus().

Because static HTML elements do not have actions associated with them, it is not possible to provide a backup implementation or explanation in environments in which scripting is not available. This technique should only be used in environments in which client-side scripting can be relied upon.

-

Such user interface controls must still satisfy Success Criterion 4.1.2. Applying this technique without also providing role, name, and state information about the user interface control will results in Failure F59, Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML.

+

Such user interface controls must still satisfy Success Criterion 4.1.2. Applying this technique without also providing role, name, and state information about the user interface control will results in Failure F59, Failure of Success Criterion 4.1.2 Name, Role, Value due to using script to make div or span a user interface control in HTML.

diff --git a/techniques/css/C30.html b/techniques/css/C30.html index f942f17853..c84128cc75 100644 --- a/techniques/css/C30.html +++ b/techniques/css/C30.html @@ -18,7 +18,7 @@

When to Use

Description

The objective of this technique is to demonstrate how CSS can be used to replace structured HTML text with images of text in a way that makes it possible for users to view content according to their preferences. To use this technique, an author starts by creating an HTML page that uses semantic elements to mark up the structure of the page. The author then designs two or more stylesheets for that page. One stylesheet presents the HTML text as text and the second uses CSS features to replace some of the HTML text with images of text. Finally, through the use of server-side or client-side scripting, the author provides a control that allows the user to switch between the available views.

-

This technique can be used to meet Success Criterion 1.4.5 or 1.4.9 if a presentation that does not include images of text is available and as long as the user interface control that is provided to allow users to switch to an alternate presentation meets the relevant criteria. Where possible, authors should deliver the presentation that does not include images of text as the default presentation. In addition, the control used to switch should be located near the beginning of the page.

+

This technique can be used to meet Success Criterion 1.4.5 Images of Text or 1.4.9 Images of Text (No Exception) if a presentation that does not include images of text is available and as long as the user interface control that is provided to allow users to switch to an alternate presentation meets the relevant criteria. Where possible, authors should deliver the presentation that does not include images of text as the default presentation. In addition, the control used to switch should be located near the beginning of the page.

A variety of "image replacement" techniques have been developed to address a variety of user agent, configuration and compatibility with assistive technology issues (See resources for more information). While there are a variety of approaches authors may use to replace text, it is important to consider compatibility with assistive technology, whether the technique will work correctly if scripting, CSS, images (or combinations of these) are turned off. Since it can be difficult to find a single solution that works in all cases, this technique recommends the use of a control that allows users to switch to a presentation that does not include an image replacement technique.

This technique can be used in combination with a style switching technique to present a page that is a conforming alternate version for non-conforming content. Refer to C29 and Understanding Conforming Alternate Versions for more information.

diff --git a/techniques/failures/F103.html b/techniques/failures/F103.html index 4b3e29c807..ac852e607a 100644 --- a/techniques/failures/F103.html +++ b/techniques/failures/F103.html @@ -29,7 +29,7 @@

Description

  • the new content does not take focus (does not change context);
  • the new content provides information to the user on the outcome of an action, the state of an application, the progress of a process, or the existence of errors.
    • - Where updated content does not conform to the definition of status messages, a failure of 4.1.3 has not taken place.

    + Where updated content does not conform to the definition of status messages, a failure of 4.1.3 Status Messages has not taken place.

    The second step in this failure technique involves examining code. Where dynamic content meets the definition of a status message, its container can be examined for an appropriate WAI-ARIA role or property which allows it to be programmatically determinable as a status message. Currently there are only a small number of techniques available to indicate status messages to assistive technologies. They are:

    • the HTML output element
      • diff --git a/techniques/failures/F105.html b/techniques/failures/F105.html index 29b9cc51d0..d0030696f3 100644 --- a/techniques/failures/F105.html +++ b/techniques/failures/F105.html @@ -49,7 +49,7 @@

      Expected Results

      diff --git a/techniques/failures/F107.html b/techniques/failures/F107.html index 1c0e45da68..50985975c1 100644 --- a/techniques/failures/F107.html +++ b/techniques/failures/F107.html @@ -19,7 +19,7 @@

      Applicability

      Description

      The purpose of this technique is to identify a failure condition where form inputs do not have the correct autocomplete attribute values for inputs that request information about the user of the form.

      -

      Success Criterion 1.3.5 uses a fixed list of tokens in Input Purposes for user interface components (based on the HTML 5.2 autocomplete attribute's fixed list of token values) because the programmatic association of specified token values (metadata) allows for other machine processing, such as expressing the input label in different modalities.

      +

      Success Criterion 1.3.5 Identify Input Purpose uses a fixed list of tokens in Input Purposes for user interface components (based on the HTML 5.2 autocomplete attribute's fixed list of token values) because the programmatic association of specified token values (metadata) allows for other machine processing, such as expressing the input label in different modalities.

      Another important part of this success criterion is that the token values are associated with inputs that are scoped directly to the primary end user.

    diff --git a/techniques/failures/F109.html b/techniques/failures/F109.html index a00e34f7fb..1dcd88853e 100644 --- a/techniques/failures/F109.html +++ b/techniques/failures/F109.html @@ -21,7 +21,7 @@

    Failure of Success Criterion 3.3.8 and 3.3.9 due to preventing password or c

    Description

    -

    Requiring users to authenticate by entering a password or code in a different format from which it was originally created is a failure to meet Success Criteria 3.3.8 and 3.3.9 (unless alternative authentication methods are available). The string to be entered could include a password, verification code, or any string of characters the user has to remember or record to authenticate.

    +

    Requiring users to authenticate by entering a password or code in a different format from which it was originally created is a failure to meet Success Criteria 3.3.8 Accessible Authentication (Minimum) and 3.3.9 Accessible Authentication (Enhanced) (unless alternative authentication methods are available). The string to be entered could include a password, verification code, or any string of characters the user has to remember or record to authenticate.

    If a user is required to enter individual characters across multiple fields in a way that prevents pasting the password in a single action, it prevents use of a password manager or pasting from local copy of the password. This means users cannot avoid transcription, resulting in a cognitive function test. This applies irrespective of whether users are required to enter all characters in the string, or just a subset.

    @@ -42,7 +42,7 @@

    Examples

    For each form field which accepts password or code entry:

    1. Check if the structure of the input field(s) prevents the user from pasting or auto-filling the entire password or code in the format in which it was originally created.
      2. -
    2. Confirm that no other acceptable authentication methods are present that satisfy Success Criteria 3.3.8 or 3.3.9 (such as an authentication method that does not rely on a cognitive function test).
      3. +
    3. Confirm that no other acceptable authentication methods are present that satisfy Success Criteria 3.3.8 Accessible Authentication (Minimum) or 3.3.9 Accessible Authentication (Enhanced) (such as an authentication method that does not rely on a cognitive function test).

    Expected Results

    diff --git a/techniques/failures/F112.html b/techniques/failures/F112.html index ded5cde8c7..0df4c221fa 100644 --- a/techniques/failures/F112.html +++ b/techniques/failures/F112.html @@ -17,7 +17,7 @@

    When to Use

    Description

    -

    Blinking content can be distracting and overwhelming for users, for example people with cognitive disabilities such as attention disorders. Content that automatically starts to blink or "flash", for five seconds or more, is presented in parallel with other content, and does not have a method to stop the blinking fails Success Criterion 2.2.2.

    +

    Blinking content can be distracting and overwhelming for users, for example people with cognitive disabilities such as attention disorders. Content that automatically starts to blink or "flash", for five seconds or more, is presented in parallel with other content, and does not have a method to stop the blinking fails Success Criterion 2.2.2 Pause, Stop, Hide.

    Examples

    diff --git a/techniques/failures/F23.html b/techniques/failures/F23.html index 54791c8875..0b756d05a5 100644 --- a/techniques/failures/F23.html +++ b/techniques/failures/F23.html @@ -17,7 +17,7 @@

    When to Use

    Description

    This describes a failure condition for Success Criteria involving sound. If sound does not turn off automatically within 3 seconds and there is no way to turn the - sound off, independently from the overall system volume level, then Success Criterion 1.4.2 would not be met. + sound off, independently from the overall system volume level, then Success Criterion 1.4.2 Audio Control would not be met. The sound would fall within this failure condition.

    @@ -46,7 +46,7 @@

    Tests

    Expected Results

      -
    • If check #1 is not true then content fails Success Criterion 1.4.2
      • +
    • If check #1 is not true then content fails Success Criterion 1.4.2 Audio Control
    diff --git a/techniques/failures/F37.html b/techniques/failures/F37.html index 2cdb0705ab..8320e60c89 100644 --- a/techniques/failures/F37.html +++ b/techniques/failures/F37.html @@ -57,7 +57,7 @@

    Expected Results

    If check #3 is false, then this failure condition applies and content fails the success criterion.

    -
    Note that in the case of a set of radio buttons, it will pass the requirements of 3.2.2 if an indication or warning is added stating that selecting a radio button will result in a change of context; however, +
    Note that in the case of a set of radio buttons, it will pass the requirements of 3.2.2 On Input if an indication or warning is added stating that selecting a radio button will result in a change of context; however, this scenario would still likely fail 2.1.1 Keyboard, since it's not possible (in current user agents) for a user to navigate through a set of radio buttons with the keyboard without triggering a change event.
    diff --git a/techniques/failures/F42.html b/techniques/failures/F42.html index 8c1f166e52..031642d6a5 100644 --- a/techniques/failures/F42.html +++ b/techniques/failures/F42.html @@ -111,8 +111,8 @@

    Scripting a div element

    Expected Results

      -
    • If check #1 is false then this failure condition applies and the content fails Success Criteria 1.3.1 and 4.1.2. - If check #2 is false then this failure condition applies and the content fails Success Criteria 2.1.1 and 2.1.3.
      • +
    • If check #1 is false then this failure condition applies and the content fails Success Criteria 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value. + If check #2 is false then this failure condition applies and the content fails Success Criteria 2.1.1 Keyboard and 2.1.3 Keyboard (No Exception).

    Examples

    @@ -35,7 +35,7 @@

    An image that responds to a mouse click to go to another page

    Expected Results

    • If check #1 is true, then this failure condition applies and content fails Success Criterion 2.1.3.
      • -
    • If check #1 is true and check #2 is false, then this failure condition applies and content fails Success Criteria 2.1.1 and 2.1.3.
      • +
    • If check #1 is true and check #2 is false, then this failure condition applies and content fails Success Criteria 2.1.1 Keyboard and 2.1.3 Keyboard (No Exceptions).
    diff --git a/techniques/failures/F70.html b/techniques/failures/F70.html index 2e98601f58..1a231e55e9 100644 --- a/techniques/failures/F70.html +++ b/techniques/failures/F70.html @@ -1,6 +1,6 @@ --- obsoleteMessage: | - This failure relates to 4.1.1: Parsing, which was removed as of WCAG 2.2. + This failure relates to 4.1.1 Parsing, which was removed as of WCAG 2.2. obsoleteSince: 22 --- Failure of Success Criterion 4.1.1 due to incorrect use of start and end tags or attribute markup

    Failure of Success Criterion 4.1.1 due to incorrect use of start and end tags or attribute markup

    ID: F70

    Technology: failures

    Type: Failure

    When to Use

    diff --git a/techniques/failures/F75.html b/techniques/failures/F75.html index 1172bf7309..ef93be9563 100644 --- a/techniques/failures/F75.html +++ b/techniques/failures/F75.html @@ -1,7 +1,7 @@ Failure of Success Criterion 1.2.2 by providing synchronized media without captions when the synchronized media presents more information than is presented on the page

    Failure of Success Criterion 1.2.2 by providing synchronized media without captions when the synchronized media presents more information than is presented on the page

    ID: F75

    Technology: failures

    Type: Failure

    When to Use

    Any technology.

    Description

    -

    The objective of this failure is to avoid situations in which synchronized media alternatives provide more information than the text for which they are alternatives, but do not provide their own text alternatives to provide access to the extra information. Synchronized media alternatives provide enhanced access to users for whom synchronized media is a more effective format than text. Since they are alternatives to text, they do not need themselves to have redundant text alternatives in the form of captions, audio descriptions or full text alternatives. However, if they provide more information than the text for which they are an alternative, then they are not just alternatives but are synchronized media content in their own right. In this case they are subject to the full requirements of Success Criterion 1.2.2 to provide captions and to Success Criterion 1.2.3, and Success Criterion 1.2.5.

    +

    The objective of this failure is to avoid situations in which synchronized media alternatives provide more information than the text for which they are alternatives, but do not provide their own text alternatives to provide access to the extra information. Synchronized media alternatives provide enhanced access to users for whom synchronized media is a more effective format than text. Since they are alternatives to text, they do not need themselves to have redundant text alternatives in the form of captions, audio descriptions or full text alternatives. However, if they provide more information than the text for which they are an alternative, then they are not just alternatives but are synchronized media content in their own right. In this case they are subject to the full requirements of Success Criterion 1.2.2 Captions (Prerecorded) to provide captions, Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded), and Success Criterion 1.2.5 Audio Description (Prerecorded).

    Examples

    Tests

    Procedure

      diff --git a/techniques/failures/F77.html b/techniques/failures/F77.html index 90caaa74a8..532770d57f 100644 --- a/techniques/failures/F77.html +++ b/techniques/failures/F77.html @@ -1,6 +1,6 @@ --- obsoleteMessage: | - This failure relates to 4.1.1: Parsing, which was removed as of WCAG 2.2. + This failure relates to 4.1.1 Parsing, which was removed as of WCAG 2.2. obsoleteSince: 22 --- Failure of Success Criterion 4.1.1 due to duplicate values of type ID

      Failure of Success Criterion 4.1.1 due to duplicate values of type ID

      ID: F77

      Technology: failures

      Type: Failure

      When to Use

      diff --git a/techniques/failures/F83.html b/techniques/failures/F83.html index 236b177ae6..42334a3e04 100644 --- a/techniques/failures/F83.html +++ b/techniques/failures/F83.html @@ -2,7 +2,7 @@

      Any technology

      Description

      This failure occurs when people with low vision are not able to read text that is displayed over a background image. When there is not sufficient contrast between the background image and the text, features of the background image can be confused with the text making it difficult to accurately read the text.

      -

      To satisfy Success Criterion 1.4.3 and 1.4.6, there must be sufficient contrast between the text and its background. For pictures, this means that there would need to be sufficient contrast between the text and those parts of the image that are most like the text and behind the text.

      +

      To satisfy Success Criterion 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced), there must be sufficient contrast between the text and its background. For pictures, this means that there would need to be sufficient contrast between the text and those parts of the image that are most like the text and behind the text.

      Examples

      Failure Example 1

      @@ -20,7 +20,7 @@

      Failure Example 2

      Procedure

      1. - Quickcheck: First do a quick check to see if the contrast between the text and the area of the image that is darkest (for dark text) or lightest (for light text) meets or exceeds that required by the Success Criterion (1.4.3 or 1.4.5). If the contrast meets or exceeds the specified contrast, then there is no failure.
        2. + Quickcheck: First do a quick check to see if the contrast between the text and the area of the image that is darkest (for dark text) or lightest (for light text) meets or exceeds that required by the Success Criterion (1.4.3 Contrast (Minimum) or 1.4.6 Contrast (Enhanced)). If the contrast meets or exceeds the specified contrast, then there is no failure.
      2. If the Quickcheck is false, then check to see if the background behind each letter has sufficient contrast with the letter.
      diff --git a/techniques/failures/F84.html b/techniques/failures/F84.html index cc5bfd9b3e..feeaf7e703 100644 --- a/techniques/failures/F84.html +++ b/techniques/failures/F84.html @@ -2,7 +2,7 @@

      HTML

      Description

      This failure describes a common condition where links such as "click here" or "more" are used as anchor elements where you need to have the surrounding text to understand their purpose and where there isn't any mechanism to make the destination clear by itself, such as a button to expand the link text.

      -

      Many blind people who use screen readers call up a dialog box that has a list of links from the page. They use this list of links to decide where they will go. But if many of the links in that list simply say "click here" or "more" they will be unable to use this feature in their screen reader, which is a core navigation strategy. That's why it's a failure of 2.4.9 to not provide any way of allowing them to know the destination from the link text alone. It is also true for people who tab through links. If all they hear as they tab through the document is "click here, click here, click here etc." they will become confused.

      +

      Many blind people who use screen readers call up a dialog box that has a list of links from the page. They use this list of links to decide where they will go. But if many of the links in that list simply say "click here" or "more" they will be unable to use this feature in their screen reader, which is a core navigation strategy. That's why it's a failure of 2.4.9 Link Purpose (Link Only) to not provide any way of allowing them to know the destination from the link text alone. It is also true for people who tab through links. If all they hear as they tab through the document is "click here, click here, click here etc." they will become confused.

      Examples

      <a href="file110.html">Click here</a> for more information on the Rocky Mountains.
      diff --git a/techniques/failures/F86.html b/techniques/failures/F86.html index bd78c56127..4f9eaf537e 100644 --- a/techniques/failures/F86.html +++ b/techniques/failures/F86.html @@ -1,7 +1,7 @@ Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part form field, such as a US telephone number

      Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part form field, such as a US telephone number

      ID: F86

      Technology: failures

      Type: Failure

      When to Use

      General

      Description

      -

      This describes a failure condition of Success Criterion 4.1.2 where some or all of the parts of multi-part form field do not have names. Often there is a label for the multi-part field, which is either programmatically associated with the first part, or not programmatically associated with any parts.

      +

      This describes a failure condition of Success Criterion 4.1.2 Name, Role, Value where some or all of the parts of multi-part form field do not have names. Often there is a label for the multi-part field, which is either programmatically associated with the first part, or not programmatically associated with any parts.

      A name does not necessarily have to be visible, but is visible to assistive technologies.

      diff --git a/techniques/failures/F94.html b/techniques/failures/F94.html index 6d212e627d..57f3c94865 100644 --- a/techniques/failures/F94.html +++ b/techniques/failures/F94.html @@ -19,7 +19,7 @@

      Metadata

      Description

      The objective of this technique is to document the failure of text to re-scale when viewport units are used on text. As these units are relative to the viewport, it means they cannot be resized by zooming or adjusting text-size.

      There are various methods to increase and decrease the size of text and other content, but viewport units applied to text (generally via font-size in CSS) prevent most available methods. Attempts to use browser controls to zoom or adjust text-size will not work. Only methods that completely override the CSS will work, and those could cause other issues such as layouts collapsing or text overlapping.

      -

      Some uses of viewport units may not prevent text-size adjustments, but if they are used as the primary method for defining text-size, they are likely to cause a failure of Success Criterion 1.4.4.

      +

      Some uses of viewport units may not prevent text-size adjustments, but if they are used as the primary method for defining text-size, they are likely to cause a failure of Success Criterion 1.4.4 Resize Text.

      If media queries were used to adjust the size of text or unit of measure at different screen sizes, it may not be a failure of Resize Text. On-page controls provided by the author are also a way of passing the resize text success criteria.

      diff --git a/techniques/flash/FLASH5.html b/techniques/flash/FLASH5.html index ae21a727d9..0ccb15c4a2 100644 --- a/techniques/flash/FLASH5.html +++ b/techniques/flash/FLASH5.html @@ -5,7 +5,7 @@

      Description

      The objective of this technique is to avoid unnecessary duplication that occurs when adjacent text and iconic versions of a button are contained in a Flash movie.

      -

      Many kinds of buttons have both a text and iconic button adjacent to each other. Often the text and the icon button are rendered in separate buttons, in part to create a slight visual separation from each other. Although the sighted user can see this slight visual separation, a blind or low vision user may not be able to recognize the separation, and be confused by the redundant buttons. To avoid this, some authors omit specifying the accessible name for the image, but this would fail Success Criterion 1.1.1 because the text alternative would not serve the same purpose as the graphical button. The preferred method to address this is to put the text and image together in one button symbol instance, and provide a single accessible name for the button to eliminate duplication of text.

      +

      Many kinds of buttons have both a text and iconic button adjacent to each other. Often the text and the icon button are rendered in separate buttons, in part to create a slight visual separation from each other. Although the sighted user can see this slight visual separation, a blind or low vision user may not be able to recognize the separation, and be confused by the redundant buttons. To avoid this, some authors omit specifying the accessible name for the image, but this would fail Success Criterion 1.1.1 Non-text Content because the text alternative would not serve the same purpose as the graphical button. The preferred method to address this is to put the text and image together in one button symbol instance, and provide a single accessible name for the button to eliminate duplication of text.

      Examples

      The following examples are for a situation where a button instance comprised of both an image and text is on the stage. The combined button in this example uses the instance name 'flashLink1'.

      To create the combined button in Flash Professional:

      diff --git a/techniques/general/G1.html b/techniques/general/G1.html index df2f781235..59b2d63a94 100644 --- a/techniques/general/G1.html +++ b/techniques/general/G1.html @@ -3,7 +3,7 @@

      Description

      The objective of this technique is to provide a mechanism to bypass blocks of material that are repeated on multiple web pages by skipping directly to the main content of the web page. The first interactive item in the web page is a link to the beginning of the main content. Activating the link sets focus beyond the other content to the main content. This technique is most useful when a web page has one main content area, rather than a set of content areas that are equally important, and when there are not multiple navigation sections on the page.

      -

      It is preferable for links to be visible at all times, since users navigating via the keyboard include switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software. However, Success Criterion 2.4.1 does not require that they be visible when they do not have focus, and links that are visible only when they have focus can meet this success criterion.

      +

      It is preferable for links to be visible at all times, since users navigating via the keyboard include switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software. However, Success Criterion 2.4.1 Bypass Blocks does not require that they be visible when they do not have focus, and links that are visible only when they have focus can meet this success criterion.

      Examples

      diff --git a/techniques/general/G103.html b/techniques/general/G103.html index 8d4a6d9656..24d31a528a 100644 --- a/techniques/general/G103.html +++ b/techniques/general/G103.html @@ -15,7 +15,7 @@

      An annual report for a company

      An annual report discusses multiple factors that influenced the company's performance in the past year. The report also includes charts and graphs that illustrate how these factors interact. Each chart or graph has a text alternative as required by - Success Criterion 1.1.1. Each one also has a number in its caption (e.g., “Figure 7"). These numbers are used in the text to reference the charts or graphs.

      + Success Criterion 1.1.1 Non-text Content. Each one also has a number in its caption (e.g., “Figure 7"). These numbers are used in the text to reference the charts or graphs.

      Screen shots in technical documentation

      diff --git a/techniques/general/G126.html b/techniques/general/G126.html index ee58f54650..26fa6e233d 100644 --- a/techniques/general/G126.html +++ b/techniques/general/G126.html @@ -4,7 +4,7 @@

      The objective of this technique is to provide a list of links to all the web pages in the set on each web page. It is one of a series of techniques for locating content that are sufficient for addressing Success Criterion 2.4.5. This technique is only effective for small sets of web pages; if the list of links is longer than the rest of the content in the web page, it may make the web page more difficult for users to understand and use.

      -

      Success Criterion 2.4.1 requires a technique for skipping this list of links.

      +

      Success Criterion 2.4.1 Bypass Blocks requires a technique for skipping this list of links.

      Examples

      diff --git a/techniques/general/G134.html b/techniques/general/G134.html index 2e618fae58..22cb0d5022 100644 --- a/techniques/general/G134.html +++ b/techniques/general/G134.html @@ -1,6 +1,6 @@ --- obsoleteMessage: | - This technique relates to 4.1.1: Parsing, which was removed as of WCAG 2.2. + This technique relates to 4.1.1 Parsing, which was removed as of WCAG 2.2. obsoleteSince: 22 --- diff --git a/techniques/general/G139.html b/techniques/general/G139.html index faf13efc11..4468edd2d6 100644 --- a/techniques/general/G139.html +++ b/techniques/general/G139.html @@ -31,7 +31,7 @@

      Client-side error checking with no popup

    1. Check that there is a link to the list of errors from the error message.
    -

    Success Criterion 3.3.2 requires that if an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user.

    +

    Success Criterion 3.3.2 Labels or Instructions requires that if an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user.

    Expected Results

    diff --git a/techniques/general/G141.html b/techniques/general/G141.html index e16a906238..9f42f3d8b1 100644 --- a/techniques/general/G141.html +++ b/techniques/general/G141.html @@ -17,7 +17,7 @@

    When to Use

    Description

    -

    The objective of this technique is to ensure that sections have headings that identify them. Success Criterion 1.3.1 requires that the headings be marked such that they can be programmatically identified.

    +

    The objective of this technique is to ensure that sections have headings that identify them. Success Criterion 1.3.1 Info and Relationships requires that the headings be marked such that they can be programmatically identified.

    In HTML, this could be done using the HTML heading elements (h1, h2, h3, h4, h5, and h6). These allow user agents to automatically identify section headings. Other technologies use other techniques for identifying headers. To facilitate navigation and understanding of overall document structure, authors should use headings that are properly nested (e.g., h1 followed by h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc.).

    diff --git a/techniques/general/G167.html b/techniques/general/G167.html index 057eca578e..3824cef2b1 100644 --- a/techniques/general/G167.html +++ b/techniques/general/G167.html @@ -4,7 +4,7 @@

    When a button invokes a function on an input field, has a clear text label or name, and is rendered adjacent to the input field, the button also acts as a label for the input field. This label helps users understand the purpose of the field without introducing repetitive text on the web page. Buttons that label single text fields typically follow the input field.

    The field must also have a programmatically determined name, per - Success Criterion 4.1.2.

    + Success Criterion 4.1.2 Name, Role, Value.

    Examples

    diff --git a/techniques/general/G174.html b/techniques/general/G174.html index 07d9b1bcc9..a8df00e09c 100644 --- a/techniques/general/G174.html +++ b/techniques/general/G174.html @@ -2,16 +2,16 @@

    Any technology.

    Description

    When the contrast between the text and its background for some portion of the page has not been designed to meet the contrast level for - Success Criterion 1.4.3 + Success Criterion 1.4.3 Contrast (Minimum) or - 1.4.6, it is possible to meet these guidelines using the "Alternate Version" clause in the conformance requirements (Conformance Requirement 1). A link or control on the page can either change the page so that all aspects conform, or it could take the viewer to a new version of the page that does conform at the desired level. Placing the link or control prominently on the page will assist users in accessing the conforming content readily.

    + 1.4.6 Contrast (Enhanced), it is possible to meet these guidelines using the "Alternate Version" clause in the conformance requirements (Conformance Requirement 1). A link or control on the page can either change the page so that all aspects conform, or it could take the viewer to a new version of the page that does conform at the desired level. Placing the link or control prominently on the page will assist users in accessing the conforming content readily.

    For this technique to be used successfully, three things must be true:

    1. The link or control on the original page must itself meet the contrast requirement of the desired SC. (If the user cannot see the control they may not be able to use it to go to the new page.)
    2. The new page must contain all the same information and functionality as the original page.
    3. The new page must conform to all of the SC for the desired level of conformance. (i.e., the new page cannot just have the desired level of contrast but otherwise not conform).
    -

    This technique can be used to meet Success Criterion 1.4.3 by having text (or images of text) on the alternate version of the page be 4.5:1 contrast and any large text (or images of large text) be 3:1 contrast with its background. If the alternate version of the page has all text (or images of text) with 7:1 contrast and large text (or images of large text) with 4.5:1 contrast then it would satisfy both Success Criterion 1.4.3 and 1.4.6.

    +

    This technique can be used to meet Success Criterion 1.4.3 Contrast (Minimum) by having text (or images of text) on the alternate version of the page be 4.5:1 contrast and any large text (or images of large text) be 3:1 contrast with its background. If the alternate version of the page has all text (or images of text) with 7:1 contrast and large text (or images of large text) with 4.5:1 contrast then it would satisfy both Success Criterion 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced).

    This technique can be used in combination with a style switching technique to present a page that is a conforming alternate version diff --git a/techniques/general/G182.html b/techniques/general/G182.html index af892bcc57..d773ee492c 100644 --- a/techniques/general/G182.html +++ b/techniques/general/G182.html @@ -8,8 +8,7 @@

    The intent of this technique is to provide a redundant visual cue for users who may not be able to discern a difference in text color. Color is commonly used to indicate the different status of words that are part of a paragraph or other block of text or where special characters or graphics cannot be used to indicate which words have special status. For example, scattered words in text may be hypertext links that are marked as such by being printed in a different color. This technique describes a way to provide cues in addition to color so that users who may have difficulty perceiving color differences or have low vision can identify them.

    To use this technique, an author incorporates a visual cue in addition to color for each place where color alone is used to convey information. Visual cues can take many forms including changes to the font style, the addition of underlines, bold, or italics, or changes to the font size.

    -

    While this technique is sufficient to meet the visual requirements of Success Criterion 1.4.1, the information conveyed by the color must also be available programmatically to satisfy Success Criterion 1.3.1. See - How to Meet 1.3.1.

    +

    While this technique is sufficient to meet the visual requirements of Success Criterion 1.4.1 Use of Color, the information conveyed by the color must also be available programmatically to satisfy Success Criterion 1.3.1 Info and Relationships.

    Examples

      diff --git a/techniques/general/G183.html b/techniques/general/G183.html index 00b892b5b1..fd7044079b 100644 --- a/techniques/general/G183.html +++ b/techniques/general/G183.html @@ -6,10 +6,10 @@

      Colored text when color alone is used to convey information such as words that are links in a paragraph

    Description

    The intent of this technique is to provide a redundant visual cue for users who may not be able to discern a difference in text color. Color (generally defined as a combination of hue, saturation and luminance) is commonly used to indicate words that are links within a paragraph or other block of text. For example, scattered words in text may be hypertext links that are identified only by a difference in color with surrounding text. This technique describes a way to provide a difference in contrast rather than relying on hue.

    -

    To meet Success Criterion 1.4.1: Use of Color a relative luminance (lightness) difference of 3:1 or greater with the text around can be used. This technique goes beyond the success criterion and asks for visual highlights when the user hovers over each link, such as an underline, a change in font style such as bold or italics, or an increase in font size. Such a hover effect provides confirmation to pointer users that the text is a link, similar to how the link alters its appearance for keyboard users when it receives focus, in order to meet 2.4.7 Focus Visible.

    +

    To meet Success Criterion 1.4.1 Use of Color a relative luminance (lightness) difference of 3:1 or greater with the text around can be used. This technique goes beyond the success criterion and asks for visual highlights when the user hovers over each link, such as an underline, a change in font style such as bold or italics, or an increase in font size. Such a hover effect provides confirmation to pointer users that the text is a link, similar to how the link alters its appearance for keyboard users when it receives focus, in order to meet 2.4.7 Focus Visible.

    While using this technique is sufficient to meet this success criterion, it is not the preferred technique to differentiate link text. This is because links that use the relative luminance of color alone may not be obvious to people with low vision. If there are not a large number of links in the block of text, underlines are recommended for links in blocks of text.

    -

    This technique is about the use of color in addition to luminosity. In this technique, the contrast ratio refers to the contrast between a link and the words around it. In Success Criteria 1.4.3 and 1.4.6, contrast ratio refers to the contrast between a word and its background. The difference is that this technique is about the ability for users to tell the difference (a noticeable difference) between different pieces of text whereas the contrast ratio used in Success Criteria 1.4.3 and 1.4.6 is about the readability of the text with its background for different color and vision disabilities.

    +

    This technique is about the use of color in addition to luminosity. In this technique, the contrast ratio refers to the contrast between a link and the words around it. In Success Criteria 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced), contrast ratio refers to the contrast between a word and its background. The difference is that this technique is about the ability for users to tell the difference (a noticeable difference) between different pieces of text whereas the contrast ratio used in Success Criteria 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced) is about the readability of the text with its background for different color and vision disabilities.

    If an author wants to use the color portion of this technique (i.e., using different colors for the words where the colors have sufficient contrast with each other) and the author also wants to conform to SC 1.4.3 (contrast of both words with their backgrounds) the following colors can be used (e.g., black text in a paragraph on a white background with the links shown as one of the colors in example 1 below).

    If assistive technology or web browsers at some point all provide an option to underline all links on web pages for users, this could be used instead of an author-provided link highlighting mechanism.

    diff --git a/techniques/general/G192.html b/techniques/general/G192.html index 710fedf1d1..80646db87c 100644 --- a/techniques/general/G192.html +++ b/techniques/general/G192.html @@ -1,12 +1,12 @@ --- obsoleteMessage: | - This technique relates to 4.1.1: Parsing, which was removed as of WCAG 2.2. + This technique relates to 4.1.1 Parsing, which was removed as of WCAG 2.2. obsoleteSince: 22 --- Fully conforming to specifications

    Fully conforming to specifications

    ID: G192

    Technology: general

    Type: Technique

    When to Use

    This technique relates to all markup languages with specifications.

    Description

    -

    When markup languages are used in a way that fully conforms to their specifications, all of the requirements in 4.1.1 are met. Therefore, while fully conforming to specifications is not required to conform to WCAG 2.0, it is a best practice and is sufficient to meet Success Criterion 4.1.1.

    +

    When markup languages are used in a way that fully conforms to their specifications, all of the requirements in 4.1.1 Parsing are met. Therefore, while fully conforming to specifications is not required to conform to WCAG 2.0, it is a best practice and is sufficient to meet Success Criterion 4.1.1.

    Examples

    • A page is created with care to make sure that all technologies are used according to specification. It is run through a validator and all identified errors are corrected. Specification requirements that can not be identified by validation are also checked and any failures are corrected.
      • diff --git a/techniques/general/G211.html b/techniques/general/G211.html index fd25dacf48..ca56193c74 100644 --- a/techniques/general/G211.html +++ b/techniques/general/G211.html @@ -28,7 +28,7 @@

      Determining the appropriate label

      Examples

      -

      Mapping a visible label to the accessible name is achieved in many technologies by meeting 1.3.1 Information and Relationships through the proper use of native semantics. Many controls derive accessible names by correct nesting of elements, while other elements have specific attributes which are a valid means of providing or referencing an accessible name.

      +

      Mapping a visible label to the accessible name is achieved in many technologies by meeting 1.3.1 Info and Relationships through the proper use of native semantics. Many controls derive accessible names by correct nesting of elements, while other elements have specific attributes which are a valid means of providing or referencing an accessible name.

      The accessible name should be assigned through native elements and semantics where possible. That helps ensure an exact match between the visible label and name.

      Anchor text provides both the link's label and its accessible name

      @@ -69,7 +69,7 @@

      Simple Radio Button Group

      Call me when balance exceeds $10,000, Yes No
      Figure 1 "Call me when balance exceeds $10,000 radio group, with Yes and No choices
      -

      The label for each component should be restricted to "Yes" and "No". To meet 1.3.1 Information and Relationships and 3.3.2 Labels or Instructions, the "Call me…" text can be coded to convey the relationship to ATs, in this example by using a fieldset and legend.

      +

      The label for each component should be restricted to "Yes" and "No". To meet 1.3.1 Info and Relationships and 3.3.2 Labels or Instructions, the "Call me…" text can be coded to convey the relationship to ATs, in this example by using a fieldset and legend.

      If the label is not restricted to the string adjacent to the radio button, multiple interpretations of what constitutes the label can result in less uniform functionality. If "Yes" alone is not the label for the first radio button, is it "Call me when balance exceeds $10,000"? Or is it a combination of text strings, in which case is the order "Call me when balance exceeds $10,000 Yes" or "Yes, Call me when balance exceeds $10,000"? Decisions to combine text strings can have negative effects on screen reader users since the order of concatenation can affect meaning. In this example, "No, call me when balance exceeds $10,000" could be very confusing to a screen reader user.

      <fieldset>
   <legend>Call me when balance exceeds $10,000?</legend><br />
diff --git a/techniques/general/G62.html b/techniques/general/G62.html
index 45428f36ff..96e5cdcd6c 100644
--- a/techniques/general/G62.html
+++ b/techniques/general/G62.html
@@ -2,7 +2,7 @@
       
      Any technology containing text.

      Description

      The objective of this technique is to make the definition of a word, phrase, or abbreviation available by providing the definition in a glossary. A glossary is an alphabetical list of words, phrases, and abbreviations with their definitions. Glossaries are most appropriate when the words, phrases, and abbreviations used within the content relate to a specific discipline or technology area. A glossary can also provide the pronunciation of a word or phrase.

      -

      The glossary is included at the end of the web page or the glossary is located via one of the mechanisms for locating content within a set of web pages. (See Understanding Success Criterion 2.4.5.)

      +

      The glossary is included at the end of the web page or the glossary is located via one of the mechanisms for locating content within a set of web pages. (See Understanding Success Criterion 2.4.5 Multiple Ways.)

      If the glossary contains several definitions for the same word, phrase, or abbreviation, simply providing the glossary is not sufficient to satisfy this Success Criterion. A different technique should be used to find the correct definition. This is especially important if the uses of the word, phrase, or abbreviation are not unique within the web page, that is, if different occurrences of the item have different definitions.

      Examples

      diff --git a/techniques/html/H2.html b/techniques/html/H2.html index a7a1e88a52..ab0cbcc76c 100644 --- a/techniques/html/H2.html +++ b/techniques/html/H2.html @@ -19,7 +19,7 @@

      When to Use

      Description

      This objective of this technique is to provide both text and iconic representations of links without making the web page more confusing or difficult for keyboard users or assistive technology users. Since different users finding text and icons more usable, providing both can improve the accessibility of the link.

      Many links have both a text and iconic representation adjacent to each other, but rendered in separate a elements. Visually they appear to be a single link, but many users encounter them as adjacent identical links. For a keyboard user, it is tedious to navigate through redundant links. For users of assistive technologies, it can be confusing to encounter successive identical links. When the text alternative for the icon is a duplicate of the link text, it is repetitive as screen readers read the description twice.

      -

      If the author omitted alternative text from the link image, it would fail Success Criterion 1.1.1 because the text alternative would not serve the same purpose as the graphical link.

      +

      If the author omitted alternative text from the link image, it would fail Success Criterion 1.1.1 Non-text Content because the text alternative would not serve the same purpose as the graphical link.

      This technique provides such links by putting the text and image together in one a element and providing null alternative text on the image to eliminate duplication of text. In this way, both representations of the link are provided, but keyboard users only encounter one link and assistive technology that provides users with link lists for a web page do not include duplicate links.

      Sometimes the text and the icon link are rendered in separate, adjacent table cells to facilitate page layout. Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content. If CSS is used, this technique can be applied to combine the links.

      diff --git a/techniques/html/H70.html b/techniques/html/H70.html index b884f973db..ea392a047a 100644 --- a/techniques/html/H70.html +++ b/techniques/html/H70.html @@ -21,7 +21,7 @@

      This technique is appropriate when framesets are already used to organize the content of the page; other techniques are preferred for pages that are not already using framesets, because many people using assistive technology have trouble with frames . An - advisory technique about using noframes is available in Success Criterion 1.1.1.

      + advisory technique about using noframes is available in Success Criterion 1.1.1 Non-text Contrast.

      In HTML5 the frame element is marked as obsolete.

      Examples

      diff --git a/techniques/html/H74.html b/techniques/html/H74.html index 0c55a0ad95..b1be1590d5 100644 --- a/techniques/html/H74.html +++ b/techniques/html/H74.html @@ -1,6 +1,6 @@ --- obsoleteMessage: | - This technique relates to 4.1.1: Parsing, which was removed as of WCAG 2.2. + This technique relates to 4.1.1 Parsing, which was removed as of WCAG 2.2. obsoleteSince: 22 --- diff --git a/techniques/html/H75.html b/techniques/html/H75.html index 38544c09f6..f7ff6a71a8 100644 --- a/techniques/html/H75.html +++ b/techniques/html/H75.html @@ -1,6 +1,6 @@ --- obsoleteMessage: | - This technique relates to 4.1.1: Parsing, which was removed as of WCAG 2.2. + This technique relates to 4.1.1 Parsing, which was removed as of WCAG 2.2. obsoleteSince: 22 --- Ensuring that web pages are well-formed

      Ensuring that web pages are well-formed

      ID: H75

      Technology: html

      Type: Technique

      When to Use

      diff --git a/techniques/html/H93.html b/techniques/html/H93.html index fb6fc0c83f..97271d193d 100644 --- a/techniques/html/H93.html +++ b/techniques/html/H93.html @@ -1,6 +1,6 @@ --- obsoleteMessage: | - This technique relates to 4.1.1: Parsing, which was removed as of WCAG 2.2. + This technique relates to 4.1.1 Parsing, which was removed as of WCAG 2.2. obsoleteSince: 22 --- diff --git a/techniques/html/H94.html b/techniques/html/H94.html index e97b2f7284..f594c4f089 100644 --- a/techniques/html/H94.html +++ b/techniques/html/H94.html @@ -1,6 +1,6 @@ --- obsoleteMessage: | - This technique relates to 4.1.1: Parsing, which was removed as of WCAG 2.2. + This technique relates to 4.1.1 Parsing, which was removed as of WCAG 2.2. obsoleteSince: 22 --- diff --git a/techniques/html/H95.html b/techniques/html/H95.html index 93851be24e..4af89ce8d9 100644 --- a/techniques/html/H95.html +++ b/techniques/html/H95.html @@ -21,7 +21,7 @@

      Description

      The src attribute of the track element is a URL that is the address of the text track data.

      The kind attribute of the track element indicates the kind of information in the timed text. captions text tracks provide a text version of dialogue and other sounds important to understanding the video. Subtitles contain only the dialogue. If other audio information is important to understanding the video, a subtitle track will not be sufficient to meet the success criterion.

      -

      Some regions use the term "subtitle" for any visible text representation of the audio track. An author may mark up a timed text track in the language of the audio track as kind=subtitles, instead of kind=captions, and may include additional relevant audio information. It is not best practice to use subtitles in this situation, since it may confuse users who are trying to find captions, but such a timed text track would meet the requirements of Success Criterion 1.2.2.

      +

      Some regions use the term "subtitle" for any visible text representation of the audio track. An author may mark up a timed text track in the language of the audio track as kind=subtitles, instead of kind=captions, and may include additional relevant audio information. It is not best practice to use subtitles in this situation, since it may confuse users who are trying to find captions, but such a timed text track would meet the requirements of Success Criterion 1.2.2 Captions (Prerecorded).

      diff --git a/understanding/20/audio-description-or-media-alternative-prerecorded.html b/understanding/20/audio-description-or-media-alternative-prerecorded.html index 5b0c86ab69..2355ce30db 100644 --- a/understanding/20/audio-description-or-media-alternative-prerecorded.html +++ b/understanding/20/audio-description-or-media-alternative-prerecorded.html @@ -64,7 +64,9 @@

      Intent of Audio Description or Media Alternative (Prerecorded)

      - 1.2.3, 1.2.5, and 1.2.8 overlap somewhat with each other. This is to give the author + 1.2.3 Audio Description or Media Alternative (Prerecorded), + 1.2.5 Audio Description (Prerecorded), and 1.2.8 Media Alternative (Prerecorded) + 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 diff --git a/understanding/20/audio-description-prerecorded.html b/understanding/20/audio-description-prerecorded.html index 1e94d19295..d08a064ba0 100644 --- a/understanding/20/audio-description-prerecorded.html +++ b/understanding/20/audio-description-prerecorded.html @@ -41,7 +41,9 @@

      Intent of Audio Description (Prerecorded)

      - 1.2.3, 1.2.5, and 1.2.8 overlap somewhat with each other. This is to give the author + 1.2.3 Audio Description or Media Alternative (Prerecorded), + 1.2.5 Audio Description (Prerecorded), and 1.2.8 Media Alternative (Prerecorded) + 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 diff --git a/understanding/20/audio-only-and-video-only-prerecorded.html b/understanding/20/audio-only-and-video-only-prerecorded.html index 351033fe9e..3b13e6ba63 100644 --- a/understanding/20/audio-only-and-video-only-prerecorded.html +++ b/understanding/20/audio-only-and-video-only-prerecorded.html @@ -50,7 +50,7 @@

      Intent of Audio-only and Video-only (Prerecorded)

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

    diff --git a/understanding/20/captions-live.html b/understanding/20/captions-live.html index 4d7366474c..7987f051c7 100644 --- a/understanding/20/captions-live.html +++ b/understanding/20/captions-live.html @@ -74,7 +74,7 @@

    Resources for Captions (Live)

    diff --git a/understanding/20/captions-prerecorded.html b/understanding/20/captions-prerecorded.html index 961c21ab31..69f65f7771 100644 --- a/understanding/20/captions-prerecorded.html +++ b/understanding/20/captions-prerecorded.html @@ -49,7 +49,7 @@

    Intent of Captions (Prerecorded)

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

    diff --git a/understanding/20/consistent-identification.html b/understanding/20/consistent-identification.html index cbe96707c4..38f1a97788 100644 --- a/understanding/20/consistent-identification.html +++ b/understanding/20/consistent-identification.html @@ -43,8 +43,8 @@

    Intent of Consistent Identification

    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. + page, 3.2.4 Consistent Identification only addresses consistency within a set of + web pages where something is repeated on more than one page in the set.

    diff --git a/understanding/20/contrast-enhanced.html b/understanding/20/contrast-enhanced.html index 6ecff14d72..a7fce87f31 100644 --- a/understanding/20/contrast-enhanced.html +++ b/understanding/20/contrast-enhanced.html @@ -87,7 +87,7 @@

    Intent of Contrast (Enhanced)

    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. + Success Criterion 1.4.5 Images of Text.

    This requirement applies to situations in which images of text were intended to be @@ -110,7 +110,7 @@

    Intent of Contrast (Enhanced)

    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. + of text, which is necessary for some users. See 1.4.5 Images of Text.

    @@ -132,7 +132,7 @@

    Intent of 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 Success Criterion 1.4.3 to account + for standard text and vision. The 4.5:1 ratio is used in Success Criterion 1.4.3 Contrast (Minimum) 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. @@ -225,7 +225,7 @@

    Notes on formula

    to analyze the contrast of web content.

    See also - 2.4.7: Focus Visible for techniques for indicating keyboard focus. + 2.4.7 Focus Visible for techniques for indicating keyboard focus.

    diff --git a/understanding/20/contrast-minimum.html b/understanding/20/contrast-minimum.html index 51e92e7551..3753e9d037 100644 --- a/understanding/20/contrast-minimum.html +++ b/understanding/20/contrast-minimum.html @@ -86,7 +86,7 @@

    Intent of Contrast (Minimum)

    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. + Success Criterion 1.4.5 Images of Text.

    This requirement applies to situations in which images of text were intended to be @@ -124,7 +124,7 @@

    Intent of Contrast (Minimum)

    See also - 1.4.6: Contrast (Enhanced). + 1.4.6 Contrast (Enhanced).

    @@ -210,7 +210,7 @@

    Notes on formula

    to analyze the contrast of web content.

    See also - 2.4.7: Focus Visible for techniques for indicating keyboard focus. + 2.4.7 Focus Visible for techniques for indicating keyboard focus.

    diff --git a/understanding/20/error-identification.html b/understanding/20/error-identification.html index 9188a3f4ae..28e3b637b9 100644 --- a/understanding/20/error-identification.html +++ b/understanding/20/error-identification.html @@ -27,7 +27,7 @@

    Intent of Error Identification

    failed. The error must be indicated in text.

    This SC requires that users be provided with information about the nature of the error, including the identity of the item in error. What the user should do to correct the item in error is covered by - 3.3.3 Error Suggestion. Often, the error description can be phrased so that it meets both SC 3.3.1 and SC 3.3.3 at the same time. For instance, "Email is not valid" would pass SC 3.3.1, but "Please provide a valid email address in the format name@domain.com" also conveys how it can be fixed and passes both. + 3.3.3 Error Suggestion. Often, the error description can be phrased so that it meets both SC 3.3.1 Error Identification and SC 3.3.3 Error Suggestion at the same time. For instance, "Email is not valid" would pass SC 3.3.1, but "Please provide a valid email address in the format name@domain.com" also conveys how it can be fixed and passes both.

    An "input error" includes:

    @@ -75,7 +75,7 @@

    Intent of Error Identification

    -

    See also 3.3.3: Error Suggestion.

    +

    See also 3.3.3 Error Suggestion.

    User agent native HTML form validation

    diff --git a/understanding/20/error-prevention-all.html b/understanding/20/error-prevention-all.html index bcad970c59..2cbd79cb50 100644 --- a/understanding/20/error-prevention-all.html +++ b/understanding/20/error-prevention-all.html @@ -25,7 +25,8 @@

    Intent of Error Prevention (All)

    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. + Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data) + 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 diff --git a/understanding/20/error-suggestion.html b/understanding/20/error-suggestion.html index 34e7279536..38f4b759f6 100644 --- a/understanding/20/error-suggestion.html +++ b/understanding/20/error-suggestion.html @@ -30,7 +30,7 @@

    Intent of Error Suggestion

    but that falls outside the required data format or allowed values.

    -

    Success Criterion 3.3.1 provides for notification of errors. However, persons with +

    Success Criterion 3.3.1 Error Identification 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 diff --git a/understanding/20/focus-order.html b/understanding/20/focus-order.html index cc920f3927..0787272c4e 100644 --- a/understanding/20/focus-order.html +++ b/understanding/20/focus-order.html @@ -48,7 +48,8 @@

    Intent of Focus Order

    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 + (see Success Criterion 1.3.2 Meaningful Sequence) + 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 diff --git a/understanding/20/headings-and-labels.html b/understanding/20/headings-and-labels.html index e619a4df6d..3da1da81a0 100644 --- a/understanding/20/headings-and-labels.html +++ b/understanding/20/headings-and-labels.html @@ -37,7 +37,7 @@

    Intent of Headings and Labels

    This success criterion requires that if headings or labels are provided, they be descriptive. This success criterion does not require headings or labels; labels for inputs are covered separately by 3.3.2 Labels or Instructions. This success criterion also does not require that content acting as a heading or label be correctly marked up or identified — that aspect is covered separately by - 1.3.1: Info and Relationships. It is possible for content + 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 @@ -45,11 +45,11 @@

    Intent of Headings and Labels

    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 have been - used — that aspect is covered separately by 4.1.2: Name, Role and Value. It is possible + used — that 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 inaccurate or insufficiently 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 accurate and sufficiently clear or descriptive. Please see 3.3.2: Labels or Instructions for more information on the use of labels. +

    This success criterion does not require the use of labels; however, it does require that if labels are present, they must be accurate and sufficiently clear or descriptive. Please see 3.3.2 Labels or Instructions for more information on the use of labels.

    @@ -63,7 +63,7 @@

    Benefits of Headings and Labels

  • Form input controls with labels that clearly and accurately 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 + 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.
    • diff --git a/understanding/20/info-and-relationships.html b/understanding/20/info-and-relationships.html index f8d1ffe210..95e8aac60c 100644 --- a/understanding/20/info-and-relationships.html +++ b/understanding/20/info-and-relationships.html @@ -88,9 +88,8 @@

    Intent of Info and Relationships

    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. + Success Criterion 1.4.1 Use of Color + addresses the specific case of color, rather than Success Criterion 1.3.1 Info and Relationships.

    diff --git a/understanding/20/labels-or-instructions.html b/understanding/20/labels-or-instructions.html index ecfe57fa8b..d8aafe1e8b 100644 --- a/understanding/20/labels-or-instructions.html +++ b/understanding/20/labels-or-instructions.html @@ -47,13 +47,13 @@

    Intent of Labels or Instructions

    This success criterion does not require that labels or instructions be correctly marked up, identified, or associated with their respective controls — that aspect is covered separately by - 1.3.1: Info and Relationships. It is possible for content + 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 — that aspect is - covered separately by 4.1.2: Name, Role and Value. It is possible + 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). @@ -63,7 +63,7 @@

    Intent of Labels or Instructions

    While this success criterion requires that controls and inputs have labels or instructions, whether or not labels (if used) are accurate, sufficiently clear, or descriptive is covered separately by - 2.4.6: Headings and Labels. + 2.4.6 Headings and Labels.

    The use of "requires" in this criterion's normative wording does not mean that the criterion only applies to required form fields. It is used here as a synonym for "accepts", "expects", or "allows". The criterion diff --git a/understanding/20/language-of-page.html b/understanding/20/language-of-page.html index 1fd557760d..4f8bb0861e 100644 --- a/understanding/20/language-of-page.html +++ b/understanding/20/language-of-page.html @@ -40,7 +40,7 @@

    Intent of Language of Page

    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 + developers to follow Success Criterion 3.1.2 Language of Parts as well even though that is a Level AA success criterion.

    diff --git a/understanding/20/language-of-parts.html b/understanding/20/language-of-parts.html index 98a6c4b760..30bf03a88b 100644 --- a/understanding/20/language-of-parts.html +++ b/understanding/20/language-of-parts.html @@ -39,7 +39,7 @@

    Intent of Language of Parts

    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). + language is the default human language of the web page (see Success Criterion 3.1.1 Language of Page). So the human language of all content in single language documents can be programmatically determined.

    diff --git a/understanding/20/link-purpose-in-context.html b/understanding/20/link-purpose-in-context.html index 6772aaa9c4..4c65edb3a9 100644 --- a/understanding/20/link-purpose-in-context.html +++ b/understanding/20/link-purpose-in-context.html @@ -42,7 +42,8 @@

    Intent of Link Purpose (In Context)

    - Success Criterion 2.4.2 deals with the titles of pages. Here also, the name of a document or web application + Success Criterion 2.4.2 Page Titled + 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. @@ -68,7 +69,8 @@

    Intent of Link Purpose (In Context)

    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 + Success Criterion 3.2.4 Consistent Identification + for pages in a set). It is also a best practice for links with different purposes and destinations to have different link text.

    @@ -94,7 +96,7 @@

    Intent of Link Purpose (In Context)

    See also - 2.4.9: Link Purpose (Link Only). + 2.4.9 Link Purpose (Link Only).

    diff --git a/understanding/20/link-purpose-link-only.html b/understanding/20/link-purpose-link-only.html index 6518158db9..df46dd861d 100644 --- a/understanding/20/link-purpose-link-only.html +++ b/understanding/20/link-purpose-link-only.html @@ -27,7 +27,8 @@

    Intent of Link Purpose (Link Only)

    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). + Success Criterion 3.2.4 Consistent Identification + 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. @@ -43,7 +44,8 @@

    Intent of Link Purpose (Link Only)

    - Success Criterion 2.4.2 deals with the titles of pages. Here also, the name of a document or web application + Success Criterion 2.4.2 Page Titled + 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. diff --git a/understanding/20/media-alternative-prerecorded.html b/understanding/20/media-alternative-prerecorded.html index ff924ec639..ca4f816d47 100644 --- a/understanding/20/media-alternative-prerecorded.html +++ b/understanding/20/media-alternative-prerecorded.html @@ -57,7 +57,9 @@

    Intent of Media Alternative (Prerecorded)

    - 1.2.3, 1.2.5, and 1.2.8 overlap somewhat with each other. This is to give the author + 1.2.3 Audio Description or Media Alternative (Prerecorded), + 1.2.5 Audio Description (Prerecorded), and 1.2.8 Media Alternative (Prerecorded) + 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 diff --git a/understanding/20/name-role-value.html b/understanding/20/name-role-value.html index 5319406abf..1c1ed86e54 100644 --- a/understanding/20/name-role-value.html +++ b/understanding/20/name-role-value.html @@ -23,7 +23,7 @@

    Intent of Name, Role, Value

    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) + of this provision will be met. (See examples of Success Criterion 4.1.2 Name, Role, Value 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 @@ -44,7 +44,7 @@

    Intent of Name, Role, Value

    -

    Success Criterion 4.1.2 requires a programmatically determinable name for all user +

    Success Criterion 4.1.2 Name, Role, Value 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. diff --git a/understanding/20/navigable.html b/understanding/20/navigable.html index 8d95c31eb7..d3ed479daa 100644 --- a/understanding/20/navigable.html +++ b/understanding/20/navigable.html @@ -44,9 +44,8 @@

    Intent of Navigable

    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 Criterion 1.3.1 Info and Relationships + for headings also addresses some aspects of Guideline 2.4 Navigable.

    diff --git a/understanding/20/page-titled.html b/understanding/20/page-titled.html index c52695ee57..4ec95f5981 100644 --- a/understanding/20/page-titled.html +++ b/understanding/20/page-titled.html @@ -45,8 +45,9 @@

    Intent of Page Titled

    - 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, + Success Criteria 2.4.4 Link Purpose (In Context) and + 2.4.9 Link Purpose (Link Only) 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 diff --git a/understanding/20/parsing.html b/understanding/20/parsing.html index 41e5c426ce..3abf52062c 100644 --- a/understanding/20/parsing.html +++ b/understanding/20/parsing.html @@ -71,7 +71,7 @@

    Intent of Parsing

    With the exception of one success criterion ( - 1.4.4: Resize Text, which specifically mentions that the effect specified by the success criterion must + 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 diff --git a/understanding/20/pause-stop-hide.html b/understanding/20/pause-stop-hide.html index 44c74d4d6d..2e503aad87 100644 --- a/understanding/20/pause-stop-hide.html +++ b/understanding/20/pause-stop-hide.html @@ -65,7 +65,7 @@

    Intent of Pause, Stop, Hide

    or status.

    -

    See 2.2.1: Timing Adjustable for additional requirements related to time-limits for reading and interactions.

    +

    See 2.2.1 Timing Adjustable for additional requirements related to time-limits for reading and interactions.

  • diff --git a/understanding/20/resize-text.html b/understanding/20/resize-text.html index 92ad16c450..7a31bcd1bb 100644 --- a/understanding/20/resize-text.html +++ b/understanding/20/resize-text.html @@ -102,7 +102,7 @@

    Intent of Resize Text

    • See also - 1.4.8: Visual Presentation. + 1.4.8 Visual Presentation.

    diff --git a/understanding/20/three-flashes.html b/understanding/20/three-flashes.html index 9dd6b018b1..10a9089841 100644 --- a/understanding/20/three-flashes.html +++ b/understanding/20/three-flashes.html @@ -32,8 +32,9 @@

    Intent of Three Flashes

    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 + Success Criterion 2.3.1 Three Flashes or Below Threshold + allows flashing if it is dim enough or has a small enough area, Success Criterion + 2.3.2 Three Flashes 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 @@ -52,7 +53,7 @@

    Intent of Three Flashes

    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. + 2.2.2 Pause, Stop, Hide for more information on blink.

    diff --git a/understanding/20/timing-adjustable.html b/understanding/20/timing-adjustable.html index b67227d6c7..ff4cb1de9f 100644 --- a/understanding/20/timing-adjustable.html +++ b/understanding/20/timing-adjustable.html @@ -103,7 +103,7 @@

    Notes regarding time limits

    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.

    +

    See also 2.2.3 No Timing.

    diff --git a/understanding/20/visual-presentation.html b/understanding/20/visual-presentation.html index f10f458018..735a4f26e4 100644 --- a/understanding/20/visual-presentation.html +++ b/understanding/20/visual-presentation.html @@ -80,7 +80,7 @@

    Intent of Visual Presentation

    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. + 1.4.4 Resize Text for additional discussion of resizing text.

    The horizontal scrolling requirement is not intended to apply to small-screen devices diff --git a/understanding/21/identify-input-purpose.html b/understanding/21/identify-input-purpose.html index d8baa980f6..4577375383 100644 --- a/understanding/21/identify-input-purpose.html +++ b/understanding/21/identify-input-purpose.html @@ -33,7 +33,7 @@

    Intent of this Success Criterion

    -

    Specific Benefits of Success Criterion 1.3.5:

    +

    Specific Benefits of Success Criterion 1.3.5

    • 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.
      • diff --git a/understanding/21/pointer-gestures.html b/understanding/21/pointer-gestures.html index ee0ea0a094..dcd4b47e4a 100644 --- a/understanding/21/pointer-gestures.html +++ b/understanding/21/pointer-gestures.html @@ -42,7 +42,7 @@

      Intent of this Success Criterion

      The difference between Pointer Gestures and Dragging

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

      + Dragging motions are covered in Success Criterion 2.5.7 Dragging Movements.

      Hand showing a starting touch, 1. Going to a second point, 2. It follows a very random path. diff --git a/understanding/22/accessible-authentication-enhanced.html b/understanding/22/accessible-authentication-enhanced.html index bfae266a04..7a9ca25377 100644 --- a/understanding/22/accessible-authentication-enhanced.html +++ b/understanding/22/accessible-authentication-enhanced.html @@ -44,7 +44,7 @@

      Examples of Accessible Authentication (Enhanced)

      The examples of this success criterion are very similar to the Accessible Authentication (Minimum) examples.

        -
      • A website 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 website 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 website 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 website 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 website is not enforcing any particular use; it is assumed a user will set up a method that suits them.
      • A website offers the ability to login with a third-party provider using the OAuth method.
        • diff --git a/understanding/22/accessible-authentication-minimum.html b/understanding/22/accessible-authentication-minimum.html index 98f5e3dcf1..b9d9fbc5fe 100644 --- a/understanding/22/accessible-authentication-minimum.html +++ b/understanding/22/accessible-authentication-minimum.html @@ -113,7 +113,7 @@

        Examples of Accessible Authentication (Minimum)

        The examples of this success criterion are the same as the Accessible Authentication (Enhanced) examples.

          -
        • A website 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 website 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 website 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 website 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 website is not enforcing any particular use; it is assumed a user will set up a method that suits them.
        • A website offers the ability to login with a third-party provider using the OAuth method.
          • diff --git a/understanding/22/consistent-help.html b/understanding/22/consistent-help.html index 96e2d23f78..85d54266d7 100644 --- a/understanding/22/consistent-help.html +++ b/understanding/22/consistent-help.html @@ -74,7 +74,7 @@

          Support for people with cognitive and learning disabilities

          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 website, this may not be apparent to some users with disabilities.

          +

          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 Help 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 website, 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:

          diff --git a/understanding/22/focus-appearance.html b/understanding/22/focus-appearance.html index cea3f0b254..16a4d2a3ea 100644 --- a/understanding/22/focus-appearance.html +++ b/understanding/22/focus-appearance.html @@ -460,8 +460,8 @@

          Relationship with Non-text Contrast

          See the Relationship with Focus Visible section of Understanding 1.4.11 - Non-text Contrast for more details and examples.

          + href="https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html">Understanding 1.4.11 Non-text Contrast + for more details and examples.

    diff --git a/understanding/22/focus-not-obscured-enhanced.html b/understanding/22/focus-not-obscured-enhanced.html index 0efea824ce..5aaff3ff7a 100644 --- a/understanding/22/focus-not-obscured-enhanced.html +++ b/understanding/22/focus-not-obscured-enhanced.html @@ -22,7 +22,7 @@

    Intent of Focus Not Obscured (Enhanced)

    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 1.4.11 Non-text Contrast and/or 2.4.13 Focus Appearance. When a focus indicator can be covered by a semi-opaque component, the focus indicator should be assessed against 1.4.11 and 2.4.13. 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.

    +

    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 1.4.11 Non-text Contrast and/or 2.4.13 Focus Appearance. When a focus indicator can be covered by a semi-opaque component, the focus indicator should be assessed against 1.4.11 Non-text Contrast and 2.4.13 Focus Appearance. 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.

    This criterion evaluates the focused component, rather than the focus indicator. The component itself does not include the focus indicator when checking that "no part of the component is hidden" - unless the focus indicator is inside the component, or focus is indicated by a change to the component itself. Although users benefit from both the component and the focus indicator (if external to the component) not being obscured when tracking the focus, for the purposes of this criterion only checking the component provides a clearer metric. However, if the focus indicator is fully obscured, it would likely fail 2.4.7 Focus Visible.

    diff --git a/understanding/22/focus-not-obscured-minimum.html b/understanding/22/focus-not-obscured-minimum.html index 491f853a3d..f91c2090f1 100644 --- a/understanding/22/focus-not-obscured-minimum.html +++ b/understanding/22/focus-not-obscured-minimum.html @@ -29,7 +29,7 @@

    Intent of Focus Not Obscured (Minimum)

    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.

    +

    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 Non-text Contrast 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.

    This criterion evaluates the focused component, rather than the focus indicator. The component itself does not include the focus indicator when checking that "the component is not entirely hidden" - unless the focus indicator is inside the component, or focus is indicated by a change to the component itself. Although users benefit from both the component and the focus indicator (if external to the component) not being obscured when tracking the focus, for the purposes of this criterion only checking the component provides a clearer metric. However, if the focus indicator is fully obscured, it would likely fail 2.4.7 Focus Visible.

    diff --git a/understanding/understanding-techniques.html b/understanding/understanding-techniques.html index 2641106dad..cd08a70dd7 100644 --- a/understanding/understanding-techniques.html +++ b/understanding/understanding-techniques.html @@ -47,7 +47,7 @@

    Sufficient Techniques

    There may be other ways to meet success criteria besides the sufficient techniques in W3C's Techniques for WCAG {{ versionDecimal }} 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)".

    +

    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 Info and Relationships has: "G115: Using semantic elements to mark up structure AND H49: Using semantic markup to mark emphasized or special text (HTML)".

    From d3d40186ebf0abcd7b60f2df5d40fff45f926177 Mon Sep 17 00:00:00 2001 From: "Kenneth G. Franqueiro" Date: Thu, 19 Feb 2026 12:17:43 -0500 Subject: [PATCH 2/8] Fix additionally-discovered typos --- guidelines/sc/20/non-text-content.html | 2 +- techniques/general/G160.html | 4 ++-- techniques/general/G207.html | 4 ++-- techniques/general/G209.html | 2 +- techniques/general/G221.html | 2 +- techniques/html/H70.html | 2 +- understanding/20/headings-and-labels.html | 2 +- understanding/20/labels-or-instructions.html | 2 +- understanding/20/timing-adjustable.html | 2 +- 9 files changed, 11 insertions(+), 11 deletions(-) diff --git a/guidelines/sc/20/non-text-content.html b/guidelines/sc/20/non-text-content.html index cb1fc458b6..ddf670b328 100644 --- a/guidelines/sc/20/non-text-content.html +++ b/guidelines/sc/20/non-text-content.html @@ -13,7 +13,7 @@

    Non-text Content

    -

    If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 Name, Role, for additional requirements for controls and content that accepts user input.) +

    If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 Name, Role, Value for additional requirements for controls and content that accepts user input.)

    diff --git a/techniques/general/G160.html b/techniques/general/G160.html index 93277cb91c..a043236db6 100644 --- a/techniques/general/G160.html +++ b/techniques/general/G160.html @@ -55,6 +55,6 @@

    See also - Related Resources for Success Criterion 1.2.6 - Sign Language.

    + Related Resources for Success Criterion 1.2.6 Sign Language.

    -
    \ No newline at end of file + diff --git a/techniques/general/G207.html b/techniques/general/G207.html index 64f6a4f93e..c760ddd2ec 100644 --- a/techniques/general/G207.html +++ b/techniques/general/G207.html @@ -21,7 +21,7 @@

    Description

    The objective of this technique is to ensure graphical icons provide enough contrast for people with vision impairments. Not all graphics are within the scope of SC 1.4.11 Non-text contrast but if the icons are required to understand the content, then the icons need to have a contrast ratio of at least 3:1.

    The success criteria for non-text contrast uses the term "graphical object" to cover small simple graphics, and parts of larger complex graphics. This technique focuses on solid color icons used on solid or gradient backgrounds.

    When choosing the colors for graphics, consider the color(s) adjacent to that graphic, and test that the contrast ratio is at least 3:1.

    -

    A selection of tools and applications for testing contrast ratios can be found in Understanding SC 1.4.3 Contrast (minimum).

    +

    A selection of tools and applications for testing contrast ratios can be found in Understanding SC 1.4.3 Contrast (Minimum).

    Examples

    @@ -77,7 +77,7 @@

    Related Techniques

    Resources

    diff --git a/techniques/general/G209.html b/techniques/general/G209.html index eaed81b970..42b43b8917 100644 --- a/techniques/general/G209.html +++ b/techniques/general/G209.html @@ -85,7 +85,7 @@

    Related Techniques

    Resources

    diff --git a/techniques/general/G221.html b/techniques/general/G221.html index 7ad46b166d..4cb863cf02 100644 --- a/techniques/general/G221.html +++ b/techniques/general/G221.html @@ -8,7 +8,7 @@

    Provide data from a previous step in a process

    Metadata

    -

    3.3.8 Redundant entry

    +

    3.3.7 Redundant entry

    Sufficient

    diff --git a/techniques/html/H70.html b/techniques/html/H70.html index ea392a047a..21225b5b17 100644 --- a/techniques/html/H70.html +++ b/techniques/html/H70.html @@ -21,7 +21,7 @@

    This technique is appropriate when framesets are already used to organize the content of the page; other techniques are preferred for pages that are not already using framesets, because many people using assistive technology have trouble with frames . An - advisory technique about using noframes is available in Success Criterion 1.1.1 Non-text Contrast.

    + advisory technique about using noframes is available in Success Criterion 1.1.1 Non-text Content.

    In HTML5 the frame element is marked as obsolete.

    Examples

    diff --git a/understanding/20/headings-and-labels.html b/understanding/20/headings-and-labels.html index 3da1da81a0..66437508ea 100644 --- a/understanding/20/headings-and-labels.html +++ b/understanding/20/headings-and-labels.html @@ -45,7 +45,7 @@

    Intent of Headings and Labels

    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 have been - used — that aspect is covered separately by 4.1.2 Name, Role and Value. It is possible + used — that aspect is covered separately by 4.1.2 Name, Role, 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 inaccurate or insufficiently clear or descriptive).

    diff --git a/understanding/20/labels-or-instructions.html b/understanding/20/labels-or-instructions.html index d8aafe1e8b..59a06e920d 100644 --- a/understanding/20/labels-or-instructions.html +++ b/understanding/20/labels-or-instructions.html @@ -53,7 +53,7 @@

    Intent of Labels or Instructions

    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 — that aspect is - covered separately by 4.1.2 Name, Role and Value. It is possible + covered separately by 4.1.2 Name, Role, 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). diff --git a/understanding/20/timing-adjustable.html b/understanding/20/timing-adjustable.html index ff4cb1de9f..5d14ee6c05 100644 --- a/understanding/20/timing-adjustable.html +++ b/understanding/20/timing-adjustable.html @@ -67,7 +67,7 @@

    Notes regarding time limits

    and are covered. Success Criteria 2.2.3 No Timing, 2.2.4 Interruptions, and - 2.2.5 Re-Authentication may also apply. + 2.2.5 Re-Authenticating may also apply.
  • Certain time limits implemented for security reasons, such as time-based / time-limited two-factor authentication tokens, can be considered essential, and may be From 7cb93c68edceca3cd7d99f3ae94f8d19ac87677b Mon Sep 17 00:00:00 2001 From: "Kenneth G. Franqueiro" Date: Thu, 19 Feb 2026 12:18:18 -0500 Subject: [PATCH 3/8] Front-load expansion in paragraphs where the same SCs appear repeatedly --- techniques/client-side-script/SCR29.html | 2 +- techniques/general/G183.html | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/techniques/client-side-script/SCR29.html b/techniques/client-side-script/SCR29.html index 348a7c6b28..89725cd46b 100644 --- a/techniques/client-side-script/SCR29.html +++ b/techniques/client-side-script/SCR29.html @@ -21,7 +21,7 @@

    Description

    When the tabindex attribute has the value 0, the element can be focused via the keyboard and is included in the tab order of the document. When the tabindex attribute has the value -1, the element cannot be tabbed to, but focus can be set programmatically, using element.focus().

    Because static HTML elements do not have actions associated with them, it is not possible to provide a backup implementation or explanation in environments in which scripting is not available. This technique should only be used in environments in which client-side scripting can be relied upon.

    -

    Such user interface controls must still satisfy Success Criterion 4.1.2. Applying this technique without also providing role, name, and state information about the user interface control will results in Failure F59, Failure of Success Criterion 4.1.2 Name, Role, Value due to using script to make div or span a user interface control in HTML.

    +

    Such user interface controls must still satisfy Success Criterion 4.1.2 Name, Role, Value. Applying this technique without also providing role, name, and state information about the user interface control will results in Failure F59, Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML.

    • diff --git a/techniques/general/G183.html b/techniques/general/G183.html index fd7044079b..127382067e 100644 --- a/techniques/general/G183.html +++ b/techniques/general/G183.html @@ -9,7 +9,7 @@

    To meet Success Criterion 1.4.1 Use of Color a relative luminance (lightness) difference of 3:1 or greater with the text around can be used. This technique goes beyond the success criterion and asks for visual highlights when the user hovers over each link, such as an underline, a change in font style such as bold or italics, or an increase in font size. Such a hover effect provides confirmation to pointer users that the text is a link, similar to how the link alters its appearance for keyboard users when it receives focus, in order to meet 2.4.7 Focus Visible.

    While using this technique is sufficient to meet this success criterion, it is not the preferred technique to differentiate link text. This is because links that use the relative luminance of color alone may not be obvious to people with low vision. If there are not a large number of links in the block of text, underlines are recommended for links in blocks of text.

    -

    This technique is about the use of color in addition to luminosity. In this technique, the contrast ratio refers to the contrast between a link and the words around it. In Success Criteria 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced), contrast ratio refers to the contrast between a word and its background. The difference is that this technique is about the ability for users to tell the difference (a noticeable difference) between different pieces of text whereas the contrast ratio used in Success Criteria 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced) is about the readability of the text with its background for different color and vision disabilities.

    +

    This technique is about the use of color in addition to luminosity. In this technique, the contrast ratio refers to the contrast between a link and the words around it. In Success Criteria 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced), contrast ratio refers to the contrast between a word and its background. The difference is that this technique is about the ability for users to tell the difference (a noticeable difference) between different pieces of text whereas the contrast ratio used in Success Criteria 1.4.3 and 1.4.6 is about the readability of the text with its background for different color and vision disabilities.

    If an author wants to use the color portion of this technique (i.e., using different colors for the words where the colors have sufficient contrast with each other) and the author also wants to conform to SC 1.4.3 (contrast of both words with their backgrounds) the following colors can be used (e.g., black text in a paragraph on a white background with the links shown as one of the colors in example 1 below).

    If assistive technology or web browsers at some point all provide an option to underline all links on web pages for users, this could be used instead of an author-provided link highlighting mechanism.

    From 83be0c5af856b62c024bf2db436f6f84a67420ea Mon Sep 17 00:00:00 2001 From: "Kenneth G. Franqueiro" Date: Thu, 19 Feb 2026 12:21:44 -0500 Subject: [PATCH 4/8] Remove colon between SC number and name in About this Technique box --- eleventy.config.ts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eleventy.config.ts b/eleventy.config.ts index a0d395daeb..52938e7fa1 100644 --- a/eleventy.config.ts +++ b/eleventy.config.ts @@ -378,7 +378,7 @@ export default async function (eleventyConfig: any) { const urlBase = this.page.filePathStem.startsWith("/understanding/") ? "" : baseUrls.understanding; - const label = `${guideline.num}: ${guideline.name}`; + const label = `${guideline.num} ${guideline.name}`; return `${label}`; }) .join("\nand\n"); From 2360be918e08defe813ed577e5c9a79439135d12 Mon Sep 17 00:00:00 2001 From: "Kenneth G. Franqueiro" Date: Fri, 20 Feb 2026 12:20:51 -0500 Subject: [PATCH 5/8] Remove guidelines/ changes (moved to separate branch) --- guidelines/relative-luminance.html | 2 +- guidelines/sc/20/non-text-content.html | 2 +- guidelines/sc/20/section-headings.html | 2 +- guidelines/sc/20/timing-adjustable.html | 2 +- guidelines/terms/20/contrast-ratio.html | 6 +++--- guidelines/terms/20/relative-luminance.html | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/guidelines/relative-luminance.html b/guidelines/relative-luminance.html index 17d0400e63..634fbcb7ad 100644 --- a/guidelines/relative-luminance.html +++ b/guidelines/relative-luminance.html @@ -342,7 +342,7 @@

    MathML version of the relative luminance definition

    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 Contrast (Minimum). + 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 diff --git a/guidelines/sc/20/non-text-content.html b/guidelines/sc/20/non-text-content.html index ddf670b328..bc59554336 100644 --- a/guidelines/sc/20/non-text-content.html +++ b/guidelines/sc/20/non-text-content.html @@ -13,7 +13,7 @@

    Non-text Content

    -

    If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 Name, Role, Value for additional requirements for controls and content that accepts user input.) +

    If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.)

    diff --git a/guidelines/sc/20/section-headings.html b/guidelines/sc/20/section-headings.html index e7266e432f..82a672677c 100644 --- a/guidelines/sc/20/section-headings.html +++ b/guidelines/sc/20/section-headings.html @@ -11,7 +11,7 @@

    Section Headings

    heading to different types of content.

    -

    This success criterion covers sections within writing, not user interface components. User interface components are covered under Success Criterion 4.1.2 Name, Role, Value. +

    This success criterion covers sections within writing, not user interface components. User interface components are covered under Success Criterion 4.1.2.

    diff --git a/guidelines/sc/20/timing-adjustable.html b/guidelines/sc/20/timing-adjustable.html index 6c0c3f26c9..cb371fa19b 100644 --- a/guidelines/sc/20/timing-adjustable.html +++ b/guidelines/sc/20/timing-adjustable.html @@ -68,7 +68,7 @@

    Timing Adjustable

    This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion - should be considered in conjunction with Success Criterion 3.2.1 On Focus, which puts limits on changes of content or context as a result of user action. + should be considered in conjunction with Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action.

    diff --git a/guidelines/terms/20/contrast-ratio.html b/guidelines/terms/20/contrast-ratio.html index 2a4a2cd7c8..66a1d522e9 100644 --- a/guidelines/terms/20/contrast-ratio.html +++ b/guidelines/terms/20/contrast-ratio.html @@ -20,9 +20,9 @@ evaluated with anti-aliasing turned off.

    -

    For the purpose of Success Criteria 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced), - 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. +

    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.

    Background color is the specified color of content over which the text is to be rendered diff --git a/guidelines/terms/20/relative-luminance.html b/guidelines/terms/20/relative-luminance.html index a5c539db6b..a071088136 100644 --- a/guidelines/terms/20/relative-luminance.html +++ b/guidelines/terms/20/relative-luminance.html @@ -45,7 +45,7 @@

    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 Contrast (Minimum). + authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3.

    If dithering occurs after delivery, then the source color value is used. For colors From 817cac66f0bea3094918d49c6ba76be57493773f Mon Sep 17 00:00:00 2001 From: "Kenneth G. Franqueiro" Date: Thu, 5 Mar 2026 11:21:46 -0500 Subject: [PATCH 6/8] Remove colon after SC number in Understanding h1 --- _includes/understanding/h1.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_includes/understanding/h1.html b/_includes/understanding/h1.html index 29db4de86b..ec7f663054 100644 --- a/_includes/understanding/h1.html +++ b/_includes/understanding/h1.html @@ -4,7 +4,7 @@

    Understanding {{- guideline.type }} {{ guideline.num -}} - : + {{ guideline.name }} {%- if guideline.level %} (Level {{ guideline.level }}){% endif %}

    From 14209d1fce43768e402601dafd53d90a94be6eb7 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Thu, 5 Mar 2026 19:33:59 +0000 Subject: [PATCH 7/8] Rework sentence in understanding three flashes --- understanding/20/three-flashes.html | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/understanding/20/three-flashes.html b/understanding/20/three-flashes.html index 10a9089841..c74c51851a 100644 --- a/understanding/20/three-flashes.html +++ b/understanding/20/three-flashes.html @@ -31,11 +31,10 @@

    Intent of Three Flashes

    -

    Whereas - Success Criterion 2.3.1 Three Flashes or Below Threshold - allows flashing if it is dim enough or has a small enough area, Success Criterion - 2.3.2 Three Flashes 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 +

    Compared to Success Criterion 2.3.1 Three Flashes or Below Threshold + – which allows flashing if it is dim enough or has a small enough area – this criterion + does not allow any flashing that occurs at a frequency 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. From dec74fe376c7deecde1042fac6ff830fdc99440e Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Thu, 5 Mar 2026 19:39:29 +0000 Subject: [PATCH 8/8] Apply suggestion from @patrickhlauke --- understanding/20/error-identification.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/understanding/20/error-identification.html b/understanding/20/error-identification.html index 28e3b637b9..84494a26a7 100644 --- a/understanding/20/error-identification.html +++ b/understanding/20/error-identification.html @@ -27,7 +27,7 @@

    Intent of Error Identification

    failed. The error must be indicated in text.

    This SC requires that users be provided with information about the nature of the error, including the identity of the item in error. What the user should do to correct the item in error is covered by - 3.3.3 Error Suggestion. Often, the error description can be phrased so that it meets both SC 3.3.1 Error Identification and SC 3.3.3 Error Suggestion at the same time. For instance, "Email is not valid" would pass SC 3.3.1, but "Please provide a valid email address in the format name@domain.com" also conveys how it can be fixed and passes both. + 3.3.3 Error Suggestion. Often, the error description can be phrased so that it meets both Success Criteria 3.3.1 Error Identification and 3.3.3 Error Suggestion at the same time. For instance, "Email is not valid" would pass 3.3.1, but "Please provide a valid email address in the format name@domain.com" also conveys how it can be fixed and passes both.

    An "input error" includes: