<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Communicating error messages accessibly</title>
	<atom:link href="http://www.standards-schmandards.com/2005/accessible-errors/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.standards-schmandards.com/2005/accessible-errors/</link>
	<description>A pragmatic approach to web standards and accessibility</description>
	<lastBuildDate>Thu, 02 Sep 2010 11:45:45 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: vp</title>
		<link>http://www.standards-schmandards.com/2005/accessible-errors/comment-page-1/#comment-190</link>
		<dc:creator>vp</dc:creator>
		<pubDate>Fri, 16 Sep 2005 14:34:46 +0000</pubDate>
		<guid isPermaLink="false">http://localhost:8888/?p=34#comment-190</guid>
		<description>&lt;p&gt;I won&#039;t make the full sentence a link I prefer this&lt;/p&gt; &lt;p&gt;The Age field can not be empty.&lt;/p&gt; &lt;p&gt;Please &lt;a href=&quot;self.php#age&quot;&gt;enter your age&lt;/a href&gt; in years.&lt;/p&gt; &lt;p&gt;so the user can guess he can follow a link (otherwise he only sees a sentence with emphasis (=underlined))&lt;/p&gt; &lt;p&gt;You should provide a valid exemple ...age in years (eg: 21) and not &quot;twenty-one&quot;&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>I won&#8217;t make the full sentence a link I prefer this</p>
<p>The Age field can not be empty.</p>
<p>Please &lt;a href=&#8221;self.php#age&#8221;&gt;enter your age&lt;/a href&gt; in years.</p>
<p>so the user can guess he can follow a link (otherwise he only sees a sentence with emphasis (=underlined))</p>
<p>You should provide a valid exemple &#8230;age in years (eg: 21) and not &#8220;twenty-one&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: web designer</title>
		<link>http://www.standards-schmandards.com/2005/accessible-errors/comment-page-1/#comment-183</link>
		<dc:creator>web designer</dc:creator>
		<pubDate>Fri, 26 Aug 2005 14:32:29 +0000</pubDate>
		<guid isPermaLink="false">http://localhost:8888/?p=34#comment-183</guid>
		<description>&lt;p&gt;great article.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>great article.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rich</title>
		<link>http://www.standards-schmandards.com/2005/accessible-errors/comment-page-1/#comment-168</link>
		<dc:creator>Rich</dc:creator>
		<pubDate>Mon, 11 Jul 2005 21:15:12 +0000</pubDate>
		<guid isPermaLink="false">http://localhost:8888/?p=34#comment-168</guid>
		<description>&lt;p&gt;Nice article. As a jaws user, I&#039;d suggest the setfocus approach (the one originally discussed in the article). The ability to click on the error message itself and be taken right to the erroneous input is nice.&lt;/p&gt; &lt;p&gt;Maybe one suggestion would be to issue an alert, even if multiple errors were found. The alert would simply say &quot;We had trouble processing your form. See specific error messages on tthe following page (or something like that).&quot; The idea being that the alert is beeps and can alert the screen reader user that the submission failed. Its sometimes easy to not notice error messages because there is no way to make them jump out at you when using a screen reader. Using a heading to introduce a list of errors is the right thing to do, but it is only findable if the user goes and looks; it doesn&#039;t jump up and announce itself. So, having a number of different ways of making the fact known that an error was found is the thing to do. So, a heading introducing a list of errors, an indication in the page title itself (sometimes the page title is announced by the screen reader when the page is refreshed), and an alert announcing that there were problems and twhere to look for more info are all helpful mechanisms to apply in tandem.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>Nice article. As a jaws user, I&#8217;d suggest the setfocus approach (the one originally discussed in the article). The ability to click on the error message itself and be taken right to the erroneous input is nice.</p>
<p>Maybe one suggestion would be to issue an alert, even if multiple errors were found. The alert would simply say &#8220;We had trouble processing your form. See specific error messages on tthe following page (or something like that).&#8221; The idea being that the alert is beeps and can alert the screen reader user that the submission failed. Its sometimes easy to not notice error messages because there is no way to make them jump out at you when using a screen reader. Using a heading to introduce a list of errors is the right thing to do, but it is only findable if the user goes and looks; it doesn&#8217;t jump up and announce itself. So, having a number of different ways of making the fact known that an error was found is the thing to do. So, a heading introducing a list of errors, an indication in the page title itself (sometimes the page title is announced by the screen reader when the page is refreshed), and an alert announcing that there were problems and twhere to look for more info are all helpful mechanisms to apply in tandem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Terrence Wood</title>
		<link>http://www.standards-schmandards.com/2005/accessible-errors/comment-page-1/#comment-165</link>
		<dc:creator>Terrence Wood</dc:creator>
		<pubDate>Wed, 06 Jul 2005 03:18:46 +0000</pubDate>
		<guid isPermaLink="false">http://localhost:8888/?p=34#comment-165</guid>
		<description>&lt;p&gt;A suggestion for friendly error messages.&lt;/p&gt; &lt;p&gt;&quot;We were unable to process your form. Some information was either missing or not understood.&lt;/p&gt; &lt;p&gt;Please check the following, and submit the form again:&lt;/p&gt; &lt;p&gt;* The Name field can not be empty. Please enter your name.&lt;br/&gt;* The Age field can not be empty. Please enter your age in years.&quot;&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>A suggestion for friendly error messages.</p>
