Re: summarization information delivery options: attribute or element

Hi Gregory,

Excuse the top post, but I want to talk generally about your email
about whether summary should be an attribute or an element. Firstly,
thank you for your considered email explaining why you think summary
would be better as an element. I agree that this needs to be addressed
before coming up with solutions.

I don't believe that summary should be an element, as it's supposed to
be concise overview of the structure for people who are unable to
determine the structure visually. If the reason for making it an
element is that authors can provide richer markup, then I think we're
definitely outside the territory of a concise overview of the
structure of a data table, and more into summary being a long
description of the table. If the consensus is that the summary should
in fact be a long description of the table, then I don't think
anything special is required. It should just be provided with markup
so that everyone has access to it, and referenced with
aria-describedby.

With regards to internationalisation. Whenever we do
internationalisation, the only difficulty with using attributes (and
it's a fairly trivial problem to solve) is when the attribute value is
in a different language to the element its on. I can't imagine a
scenario where the language of the summary attribute would be
different from that of the data table itself. Usually, the content of
the data table is generated for a specific language depending on the
language of the page or the element (in this case the data table).

Anyway, it will be interesting to see whether people regard the
summary attribute as a means of providing a concise overview of the
structure, or whether they regard it as a long description of the
table.

Cheers,

Gez


On 25 February 2010 17:36, Gregory J. Rosmaita <oedipus@hicom.net> wrote:
> aloha!
>
> i'm sending this to the list because these are the points i made at
> today's HTML A11y TF telecon, but which i didn't minute as i can't
> type and talk and chew gum at the same time (i know, next time, lose
> the gum)
>
> when it came to the first question of the details versus summary survey,
> i could not select an option because i support replacing the summary
> attribute with a summary element, and i would have liked the first
> question of this survey to have been a choice between summary as an
> attribute and summary as an element;
>
> if authors and developers are used to the concept of using the summary
> attribute for the TABLE element in HTML4, why not simply change summary
> from an attribute to an element (regardless of what that element is
> named)? as an element, summary provides those who have actually used the
> summary attribute, with capabilities which were not possible when summary
> was an attribute; one of the internationalization issues authors have
> faced when using the summary attribute is how to provide multi-lingual
> versions of information which is limited to an attribute value, without
> the possibility of programmatically indicating natural language switches,
> through the use of the lang attribute;
>
> if authors are as ignorant of the HTML4 attribute summary as some have
> claimed, then they won't be confused by an HTML5 element named summary
> which is the child of CAPTION;
>
> bottom line: in order for a summarization of a table's contents to be of
> real utility, the summary's delivery mechanism needs to be able to
> support "rich content" -- that is, markup, such as use of the lang
> attribute to programatically indicate a natural language switch where
> multi-lingual versions of the summarizing information is required);
> ideally, such information should, therefore, be contained in an element,
> to ensure that an author can use standard markup to annotate/describe the
> table (such as ABBR, DFN, etc.), although i would NOT allow anchors or
> other interactive elements to be used in the summary/summarization
> element;
>
> whatever the summary element's name, it should be a child of CAPTION, and
> should be considered a strong "hint" by the author, which is NOT rendered
> by default, thereby making it possible for multiple non-mutually
> exclusive alternative renderings of the summary's contents through user
> agent configuration; any "button" type mechanism could be one option
> offered by a user agent, just as user agents should allow users to flag
> FORM controls without explicit "submit" mechanisms and provide a UA user
> interface control for any FORM control that lacks an explicit "submit"
> mechanism;
>
> proposed next steps:
>
> the task force needs to:
>
> 1. ascertain the position of working group members on summary as an
>   attribute versus summary as an element;
>
> 2. if the task force agrees on a summarizing element, then the various
>   proposals for the specific name and mechanics of the summarization
>   element would be the next deliverable of the task force in regards
>   the TF's feedback on the summary 1ssue;
>
> 3. i'm not so opposed to DETAILS as an element name, but wonder if the
>   change in nomenclature is necessary -- what authors and users have
>   been asking for is the ability to use a limited set of markup tags
>   within the summarizing text, so as to indicate natural language
>   switches, the expansion for an abbreviation/abbreviated form,
>   emphasis markers, but NO interactive elements
>
> my 2 cents, american, gregory.
> -------------------------------------------------------------
> ADVICE, n.  The smallest common coin.
>                    -- Ambrose Bierce, The Devil's Dictionary
> -------------------------------------------------------------
>             Gregory J. Rosmaita, oedipus@hicom.net
>  Camera Obscura: http://www.hicom.net/~oedipus/index.html
> -------------------------------------------------------------
>
>
>



-- 
_____________________________
Supplement your vitamins
http://juicystudio.com
http://twitter.com/gezlemon

Received on Thursday, 25 February 2010 22:49:03 UTC