Re: FW: [html] Summary draft

I apologize in advance if any of this post duplicates things that have
been said before I joined these lists (which some parts probably do).

On Mon, Sep 14, 2009 at 7:13 PM, Cynthia Shelly
<cyns@exchange.microsoft.com> wrote:
> 2.       I’d like to hear from those on the list who have general objections
> to hidden metadata. In general I agree that developer psychology is such
> that things the developer can't see are more likely to be missed or allowed
> to get out of date, and that it’s good to try to avoid them.  But, I think
> there are use cases where they are needed anyway, and in those cases we need
> to rely on authoring tools to expose them in a reasonable way to
> developers.  Alt text is one example, and one where some authoring tools do
> a decent job.  I think summary falls into the same category.  So, for me,
> avoiding hidden things is more of a guideline than a hard-and-fast rule.  In
> my opinion, describing purely visual information is such a use case.  Alt
> does that for graphics, summary does it for table layout.

Alt is significantly more visible than summary.  If images are
disabled or don't load, or possibly even if they haven't yet loaded,
it's displayed even in normal browsers.  It's also required for all
images, so anyone who wants their page to validate (a surprising
number of people) has to stick *something* in there.  And finally, the
correct way to use it isn't that hard to understand for a typical web
author: "If you had images disabled in your browser, what would like
to see here?"

