Subject: RE: PaceReformedContent3

From: <[email-masked]>
Date: Fri, 8 Oct 2004 09:01:42 +0300

> By not requiring accessible alternatives, the specification is
> the tool that is screwing the blind. By requiring accessible
> alternatives, the author - or the tool he has chosen - is the 
> one screwing the blind.

I think that Robert put it very nicely - the <title> should be an adequate lowest-common-denominator representation of the content, with no need for an extra alternative format.

So perhaps we should reword this into "In an Atom Entry, you MUST Have either a <title>or <link rel="alternative"> to provide a textual representation.  You MAY also have both."

Besides, in those cases where the content in itself is fully accessible to even the blindest of users, requiring a <link rel="alternative"> seems kinda stupid.  Or in those cases where you are just providing a headline, but no content.  If you have no content, how can you provide an alternative representation of it?

> You say that (alt="") as if it is a bad thing. There are valid 
> and correct uses for alt="". I see more problems with no alt
> attribute at all.

...which is exactly happening in very, very many web sites.
 
> An alt attribute on an image is mandatory according to the
> current HTML specification. How is reducing the requirement of
> an accessible alternative to a "SHOULD" going to be an 
> improvement for the end-user?

...because requiring ALT resulted in a bunch of malformed web sites, where the developers just did not care.

/Janne

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 8 Oct 2004 09:04:58 -0400

> I think that Robert put it very nicely - the <title> should be an adequate lowest-common-denominator representation of the content, with no need for an extra alternative format.

This is not an acceptable solution.  Go read http://www.w3.org/TR/xag

> ...which is exactly happening in very, very many web sites.

There are also many web sites that use the alt attribute correctly and
are accessible to the blind.  This would be impossible without the
existence of the alt attribute.

> ...because requiring ALT resulted in a bunch of malformed web sites, where the developers just did not care.

This is a non-sequiter.  Isofarro had it right.  If individual authors
choose to publish inaccessible content, that is an education/advocacy
problem.  If individual authors are unable to publish accessible
content, that is a specification problem.

Accessibility is not optional.  Our co-chair agrees with me that this
is a baseline requirement.  Our content model will be accessible (in
fact, it will be *more* accessible than the stupid alt attribute in
HTML, which only allows plain text).

-- 
Cheers,
-Mark

---

From: Robert Sayre <[email-masked]>
Date: Fri, 08 Oct 2004 10:12:51 -0400

Mark Pilgrim wrote:
> This is not an acceptable solution.  
> 

I asked for an acceptable solution. Show me one.

Here is a sample entry, which demonstrates a very common use case:

<entry>
...
<title>A Picture of My Trip To The Lake</title>
<content src="some.jpg" type="image/jpg" />
</entry>

How do we improve this? Would including a summary make it better?

> existence of the alt attribute.

It would still be possible if the alt attribute were optional.

> content, that is a specification problem.

Isofarro stated that the spec "screws the blind" if it doesn't include a 
validity constraint that requires some sort of "alternative" element or 
attribute. If such an element is available, but not a validity 
constraint, are we still "screwing the blind"? It seems like a judgement 
call for the author to make, based on the nature of the content.

> HTML, which only allows plain text).

Everyone agrees that this is a baseline requirement. I want to do the 
right thing. Please explain why a validity constraint is the right thing.

 > Go read http://www.w3.org/TR/xag

OK, I read that. Where does it talk about validity constraints? In 
particular, I noted

"1.1 Provide a mechanism to explicitly associate alternatives for 
content or content fragments."

It does not say "require a mechanism".

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Fri, 08 Oct 2004 08:11:27 -0700

> <content src="some.jpg" type="image/jpg" />

This is illegal per PaceReformedConetent3 because it doesn't have an 
<atom:summary>.

> Isofarro stated that the spec "screws the blind" if it doesn't include 
> a validity constraint that requires some sort of "alternative" element 
> or attribute. If such an element is available, but not a validity 
> constraint, are we still "screwing the blind"? It seems like a 
> judgement call for the author to make, based on the nature of the 
> content.

