w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire [Tutorials] Forms Tutorial Review
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: ee@w3.org
This questionnaire was open from 2014-12-19 to 2015-01-20.
14 answers have been received.
Jump to results for question:
- Support for publishing the Forms Tutorial
- Forms concepts
- Labeling Controls
- Grouping Controls
- Form Instructions
- Validating Input
- User Notifications
- Multi-Page Forms
- Custom Controls
- Tips and Tricks
- Overall and other
1. Support for publishing the Forms Tutorial
Summary
| Choice | All responders |
|---|---|
| Results | |
| I support publishing these Forms Tutorial pages as they are | 4 |
| I support publishing these Forms Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion) | 5 |
| I support publishing these Forms Tutorial pages only with the changes in the comments sections below | 3 |
| I do not support publishing these Forms Tutorial pages, because of the comments in the comments sections below | 2 |
| I abstain (not vote) |
Details
| Responder | Support for publishing the Forms Tutorial | |
|---|---|---|
| Chaals Nevile | I support publishing these Forms Tutorial pages only with the changes in the comments sections below | |
| Eric Eggert | I support publishing these Forms Tutorial pages as they are | |
| Léonie Watson | I do not support publishing these Forms Tutorial pages, because of the comments in the comments sections below | |
| Wayne Dick | I support publishing these Forms Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion) | |
| Michael Elledge | I support publishing these Forms Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion) | |
| Marc Johlic | I support publishing these Forms Tutorial pages only with the changes in the comments sections below | |
| Andrew Kirkpatrick | I support publishing these Forms Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion) | |
| Michael Cooper | I support publishing these Forms Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion) | |
| Anna Belle Leiserson | I support publishing these Forms Tutorial pages; however, I suggest the changes in the comments sections below (for editors' discretion) | |
| Shawn Lawton Henry | I support publishing these Forms Tutorial pages as they are | [I have not been able to review it much, but I support publishing it based on others' reviews.] |
| Sharron Rush | I do not support publishing these Forms Tutorial pages, because of the comments in the comments sections below | I am eager to get the tutorials published, but clearly we need more time to evaluate and address the comments submitted so far. I agree with the need for more ARIA references and would like additional time to review the comments in context. |
| Lydia Harkey | I support publishing these Forms Tutorial pages as they are | |
| Vivienne Conway | I support publishing these Forms Tutorial pages as they are | |
| Frederick Boland | I support publishing these Forms Tutorial pages only with the changes in the comments sections below |
2. Forms concepts
Forms concepts
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
Details
| Responder | Forms concepts |
|---|---|
| Chaals Nevile | Editorial: A few examples illustrating forms (e.g. the things you actually show later on) might be helpful in this page. |
| Eric Eggert | |
| Léonie Watson | |
| Wayne Dick | Nice flow and organization. I believe moving ARIA up in the discussion is critical. |
| Michael Elledge | No comments. |
| Marc Johlic | |
| Andrew Kirkpatrick | I am concerned that this diminishes ARIA techniques as viable through omission. I understand the desire to not highlight ARIA (kind of) but for labeling you say "use label and in rare cases title" which leaves the reader to assume that anything else is so rare as to not merit mention. Suggestion: "Use the label element and other mechanisms to identify each form control" or "Use the label element and other mechanisms (e.g. ARIA, title attribute, etc) to identify each form control" or, since this is the one of the only items where a specific element is mentioned: "Identify each form control to help users understand the purpose of the control." |
| Michael Cooper | |
| Anna Belle Leiserson | |
| Shawn Lawton Henry | |
| Sharron Rush | +1 to Andrew re ARIA |
| Lydia Harkey | |
| Vivienne Conway | I have gone through the Forms concepts and don't have any issue with them - it all looks straight forward and easy to understand. |
| Frederick Boland | cf. Andrew |
3. Labeling Controls
Labeling Controls
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
Details
| Responder | Labeling Controls |
|---|---|
| Chaals Nevile | Showstopper: The use of for attributes should be introduced in the first example Showstopper: The example of table-layout CSS overly complicates what could be a simple table. Showstopper: Hiding information from people who don't have a screenreader - i.e. the enormous majority of people with disabilities - is bad practice. Showstopper: Search should always be marked up with the relevant role Showstopper: There should be a clear difference between examples of recommended practices and examples of practices that are not recommended (e.g. relying on aria-label or title). |
| Eric Eggert | |
| Léonie Watson | |
| Wayne Dick | Really excellent |
| Michael Elledge | #1: priority: strong suggestion for editors' discretion location: Throughout document current wording: NA suggested revision: Indicate which implementations are recommended, when and why. rationale: Users need direction about which technique to use. #2: priority: strong suggestion for editors' discretion location: Throughout document current wording: NA suggested revision:Revise ids in the examples so they would validate if they are copy and pasted to a single document. |
| Marc Johlic | #1 Priority: important to be addressed before publication Location: http://www.w3.org/WAI/tutorials/forms/labels/#using-the-aria-label-attribute Rationale: I'm not sure what this "Using the aria-label attribute" is doing at the bottom of the page. It seems to have been covered earlier in the page in the "Hiding Labels" section. If the intent is to just have a separate "Using the aria-label attribute" section in addition to the earlier mention on the page, that's great - but the example code in this section needs to be updated because it currently does not contain an aria-label. #2 Priority: strong suggestion for editors' discretion I was always under the impression that explicitly associating labels was the better option - and therefore feel it should be the first method covered. That said - I'm wondering if there is a better way to indicate which of the methods described is preferred / more accessible. Perhaps by listing them in the that order? Most preferred to least? #3 Priority: important to be addressed before publication I feel that aria-labelledby (ARIA 16) should also be covered on this page. #4 Priority: important to be addressed before publication Add ARIA14 and ARIA16 to the resources |
| Andrew Kirkpatrick | Same comment re: ARIA in first paragraph No mention of labelled-by? No references to ARIA techniques? |
| Michael Cooper | |
| Anna Belle Leiserson | |
| Shawn Lawton Henry | |
| Sharron Rush | Seems necessary to make a stronger delineation between recommended practice examples and others. |
| Lydia Harkey | priority: [mild suggestion for editors' discretion] location: Title current wording:Labeling suggested revision:Label rationale:A developer learning to code accessibility will most likely search for the actual code for accessibility as 'label' versus labeling. |
| Vivienne Conway | I have reviewed the Labeling Controls and it seems very comprehensive. I don't have anything further to add. |
| Frederick Boland |
4. Grouping Controls
Grouping Controls
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
Details
| Responder | Grouping Controls |
|---|---|
| Chaals Nevile | Showstopper: Please explain optgroup here and not just in tips and tricks. |
| Eric Eggert | |
| Léonie Watson | |
| Wayne Dick | see: http://nosetothepage.org/EO/Meeting07-01.html#form |
| Michael Elledge | No comments. |
| Marc Johlic | #1 Priority: strong suggestion for editors' discretion Rationale: I'd like to see ARIA17: "Using grouping roles to identify related form controls" included on this page. |
| Andrew Kirkpatrick | ARIA17 concept? At least a mention that this exists? |
| Michael Cooper | Would like to talk more about the ins and outs of grouping. Should fieldset be used around controls other than checkbox and radio button groups? Why or why not? How is the user experience different from when a fieldset is not used? |
| Anna Belle Leiserson | |
| Shawn Lawton Henry | |
| Sharron Rush | Mention of ARIA 17 is missing here |
| Lydia Harkey | |
| Vivienne Conway | no further comment |
| Frederick Boland |
5. Form Instructions
Form Instructions
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
Details
| Responder | Form Instructions |
|---|---|
| Chaals Nevile | Showstopper: There should be something stronger about design of forms in themselves, rather than accepting that people just randomly ask for dates in whatever format makes sense to them... |
| Eric Eggert | |
| Léonie Watson | |
| Wayne Dick | |
| Michael Elledge | priority: strong suggestion for editors' discretion location: Throughout document current wording: NA suggested revision: Indicate which implementations are recommended, when and why. rationale: Users need direction about which technique to use. |
| Marc Johlic | #1 Priority: important to be addressed before publication Rationale: ARIA1: "Using the aria-describedby property to provide a descriptive label for user interface controls" should be included on this page #2 Priority: strong suggestion for editors' discretion Rationale: ARIA9: "Using aria-labelledby to concatenate a label from several text nodes" would be a good technique to cover on this page #3 Both ARIA1 and ARIA9 should be added to Resources section |
| Andrew Kirkpatrick | Approach #2 will result in a missing label. The labeling hierarchy will make the labelled-by trump the for/id. Good to have the CSS placeholder styling recommendations. |
| Michael Cooper | |
| Anna Belle Leiserson | |
| Shawn Lawton Henry | |
| Sharron Rush | |
| Lydia Harkey | |
| Vivienne Conway | no further comment |
| Frederick Boland |
6. Validating Input
Validating Input
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
Details
| Responder | Validating Input |
|---|---|
| Chaals Nevile | Showstopper: The page should point out that client-side forms can always be tampered with, and input MUST still be validated server-side. Showstopper: |
| Eric Eggert | |
| Léonie Watson | |
| Wayne Dick | Clear and direct. |
| Michael Elledge | priority: strong suggestion for editors' discretion location: Fifth heading current wording: Be forgiving of different input formats suggested revision: Add link to resource that describes how to create forgiving input formats. rationale: Most users will not know how to do this and will benefit by having link/example. |
| Marc Johlic | #1 Priority: important to be addressed before publication Rationale: The following ARIA techniques should be added to the Resources section and used in examples: ARIA21: Using Aria-Invalid to Indicate An Error Field ARIA18: Using aria-alertdialog to Identify Errors ARIA19: Using ARIA role=alert or Live Regions to Identify Errors ARIA21: Using Aria-Invalid to Indicate An Error Field |
| Andrew Kirkpatrick | |
| Michael Cooper | The "required" example shows the word "required" being used in the label as well as the attribute "required" but does not explain why both are needed. This section should also go into what happens when authors do validation beyond the client-side features provided by HTML. How do they report issues to the user in a WCAG conforming way? The UA takes care of that for standard control types, but not for more elaborate validations. ... or more clearly point out the relevance of the following section on user notifications to cover that. |
| Anna Belle Leiserson | |
| Shawn Lawton Henry | |
| Sharron Rush | |
| Lydia Harkey | |
| Vivienne Conway | no further comment |
| Frederick Boland |
7. User Notifications
User Notifications
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
Details
| Responder | User Notifications |
|---|---|
| Chaals Nevile | |
| Eric Eggert | |
| Léonie Watson | |
| Wayne Dick | Good. |
| Michael Elledge | priority: strong suggestion for editors' discretion location: Throughout document current wording: NA suggested revision: Indicate which implementations are recommended, when and why. rationale: Users need direction about which technique to use. |
| Marc Johlic | #1 Priority: Rationale: ARIA18: "Using aria-alertdialog to Identify Errors" should be included in resources and examples. |
| Andrew Kirkpatrick | |
| Michael Cooper | I'm not very hot on the stuff about pop-up dialogs. Don't really want to encourage it. But if describing it, it seems like it belongs in a separate tutorial about dialogs, not in the forms tutorial. If the forms tutorial wants to mention them, they should say "you can use dialogs as described in the dialogs tutorial". I know there isn't a dialogs tutorial now. But one shouldn't be squozen into the forms tutorial. |
| Anna Belle Leiserson | |
| Shawn Lawton Henry | |
| Sharron Rush | |
| Lydia Harkey | |
| Vivienne Conway | no further comment - really good content |
| Frederick Boland |
8. Multi-Page Forms
Multi-Page Forms
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
Details
| Responder | Multi-Page Forms |
|---|---|
| Chaals Nevile | |
| Eric Eggert | |
| Léonie Watson | |
| Wayne Dick | Good. |
| Michael Elledge | No comment. |
| Marc Johlic | |
| Andrew Kirkpatrick | |
| Michael Cooper | [Publication Killer though easily addressed] There is unstoppable animation on the progress element example that causes it not to conform to WCAG. |
| Anna Belle Leiserson | |
| Shawn Lawton Henry | |
| Sharron Rush | |
| Lydia Harkey | |
| Vivienne Conway | no further comment |
| Frederick Boland |
9. Custom Controls
Custom Controls
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
Details
| Responder | Custom Controls |
|---|---|
| Chaals Nevile | |
| Eric Eggert | |
| Léonie Watson | |
| Wayne Dick | Good. |
| Michael Elledge | No comment. |
| Marc Johlic | Looks good |
| Andrew Kirkpatrick | |
| Michael Cooper | |
| Anna Belle Leiserson | |
| Shawn Lawton Henry | |
| Sharron Rush | |
| Lydia Harkey | |
| Vivienne Conway | no further comment |
| Frederick Boland |
10. Tips and Tricks
Tips and Tricks
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
For each comment, remember to indicate if it is a suggestion for editor's discretion or if you feel it must be addressed before this version is published.
Details
| Responder | Tips and Tricks |
|---|---|
| Chaals Nevile | |
| Eric Eggert | |
| Léonie Watson | |
| Wayne Dick | Excellent. |
| Michael Elledge | priority: strong suggestion for editors' discretion location: Throughout document current wording: NA suggested revision:Would like to see links to examples of how to implement these tips, or, even better, provide them on the relevant preceding page(s). |
| Marc Johlic | Looks good |
| Andrew Kirkpatrick | |
| Michael Cooper | |
| Anna Belle Leiserson | |
| Shawn Lawton Henry | |
| Sharron Rush | |
| Lydia Harkey | |
| Vivienne Conway | no further comment |
| Frederick Boland |
11. Overall and other
Any overall comments or other comments?
Details
| Responder | Overall and other |
|---|---|
| Chaals Nevile | The paragraph marker for permalinks is a total mystery. If you want "link to here" please use that. But since you already have those links in the navigation, it strikes me as extra noise, to be honest. By the way, please do get these documents published. When corrected, and with the explanation text simplified, I think they will become very valuable to W3C as well as the community at large |
| Eric Eggert | |
| Léonie Watson | This tutorial will be a useful and respected source of information for developers. However I'm afraid that at present it isn't at a point where it should be considered fit for publication. It isn't clear whether techniques are recommended or not. A tutorial should only include best practice techniques, or make it abundantly clear when it's reasonable to use an alternative technique and under what circumstances. There is no consistent structure within each section of the tutorial, making it difficult for students to gradually build knowledge. Examples are often too complex, and general concepts are bundled together with specific techniques in no discernible pattern. There is missing and misleading information. Some recommendations are either inadvisable (and not clearly flagged as such), inadequately explained, or otherwise inappropriate for inclusion in a tutorial of this nature. Suggest further review is needed before the tutorial merits further peer review. --- (I asked Léonie to provide some more detailed information, this is her response to my email.) Eric, Thanks for getting in touch. The "Labeling controls" component is an example where the structure is confusing: http://www.w3.org/WAI/tutorials/forms/labels/ It begins by talking about the concepts of explicit/implicit labels, then to labels for one specific control type (but not others), then to methods for hiding and positioning labels, then to specific attribute based techniques. For example, the information about implicit/explicit association is given too much prominence. It would be better to group this information into a section called "Using the label element", and for the explicit example to be clearly indicated as best practice, with a short note on implicit association. The section on using the label element should include more examples. In doing so the topic of label positioning can be addressed, without needing a section of its own. The aria-label attribute is included in the "Hiding labels" section, and in a section of its own. It would be easier to use this tutorial if a consistent way of presenting information were chosen (for this component and throughout the tutorial). For example by breaking information down by technique for accomplishing the task the component features on. In this case the task is providing labels, so the techniques/sections of the component might be: Using the label element Using the title attribute Using the aria-label attribute The "Labeling controls" component also sets the scene for overly complicated examples. The use case for explicitly associated labels is too complex and the subsequent code example gets in the way. The simple explanation is that if the label isn't wrapped around the field, you must use an explicit association. There are also examples of advice where the correct approach is not made clear enough. For example, when referencing techniques to hide labels, it needs to be emphasised much more clearly that a visible cue (that is visually associated with the field) must be present. If no visible cue is available it isn't acceptable to use hidden labels. An example of information that is misleading can also be found in this component of the toturial. Under the "Using the title attribute" heading, the tutorial says: " The title attribute can be used to identify form elements. This approach is generally less reliable and not recommended because some screen readers and assistive technology do not interpret the title attribute as a replacement for the label element, possibly because the title attribute is often used to provide non-essential information." I believe that all the major screen readers support the title attribute on form fields as default behaviour. This includes Jaws, NVDA, Window-Eyes, Supernova, Orca, VoiceOver (iOS/OSX) and Talkback. In the section on hiding labels it says "In such cases a label can be hidden visually though it still needs to be provided within the code to support other forms of presentation and interaction, such as for screen reader and speech input users.". How does a speech recognition user benefit from a label they cannot see? In terms of missing information there are examples in this component too. For example, the aria-labelledby attribute should be included as a technique for providing a label. It can be used to associate existing content with the field - for example the text from the search button with the search field. In the section that currently focuses on labels for buttons, there are no examples of buttons that use background images to provide visual cues. Other random notes from the rest of the tutorial include: The aria-labelledby attribute should not be used to associate a hint or instruction with a form field. The aria-labelledby attribute is intended to provide an accessible name for the field (which is already being done through the label element). The aria-describedby attribute is better for providing additional descriptive information (like a hint or instruction). Using the progress element to indicate user progress feels like a stretch. It's generally used to indicate automatic progress, not user progress. I'm afraid I stopped making notes after I read through the first couple of sections, so can't pull out examples from later components within the tutorial. Essentially I think that the tutorial itself is difficult to understand, and that the information within it needs thorough technical review. Hope this helps.Léonie. |
| Wayne Dick | Good code, clear write up, fun, probably needs more ARIA representations of forms (using standard controls without <form> element. |
| Michael Elledge | |
| Marc Johlic | #1 Overall I think this is a great tutorial and look forward to having it published. #2 I would just like to see more use of WAI-ARIA; at a minimum, all of the ARIA techniques listed as Sufficient Techniques for the referenced Success Criteria should be included. #3 I think there should be some sort of indication given as to which techniques / examples are considered optimal or best practice. (And of course *I* would put the ARIA techniques up at / or near the top). |
| Andrew Kirkpatrick | |
| Michael Cooper | |
| Anna Belle Leiserson | |
| Shawn Lawton Henry | |
| Sharron Rush | Still a draft it seems to me, not ready for publication. |
| Lydia Harkey | |
| Vivienne Conway | It all looks really good to me. Hats off to the contributors, these tutorials are looking great! |
| Frederick Boland |
More details on responses
- Chaals Nevile: last responded on 30, December 2014 at 13:09 (UTC)
- Eric Eggert: last responded on 8, January 2015 at 14:50 (UTC)
- Léonie Watson: last responded on 8, January 2015 at 14:55 (UTC)
- Wayne Dick: last responded on 9, January 2015 at 14:12 (UTC)
- Michael Elledge: last responded on 12, January 2015 at 20:49 (UTC)
- Marc Johlic: last responded on 13, January 2015 at 01:27 (UTC)
- Andrew Kirkpatrick: last responded on 13, January 2015 at 15:21 (UTC)
- Michael Cooper: last responded on 13, January 2015 at 15:35 (UTC)
- Anna Belle Leiserson: last responded on 13, January 2015 at 19:44 (UTC)
- Shawn Lawton Henry: last responded on 13, January 2015 at 21:40 (UTC)
- Sharron Rush: last responded on 13, January 2015 at 22:51 (UTC)
- Lydia Harkey: last responded on 14, January 2015 at 08:56 (UTC)
- Vivienne Conway: last responded on 14, January 2015 at 08:58 (UTC)
- Frederick Boland: last responded on 20, January 2015 at 15:39 (UTC)
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