<?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: The accessibility of HTML 5 autofocus</title>
	<atom:link href="http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/</link>
	<description></description>
	<lastBuildDate>Wed, 08 Feb 2012 14:14:31 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: [extern] Technikwürze &#8211; Formulare total 1+ 2 &#124; sprungmarker</title>
		<link>http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/comment-page-1/#comment-833444</link>
		<dc:creator>[extern] Technikwürze &#8211; Formulare total 1+ 2 &#124; sprungmarker</dc:creator>
		<pubDate>Sun, 23 Oct 2011 16:51:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.brucelawson.co.uk/?p=1680#comment-833444</guid>
		<description>[...]  [...]</description>
		<content:encoded><![CDATA[<p>[...]  [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stomme poes</title>
		<link>http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/comment-page-1/#comment-799446</link>
		<dc:creator>Stomme poes</dc:creator>
		<pubDate>Sun, 11 Sep 2011 14:17:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.brucelawson.co.uk/?p=1680#comment-799446</guid>
		<description>Kevin:
&gt;&gt;Currently, Leve a Reply is a H3, but not an ARIA landmark.

What landmark would it be?  I can&#039;t think of one that would fit, and not sure if a comment form should need a landmark.

&gt;&gt;Is it necessary to have (required) next to name field, considering that with Firefox and NVDA...

Labels should state whether something is required, yes.  Not everyone has a screen reader to tell them there&#039;s a &quot;required&quot; attribute on an input. Labels are also used by sighted people using graphical browsers.

If all AT universally announced that a field was required, then authors could maybe decide to leave the attribute off the inputs and leave it in the labels, who should be accessible to *everyone*.

Also, announcing to a user the moment they touch an input that it&#039;s invalid is stupid and annoying. It&#039;s like telling someone they fail before they&#039;ve even tried, or pointing out the obvious (&quot;the field is currently empty&quot;).  It should not be considered invalid until the user has left. 

Autocomplete is going to be a problem if all HTML5-parsing browsers make it default. Great, every single e-commerce form now needs to add autocomplete=&quot;off&quot; to everything just to stop the idiocy that is &quot;automatically adding in credit card numbers&quot; and other junk public computers with caching-on browsers would store.  Oh the joy.

Oh and I&#039;m still waiting for my promised ability to turn autocomplete and autofocus off on my end.  I can turn Javascript off, but haven&#039;t found a way to turn off autofocus or autocomplete.  Which one is more accessible? The one *I* can control, and I don&#039;t mean &quot;control by spending 15 minutes crawling through some config file that the browser decides to overwrite next time I start up anyway&quot; either. 

Old article, things have changed, maybe it&#039;s time for an update?</description>
		<content:encoded><![CDATA[<p>Kevin:<br />
&gt;&gt;Currently, Leve a Reply is a H3, but not an ARIA landmark.</p>
<p>What landmark would it be?  I can&#8217;t think of one that would fit, and not sure if a comment form should need a landmark.</p>
<p>&gt;&gt;Is it necessary to have (required) next to name field, considering that with Firefox and NVDA&#8230;</p>
<p>Labels should state whether something is required, yes.  Not everyone has a screen reader to tell them there&#8217;s a &#8220;required&#8221; attribute on an input. Labels are also used by sighted people using graphical browsers.</p>
<p>If all AT universally announced that a field was required, then authors could maybe decide to leave the attribute off the inputs and leave it in the labels, who should be accessible to *everyone*.</p>
<p>Also, announcing to a user the moment they touch an input that it&#8217;s invalid is stupid and annoying. It&#8217;s like telling someone they fail before they&#8217;ve even tried, or pointing out the obvious (&#8220;the field is currently empty&#8221;).  It should not be considered invalid until the user has left. </p>
<p>Autocomplete is going to be a problem if all HTML5-parsing browsers make it default. Great, every single e-commerce form now needs to add autocomplete=&#8221;off&#8221; to everything just to stop the idiocy that is &#8220;automatically adding in credit card numbers&#8221; and other junk public computers with caching-on browsers would store.  Oh the joy.</p>
<p>Oh and I&#8217;m still waiting for my promised ability to turn autocomplete and autofocus off on my end.  I can turn Javascript off, but haven&#8217;t found a way to turn off autofocus or autocomplete.  Which one is more accessible? The one *I* can control, and I don&#8217;t mean &#8220;control by spending 15 minutes crawling through some config file that the browser decides to overwrite next time I start up anyway&#8221; either. </p>
<p>Old article, things have changed, maybe it&#8217;s time for an update?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Chao</title>
		<link>http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/comment-page-1/#comment-797886</link>
		<dc:creator>Kevin Chao</dc:creator>
		<pubDate>Fri, 09 Sep 2011 03:16:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.brucelawson.co.uk/?p=1680#comment-797886</guid>
		<description>Currently, Leve a Reply is a H3, but not an ARIA landmark. Is this expected? Is it necessary to have (required) next to name field, considering that with Firefox and NVDA, arrowing or read current line on edit field reports: &quot;edit, invalid entry, required, has autocomplete, blank&quot;. I&#039;m in favor of cutting out redundacy and any unneeded level of verbosity. With focus in name field, TAB goes to privacy policy link, another TAB will go to email field, &quot;privacy policy&quot; seems to be part of field label, making it overly verbose and messy. In addition, Email field has same issue as name field, where required is spoken twice, once in edit box label and part of edit box. It&#039;s only needed once, which is in edit box. With focus in website, TAB to comment field, which is read as &quot;edit, invalid entry, multiline, required&quot;. Edit box label should be part of edit box like it was in all previous fields, including website. Report current control, NVDA+TAB does not report edit box label. Only thing that is reported differently with NVDA+TAB over pressing TAB to go to edit box is &quot;focused is in between &quot;edit&quot; and &quot;invalid entry&quot;.  While HTML5 and ARIA are great, it&#039;s nearly impossible to find examples to test that do not have bugs in the code itself.</description>
		<content:encoded><![CDATA[<p>Currently, Leve a Reply is a H3, but not an ARIA landmark. Is this expected? Is it necessary to have (required) next to name field, considering that with Firefox and NVDA, arrowing or read current line on edit field reports: &#8220;edit, invalid entry, required, has autocomplete, blank&#8221;. I&#8217;m in favor of cutting out redundacy and any unneeded level of verbosity. With focus in name field, TAB goes to privacy policy link, another TAB will go to email field, &#8220;privacy policy&#8221; seems to be part of field label, making it overly verbose and messy. In addition, Email field has same issue as name field, where required is spoken twice, once in edit box label and part of edit box. It&#8217;s only needed once, which is in edit box. With focus in website, TAB to comment field, which is read as &#8220;edit, invalid entry, multiline, required&#8221;. Edit box label should be part of edit box like it was in all previous fields, including website. Report current control, NVDA+TAB does not report edit box label. Only thing that is reported differently with NVDA+TAB over pressing TAB to go to edit box is &#8220;focused is in between &#8220;edit&#8221; and &#8220;invalid entry&#8221;.  While HTML5 and ARIA are great, it&#8217;s nearly impossible to find examples to test that do not have bugs in the code itself.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stomme poes</title>
		<link>http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/comment-page-1/#comment-725759</link>
		<dc:creator>Stomme poes</dc:creator>
		<pubDate>Mon, 17 Jan 2011 08:50:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.brucelawson.co.uk/?p=1680#comment-725759</guid>
		<description>Form information/description/instructions belong outside (preferably before) the form.  This keeps the legend short (a must), and prevents long paragraphs of text inside something the user expects to just fill in.  I have forms with long bouts of &quot;help text&quot; and frankly it&#039;s annoying and slows users down (too bad I can&#039;t remove it).  I include stuff like &quot;Required fields marked by (something) also before and outside the form.

Using CSS to style required fields means anyone not getting the styles miss that important information.  And any readers who understand the ARIA required role, it should just override the HTML5 required attribute.  Does that mean anything for browsers (if they do validation and check for required fields filled while the user is making use of ARIA roles?)?

Autofocussing would be better a setting users can choose themselves for the sites they visit most: say, Google search or a web-based mail site or someplace they always log into first... rather than something set by authors.  I don&#039;t like the idea of losing my control of my cursor or my focus.  If I&#039;m on a new-to-me page I may not realise where the hell I am right away!  Keeping Javascript off helped this, but won&#039;t help when it&#039;s built into the markup.  Like bookmarks, I better like the idea of users setting this attribute instead.  We know which pages we want to skip to a form field and which ones we don&#039;t.</description>
		<content:encoded><![CDATA[<p>Form information/description/instructions belong outside (preferably before) the form.  This keeps the legend short (a must), and prevents long paragraphs of text inside something the user expects to just fill in.  I have forms with long bouts of &#8220;help text&#8221; and frankly it&#8217;s annoying and slows users down (too bad I can&#8217;t remove it).  I include stuff like &#8220;Required fields marked by (something) also before and outside the form.</p>
<p>Using CSS to style required fields means anyone not getting the styles miss that important information.  And any readers who understand the ARIA required role, it should just override the HTML5 required attribute.  Does that mean anything for browsers (if they do validation and check for required fields filled while the user is making use of ARIA roles?)?</p>
<p>Autofocussing would be better a setting users can choose themselves for the sites they visit most: say, Google search or a web-based mail site or someplace they always log into first&#8230; rather than something set by authors.  I don&#8217;t like the idea of losing my control of my cursor or my focus.  If I&#8217;m on a new-to-me page I may not realise where the hell I am right away!  Keeping Javascript off helped this, but won&#8217;t help when it&#8217;s built into the markup.  Like bookmarks, I better like the idea of users setting this attribute instead.  We know which pages we want to skip to a form field and which ones we don&#8217;t.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Technikwürze 158 – Formulare total 2 (Barrierefreie Formulare) &#187; Technikwürze &#8211; Web Standards Podcast</title>
		<link>http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/comment-page-1/#comment-675743</link>
		<dc:creator>Technikwürze 158 – Formulare total 2 (Barrierefreie Formulare) &#187; Technikwürze &#8211; Web Standards Podcast</dc:creator>
		<pubDate>Tue, 22 Jun 2010 07:38:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.brucelawson.co.uk/?p=1680#comment-675743</guid>
		<description>[...] The accessibility of HTML 5 autofocus – Bruce Lawson [...]</description>
		<content:encoded><![CDATA[<p>[...] The accessibility of HTML 5 autofocus – Bruce Lawson [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: WebAIM: Blog - Future Web Accessibility: HTML5 &#60;input&#62; Extensions</title>
		<link>http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/comment-page-1/#comment-673014</link>
		<dc:creator>WebAIM: Blog - Future Web Accessibility: HTML5 &#60;input&#62; Extensions</dc:creator>
		<pubDate>Thu, 27 May 2010 18:47:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.brucelawson.co.uk/?p=1680#comment-673014</guid>
		<description>[...] that there are some accessibility concerns with autofocusing in general, and this won&#8217;t change those one way or the other, but in the [...]</description>
		<content:encoded><![CDATA[<p>[...] that there are some accessibility concerns with autofocusing in general, and this won&#8217;t change those one way or the other, but in the [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

