This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10710 - Require controls to have programatically associated names
Summary: Require controls to have programatically associated names
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11ytf
: 13563 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-09-24 06:45 UTC by Benjamin Hawkes-Lewis
Modified: 2011-08-15 16:39 UTC (History)
8 users (show)

See Also:


Attachments

Description Benjamin Hawkes-Lewis 2010-09-24 06:45:04 UTC
WCAG 2.0 1.1 requires: "If non-text content is a control or accepts user input, then it has a name that describes its purpose."

Including controls in the page without providing them with such names is a common antipattern. For example, I often see:

   * links and buttons whose only "content" is provided by an "alt"-less "img" or a background image
   * form controls without labels.

I have not yet seen a use case for having a control without a programatically associated name, whereas the omission of such names does considerable damage to the accessibility, media independence, and restylability of the web.

Proposal: Require controls to have programatically associated names.

Specifically:

   * 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.
   * Require image "input" elements to have a non-whitespace "alt" attribute that names the control.
   * Require reset, button and submit "input" elements to have a non-whitespace "value" attribute that names the control.
   * 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.
   * Require radio button groups to have a programmatically associated "legend" element that names the control.
   * 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.
   * Require "optiongroup" elements to have a non-whitespace "label" attribute that names the group.
   * 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.
   * Require "command" elements to have a non-whitespace "label" attribute (note the spec currently requires non-empty only) that names the command.
   * Require nested "menu" elements to have a non-whitespace "label" attribute that names the submenu.

(If I've missed out controls or HTML-native ways to associate them with names, corrections welcome.)
Comment 1 Ian 'Hixie' Hickson 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
Comment 2 contributor 2010-09-29 07:29:02 UTC
Checked in as WHATWG revision r5550.
Check-in comment: Require label for <input type=button>
http://html5.org/tools/web-apps-tracker?from=5549&to=5550
Comment 3 Joshue O Connor 2010-10-12 15:48:55 UTC
The Bug Triage Sub Team wants to work on this. We want to investigate the issues raised and the proposed solution.
Comment 4 Anne 2011-08-15 16:39:11 UTC
*** Bug 13563 has been marked as a duplicate of this bug. ***