NOTE: Since we are close to publishing, this survey will provide the original content vs. proposed changes - most of which are clarifications. Therefore survey answers will be to either leave as is, or merge in the proposed changes (with or without edits). The point is to avoid opening this or other content up for rewriting.

Review the proposed changes to the definition of "closed functionality" in PR 375 Key Terms file. You can read all of the proposed changes to the key term closed functionality in context. Then answer the first three questions of the survey regarding the proposed changes that are substantive (beyond simple editorial).

This is the first of 3 questions and focuses on the proposed change to the definition verbiage, repeated below.

Option 1: Original definition

closed functionality (as used in WCAG2ICT)

a property or characteristic that prevents users from attaching, installing, or using assistive technology

Option 2: Proposed updated definition

closed functionality (as used in WCAG2ICT)

a property or characteristic that prevents users from attaching, installing, or using assistive technology or the accessibility features built into platform software (operating systems, players, and other software that is between the software being evaluated and the user)

Indicate which option you prefer. If edits are needed, provide the detailed edits in the survey or in the PR.

Summary

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

Details

This is the second question regarding proposed changes to the key term "closed functionality", specifically the Examples callout box. Use the links in the previous question to see the detailed changes in the PR and the in-context view of all changes being proposed. NOTE: If these edits are accepted, they would also be similarly changed as shown in the example callout box in the Comments on Closed Functionality section.

Option 1: Original bullet 2 in the examples

• telephony devices such as IP phones, feature phones, smartphones, and phone-enabled tablets (although such devices are becoming increasingly open and/or supplying AT and accessibility features that software can rely upon to meet WCAG requirements.)

Option 2: Edit bullet 2, and move and rewrite the parenthetic content in the bullet as a Note after the list of examples

• telephony devices such as internet-phones, feature phones, smartphones and phone-enabled tablets

NOTE: Some of these technologies, though closed to some external assistive technologies, often have extensive internal accessibility features that serve as AT that can be used by applications on these devices in the same way AT is used on fully open devices like desktop computers. Others are open to some types of assistive technology but not others. (Thus, we talk about “closed functionality” rather than closed products in this document.)

Indicate which option you prefer. If edits are needed, provide the detailed edits in the survey or in the PR.

Summary

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

Details

This is the third and final question regarding possible guidance changes the key term "closed functionality". The last statement in the key term "closed functionality" section says:

Existing text says: These examples are explained more fully in the Comments on Closed Functionality section.

The problem is that we had switched to have the more brief examples in the Comments on Closed Functionality section, and the more detailed ones in the key term "closed functionality". So either this statement needs to moved to the same location in Comments on Closed Functionality section and changed to refer to the key term "closed functionality," or we simply remove the statement.

Review the following proposals:

Proposal 1: Remove the statement

Proposal 2: Move the statement to Comments on Closed Functionality, and edit

Edited text would say: These examples are explained more fully in the definition of closed functionality in the Key Terms section.

Indicate whether you agree with adding this note. If further edits are needed, provide the detailed edits in the survey or in the Google doc.

Summary

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

Details

Here is a link to PR 375's changes to the comments by guideline and success criterion file so you can see all of the substantive changes and edits to proposed for this part of the document. This and the next question will cover proposed SC changes separately. To read the changes to the SCs in context, each question will give you a direct link to the pertinent SC's section in the built document.

This first question is about proposed changes to Applying 1.4.10 Reflow to Non-Web Documents and Software where you can read the proposed changes in-context. Excerpted text below shows the the original Note 8 vs. the proposed changes:

Option 1: Original Note 8 for 1.4.10 Reflow

Some software applications provide a mode of operation where reflow is possible, while other modes are unable to reflow. An example is a document authoring tool, which includes both a "print preview mode" (without reflow, for users to view the spatial formatting) and a "drafting view mode" where reflow is supported.

Option 2: Clarified Note 8 for 1.4.10 Reflow

