W3C

Results of Questionnaire WCAG2ICT - Review updated proposal for edits to Closed Functionality

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-11-04 to 2023-11-08.

9 answers have been received.

Jump to results for question:

  1. Proposed heading title for the Closed Functionality section
  2. Review updates to the examples (in Examples callout)
  3. Proposed examples changes for "closed functionality" definition
  4. Review the rest of the text (not the Examples callout)

1. Proposed heading title for the Closed Functionality section

The last survey indicated that "Closed Functionality Products" was not an ideal title for the section. The title change is needed to provide a document anchor different from the definition. Several alternate suggestions were provided, listed below. Please indicate your preference or provide an alternate proposal.


  1. Closed Functionality Situations
  2. Closed Functionality Contexts
  3. Comments on Closed Functionality
  4. Software with Closed Functionality
  5. Closed Functionality Examples

Summary

ChoiceAll responders
Results
Prefer #1
Prefer #2
Prefer #3 3
Prefer #4 1
Prefer #5
Something else 5

Details

Responder Proposed heading title for the Closed Functionality sectionComments
Gregg Vanderheiden Something else nice to start with "Closed Functionality" since that is what people will be looking for.

Suggest.
Closed Functionality Considerations. or.
Closed Functionality and WCAG 2.2. or
Closed Functionality Guidance
Shadi Abou-Zahra Prefer #3 I chose #3 because it's consistent with the following section "Comments on Conformance". I'm also happy with #1, #2, and #5. Please don't use #4 because the EAA considers OS-level software to be part of the hardware product, so that using the term software here might be ambiguous.
Phil Day Something else I'd prefer that we change the section name back to "Closed Functionality", and rename the definition anchor to something different (like defn-closedFunctionality).
All the alternatives above are rather wordy.

If we cannot change the definition anchor, then options 3 or 5 are least bad in my opinion, with 3 being slightly preferred.
Olivia Hogan-Stark Something else +1 to Phil's comment
Loïc Martínez Normand Prefer #3 After reading other comments, I have to agree with Shadi. To me the best option is "Comments on Closed Functionality".
Mike Pluke Something else +1 to Phil's comment.
Sam Ogami Something else +1 to Phil's comment.
Bruce Bailey Prefer #4 FWIW, i think "software with closed functionality" is better than "ICT with closed functionality" since it further reinforces how problematic it is to apply WCAG to hardware.

I seem to be the only one preferring 4, but I am happy to defer. +1 to edits proposed in survey.

Mary Jo Mueller Prefer #3 I wish I had full control over the ids used for anchors. Because we are using markdown, I do not know of a way to manually set an anchor name for the key term definition, as it is automatically set as derived by the heading name. I believe it seems to be typical W3C (or at least WCAG) convention to have the anchor match the heading.

I prefer 3 because it is consistent with "Comments on Conformance" section. #2 is my 2nd favorite, and I could also go with Gregg's suggestion of "Closed Functionality Considerations" as this section doesn't really contain guidance, and I'd prefer to leave WCAG 2.2 out of the headings as we don't use that anywhere else.

2. Review updates to the examples (in Examples callout)

Read the examples callout (yellow box) in the Closed Functionality section. Determine if the updated examples are sufficient to address Issue 217 - Stale closed functionality examples as well as numerous comments from the previous survey. Indicate whether the examples are ready to merge into the editor's draft. If you wish to see the specific changes from the original content, look at Pull Request 254.

Summary

ChoiceAll responders
Results
The examples are sufficiently covered, as is. 3
The examples are sufficiently covered, with edits. 5
Would like more major changes to the examples. 1

Details

Responder Review updates to the examples (in Examples callout)Comments
Gregg Vanderheiden The examples are sufficiently covered, with edits. I think the smartphone item will confuse people since smartphones often have AT-like functionality built in. Suggest we add some language like this to that bullet

- telephony devices such as IP phones, feature phones, smartphones, and phone-enabled tablets. (Although smartphones have build in AT or AT-like features they are mostly (but not completely) closed to other AT. Mobile apps can depend on the built-in AT if they are open to it, but are mostly not open to any AT not built into the smartphones.)
Shadi Abou-Zahra The examples are sufficiently covered, as is.
Phil Day The examples are sufficiently covered, with edits. Minor editorial as automated banking machines is predominately used in Canada.
I'd prefer it if we also referred to ATMs. The previous version had this which I thought was better:
"automated banking machine (a.k.a. Automated Teller Machine, or ATM)", although a.k.a. should be spelt out if we haven't previously defined the abbreviation.

