RE: FW: CHANGE PROPOSAL: Table Summary

Cynthia Shelly wrote:
> 
> 
> <cyns>
> This says to show it by default *in authoring scenarios*.  For a current
> browser, that would generally mean on things that are content-editable.
> For a visual authoring tool, it would render in the editing/design
> surface, but not in previews.  I'd like to get general agreement here
> that this is a good idea, and then I'll happily take it to the IE team
> and various authoring tools teams.  It sounds like you think it's a good
> idea.  Is that correct?  Anyone else?  Anyone hate it?
> </cyns>

I believe it is both a good idea, and an idea that has been floating
around in various forms, suggested by various folks, including both myself
and as I recall Matt May.  It would be even *better* if the browsers/UI
allowed the end user to toggle 'display' on or off as determined by any
given user.  Previously I had suggested a 'right-click' kind of
functionality (knowing full well that this is a windows-centric
suggestion, but a similar type of functionality could be achieved in all
of the major OSes)


> <cyns>
> However it is implemented, the text providing the accessible name is not
> going to be visible. It just doesn't make sense in the design. 

And this particular point needs to be strongly underscored.  Design is
important.  Design cannot always be dictated by accessibility (sad truth),
but by the same token, we should be ensuring that no matter the 'design'
we can implement accessibility.  Somehow I just feel that this point is
being lost in this discussion (and others - like @longdesc, where the
'alternative' is to use aria-describedby pointing to a paragraph of text
that is off screen using CSS - seems like a circuitous route to be
achieving what @longdesc essentially delivers by design).

> 
> <cyns>
> If you're ok with explanatory text being hidden in <details>, why do you
> object to it being hidden in summary?  How do you see them as different?
> These seem the same to me, except that summary has legacy support, so
> I'd be happy to better understand your thinking here.
> 
> There's a difference between recommending using visible text and issuing
> a validation warning when you using hidden text.  It's the validation
> warning that people object to. 

Agreed!  Warning suggests that you are doing something "bad", and so far
many are simply not convinced that using @summary is "bad" - it might not
be ideal, but there are many times when using @summary will be good, if
not optimum.

> It says that using summary is a bad
> thing to do, and for people who spend a great deal of time and effort
> convincing developers to do accessibility work, including adding
> summary, this makes life very difficult.  I suspect that most of the
> objections would go away if the validation warning went away, and there
> was just advisory text saying that it's better to use visible text when
> you can.

Hear, hear!

> 
> What if we got rid of the validation warning, positioned <details> and
> @summary as mechanisms for including non-visible text, and then
> discussed the value of including visible text, and situations where
> authors might not be able to?  This seems like something we could all
> live with, which is all that's needed for consensus.
> </cyns>

+1

JF

Received on Thursday, 10 December 2009 00:50:45 UTC