diff --git a/comments-by-guideline-and-success-criterion.md b/comments-by-guideline-and-success-criterion.md index 9e293ff6..7dd8110f 100644 --- a/comments-by-guideline-and-success-criterion.md +++ b/comments-by-guideline-and-success-criterion.md @@ -564,24 +564,23 @@ 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”. -With this substitution, it would read: +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 "Page" with "Non-web document" and “Web pages” with “non-web documents”. -**2.4.2 Page Titled:** **[[Non-web documents](#document) or [software](#software)]** have titles that describe topic or purpose. +With this substitution, it would read: +**2.4.2 [Non-Web Document] Titled:** **[[Non-web documents](#document)]** have titles that describe topic or purpose.
-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.
+As described in the WCAG intent, the name of a [non-web document](#document) (e.g. document, media file, etc.) is a sufficient title if it describes the topic or purpose. -
- -See also the [Comments on Closed Functionality](#comments-on-closed-functionality).
+###### Applying SC 2.4.2 Page Titled to Non-Web Software + +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](#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 c30f0257..113ae2b1 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 products with closed functionality, those who implement
  • 2.1.2 No Keyboard Trap — This criterion applies when focus can be moved using a keyboard interface. In some closed systems, 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 — Certain closed systems 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 closed functionality software. 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 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 closed functionality software, 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 closed functionality software.
  • 2.4.7 Focus Visible — Presumes that there is a mode of operation where focus can be moved and controlled by keyboard. Some closed systems 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.