<?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: Web Accessibility &#8211; The Power of Five.</title>
	<atom:link href="http://www.headstar.com/eablive/?feed=rss2&#038;p=183" rel="self" type="application/rss+xml" />
	<link>http://www.headstar.com/eablive/?p=183</link>
	<description>Access to technology for all</description>
	<lastBuildDate>Sun, 01 Apr 2018 16:32:15 +0000</lastBuildDate>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=4.0.1</generator>
	<item>
		<title>By: David O'Brien</title>
		<link>http://www.headstar.com/eablive/?p=183&#038;cpage=1#comment-5359</link>
		<dc:creator><![CDATA[David O'Brien]]></dc:creator>
		<pubDate>Mon, 21 Jul 2008 19:09:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.headstar.com/eablive/?p=183#comment-5359</guid>
		<description><![CDATA[We recently relaunched our site and used server-side validation on forms, rather than javascript. Content spam has dropped dramatically (almost disappeared, in fact) since. The validation scripting is quite time-consuming, but if you subtract the amount of time colleagues are not dealing with spam, it is probably worth the effort (though I haven&#039;t done the sums yet).

We get about 100 enquiries a month through forms on our site. We completely rejected the option of CAPTCHA (although it had been requested by some colleagues) because of the accessibility issues; but also because it makes it harder for everyone to use, not just those with disabilities.  I have 20/20 vision and I sometimes have difficulty deciphering CAPTCHAs.

Another possibility we considered was simply to classify any form submission with a URL in it as spam. Over 95% of the spam we used to receive contained a URL. So just add a note in the label of your form inputs to say &#039;do not enter a URL&#039;, and write a script so that any submission containing the string &#039;http://&#039; is rejected.]]></description>
		<content:encoded><![CDATA[<p>We recently relaunched our site and used server-side validation on forms, rather than javascript. Content spam has dropped dramatically (almost disappeared, in fact) since. The validation scripting is quite time-consuming, but if you subtract the amount of time colleagues are not dealing with spam, it is probably worth the effort (though I haven&#8217;t done the sums yet).</p>
<p>We get about 100 enquiries a month through forms on our site. We completely rejected the option of CAPTCHA (although it had been requested by some colleagues) because of the accessibility issues; but also because it makes it harder for everyone to use, not just those with disabilities.  I have 20/20 vision and I sometimes have difficulty deciphering CAPTCHAs.</p>
<p>Another possibility we considered was simply to classify any form submission with a URL in it as spam. Over 95% of the spam we used to receive contained a URL. So just add a note in the label of your form inputs to say &#8216;do not enter a URL&#8217;, and write a script so that any submission containing the string &#8216;http://&#8217; is rejected.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Henry French</title>
		<link>http://www.headstar.com/eablive/?p=183&#038;cpage=1#comment-5358</link>
		<dc:creator><![CDATA[Henry French]]></dc:creator>
		<pubDate>Mon, 21 Jul 2008 16:32:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.headstar.com/eablive/?p=183#comment-5358</guid>
		<description><![CDATA[I&#039;m writing from Access Journal at RNIB, wondering if anyone has any ideas on the following points.

Should the whole idea of CAPTCHAs as a concept be abandoned? It seems that few web designers know about alternatives, especially for blind and partially sighted people. But even if we attempt to educate more designers about alternative CAPTCHAs, is spam software not going to soon improve to the point that it is too smart for CAPTCHAs anyway?

My understanding has always been (correct me if I&#039;m wrong) that the standard CAPTCHA - obscure letters on a busy background - was introduced to beat software that could read standard text and &#039;know&#039; how to fill in a form based on replicating a piece of text. This is why web designers do not use alt text tags - the same software could read that alt text and fill in a form.

But I thought that artificial intelligence was moving forward quickly, including in the abilities of programs to understand images and audio. I have a friend who could probably use a PhD project to this end if he was so inclined. Stuart above seems to have found a good idea - but I wonder whether programs will soon be able to &#039;think&#039; around this solution, or failing that, bombard developers like him with every potential solution to a question CAPTCHA.

Am I being crazily futuristic? Or should we look forward to a future in which we are all - regardless of ability to interact with CAPTCHAs - left waiting for hours or days for a human to authenticate online forms?

...I could ask if there will be programs in the future which forge online forms and then interact with authenticators, over the phone for example. But that&#039;s crazy talk.]]></description>
		<content:encoded><![CDATA[<p>I&#8217;m writing from Access Journal at RNIB, wondering if anyone has any ideas on the following points.</p>
<p>Should the whole idea of CAPTCHAs as a concept be abandoned? It seems that few web designers know about alternatives, especially for blind and partially sighted people. But even if we attempt to educate more designers about alternative CAPTCHAs, is spam software not going to soon improve to the point that it is too smart for CAPTCHAs anyway?</p>
<p>My understanding has always been (correct me if I&#8217;m wrong) that the standard CAPTCHA &#8211; obscure letters on a busy background &#8211; was introduced to beat software that could read standard text and &#8216;know&#8217; how to fill in a form based on replicating a piece of text. This is why web designers do not use alt text tags &#8211; the same software could read that alt text and fill in a form.</p>
<p>But I thought that artificial intelligence was moving forward quickly, including in the abilities of programs to understand images and audio. I have a friend who could probably use a PhD project to this end if he was so inclined. Stuart above seems to have found a good idea &#8211; but I wonder whether programs will soon be able to &#8216;think&#8217; around this solution, or failing that, bombard developers like him with every potential solution to a question CAPTCHA.</p>
<p>Am I being crazily futuristic? Or should we look forward to a future in which we are all &#8211; regardless of ability to interact with CAPTCHAs &#8211; left waiting for hours or days for a human to authenticate online forms?</p>
<p>&#8230;I could ask if there will be programs in the future which forge online forms and then interact with authenticators, over the phone for example. But that&#8217;s crazy talk.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stuart Harrison</title>
		<link>http://www.headstar.com/eablive/?p=183&#038;cpage=1#comment-5356</link>
		<dc:creator><![CDATA[Stuart Harrison]]></dc:creator>
		<pubDate>Fri, 18 Jul 2008 08:13:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.headstar.com/eablive/?p=183#comment-5356</guid>
		<description><![CDATA[We had loads of problems with Spam on our contact form - some of it quite offensive, and, as some of it was going directly to frontline staff with considerably thinner skin than me, I had to do something about it. 

Rather than going down the route of a traditional CAPTCHA, I used PHP to generate two numbers - one between 1 and 50, and another between 1 and 5, the second number of the first number never goes beyond 5, so the sum&#039;s answer never goes beyond the next 10 digit range (to make the sum easier). This is all wrapped in a label, so screenreader users can see the link between the question and the form and I&#039;ve never had another bit of Spam since!

The only thing that worries me is that this might lock out users with poor numeracy - am I being too cautious? Here&#039;s the form for reference:

http://www.lichfielddc.gov.uk/site/custom_scripts/feedback2.php]]></description>
		<content:encoded><![CDATA[<p>We had loads of problems with Spam on our contact form &#8211; some of it quite offensive, and, as some of it was going directly to frontline staff with considerably thinner skin than me, I had to do something about it. </p>
<p>Rather than going down the route of a traditional CAPTCHA, I used PHP to generate two numbers &#8211; one between 1 and 50, and another between 1 and 5, the second number of the first number never goes beyond 5, so the sum&#8217;s answer never goes beyond the next 10 digit range (to make the sum easier). This is all wrapped in a label, so screenreader users can see the link between the question and the form and I&#8217;ve never had another bit of Spam since!</p>
<p>The only thing that worries me is that this might lock out users with poor numeracy &#8211; am I being too cautious? Here&#8217;s the form for reference:</p>
<p><a href="http://www.lichfielddc.gov.uk/site/custom_scripts/feedback2.php" rel="nofollow">http://www.lichfielddc.gov.uk/site/custom_scripts/feedback2.php</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Jellinek</title>
		<link>http://www.headstar.com/eablive/?p=183&#038;cpage=1#comment-5342</link>
		<dc:creator><![CDATA[Dan Jellinek]]></dc:creator>
		<pubDate>Tue, 27 May 2008 10:56:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.headstar.com/eablive/?p=183#comment-5342</guid>
		<description><![CDATA[Thanks for these new comments, I will publish them in the next issue of E-Access Bulletin to stimulate further debate and to recruit testers for the CAPTCHA ideas!
all the best,
dan]]></description>
		<content:encoded><![CDATA[<p>Thanks for these new comments, I will publish them in the next issue of E-Access Bulletin to stimulate further debate and to recruit testers for the CAPTCHA ideas!<br />
all the best,<br />
dan</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Coltham</title>
		<link>http://www.headstar.com/eablive/?p=183&#038;cpage=1#comment-5341</link>
		<dc:creator><![CDATA[James Coltham]]></dc:creator>
		<pubDate>Mon, 26 May 2008 16:40:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.headstar.com/eablive/?p=183#comment-5341</guid>
		<description><![CDATA[Can I point out a small error in point number 5 where it says &quot;make sure that all images that are also links or buttons describe what will happen when you click on them, e.g. alternative text as &quot;Marilyn Monroe - click to read her life story&quot;. &quot;
 
This isn&#039;t really correct. The alternative description of an image should be the exact equivalent of its appearance. So if it&#039;s a photo of Marilyn Monroe with no text in the image, it should just be &#039;Marilyn Monroe&#039;. However, if that image is also a hyperlink, the title attribute of the link itself can be used to describe where the link goes to.]]></description>
		<content:encoded><![CDATA[<p>Can I point out a small error in point number 5 where it says &#8220;make sure that all images that are also links or buttons describe what will happen when you click on them, e.g. alternative text as &#8220;Marilyn Monroe &#8211; click to read her life story&#8221;. &#8221;</p>
<p>This isn&#8217;t really correct. The alternative description of an image should be the exact equivalent of its appearance. So if it&#8217;s a photo of Marilyn Monroe with no text in the image, it should just be &#8216;Marilyn Monroe&#8217;. However, if that image is also a hyperlink, the title attribute of the link itself can be used to describe where the link goes to.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tedd</title>
		<link>http://www.headstar.com/eablive/?p=183&#038;cpage=1#comment-5340</link>
		<dc:creator><![CDATA[tedd]]></dc:creator>
		<pubDate>Mon, 26 May 2008 15:44:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.headstar.com/eablive/?p=183#comment-5340</guid>
		<description><![CDATA[The following is a link to a group of different CAPTCHA&#039;s that I&#039;ve created.

http://webbytedd.com/aa/assorted-captcha/

I realize that the first demo is not acceptable, but do any other the other examples work for those with disabilities? Granted some won&#039;t because they require sight, but blindness is only one of many different disabilities. 

Could a combination of different CAPTCHA&#039;s provide a solution or is CAPTCHA just one of the things that can not be resolved?]]></description>
		<content:encoded><![CDATA[<p>The following is a link to a group of different CAPTCHA&#8217;s that I&#8217;ve created.</p>
<p><a href="http://webbytedd.com/aa/assorted-captcha/" rel="nofollow">http://webbytedd.com/aa/assorted-captcha/</a></p>
<p>I realize that the first demo is not acceptable, but do any other the other examples work for those with disabilities? Granted some won&#8217;t because they require sight, but blindness is only one of many different disabilities. </p>
<p>Could a combination of different CAPTCHA&#8217;s provide a solution or is CAPTCHA just one of the things that can not be resolved?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marc</title>
		<link>http://www.headstar.com/eablive/?p=183&#038;cpage=1#comment-5339</link>
		<dc:creator><![CDATA[Marc]]></dc:creator>
		<pubDate>Wed, 14 May 2008 09:13:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.headstar.com/eablive/?p=183#comment-5339</guid>
		<description><![CDATA[An excellent point Darrell. I&#039;m in the process of removing CAPTCHA from my contact form (I was going to feed the form through Akismet for spam protection) but I will now look at ReCAPTCHA.net]]></description>
		<content:encoded><![CDATA[<p>An excellent point Darrell. I&#8217;m in the process of removing CAPTCHA from my contact form (I was going to feed the form through Akismet for spam protection) but I will now look at ReCAPTCHA.net</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Darrell Shandrow</title>
		<link>http://www.headstar.com/eablive/?p=183&#038;cpage=1#comment-5338</link>
		<dc:creator><![CDATA[Darrell Shandrow]]></dc:creator>
		<pubDate>Mon, 12 May 2008 17:22:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.headstar.com/eablive/?p=183#comment-5338</guid>
		<description><![CDATA[I object to the suggestion in item number 5 that an e-mail or telephone based alternative to the CAPTCHA is acceptable.  It is patently unacceptable to be forced to wait anywhere from hours to days or weeks for something that is granted our sighted peers instantly if only one is able to physically see a CAPTCHA image.  At a bare minimum, all sites should now feature an audio CAPTCHA playback.  There&#039;s really no excuse for omitting this feature now that services such as ReCAPTCHA.net exist as turn key solutions for web developers.

At this point, failure to provide at least an audio playback on any CAPTCHA represents nothing less than a &quot;no blind people allowed&quot; sign.]]></description>
		<content:encoded><![CDATA[<p>I object to the suggestion in item number 5 that an e-mail or telephone based alternative to the CAPTCHA is acceptable.  It is patently unacceptable to be forced to wait anywhere from hours to days or weeks for something that is granted our sighted peers instantly if only one is able to physically see a CAPTCHA image.  At a bare minimum, all sites should now feature an audio CAPTCHA playback.  There&#8217;s really no excuse for omitting this feature now that services such as ReCAPTCHA.net exist as turn key solutions for web developers.</p>
<p>At this point, failure to provide at least an audio playback on any CAPTCHA represents nothing less than a &#8220;no blind people allowed&#8221; sign.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