Some software applications provide a mode of operation where reflow is possible, while other modes are unable to reflow. An example is a document authoring tool, which includes both a "print preview mode" (without reflow, for users to view the spatial formatting) and a "drafting view mode" where reflow is supported. Such software would satisfy this success criteria as long as there is no loss of information or functionality in the drafting view.

Indicate which option you prefer, and whether it can be incorporated as-is or needs edits. If edits are needed, be specific and provide them either in the PR or in this survey.

Summary

(2 responses didn't contain an answer to this question)

Details

This proposal is to modify Note 1 in the general guidance for 2.1.1 Keyboard. The changes appear in lines 386-389 of the PR file linked in the previous question.

Please review the updated content in-context (will appear as Notes 1 and 2) in Applying SC 2.1.1 Keyboard to Non-Web Documents and Software from PR 338.

Option 1: Original Note 1

Note 1: This does not imply that software always needs to directly support a keyboard or “keyboard interface”. Nor does it imply that software always needs to provide a soft keyboard. Underlying platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard and would comply.

Option 2: Edited Note 1 and split off first 2 sentences into Note 2

Note 1: Keyboard interface does not refer to a physical device but to the interface between the software and any keyboard or keyboard substitute (i.e., this interface where the software accepts text or other keystroke input). Underlying platform software may provide device independent input services to applications that enable operation via such a keyboard interface. Software that supports operation via such platform device independent services would be operable via a keyboard interface and would satisfy the success criterion.

Note 2: This does not imply that software always needs to directly support a keyboard or “keyboard interface”. Nor does it imply that software always needs to provide a soft keyboard.

Also note that if changes in Option 2 are accepted, they will also be reflected in the section as shown in Applying "keyboard interface" to Non-Web Documents and Software.

Indicate which proposal you prefer and if any edits are needed.

Summary

Details

There are a few changes proposed for the SC Problematic for Closed Functionality file. This file shows the details of the changes that are the subject of the next few survey questions. You can read the changes in-context using this link to the built document's section SC Problematic for Closed Functionality

This is the first question regarding those proposed changes, focused on the introductory content, the 2nd paragraph. The proposed change is in line 6 of the file (link above), and excerpted out into the survey as options below.

Option 1: Original content

There are success criteria that can be problematic for developers of ICT with closed functionality. Some criteria discuss making information available in text (which can be read by assistive technologies), making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies), or doing something else to make content compatible with assistive technologies. Where ICT with closed functionality doesn’t support use of assistive technology or the platform is not sophisticated enough to have an accessibility API, providing equivalent information and operation through another mechanism, such as functions built into the software that behave like assistive technology, would help meet the intent of these success criteria.

Option 2: Updated to add verbiage at the end of the paragraph

There are success criteria that can be problematic for developers of ICT with closed functionality. Some criteria discuss making information available in text (which can be read by assistive technologies), making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies), or doing something else to make content compatible with assistive technologies. Where ICT with closed functionality doesn’t support use of assistive technology or the platform is not sophisticated enough to have an accessibility API, providing equivalent information and operation through another mechanism, such as functions built into the software that behave like the various assistive technologies, would help meet the intent of these success criteria – although this is challenging given the range of existing and emerging assistive technologies. Those trying to apply the WCAG success criteria to closed functionality will need to consider the wide variety of assistive technologies that are no longer available when product functionality is closed and the impact on those who rely on those assistive technologies.

Indicate which option you prefer. If edits are needed, provide the detailed edits in the survey or in the PR.

Summary

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

Details

Using the same links as question 6, this question focuses on proposed edits to the 1.3.4 Orientation content in SC Problematic for Closed Functionality.

Option 1: Original content for 1.3.4 Orientation

1.3.4 Orientation - Products with closed functionality that have fixed-in-place displays or other limitations to modifying the physical display orientation are covered under the essential exception and are not required to provide support for orientation changes. See the note in the section Applying SC 1.3.4 Identify Input Purpose to Non-Web Documents and Software.

Option 2: Updated to add verbiage at the end of the paragraph

