diff --git a/comments-by-guideline-and-success-criterion.md b/comments-by-guideline-and-success-criterion.md index 7d7cdf09..a54557ec 100644 --- a/comments-by-guideline-and-success-criterion.md +++ b/comments-by-guideline-and-success-criterion.md @@ -588,24 +588,20 @@ 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 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: -With this substitution, it would read: +**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. +
-**2.4.2 Page Titled:** [**[Non-web documents](#document)** or **[software](#software)**] have titles that describe 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.
-
- -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.
+###### Applying SC 2.4.2 Page Titled to Non-Web Software -
- -See also the [Comments on Closed Functionality](#comments-on-closed-functionality).
+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: + +**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 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.