Despite all this, it's misused much more often than it's used
correctly.  As far as I'm aware, the situation isn't bad enough that
user agents ignore the attribute.  On the other hand, as far as I
know, longdesc is so consistently misused that no user agent, AT or
otherwise, bothers providing it to users in any obvious way by
default.  (Please correct me if I'm wrong here.)

Perhaps someone here knows -- do a significant number of tables on the
existing web use the summary attribute?  How many of them use it in a
useful fashion?  Is it useful enough that existing AT typically makes
it prominently available to users?  If the attribute is almost always
used incorrectly, or isn't used correctly often enough for existing AT
to feel it's worth displaying, that would strongly indicate to me that
it's an ineffective way to communicate the needed information in
practice.  HTML5 should recognize this and we should go back to the
drawing board.


A further problem I have with the summary attribute as an author is
that I really don't understand how it's supposed to be used.
Apparently it should contain

"infomration about relationships between data elements that are
obvious to users who can see the two-dimensional layout of the table,
but would be difficult to determine for users who cannot see the
table. The information provided by the summary is needed by users who
cannot see the table, but would usually be redundant for those who
can."

Okay, but . . . I'm having a hard time figuring out what this would
be.  "Pretend the image isn't there -- what text should be there
instead?" is fairly easy (although most authors still get it wrong!).
But the problem I'm being given here seems like "Pretend the table is
being presented to you in some unspecified way that doesn't allow you
to actually see it -- what would a useful summary be?"

I have not the slightest idea.  I've seen plenty of pages without
images before, but I've never used AT of any kind.  I don't know how
they present tables.  (Do they even all do so in the same way?)  Even
if that were explained, I don't have any experience trying to
interpret tables presented in that fashion.  I'm sure that if I
routinely had to puzzle through tables being read out or whatnot, I'd
figure out what kinds of things are useful to explain up front, but
I'm really at a loss without that experience.

So the spec currently provides an example.  Great!  Let me look:

<table summary="The table is divided into six columns: Map number,
  Date, Area or stream with flooding, Reported deaths, Approximate costs
  (uninflated), and Comments. The rows are grouped by flood types into six
  subcategories:  Regional flood, Flash flood, Ice-jam flood,
Storm-surge flood,
  Dam-failure flood and Mudflow flood." >

Now I'm even more confused.  Surely this information can be
automatically determined from the table itself, if I correctly use
<th>?  Why is this repetition useful?  It duplicates info -- I'm very
likely, as an author, to update the table and then forget to update
the summary, making blind users of my site even *more* confused.

I feel like reading the proposed spec, as a sighted author, I'm being
required to do something that's just not specified well enough for me
to be able to do it even competently, let alone well.  I think it's
fair to say that I'm exceptionally familiar with accessibility issues
compared to the average web author (although not compared to members
of the HTML WG).  I'm also actually reading the spec, which virtually
no authors will -- and that should mean I'm *much* better prepared to
use this kind of feature correctly.  Yet I can't make heads or tails
of it.  I really don't think this bodes well for its usefulness in
practice.


While accessibility is important, I think a lot of the people who work
on accessibility start out with the attitude "Let's provide a
mechanism that would be helpful for accessibility if used correctly".
The problem with that is the "if used correctly" part.  A lot of the
accessibility proposals I've seen for HTML don't seem to take
seriously the fact that the overwhelming majority of authors, in fact,
have not ever thought much about accessibility; will not know one way
or another what users of non-standard web browsers see, even if they
know about them, because they don't have one; and will not read any
applicable standards.  They will not use anything correctly if they
can't perceive a difference.  The most you can do is try to make their
page not validate -- but then they'll just stick in whatever garbage
makes the page validate.  (See: alt.)

This seems gloomy.  Well, it is gloomy, because the situation is
gloomy.  Wikipedia is probably significantly more accessible than the
average website, for instance, and MediaWiki developers are probably
more concerned with accessibility than most web authors.  But for
instance, the software didn't even *allow* users to add proper alt
text for years -- that functionality was only added very recently.
Why?  Complaints were fairly rare, so other issues got priority.  Some
months ago I added support in a couple of hours.  Similarly,
<https://bugzilla.wikimedia.org/show_bug.cgi?id=11555> has remained
open for nearly two years now despite complaints by some screen reader
users.  Why?  Because it would be somewhat disruptive to fix, and it
only affects a tiny percentage of users who don't complain terribly
loudly, so we have more motivation to fix possibly more minor things
that affect orders of magnitude more users.

The bottom line is, standards authors can't give authors much
incentive to cater to blind people if blind people are 0.1% or less of
their audience.  It's honestly unreasonable to expect them to care
much.  The only way you're going to get accessibility to work is to
make sure that everything that's useful to blind people is somehow
best for sighted people as well.  That's not always going to be easy,
or even possible.  But it has the *possibility* of actually working
reliably, unlike (I strongly suspect) schemes such as summary.

On Mon, Sep 14, 2009 at 9:33 PM, John Foliot <jfoliot@stanford.edu> wrote:
> Ian Hickson wrote:
>>
>> I couldn't find any description of what problem this proposal is trying
>> to solve.
>
> Then, frankly, you are being obstinate and not reading the email properly.
> I quote the 3rd and 4th sentence in the first paragraph:
>
> (1) "One goal was to clarify when a "hidden" summary, only used by those
> who can't see the relationships implied by table layout, should be used,
> and when a visible description of the table (such as in a caption or
> surrounding text) is more appropriate."
>
> Seems pretty clear to me.  Goal = clarification.
>
>
> (2) "It also uses 'guidance to conformance checkers' rather than
> obsoleting the @summary attribute."
>
> Goal = confirms that @summary is not obsolete, but deserves to be
> 'flagged' by conformance checkers to provide accurate and balanced author
> guidance.
>
> What exactly do you not understand in those 2 sentences?

Those aren't the problems that the proposal is trying to solve,
ultimately.  They're means to an end.  It seems to me that the actual
goal is something like the following (this is largely guesswork since
no one has stated it very explicitly):

Problem: Tables are a common format for presenting structured
information.  They are very convenient for sighted individuals, but
become difficult to understand when read out loud, such as to a blind
person.

Examples:
* ???  What are some realistic cases where blind people would have
trouble understanding a table, and what information would help?
Ideally, from real-world data of some kind.

Requirements:
* Screen readers must be able to read out tables in a way that makes
them more comprehensible.
* As many tables as possible should become usable in practice -- in
particular, if possible, those written by authors who don't have
access to or familiarity with, screen readers and may not have read
the HTML5 spec or any other specification.

That problem statement probably doesn't exactly match what you'd want.
 The Examples section badly needs filling in -- I, like Ian, still
don't feel like I understand well where and how the actual problem
occurs here.  The examples given have just confused me even more.
Does anyone here use screen readers regularly?  Do we have real-life
examples where actual users can tell us "I was reading this page and
got completely confused when it got to this table, it would have
really helped if it had said something like '...'"?

Again, I apologize if I'm retreading old ground in this post.

Received on Tuesday, 15 September 2009 16:55:24 UTC