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.

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

(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.

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

(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

added to HTML WG Issue http://www.w3.org/html/wg/tracker/issues/129

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.

resolved by http://www.w3.org/html/wg/tracker/issues/14