W3C

Site Navigation

Nearby

Results of Questionnaire Question, Github Issues & proposals

The results of this questionnaire are available to anybody.

This questionnaire was open from 2016-05-13 to 2016-06-02.

18 answers have been received.

Jump to results for question:

  1. [Question - discuss on 25th May] Does WCAG 2.0 SC 1.3.1 mean that headings areas, footer areas are required to be identified programatically or in text
  2. Proposal Should G83: "Providing text descriptions to identify required fields that were not completed" reference 3.3.2 (Labels or Instructions: Labels or instructions are provided when content requires user input)? #164
  3. F38 and 4.1.1 conflict ? #186
  4. "Large text" - using px rather than pt as unit #181

1. [Question - discuss on 25th May] Does WCAG 2.0 SC 1.3.1 mean that headings areas, footer areas are required to be identified programatically or in text

Question “Does WCAG 2.0’s SC 1.3.1 require that heading areas, footer areas, navigation areas, main content area, asides are identified (either programmatically or in text)?

This question is core to a couple of issues that the group is looking at and we need a clear answer on this specific point to proceed.”

Summary

ChoiceAll responders
Results
Yes 6
No 5
Not sure - here's why... 7

Details

Responder [Question - discuss on 25th May] Does WCAG 2.0 SC 1.3.1 mean that headings areas, footer areas are required to be identified programatically or in text
Jonathan Avila Not sure - here's why... In some specific cases perhaps -- but generally no because this information appears at the top of a page, at the bottom of a page, or in groups such as a links in a unordered list.
Andrew Kirkpatrick No
Wayne Dick Yes It has always been necessary to identify meaningful areas for navigation. One can use many mechanisms but one should be chosen.
Patrick Lauke Not sure - here's why... I would argue that it is highly dependent on the actual content of these areas. If it is clear from their actual content what they are (e.g. if a footer only contains a copyright notice or similar), or if their content is "trivial" (for whatever definition of trivial - e.g. a header area that only contains a company logo), then even when they are not explicitly identified, users won't be confused/lost.
James Nurthen No Only if they are "significant"
Alastair Campbell Not sure - here's why... Yes if "conveyed through presentation".
However, I do refer back to previous discussions that when WCAG 2 was published there was no useful and clear mechanism for identifying header/footer/nav/main areas, therefore failing old pages / products for that now seems overly harsh.
Makoto Ueki Not sure - here's why... If using HTML5 and those areas are clearly conveyed through presentation, I would say Yes since HTML5 has the sectioning element for the areas. As for non HTML5, we can use landmark role now. If I were asked to evaluate a non HTML5 web page today, I would recommend to use landmark roles. But I'm not sure if it is always testable to determine that those areas are clearly conveyed through presentation.
Joshue O'Connor No I think headers/footers are different from navigation/main. The later are more functional and better defined. A header 'may' or usually contains things like navigation - but may not. A footer has historically been almost usless with copyright info and inaccessibility statements. Lately they are being used more. My point is that some are functional, and thats fine, but some only 'maybe' functional and usefull to mark up as 'header' and 'footer' but that is dependent on where their contents are useful or not.

