- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 04 Aug 2009 15:43:00 -0700
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: HTML WG <public-html@w3.org>
On Aug 4, 2009, at 2:50 PM, Charles McCathieNevile wrote: > On Tue, 04 Aug 2009 14:03:37 -0400, Maciej Stachowiak > <mjs@apple.com> wrote: > >> >> I believe there are two different value systems in conflict in the >> summary dicussion: >> >> A) HTML5 should guide authors toward choices that will result in >> the best accessibility outcomes, based on reasoning from the best >> evidence we have available. Argument that are not outcome-driven or >> evidence-based are seen as irrelevant, from this point of view. >> >> B) If HTML5 provides advisory guidance on how to use HTML >> constructs to make accessible documents, it should not directly >> contradict other W3C guidance on accessibility. It's ok, from this >> point of view, to expand on guidance, but direct contradiction is >> seen as giving an inconsistent message. > > Actually, I think this is a false dichotomy, and is not an accurate > representation of the differences that lead to disagreement. > However, that fortunately doesn't matter in deciding on the proposal > to resolve the problem at hand. So... OK, I didn't mean to present these views either as mutually exclusive or as covering everyone's point of view. > (If there are similar mandatory warnings for canvas with no clear > fallback content, a lack of @alt, the font element, and various > other things that are bad style, I might move to support it. I don't > see it as feasible to reach that agreement, so I am happy to simply > compromise on this point). Mandatory warnings might be appropriate for other constructs that are error-prone or bad style, without necessarily being always wrong. But I'd rather not tie that up with this particular issue. Thanks for being willing to compromise. > >> 4) The goal of HTML5 in this case is to promote good accessibility >> outcomes based on evidence. Telling someone that the technique they >> are using is dumb or wrong, even by implication, is not necessary >> to serve this goal, providing relevant information is what serves >> the goal. Thus, the spec will be changed to avoid disparaging >> summary in unnecessary ways. For example, describing summary="" >> only in the "obsolete features" section and not in the "table" >> section gives the appearance of disparagement. There may not be an >> evidence-based reason to stop doing this, but I don't see an >> evidence-based reason to continue doing it, either. So, why >> needlessly give offense if the goal can be served either way? > > Agreed. The obvious actionable outcome being > > 4a) summary will be listed in the table section, with examples > provided for what should and should not be in it. > >> 5) HTML WG will propose a WCAG2 Techniques update to the >> appropriate working group of WAI (is it PFWG or WCAG WG?) to better >> reflect HTML5 features for describing tables. I can draft a message >> to communicate this, but I'd like to request: >> (a) John Foliot as a co-signer (assuming he agrees with the >> language), since he said he'd support an effort to update WCAG2, >> and I'd like to make clear that this is a coordination effort, not >> an attempt to pick a fight. >> (b) I'd like to ask for some official blessing from the HTML WG >> for this message, since WAI apparently takes official input from >> Working Groups more seriously than input from individuals. > > This makes sense... although getting a blessing must depend on the > actual message text. > > Thanks for this proposal. It includes a bunch of stuff that I think > is good, nothing I think is new, and a few things I think are bad. > But overall I can live with it. Thank you for your feedback. Regards, Maciej
Received on Tuesday, 4 August 2009 22:43:40 UTC