Olivia Hogan-Stark Would like more major changes to the examples. +1 to Phil's note on using "automated teller machines." I would replace "banking" with "teller."

Otherwise, examples are sufficiently covered.
Loïc Martínez Normand The examples are sufficiently covered, as is. First, I agree with Gregg's comment on smartphone, but I would not include the text on mobile apps (To my knowledge they are "open" because they can use the accessibility API of the mobile platforms to enable AT access). I also suggest to delete the brackets.

With this changes, the bullet point on phones would be:

"telephony devices such as IP phones, feature phones, smartphones, and phone-enabled tablets. Although smartphones have build in AT or AT-like features they are mostly (but not completely) closed to other AT"

I also agree with Phil's proposal for the self-service terminals, to mention ATM.
Mike Pluke The examples are sufficiently covered, with edits. +1 to Loïc's comments
Sam Ogami The examples are sufficiently covered, with edits. +1 to Phil's comment.
Bruce Bailey The examples are sufficiently covered, as is. I am fine with edits proposed in survey.
Mary Jo Mueller The examples are sufficiently covered, with edits. I believe that Loïc summed up everyone's comments nicely with changes to Gregg's suggestion. I agree with everything in Loïc's summary.

3. Proposed examples changes for "closed functionality" definition

Review the proposed update to the examples in the closed functionality definition. This was done to address differences in the list in the Comments on Closed Functionality section. Indicate whether the level of consistency is sufficient and the changes can be merged into the editor's draft. If you wish to see the specific changes that were made, look at Pull Request 254.

Summary

ChoiceAll responders
Results
The examples can be incorporated, as is. 3
The examples can be incorporated, with edits. 6
Would like more major changes to the examples.

Details

Responder Proposed examples changes for "closed functionality" definitionComments
Gregg Vanderheiden The examples can be incorporated, with edits. These examples are expained more full in the "Comments on Closed Functionality"(current title) section. We should put a pointer from the definition to this section at the END of the examples as follow

(See more on these examples in '"Comments on Closed Functionality"' section).
Shadi Abou-Zahra The examples can be incorporated, as is.
Phil Day The examples can be incorporated, with edits. as above - expand automated banking machines
"automated banking machine (a.k.a. Automated Teller Machine, or ATM)", although a.k.a. should be spelt out if we haven't previously defined the abbreviation.
Olivia Hogan-Stark The examples can be incorporated, with edits.
Loïc Martínez Normand The examples can be incorporated, with edits. I suggest to have the exact same text for the examples in both parts (the definition and the section).
Mike Pluke The examples can be incorporated, with edits. +1 to Loïc's proposal
Sam Ogami The examples can be incorporated, as is.
Bruce Bailey The examples can be incorporated, as is. I am fine with edits proposed in survey.
Mary Jo Mueller The examples can be incorporated, with edits. I like Gregg's approach pointing to the Comments on Closed Functionality for more details. Was trying not to verbatim repeat all of the example text. Also agree with Phil's ATM edit.

4. Review the rest of the text (not the Examples callout)

Read the rest of the text in the Closed Functionality section. Indicate whether the comments you submitted in the last survey on this section are addressed and the rest of the text updates are ready to merge into the editor's draft. If you wish to see the specific changes that were made, look at Pull Request 254.

Summary

ChoiceAll responders
Results
The rest of the text content can be incorporated, as is. 3
The rest of the text content can be incorporated, with edits. 6
Would like more major changes to the text content.

Details

Responder Review the rest of the text (not the Examples callout)Comments
Gregg Vanderheiden The rest of the text content can be incorporated, with edits. This statement is incorrect -- and also puts the label "closed" on the whole product and not specific functionality where it belongs
" ICT products with closed functionality do not allow the use of some assistive technologies for all of their functions."

Suggest the following substitutions/edits

NOW: "ICT products with closed functionality do not allow the use of some assistive technologies for all of their functions."
EDITED: "ICT products with closed functionality do not allow the use of some assistive technologies for ***some or ***all of their functions.


NOW: "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 products.