So for that reason I don't want us to make a blanket call that they are required to be marked up as such. Maybe we should tweak the question around 'functionality'? I can see that being more of a requirement.
Greg Lowney Not sure - here's why... From a user's perspective there are at least two reasons areas should be demarcated: because they affect navigation (e.g. a user wants to skip content that's repeated on every page of a site) or they're distinguished by presentation (so that it might be referred to in instructions or conversation).

However, the wording of SC 1.3.1 clearly limits itself to information "conveyed through presentation" so I'd say it *does* require textual or programmatic identification for areas that are distinguished in presentation, but not for others.

Significance does not meaningful given the way the SC is worded.
Laura Carlson Not sure - here's why... Yes and No dependent on visual formatting.

Yes, if implied by visual formatting. As the Understanding SC 1.3.1 says, "Having these structures and these relationships programmatically determined or available in text ensures that information important for comprehension will be perceivable to all."

No, if not implied by visual formatting.

Michael Cooper Not sure - here's why... If regions are conveyed through presentation, then I think the wording does mean they need to be identified. But "conveyed through presentation" seems partly subjective.

I always assumed just wrapping them in a <div> did the job, they were identifiable "chunks" in the DOM even though there wasn't much specific a11y support for that.

Labeling them with headings or title text seems like a "nice to have", though it could be argued is a requirement.

ARIA landmarks and allow a better programmatically determined regions than were possible at the time the guidelines were approved. That's great for new content. But it's still not clear to me that older techniques would therefore become insufficient.
Sarah Horton No
Kim Dirks No This seems like a simple question, but the implications are huge and therefore I do not think we can require this. Of course, people should be doing this, but I don't think we can *explicitly* require it now, after WCAG 2.0 has been out for so long. From a policy perspective, there are at least two concerns: Whether true or not, this will be perceived as changing WCAG 2.0. Second, for teams with large complicated sites, adding this codding can be a massive undertaking, and I do not want WCAG 2.0 to be seen as either a moving target or as a set of "impossible to achieve" guidelines.
Stephen Repsher Yes I can speak in more detail via email or in the meeting, but I strongly feel that, as written today, the SC applies to headers, footers, sidebars, etc. I also believe a failure needs to be introduced on the misuse of landmarks when they are used in ways that does not completely encompass the webpage.
Marc Johlic Yes I lean toward Yes because the layout of the page is pretty much "conveyed through presentation". And to further that, if for some reason someone put their "header" on the left side of a bizarre 3 column layout and the "footer" on the right side of the page (for whatever horrendous reason), shouldn't those regions be programmatically determinable so that folks can easily find them?

So, I'm in the Yes corner because I feel these regions are easily visually identifiable via visual presentation and folks should be able to do so programmatically as well.
David MacDonald Yes
Maureen Kraft Yes 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. Yes. I think this includes header, footer, navigation, main and asides. Programmatically exposing elements that are visually presented is essential for screen reader users to not only navigate the page but to understand its structure. We sightees take the presentation/layout for granted. If a help desk were to ask us to select Link A in the header, we can quick go to the header and find Link A. Sure a screen reader user can bring up a list of links and search for Link A but it doesn't seem right to not give them the same benefit of the structure of the page and the ability to quickly locate an item contained within that section/region.
Adam Zerner Yes I'm more yes than no, if regions are conveyed visually then yes. So its dependent on how the content is presented.

2. Proposal Should G83: "Providing text descriptions to identify required fields that were not completed" reference 3.3.2 (Labels or Instructions: Labels or instructions are provided when content requires user input)? #164

We have an updated proposal from Sailesh on Github issue #164.

You can view the rationale for change on GitHub: .

Results from last survey on #164.

Resolution [Left open] from this meeting:.

Summary

ChoiceAll responders
Results
Accept this updated proposal 2
Accept with the following changes.
Do not accept at this time. 8

Details

Responder Proposal Should G83: "Providing text descriptions to identify required fields that were not completed" reference 3.3.2 (Labels or Instructions: Labels or instructions are provided when content requires user input)? #164
Jonathan Avila Accept this updated proposal
Andrew Kirkpatrick Do not accept at this time. I still do not understand / agree with all of the proposed changes

https://github.com/w3c/wcag/issues/164#issuecomment-213559916
Wayne Dick I did not follow this issue.
Patrick Lauke
James Nurthen Do not accept at this time. ok - what is this about. The survey question is about G83 but the proposal seems to be a rewrite of the understanding for 3.3.2
I do not agree with removing the instructions examples for date formats etc from 3.3.2 as I believe 3.3.2 covers these - however I do agree that 3.3.2 doesn't really seem to apply to G83 so am fine with that part.
Alastair Campbell Do not accept at this time. I have a hard time understanding this one, but for my money the first line of the understanding says what it needs to: "content authors place instructions or labels that identify the controls in a form so that users know what input data is expected." and the US phone number example lays out the multi-field approach.
Makoto Ueki Do not accept at this time. I don't agree with removing the existing 2 examples. And I think G83 is about 3.3.1 and 3.3.3, but not 3.3.2.
Joshue O'Connor Do not accept at this time. Unfortunately, I just don't fully understand this.
Greg Lowney
Laura Carlson
Michael Cooper Do not accept at this time. I'm really trying, but just cannot manage to wade through everything and figure out 1) exactly what is proposed to change (and what is not), and 2) why. I see a bunch of new stuff but can't figure out how radical of a change it proposes, nor what problem it solves.

To get effective review, an exact diff and rationale needs to be provided in a concise manner that is not interwoven among several comments and links.
Sarah Horton Do not accept at this time.
Kim Dirks Do not accept at this time. I'm not sure what the proposal is proposing
Stephen Repsher Accept this updated proposal
Marc Johlic
David MacDonald
Maureen Kraft
Adam Zerner

3. F38 and 4.1.1 conflict ? #186

We have a comment and proposed response on F38.

Please review the following,related to proposed response to F38 on GitHub.

Summary

ChoiceAll responders
Results
Accept the response as proposed 15
Accept with the following changes 1
Do not accept for the following reasons.

Details

Responder F38 and 4.1.1 conflict ? #186
Jonathan Avila Accept the response as proposed
Andrew Kirkpatrick Accept the response as proposed
Wayne Dick Accept the response as proposed
Patrick Lauke Accept the response as proposed
James Nurthen Accept the response as proposed
Alastair Campbell Accept the response as proposed
Makoto Ueki Accept the response as proposed
Joshue O'Connor Accept with the following changes Small edit -" and there is no[t] requirement to indicate every Success Criteria that is not related to a failure".
Greg Lowney
Laura Carlson Accept the response as proposed
Michael Cooper Accept the response as proposed
Sarah Horton Accept the response as proposed
Kim Dirks Accept the response as proposed
Stephen Repsher Accept the response as proposed
Marc Johlic Accept the response as proposed
David MacDonald
Maureen Kraft Accept the response as proposed
Adam Zerner Accept the response as proposed

4. "Large text" - using px rather than pt as unit #181

There is an interesting discussion on on Github around whether pixels are a more natural format for Large text than Points (for on screen content). The question is should we consider this issue merely editorial or is it more substantive?

Please review the issue should "Large text" - using px rather than pt as unit .

Summary

ChoiceAll responders
Results
This issue is editorial and we should include it in current WCAG work. 7
This issue is more substantive and is more suitable to our WCAG 2.x or WCAG.next work. 7

Details

Responder "Large text" - using px rather than pt as unit #181
Jonathan Avila This issue is editorial and we should include it in current WCAG work. I feel this is an editorial issue but unfortunately the pt made it's way into the definition portion that is not a note! Really this shouldn't even be in px -- but should be about defualt font size (commonly 12pt, 1em, 16px and font size that 1.2x and 1.5x -- that is on mobile the default font size may something other than 12pt and all of this should be based on lessening the thresold based on the size of the font compared to the default font size.
Andrew Kirkpatrick This issue is more substantive and is more suitable to our WCAG 2.x or WCAG.next work. There is no question that the language of the SC was provided deliberately, and if there is a need to provide clarification we should do that in the understanding document. We can adjust the language in a 2.1 if needed.
Wayne Dick This issue is editorial and we should include it in current WCAG work. The size should be expressed in a format that makes it easiest for developers to implement. The unit of measure is not important the relative size is the key.
Patrick Lauke This issue is editorial and we should include it in current WCAG work. For clarity, it may have been good to also point to the actual hard proposal https://github.com/w3c/wcag/pull/184
James Nurthen This issue is editorial and we should include it in current WCAG work.
Alastair Campbell This issue is editorial and we should include it in current WCAG work. On Jonathon's comments about pt being in the definition: That is unfortunate, but given that the explanation about PX and defaults becomes necessary.
AWK: Not sure I understand, the SC just references "large text", and the definition is not changing, the proposal is changing the notes underneath the definition. The understanding doc also links through to the definition, and (re?) displays it (and the notes) at the bottom, which would undermine the new text.
Makoto Ueki I agree with "using px rather than pt as unit" itself. But I'd like to confirm the border line between "editorial" and "not editorial" for WCAG.
Joshue O'Connor Thanks Patrick for bring this up - very interesting. I'm on the fence with this or rather feel the answers to this survey question are not sufficient. If we can bring clarity to this area - that's fine with me. I agree designers don't think in points. But then what a point is itself is a movable feast. I agree with framing the discussion around default sizes - as that may help all understand that this is all relative and context dependent.

Anyway, I do think it needs more discussion, and more awareness/input from the Working group - so I'm voting that this is more substantive and that we should hold off making the change until we are sure it won't break anything.
Greg Lowney
Laura Carlson This issue is editorial and we should include it in current WCAG work. I'd really like the issue to be editorial as developers understand pixels better than points. We would need to make sure that the clarification meets the actual text of the SC. Perhaps a non-normative note?

If the the change is more substantive, It could be included in WCAG 2.x or WCAG.next.
Michael Cooper This issue is more substantive and is more suitable to our WCAG 2.x or WCAG.next work. Given this is a proposed change to WCAG 2.0 itself, I think this is clearly substantive. To me, "pt" is an absolute measure which is defined in terms of fractions of inches or meters. Changing to a different measure in WCAG would be an extremely substantive change. I am concerned that the argument for a change is based on current implementations that essentially redefine the meaning of pt and px and move away from the absolute meaning that WCAG 2.0 uses.
Sarah Horton This issue is more substantive and is more suitable to our WCAG 2.x or WCAG.next work.
Kim Dirks This issue is more substantive and is more suitable to our WCAG 2.x or WCAG.next work.
Stephen Repsher This issue is more substantive and is more suitable to our WCAG 2.x or WCAG.next work. Personally, I do not believe the WCAG should be in the business of defining "large" text. As pointed out in the discussion, ambiguities arise no matter what measure is being used, and there are too many variables and sciences to be sorted out when talking about digital screen content. The questions for WCAG work should be centered around 2 themes: clarity of all text (thus, font and pixels are what matters), and "relative size" to differentiate semantics.
Marc Johlic This issue is editorial and we should include it in current WCAG work.
David MacDonald
Maureen Kraft This issue is more substantive and is more suitable to our WCAG 2.x or WCAG.next work.
Adam Zerner This issue is more substantive and is more suitable to our WCAG 2.x or WCAG.next work. I like the idea of accepted base values as defaults across a range of units (px, pt, em and so on) - also I see value in a conversion chart across units. I've found designers & developers use different units per project and/or per software. As an example a designer is using Adobe Indesign with points, the developers are using ems and the styleguide of the organisation is referenced in pixels.

More details on responses

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

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.