Re: [text] updated draft, 20110430, of clarification on alt validation

Benjamin Hawkes-Lewis, Sun, 1 May 2011 10:50:06 +0100:
> On Sun, May 1, 2011 at 8:19 AM, Leif Halvard Silli:
>> Benjamin Hawkes-Lewis, Sat, 30 Apr 2011 22:53:08 +0100:

>>> Note doing this is explicitly prohibited by ATAG 2 WD B.2.3.3:
 ...
>> B.2.3.3 Let User Agents Repair: The authoring tool avoids repairing
>> programmatically associated text alternatives for non-text content
>> using any text value that would also be available to user agents (e.g.
>> do not use the image filename). (Level A) [Implementing B.2.3.3]

>> However, if I use TextEdit as an authoring tool, and adapt myself to
>> how it works, creating file names such as 'My mom and dad in the
>> sofa.jpeg', which results in code like
>> 
>> <img src="My mom and dad in the sofa.jpeg" alt="My mom and dad in the
>> sofa">
>> 
>> Then I don't see that the term 'repair' applies.
> 
> I agree this could result in more accessible content than missing @alt;
> I disagree it would not be a violation of ATAG 2.

'be a violation': The guidelines themselves uses the verb 'meet' (40 
times, in various conjugations). 'Violate' is only used once, about 
breaking a WCAG success criteria. It is obviously not so that a good 
@alt text is only good if it is inserted via 'procedure x' instead of 
via 'procedure y'. ATAG is about accessible authoring. Accessible 
*content* is not its domain. (In more than one sense. [1])

B.2.3.3. is part of Guideline B.2.3 which goes: "Assist authors with 
managing alternative content for non-text content." 'Assist' is not a 
synonym for 'force'. Also, ATAG2 does not aspire to describe every 
authoring situation. [2] At the same time, it has a wide understanding 
of 'authoring tool'. [3]

Tools are, per ATAG2, required to prompt only for 'automatically 
generated content', which in turn is defined as being: [4] "When 
programming by the authoring tool developer is responsible for the web 
content". 

Unlike what the Decision said, there does not, btw, appear to be an 
absolute requirement for prompts in ATAG2.  There are mentioned 3 
alternatives to prompting: automatically accessible without author 
input; automatic accessibility checking ore merely a proposal to the 
author to perform accessibility checking.

I do agree that that the tool could skip prompting for @alt in the very 
moment when the image is added. But then there should be a prompt, at 
some point, automatic validation or a suggestion about validation, 
instead. And the checking itself could be both automatic, manual or 
semi-automatic. 

But, an interesting detail is that the checking ATAG speaks about is 
WCAG checking - not HTML validation. This means that the generator 
string would not matter with regard to ATAG.

...
>> Also, we have the priority of constituencies: tool vendors should
>> comply to ATAG2, while authors should comply to CGAG2 and HTML5.
> 
> Not sure what you mean.

I meant WCAG - not CGAG. It is the author's task to comply with 
document guidelines/rules, even if the authoring tool doesn't meet the 
ATAG requirements. 

>>>> After all, there are many much more important HTML features to
>>>> implement in HTML e-mail before the generator string?
>>> 
>>> This seems weak.
>> 
>> May be. How? Most HTML e-mail messages do not use a valid DOCTYPE etc.
> 
> I think it's a bit like arguing that most webpages do not validate, 
> so surely there are more important features they should implement>
> before  "figure", so we shouldn't spec "figure".

It matters with regard to ATAG: "email clients that send messages in 
web content technologies". 

But what we are discussing in our context is HTML validity - and not 
WCAG conformance. One of the criteria for revisiting the private e-mail 
exception was to provide evidence that private, hand authored HTML-mail 
messages is a big concern. Thus, if the tool vendors - the e-mail 
program vendors - do not implement HTML5, why should we carve out a 
HTML-validity loophole for them? If the <head> element plays no role in 
HTML e-mail, then it it is of little value to use HTML-mail as pretext 
to water down HTML5's validity requirements.

>>>> [4] One (so far hypothetical) problem is that the
>>>> generator exception could cause vendors to treat images differently
>>>> when they operate with the generator flag present.
>>> 
>>> IIRC past Decisions have been fairly dismissive of purely hypothetical
>>> problems.
>> 
>> I'm sorry, but in your previous reply you wrote:

 [ ... ]

> Okay, I thought "vendors" was referring to browsers. Based on what you say
> above, you seem to be describing the intended effect of the exemption
> (authoring tools insert no @alt instead of bogus @alt when the author 
> does not
> provide an @alt) as a "hypothetical problem".  This is confusing.

OK. Will look at it.

[1] 
http://lists.w3.org/Archives/Public/public-atag2-comments/2011May/0000
[2] http://www.w3.org/TR/2011/WD-ATAG20-20110426/#def-Content-Auto-Gen
[3] http://www.w3.org/TR/2011/WD-ATAG20-20110426/#def-Authoring-Tool
[4] http://www.w3.org/TR/2011/WD-ATAG20-20110426/#intro-notes
-- 
Leif H Silli

Received on Sunday, 1 May 2011 22:09:40 UTC