w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: maryjom@us.ibm.com
This questionnaire was open from 2023-12-13 to 2024-01-10.
6 answers have been received.
Jump to results for question:
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.
Choice | All responders |
---|---|
Results | |
Prefer option 1, as-is. | |
Prefer option 1, with edits. | |
Prefer option 2, as-is. | 1 |
Prefer option 2, with edits. | 5 |
Something else (provide your alternate proposal) |
Responder | SC Problematic for Closed Functionality: 1.4.5 Images of Text | Comments |
---|---|---|
Phil Day | Prefer option 2, with edits. | "this criterion does not apply" should be reworked for consistency (the intent of SC is met) |
Thorsten Katzmann | Prefer option 2, with edits. | should be formulated positively "criterion applies" |
Loïc Martínez Normand | Prefer option 2, with edits. | +1 to Phil's "the intent of the success criterion is met". |
Mike Pluke | Prefer option 2, with edits. | I agree with the change proposed by Phil and Loïc. |
Fernanda Bonnin | Prefer option 2, with edits. | +1 to Phil's suggestion |
Bruce Bailey | Prefer option 2, as-is. | I am also okay with option 1, but it needs a little more word smithing. It should not start with "because" and can shortened. For example: There is not a requirement 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. |
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.
Choice | All responders |
---|---|
Results | |
Prefer option 1, no bullet needed. | |
Prefer option 2, as-is. | 3 |
Prefer option 2, with edits. | 3 |
Something else (provide your alternate proposal) |
Responder | SC Problematic for Closed Functionality: 2.4.3 Link Purpose (In Context) | Comments |
---|---|---|
Phil Day | Prefer option 2, as-is. | |
Thorsten Katzmann | Prefer option 2, as-is. | |
Loïc Martínez Normand | Prefer option 2, with edits. | I suggest what Phil proposed for 1.4.5: instead of "this criterion does not apply", we should have "the intent of the success criterion is met". |
Mike Pluke | Prefer option 2, with edits. | I agree with Loïc's proposed change. |
Fernanda Bonnin | Prefer option 2, with edits. | editorial: S.C. number is 2.4.4 not 2.4.3 |
Bruce Bailey | Prefer option 2, as-is. |
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.
Choice | All responders |
---|---|
Results | |
Prefer option 1, as-is. | 5 |
Prefer option 1, with edits. | |
Prefer option 2, as-is. | |
Prefer option 2, with edits. | |
Something else (provide your alternate proposal) | 1 |
Responder | SC Problematic for Closed Functionality: 4.1.3 Status Messages | Comments |
---|---|---|
Phil Day | Prefer option 1, as-is. | But also happy with option 2 |
Thorsten Katzmann | Prefer option 1, as-is. | |
Loïc Martínez Normand | Prefer option 1, as-is. | |
Mike Pluke | Prefer option 1, as-is. | |
Fernanda Bonnin | Prefer option 1, as-is. | |
Bruce Bailey | Something else (provide your alternate proposal) | We need a way to write that the Task Force has a consensus opinion that some SC are not applicable. Here is my attempt for SC 4.1.3: 4.1.3 Status Messages--is scoped to content implemented using markup languages. By definition, this means SC 4.1.3 is not usable for non-web documents and non-web software. SC 4.1.3 does not apply to status messages which are not implemented using markup languages. |
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.
Choice | All responders |
---|---|
Results | |
Incorporate proposed text, as-is. | 3 |
Incorporate proposed text, with edits. | 3 |
Incorporate proposed text, removing the note and leave the rest as-is. | |
Incorporate proposed text, removing the note, and with additional edits. | |
Something else. |
Responder | Update to "closed functionality" key term definition | Comments |
---|---|---|
Phil Day | Incorporate proposed text, as-is. | |
Thorsten Katzmann | Incorporate proposed text, as-is. | |
Loïc Martínez Normand | Incorporate proposed text, with edits. | I have only a suggestion to change the computer example. First, to change the order of words for clarification (moving "due to policy" just after "locked down"). Second, to add text to refer to the restriction to install software. My proposal would be: "computer that is locked down due to a policy so that users may not adjust settings or install software". |
Mike Pluke | Incorporate proposed text, with edits. | I agree with Loïc's two proposals. |
Fernanda Bonnin | Incorporate proposed text, as-is. | |
Bruce Bailey | Incorporate proposed text, with edits. | I like the note and the examples. I would very much prefer if we could avoid the word "functionality" in the definition of closed functionality. For example: a property or characteristic of ICT that prevents users from attaching, installing, or using assistive technology |
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.
Choice | All responders |
---|---|
Results | |
Incorporate proposed text, as-is. | 4 |
Incorporate proposed text, with edits. | 1 |
Something else. |
(1 response didn't contain an answer to this question)
Responder | Update to detailed examples of closed functionality callout | Comments |
---|---|---|
Phil Day | Incorporate proposed text, as-is. | |
Thorsten Katzmann | Incorporate proposed text, as-is. | |
Loïc Martínez Normand | Incorporate proposed text, as-is. | |
Mike Pluke | Incorporate proposed text, as-is. | |
Fernanda Bonnin | ||
Bruce Bailey | Incorporate proposed text, with edits. | I like the examples, and I get that "iOt" is Internet of Things, but I think we should spell those word out (or use a parenthetical). |
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:
Choice | All responders |
---|---|
Results | |
Prefer edits with Proposal 1 text, as-is. | 4 |
Prefer edits with Proposal 1 text, with the following changes. | |
Prefer edits with Proposal 2 text, as-is. | 1 |
Prefer edits with Proposal 2 text, with the following changes. | 1 |
Something else. |
Responder | Update to Closed Functionality introductory text (not the example callout) | Comments |
---|---|---|
Phil Day | Prefer edits with Proposal 1 text, as-is. | I think that I prefer proposal 1 as it is easier to read. Proposal 2 contains more nuance, but takes more effort to parse. However, I'm happy to go with the majority of others all feel proposal 2 is better. |
Thorsten Katzmann | Prefer edits with Proposal 1 text, as-is. | |
Loïc Martínez Normand | Prefer edits with Proposal 2 text, as-is. | I prefer proposal 2, as the issue of closed functionality (total or partial) is complex and requires a longer explanation with several examples. But I can accept proposal 1 if the majority goes for it. |
Mike Pluke | Prefer edits with Proposal 1 text, as-is. | |
Fernanda Bonnin | Prefer edits with Proposal 1 text, as-is. | |
Bruce Bailey | Prefer edits with Proposal 2 text, with the following changes. | I have strong preference for Proposal 2 over Proposal 1. I do like that Proposal 1 is easier to read, but I think the nuance provided by 2 is important. I think the ending sentence of Proposal 2 could be improved, since "closed functionality" is not a noun. Current: WCAG2ICT points out which success criteria depend on assistive technologies—and therefore would not work by themselves for closed functionality. Proposed: WCAG2ICT points out which success criteria depend on assistive technologies—and therefore which SC would not be sufficient for assuring the accessibility of non-web documents and software with closed functionality. |
The following persons have not answered the questionnaire:
Send an email to all the non-responders.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
w3c/wbs-design
or
by mail to sysreq
.