W3C home > Mailing lists > Public > public-html-a11y@w3.org > January 2010

Re: Discussion on Change Proposal for ISSUE-66

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 22 Jan 2010 01:07:31 -0800
Cc: 'Matt May' <mattmay@adobe.com>, 'HTML WG' <public-html@w3.org>, public-html-a11y@w3.org
Message-id: <A61A60C4-621B-4780-9C65-F8D20AA8834F@apple.com>
To: John Foliot <jfoliot@stanford.edu>

On Jan 22, 2010, at 12:21 AM, John Foliot wrote:

> Maciej Stachowiak wrote:
>> which requires cognition - no machine today can do this.
> 
>> 
>> Nobody is saying "substitute for". The question is just whether repair
>> techniques are allowed in the face of broken content.
> 
> I think that perhaps I've not explained myself correctly, of course they
> should be allowed.  I don't think they should be prescribed in the
> specification, especially given that the root of this discussion, the
> removal of language that referenced non-existent techniques, simply sought
> to remove reference to said non-existent techniques. Nothing in the Change
> Proposal suggests that *all* repairs techniques be foregone, only the
> reference to 'Heuristics'. 

Ok. What I'm trying to figure out is whether a general statement that repair techniques are allowed would be acceptable to everybody.

> 
>> I ask you again:
>> are you saying that emergency repair techniques by the UA or AT should
>> be explicitly banned? Note that this would make *all* existing AT
>> noncompliant. (The most common current emergency repair for missing alt
>> is to read the filename.)
> 
> I am not. But I have grave concerns that we reference in a Standard a
> technique that is a non-technique, as it can foster a sense of complacency
> in authors - it is but wishful thinking today.  

I agree that it doesn't make sense to specifically mention techniques the practicality of which is uncertain. I think it would be better to list no specific techniques, or list some examples that are clearly practical today.

> 
>>> 
>>> I think any statement that suggests futuristic magic as a potential
>>> technical possibility inside a technical specification and standard
>> is
>>> wrong, and should be avoided.
>> 
>> I believe what I suggested was exactly the opposite of that.
> 
> Then I think we are essentially in agreement.

That would be great. This email is to double-check that we are really on the same page.

Regards,
Maciej
Received on Friday, 22 January 2010 09:08:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:00 GMT