The survey results for 2.5.2 Pointer Cancellation in the SC problematic for Closed Functionality section resulted in 2 proposals for this SC:

Option 1: Original text

1.4.5 Images of Text—because there is no need to impose a requirement on all closed functionality that text displayed on the screen actually be represented internally as text (as defined by WCAG 2), given that there is no interoperability with assistive technology;

Option 2: Proposed update

1.4.5 Images of Text—Requires text for interoperability with assistive technology and high-quality resizing. Where other mechanisms achieve equivalent results, this criterion does not apply. An example of a system with closed functionality achieving equivalent results would be for that system to provide audio description for all onscreen information, and either support zooming or ensure that text is large enough to be legible if zooming is not supported.

Indicate your preference and any potential edit or alternate proposals.

Summary

Details

The survey results asking if any additional SCs should be added to the SC problematic for Closed Functionality section and SC 2.4.3 Link Purpose (In context) had a comment resulting in the following proposal:

Option 1: 2.4.3 Link Purpose (In context) does not need a bullet

Option 2: Proposed bullet

2.4.3 Link Purpose (In Context) - Requires text and context in a programmatically determinable form. Where another mechanism provides link purpose information for built-in assistive technology functions, this criterion does not apply.

Indicate your preference and any potential edits or alternate proposals.

Summary

Details

The survey results in the SC problematic for Closed Functionality section had a comment that 4.1.3 Status Messages needs an update. The comment said: "Keep the first two sentences. Change the "NOTE" to point to non-web software in general." This results in 2 proposals for this SC:

Option 1: Original bullet, as-is

4.1.3 Status Messages—requires information in a programmatic determinable form. Additionally, software with closed functionality is not typically implemented using markup languages.

NOTE 5: Non-web software with closed functionality would need equivalent facilitation to provide access to status messages.

Option 2: With suggested edits

4.1.3 Status Messages—requires information in a programmatic determinable form. Additionally, software with closed functionality is not typically implemented using markup languages. (See Note 1 in a href=https://www.w3.org/2002/09/wbs/55145/wcag2ict-sc-problematic-for-closed/results#xq25 target=”_blank”>Applying SC 4.1.3 Status Messages to Non-web Documents and Software.)

Indicate your preference and any potential edits or alternate proposals.

Summary

Details

Updates are being proposed for the "closed functionality" key term section based on the original proposal and incorporating comments from the survey "closed functionality" question that closed on 8 Nov. The updates include a reference to the more detailed examples as well as a proposed update to the note to try to address Sam's concern. The other option is to remove the note as Sam suggested in his survey comment. Read the proposed update to the key term "closed functionality"

Indicate the readiness to incorporate into the editor's draft.

Summary

Details

Updates are being proposed for the "closed functionality" example callout section based on the updated proposal and incorporating comments from the survey "closed functionality" question that closed on 8 Nov. into that proposal. The sentence introducing the examples, the telephony bullet clarification, and changing ABM to ATM are some of the more major changes included. Read the proposed update to the example callout in the proposed Comments on Closed Functionality section.

Indicate the readiness to incorporate into the editor's draft.

Summary

(1 response didn't contain an answer to this question)

Details

Updates are being proposed for the Comments on Closed Functionality section section based on the updated proposal and incorporating survey comments, Shadi's PR, and Mitch's email thread content that resulted from the survey question on the rest of the introductory Closed Functionality text that closed on 8 Nov. There were quite a number of proposed changes too numerous to detail here. The second paragraph has 2 options - Mitch's full proposal, or a less extensively edited version. The answers to this question will ask your preference, and ask for any other potential edits you think are needed. Review the proposed update to the proposed Comments on Closed Functionality section (excluding the example callout which was reviewed in an earlier question).

Indicate the readiness to incorporate into the editor's draft.

We can discuss in the WCAG2ICT meeting some specific comments from the last survey that have not been incorporated quite yet to see if they are needed. These are:

• Removal (or editing) of the sentence in the last paragraph regarding not applying WCAG to hardware that currently states, "This document does not comment on those standards, but does note that WCAG success criteria should not be used as requirements for hardware aspects of closed functionality ICT."
• Left the last "software" part in the last paragraph but hopefully edited it enough to address Shadi's concern/PR.

Summary

Details