- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 26 Feb 2009 11:46:40 +0000 (UTC)
- To: HTMLWG <public-html@w3.org>
On Mon, 23 Feb 2009, William Loughborough wrote:
> On Mon, Feb 23, 2009 at 6:54 PM, Ian Hickson <ian@hixie.ch> wrote:
> >
> > 3. Whether the solution would be used correctly enough for users to
> > actually pay attention to it. A feature that is rarely used in
> > practice is better than a feature that is used wrongly, since the
> > latter will cause users to ignore the feature even when it is used
> > correctly.
>
> I believe that this is a flawed premise. How can one KNOW that it is
> "better"?
If a user is repeatedly beaten on the head almost every time he clicks a
button, he will stop clicking the button, even if the button on occasion
will give him cake. This is widely documented. Users adapt their behaviour
to route around negative feedback.
Similarly, if a user is offered a feature which occasionally helps them
but usually does not, then they will not use the feature. Joshue
accidentally demonstrated this (sorry Joshue!) when he had an experienced
AT user show us the feature on video -- the user said (paraphrasing) that
they never used summary="" because it rarely worked.
> We have so many examples that "pay attention" is time-sensitive, i.e. it
> could very well (perhaps even likely?) be that over time "rarely used"
> features become rightly used.
Yes, I agree entirely. That's one reason that rarely used features are
better; over time they will become less rarely used.
> That there is any causal connection between wrong use and ignored
> features doesn't seem all that clear.
Can you give an example of a feature that is widely misused by authors and
yet is still activated by users?
> The "poster child" for this view is the longdesc feature. Over time it
> could easily become central to elucidation of whatever is there because
> of the training in Web Design curricula - and these effects take a very
> long time to prevail. But claiming causality is untenable on the usual
> contention that since smoke alarms are seldom used, they shouldn't be
> mandatory in building codes.
You are right that longdesc="" is the poster child for this. However, your
conclusion is exactly backwards, IMHO. There is no way longdesc="" can
ever be seriously useful anymore, it is so widely misused. Mark Pilgrim,
well known accessibility expert, described this on the WHATWG blog:
http://blog.whatwg.org/the-longdesc-lottery
(By the way, the WHATWG blog is open to anyone who wants to write an
article for it. If anyone wants to contribut articles, let me know.)
On Tue, 24 Feb 2009, Joshue O Connor wrote:
>
> +1. Other entropy encoding analogies spring to mind also. Because there
> are admittedly few good examples of @summary in the wild is just not
> solid grounds to drop it.
Agreed. The reason to drop it is that there are so many _bad_ cases of its
use, even on sites that have the highest probablity of getting it right
(namely, government Web sites, which are legally required to do the right
thing here).
> I have not heard one convincing case for its removal FWIW beyond a
> nebulous desire to /improve/ things.
It's not really nebulous, it's based on a number of different studies
including your own.
> And yes, @summary is unashamedly more useful for non-sighted users.
The problem isn't that it's more useful for non-sighted users, the problem
is that it actually reduces accessibility for the visually _able_.
(It's effectively the opposite of <canvas>, except that it has
alternatives, such as <caption>, which we don't really have for <canvas>.)
> Ian Hickson said:
> >
> > I think you underestimate the number of people who have problems
> > reading complicated tables.
>
> No. I don't.
Then you agree that the problem summary="" tries to address for
non-sighted users is also a problem for sighted users?
> > Some of the tables I've seen discussed in this thread are tables for
> > which I really wish I had access to real summaries.
>
> Well then keep it in the spec.
Unfortunately summary="" can't be made visible in Web browsers, due to the
wide mis-use of the attribute.
<caption> can, however. So <caption> has been redefined to cover the use
cases for which summary="" was invented.
What use cases does this not handle?
> All a /real/ summary is btw is an authors attempt at an overview or
> desciption, they are often poor. It's like @alt text, often subjective,
> badly done, useless. The point however is that the mechanism is needed.
> You wouldn't ban paint brushes or guitars because there is a lot of crap
> music and art?
No, but that's the wrong (IMHO) metaphor.
I _would_ ban public use of paint brushes that caused whatever they
painted to hurt people who later visited the area, or public use of
guitars that caused hearing loss.
It's not enough to make it _possible_ to make pages accessible. We also
have to check that we've actually done enough to actually have a positive
effect on the world. With summary="", we can see that it has failed to
achieve the benefit we need.
On Tue, 24 Feb 2009, Leif Halvard Silli wrote:
>
> Explanation: One only needs to read the table instruction as long as one
> is unfamilar with the table. Once one is familar with the table (because
> one has gone through it in all directions oneself) one will not be so
> interested the overview anymore.
>
> So, it is not that the caption becomes more important, perhaps, but the
> summary that becomes less important. (It could als also be the opposite
> though: As you becomes familiar with the table, you understand the
> overview better.)
>
> This is also one reason that one needs to distinguish captioning content
> from summarising content. One must be able to know what one refers to.
Why?
Consider the example in the spec, with the table for dice. Why wouldn't a
user just learn to ignore the caption once they knew what it said,
skipping past it to the table content? How would the UI be any different
if the user agent knew that the table's name ended at one point and the
usage help started after that point? Surely the user would still just have
to hit the "advance to next block" key either way.
> > > Thus, HTML 5 as defined does not let us provide users with fast
> > > accessed and fast read summaries of tables for the situations when
> > > the <caption> does not give the reader enough clue about what the
> > > table is about, when starting to wade through the table itself to
> > > find this out, would be considerably more timeconsuming than reading
> > > a such description.
> >
> > If the caption doesn't help the user, why would summary=""?
>
> Because a <caption> is a table title. ANd at table title can e.g. be
> only "Table 10: Outcome of the first test."
HTML5 changes this. You can now say more in the caption.
> This is very little "to become wise frome". A summary can explain that
> "First test was about this and that. That is listed there. And this is
> listed there." This info is fast read. And if the user e.g. reread the
> text, he/she will perhaps remember what the table was about simply by
> reading that text. As Joshue told, screen readers might jump from table
> to table, and then need some context regarding what the table is about.
> As single cells can be rather naked in contenct, one would need to
> criss-cross the table to get an overview, wheras summary could give that
> instantly.
Caption can now gives that too.
> > How is summary="" supposed to be exposed to users of visual browsers?
> > After all, it's not just users who don't have a screen who need to
> > understand complex tables. Wouldn't it be better for the information
> > to be available to everyone? (Isn't that the whole point of
> > accessibility?)
>
> There could be advantages to both. Let's consider the advantage of only
> targeting the unsighted usergroup: It has been argued that we don't need
> fallback for video, because the point of video is the video. Without
> going into that question too much, I also think that just as video is
> best created if one take into account those that can actualy see the
> video, a summary text with the purpose of helping non-sighted is also
> best made if one make with only that target group in mind. So this is
> the positive side of having an attribute that only has one usergroup in
> mind.
I strongly disagree that videos should be made by ignoring users with
special needs! I similarly disagree that ignoring users without AT tools
is a good way to design sites. Steven's list of US Government tables with
summaries that contain data useful to anyone but only visible to disabled
users is a great example of the danger of doing this.
> But I am not certain that this advantage so enormous that it would be
> wise to avoid an element or attribute that could help all users.
> Probably not.
Would <caption>, with its new definition, thus solve the problem?
> Below yo propose to joine sumary and caption into one element. I guess
> this is what you mean here. (THus you agree that wee need both, but it
> isn't clear to you that we need to keep them separate.)
Right.
> Yes, I am quite certain that AT software needs to distinguish the one
> from the other. And so does in fact all UAs.
Why?
> (In the example you give in the draft, the "real" caption has now become
> "Table Number" inside <strong>.)
Why is that a problem?
> > On Wed, 18 Feb 2009, Leif Halvard Silli wrote:
> > >
> > > * Avoids the problems of the (claimed) misused @summary
> >
> > How so? Surely it would just move the problems from one attribute to
> > another.
>
> Because it would be like starting from a clean slate and so on. (I feel
> like I allready explained this point.)
To use another forced metaphor, if one burns down one's shed while trying
to have an open fire in the middle of it, getting a second shed to do the
same thing isn't going to solve the underlying problem.
If we just use a new attribute and hope for the best, we're not learning
from our collective mistakes.
> The example you have made there is telling:
>
> <table>
> <caption><strong>Table 1.</strong> This table shows the total score obtained
> from rolling two six-sided dice. The first row represents the value of the
> first die, the first column the value of the second die. The total is given in
> the cell that corresponds to the values of the two dice.</caption>
> 1 2 3 4 5 6
> 1 2 3 4 5 6 7
> 2 3 4 5 6 7 8
> 3 4 5 6 7 8 9
> 4 5 6 7 8 9 10
> 5 6 7 8 9 10 11
> 6 7 8 9 10 11 12
> </table>
>
> It would be possible to claim that such a long caption no longer is a
> caption, would it not?
The caption includes more than just the table number, if that's what you
mean. But it's not unusual for captions to include lots of information.
Consider captions for paintings in museums. They have the title, the
media, the artist name, even sometimes backstory and commentary.
> I think this could create problems.
Why?
> This not longer is pure table title.
Why does that matter?
> E.g. AT needs title to navigate between elements.
Which elements?
> If you are effectively concatenating @summary and <caption>, then why
> not define a way to subdivide caption? Caption as you have defined it
> here, becomes more like the <header> element, with a "title segment"
> first (<strong>Table 1</strong> in your example in the draft). As such,
> it could make sence to divide it in a summary section and a caption
> section.
What's the use case?
> Currently screen readers discern between caption and heading. E.g. Jaws
> tells some general table info between the caption and the summary, thus
> distinguishing the one element from the other. Like you propose it here,
> it all come in one big chunk, I'm afraid.
I don't understand why this is a problem.
> > > It is when one has allread used <caption> for something else, or
> > > when the summary info is longer than what is fit for a caption, that
> > > one really needs @summary.
> >
> > Could you give an example of this from a real Web page? Is this common
> > enough that it matters enough that we should handle it? (How often are
> > they used together today?)
>
> This depends on what you mean. The Vegetarian newsletter in collection
> of tables that Steve came up with did have both - as I have allready
> explained.
( http://www.vrg.org/journal/vj2006issue2/vj2006issue2mealplans.htm )
> But the problem was that the author did not use a real <caption> but
> instead a table cell as caption. However, that table had both. The
> caption was short, as one expects captions to be.
That page is a great example; the summaries are basically just repetitions
of the captions in the cases where there are captions. That page would
really _benefit_ from advocacy arguing for captions only, as would all
its users, both sighted and not.
> > I can't speak for Sam and Chris, but personally I'm looking at the
> > long term, and so I certainly wouldn't limit us to discussing
> > summary="" only. We should investigate any and all solutions that
> > would help users (all users) understand the Web better.
>
> Hence, your opinion about a way to designate a part of the caption as
> "title", please.
It's not clear to me that there's a need to do this.
On Tue, 24 Feb 2009, Henri Sivonen wrote:
> On Feb 24, 2009, at 04:54, Ian Hickson wrote:
> >
> > (Screen readers properly supporting the 'speech' media would
> > significantly aid in making pages written by caring authors more
> > accessible, since hacks like 'text-indent' would not be needed.)
>
> Unlikely. While people who use a given rendering medium themselves may
> be able to produce styling that is more usable than the UA default,
> people who don't use a rendering medium themselves don't have the same
> experience as users who use the medium all the time and due to this lack
> of experience may well produce styling that is worse than UA default.
>
> Given that non-blind Web authors (i.e. most authors) usually don't use a
> speech rendering as their primary Web browsing medium, chances are that
> more often than not, dabbling in speech styling wouldn't be very
> competent.
Good point. What's really needed isn't full-on speech media control, but a
way to explictly hide content from visual users but not screen readers. A
kind of 'display: screen-reader' value.
> > This, to me, argues that the summary information shouldn't be hidden
> > in the summary="", but should be somewhere in flow, like the
> > <caption>. Instead of:
> >
> > summary="Search results sorted by title, ascending">
> >
> > ...it would be better to have:
> >
> > <caption>Search results sorted by title, ascending</caption>
> >
> > The CSS could then be used to hide this information, e.g.:
> >
> > caption { height: 0; overflow: hidden; }
> >
> > ...without hiding it from users who need it.
>
> Seems like a lot of trouble for just Links/Lynx users.
This is trouble that authors already go to to hide "jump past
navigation"-style links, for what that's worth.
On Tue, 24 Feb 2009, Steven Faulkner wrote:
> >
> > Problem statement: some users find navigating tables complicated, and
> > would like a description of the table so that they can make better use
> > of the table. Such users might be blind, using an accessibility tool,
> > or might have cognitive difficulties, or might just be unfamiliar with
> > the structure of particularly complicated tables.
>
> I don't agree with the underlying goals in relation to @summary, the use
> of @summary has been discussed in terms of its scope as set out in HTML
> 4.01
I think this summarises my disagreement pretty well.
I'm not interested in what HTML4 does. I'm interested in making the Web
accessible to all users. If your interest lies merely in feature parity
with HTML4, then this is not likely to be something we can every agree on.
If this is indeed where we have a difference of opinion, then I think it
would be useful to have guidance from the chairs regarding whether we
should be focussed on helping users or on HTML4.
> It is and does try to solve a subset of your problem statement, the
> other aspects of your problem statement can be handled by providing, for
> example, a paragraph before the table with content that describes the
> table.
How would tha not make the user experience for users of AT tools worse,
with duplicate information?
> What @summary does, but HTML5 omission of it does not is provide an
> explicitly associated container for text that can be unambiguously
> identifed as a summary of a data table. For a user group that has unique
> problems in understanding data organized into a tabular format.
Why isn't <caption>, as defined in HTML5, enough for this? (And indeed,
how is it not better, being accessible to more userse?)
> > Whether it would be used correctly is a question we can in fact
> > answer, since we have ten years' worth of experience with sites using
> > summary="", with ample accessibility advocacy, education, and law (!)
> > to support it. I'll discuss this further below.
>
> No, we can say that in the samples there was wide variability in its
> use, whether its used strictly "correctly" is not the issue, is it used
> in a way that helps or hinders those that that it is aimed at helping is
> a better question, one that you have not answered.
I think it is clear from the data that summary _at best_ provides no more
use to AT users than a <caption> with the same information would, and at
worst, irritates users to the point where they stop using the feature.
On Tue, 24 Feb 2009, James Graham wrote (to Steven):
>
> This suggests that @summary is not needed to fulfill your use case as
> stated. I agree that _in principle_ there are minor semantic differences
> between @summary and some of those constructs; in practice the data
> doesn't support the idea there is a difference in practice.
Indeed.
On Tue, 24 Feb 2009, Sailesh Panchang wrote:
>
> At the outset one needs to realize that caption and summary are not
> interchangeable. The elements serve different purposes.
Do they have to? HTML5 defines <caption> in a way that covers both. Why is
that a problem?
> I do not understand how people look at cases where tags have been used
> incorrectly or misused and argue that the tag should go. It is like
> saying guns are misused and criminals kill people with guns so one
> should stop producing guns and ban them completely.
Not an uncommon argument, it should be noted.
On Tue, 24 Feb 2009, Sailesh Panchang wrote:
>
> In HTML4 the summary attribute for a (data) table has the limited
> objective of aiding non-visual users. So visual browsers do not expose
> it. I do not see any flaw there.
The flaw is that it has caused authors to provide information only to
users of AT tools, which is an accessibility failure for non-AT users.
Accessibility is important for _all_ users, not just those with
disabilities or special needs.
> Experience in accessing content via a visual interface is quite
> different from accessing content via an auditory / Braille interface and
> the summary is meant for this group of users. When developers who have
> limited or no understanding of auditory interface are tasked with
> writing summaries for data tables one cannot expect to see summaries
> that are really helpful, well written and concise.
It should be noted that that describes nearly all Web authors.
If we are intending users of accessibility tools to have a pleasant
experience, then using a feature which we know ahead of time will be
almost never correctly used is simply bad design on our part.
On Tue, 24 Feb 2009, David Poehlman wrote:
>
> One thing we need to do is make summary for data tables visible
> regardless of what html 4 says.
As far as I can tell, the only way we can do that is to use <caption>. Due
to complexities with the parser, adding a new element is unlikely to be
possile in the near term. Due to the high proportion of useless summary=""
values in existing content, we can't expose summary="". <caption> already
exists and is visible.
> Why? because as has been stated, it aids with the cognative load in
> many instances and something perhaps not thought of if I am using screen
> mag software, I might not be able to get the entire table in view at
> once thereby breaking my view of it so the summary would help me to pick
> out the interesting bits. Also, making summary visible might encourage
> authors to get it right.
Agreed entirely.
On Wed, 25 Feb 2009, Leif Halvard Silli wrote:
> Ian Hickson 2009-02-24 03.54:
> > On Tue, 17 Feb 2009, Leif Halvard Silli wrote:
> > >
> > > Both <caption> and @summary provide metadata. But currently, in HTML
> > > 5, one cannot author the table metadata with both screen readers and
> > > visual media in mind, simply because, in visual medias, a long and
> > > wordy caption would not work or serve its purpose as caption. Such
> > > <caption>s would not even work for screen readers, since those
> > > readers too need short, clue giving captions. (As soon as one learns
> > > what a particular table is about, the @summary looses more if its
> > > purpose, while the short <caption> increases its usefullness.)
> >
> > I am concerned here over the media-specific aspect of this problem
> > statement. What about other media, such as braille?
>
> You are hinting that braille doesn't support @summary. Why?
That wasn't my intent; I was merely commenting on your description above.
On Thu, 26 Feb 2009, Steven Faulkner wrote:
>>
>> That would be ideal, but unfortunately, pages on the Web that use
>> summary="" almost always use it incorrectly, with horrible values that
>> aren't helpful to anyone
>
> This a statement of opinion not fact. Please do not continue to assert
> this without providing a balanced study of summary use to back it up.
There have been a number of such studies. Here's one:
http://canvex.lazyilluminati.com/misc/summary.html
Philip's data has in the past been found to track very closely with the
results of my own studies of billions of pages, so I would say the above
is representative of what one might expect across any more or less random
sample of the Web.
If one examines this data, one finds that not one of the values found
is actually useful. (A few seem like they'd be useful, until you look at
the pages, and then you realise that they are redundant with other data
immediately before or after the summary.)
There is no way browser vendors would agree to exposing this data to all
users.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 26 February 2009 11:47:19 UTC