RE: summarization information delivery options: attribute or element

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":

	"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.  

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?   


>
> 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?


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

	"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?

JF

Received on Monday, 1 March 2010 20:12:15 UTC