- From: <bugzilla@jessica.w3.org>
- Date: Wed, 29 Sep 2010 07:27:21 +0000
- To: public-html-bugzilla@w3.org
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 the QA contact for the bug.
Received on Wednesday, 29 September 2010 07:27:26 UTC