draft review of 4.10 forms

General

*         I'd like to see some discussion of using form elements (checkboxes, buttons, etc) outside of <form> tags, as is common for interactive applications.

*         Does the spec have a glossary?  There are a lot of linked terms don't lead to a clear definition.  Some of the links seem to be circular.  (some specific examples in the notes below)

4.10.1.1
Is it really common to wrap form elements in <p> tags?  I would have expected divs or just letting them flow within a fixed-width container.


*         example uses <label><input>text</label> which is the less-preferred way to do labeling.  Examples should use <label for> and ID.

*         Uses <button> for submission.  Better practice to use <input type=submit> so script is not required.
4.10.4 Fieldset

*         Why is fieldset barred from constraint validation.  Why does it support validation methods if it is?

*         Examples are all about disabling sections, which is a new feature in 5.  Add examples of grouping and labeling uses from prior versions.

4.10.5 Legend

*         This syntax is confusing.  Why are the only examples of legends that are interactive?

<legend><label><input>text<label><legend>



4.10.6 Label

*         The second sentence here seems to contradict the first and the following example???

"The label<http://dev.w3.org/html5/spec/forms.html#the-label-element> element's exact default presentation and behavior, in particular what its activation behavior<http://dev.w3.org/html5/spec/content-models.html#activation-behavior> might be, if anything, should match the platform's label behavior. The activation behavior<http://dev.w3.org/html5/spec/content-models.html#activation-behavior> of a label<http://dev.w3.org/html5/spec/forms.html#the-label-element> element for events targetted at interactive content<http://dev.w3.org/html5/spec/content-models.html#interactive-content> descendants of a label<http://dev.w3.org/html5/spec/forms.html#the-label-element> element, and any descendants of those interactive content<http://dev.w3.org/html5/spec/content-models.html#interactive-content> descendants, must be to do nothing."

*         Multiple labels (control.labels).  HTML 4 restricted this to one label per control.  How does this map to control name accessibility APIs?  How does it interact with ARIA name calculation?  Is it useful for accessibility? What is the use case for this?  Problems with hit testing and API mappings.

*         Need to think about how this example would map to Accessibiltiy APIs
<p><label>Full name: <input name=fn> <small>Format: First Last</small></label></p>
<p><label>Age: <input name=age type=number min=0></label></p>
<p><label>Post code: <input name=pc> <small>Format: AB12 3CD</small></label></p>



4.10.7 Input http://dev.w3.org/html5/spec/the-input-element.html#the-input-element

*         In general, having attributes that are only valid with certain types is confusing.  In HTML 4, it's a common error to use alt on input other than type=img.  The design seems likely to cause more of that sort of confusion.  Can any of the attributes be made applicable to all input types, with specified mapping behavior?

*         Alt.  Is it required? API mapping needs to cover interaction of label and alt

*         Autocomplete:  how does this map to API?  Does this turn text controls into comboboxes?

*         Should autocomplete be able to take a URL for a service?  How about a datalist?

*         Autofocus:  good idea to get around script issues with screen readers.  Do we know if it works?

*         "Save Button" example for formnovalidate is a good candidate for a WCAG technique http://dev.w3.org/html5/spec/association-of-controls-and-forms.html#attr-fs-formnovalidate

*         Why are there size, width and height attributes?  Shouldn't this be handled with CSS?  Can we make these obsolete but conforming?

*         Input.form what is the use case for this?  It claims to be a work-around for the lack of nested forms, but what is the use case for nested forms?  4.10.18 Association of controls and forms http://www.w3.org/TR/2011/WD-html5-20110525/association-of-controls-and-forms.html#attr-fae-form.  This looks like an authoring error. Specifying what the browser should do in case of this authoring error is fine, but why have an authoring feature to work around it?

*         List.  This makes any input that is a text control into a combobox.  Type table needs to reflect that these change control type when they have lists.

*         Name isn't in the table of what attributes are supported on what types.  Assume it's on all types?  Should be listed to make it clear.

*         Pattern.  This is really cool.

*         Placeholder.  What should users put in here, vs. label, vs. title.  In accessibility API, I think this maps to accname, not value as current fake-placeholders do.  How does it play with other things in name calculation?  What should be read if there is a label and a placeholder

*         Required.  Also good.

*         What is a value sanitation algorithm?  Please define what this is supposed to do.  Links within the section go to the top of the section.

*         Is the second sentence referring to immutable objects? It seems to apply to mutable, but doesn't make sense  "Each input<http://www.w3.org/TR/2011/WD-html5-20110525/the-input-element.html#the-input-element> element is either mutable or immutable. Except where otherwise specified, an input<http://www.w3.org/TR/2011/WD-html5-20110525/the-input-element.html#the-input-element> element is always mutable<http://www.w3.org/TR/2011/WD-html5-20110525/the-input-element.html#concept-input-mutable>. Similarly, except where otherwise specified, the user agent should not allow the user to modify the element's value<http://www.w3.org/TR/2011/WD-html5-20110525/association-of-controls-and-forms.html#concept-fe-value> or checkedness<http://www.w3.org/TR/2011/WD-html5-20110525/association-of-controls-and-forms.html#concept-fe-checked>."

