W3C

Site Navigation

Nearby

Results of Questionnaire WCAG2ICT: Review of proposed responses to public comments - group 1

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 2024-01-23 to 2024-02-07.

9 answers have been received.

Jump to results for question:

  1. Public Comment: Issue 230 - 2.6 Software
  2. Public Comment: Issue 227 - CSS pixels: How to measure CSS pixel equivalents for systems with closed functionality
  3. Public Comment: Issue 225 - More affirmative examples
  4. Public Comment: Issue 216 - Inconsistency between 1.4.12 Text Spacing and 4.1.3 Status Messages
  5. Public Comment: Issue 308 - Native application equivalent in set of documents vs set of software programs

1. Public Comment: Issue 230 - 2.6 Software

Read and understand the public comment in Issue 5: 2.6 Software

Review the draft answer for issue 230.

Indicate whether the proposed answer is sufficient and note any potential edits or alternate proposals.

Summary

ChoiceAll responders
Results
Draft answer is sufficient, as-is. 8
Draft answer is sufficient, with the following edits. 1
The answer is not ready. To expedite the process, please provide your alternate proposal.

Details

Responder Public Comment: Issue 230 - 2.6 SoftwareComments
Thorsten Katzmann Draft answer is sufficient, as-is.
Sam Ogami Draft answer is sufficient, as-is.
Mary Jo Mueller Draft answer is sufficient, as-is. IMO, it isn't really necessary to reiterate that the document won't be changed. Instead it could be called out at the bottom with a bolded word "CONCLUSION:" to make it more obvious. This is a long answer and I don't think it's necessary to make it longer by repeating a paraphrased conclusion at the top.

However, I did draft something just in case it is needed: The WCAG2ICT Task Force discussed the potential for adding examples to the definition of “software”, but we will not be making modifications, as there aren’t truly bright lines for classification of non-web software. There may be situations where classification would require a judgement call to be made.
Gregg Vanderheiden Draft answer is sufficient, as-is.
Phil Day Draft answer is sufficient, as-is.
Fernanda Bonnin Draft answer is sufficient, as-is.
Bruce Bailey Draft answer is sufficient, as-is. I almost missed the lede: The WCAG2ICT document will not be modified to address the above points.

Bolding CONCLUSION addressed my concern.
Mike Pluke Draft answer is sufficient, as-is.
Mitchell Evan Draft answer is sufficient, with the following edits. (my response the first time) Good as is, or better with Bruce's suggestion: "Can a version of that paragraph be moved to the top of the answer?"

(my response after survey re-opened) I'm happy with it as is. Adding "Conclusion:" is even better.

2. Public Comment: Issue 227 - CSS pixels: How to measure CSS pixel equivalents for systems with closed functionality

Read and understand the public comment in Issue 227 - CSS pixels: How to measure CSS pixel equivalents for systems with closed functionality.

Review the draft answer for issue 226 which proposes an edit to Note 4 in the WCAG2ICT definition of the key term "document".

Indicate whether the proposed content change and issue answer are sufficient and note any potential edits or alternate proposals.

Summary

ChoiceAll responders
Results
Draft change and issue answer is sufficient, as-is. 4
Draft change and issue answer is sufficient, with the following edits. 2
This is not ready. To expedite the process, please provide your alternate proposal. 3

Details

Responder Public Comment: Issue 227 - CSS pixels: How to measure CSS pixel equivalents for systems with closed functionalityComments
Thorsten Katzmann Draft change and issue answer is sufficient, as-is.
Sam Ogami Draft change and issue answer is sufficient, with the following edits. To reflect that there are cases where screen platform-defined density-independent pixel or display distance is unknown. Remove sentence: Still other closed functionality software runs on a range of physical screens, such as smart TVs, where the software scales to fit the screen in such a way that it yields a predictable "CSS pixel" unit on any commonly-used physical screen. CHANGE Other closed functionality software runs on a specific hardware device, such as a self-service terminal or kiosk, where the physical screen size is known.
TO Other closed functionality software runs on a specific hardware device, such as a self-service terminal or kiosk, where the physical screen might be known.
Mary Jo Mueller Draft change and issue answer is sufficient, as-is. NOTE: I checked with Mitch who drafted this answer to see if Sam's comments would be OK to incorporate. He agreed, so I incorporated both Sam's sentence deletion and replacement as well as Mitch's note to indicate the document isn't changing. Other than those changes, the draft answer remains the same.