<p>&#8220;We were unable to process your form. Some information was either missing or not understood.</p>
<p>Please check the following, and submit the form again:</p>
<p>* The Name field can not be empty. Please enter your name.<br />* The Age field can not be empty. Please enter your age in years.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roger Johansson</title>
		<link>http://www.standards-schmandards.com/2005/accessible-errors/comment-page-1/#comment-164</link>
		<dc:creator>Roger Johansson</dc:creator>
		<pubDate>Thu, 30 Jun 2005 19:52:49 +0000</pubDate>
		<guid isPermaLink="false">http://localhost:8888/?p=34#comment-164</guid>
		<description>&lt;p&gt;That would probably have to be a confirm dialog to allow the form to be submitted without fixing the errors, that&#039;s right.&lt;/p&gt; &lt;p&gt;Presenting the problems on the page is probably better, but less obvious.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>That would probably have to be a confirm dialog to allow the form to be submitted without fixing the errors, that&#8217;s right.</p>
<p>Presenting the problems on the page is probably better, but less obvious.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete</title>
		<link>http://www.standards-schmandards.com/2005/accessible-errors/comment-page-1/#comment-163</link>
		<dc:creator>Pete</dc:creator>
		<pubDate>Mon, 27 Jun 2005 10:01:20 +0000</pubDate>
		<guid isPermaLink="false">http://localhost:8888/?p=34#comment-163</guid>
		<description>&lt;p&gt;&lt;strong&gt;Tanny:&lt;/strong&gt; That is a good suggestion and I have made an &lt;a href=&quot;/exhibits/errors/label.php&quot;&gt;example with the label element here&lt;/a&gt;. The HTML spec allows for multiple label elements for the same field. However, I would recommend that the label element in the error text only spans the name of the field in order to avoid confusion for browsing devices that may display form information in a different context. One drawback of this method is that users navigating without a mouse are unable to click the error message (it is not highlighted as a link). Other users may miss that it is clickable becasue the label does not look like a link. This could be taken care of in the CSS of course.&lt;/p&gt; &lt;p&gt;&lt;strong&gt;Martin:&lt;/strong&gt; Attaching event handling code on window.onload should be done with caution (even if it is a nice way to separate script from markup). In my experience from Fangs I have noticed that for large DOMs it may take a while to find elements and modify them. In that time users may already have clicked something or done something else that prevents all the event handling code from being set.&lt;/p&gt; &lt;p&gt;&lt;strong&gt;Roger:&lt;/strong&gt; I am not sure if I understand exactly how you would do it. Are you thinking an alert or a modal dialog window? For alerts there are som drawbacks: How would you allow the user to submit the form without fixing the errors first if your alert is triggered by the submit button? Alerts are harder to format nicely and there is no semantic information. This is of course bad for multiple errors if you are using e.g. JAWS.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p><strong>Tanny:</strong> That is a good suggestion and I have made an <a href="/exhibits/errors/label.php">example with the label element here</a>. The HTML spec allows for multiple label elements for the same field. However, I would recommend that the label element in the error text only spans the name of the field in order to avoid confusion for browsing devices that may display form information in a different context. One drawback of this method is that users navigating without a mouse are unable to click the error message (it is not highlighted as a link). Other users may miss that it is clickable becasue the label does not look like a link. This could be taken care of in the CSS of course.</p>
