The participants in the extra Friday meeting on 24 May worked to address comments from questions in the previous survey that proposed changes to the WCAG2ICT draft. All but two of the new proposals can be found in the Google doc to solve the 23 May survey comments. The options have been narrowed to one or two to items for each question, but other numbered items are left in the document for historical purposes. A new pull request was made to enable reading the changes in-context. Links to specific files and sections are provided with the questions they pertain to.

Review the proposed changes to the definition of "closed functionality" in PR 375 Key Terms file line 28. You can read all of the proposed changes to the key term closed functionality in context. This proposal also provides a new key term definition which can be read in-context: "platform software".

There are three questions in the survey regarding proposed changes to "closed functionality". This question focuses on the proposed change to the definition verbiage, excerpted below.

NOTE: The last survey was very split on the two proposals (3 preferred option 1, 4 preferred option 2 - 3 of those with proposed changes to option 2), so two options are again presented for this question with the requested edits incorporated into Option 3 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 3: Updated proposal from last week based on survey comments

closed functionality (as used in WCAG2ICT)

a property or characteristic that prevents users from attaching, installing, or using either assistive technology or the accessibility features built into platform software

Add a new definition for "platform software" using the definition from the EN 301 549

platform software

collection of software components that runs on an underlying software or hardware layer, and that provides a set of software services to other software components that allows those applications to be isolated from the underlying software or hardware layer

NOTE: Should the new definition be accepted, the editors will sweep the document to add links to the definition from all uses of the term "platform software".

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

Summary

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

Details

Note, the survey results from last week showed a high preference for Option 2 - 2 preferred option 1 (but both were OK with option 2 with edits), 5 preferred Option 2 (4 with edits). Option 3 below incorporates the comments from last week's survey.

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.

For reference only: 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 3: Edited option 2 from last week's survey

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

Then after the list of examples, add the following note:

NOTE: Some of these technologies, though closed to some external assistive technologies, often have extensive internal accessibility features that serve as assistive technology that can be used by applications on these devices in the same way assistive technology is used on fully open devices, such as desktop computers. Others are open to some types of assistive technology but not others.

Indicate if Option 3 is ready to incorporate into the editor's draft. 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

Note, Option 1 from last week's survey was removed in this question since the survey results indicated a strong preference for Proposal 2, as-is with only 1 of 7 preferring option 1. Therefore, we are working to reach consensus on Option 2.

This is the third and final question regarding possible guidance changes the key term "closed functionality". Since proposal 2 received overwhelming support in the previous survey, the text is shown below as it appears in the Comments on Closed Functionality file in the pull request (line 23).

Option 2: Move statement from key term to Comments on Closed Functionality

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

Indicate whether the proposal is ready to incorporate into the editor's draft. If further 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

Note, Option 1 from last week's survey was removed in this question because Option 2 was preferred, as-is by all 6 respondents. The Option 2 proposal has only an editorial change, in italics.

Here is a link to PR 378'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. In the last survey of the proposed edits (from May 23), 6 respondents indicated Option 2 was preferred, as-is. So in this survey Option 1 has been removed. You can see what changes were made by looking at line 288 in the file.

Text below also shows the proposed changes in bold:

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 criterion as long as there is no loss of information or functionality in the drafting view.

Indicate whether this proposal 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

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

Details

Note, Option 1 from last week's survey is only for reference in this question because Option 2 was preferred, by 7 out of 8 respondents, with 5 requesting edits to option 2. The Option 4 proposal was developed to address the edits requested.

This proposal is to modify Note 1 in the general guidance for 2.1.1 Keyboard and split part of it into a new note. The changes appear in lines 386-389 of the general SC guidance file. You can 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.

This also proposes the addition of a new definition of "virtual keyboard" in the key terms file, which appears in lines 225-238 and can be read in-context at virtual keyboard.

For comparison only: 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 4: Last week's Option 2 with survey comments incorporated

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., an 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 success criterion 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 virtual keyboard.

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

Here's the excerpted key term definition of "virtual keyboard":

Virtual Keyboard

any software that acts as a keyboard and generates output that is treated by other software like keystrokes from a keyboard

NOTE: Speech, eye-gaze, sip-and-puff, sounds, switches, and codes have all been used by virtual keyboards as input that generates "keystroke" output.

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

Summary

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

Details

Review the 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 in the 2nd paragraph. The proposed change is in line 6 of the file (first link for this question, above), and excerpted as text below with changes highlighted in bold.

Note, Option 1 from last week's survey was removed, as the Friday group proposed an option that addressed concerns raised on Option 2 from last week's survey. The Option 3 proposal below was developed to address the edits requested.

Option 3: 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 does not 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. See also the Comments on Closed Functionality section.

Additionally some small clarifications were needed in the 2nd paragraph after the editor's note in the Comments on Closed Functionality section as follows: (NOTE: exact changes are highlighted in the closed functionality.md file in line 10.) Excerpted text is shown below with changes highlighted in bold text:

ICT with closed functionality does not allow the use of some assistive technologies for some or all of the ICT's functions. In many cases, such ICT also lacks a “user agent” or its equivalent. To the extent the ICT is closed, following the WCAG success criteria by themselves will not ensure that non-web software is accessible. Where the wide range of assistive technologies or user agents are not available, as they are for Web content, to address the intent of these success criteria, something else needs to be provided or be required to facilitate accessibility as intended by WCAG 2. It is outside the WCAG2ICT Task Force Work Statement to say what additional measures are needed, but WCAG2ICT points out which success criteria depend on assistive technologies - and therefore which success criteria would be problematic in the context of ICT with closed functionality.