So with the changes to the draft answer I've incorporated, I think this answer is sufficient. Would like for other TF members to indicate the same, if the updated version is good to go.
Gregg Vanderheiden This is not ready. To expedite the process, please provide your alternate proposal. Don't have a suggested fix since I can't understand the follow sentence.

If you use the method of viewing distance for a display type: Project either the physical pixel size or the equivalent viewing angle onto a display of that type.

how do I project a pixel size. What kind of projector? Where do I get the pixel size. I'm sure this makes sense technically but not as written. Can we use plainer language? What does it mean "a display of that type".

does this mean. "Just use math and trigonometry to determine the physical size of a pixel by determining the size of an X Degree arc at the normal viewing distance?" Is there a chart somewhere where we can say something like "refer to the viewing angle vs distance chart at XXX and find the size that corresponds to X degree viewing Angle at the viewing distance that will, on average, be used with the display " ?

or something else?
Phil Day Draft change and issue answer is sufficient, as-is.
Fernanda Bonnin This is not ready. To expedite the process, please provide your alternate proposal. I am not clear how the draft answer is proposing an edit to Note 4 for the key term "document" as per the description on this question.
On Part 2, I think we should acknowledge that there might not be software tools available to measure.
Bruce Bailey Draft change and issue answer is sufficient, as-is.
Mike Pluke This is not ready. To expedite the process, please provide your alternate proposal. Like Gregg, I don't understand what the sentence "Project either the physical pixel size or the equivalent viewing angle onto a display of that type" is supposed to mean.
Mitchell Evan Draft change and issue answer is sufficient, with the following edits. Add that we won't be editing WCAG2ICT for this question.

3. Public Comment: Issue 225 - More affirmative examples

Read and understand the public comment in Issue 225 - More affirmative examples and the draft answer for issue 225 which proposes to make no change to the WCAG2ICT document.

Indicate whether the proposed answer is sufficient and note any potential edits or alternate proposals.

Summary

ChoiceAll responders
Results
Draft issue answer is sufficient, as-is. 4
Draft issue answer is sufficient, with the following edits. 3
This is not ready. To expedite the process, please provide your alternate proposal. 1

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

Details

Responder Public Comment: Issue 225 - More affirmative examplesComments
Thorsten Katzmann
Sam Ogami Draft issue answer is sufficient, as-is.
Mary Jo Mueller Draft issue answer is sufficient, as-is.
Gregg Vanderheiden This is not ready. To expedite the process, please provide your alternate proposal. this answer looks like it is only responding to her last question -- about sets of software.

but she also asks for examples for other things before that including

1.3.5 Input Purpose (For example, there’s an equivalent for Android and iOS native mobile. Are there similar examples for desktop software?)
1.4.12 Text Spacing
1.4.10 Reflow

we need to include some text in the response about that
Phil Day Draft issue answer is sufficient, as-is.
Fernanda Bonnin Draft issue answer is sufficient, with the following edits. suggestion: instead of tedious, use comprehensive or long.
for examples being documented in a wiki or another easily updated resource who would be the body reviewing that the examples are accurate?
Bruce Bailey Draft issue answer is sufficient, as-is.
Mike Pluke Draft issue answer is sufficient, with the following edits. I think that this will be fine with Mitch's suggested additions.
Mitchell Evan Draft issue answer is sufficient, with the following edits. (my response the first time) FYI, I edited the comment directly in GitHub, fixing a typo "decided that not to add" to "decided not to add". With this edit, it's sufficient as-is.

(my response after survey re-opened) Gregg is right, we didn't answer all of the commenter's questions. Here's a draft addition.

The Task Force is declining to add more examples to the following, for these reasons:
1.3.5 Input Purpose: iOS or Android is a likely example where it will be relevant, but this Task Force is not in a position to decide whether there is currently sufficient accessibility support.
1.4.12 Text Spacing: Examples are sufficiently addressed in Note 1: "Examples of markup languages that are used internally...."
1.4.10 Reflow: This criterion links to the definition of "CSS pixel," which includes examples of platforms that use a density-independent pixel.