We *have* a constraint: that atom:summary is required in any case where 
the content is not locally provided or is is not text/* or *xml.  Thus, 
I claim the spec currently meets the bar for accessibility. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Fri, 08 Oct 2004 11:40:02 -0400

> I claim the spec currently meets the bar for accessibility. -Tim

I know we have a constraint. I question whether the constraint helps
accessibility.

<entry>
...
<title>My First Program</title>
<summary type="HTML">&lt;img src="my_thumbnail.jpg"></summary>
<content src="my.jpg" type="image/jpg" />
</entry>

Robert Sayre

---

From: Isofarro <[email-masked]>
Date: Fri, 08 Oct 2004 17:32:00 +0100

Robert Sayre wrote:

> Tim Bray wrote:
>> We *have* a constraint: that atom:summary is required in any case 
>> where the content is not locally provided or is is not text/* or 
>> *xml.  Thus, I claim the spec currently meets the bar for 
>> accessibility. -Tim
> 

As I understand it, this meets the Atom part of the 
specification. But fails on the HTML part. If you are using an 
img element (as in the summary), then the alt attribute is 
required [1].

Interesting to compare your example against the specific WCAG 
1.0 guideline to non-text content [2]:

specifically: "This guideline emphasizes the importance of 
providing text equivalents of non-text content (images, 
pre-recorded audio, video)."

The XML Accessibility Guidelines seem to correlate with this 
understanding, since references checkpoint 1.1 of the WCAG1.0 
which is [3]:

"Provide a text equivalent for every non-text element (e.g., via 
"alt", "longdesc", or in element content)."

More to the point, accessibility can be improved by emphasising 
(as WCAG1.0 and XAG do) the importance of providing text 
equivalents to non-text content. I'd suggest also that or 
accessible HTML equivalents can be used instead of text where 
possible.

So in case of the summary, the following should be sufficient:

<summary type="HTML">&lt;img src="my_thumbnail.jpg" alt="My day 
job - dressed as a penguin"></summary>

Mike.

[1] <url:http://www.w3.org/TR/html401/struct/objects.html#h-13.2>
[2] 
<url:http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#gl-provide-equivalents>
[3] <url:http://www.w3.org/TR/xag#g1_0>

---

From: Robert Sayre <[email-masked]>
Date: Fri, 08 Oct 2004 12:59:21 -0400

> As I understand it, this meets the Atom part of the specification. But 
> fails on the HTML part. If you are using an img element (as in the 
> summary), then the alt attribute is required [1].

Only in HTML 4, and note that I could have whitespace, linebreaks, or 
any other nonsense in there.

> 
> Interesting to compare your example against the specific WCAG 1.0 
> guideline to non-text content [2]:
> 
> specifically: "This guideline emphasizes the importance of providing 
> text equivalents of non-text content (images, pre-recorded audio, video)."
> 
> understanding, since references checkpoint 1.1 of the WCAG1.0 which is [3]:
> 
> "Provide a text equivalent for every non-text element (e.g., via "alt", 
> "longdesc", or in element content)."

We provide summary elements and links. It's also interesting to compare 
my point of view with the example XML dialect given in checkpoint 1.1 of 
the XAG document, SVG.

"When a graphic does not include explanatory text content, it requires a 
text equivalent. If the equivalent is complex, use the 'desc' element, 
otherwise use the 'title' child element."

-- http://www.w3.org/TR/SVG/access.html

> 
> 
> More to the point, accessibility can be improved by emphasising (as 
> WCAG1.0 and XAG do) the importance of providing text equivalents to 
> non-text content. I'd suggest also that or accessible HTML equivalents 
> can be used instead of text where possible.
> 
> <summary type="HTML">&lt;img src="my_thumbnail.jpg" alt="My day job - 
> dressed as a penguin"></summary>
> 

I agree that we should emphasize it. It's not clear to me that required 
elements are a productive way to do that. We are still "providing" 
accessibility if the choice of elements are left to the author.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Fri, 08 Oct 2004 13:19:19 -0700

> <content src="my.jpg" type="image/jpg" />

You can't legislate against stupidity or perversity.  To quote Mark 
[http://imc.org/atom-syntax/mail-archive/msg10365.html]: "If individual 
authors choose to publish inaccessible content, that is an 
education/advocacy problem.  If individual authors are unable to 
publish accessible content, that is a specification problem."

I think the rules around atom:summary give us a good accessibility 
story.  If you or MarkP wanted to propose some language to improve the 
advocacy in the spec, that would be fine. -Tim

---

From: Karl Dubost <[email-masked]>
Date: Fri, 8 Oct 2004 13:49:09 -0400

<entry>
...
<title>A Picture of My Trip To The Lake</title>
<content src="some.jpg" type="image/jpg">
Beach and Trees at the Lake
<content>
</entry>

This is an accessible constructs. The title is not completely necessary 
related to your pictures as you may notice here. Because your title is 
not a description of the picture but the contextual meaning of the 
picture which is different.

Hope it helps to understand.

-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***

---

From: Martin Duerst <[email-masked]>
Date: Sat, 09 Oct 2004 09:34:15 +0900

>We *have* a constraint: that atom:summary is required in any case where 
the content is not locally provided or is is not text/* or *xml.  Thus, I 
claim the spec currently meets the bar for accessibility. -Tim

I think on first approximation, it does. But looking at the details,
it may not be that easy. There are lots of different xml formats.
Some of them are trivially accessible, some of the are unaccessible
to some people, some are tough to handle for virtually anybody.

I think the atom content spec should have a section on accessibility
in a similar way it has a section on security issues.
[If anybody thinks this is a good idea, please start a Pace.
I won't have the time to get around to do it for at least a few weeks
(and I don't think I'm an expert, either).]

Regards,    Martin.