Re: summarization information delivery options: attribute or element

John Foliot wrote:
> Lara Carlson wrote:
>   
>> The danger of broadening the scope and distorting the
>> purpose of @summary to include everyone is that discussions can
>> quickly degenerate and lose focus, rather than addressing the initial
>> use case.
>>     
>
> If we look to HTML4's definition for why @summary is/was created, it
> states: 
>
> "This attribute provides a summary of the table's purpose and structure
> for user agents rendering to non-visual media such as speech and Braille."
>
> As I read this, there are 2 requirements intertwined here: that a
> mechanism be provided to deliver "...a summary of the table's purpose and
> structure", and that it be targeted to "...user agents rendering to
> non-visual media such as speech and Braille."
>
> So the question becomes, do we continue to ghettoize content for one
> user-group, or do we learn by our mistakes and seek to apply a more
> broadly applicable Universal Design approach? I point, yet again, to WCAG
> 2's requirement for mechanisms that ensure "Robustness":
>   
Interesting, I never thought that providing an additional assistance is 
demeaning, if I read your use of the word "ghettoize" correctly.


> 	"WCAG 2 Principle 4: Robust - Content must be robust enough that
> it can be interpreted reliably by a wide variety of user agents, including
> assistive technologies." 
>
> I argue that creating content that is only accessible to screen reading
> technologies goes against that requirement, as it excludes other types of
> assistive technology (screen magnifiers) and other common user-agents
> today.  It is an simple solution that is directed at a single user-base,
> and flies in the face of WCAG 2's 'spirit' of inclusiveness.
>
> I might also suggest that since WCAG2 is significantly more 'current' than
> HTML4 (by a decade), the 'intent' of the broader WAI initiative here is to
> move towards Universal Design solutions (at least, that is my take based
> upon interpretation of Principle 4).
>
>
>   
>> Access for people with disabilities is essential. This does not mean
>> that features should be omitted if not all users can fully make use of
>> them but rather that alternative/equivalent mechanisms must be
>> provided where needed. People with disabilities face some unique
>> challenges and barriers (and are only too often systemically
>> excluded). To ensure that such exclusion does not occur in HTML 5, it
>> does need to contain some features that are *only* of use to people
>> with certain disabilities, if functional equivalents can't provided.
>>     
>
> Both Cynthia's and Leif's ideas provide the *functional equivalents*
> required - Leif's proposal even more specifically than Cynthia's proposal.
> However both of those proposals extend and build upon the limited
> functionality of @summary as an attribute.  
>   

If I read Cynthia's proposal correctly, her change proposal was, 
specifically to replace @summary. Cynthia, do you feel this is a correct 
understanding on my part.

So it's not really an extension, it's a replacement.

I'm still trying to parse Leif's proposal.

> It can be argued that user-agents could be modified to expose @summary
> content, but if we ask the browsers to make a more 'universal' exposure
> and output facility, would it not make sense to allow authors to be able
> to script and style this output as well?   
>
>   
@summary as it exists now is scriptable. I imagine if the nature of the 
table structure changed dynamically, the @summary attribute could be 
updated.

Styling probably doesn't make a lot of sense for something that's 
specifically non-visual. At least, not visual styling. Were you thinking 
of aural styling?

>   
>> Example: The image in the img element is not perceivable by blind
>> users. It has mechanisms for adding text alternatives. No one is
>> arguing to make alt text visible by default or add a button for it. 
>>     
>
> HANG ON!! Right now, if images are 'turned off' in a browser, the fallback
> is to display the alternative text: a 'solution' that aids more than just
> the non-sighted. In a text-only browser the 'default' is to show the alt
> text if provided (Lynx). So yes, if you can see the image and your
> user-agent supports images, that is the default rendering; however the alt
> text is not discarded in any way, and is in no way intended for
> non-sighted users only! The argument that alt-text be the default in a
> text-only browser is a non-argument, who would argue against it?
>
> (Secondly, numerous FF 'testing toolbars' today have a 'button' that will
> expose or visually render the text values for @alt on demand: Web
> Developer's toolbar, WAVE toolbar, iCITA's Firefox Accessibility
> Extension, etc. - so there alone is the use-case for an 'exposure method',
> be it a button or other user-activated mechanism) 
>
> @longdesc is an 'on-demand' textual equivalent that screen-reading
> technology can access, as can sighted users if they choose to by using
> Patrick's tool, and in the latest builds of Opera- certainly in the 10.10
> and later releases, as part of the contextual dialogue box (a.k.a Right
> click). If we remain with @summary, do we also ask/demand that user-agents
> provide this functionality?
>
>   
If the person is allowed to turn off the HTML table, I would assume it 
makes sense to provide this information. Other than a text-based 
browser, though, I'm not aware of any user agent that allows people to 
turn off HTML tables.

As for something like Lynx, well, most people would be in somewhat the 
same boat when it comes to what Lynx will do a complex table. Typically, 
Lynx just serializes the table. If anything the summary attribute would 
be extremely helpful for everyone using Lynx, but I'm not sure what it 
does with the attribute.

>   
>> A
>> text alternative for an image is not rendered with the image. Text
>> alternatives are there for people who cannot perceive the image. The
>> same principle applies to the summary attribute.
>>
>> The reason for retaining @summary as valid and conforming is to ensure
>> a group people with disabilities, blind and non-visual users, have a
>> table summary mechanism and are not shut out.
>>     
>
> Can we please stop already with the 'Valid and Conforming' FUD?  Both
> Cynthia's proposal and Leif's draft specifically state that @summary would
> remain conformant: 
>
>   

Can I suggest that "FUD" is a less than helpful term?

> 	"Make summary obsolete but -->conforming<-- (in other words,
> deprecated). Authors who need to support non-HTML5 browsers and Assistive
> Technology -->would be able to continue to use summary and validate<-- to
> HTML" 
> (Cynthia's Proposal:
> http://www.w3.org/WAI/PF/HTML/wiki/Details_element_as_a_replacement_for_su
> mmary_attribute%2C_Feb_15%2C_2010)
>
> 	"summary="*" remains -->valid<--." "Conformance Classes Changes:
> Validators -->must accept<-- the summary attribute."
> (Leif's proposal:
> http://www.w3.org/html/wg/wiki/ChangeProposals/tableSummaryProposal)
>
> It cannot be clearer than that: @summary will be 'safe' in the next HTML
> version if either of these proposals go through. So the question becomes,
> do we remain with the status quo, or do we strive to do better?
>
>   

Actually, I'm with Sam Ruby[1] -- the whole obsolete but conforming 
concept is confusing, and is going to cause more problems than solve, so 
I, for one, don't consider applying to @summary to be useful. I also 
have a bug on the "obsolete but conforming" concept. I have a high 
degree of confidence that this one will end up WONTFIX, and will need to 
be addressed through the decision process.

Now Lief does agree that @summary is still conforming, and not obsolete. 
But he also recommends an extension, with an additional suggestion of a 
second caption element, to act as table summary. I'm not sure, though, 
that his new table summary is the same type of summary as the existing 
@summary attribute.

Regardless of my understanding of this second table summary, the idea of 
redefining the existing element (caption), including its default 
behavior and relationship to the html table, breaks backwards 
compatibility. You can check with Henri to confirm this, if you wish.

> JF
>
>
>   

Shelley

[1] http://lists.w3.org/Archives/Public/public-html/2010Feb/0764.html

Received on Monday, 1 March 2010 21:47:27 UTC