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 10448 - Consider broadening the set of allowed roles for command elements
Summary: Consider broadening the set of allowed roles for command elements
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
: P1 major
Target Milestone: ---
Assignee: steve faulkner
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf, aria, TrackerIssue
Depends on:
Blocks: 10066
  Show dependency treegraph
 
Reported: 2010-08-26 10:19 UTC by Maciej Stachowiak
Modified: 2013-01-21 13:23 UTC (History)
8 users (show)

See Also:


Attachments

Description Maciej Stachowiak 2010-08-26 10:19:00 UTC
Command-type elements such as buttons or links are often used interchangeably by authors. This has been reported previously for the <a> element but is a more general issue. In addition to misuses that are actually common for authors, the following suggested additional roles follow the ARIA role taxonomy; command elements are allowed child, parent and sometimes sibling roles within the taxonomy.


a (that represents a hyperlink -> button, link, menuitem, menuitemcheckbox, menuitemradio, radio, slider, scrollbar, progressbar
area (that represents a hyperlink -> button, link, menuitem, menuitemcheckbox, menuitemradio, radio, slider, scrollbar, progressbar
button -> button, link, menuitem, menuitemcheckbox, menuitemradio, radio, slider, scrollbar, progressbar
input type=button-> button, link, menuitem, menuitemcheckbox, menuitemradio, radio, slider, scrollbar, progressbar
input type=checkbox -> button, link, menuitem, menuitemcheckbox, menuitemradio
input type=image -> button, link, menuitem, menuitemcheckbox, menuitemradio, radio, slider, scrollbar, progressbar
input type=radio-> button, link, menuitem, menuitemcheckbox, menuitemradio, radio, slider, scrollbar, progressbar
Comment 1 Ian 'Hixie' Hickson 2010-08-26 19:33:59 UTC
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: Rejected
Change Description: no spec change
Rationale: Most of these changes make no sense. For example, why would an <input type=checkbox> ever be considered equivalent to a role=menuitemradio? Or an <input type=radio> equivalent to a role=progressbar?

If there are specific cases that should be considered specifically, please file individual bugs for those issues.
Comment 2 steve faulkner 2010-08-26 19:54:17 UTC
not all of the following are correct here are the corrections: 

input type=radio -> radio or menuitemradio
input type=checkbox -> checkbox or menuitemcheckbox


(In reply to comment #0)
> Command-type elements such as buttons or links are often used interchangeably
> by authors. This has been reported previously for the <a> element but is a more
> general issue. In addition to misuses that are actually common for authors, the
> following suggested additional roles follow the ARIA role taxonomy; command
> elements are allowed child, parent and sometimes sibling roles within the
> taxonomy.
> 
> 
> a (that represents a hyperlink -> button, link, menuitem, menuitemcheckbox,
> menuitemradio, radio, slider, scrollbar, progressbar
> area (that represents a hyperlink -> button, link, menuitem, menuitemcheckbox,
> menuitemradio, radio, slider, scrollbar, progressbar
> button -> button, link, menuitem, menuitemcheckbox, menuitemradio, radio,
> slider, scrollbar, progressbar
> input type=button-> button, link, menuitem, menuitemcheckbox, menuitemradio,
> radio, slider, scrollbar, progressbar
> input type=checkbox -> button, link, menuitem, menuitemcheckbox, menuitemradio
> input type=image -> button, link, menuitem, menuitemcheckbox, menuitemradio,
> radio, slider, scrollbar, progressbar
> input type=radio-> button, link, menuitem, menuitemcheckbox, menuitemradio,
> radio, slider, scrollbar, progressbar
Comment 3 Maciej Stachowiak 2010-08-29 01:35:21 UTC
(In reply to comment #2)
> not all of the following are correct here are the corrections: 
> 
> input type=radio -> radio or menuitemradio
> input type=checkbox -> checkbox or menuitemcheckbox

My mistake, Steve. I filed bug 10487 for these two, since they seem like a different and simpler case.

Let's have this bug represent only the following:

a (that represents a hyperlink -> button, link, menuitem, menuitemcheckbox, menuitemradio, radio, slider, scrollbar, progressbar
area (that represents a hyperlink -> button, link, menuitem, menuitemcheckbox, menuitemradio, radio, slider, scrollbar, progressbar
button -> button, link, menuitem, menuitemcheckbox, menuitemradio, radio, slider, scrollbar, progressbar
input type=button-> button, link, menuitem, menuitemcheckbox, menuitemradio, radio, slider, scrollbar, progressbar
input type=image -> button, link, menuitem, menuitemcheckbox, menuitemradio, radio, slider, scrollbar, progressbar

Essentially these makes buttons and links interchangeable for ARIA purposes, and allow either to be used as a variety of other roles, including scrollbars, progress bars, sliders, etc.
Comment 4 Ian 'Hixie' Hickson 2010-09-07 08:32:45 UTC
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: Rejected
Change Description: no spec change
Rationale: Half of this proposal still makes no sense. Links as progress bars? Buttons as scrollbars? Image map areas as range controls? Heck, even the link as button thing makes no sense to me. If we want a button-like UI to look like a link for visual users, why would we then go out of our way to turn them back into buttons for AT users? Won't that just confuse users when tech support people say "now click the link" and the AT says it's a button?

I really don't understand the motivation here. How do any of these suggestions improve accessibility?

See also http://lists.w3.org/Archives/Public/public-html/2010Jun/0392.html
Comment 5 Leif Halvard Silli 2010-10-02 07:05:07 UTC
(In reply to comment #4)

> I really don't understand the motivation here. How do any of these suggestions
> improve accessibility?

Consentrating on the anchor element:  It improves accessibility by sending relevant information to the user.

An <a> element that doesn't take you to another location but instead activates a player is better presented to AT as a button. 

That is how Yahoo's media player works (http://mediaplayer.yahoo.com/)
The Yahoo Media Player is simply a script which turns all the MP3 links into player buttons.
And it was recently hailed as the most accessible solutio for uas which doesn't support <audio>:
http://terrillthompson.blogspot.com/2010/09/quest-for-accessible-flash-mp3-player.html
Comment 6 steve faulkner 2010-10-12 09:05:06 UTC
added to HTML WG Issue http://www.w3.org/html/wg/tracker/issues/129
Comment 7 Michael Cooper 2010-12-15 14:42:05 UTC
This is part of HTML-ISSUE-129. There is some debate taking place actively. Therefore bug triage sub-team thinks this is a HTML A11Y TF priority. Adding a11ytf keyword and assigning to Steve Faulkner for ARIA mapping sub-team.
Comment 8 steve faulkner 2013-01-21 13:23:32 UTC
resolved by http://www.w3.org/html/wg/tracker/issues/14