<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Alternative Text for Significant Images</title>
	<atom:link href="http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/</link>
	<description>Tips and Commentary on Web Accessibility, Usability, and Search Marketing best practices.</description>
	<pubDate>Sat, 11 Oct 2008 18:14:54 +0000</pubDate>
	<generator>http://wordpress.org/?v=abc</generator>
		<item>
		<title>By: Joe Dolson</title>
		<link>http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23772</link>
		<dc:creator>Joe Dolson</dc:creator>
		<pubDate>Sun, 06 Jan 2008 20:27:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23772</guid>
		<description>Thanks, Mike!</description>
		<content:encoded><![CDATA[<p>Thanks,&nbsp;Mike!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Cherim</title>
		<link>http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23771</link>
		<dc:creator>Mike Cherim</dc:creator>
		<pubDate>Sun, 06 Jan 2008 03:56:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23771</guid>
		<description>None of that wasn't lost on me, Joe. From this post or your recent one. I guess I'm just echoing your sentiments. To make my contribution here official, though, I will formally cast my vote for keeping the alt rules as are and expend any and all previously slated energies into further clarification of current usage to ensure the existing rules are implemented in such a way that supports best practices: standards, accessibility, and usability. I feel this strategy is what HTML 5 should embrace.</description>
		<content:encoded><![CDATA[<p>None of that wasn&#8217;t lost on me, Joe. From this post or your recent one. I guess I&#8217;m just echoing your sentiments. To make my contribution here official, though, I will formally cast my vote for keeping the alt rules as are and expend any and all previously slated energies into further clarification of current usage to ensure the existing rules are implemented in such a way that supports best practices: standards, accessibility, and usability. I feel this strategy is what <acronym title="HyperText Markup Language">HTML</acronym> 5 should&nbsp;embrace.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Dolson</title>
		<link>http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23769</link>
		<dc:creator>Joe Dolson</dc:creator>
		<pubDate>Sat, 05 Jan 2008 16:29:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23769</guid>
		<description>&lt;blockquote&gt;
I wonder if this is indicative of a consensus of it not being, or perceived as not being, broken as is now. I mean I don’t think there’s any issue with the rules surrounding the tag’s usage, and I think it being used and left empty if the image has no significance is a good thing.
&lt;/blockquote&gt;

Which may be the problem: a lack of understanding concerning what I'm discussing. Perhaps the realization that the HTML 5 specification, as it exists today, currently &lt;em&gt;does&lt;/em&gt; allow (and even require) the &lt;code&gt;alt&lt;/code&gt; attribute to be excluded on certain types of significant images. 

There are two possible approaches to changing the HTML 5 specifications in this situation: fighting to remove that exclusion, so that we continue to use the existing standards (which I'm quite comfortable with), or attempting to come up with an alternate syntax which would allow the semantic situations described in the specification to be taken into consideration &lt;em&gt;without&lt;/em&gt; requiring the &lt;code&gt;alt&lt;/code&gt; attribute to be removed. 

I'm attempting to gather thoughts concerning these alternatives: there are many arguments on the web concerning fighting against the entire idea, but very little in the way of coming up with an alternative. ("Having our cake and eating it, too.")

&lt;blockquote&gt;
I’m afraid if the attribute become optional, a lot of people won’t use it and the situation will worsen.
&lt;/blockquote&gt;

So am I --- and that's why this post, and conversation, exists: to attempt to find a new way of authoring the specification so that there is no longer a clause which allows the exclusion of the &lt;code&gt;alt&lt;/code&gt; attribute.</description>
		<content:encoded><![CDATA[<blockquote><p>
I wonder if this is indicative of a consensus of it not being, or perceived as not being, broken as is now. I mean I don’t think there’s any issue with the rules surrounding the tag’s usage, and I think it being used and left empty if the image has no significance is a good thing.
</p></blockquote>
<p>Which may be the problem: a lack of understanding concerning what I&#8217;m discussing. Perhaps the realization that the <acronym title="HyperText Markup Language">HTML</acronym> 5 specification, as it exists today, currently <em>does</em> allow (and even require) the <code>alt</code> attribute to be excluded on certain types of significant images. </p>
<p>There are two possible approaches to changing the <acronym title="HyperText Markup Language">HTML</acronym> 5 specifications in this situation: fighting to remove that exclusion, so that we continue to use the existing standards (which I&#8217;m quite comfortable with), or attempting to come up with an alternate syntax which would allow the semantic situations described in the specification to be taken into consideration <em>without</em> requiring the <code>alt</code> attribute to be removed. </p>
<p>I&#8217;m attempting to gather thoughts concerning these alternatives: there are many arguments on the web concerning fighting against the entire idea, but very little in the way of coming up with an alternative. (&#8220;Having our cake and eating it, too.&#8221;)</p>
<blockquote><p>
I’m afraid if the attribute become optional, a lot of people won’t use it and the situation will worsen.
</p></blockquote>
<p>So am I&thinsp;&#8212;&thinsp;- and that&#8217;s why this post, and conversation, exists: to attempt to find a new way of authoring the specification so that there is no longer a clause which allows the exclusion of the <code>alt</code>&nbsp;attribute.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Cherim</title>
		<link>http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23768</link>
		<dc:creator>Mike Cherim</dc:creator>
		<pubDate>Sat, 05 Jan 2008 15:30:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23768</guid>
		<description>&lt;blockquote cite="#comment-23767"&gt;
You know, an interesting thing about the comments on this post is that not one has actually had any alternate suggestion concerning eliminating the alt attribute [...]
&lt;/blockquote&gt;

I wonder if this is indicative of a consensus of it not being, or perceived as not being, broken as is now. I mean I don't think there's any issue with the rules surrounding the tag's usage, and I think it being used and left empty if the image has no significance is a good thing. That is like saying it is unimportant, ignore it. I'm afraid if the attribute become optional, a lot of people won't use it and the situation will worsen.

&lt;blockquote cite="#comment-23767"&gt;
[...] the HTML 5 spec actual describes very nearly exactly what you propose in some detail [...]
&lt;/blockquote&gt;

Cool. I feel usage clarification is what's needed most, not a change to the spec.</description>
		<content:encoded><![CDATA[<blockquote cite="#comment-23767"><p>
You know, an interesting thing about the comments on this post is that not one has actually had any alternate suggestion concerning eliminating the alt attribute [&#8230;]
</p></blockquote>
<p>I wonder if this is indicative of a consensus of it not being, or perceived as not being, broken as is now. I mean I don&#8217;t think there&#8217;s any issue with the rules surrounding the tag&#8217;s usage, and I think it being used and left empty if the image has no significance is a good thing. That is like saying it is unimportant, ignore it. I&#8217;m afraid if the attribute become optional, a lot of people won&#8217;t use it and the situation will worsen.</p>
<blockquote cite="#comment-23767"><p>
[&#8230;] the <acronym title="HyperText Markup Language">HTML</acronym> 5 spec actual describes very nearly exactly what you propose in some detail [&#8230;]
</p></blockquote>
<p>Cool. I feel usage clarification is what&#8217;s needed most, not a change to the&nbsp;spec.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Dolson</title>
		<link>http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23767</link>
		<dc:creator>Joe Dolson</dc:creator>
		<pubDate>Sat, 05 Jan 2008 05:53:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23767</guid>
		<description>You know, an interesting thing about the comments on this post is that not one has actually had any alternate suggestion concerning eliminating the &lt;code&gt;alt&lt;/code&gt; attribute in the specific case where a significant image does not have available or practical &lt;code&gt;alt&lt;/code&gt; text, as  currently proposed in HTML 5.

Which, as it happens, was the point of the article.

I do value the discussions on the merit (and flaws) of the ideas I mentioned; but I was hoping to come up with something &lt;em&gt;new&lt;/em&gt;, as well, rather than re-hashing the issue of "appropriate use of the &lt;code&gt;alt&lt;/code&gt;attribute." 

This suggests to me something rather significant concerning the sheer challenge of solving the problem, as defined previously. 

@Mike - the HTML 5 spec actual describes very nearly exactly what you propose in some detail --- it's well specified, except that it includes one additional categories: images which are significant but which exist in a context where &lt;code&gt;alt&lt;/code&gt; text must be automatically generated and may not be provided by the author. 

It's somewhat debatable whether it's the responsibility of the syntax to come up with a solution to this problem, honestly, rather than the responsibility of an author, but in the clearly relevant world of user-generated content, it does seem meaningful to discuss the possibility of determining some alternative.</description>
		<content:encoded><![CDATA[<p>You know, an interesting thing about the comments on this post is that not one has actually had any alternate suggestion concerning eliminating the <code>alt</code> attribute in the specific case where a significant image does not have available or practical <code>alt</code> text, as  currently proposed in <acronym title="HyperText Markup Language">HTML</acronym> 5.</p>
<p>Which, as it happens, was the point of the article.</p>
<p>I do value the discussions on the merit (and flaws) of the ideas I mentioned; but I was hoping to come up with something <em>new</em>, as well, rather than re-hashing the issue of &#8220;appropriate use of the <code>alt</code>attribute.&#8221; </p>
<p>This suggests to me something rather significant concerning the sheer challenge of solving the problem, as defined previously. </p>
<p>@Mike - the <acronym title="HyperText Markup Language">HTML</acronym> 5 spec actual describes very nearly exactly what you propose in some detail&thinsp;&#8212;&thinsp;- it&#8217;s well specified, except that it includes one additional categories: images which are significant but which exist in a context where <code>alt</code> text must be automatically generated and may not be provided by the author. </p>
<p>It&#8217;s somewhat debatable whether it&#8217;s the responsibility of the syntax to come up with a solution to this problem, honestly, rather than the responsibility of an author, but in the clearly relevant world of user-generated content, it does seem meaningful to discuss the possibility of determining some&nbsp;alternative.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Cherim</title>
		<link>http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23766</link>
		<dc:creator>Mike Cherim</dc:creator>
		<pubDate>Sat, 05 Jan 2008 05:42:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23766</guid>
		<description>As you know Joe, based on &lt;a href="http://green-beast.com/blog/?p=81"&gt;my old article&lt;/a&gt; on this, I feel the secret to using the alt attribute correctly, to the most benefit that is, is to have a specific protocol for assessing the image. If it's done right, the best choice can be made consistently.

This is how I defined it in the article, and I still think this holds true in my mind:

&lt;blockquote cite="http://green-beast.com/blog/?p=81"&gt;
1. &lt;strong&gt;Decorative&lt;/strong&gt; or style images are those used solely for decorative purposes. Most often, with today's site-building methods, decorative images are backgrounds and not embedded images at all. In other words, using today's web development methodologies, there should be next to no purely decorative images embedded in an HTML document.

2. &lt;strong&gt;Relative&lt;/strong&gt; or identifying images are those used for decorative purposes, but lend themselves well to the content or have some iconic function relative to said content. An example of this can be shown embedded and floated by my copyright statement. The image is a symbol relating to the copyright subject matter.

3. &lt;strong&gt;Descriptive&lt;/strong&gt; or Supporting images, help the content succeed, but aren’t necessarily critical to it. One example would be an image of a house next to a real estate listing. For sighted web visitors, this image lends some value.

4. &lt;strong&gt;Definitive&lt;/strong&gt; or Content images are the content. A good example of this would be a location map for a retail store.
&lt;/blockquote&gt;

Regarding linked images: as far as I'm concerned they require alt text. 

And as far as the alt attribute used to describe an image to the non-sighted: I have to disagree. I feel it's much better to offer the alt attribute, and then leave it null (following the assessment criteria above). The vast majority of my embedded images are null. They're using floated in some content and if they are to be described are done so in the text. This allows me to ensure the description in the right spot within the flow. Otherwise the alt text would sound out of place.

Now some people will state that ALL decorative images should be backgrounds put in by CSS. I strongly disagree with this. First of all a decorative image may be part of specific content (like my blog post images). To do this, and to make the text wrap it, I'd have to float some HTML structure, then make an entry in my style sheet --- for each post!</description>
		<content:encoded><![CDATA[<p>As you know Joe, based on <a href="http://green-beast.com/blog/?p=81">my old article</a> on this, I feel the secret to using the alt attribute correctly, to the most benefit that is, is to have a specific protocol for assessing the image. If it&#8217;s done right, the best choice can be made consistently.</p>
<p>This is how I defined it in the article, and I still think this holds true in my mind:</p>
<blockquote cite="http://green-beast.com/blog/?p=81"><p>
1. <strong>Decorative</strong> or style images are those used solely for decorative purposes. Most often, with today&#8217;s site-building methods, decorative images are backgrounds and not embedded images at all. In other words, using today&#8217;s web development methodologies, there should be next to no purely decorative images embedded in an <acronym title="HyperText Markup Language">HTML</acronym> document.</p>
<p>2. <strong>Relative</strong> or identifying images are those used for decorative purposes, but lend themselves well to the content or have some iconic function relative to said content. An example of this can be shown embedded and floated by my copyright statement. The image is a symbol relating to the copyright subject matter.</p>
<p>3. <strong>Descriptive</strong> or Supporting images, help the content succeed, but aren’t necessarily critical to it. One example would be an image of a house next to a real estate listing. For sighted web visitors, this image lends some value.</p>
<p>4. <strong>Definitive</strong> or Content images are the content. A good example of this would be a location map for a retail store.
</p></blockquote>
<p>Regarding linked images: as far as I&#8217;m concerned they require alt text. </p>
<p>And as far as the alt attribute used to describe an image to the non-sighted: I have to disagree. I feel it&#8217;s much better to offer the alt attribute, and then leave it null (following the assessment criteria above). The vast majority of my embedded images are null. They&#8217;re using floated in some content and if they are to be described are done so in the text. This allows me to ensure the description in the right spot within the flow. Otherwise the alt text would sound out of place.</p>
<p>Now some people will state that ALL decorative images should be backgrounds put in by <acronym title="Cascading Style Sheets">CSS</acronym>. I strongly disagree with this. First of all a decorative image may be part of specific content (like my blog post images). To do this, and to make the text wrap it, I&#8217;d have to float some <acronym title="HyperText Markup Language">HTML</acronym> structure, then make an entry in my style sheet&thinsp;&#8212;&thinsp;- for each&nbsp;post!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Dolson</title>
		<link>http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23762</link>
		<dc:creator>Joe Dolson</dc:creator>
		<pubDate>Fri, 04 Jan 2008 00:25:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23762</guid>
		<description>I figured it might be something like that. 

As to joining the working group, I've already applied (following the comment from Ian Hickson on 12/25) - but haven't heard back yet. I'm in the "You should get a reply back within about ten days, at which point you can fill in the Joining the HTML Working Group form." stage.</description>
		<content:encoded><![CDATA[<p>I figured it might be something like that. </p>
<p>As to joining the working group, I&#8217;ve already applied (following the comment from Ian Hickson on 12/25) - but haven&#8217;t heard back yet. I&#8217;m in the &#8220;You should get a reply back within about ten days, at which point you can fill in the Joining the <acronym title="HyperText Markup Language">HTML</acronym> Working Group form.&#8221;&nbsp;stage.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Geoffrey Sneddon</title>
		<link>http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23761</link>
		<dc:creator>Geoffrey Sneddon</dc:creator>
		<pubDate>Thu, 03 Jan 2008 23:52:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23761</guid>
		<description>FWIW, I was taking what you meant as something like:
&lt;blockquote&gt;If the image is a key part of the content and has no obvious textual alternative, then a &lt;code&gt;notsignificant&lt;/code&gt; attribute must be present. The notsignificant attribute is a boolean attribute.&lt;/blockquote&gt;

With such text in the spec, current generators' output would be non-conforming.

Regardless, I'd invite you to take a more direct part in the work, you can find instructions on joining the effort here:

http://blog.whatwg.org/w3c-restarts-html-effort</description>
		<content:encoded><![CDATA[<p>FWIW, I was taking what you meant as something like:</p>
<blockquote><p>If the image is a key part of the content and has no obvious textual alternative, then a <code>notsignificant</code> attribute must be present. The notsignificant attribute is a boolean attribute.</p></blockquote>
<p>With such text in the spec, current generators&#8217; output would be non-conforming.</p>
<p>Regardless, I&#8217;d invite you to take a more direct part in the work, you can find instructions on joining the effort here:&nbsp;<a href="http://blog.whatwg.org/w3c-restarts-html-effort">http://blog.whatwg.org/w3c-restarts-<acronym title="HyperText Markup Language">HTML</acronym>-effort</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Dolson</title>
		<link>http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23760</link>
		<dc:creator>Joe Dolson</dc:creator>
		<pubDate>Thu, 03 Jan 2008 22:43:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23760</guid>
		<description>&lt;blockquote&gt;
As your using @alt without @notsignificant, you aren’t using @alt for it’s appropriate semantic purpose, you fall foul of that must condition (which therefore means the document is non-conformant).
&lt;/blockquote&gt;

I guess I don't really agree with this: the signifier attribute should not be in any way relative to the &lt;code&gt;alt&lt;/code&gt; attribute. Regardless of whether there is an attribute present which would indicate the significance of the image, the value of the &lt;code&gt;alt&lt;/code&gt; attribute is semantically meaningful as an alternative text. Both attributes are relative to the &lt;code&gt;img&lt;/code&gt; element, not to each other.

Regardless, the method obviously has issues.</description>
		<content:encoded><![CDATA[<blockquote><p>
As your using @alt without @notsignificant, you aren’t using @alt for it’s appropriate semantic purpose, you fall foul of that must condition (which therefore means the document is non-conformant).
</p></blockquote>
<p>I guess I don&#8217;t really agree with this: the signifier attribute should not be in any way relative to the <code>alt</code> attribute. Regardless of whether there is an attribute present which would indicate the significance of the image, the value of the <code>alt</code> attribute is semantically meaningful as an alternative text. Both attributes are relative to the <code>img</code> element, not to each other.</p>
<p>Regardless, the method obviously has&nbsp;issues.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Geoffrey Sneddon</title>
		<link>http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23759</link>
		<dc:creator>Geoffrey Sneddon</dc:creator>
		<pubDate>Thu, 03 Jan 2008 22:09:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.joedolson.com/articles/2008/01/alternative-text-for-significant-images/#comment-23759</guid>
		<description>&lt;blockquote cite="#comment-23752"&gt;No, I don’t think that’s true: this would not be a required attribute. If, as I proposed, HTML 5 would assume a default value for the new attribute, then older generators would simply be flawed in that all images would be assumed to be significant.
I agree that this is a problem, but I don’t think it would create non-conformance.&lt;/blockquote&gt;

As you rightfully point out, all images are therefore significant. Omitting the attribute that denotes that @alt isn't significant has a semantic meaning, and as a paraphrased before…

&lt;blockquote cite="http://www.whatwg.org/specs/web-apps/current-work/"&gt;Authors must only use elements, attributes, and attribute values for their appropriate semantic purposes.&lt;/blockquote&gt;

As your using @alt without @notsignificant, you aren't using @alt for it's appropriate semantic purpose, you fall foul of that must condition (which therefore means the document is non-conformant).</description>
		<content:encoded><![CDATA[<blockquote cite="#comment-23752"><p>No, I don’t think that’s true: this would not be a required attribute. If, as I proposed, <acronym title="HyperText Markup Language">HTML</acronym> 5 would assume a default value for the new attribute, then older generators would simply be flawed in that all images would be assumed to be significant.<br />
I agree that this is a problem, but I don’t think it would create non-conformance.</p></blockquote>
<p>As you rightfully point out, all images are therefore significant. Omitting the attribute that denotes that @alt isn&#8217;t significant has a semantic meaning, and as a paraphrased before…</p>
<blockquote cite="http://www.whatwg.org/specs/web-apps/current-work/"><p>Authors must only use elements, attributes, and attribute values for their appropriate semantic purposes.</p></blockquote>
<p>As your using @alt without @notsignificant, you aren&#8217;t using @alt for it&#8217;s appropriate semantic purpose, you fall foul of that must condition (which therefore means the document is&nbsp;non-conformant).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
