Re: Why I don't attend the weekly teleconference (Was: Input on the agenda)

On Mon, Jun 29, 2009 at 8:53 AM, David Singer<singer@apple.com> wrote:
> Shelley,
>
> As was recently posted on this list, we seem to have two strawmen that are
> repeatedly set up on this list:
>
> a) "If you don't support the attributes and designs that have traditionally
> been there for accessibility, then you are an accessibility-hater who
> doesn't deserve to be listened to."
>
> b) "If you don't check whether your accessibility provisions work, or could
> work, in practice, you are treating accessibility solutions as a talisman
> and you are not interested in actually serving the accessibility community,
> and you don't deserve to be listened to."
>
> Your recent emails are coming across with an undertone of (a) and getting
> close to being capable of characterization (b).  I don't think this is
> helping move the discussion along.
>
>

David, this is a perfect example of what happens on this list.

People express concerns, and then someone comes along and classifies
such actions as strawmen, primarily because it seems to go counter to
your own interests.

Haven't you ever thought that perhaps your response is just as much a strawman?

I'm not accusing Ian of being an accessibility hater. I do
believe--and this is belief, I won't imply otherwise--that Ian tends
to respect those most like himself, and that this bias in respect can
undercut the necessary empathy in order to create a truly
comprehensive and inclusive HTML 5.


>
> There is a clear concern on this list, supported by some data, that
> 'summary' is so polluted in practice that no-one who needs accessibility
> would ever bother looking at its value, which means in turn that no-one
> interested in supporting accessibility would bother putting data there
> because their constituency won't notice it.  If this is true, summary may be
> irrecoverably polluted.  We need to know if there is evidence to the
> contrary.
>

Concern, yes. But not scientific study, which is what is claimed to
support a specific set of actions taken for that concern.

Wouldn't another set of actions be a stronger clarification in the
HTML 5 specification about how the attribute is to be used? Isn't that
just as viable an action to take based on the concern?

> Now, it may well be that the alternatives proposed to date are inadequate.
>  But the floor is open.
>
> I think part of the problem on the alternatives may be another unvoiced
> tension, which is roughly as follows.
>
> Some people seem to feel that accessibility provisions should be
> specifically and only targeted for accessibility -- e.g. an attribute that
> no-one else ever sees or uses.  Others wonder, since most web authors don't
> use accessibility provisions, whether accessibility provisions that web
> authors don't see are unlikely to be supported by them very well, if at all
> (and indeed, that they are highly unlikely to check how effective or even
> correct they are).
>
> I think this lies behind some suggestions that we make accessibility 'work'
> from design aspects that everyone can perceive and verify, so that web
> authors are more likely to 'get it right'.  So, far from trying to make
> accessibility invisible, it's an attempt to make it not a ghetto, but a
> normal aspect of everyday design.  But it does lead to a situation where you
> can no longer point and say "see, this attribute is purely for
> accessibility, ergo, we support accessibility".
> --

Again, that is one solution, but it completely abrogates the purpose
behind summary, which was to provide a description of an HTML data
table, when necessary to ensure that the table is more easily
understood by those with visual impairments. To provide in text, what
others see from visual clues associated with the table.

Bunging summary into caption, not only undercuts the purpose behind
summary, it redefines caption. Caption is now no longer just a short
title, description for a table -- it's supposed to now provide clues
to those with visual impairments about how they are supposed to
traverse this table, or access the table. It is no longer the same
thing.

For a group who prides on "semantic" markup, I would think there would
be reluctance to redefine an element that has existed since HTML 3.2.

Regardless, I would appreciate that my arguments are seen as genuine
interest. More so, I do believe that I have asked questions and
expressed concerns that have not been addressed, and that as a member
of this working group, I have the right to express these questions and
concerns, yes, multiple times, until such is answered.


Shelley

Received on Monday, 29 June 2009 14:43:28 UTC