W3C

Site Navigation

Nearby

Results of Questionnaire Miscellaneous Survey for May 12th 2015

The results of this questionnaire are available to anybody.

This questionnaire was open from 2015-05-10 to 2015-05-19.

9 answers have been received.

Jump to results for question:

  1. Issue 86: UA support for this technique seems to be non-existent
  2. Issue 69: Restating flash and red flash thresholds for clarity
  3. Issue 89: Scope of "Third Party Content"
  4. WCAG Call for Consensus Proposal

1. Issue 86: UA support for this technique seems to be non-existent

Please review the following GitHub issue response: Issue 86.

The link above references the specific comment containing the proposal, but feel free to review the discussion within the issue page.

Details

Responder
Makoto Ueki I've been thinking that H69 is a sufficient technique for SC 2.4.1, but it is not required to meet SC 2.4.1. Understanding says "The intent of this Success Criterion is to allow people who navigate sequentially through content more direct access to the primary content of the Web page." So it would be sufficient if a heading (<h1> in many cases) indicates start of main content. "Providing heading elements at the beginning of EACH section of content" is not required for SC 2.4.1.

This should be the other issue, but I'd like to point it out.
Joshue O'Connor + 1 to keeping h69: Response is generally fine (but IMO, AWKs is better) - we can discuss - some suggested small changes to Davids here:

"H69 has been a sufficient technique for 2.4.1 for 6 years and has no tangible negative impact on sighted keyboard users, nor has there been any buzz on the blogs, or complaints from end users that we are aware of.

Regarding better user agent support - this could be easily remedied by browser manufacturers in time - for example via a simple revision to the current Landmarks plugin. Therefore, given the long standing precedence, the lack of opposition to the status quo from end users, and the potential impact on existing WCAG conforming sites, we will leave H69 as a sufficient technique for 2.4.1. We will continue to periodically monitor new technologies and comments regarding this issue."
Michael Cooper Seems ok. Looking for a radio button to vote so.
Kathleen Wahlbin +1 to keeping
Frederick Boland +1 to keeping
Laura Carlson + 1 to keeping h69. Perhaps in the response mention the concrete positive impact for screen reader users. From the WebAIM survey, "Reliance on headings as the predominant mechanism for finding page information continues to increase."
http://webaim.org/projects/screenreadersurvey5/
Marc Johlic Reviewed and commented on in GitHub (+1 for keeping H69)
Maureen Kraft Entered comments in GitHub thread.
Daniel Frank

2. Issue 69: Restating flash and red flash thresholds for clarity

Please review the following GitHub issue response: Issue 69.

The link above references the specific comment containing the proposal, but feel free to review the discussion within the issue page.

Details

Responder
Makoto Ueki This is a question I asked on behalf of WAIC (Web A11y Committee in Japan). Thanks so much for clarification. I'll share this with the committee.
Joshue O'Connor +1
Michael Cooper The original wording is clearly in Gregg-ese. We need to be sure Gregg reviews the proposal, as he often has very specific reasons for his wording choices. To me the proposal seems ok, but not comfortable accepting the change without the GV review.

We could put this in the errata for now, if accepted.
Kathleen Wahlbin +1
Frederick Boland +1
Laura Carlson +1
Marc Johlic Reviewed and commented on in GitHub (+1 to proposed resolution)
Maureen Kraft
Daniel Frank

3. Issue 89: Scope of "Third Party Content"

Please review the following GitHub issue (Issue 89) and the Proposed Response.

Details

Responder
Makoto Ueki How can we judge if "the page author has done everything possible to conform to WCAG"?

Andrew says that the question seems to be "what level of pragmatism is appropriate for allowing authors to claim partial conformance?"[1]

And I responded to it with my suggestion [2]. For example, AddThis [3] uses CSS background images for the icons of sharing buttons so that users of Windows high-contrast mode can't see them. However, this is a very popular marketing tool. Actually some of my clients are using this tool. Even if confomance claim can't be made due to it, it would be desirable for them if they could make the partial conformance claim to show how accessible their websites are except for the tool.

What do you think???

