From 3275b6f932996d019df003694cb3b975959b99f6 Mon Sep 17 00:00:00 2001 From: Mary Jo Mueller Date: Mon, 6 Oct 2025 14:44:12 -0500 Subject: [PATCH 1/4] Update comments-by-guideline-and-success-criterion.md This is a reimplementation of PR #633 using the current main branch as the original source which was approved by the TF back in May but not incorporated because we hadn't solved non-web documents yet. This new PR is to address issue #627 - for both non-web documents and software since there are problems applying this SC in both cases. --- ...ents-by-guideline-and-success-criterion.md | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/comments-by-guideline-and-success-criterion.md b/comments-by-guideline-and-success-criterion.md index 7d7cdf09..da8e356e 100644 --- a/comments-by-guideline-and-success-criterion.md +++ b/comments-by-guideline-and-success-criterion.md @@ -588,24 +588,15 @@ See also the [Comments on Closed Functionality](#comments-on-closed-functionalit ##### page-titled -###### Applying SC 2.4.2 Page Titled to Non-Web Documents and Software +###### Applying SC 2.4.2 Page Titled to Non-Web Documents -This applies directly as written, and as described in [Intent from Understanding Success Criterion 2.4.2](https://www.w3.org/WAI/WCAG22/Understanding/page-titled#intent) replacing “web pages” with “non-web documents or software”. +This success criterion is problematic to apply directly to non-web documents through simple word substitution because not all document formats provide support for a title attribute, and document titles don't always describe the topic or purpose of the document. File names, as the WCAG 2.2 Understanding document allows, also rarely describe the topic or purpose of the document – especially where the document names are not under the author’s control. However, where the document authoring tool or technology provides the capability to supply a semantic title style or name for a document, when the non-web document utilizes that feature to provide a unique title or name inside of each document, and/or when a meaningful file name can be supplied, the user can more easily find it or understand its purpose. This would address the user needs identified in the WCAG 2.2 Intent from Understanding Success Criterion 2.4.2. -With this substitution, it would read: +###### Applying SC 2.4.2 Page Titled to Non-Web Software -**2.4.2 Page Titled:** [**[Non-web documents](#document)** or **[software](#software)**] have titles that describe topic or purpose. +This success criterion is problematic to apply directly to non-web software through simple word substitution because application titles rarely describe the topic or purpose of the software. However, where the platform supports a programmatic title or name for a software window or screen, when a software application utilizes that feature to provide a unique title or name for each window or screen, the user can more easily find it or understand its purpose. This would address the user needs identified in the [Intent from Understanding Success Criterion 2.4.2](https://www.w3.org/WAI/WCAG22/Understanding/page-titled#intent). The following criterion is recommended as a substitute for the WCAG language: -
- -As described in the WCAG intent, the name of a [non-web software application](#software) or [non-web document](#document) (e.g. document, media file, etc.) is a sufficient title if it describes the topic or purpose.
-
- -Although not required by this success criterion, ensuring that individual windows or screens have a title (where that title describes the topic or purpose) addresses the user needs identified in the Understanding Success Criterion 2.4.2 Intent section, and is generally considered a best practice.
- -
- -See also the [Comments on Closed Functionality](#comments-on-closed-functionality).
+**2.4.2 Non-web Software Titled:** In non-web software implemented on a platform that supports title attributes for windows or screens, titles are provided that are unique or differentiable within the software. ##### focus-order From c1026cfc7e2fd4d97c239920c5fa7bdda7a11ed4 Mon Sep 17 00:00:00 2001 From: Mary Jo Mueller Date: Mon, 6 Oct 2025 14:47:55 -0500 Subject: [PATCH 2/4] New guidance for software eliminates need for bullet in problematic for closed --- success-criteria-problematic-for-closed-functionality.md | 1 - 1 file changed, 1 deletion(-) diff --git a/success-criteria-problematic-for-closed-functionality.md b/success-criteria-problematic-for-closed-functionality.md index b84a69da..1b90a37b 100644 --- a/success-criteria-problematic-for-closed-functionality.md +++ b/success-criteria-problematic-for-closed-functionality.md @@ -41,7 +41,6 @@ For non-web software on ICT with closed functionality, those who implement this
  • 2.1.2 No Keyboard Trap — This criterion applies when focus can be moved using a keyboard interface. In some ICT with closed functionality, tactile input like numeric keypads or other functional groups of keys may be available, but there is no mechanism for onscreen focus; for example, the keys are mapped directly to functions without moving focus between on-screen controls. In this case, there is no concept of focus, and therefore keyboard traps cannot exist and this success criterion would be satisfied.
  • 2.1.4 Character Key Shortcuts — ICT with closed functionality might lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.
  • 2.4.1 Bypass Blocks — The WCAG2ICT interpretation of this success criterion replaces "sets of Web pages" with "sets of software programs" which are extremely rare - especially for non-web software on ICT with closed functionality. However, being able to bypass blocks of content that are repeated within software is generally considered best practice.
    • -
  • 2.4.2 Page Titled — Where the non-web software is part of a product that provides a single function, or has a menu-driven interface, the intent of this success criterion would be met without needing an explicit title.
  • 2.4.4 Link Purpose (In Context) — This success criterion relies upon text and context being made available in a programmatically determinable form.
  • 2.4.5 Multiple Ways — The WCAG2ICT interpretation of this success criterion replaces "set of Web pages" with "set of software programs". Such sets, particularly in the context of non-web software on ICT with closed functionality, are exceedingly rare. There are a number of notes in the section Applying SC 2.4.5 Multiple Ways to Non-Web Documents and Software that are applicable to non-web software on ICT with closed functionality.
  • 2.4.7 Focus Visible — Presumes that there is a mode of operation where focus can be moved and controlled by keyboard. Some ICT with closed functionality may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for conveying focus because the user interface is designed not to need that. For example, the keys are used to select options from a spoken menu rather than to move an onscreen focus element between multiple options. In this case, there is no concept of focus, thus there is no need for a visible indicator and this success criterion would be satisfied.
    • From 8fae33602a197b17a0efd75b0b1ee104fb193683 Mon Sep 17 00:00:00 2001 From: Mary Jo Mueller Date: Wed, 15 Oct 2025 12:04:44 -0500 Subject: [PATCH 3/4] Proposal 3: A variant using Gregg and Mike's input Gregg, Mike, and I had an email thread to develop potential language. The alternate requirement isn't exactly as Gregg had it but the note is what was proposed. I'm trying to keep this more closely aligned to WCAG2ICT's writing style which doesn't use the precondition style used in the EN 301 549. --- comments-by-guideline-and-success-criterion.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/comments-by-guideline-and-success-criterion.md b/comments-by-guideline-and-success-criterion.md index da8e356e..5022181d 100644 --- a/comments-by-guideline-and-success-criterion.md +++ b/comments-by-guideline-and-success-criterion.md @@ -590,7 +590,12 @@ See also the [Comments on Closed Functionality](#comments-on-closed-functionalit ###### Applying SC 2.4.2 Page Titled to Non-Web Documents -This success criterion is problematic to apply directly to non-web documents through simple word substitution because not all document formats provide support for a title attribute, and document titles don't always describe the topic or purpose of the document. File names, as the WCAG 2.2 Understanding document allows, also rarely describe the topic or purpose of the document – especially where the document names are not under the author’s control. However, where the document authoring tool or technology provides the capability to supply a semantic title style or name for a document, when the non-web document utilizes that feature to provide a unique title or name inside of each document, and/or when a meaningful file name can be supplied, the user can more easily find it or understand its purpose. This would address the user needs identified in the WCAG 2.2 Intent from Understanding Success Criterion 2.4.2. +This success criterion is problematic to apply directly to non-web documents through simple word substitution because not all document formats provide support for a title attribute, and document titles don't always describe the topic or purpose of the document. File names, as the WCAG 2.2 Understanding document allows, also rarely describe the topic or purpose of the document – especially where the document names are not under the author’s control. However, where the document authoring tool or technology provides the capability to supply a semantic title style or name for a document, such as page-oriented publishing tools and word processing applications, when the non-web document utilizes the title attribute to provide a unique title or name inside of each document, and/or when a meaningful file name can be supplied, the user can more easily find it or understand its purpose. This would address the user needs identified in the WCAG 2.2 Intent from Understanding Success Criterion 2.4.2. The following criterion is recommended as a substitute for the WCAG language: + +**2.4.2 Non-web Document Titled:** Where a non-web document is page-oriented and is implemented in a format that provides a "Title" metadata attribute which is editable using the primary authoring tools for that document format, the non-web document has a title that describes the topic or purpose. +
    + +The “Title” attribute is specified as "editable through that document format’s primary editing tools" so that authors can view and edit the Title without requiring specialized or external metadata utilities. The word “primary" is included to exclude specialty tools not usually used for editing particular document types. The phrase “page oriented” excludes movie, image, sound and other files that qualify as non-web documents but not intended to be covered by this requirement because AT does not genarlly access and expose title attributes for these document types even if present.
    ###### Applying SC 2.4.2 Page Titled to Non-Web Software From cf401db3519fe7201f9a941f56585548d7bd134c Mon Sep 17 00:00:00 2001 From: Mary Jo Mueller Date: Wed, 15 Oct 2025 12:13:59 -0500 Subject: [PATCH 4/4] Pulling in Daniel's editorial change as well --- comments-by-guideline-and-success-criterion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/comments-by-guideline-and-success-criterion.md b/comments-by-guideline-and-success-criterion.md index 5022181d..a54557ec 100644 --- a/comments-by-guideline-and-success-criterion.md +++ b/comments-by-guideline-and-success-criterion.md @@ -590,7 +590,7 @@ See also the [Comments on Closed Functionality](#comments-on-closed-functionalit ###### Applying SC 2.4.2 Page Titled to Non-Web Documents -This success criterion is problematic to apply directly to non-web documents through simple word substitution because not all document formats provide support for a title attribute, and document titles don't always describe the topic or purpose of the document. File names, as the WCAG 2.2 Understanding document allows, also rarely describe the topic or purpose of the document – especially where the document names are not under the author’s control. However, where the document authoring tool or technology provides the capability to supply a semantic title style or name for a document, such as page-oriented publishing tools and word processing applications, when the non-web document utilizes the title attribute to provide a unique title or name inside of each document, and/or when a meaningful file name can be supplied, the user can more easily find it or understand its purpose. This would address the user needs identified in the WCAG 2.2 Intent from Understanding Success Criterion 2.4.2. The following criterion is recommended as a substitute for the WCAG language: +This success criterion is problematic to apply directly to non-web documents through simple word substitution because not all document formats provide support for a semantic title style, and document titles don't always describe the topic or purpose of the document. File names, as the WCAG 2.2 Understanding document allows, also rarely describe the topic or purpose of the document – especially where the document names are not under the author’s control. However, where the document authoring tool or technology provides the capability to supply a semantic title style or name for a document, such as page-oriented publishing tools and word processing applications, when the non-web document utilizes the title attribute to provide a unique title or name inside of each document, and/or when a meaningful file name can be supplied, the user can more easily find it or understand its purpose. This would address the user needs identified in the WCAG 2.2 Intent from Understanding Success Criterion 2.4.2. The following criterion is recommended as a substitute for the WCAG language: **2.4.2 Non-web Document Titled:** Where a non-web document is page-oriented and is implemented in a format that provides a "Title" metadata attribute which is editable using the primary authoring tools for that document format, the non-web document has a title that describes the topic or purpose.