*         "The readonly<http://www.w3.org/TR/2011/WD-html5-20110525/common-input-element-attributes.html#attr-input-readonly> attribute can also in some cases (e.g. for the Date<http://www.w3.org/TR/2011/WD-html5-20110525/states-of-the-type-attribute.html#date-state> state, but not the Checkbox<http://www.w3.org/TR/2011/WD-html5-20110525/number-state.html#checkbox-state> state) make an input<http://www.w3.org/TR/2011/WD-html5-20110525/the-input-element.html#the-input-element> element immutable<http://www.w3.org/TR/2011/WD-html5-20110525/the-input-element.html#concept-input-immutable>. "

Is the full list of cases defined somewhere?

*         "When an input<http://www.w3.org/TR/2011/WD-html5-20110525/the-input-element.html#the-input-element> element is first created, the element's rendering and behavior must be set to the rendering and behavior defined for the type<http://www.w3.org/TR/2011/WD-html5-20110525/the-input-element.html#attr-input-type> attribute's state, and the value sanitization algorithm<http://www.w3.org/TR/2011/WD-html5-20110525/the-input-element.html#value-sanitization-algorithm>, if one is defined for the type<http://www.w3.org/TR/2011/WD-html5-20110525/the-input-element.html#attr-input-type> attribute's state, must be invoked."

These are defined with the states.  This is not clear when reading the above text, and the link goes to the top of the same section.  Can we have a generic definition of a value sanitation algorithm?

*         Input type can be changed dynamically.  This is inconsistent with ARIA role.  Is that ok?  It seems unlikely that either will change at this point.  Will need to be considered for API mapping.

*         Not accessibility, but it would be nice if <input type=email multiple> could split on semi-colon as well as comma

*         Is there value to allowing some form of friendly name in email fields?  When you paste from email programs, this is often included, and it's nice to be able to keep the friendly names around.  Cognitive, maybe?

*         Security issues with autocomplete or pattern on password?

*         Still concerning that date and time elements don't have controls specified for them.  This seems likely to lead to inconsistent UI, which may be confusing to AT users.

*         Range says that the exact number is not important, but it renders as a slider.  There are sliders where the exact number is important. "The user agent could pick which one to display based on the dimensions given in the style sheet. This would allow it to maintain the same resolution for the tick marks, despite the differences in width." This is very vague.  These different presentations should be controlled with CSS, not the browser.

*         Number's control is a "text box or spinner control."  Need to pick one so we know what accessibility role to map it to

*         "The input element represents a two-state control that represents the element's checkedness state. If the element's checkedness state is true, the control represents a positive selection, and if it is false, a negative selection. If the element's indeterminate IDL attribute is set to true, then the control's selection should be obscured as if the control was in a third, indeterminate, state.
Note:
The control is never a true tri-state control, even if the element's indeterminate IDL attribute is set to true. The indeterminate IDL attribute only gives the appearance of a third state."
Why isn't there a 3rd state?  This is inconsistent with ARIA.  Is that ok?

*         Are radio and checkbox valid without associated labels?

*         Can accept be extensible, to allow other file type filters?

*         "If the src attribute is set, and the image is available and the user agent is configured to display that image, then: The element represents a control for selecting a coordinate from the image specified by the src attribute; if the element is mutable, the user agent should allow the user to select this coordinate. The activation behavior in this case consists of taking the user's selected coordinate, and then, if the element has a form owner, submitting the input element's form owner from the input element. If the user activates the control without explicitly selecting a coordinate, then the coordinate (0,0) must be assumed.
Otherwise, the element represents a submit button whose label is given by the value of the alt attribute; if the element is mutable, the user agent should allow the user to activate the button. The activation behavior in this case consists of setting the selected coordinate to (0,0), and then, if the element has a form owner, submitting the input element's form owner from the input element."
Does this mean that it's only a button if the image doesn't download?

HTML 4 has this:
"Creates a graphical submit button. The value of the src attribute specifies the URI of the image that will decorate the button. For accessibility reasons, authors should provide alternate text for the image via the alt attribute.
When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where "name" is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.

If the server takes different actions depending on the location clicked, users of non-graphical browsers will be disadvantaged. For this reason, authors should consider alternate approaches:

Use multiple submit buttons (each with its own image) in place of a single graphical submit button. Authors may use style sheets to control the positioning of these buttons.
Use a client-side image map together with scripting."


Sounds like this functionality should be deprecated.  Is it often used?

*         "The alt attribute provides the textual label for the alternative button for users and user agents who cannot use the image. The alt<http://www.w3.org/TR/2011/WD-html5-20110525/number-state.html#attr-input-alt> attribute must also be present, and must contain a non-empty string."  Needs a rewrite.  The alt attribute provides a text equivalent for the image button.  Not sure what an "alternative button" is...