4. Public Comment: Issue 216 - Inconsistency between 1.4.12 Text Spacing and 4.1.3 Status Messages

Read and understand the public comment in Issue 216 - Inconsistency between 1.4.12 Text Spacing and 4.1.3 Status Messages . In the text of the issue, two proposed options are provided to make these two SC more consistent. Once chosen (and edited, if needed) the proposed answer would be:

Thanks for your comment. The task force has considered the two proposals and has chosen to incorporate the following text into the editor's draft:


@@ insert text from approved option here @@

Indicate in your answer the preferred option and indicate if the proposed answer is sufficient. Note any potential edits or alternate proposals.

Summary

ChoiceAll responders
Results
Prefer Option 1, as is. Draft issue answer is sufficient, as-is. 1
Prefer Option 1, with edits. Draft issue answer is sufficient, as-is.
Prefer Option 1, with edits. Draft issue answer also needs edits.
Prefer Option 2, as is. Draft issue answer is sufficient, as-is. 5
Prefer Option 2, with edits. Draft issue answer is sufficient, as-is.
Prefer Option 2, with edits. Draft issue answer also needs edits. 1
This is not ready. To expedite the process, please provide your alternate proposal. 1

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

Details

Responder Public Comment: Issue 216 - Inconsistency between 1.4.12 Text Spacing and 4.1.3 Status MessagesComments
Thorsten Katzmann
Sam Ogami Prefer Option 2, as is. Draft issue answer is sufficient, as-is.
Mary Jo Mueller Prefer Option 2, as is. Draft issue answer is sufficient, as-is.
Gregg Vanderheiden Prefer Option 2, with edits. Draft issue answer also needs edits. Option 1 is not a sentence -- broken somehow

Option 2 is good - but needs a common before "content" (actually, both need the comma)
Phil Day Prefer Option 1, as is. Draft issue answer is sufficient, as-is. Also happy with option 2 if the majority prefer it - I think either work, but prefer the form of 1
Fernanda Bonnin Prefer Option 2, as is. Draft issue answer is sufficient, as-is.
Bruce Bailey Prefer Option 2, as is. Draft issue answer is sufficient, as-is.
Mike Pluke Prefer Option 2, as is. Draft issue answer is sufficient, as-is.
Mitchell Evan This is not ready. To expedite the process, please provide your alternate proposal. (my response the first time) I'm undecided, and can be convinced. I recall in our discussion of 1.4.12 that at the time we didn't want to expand it past markup, so we should give folks a chance to speak up for that original position of our task force. That said, I like a change that's more inclusive for users, in which case I would choose Option 1 as-is.

(my response after survey re-opened) I've changed my response.

I propose this alternate response:
The WCAG2ICT Task Force declines to say that 1.4.12 can be applied as the commenter proposed. We are saying that 4.1.3 Status Messages can apply to notifications, because the concept of support for programmatic notifications is clear enough from cross-platform precedents. In contrast, the Task Force has not seen precedents for setting text style properties in software in general, that would allow us to say that the concept is the same.
(end of proposed alternate response)

That said, I could accept Option 2 or Option *if* the following occur.
- Rephrase Option 2 or Option 1 to restore WCAG's condition, that the "markup" part apply only to "markup languages that support the following text style properties" (not all markup languages).
- Remove or rewrite Note 1. Both Option 2 and Option 1 propose no longer limiting 1.4.12 to markup languages, so it's confusing to list examples of software implemented in markup languages in this new context.
- Decide how to respond to the 1.4.12 aspect of Issue 225.

5. Public Comment: Issue 308 - Native application equivalent in set of documents vs set of software programs

Read and understand the public comment in Issue 308 - Native application equivalent in set of documents vs set of software programs and the draft answer for issue 308. There is no change needed in the WCAG2ICT document due to this comment.

Indicate whether the proposed answer is sufficient and note any potential edits or alternate proposals.

Summary

ChoiceAll responders
Results
Draft issue answer is sufficient, as-is. 5
Draft issue answer is sufficient, with the following edits. 3
This is not ready. To expedite the process, please provide your alternate proposal.

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

Details