Indicate whether these changes are ready to incorporate into the editor's draft. 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

Note, Option 1 from last week's survey is for reference only, as the Friday group proposed an option that addressed concerns raised on Option 2 from last week's survey and feel it is a good compromise without having a normative exception in WCAG2ICT. The Option 5 proposal was developed to address the edits requested and concerns raised by those who chose Option 1 last week.

This question focuses on proposed edits to the 1.3.4 Orientation content in SC Problematic for Closed Functionality which appears on line 18 of the file closed-functionality.md. You can read the changes in-context using this link to the built document's section SC Problematic for Closed Functionality.

For comparison only: 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 5: Remove the normative-sounding content from the original

1.3.4 Orientation - Products with closed functionality that have fixed-in-place displays or other limitations that prevent 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 whether Option 5 is ready to incorporate into the editor's draft. 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

Note, Option 1 from last week's survey is for reference only, because the survey results from last week had a strong preference for Option 2, as-is. This question is an attempt to reach consensus on Option 2.

This question focuses on proposed edits to the 1.4.10 Reflow content in SC Problematic for Closed Functionality which appears on line 30 in the file closed-functionality.md. In last week's survey, 7 of 8 respondents preferred option 2, as is (shown below). You can read the changes in-context using this link to the built document's section SC Problematic for Closed Functionality. Asking in the survey once more to obtain consensus - no further changes have been proposed.

For comparison only: 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 whether Option 2 is ready to incorporate into the editor's draft. If edits are needed, provide the detailed edits in the survey or in the PR.

Summary

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

Details

Note, Option 1 from last week's survey is for reference only, because the survey results from last week had a strong preference for Option 2, as-is with one person requesting a minor edit. This question is an attempt to reach consensus on Option 2, as edited.

This question focuses on proposed edits to the 2.1.1 Keyboard content in SC Problematic for Closed Functionality which appears on line 41 of the file closed-functionality.md. You can read the changes in-context using this link to the built document's section SC Problematic for Closed Functionality.

For comparison only: 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 3: Changed 2nd sentence (aligned with proposed changes to general guidance) and edited per the last survey

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) that provides keyboard-like input 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).

Indicate whether the proposed changes in Option 3 are ready to merge into the editor's draft. If edits are needed, provide the detailed edits in the survey or in the PR.

Summary

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

Details

Note, Option 1 from last week's survey is for reference only, because the survey results from last week indicated it contained a normative statement in the language. This question is an attempt to reach consensus on Option 3, which takes Option 2 from the last survey and contains edits to address concerns expressed in the survey.

This question focuses on proposed edits to the 2.4.2 Page Titled content in SC Problematic for Closed Functionality which appears on line 45 of the file closed-functionality.md. You can read the changes in-context using this link to the built document's section SC Problematic for Closed Functionality.

For comparison only: 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 3: Soften language regarding "there is no need for a title" with edits from the last survey

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.

Indicate whether this update is ready to incorporate into the editor's draft. 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

Note, Option 1 from last week's survey is for reference only, because the survey results from last week indicated a strong preference for Option 2 (2 to 5), though there were requested edits to Option 2. This question is an attempt to reach consensus on Option 5, which takes Option 2 from the last survey and incorporates edits to address concerns expressed in last week's survey.

This question focuses on proposed edits to the 3.3.1 Error Identification content in SC Problematic for Closed Functionality which appears on line 58 of the file closed-functionality.md. You can read the changes in-context using this link to the built document's section SC Problematic for Closed Functionality.

For comparison only: 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 5: Use language that avoids stating an exception

3.3.1 Error Identification - Requires error information to be provided as text in a programmatically determinable form.

Indicate whether Option 5 is ready to incorporate into the editor's draft. If edits are needed, provide the detailed edits in the survey or in the PR.

Summary

Details

This proposal is to add Note 4 to the general guidance for 3.3.8 Accessible Authentication (Minimum). We previously reviewed and rejected a different proposal 2 weeks ago, so a new proposal was developed by the Friday sub-group. The proposed changes appear in line 1033 of the general SC guidance file.

You can review the updated content in-context (will appear as Note 4) in Applying SC 3.3.8 Accessible Authentication to Non-Web Documents and Software from PR 378.

Option 5: Updated proposal due to the note not being approved previously

Note 4: There are cases where non-web software has an authentication process and no alternative or assistance mechanism is feasible, for example when entering a password on first start of a product. In such situations, it may not be possible for the non-web software to meet this success criterion.

Indicate whether this proposal is ready to incorporate into the editor's draft or if any edits are needed.

Summary

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

Details

This proposal is to add a Note to the general guidance for 2.4.11 Focus Not Obscured (Minimum). We previously reviewed and rejected a different proposal 2 weeks ago, so a new proposal was developed by the Friday sub-group. The proposed note appears on line 647 of the general SC guidance file.

You can review the updated content in-context (will appear as Note 1) in Applying SC 2.4.11 Focus Not Obscured (Minimum) to Non-Web Documents and Software from PR 378.

Option 3: May not be possible to satisfy

Note: There are cases where non-web software has toolbars or other overlapping content where it may not be possible to satisfy this success criterion.

Indicate whether this proposal is ready to incorporate into the editor's draft or if any edits are needed.

Summary

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

Details