1.3.4 Orientation - Products with closed functionality that have fixed-in-place displays or other limitations to modifying the physical display orientation should be considered as examples that are covered under the essential exception. See the note in the section Applying SC 1.3.4 Identify Input Purpose to Non-Web Documents and Software.

Indicate which option you prefer. If edits are needed, provide the detailed edits in the survey or in the PR.

Summary

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

Details

Using the same links as question 6, this question focuses on proposed edits to the 1.4.10 Reflow content in SC Problematic for Closed Functionality.

Option 1: Original content for 1.4.10 Reflow

1.4.10 Reflow - Some software on ICT with closed functionality does not support scrolling content or changing the viewport (examples include software for self-service transaction machines or kiosks). Therefore, there would be no content to which this success criterion applies, meaning the success criterion would be satisfied. Instead, other requirements exist outside of WCAG to address use by persons with low vision (including but not limited to using sufficiently large text and single screen designs).

Option 2: Updated to soften last sentence regarding existence of requirements

1.4.10 Reflow - Some software on ICT with closed functionality does not support scrolling content or changing the viewport (examples include software for self-service transaction machines or kiosks). Therefore, there would be no content to which this success criterion applies, meaning the success criterion would be satisfied. Instead, other requirements outside of WCAG would be needed to address use by persons with low vision (including but not limited to using sufficiently large text).

Indicate which option you prefer. If edits are needed, provide the detailed edits in the survey or in the PR.

Summary

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

Details

Using the same links as question 6, this question focuses on proposed edits to the 2.1.1 Keyboard content in SC Problematic for Closed Functionality.

Option 1: Original content for 2.1.1 Keyboard

2.1.1 Keyboard - Assumes operation via a keyboard interface which also allows for alternative input devices. When a product with closed functionality does not have a standard keyboard or an alternative input device cannot be connected, it may not be possible to satisfy this success criterion. It may be possible to address some user needs (such as offering input methods that support users with low vision, without vision, or limited manual dexterity).

Option 2: Make changes to 2nd sentence (aligned with proposed changes to general guidance)

2.1.1 Keyboard - Assumes operation via a keyboard interface which also allows for alternative input devices. When a product with closed functionality does not have a standard keyboard, or an alternative keyboard (hardware or software) cannot be connected that provides keyboard-like input, it may not be possible to satisfy this success criterion. It may be possible to address some user needs (such as offering input methods that support users with low vision, without vision, or limited manual dexterity).

Indicate which option you prefer. If edits are needed, provide the detailed edits in the survey or in the PR.

Summary

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

Details

Using the same links as question 6 (the one marked with 1 of 6), this question focuses on proposed edits to the 2.4.2 Page Titled content in SC Problematic for Closed Functionality.

Option 1: Original content for 2.4.2 Page Titled

2.4.2 Page Titled - Where the software is part of a product that provides a single function, or has a menu-driven interface, there is no need for a title and the intent of this success criterion would be met.

Option 2: Soften language regarding "there is no need for a title"

2.4.2 Page Titled - Where the software is part of a product that provides a single function, or has a menu-driven interface, we suggest there is no need for a title.

Indicate which option you prefer. If edits are needed, provide the detailed edits in the survey or in the PR.

Summary

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

Details

Using the same links as question 6 (the one marked with 1 of 6), this question focuses on proposed edits to the 3.3.1 Error Identification content in SC Problematic for Closed Functionality.

Option 1: Original content for 3.3.1 Error Identification

3.3.1 Error Identification - It is important for errors that can be detected to be described to the user; for ICT with closed functionality, the error description doesn’t have to be provided in text, as defined in WCAG 2.

Option 2: Clarify "programmatically determinable text" and add phrasing about alternatives in multiple forms

3.3.1 Error Identification - It is important for errors that can be detected to be described to the user; for ICT with closed functionality, the error description doesn’t have to be provided in programmatically determinable text, as defined in WCAG 2 (but it should be available in multiple forms - as all content should be.)

Indicate which option you prefer. If edits are needed, provide the detailed edits in the survey or in the PR.

Summary

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

Details