w3c/wbs-design
or
by mail to sysreq
.
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:
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) |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
w3c/wbs-design
or
by mail to sysreq
.