<?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: Screen Reader Support For Disabled &amp; Read Only Form Fields</title>
	<atom:link href="http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/feed/" rel="self" type="application/rss+xml" />
	<link>http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/</link>
	<description></description>
	<lastBuildDate>Tue, 24 Jan 2012 10:02:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Joanna Wall</title>
		<link>http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/comment-page-1/#comment-34</link>
		<dc:creator>Joanna Wall</dc:creator>
		<pubDate>Thu, 23 Dec 2010 22:21:57 +0000</pubDate>
		<guid isPermaLink="false">http://tink.co.uk/?p=146#comment-34</guid>
		<description>Just some (rather technical) thoughts from an NVDA developer. :) The problems with Windows screen readers and detecting read-only fields are partly caused by the way web browsers currently expose information to accessibility APIs. MSAA provides ROLE_SYSTEM_TEXT which is the role normally used for editable text fields. For some reason, a decision was historically made (probably by Microsoft) to expose normal text leaf nodes with ROLE_SYSTEM_TEXT, using the read-only state to differentiate them from editable text fields. This means that using MSAA, you can&#039;t differentiate text leaf nodes from read-only editable text fields. For example: test looks the same in MSAA as: Screen readers don&#039;t use MSAA alone to get their information from web browsers, so it&#039;s theoretically possible to detect this, but it isn&#039;t trivial and MSAA is still used as the primary source for some information. I can certainly look into fixing this for NVDA if someone wants it badly, but read-only editable text fields on the web tend to be quite rare, so there haven&#039;t been any requests from our users to fix this. As I say, the fix isn&#039;t trivial and there&#039;s always plenty of other high priority work for us to do. :)</description>
		<content:encoded><![CDATA[<p>Just some (rather technical) thoughts from an NVDA developer. :) The problems with Windows screen readers and detecting read-only fields are partly caused by the way web browsers currently expose information to accessibility APIs. MSAA provides ROLE_SYSTEM_TEXT which is the role normally used for editable text fields. For some reason, a decision was historically made (probably by Microsoft) to expose normal text leaf nodes with ROLE_SYSTEM_TEXT, using the read-only state to differentiate them from editable text fields. This means that using MSAA, you can&#8217;t differentiate text leaf nodes from read-only editable text fields. For example: test looks the same in MSAA as: Screen readers don&#8217;t use MSAA alone to get their information from web browsers, so it&#8217;s theoretically possible to detect this, but it isn&#8217;t trivial and MSAA is still used as the primary source for some information. I can certainly look into fixing this for NVDA if someone wants it badly, but read-only editable text fields on the web tend to be quite rare, so there haven&#8217;t been any requests from our users to fix this. As I say, the fix isn&#8217;t trivial and there&#8217;s always plenty of other high priority work for us to do. :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Léonie Watson</title>
		<link>http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/comment-page-1/#comment-30</link>
		<dc:creator>Léonie Watson</dc:creator>
		<pubDate>Tue, 23 Feb 2010 20:12:37 +0000</pubDate>
		<guid isPermaLink="false">http://tink.co.uk/?p=146#comment-30</guid>
		<description>James, I guess that explains why screen readers seem to have trouble with these form fields. Do you think UI Automation will/has improve things at all?</description>
		<content:encoded><![CDATA[<p>James, I guess that explains why screen readers seem to have trouble with these form fields. Do you think UI Automation will/has improve things at all?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Teh</title>
		<link>http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/comment-page-1/#comment-29</link>
		<dc:creator>James Teh</dc:creator>
		<pubDate>Mon, 22 Feb 2010 22:13:04 +0000</pubDate>
		<guid isPermaLink="false">http://tink.co.uk/?p=146#comment-29</guid>
		<description>Bah. Wordpress clobbered my example. Let&#039;s try this.

&lt;div&gt;test&lt;/div&gt;
looks the same in MSAA as:
&lt;div&gt;&lt;input type=&quot;text&quot; readonly=&quot;readonly&quot; value=&quot;test&quot;&gt;&lt;/div&gt;</description>
		<content:encoded><![CDATA[<p>Bah. WordPress clobbered my example. Let&#8217;s try this.</p>
<p>&lt;div&gt;test&lt;/div&gt;<br />
looks the same in MSAA as:<br />
&lt;div&gt;&lt;input type=&#8221;text&#8221; readonly=&#8221;readonly&#8221; value=&#8221;test&#8221;&gt;&lt;/div&gt;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Teh</title>
		<link>http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/comment-page-1/#comment-28</link>
		<dc:creator>James Teh</dc:creator>
		<pubDate>Mon, 22 Feb 2010 22:10:05 +0000</pubDate>
		<guid isPermaLink="false">http://tink.co.uk/?p=146#comment-28</guid>
		<description>Just some (rather technical) thoughts from an NVDA developer. :)

The problems with Windows screen readers and detecting read-only fields are partly caused by the way web browsers currently expose information to accessibility APIs. MSAA provides ROLE_SYSTEM_TEXT which is the role normally used for editable text fields. For some reason, a decision was historically made (probably by Microsoft) to expose normal text leaf nodes with ROLE_SYSTEM_TEXT, using the read-only state to differentiate them from editable text fields. This means that using MSAA, you can&#039;t differentiate text leaf nodes from read-only editable text fields. For example:
test
looks the same in MSAA as:

Screen readers don&#039;t use MSAA alone to get their information from web browsers, so it&#039;s theoretically possible to detect this, but it isn&#039;t trivial and MSAA is still used as the primary source for some information.

I can certainly look into fixing this for NVDA if someone wants it badly, but read-only editable text fields on the web tend to be quite rare, so there haven&#039;t been any requests from our users to fix this. As I say, the fix isn&#039;t trivial and there&#039;s always plenty of other high priority work for us to do. :)</description>
		<content:encoded><![CDATA[<p>Just some (rather technical) thoughts from an NVDA developer. :)</p>
<p>The problems with Windows screen readers and detecting read-only fields are partly caused by the way web browsers currently expose information to accessibility APIs. MSAA provides ROLE_SYSTEM_TEXT which is the role normally used for editable text fields. For some reason, a decision was historically made (probably by Microsoft) to expose normal text leaf nodes with ROLE_SYSTEM_TEXT, using the read-only state to differentiate them from editable text fields. This means that using MSAA, you can&#8217;t differentiate text leaf nodes from read-only editable text fields. For example:<br />
test<br />
looks the same in MSAA as:</p>
<p>Screen readers don&#8217;t use MSAA alone to get their information from web browsers, so it&#8217;s theoretically possible to detect this, but it isn&#8217;t trivial and MSAA is still used as the primary source for some information.</p>
<p>I can certainly look into fixing this for NVDA if someone wants it badly, but read-only editable text fields on the web tend to be quite rare, so there haven&#8217;t been any requests from our users to fix this. As I say, the fix isn&#8217;t trivial and there&#8217;s always plenty of other high priority work for us to do. :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Léonie Watson</title>
		<link>http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/comment-page-1/#comment-27</link>
		<dc:creator>Léonie Watson</dc:creator>
		<pubDate>Sun, 21 Feb 2010 18:10:38 +0000</pubDate>
		<guid isPermaLink="false">http://tink.co.uk/?p=146#comment-27</guid>
		<description>I didn&#039;t test this thoroughly, but it seems that if a read only radio button is selected then the selection is submitted with the rest of the form data.</description>
		<content:encoded><![CDATA[<p>I didn&#8217;t test this thoroughly, but it seems that if a read only radio button is selected then the selection is submitted with the rest of the form data.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: graste</title>
		<link>http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/comment-page-1/#comment-26</link>
		<dc:creator>graste</dc:creator>
		<pubDate>Sun, 21 Feb 2010 17:46:05 +0000</pubDate>
		<guid isPermaLink="false">http://tink.co.uk/?p=146#comment-26</guid>
		<description>When screenreaders allow selecting of readonly radio buttons, does this mean that those _changes_ are eventually submitted by the user agent?</description>
		<content:encoded><![CDATA[<p>When screenreaders allow selecting of readonly radio buttons, does this mean that those _changes_ are eventually submitted by the user agent?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tink</title>
		<link>http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/comment-page-1/#comment-25</link>
		<dc:creator>Tink</dc:creator>
		<pubDate>Sun, 21 Feb 2010 17:36:12 +0000</pubDate>
		<guid isPermaLink="false">http://tink.co.uk/?p=146#comment-25</guid>
		<description>Thanks Everett. I&#039;m glad you&#039;ve added some results from VoiceOver... It&#039;s one platform I don&#039;t have immediate access to at the moment :)</description>
		<content:encoded><![CDATA[<p>Thanks Everett. I&#8217;m glad you&#8217;ve added some results from VoiceOver&#8230; It&#8217;s one platform I don&#8217;t have immediate access to at the moment :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Everett Zufelt</title>
		<link>http://tink.co.uk/2010/02/screen-reader-support-for-disabled-read-only-form-fields/comment-page-1/#comment-24</link>
		<dc:creator>Everett Zufelt</dc:creator>
		<pubDate>Sun, 21 Feb 2010 16:42:10 +0000</pubDate>
		<guid isPermaLink="false">http://tink.co.uk/?p=146#comment-24</guid>
		<description>Excellent post.  I took a look at the test page with VoiceOver on OS X Snow Leopard (10.6.0) and Safari 4.0.3.

1. The Disabled form fields are not part of the tab order.

2. Disabled form fields are identified as &quot;dimmed&quot;, essentially meaning grayed out or disabled.

3. Nothing was announced by VoiceOver to indicate that a form field is read only.

4. Users cannot type into text fields or text areas that are disabled or read only.

5. Users cannot select radio buttons that are disabled.

6. Users can select radio buttons that are read only.

7. Users cannot make selections in select boxes that are disabled.

Thanks again for the great article,
Everett</description>
		<content:encoded><![CDATA[<p>Excellent post.  I took a look at the test page with VoiceOver on OS X Snow Leopard (10.6.0) and Safari 4.0.3.</p>
<p>1. The Disabled form fields are not part of the tab order.</p>
<p>2. Disabled form fields are identified as &#8220;dimmed&#8221;, essentially meaning grayed out or disabled.</p>
<p>3. Nothing was announced by VoiceOver to indicate that a form field is read only.</p>
<p>4. Users cannot type into text fields or text areas that are disabled or read only.</p>
<p>5. Users cannot select radio buttons that are disabled.</p>
<p>6. Users can select radio buttons that are read only.</p>
<p>7. Users cannot make selections in select boxes that are disabled.</p>
<p>Thanks again for the great article,<br />
Everett</p>
]]></content:encoded>
	</item>
</channel>
</rss>