[1] https://github.com/w3c/wcag/issues/89#issuecomment-97454070
[2] https://github.com/w3c/wcag/issues/89#issuecomment-98319937
[3] https://www.addthis.com/get/sharing
Joshue O'Connor Too long. I suggest trimming it;

<josh edit>

"WCAG defines a statement of partial conformance when the page does not conform to WCAG only for reasons that are legitimately outside the author's control. It is important to recognize that this is a statement of non-conformance and there are users who will not be able to access this page.

One reason that content may be outside the author's control is because it is being provided by a third party (blogs, portals, news sites). Web pages may also include content via third party libraries, plugins, or widgets.

In practice, it may be possible to claim conformance for web pages that contain third party content. A platform or tool may provide guidance for how to address conformance problems when including it in another web page. Filtering third third party content so that only conforming content is allowed could help raise the bar.

If it is not possible to monitor and repair the third party content, it may be possible to identify the non-conforming parts of the page to users. If the rest of the web page conforms to WCAG, such a page qualifies for a statement of partial conformance, third party content.

Finally, when an author has made a decision to use that third party implementation, they should choose products that meets accessibility requirements. However, if the content can change without approval from the web page author, then a web page which once conformed may suddenly fail to conform, and the conformance of that web page is outside of the author's control.

</josh edit>
Michael Cooper s/it is not relieve/it does not relieve/

I also wonder if we should change "will not be able to access this page" to "will not be able to access some content on this page".

That leads into a need to discuss the non-interference conformance provision. I would think that a statement of partial conformance cannot be applied if there is a risk that the included content radically breaks accessibility of the entire page, e.g., via flashing content, keyboard trapping, etc. However, I don't see that the wording in WCAG specifically makes that a requirement - it's a *conformance* requirement, not a *partial* conformance requirement. Still, maybe the Understanding should at least point out that you should try extra hard to make sure included content doesn't violate the non-interference provision because it's extra bad.

The last paragraph I found hard to parse for some reason. I think one think I'm looking for is for it to say "you still have to have made all the non-third party content conform before a statement of partial conformance statement become legit". The first para essentially says that but the context of the last para makes me think it bears repeating.
Kathleen Wahlbin
Frederick Boland
Laura Carlson Josh's idea of shortening would make it a lot simpler to understand.

In addition when authors say, "that's a 3rd party tool or content and we can't control its accessibility" they should in no uncertain terms be made aware that they chose that 3rd party tool or content in the first place. I would suggest rearranging Josh's edit a bit to make that point clear right from the start. (I have witnessed many authors wanting to include uncaptioned 3rd party YouTube videos in web pages and are looking for a WCAG escape clause which condones that practice, instead of contacting the author and trying to get the video captioned.)

<laura's edit of josh's edit>

When an author makes a decision to use a third party implementation, they should choose products that meet accessibility requirements.

However, WCAG defines a statement of partial conformance when the page does not conform to WCAG only for reasons that are legitimately outside the author's control. It is important to recognize that this is a statement of non-conformance and there are users who will not be able to access this page.

One reason that content may be outside the author's control is because it is being provided by a third party (blogs, portals, news sites). Web pages may also include content via third party libraries, plugins, or widgets.

In practice, it may be possible to claim conformance for web pages that contain third party content. A platform or tool may provide guidance for how to address conformance problems when including it in another web page. Filtering third third party content so that only conforming content is allowed could help raise the bar.

Be sure to monitor any content that can change without approval from the web page author, as a page which once conformed may suddenly fail to conform. If it is not possible to monitor and repair the third party content, it may be possible to identify the non-conforming parts of the page to users. If the rest of the web page conforms to WCAG, such a page qualifies for a statement of partial conformance, third party content.

</laura's edit of josh's edit>

Of note: Sec. 51(a) of Settlement Agreement between the United States of America and Madison County, New York under the Americans with Disabilities Act covers third parties:
"Ensure that its websites and all online services, including those websites or online services provided by third parties upon which the County relies to provide services or content, comply with, at minimum, WCAG 2.0 AA"
http://www.ada.gov/madison_co_ny_pca/madison_co_ny_sa.html
Marc Johlic I like Josh's edit
Maureen Kraft
Daniel Frank