EDITED: "This document does not comment on those standards, but does note that WCAG success criteria ***called out in Appendix A *** should not be relied upon to provide accessibility for closed functionality aspects of products.***

**(I dropped the hardware part of the previous text because there is nothing about hardware accessibility in WCAG2ICT - and if we open up hardware here - we need to talk about application of all the other SC to hardware - even in non-closed product functionality.)**


NOW: "Instead, this Note indicates considerations for applying WCAG criteria to closed functionality software and when that might be problematic due to the underlying assumptions built into the WCAG criteria."

EDITED: "Instead, ***WCAG2ICT provides*** considerations for applying WCAG ***success*' criteria to closed functionality software. **It also indicates where and why*** that might be problematic due to the underlying assumptions built into the WCAG criteria.
** I changed NOTE to WCAG2ICT since otherwise it appears to mean the text itself rather than the document. I also added "success" to criteria. Finally the words. ***and when that*** makes it very hard to figure out what the sentence is saying -- so I broke it off to make it clearer
Shadi Abou-Zahra The rest of the text content can be incorporated, with edits. https://github.com/w3c/wcag2ict/pull/256 -- I made light edits, mostly to remove occurrences of the terms "products" and "software" that might be ambiguous in the context of the EAA.
Phil Day The rest of the text content can be incorporated, as is.
Olivia Hogan-Stark The rest of the text content can be incorporated, as is.
Loïc Martínez Normand The rest of the text content can be incorporated, with edits. +1 to Gregg's and Shadi's edits.
Mike Pluke The rest of the text content can be incorporated, with edits. +1 to Gregg and Shadi's proposals
Sam Ogami The rest of the text content can be incorporated, with edits. Remove "To support users with disabilities, products with closed functionality can instead provide built-in features that function as assistive technology."
In the key terms section Closed functionality is being defined with examples to help the reader understand what Closed Functionality is. The sentence above does not provide any additional clarity and is a recommendation.
Bruce Bailey The rest of the text content can be incorporated, as is. I am okay with PR as-is, but I am comfortable with edits proposed in survey.
Mary Jo Mueller The rest of the text content can be incorporated, with edits. I agree with Shadi's proposed changes for the most part. Except for the last "software" changing to "ICT" which, to me, seems an incorrect change. The use of "software" there was intentional since we are not providing guidance on applying to hardware and warn against that, then this sentence is referring to Appendix A which is entirely about applying WCAG to non-web software in situations of closed functionality.

Agree with first and third edits suggested by Gregg.

Gregg's 2nd comment is on text I added due to comments from Sam on the last survey saying we should specifically say it is not appropriate to apply WCAG to hardware aspects of ICT. This isn't opening anything up, but reiterating that we are not guiding on, nor are we recommending using WCAG for hardware. Laura brought this up in a meeting a few weeks ago where people were trying to do this. Was hoping to make it clear here.

Sam brought up a comment on the note in the definition of Closed Functionality. This note had no changes in it due to the update, and is the consensed text the TF previously agreed upon. Would changing the note to say:

To support users with disabilities, products with closed functionality "might" provide built-in features that function as assistive technology "or use other mechanisms to make the technology accessible."

More details on responses

  • Gregg Vanderheiden: last responded on 6, November 2023 at 04:49 (UTC)
  • Shadi Abou-Zahra: last responded on 6, November 2023 at 10:58 (UTC)
  • Phil Day: last responded on 6, November 2023 at 15:06 (UTC)
  • Olivia Hogan-Stark: last responded on 6, November 2023 at 15:25 (UTC)
  • Loïc Martínez Normand: last responded on 8, November 2023 at 17:22 (UTC)
  • Mike Pluke: last responded on 8, November 2023 at 19:16 (UTC)
  • Sam Ogami: last responded on 8, November 2023 at 21:28 (UTC)
  • Bruce Bailey: last responded on 8, November 2023 at 22:38 (UTC)
  • Mary Jo Mueller: last responded on 8, November 2023 at 22:56 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Chris Loiselle
  2. Mitchell Evan
  3. Charles Adams
  4. Daniel Montalvo
  5. Fernanda Bonnin
  6. Shawn Thompson
  7. Laura Miller
  8. Anastasia Lanz
  9. Devanshu Chandra
  10. Bryan Trogdon
  11. Thorsten Katzmann
  12. Tony Holland
  13. Kent Boucher

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