RE: summarization information delivery options: attribute or element

Shelley Powers wrote:
> 
> Interesting, I never thought that providing an additional assistance is
> demeaning, if I read your use of the word "ghettoize" correctly.

You did not.

Please do not misrepresent or misunderstand my position. I am all in favor
of providing the maximum user experience to all users, regardless of
ability/disability, and if that means providing additional assistance,
then we should do so.

By ghetto-ization I am speaking of a technique that, by its very
construct, is targeted at one user-group, and one user-group alone: blind
users. Not low vision users, not cognitively impaired users, in fact *no
other* user-group that I can think of beyond blind users. It is, in some
ways, one more reminder of their differences, rather than their
commonality with other users: in the physical world it's like the
accessible entrance to the restaurant, as long as you don't mind taking
your wheelchair to the back entrance and roll in via the kitchen... (It
also presumes that the *ONLY* users who need a prose "purpose and layout"
description is the blind - another perspective that I reject as
short-sighted and false; the one absolute we can presume is that each user
is unique, with unique needs, wants and requests). 

I also reject the idea that this type of content, if in fact important for
other user-groups, should always be plainly visible on the page. The
reality today is that conflicting business requirements will struggle hard
with that requirement, regardless of its perceived value: this argument
has been long discussed with the larger HTML WG and the editor. Thus a
means that natively 'hides' the prose in user-agents until requested is a
stated need if we are to understand the graphic designer community: yes we
could push all of this off on CSS, but I believe that it would simply
reduce the number of instances that we would see this - it's more work
effort on the author.

If we must provide Accommodation, then let's do so.  However if we can
find a Universal Design solution that addresses the core need of the blind
users elegantly, but also serves to improve the user experience for other
users, then that is my preference. I suggest that both Cynthia's and
Leif's proposals seek to do just that. After digesting Leif's proposal
briefly, I am now at a point where I am weighing both equally. I do know
that maintaining @summary as it is from HTML 4 does some users a
disservice, and is personally my least favored solution moving forward.


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

Semantic hair splitting IMHO. (I will let Cynthia respond with her own
thoughts)

What I see is Cynthia's (and Leif's) proposal seeks to take what @summary
was alleged to do (but hasn't succeed in doing BTW) to a new level, a
different level, perhaps (likely?) a better level.  These proposals also
_explicitly_ ensures that @summary remains conformant, certainly to the
*next* version of HTML, which given the current track record of HTML
evolution, will likely be in a decade or more.  We all need to take a deep
breath and acknowledge that *all* of the existing proposals explicitly
'protect' @summary. Please! 



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

Nope, I think here you missed why I stated what I stated.  Laura was
suggesting (as I read it) that @alt was there for non-visual users
(alone), I countered with examples of when it served sighted users as
well. She wrote:

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

(We don't need to argue it - that functionality exists already. It is
exposed when required, using stable methods and techniques, and exposed to
more than one user-group. That, plus the fact that 3rd party tools have
emerged that apply a 'toggle button' to the UI, so that sighted viewers
can read the alt text, and are freely available.) 

Shelley, can you think of one use case where having a description of a
table that explained it's "purpose and structure" would be useful to a
sighted user, but would normally not want to be included in a 'normalized'
or mainstream page-view - i.e. Information that could be delivered on
demand, by demand? Can you envision a scenario where a large site's design
director would argue that the 'real estate' being used for such a
description is way too valuable - that the 80/20 rule should apply? (I've
attended such meetings, and trust me they can get testy - especially since
I advocate for the minority daily.  I had one designer state that they
would "...add accessibility whenever possible" - I was tearing up paper
under the table I was so incensed - y'all know I can get 'upset'
sometimes)

Returning to the question: if the answer is yes, then how do we deliver
that information to the end user?  If we use @summary, then what needs to
be changed in the user-agents to deliver that on-demand-by-sighted-users
function? If that cannot be done, then how else could we produce this type
of functionality?  Leif proposes a caption within a caption if I am to
understand him correctly, and that second caption is pointed to by
aria-describedby.  It's an interesting idea.

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

Can we all agree then that all existing change proposals take measures to
ensure that @summary remains conformant and valid? I have pointed to the
specific sentences in both Leif's and Cynthia's proposals that backs up
this claim; continuing to speak like @summary is going to be trash-canned
moving forward is less than helpful as well. Continuing to insist that
@summary is in peril in HTML5 if either of the alternate proposals is
adopted is simply false, and I am tiring of hearing that assertion.

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

Here, we are in agreement.  We still need 'deprecated' as a transition
path moving forward.  If we get 'deprecated' then I for one would seek to
change the language in Cynthia's proposal to read deprecated, (which she
already alludes to in her prose). Until then, the editor has suggested
that obsolete but conforming is essentially equivalent (I believe), or at
least this is how it appears to be operating today - but we shall see.

Leif's proposal sidesteps the question slightly by simply stating that
@summary remains conformant.


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

If I am to understand his proposal, yes this is the intent, although I
will leave it to Leif to specifically answer that question.  Leif has
thought a lot about table summaries in general, and has had many a
discussion outside of the W3C list with others, including myself.  I (for
one) encouraged him to put forth his thoughts as an alternative to
Cynthia's proposal, to spark discussion (I believe he mentioned a recent
conversation with some Opera engineers in Oslo as well).  It's actually a
rather clever idea.

The bottom line for me: I think we can do much better than @summary, and
we should be looking to do so, rather than continue to prop up an
attribute that frankly has failed us over the last decade.  I've been
doing web accessibility for close to the same number of years now (1999),
and as much as I wish this were not true, it is.  So to me, the options
are 1) continue to try flogging this limp ol' horse in hopes that it will
receive greater take-up in HTML5, or 2) start afresh, deliver on the need,
but maybe do it better this time around.  We've learned a lot in 10 years;
let's use that knowledge to move forward. Both proposals to *improve* on
@summary are worth discussing, and not rejected out of hand because they
signal the sunset of @summary - both take pains to ensure that @summary
remains an author option today, tomorrow, and for the foreseeable future.
They simply also suggest it might not be the best option.  Where is the
downside? 


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

Backwards compatibility with what? Breaks how? Ask Henri to confirm what
exactly? (I really don't understand what you are referring to here -
honest).

JF

Received on Tuesday, 2 March 2010 02:19:38 UTC