4. WCAG Call for Consensus Proposal

The WCAG group has discussed and conceptually approved an update to the consensus process for working group decisions. Below is a proposed draft of a Consensus Procedure document for review.

WCAG WG Consensus Procedures

This document explains the decision process of the WCAG Working Group.

The Working Group strives to reach unanimous agreement whenever possible. However, at times this is not possible, and for the sake of continuing to work on important topics the group must arrive at a consensus decision and move forward. In the course of establishing consensus it is critical that all working group members have the opportunity to express their views for consideration so that all relevant information can be used in arriving at the conclusion.

1. Discussion on a topic proceeds until the chairs believe that all points of view have been expressed and the group has considered the variety of information presented. Depending on the topic, this discussion may take a couple of days or a couple of weeks, or more.
a. Discussion can take place in email on the WCAG mailing list, within the comment thread of a GitHub issue or pull request, or on a Working Group call.
2. When the chairs believe that the group is ready to come to a decision they announce a Call for Consensus either email to the Working Group's mailing list. The Call must remain open for a minimum of two working days.
a. The Call will contain pointers to the relevant discussion. This may include links to GitHub issues or pull requests, WCAG surveys, email threads, or meeting minutes topics.
b. Discussion on a WCAG teleconference may precede a Call for Consensus, but it may not replace the official Call for Consensus.
c. Issues that are regarded as editorial by the Chairs do not require a Working Group decision in order for the Chairs to address, and thus do not require a Call for Consensus.
3. Evaluating the Call for Consensus:
a. If no objections are received by the deadline, the draft decision becomes a formal decision of the Working Group.
b. If objections are received but the chairs believe the objections have already been considered and addressed and there is an overall consensus, the draft decision becomes a formal decision of the Working Group with objections. Objections are recorded as an appendix to the formal decision.
c. If objections are received that the chairs believe present substantive new information, or if the chairs believe there is not a clear consensus in the Task Force they will reopen the discussion.
4. The Working Group chairs record the Formal Decisions on the WCAG Decisions page on the wiki.

During discussion on a topic, participants are welcome to raise objections freely to help ensure that all available information can be considered and contribute to the best possible decision. However, when the chairs issue a Call for Consensus, objections should not be raised unless the individual strongly believes the decision is the wrong one in spite of discussion, and the individual cannot "live with" the decision. Compromise on points that the individual considers suboptimal but can "live with" is an essential part of group decisions that must meet various requirements.

If a participant believes the Chairs have not exercised sound judgment in following this policy, they should express their concern first to one of the Working Group Chairs, escalating if needed to the WCAG staff contact, and escalating if needed to the W3C Accessibility Domain Lead.

Summary

ChoiceAll responders
Results
I agree with the proposal as written 5
I agree with the proposal with the following changes 2
The Working Group needs to discuss this proposal further 1

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

Details

Responder WCAG Call for Consensus Proposal
Makoto Ueki I agree with the proposal as written
Joshue O'Connor I agree with the proposal with the following changes <grammar>

2. When the chairs believe that the group is ready to come to a decision they announce a Call for Consensus either [via] email to the Working Group's mailing list. The Call must remain open for a minimum of two working days.

The Call will contain pointers to the relevant discussion. This may include links to GitHub issues or pull requests, WCAG surveys, email threads, or meeting minutes. <del> topics.</del>

Why is TF mentioned here explicitly? Suggest removing:

"c. If objections are received that the chairs believe present substantive new information, or if the chairs believe there is not a clear consensus <del> in the Task Force</del> they will reopen the discussion.

4. The Working Group chairs record the Formal Decisions on the WCAG Decisions page. <del> on the wiki.</del>


Michael Cooper The Working Group needs to discuss this proposal further Good overall but think there are some gotchas we need to address:

1.a. Discussion can take place... - I'm reluctant to have the consensus policy say where discussion can take place, and by omission where it cannot. I prefer to say "using any recognized communication channel of the WG". That said, I'm worried about channels where if you miss it you've missed it - in particular IRC or some chat where if you didn't happen to be logged in at that time you didn't even know a discussion took place? Teleconferences have that issue too but at least are minuted so people can catch up. Somehow we need to ensure that everyone has a reasonable chance to participate in the discussion - without requiring we hold up the train just in case someone who was dawdling in the washroom wants to catch the caboose.

2.b. instead of saying "Discussion on a WCAG teleconference" I think it should be "a resolution recorded in a WG teleconference". Discussion can happen anywhere as previously noted. It's the teleconference resolution that we want to clearly state is not an official consensus in this policy. Yet I think we also want to underscore the value of such a resolution as a preliminary step.

2.c. "Issues that are regarded as editorial by the Chairs" there needs to be a way for people to protest the chairs' opinion of what's editorial.

...interrupted, hope to get back to this...
Kathleen Wahlbin
Frederick Boland I agree with the proposal as written
Laura Carlson I agree with the proposal as written
Marc Johlic I agree with the proposal as written
Maureen Kraft I agree with the proposal with the following changes I feel 2 days is a bit short especially with different time zones. One may not see the call for consensus until 1 day has passed. Should we say 3 days to allow for 1 day for folks to receive notice?
Daniel Frank I agree with the proposal as written

