[Bug 10710] Require controls to have programatically associated names

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10710

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ian@hixie.ch
         Resolution|                            |FIXED

--- Comment #1 from Ian 'Hixie' Hickson <ian@hixie.ch> 2010-09-29 07:27:20 UTC ---
> Proposal: Require controls to have programatically associated names.

As a side note, I don't think programmatically means what you think it means.

>    * Require "a href" and "button" to have descendant non-whitespace text
> content (either in a text node or an "alt" attribute) that names the control.

Already required.

>    * Require image "input" elements to have a non-whitespace "alt" attribute
> that names the control.

Already required.

>    * Require reset, button and submit "input" elements to have a non-whitespace
> "value" attribute that names the control.

Why for reset and submit? Are the defaults not enough?

Added it for button.

>    * Require "input" elements of other types (except "hidden") to have a
> programmatically associated "label" element with descendant non-whitespace text
> content (either in a text node or an "alt" attribute) that names the control.

This isn't practical, unfortunately. There are many use cases for elements that
have no label. For example, a grid of checkboxes in a table, where each cell
has a row and column header but the checkbox itself doesn't have any explicit
label (not even for users of visual user agents).

>    * Require radio button groups to have a programmatically associated "legend"
> element that names the control.

Already required assuming you mean radio groups in fieldsets, which is the only
place legend is relevant.

>    * Require "select" elements to have a programmatically associated "label"
> element with descendant non-whitespace text content (either in a text node or
> an "alt" attribute) that names the control.

This isn't practical for the same reason as labels for inputs.

>    * Require "optiongroup" elements to have a non-whitespace "label" attribute
> that names the group.

Assuming you mean optgroup, this is already required.

>    * Require "option" elements to have either a non-whitespace "label"
> attribute or descendant non-whitespace text content (either in a text node or
> an "alt" attribute that names the option.

This is not practical; authors sometimes use blank <option> elements as
separators or to represent the no-selected-value state.

>    * Require "command" elements to have a non-whitespace "label" attribute
> (note the spec currently requires non-empty only) that names the command.

Already required (modulo note below).

>    * Require nested "menu" elements to have a non-whitespace "label" attribute
> that names the submenu.

Unnecessary; a menu with no label doesn't make a submenu, just a subsection.


As a general note, the spec doesn't always explicitly require labels to be
non-empty or have non-whitespace content, but as a practical matter such
requirements usually just lead to authors who do not want to provide labels
finding more subtle ways of evading the requirement, e.g. using a non-breaking
space, or a period, or changing the styles to be invisible, and thus it is in
fact a bad idea to explicitly require non-blank values like that. It's better
to let authors give a blank value and then let tools (like screen readers)
detect that case and substitute a default label. The alternative is that the
tools can't figure out that the label is bogus and end up making the page less
accessible. For authors who do want to do the right thing, requiring the
attribute be present is sufficient to have them realise they'd forgot to
provide it.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given below
Rationale: see response above

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 29 September 2010 07:27:24 UTC