- From: Sam Ruby <rubys@intertwingly.net>
- Date: Tue, 28 Jul 2009 09:35:58 -0400
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- CC: Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>, Richard Schwerdtfeger <schwer@us.ibm.com>, Steve Faulkner <sfaulkner@paciellogroup.com>, wai-liaison@w3.org
Laura Carlson wrote: > > The procedure proposal was made in good faith to ensure that > accessibility related issues within HTML5 are dealt with in an > efficient and constructive manner utilizing the relevant resources and > expertise available. We are not trying to change the rules and have > proposed nothing to that effect. We have simply proposed a procedure > to make the rules clearer. I must be missing something that is extremely obvious to the people who are supporting this proposal. You are not changing the rules, but are proposing a procedure (but not a rule?) that somehow would make things clearer. Can you tell me exactly, and with precision, what this proposal, if adopted, would change in how we approach the summary attribute and making canvas accessible? From my perspective, on the summary attribute, Ian is the only one who has put forward a concrete and complete proposal, and that proposal: 1) Approaches the subject with a goal of making HTML 5 the best solution for everybody, including people with disabilities, and including people without disabilities. 2) Was based on the concrete use cases provided, and addressed the any and all accessibility functional requirements that were clearly identified. 3) From my perspective #3 is largely redundant with #2 and #4, but I do believe the the use cases provided were listened to and that clarification was requested. 4) It seems clear enough that the PFWG doesn't feel that what was provided was adequate, but it is equally clear to me that Ian has asked for input and has not received it. In short, I don't see how the proposal fixes anything. And I believe that the reason why that is the case is because the proposal assumes that there is only one "right" solution, and that the "right" solution is the one that we should be adopted. I disagree on both counts. This is not a physics problem, it is an engineering problem. Worse: it is a social engineering problem. In such problems, there often are multiple solutions, or no solutions. And when there are no solutions, one must decide which constraint to violate and how to compensate for this violation. Once you go down this path, you again find that there are multiple solutions and the selection criteria between these solutions is necessarily subjective. Even if there was only one right solution, it may not be one that people are willing to follow. I'll use shorthand for the next statement: suffice it to say that charset=iso-8859-1 and RFC 3023 are both works of fiction at this point in time. I (or others) can explain what I mean, but the message is that a right solution that nobody follows is no solution. The question we need to address is not whether the explicit marking of summary as obsolete is the right technical solution, but is it a work of fiction; i.e., is it advice that people are willing to follow? If not, it may be both right and silly. To find a solution that isn't silly, what we need at this point isn't more rules or more procedures or more use cases. No, what we need is a simple, common sense, down-to-earth, concrete proposal that people can rally behind. I could do a similar level of analysis for canvas accessibility, but this email is already way too long. Suffice it say that I don't believe there is anybody who believes that what currently is spec'ed is ideal or meets all requirements. It simply is the best concrete proposal that anybody has put forward to date. And despite setting a rather low bar, to date nobody has provided any better ideas. And that is not due to a lack of having a shared goal. And not due to a lack of asking for advice from the PFWG. And not due to a lack of interest in asking for clarifications. And not due to a lack of asking what functionality is needed. - Sam Ruby
Received on Tuesday, 28 July 2009 13:36:44 UTC