<p><strong>Martin:</strong> Attaching event handling code on window.onload should be done with caution (even if it is a nice way to separate script from markup). In my experience from Fangs I have noticed that for large DOMs it may take a while to find elements and modify them. In that time users may already have clicked something or done something else that prevents all the event handling code from being set.</p>
<p><strong>Roger:</strong> I am not sure if I understand exactly how you would do it. Are you thinking an alert or a modal dialog window? For alerts there are som drawbacks: How would you allow the user to submit the form without fixing the errors first if your alert is triggered by the submit button? Alerts are harder to format nicely and there is no semantic information. This is of course bad for multiple errors if you are using e.g. JAWS.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tanny O'Haley</title>
		<link>http://www.standards-schmandards.com/2005/accessible-errors/comment-page-1/#comment-162</link>
		<dc:creator>Tanny O'Haley</dc:creator>
		<pubDate>Sun, 26 Jun 2005 19:00:54 +0000</pubDate>
		<guid isPermaLink="false">http://localhost:8888/?p=34#comment-162</guid>
		<description>&lt;p&gt;Very nice article, although, I would replace the onclick events with label elements. If the user has javascript turned off the browser should put focus on the field when the user clicks or selects the label.&lt;/p&gt; &lt;p&gt;John,&lt;/p&gt; &lt;p&gt;I&#039;m sorry you were shocked by the use of the word error. One of the definitions of error is:&lt;/p&gt; &lt;p&gt;n 1: a wrong action attributable to bad judgment or ignorance or inattention;&lt;/p&gt; &lt;p&gt;I believe that this applies to a user who has not entered data or has entered incorrect data in a field. The word &quot;error&quot; has been used for informing a user of invalid data since before I started programming in 1980. Used in this context would be considered &quot;common&quot; usage.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>Very nice article, although, I would replace the onclick events with label elements. If the user has javascript turned off the browser should put focus on the field when the user clicks or selects the label.</p>
<p>John,</p>
<p>I&#8217;m sorry you were shocked by the use of the word error. One of the definitions of error is:</p>
<p>n 1: a wrong action attributable to bad judgment or ignorance or inattention;</p>
<p>I believe that this applies to a user who has not entered data or has entered incorrect data in a field. The word &#8220;error&#8221; has been used for informing a user of invalid data since before I started programming in 1980. Used in this context would be considered &#8220;common&#8221; usage.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin Smales</title>
		<link>http://www.standards-schmandards.com/2005/accessible-errors/comment-page-1/#comment-161</link>
		<dc:creator>Martin Smales</dc:creator>
		<pubDate>Sun, 26 Jun 2005 10:52:59 +0000</pubDate>
		<guid isPermaLink="false">http://localhost:8888/?p=34#comment-161</guid>
		<description>&lt;p&gt;Great article, although, it can be improved by replacing onclick events with CSS class names, giving way to unobtrusive JavaScript.&lt;/p&gt; &lt;p&gt;How-to: &lt;a href=&quot;http://adactio.com/atmedia2005/&quot;&gt;http://adactio.com/atmedia2005/&lt;/a&gt;&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>Great article, although, it can be improved by replacing onclick events with CSS class names, giving way to unobtrusive JavaScript.</p>
<p>How-to: <a href="http://adactio.com/atmedia2005/">http://adactio.com/atmedia2005/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeroen Mulder</title>
		<link>http://www.standards-schmandards.com/2005/accessible-errors/comment-page-1/#comment-160</link>
		<dc:creator>Jeroen Mulder</dc:creator>
		<pubDate>Sun, 26 Jun 2005 00:19:11 +0000</pubDate>
		<guid isPermaLink="false">http://localhost:8888/?p=34#comment-160</guid>
		<description>&lt;p&gt;Pete, I do use the word &#039;error&#039;, but from a difference perspective.&lt;/p&gt; &lt;p&gt;&quot;An error occured while saving your new article. Please ensure the article title is not blank.&quot;&lt;/p&gt; &lt;p&gt;I tend to think that says the error was on our side, but the user might want to check for the following requirements. Granted, english isn&#039;t my first language either. ;-)&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>Pete, I do use the word &#8216;error&#8217;, but from a difference perspective.</p>
<p>&#8220;An error occured while saving your new article. Please ensure the article title is not blank.&#8221;</p>
<p>I tend to think that says the error was on our side, but the user might want to check for the following requirements. Granted, english isn&#8217;t my first language either. ;-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete</title>
		<link>http://www.standards-schmandards.com/2005/accessible-errors/comment-page-1/#comment-159</link>
		<dc:creator>Pete</dc:creator>
		<pubDate>Sun, 26 Jun 2005 00:13:35 +0000</pubDate>
		<guid isPermaLink="false">http://localhost:8888/?p=34#comment-159</guid>
		<description>&lt;p&gt;John: You may be corrent. English is not my first language and I sometimes fail to use the correct words. However, the example in the WebAIM discussion talks about &quot;errors&quot;. Does anyone else have any suggestions for terminology? What would be a polite way of informing the user about validation errors?&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>John: You may be corrent. English is not my first language and I sometimes fail to use the correct words. However, the example in the WebAIM discussion talks about &#8220;errors&#8221;. Does anyone else have any suggestions for terminology? What would be a polite way of informing the user about validation errors?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
