RE: [html] Summary draft

Cynthia Shelly wrote:
> The highlights of this draft are this
> 1) It leaves the summary attribute in, using the HTML 4.01 text but 
> edited to fit the sentence format of the HTML 5 spec.

Please note: In the explanatory paragraph there is a typo - "...provide
infomration about relationships" (s/b information)

> 2) It adds summary to the content attributes and DOM interface. I 
> added it at the end of the DOM interface, not sure that's the right 
> style.  I also added it to the table API as table.summary, 
> table.createSummary, and table.deleteSummary, but I'm not sure that's 
> really needed.  Perhaps normal attribute accessors are enough?
> 3) It adds some text and a code example donated by Matt May from his 
> and Wendy Chisholm's book Universal Design for Web Applications.
> I still need to add the working table example, but do have the code 
> snippet in there.

Thanks to Matt and Wendy for allowing reuse here!

> 4) It describes at some length when to use summary vs. the techniques 
> in Ian's draft.  This basically boils down to using summary for things 
> that are obvious if you see them, and confusing if you can't.  Ian's 
> examples are retained with minor edits to the surrounding text.  The 
> text is still a bit clunky, but I think it suffices to open the dialog.
> I also notice that there is a similar example under the caption 
> element. It reads a bit strangely to have it in two places, and would 
> be nice to consolidate them. 
> I also plan to submit Ian's examples to WCAG, but haven't yet done 
> that.

I think that this is an important step in the larger process.  There are
indeed some new techniques that HTML5 is bringing to the accessibility
equation that deserve to be added to the Techniques for Success Criteria, as
this exercise has highlighted.  What is the next step to achieve this?

> 5) It adds some discussion of Platform Accessibility APIS and 
> programmatically determined under WCAG, and when ARIA might be needed 
> to make either of these work as expected.  I also added 
> aria-describedby to the example that uses a paragraph before the 
> table.  See for a definition 
> and discussion of programmatically determined under WCAG.

Is this going to cause any concern given that ARIA has not yet been formally
integrated into the HTML5 specification?  While I believe that this is
important and should be included here, I'm just questioning whether this is
going to introduce a whole other round of 'discussion' at this time?

> 6) It adds a section on Guidance for conformance checkers, which 
> suggests warning when any of these techniques is used, describing the 
> difference between summary and the others, and also for any table 
> which uses none of the techniques.  This essentially means warning on 
> every table, which I'll admit seems less than ideal.  This is modeled 
> after the guidance for alt in the image attribute.    I think this 
> allows removing summary from the obsolete section, but still gives the 
> opportunity to provide guidance to authors about when to (and not to) use
> nce-checkers-0

I have suggested before that I believe this to be a good thing.  Conformance
checkers should be author configurable to toggle accessibility guidance on
or off as required: in fact, one of my current favorites, the Firefox HTML
Validator (, allows for exactly
that, so it should not be hard to develop other tools with similar
functionality (the WDG validator has a similar feature which links to
definitions and explanations of the various html elements).

What is wrong with warning authors that tables can be problematic?  After
all, they can be... 

> 7) It removes summary from the obsolete section

Unequivocally!  +1

> I'll be sending this to the HTML list, but wanted to get a bit of a 
> sanity check and some initial discussion here first.
> Thoughts?

Bravo! Thanks for this Cynthia.


Received on Saturday, 15 August 2009 05:09:40 UTC