Responder Public Comment: Issue 308 - Native application equivalent in set of documents vs set of software programsComments
Thorsten Katzmann
Sam Ogami Draft issue answer is sufficient, as-is.
Mary Jo Mueller Draft issue answer is sufficient, as-is. I have removed the sentence Mitch asked to be removed. If others have no further comments, I think this is ready to finalize.
Gregg Vanderheiden Draft issue answer is sufficient, with the following edits. looks good. (Lot of work)

only bit I had a question on was "nor the U.S. Revised 508 standards apply any of the Success Criteria that are scoped to "sets of software programs" to non-web software - including mobile apps."

that is true for EN 301 549 where they break all the SC out -- but I thought in 508 they simply say 'substitute xxxx for web page and apply WCAG'. I did not know that they split out any specific SC and said they did not apply. If so - I am behind the times and need to bone up. If not then we need to change this bit of our answer. easiest is just to drop the "we don't know of any..." part - to the end of paragraph. But only if I am not behind the times.
Phil Day Draft issue answer is sufficient, with the following edits. Content of comment was good. I just had a couple of minor editorials - see my comment https://github.com/w3c/wcag2ict/issues/308#issuecomment-1929191313 for full formatting as the formatting has been stripped from this answer.


Bypass Blocks is one where (if applied) non-web software would likely automatically satisfy the requirement. Web content has the problem that one cannot quickly navigate to the main part of the content - you have to Tab tab past every menu and navigation link whenever there is a left or top navigation on a website. For a native desktop application, one simply uses a keystroke to toggle between the menu and the main part of the application. For mobile applications, a user simply taps where they want to start interacting. If navigating sequentially using a screen reader, mobile applications also have much smaller top level menus, meaning the burden of getting past them to get to the main part of the application is minimal - especially when they employ the use of the hamburger menu.
Fernanda Bonnin Draft issue answer is sufficient, as-is.
Bruce Bailey Draft issue answer is sufficient, as-is. I am also content with edit proposed.
Mike Pluke Draft issue answer is sufficient, as-is.
Mitchell Evan Draft issue answer is sufficient, with the following edits. (my response the first time) Delete this sentence: "The navigation problem that exists in the Web does not exist in native software." The problem does sometimes exist, for example when a hybrid app includes whole web pages. With this sentence removed the rest is good.

(my response after survey re-opened) Patrick and Jonathan have replied with concerns which I share, pointing out that this paragraph is not entirely accurate:

"Bypass Blocks is one where (if applied) non-web software would likely automatically satisfy the requirement...."

So I propose deleting that whole paragraph from our response. It's not necessary.

This paragraph alone is enough justification: "Note: It wasn't and still isn't within the allowable scope of the WCAG2ICT Task Force..."

I can accept the "Task force is unaware..." paragraph as-is, but I want to point out that its logic is a bit circular. WCAG2ICT (2013) was the first to say how of the "set of web pages" criteria could apply to non-web software. Revised Section 508 (2017) and EN 301 549 followed WCAG2ICT's lead and took it half a step further, explicitly saying that they would not apply those criteria to non-web software full stop. So citing those standards as a precedent is not much stronger than just using WCAG2ICT 2013 as a precedent.

More details on responses

  • Thorsten Katzmann: last responded on 30, January 2024 at 12:48 (UTC)
  • Sam Ogami: last responded on 31, January 2024 at 22:06 (UTC)
  • Mary Jo Mueller: last responded on 5, February 2024 at 14:49 (UTC)
  • Gregg Vanderheiden: last responded on 5, February 2024 at 22:07 (UTC)
  • Phil Day: last responded on 6, February 2024 at 10:17 (UTC)
  • Fernanda Bonnin: last responded on 7, February 2024 at 19:33 (UTC)
  • Bruce Bailey: last responded on 7, February 2024 at 21:44 (UTC)
  • Mike Pluke: last responded on 7, February 2024 at 23:55 (UTC)
  • Mitchell Evan: last responded on 8, February 2024 at 00:45 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Shadi Abou-Zahra
  2. Loïc Martínez Normand
  3. Chris Loiselle
  4. Charles Adams
  5. Daniel Montalvo
  6. Shawn Thompson
  7. Olivia Hogan-Stark
  8. Laura Miller
  9. Anastasia Lanz
  10. Devanshu Chandra
  11. Bryan Trogdon
  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

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.