More details on responses

  • Daniel Frank: last responded on 19, May 2015 at 15:58 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Gregg Vanderheiden
  2. Chris Wilson
  3. Lisa Seeman-Horwitz
  4. Janina Sajka
  5. Shawn Lawton Henry
  6. Katie Haritos-Shea
  7. Shadi Abou-Zahra
  8. Chus Garcia
  9. Steve Faulkner
  10. Patrick Lauke
  11. David MacDonald
  12. Gez Lemon
  13. Peter Korn
  14. Preety Kumar
  15. Bruce Bailey
  16. Georgios Grigoriadis
  17. Stefan Schnabel
  18. Romain Deltour
  19. Chris Blouch
  20. Jedi Lin
  21. Jeanne F Spellman
  22. Wilco Fiers
  23. Kimberly Patch
  24. Glenda Sims
  25. Ian Pouncey
  26. Alastair Campbell
  27. Léonie Watson
  28. David Sloan
  29. Mary Jo Mueller
  30. John Kirkwood
  31. Detlev Fischer
  32. Reinaldo Ferraz
  33. Matt Garrish
  34. Mike Gifford
  35. Loïc Martínez Normand
  36. Mike Pluke
  37. Justine Pascalides
  38. Chris Loiselle
  39. Tzviya Siegman
  40. Jan McSorley
  41. Sailesh Panchang
  42. Cristina Mussinelli
  43. Jonathan Avila
  44. John Rochford
  45. Sarah Horton
  46. Sujasree Kurapati
  47. Jatin Vaishnav
  48. Sam Ogami
  49. Kevin White
  50. E.A. Draffan
  51. Paul Bohman
  52. JaEun Jemma Ku
  53. 骅 杨
  54. Victoria Clark
  55. Avneesh Singh
  56. Mitchell Evan
  57. Michael Gower
  58. biao liu
  59. Scott McCormack
  60. Denis Boudreau
  61. Rachael Bradley Montgomery
  62. Francis Storr
  63. Rick Johnson
  64. David Swallow
  65. Aparna Pasi
  66. Gregorio Pellegrino
  67. Melanie Philipp
  68. Jake Abma
  69. Nicole Windmann
  70. Oliver Keim
  71. Gundula Niemann
  72. Ruoxi Ran
  73. Wendy Reid
  74. Scott O'Hara
  75. Charles Adams
  76. Muhammad Saleem
  77. Amani Ali
  78. Trevor Bostic
  79. Jamie Herrera
  80. Shinya Takami
  81. Karen Herr
  82. Kathy Eng
  83. Cybele Sack
  84. Audrey Maniez
  85. Jennifer Delisi
  86. Arthur Soroken
  87. Daniel Bjorge
  88. Kai Recke
  89. David Fazio
  90. Daniel Montalvo
  91. Mario Chacón-Rivas
  92. Michael Gilbert
  93. Caryn Pagel
  94. Achraf Othman
  95. Helen Burge
  96. Fernanda Bonnin
  97. Jared Batterman
  98. Raja Kushalnagar
  99. Jan Williams
  100. Todd Libby
  101. Isabel Holdsworth
  102. Julia Chen
  103. Marcos Franco Murillo
  104. Yutaka Suzuki
  105. Azlan Cuttilan
  106. Jennifer Strickland
  107. Joe Humbert
  108. Ben Tillyer
  109. Charu Pandhi
  110. Poornima Badhan Subramanian
  111. Alain Vagner
  112. Roberto Scano
  113. Rain Breaw Michaels
  114. Kun Zhang
  115. Jaunita George
  116. Regina Sanchez
  117. Shawn Thompson
  118. Thomas Brunet
  119. Kenny Dunsin
  120. Jen Goulden
  121. Mike Beganyi
  122. Ronny Hendriks
  123. Breixo Pastoriza Barcia
  124. Olivia Hogan-Stark
  125. Rashmi Katakwar
  126. Julie Rawe
  127. Duff Johnson
  128. Laura Miller
  129. Will Creedle
  130. Shikha Nikhil Dwivedi
  131. Marie Csanady
  132. Meenakshi Das
  133. Perrin Anto
  134. Stephanie Louraine
  135. Rachele DiTullio
  136. Jan Jaap de Groot
  137. Rebecca Monteleone
  138. Ian Kersey
  139. Peter Bossley
  140. Anastasia Lanz
  141. Michael Keane
  142. Chiara De Martin
  143. Giacomo Petri
  144. Andrew Barakat
  145. Devanshu Chandra
  146. Xiao (Helen) Zhou
  147. Bryan Trogdon
  148. Mary Ann (MJ) Jawili
  149. 禹佳 陶
  150. 锦澄 王
  151. Stephen James
  152. Jay Mullen
  153. Thorsten Katzmann
  154. Tony Holland
  155. Kent Boucher
  156. Abbey Davis
  157. Julia Kim
  158. Michelle Lana
  159. David Williams
  160. Mikayla Thompson
  161. Catherine Droege
  162. James Edwards
  163. Eric Hind
  164. Quintin Balsdon
  165. Mario Batušić
  166. David Cox
  167. Sazzad Mahamud
  168. Katy Brickley
  169. Kimberly Sarabia
  170. Corey Hinshaw
  171. Ashley Firth
  172. Daniel Harper-Wain
  173. Kiara Stewart
  174. DJ Chase
  175. Suji Sreerama
  176. Lori Oakley
  177. David Middleton
  178. Alyssa Priddy
  179. Young Choi
  180. Nichole Bui
  181. Julie Romanowski
  182. Eloisa Guerrero
  183. Daniel Henderson-Ede
  184. George Kuan
  185. YAPING LIN
  186. Justin Wilson
  187. Tiffany Burtin
  188. Shane Dittmar
  189. Nayan Padrai
  190. Niamh Kelly
  191. Matt Argomaniz Matthew Argomaniz
  192. Frankie Wolf
  193. Kimberly McGee
  194. Ahson Rana
  195. Carolina Crespo
  196. humor927 humor927
  197. Samantha McDaniel
  198. Matthäus Rojek
  199. Phong Tony Le
  200. Bram Janssens
  201. Graham Ritchie
  202. Aleksandar Cindrikj
  203. Jeroen Hulscher
  204. Alina Vayntrub
  205. Marco Sabidussi
  206. John Toles
  207. Jeanne Erickson Cooley
  208. Theo Hale
  209. Gert-Jan Vercauteren
  210. Karla Rubiano
  211. Aashutosh K
  212. Hidde de Vries
  213. Julian Kittelson-Aldred
  214. Roland Buss
  215. Aditya Surendranath
  216. Avon Kuo
  217. Elizabeth Patrick
  218. Nat Tarnoff
  219. Filippo Zorzi
  220. Mike Pedersen
  221. Rachael Yomtoob
  222. Oliver Habersetzer

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.