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

Gentle readers, I would appreciate private feedback on whether my 
participation in this thread is helpful. My main goal is to help clarify 
the discussion. I don't expect to be able to convince Ian to my point of 
view, but I am hopeful that we will better understand the disagreement, 
shaking out the straw men and red herrings.

Ian or David, feel free to adopt a new subject line.

At 05:38 PM 6/30/2009 +0100, David Singer wrote:
>At 11:57  -0500 30/06/09, Murray Maloney wrote:
>>David, I don't know why you failed to respond to this part of what I 
>>wrote. I think that you should read and respond to this part because you 
>>seem to be voicing a tension that appears to be a straw man.
>
>It's because I didn't see a question here.

OK, let me try again. Please forgive me for moving the paragraphs around a 
bit, but it will help me respond better...

You wrote the following...

>>At 02:53 PM 6/29/2009 +0100, David Singer wrote:
>>
>>>I think part of the problem on the alternatives may be another unvoiced 
>>>tension, [...] 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).

What I want to know, first of all, is whether you more or less agree with 
the following paragraphs...


>>What I have heard, repeatedly, from accessibility people is that they 
>>recognize that some of the special provisions that are provided for their 
>>benefit can be a burden to those who derive no benefit. Moreover, they 
>>have learned that it is important to find solutions to their problems 
>>that provide ancillary benefits to others, such as curb cuts. With 
>>respect to longdesc and summary, I will make the following observations.
>>
>>Longdesc is intended to hold a long description of a graphic element 
>>which contains information sufficient to allow a non-sighted user to 
>>appreciate the intent or content of the graphic element. Ideally, there 
>>would be no more information in the long description than is discernible 
>>by a sighted user. Having some experience with publishing, they have 
>>acknowledged that placing such information in the main stream of content, 
>>or in a caption as has been suggested, would be more of a speed bump than 
>>a curb cut for sighted users. So, they have allowed as how the content of 
>>a longdesc need not be displayed to all users at all times, but I have 
>>never heard anybody suggest that a long description should not be made 
>>available to sighted users.
>>
>>Summary is intended to a) a quick summary of a table, such as you or I 
>>might gain by simply glancing at it without examining the content 
>>closely, such as 'A price chart of teas and coffees' or b) a navigational 
>>aid to the table, such as 'This is a complex table with headers spanning 
>>several rows and columns. The prices of tea are presented in columns 3 
>>and 4. The prices of coffee are presented in column 6, [and so on].' 
>>Again, one suspects that sighted users would not need or want such a 
>>summary, but I don't think that anybody has suggested that they should 
>>not or must not have it.

Carrying on, you responded with....

>But let me try, since there is a mis-understanding that may be worth 
>teasing out.
>
>I don't think I said that there are features that MUST not be displayed to 
>sighted users; clearly that would be a silly restriction.  But some of 
>these attributes ARE not displayed to sighted users, and as a result, they 
>are invisible, unchecked, by the average web author.  The result is a poor 
>level of conformance, I fear; people just don't notice their failures.

It is unfortunate that UIs do not offer more and better features to support 
QA of web documents. The problem of invisible and unchecked attribute 
values is widespread, affecting not only AT attributes, but also linking 
and other attributes. Thus, it would seem that this is not a particular 
flaw of AT attributes. Do you agree? If so, could we untie this problem 
from the discussion of AT attributes? If not, please explain further.

>If, on the other hand, getting the accessibility provisions wrong ALSO 
>meant that the page didn't work well for the average sighted user, then 
>the average web author has a better chance of noticing that and fixing 
>that.  That's all.  The accessibility provisions would then be in an 
>'integrated' rather than 'ghettoed' state.  The downside would be that you 
>can no longer point at something and say "see, that is there specifically 
>and only for accessibility" -- but that very statement is also potentially 
>an upside.

That would be nice, I suppose, but you may have noticed that although not 
all users of televisions enable Closed Captions, they are still useful to 
the hearing impaired, and in multiple languages. I am not hearing impaired, 
but when I mute my TV, I get Closed Captions, which can be helpful if I am 
on a conference call while watching Jeopardy. Another 'curb cut' technology 
that can benefit us all without having to be a speed bump for the majority 
who never use CC. Nobody has to see the 'invisible content' if they choose 
not to, and nobody has to see the 'invisible content' fill the screen with 
English, French, Spanish, Italian and German subtitles, thereby obscuring 
the image on the screen.

But I think that you are exposing a bias that you share with Ian with 
regard to meta data in attributes. I would like to understand this bias 
better so that I can respond to it because I think that this particular 
bias is a source of tension among participants in this WG. Could you and 
Ian please try to expose your thinking on this, bearing mind the paragraphs 
above that outline my understanding of longdesc and summary.

Thanks in advance,

Murray

Received on Tuesday, 30 June 2009 19:36:06 UTC