- 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:47 UTC