*         "A user agent may allow the user to override the resulting autocompletion state<http://www.w3.org/TR/2011/WD-html5-20110525/common-input-element-attributes.html#resulting-autocompletion-state> and set it to always on, always allowing values to be remembered and prefilled), or always off, never remembering values. However, the ability to override the resulting autocompletion state<http://www.w3.org/TR/2011/WD-html5-20110525/common-input-element-attributes.html#resulting-autocompletion-state> to on should not be trivially accessible, as there are significant security implications for the user if all values are always remembered, regardless of the site's preferences."  Implications for cognitive.  Some users will need to set this all the time.  Also, I'm not sure what "trivially accessible" means.  I think it is advice on UI design for the browser.  Should that be in a normative section?  Is the an RFC SHOULD?  Use a different word than accessible.

*         Is list just for making combo-boxes?  Are there other uses?  Examples using <label>foo<input></label> instead of <label for>

*         Note in 4.10.7 says that readonly sometimes makes element immutable, but 4.10.7.2.4 The readonly attribute says "When specified, the element is immutable."

*         "When a control has a pattern attribute, the title attribute, if used, must describe the pattern. Additional information could also be included, so long as it assists the user in filling in the control. Otherwise, assistive technology would be impaired.

For instance, if the title attribute contained the caption of the control, assistive technology could end up saying something like The text you have entered does not match the required pattern. Birthday, which is not useful.

UAs may still show the title in non-error situations (for example, as a tooltip when hovering over the control), so authors should be careful not to word titles as if an error has necessarily occurred."

Wow.  Title must describe the pattern?  Title is last choice for a lot of AT, right?  Shouldn't the pattern be described in the visible label for everyone?

*         Needs discussion
4.10.7.4 Common event behaviors
When the input event applies, any time the user causes the element's value to change, the user agent must queue a task to fire a simple event that bubbles named input at the input element. User agents may wait for a suitable break in the user's interaction before queuing the task; for example, a user agent could wait for the user to have not hit a key for 100ms, so as to only fire the event when the user pauses, instead of continuously for each keystroke.
Examples of a user changing the element's value would include the user typing into a text field, pasting a new value into the field, or undoing an edit in that field. Some user interactions do not cause changes to the value, e.g. hitting the "delete" key in an empty text field, or replacing some text in the field with text from the clipboard that happens to be exactly the same text.
When the change event applies, if the element does not have an activation behavior defined but uses a user interface that involves an explicit commit action, then any time the user commits a change to the element's value or list of selected files, the user agent must queue a task to fire a simple event that bubbles named change at the input element.
An example of a user interface with a commit action would be a File Upload control that consists of a single button that brings up a file selection dialog: when the dialog is closed, if that the file selection changed as a result, then the user has committed a new file selection.
Another example of a user interface with a commit action would be a Date control that allows both text-based user input and user selection from a drop-down calendar: while text input might not have an explicit commit step, selecting a date from the drop down calendar and then dismissing the drop down would be a commit action.
When the user agent changes the element's value on behalf of the user (e.g. as part of a form prefilling feature), the user agent must follow these steps:
If the input event applies, queue a task to fire a simple event that bubbles named input at the input element.
If the change event applies, queue a task to fire a simple event that bubbles named change at the input element.
In addition, when the change event applies, change events can also be fired as part of the element's activation behavior and as part of the unfocusing steps.
The task source for these tasks is the user interaction task source.

*         Why does color support autocomplete?  What does autocomplete on color do?

*         Random Idea: I wonder if there's any way to support validating contrast ratios with color pickers within the same form?  Could adding pattern to color help here?

4.10.8 the button element

*         "The button<http://www.w3.org/TR/2011/WD-html5-20110525/the-button-element.html#the-button-element> element represents<http://www.w3.org/TR/2011/WD-html5-20110525/rendering.html#represents> a button. If the element is not disabled<http://www.w3.org/TR/2011/WD-html5-20110525/association-of-controls-and-forms.html#concept-fe-disabled>, then the user agent should allow the user to activate the button."  Should?
4.10.13 Textarea

*         Anyone see issues with wrap=hard?


4.10.18 association of controls and forms

*         Probably need some wcag techniques and failures here.  Seems like you could get pretty messy associating elements to different forms.


4.10.19 autfocusing a form control
"If the user has indicated (for example, by starting to type in a form control) that he does not wish focus to be changed, then optionally abort these steps."
Should this really be optional?

4.10.21 Constraints
This is really powerful.  Consider how this can be used to improve accessibility, and create WCAG techniques to leverage it.

4.10.22.2 Implicit submissions
"User agents may establish a button in each form as being the form's default button. This should be the first submit button in tree order whose form owner is that form element, but user agents may pick another button if another would be more appropriate for the platform. If the platform supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text field is focused implicitly submits the form), then doing so must cause the form's default button's activation behavior, if any, to be run.
Note:
Consequently, if the default button is disabled, the form is not submitted when such an implicit submission mechanism is used. (A button has no activation behavior when disabled.)

If the form has no submit button, then the implicit submission mechanism must just submit the form element from the form element itself."

This seems like it could cause different submission behavior on different platforms when the user hits enter.  Is that ok?