[Bug 10448] Consider broadening the set of allowed roles for command elements

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


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #4 from Ian 'Hixie' Hickson <ian@hixie.ch>  2010-09-07 08:32:45 ---
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

-- 
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 Tuesday, 7 September 2010 08:32:50 UTC