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. Peter Heery
  31. John Kirkwood
  32. Detlev Fischer
  33. Reinaldo Ferraz
  34. Matt Garrish
  35. Mike Gifford
  36. Loïc Martínez Normand
  37. Mike Pluke
  38. Justine Pascalides
  39. Chris Loiselle
  40. Tzviya Siegman
  41. Jan McSorley
  42. Sailesh Panchang
  43. Cristina Mussinelli
  44. Jonathan Avila
  45. John Rochford
  46. Sarah Horton
  47. Sujasree Kurapati
  48. Jatin Vaishnav
  49. Sam Ogami
  50. Kevin White
  51. E.A. Draffan
  52. Paul Bohman
  53. JaEun Jemma Ku
  54. 骅 杨
  55. Victoria Clark
  56. Avneesh Singh
  57. Mitchell Evan
  58. Michael Gower
  59. biao liu
  60. Scott McCormack
  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. Christina Adams
  98. Jared Batterman
  99. Raja Kushalnagar
  100. Jan Williams
  101. Todd Libby
  102. Isabel Holdsworth
  103. Julia Chen
  104. Marcos Franco Murillo
  105. Yutaka Suzuki
  106. Azlan Cuttilan
  107. Jennifer Strickland
  108. Joe Humbert
  109. Ben Tillyer
  110. Charu Pandhi
  111. Poornima Badhan Subramanian
  112. Alain Vagner
  113. Roberto Scano
  114. Rain Breaw Michaels
  115. Kun Zhang
  116. Jaunita George
  117. Regina Sanchez
  118. Shawn Thompson
  119. Thomas Brunet
  120. Kenny Dunsin
  121. Jen Goulden
  122. Mike Beganyi
  123. Ronny Hendriks
  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. Rachele DiTullio
  135. Jan Jaap de Groot
  136. Rebecca Monteleone
  137. Ian Kersey
  138. Peter Bossley
  139. Michael Keane
  140. Chiara De Martin
  141. Giacomo Petri
  142. Andrew Barakat
  143. Devanshu Chandra
  144. Xiao (Helen) Zhou
  145. Joe Lamyman
  146. Bryan Trogdon
  147. Mary Ann (MJ) Jawili
  148. 禹佳 陶
  149. 锦澄 王
  150. Stephen James
  151. Jay Mullen
  152. Thorsten Katzmann
  153. Tony Holland
  154. Kent Boucher
  155. Abbey Davis
  156. Phil Day
  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. Fred Edora
  177. Lori Oakley
  178. David Middleton
  179. Alyssa Priddy
  180. Young Choi
  181. Nichole Bui
  182. Julie Romanowski
  183. Eloisa Guerrero
  184. George Kuan
  185. YAPING LIN
  186. Justin Wilson
  187. Leonard Beasley
  188. Tiffany Burtin
  189. Shane Dittmar
  190. Nayan Padrai
  191. Niamh Kelly
  192. Matt Argomaniz Matthew Argomaniz
  193. Frankie Wolf
  194. Kimberly McGee
  195. Ahson Rana
  196. Carolina Crespo
  197. humor927 humor927
  198. Jackie Fei
  199. Samantha McDaniel
  200. Matthäus Rojek
  201. Phong Tony Le
  202. Bram Janssens
  203. Graham Ritchie
  204. Aleksandar Cindrikj
  205. Jeroen Hulscher
  206. Alina Vayntrub
  207. Marco Sabidussi
  208. John Toles
  209. Jeanne Erickson Cooley
  210. Theo Hale
  211. Gert-Jan Vercauteren
  212. Karla Rubiano
  213. Aashutosh K
  214. Hidde de Vries
  215. Julian Kittelson-Aldred
  216. Roland Buss
  217. Aditya Surendranath
  218. Avon Kuo
  219. Elizabeth Patrick
  220. Tj Squires
  221. Nat Tarnoff
  222. Illai Zeevi
  223. Filippo Zorzi
  224. Gleidson Ramos
  225. Mike Pedersen
  226. Rachael Yomtoob
  227. Oliver Habersetzer
  228. Irfan Mukhtar
  229. Sage Keriazes
  230. Tananda Darling
  231. Nina Krauß
  232. Demelza Feltham
  233. Ragvesh Sharma
  234. Shunguo Yan
  235. Nora GOUGANE

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.