<?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 for David Berman Communications</title>
	<atom:link href="http://www.davidberman.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.davidberman.com</link>
	<description>David Berman will help you repeat your successes</description>
	<lastBuildDate>Sun, 19 Feb 2012 03:05:51 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>Comment on The New Standard on Web Accessibility: WCAG 2.0 by Soila</title>
		<link>http://www.davidberman.com/courses/web-accessibility-course/#comment-648</link>
		<dc:creator>Soila</dc:creator>
		<pubDate>Sun, 19 Feb 2012 03:05:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.davidberman.com/courses/web-accessibility/#comment-648</guid>
		<description>Thanks for the Post. Was&#039;t what I was exactly looking for but when I searched Google your post came up so I checked it out and wanted to at least say thanks.  </description>
		<content:encoded><![CDATA[<p>Thanks for the Post. Was&#8217;t what I was exactly looking for but when I searched Google your post came up so I checked it out and wanted to at least say thanks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Making The Planet Your Client: Designing Sustainability by David Berman</title>
		<link>http://www.davidberman.com/courses/howlogo/#comment-617</link>
		<dc:creator>David Berman</dc:creator>
		<pubDate>Sun, 12 Feb 2012 05:35:05 +0000</pubDate>
		<guid isPermaLink="false">http://dbc.ten-321.com/seminars/howlogo/#comment-617</guid>
		<description>Great: well, we&#039;ll be announcing dates for this seminar in Savannah USA, and Melbourne Australia very shortly. Where are you located?</description>
		<content:encoded><![CDATA[<p>Great: well, we&#8217;ll be announcing dates for this seminar in Savannah USA, and Melbourne Australia very shortly. Where are you located?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Making The Planet Your Client: Designing Sustainability by arabi</title>
		<link>http://www.davidberman.com/courses/howlogo/#comment-613</link>
		<dc:creator>arabi</dc:creator>
		<pubDate>Sat, 11 Feb 2012 17:14:34 +0000</pubDate>
		<guid isPermaLink="false">http://dbc.ten-321.com/seminars/howlogo/#comment-613</guid>
		<description>iwould loue to attend your seminar</description>
		<content:encoded><![CDATA[<p>iwould loue to attend your seminar</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The New Standard on Web Accessibility: WCAG 2.0 by sjw</title>
		<link>http://www.davidberman.com/courses/web-accessibility-course/#comment-571</link>
		<dc:creator>sjw</dc:creator>
		<pubDate>Mon, 06 Feb 2012 20:03:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.davidberman.com/courses/web-accessibility/#comment-571</guid>
		<description>Thank you David,  this is the information that I have been searching for.</description>
		<content:encoded><![CDATA[<p>Thank you David,  this is the information that I have been searching for.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The New Standard on Web Accessibility: WCAG 2.0 by David Berman</title>
		<link>http://www.davidberman.com/courses/web-accessibility-course/#comment-481</link>
		<dc:creator>David Berman</dc:creator>
		<pubDate>Thu, 02 Feb 2012 04:15:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.davidberman.com/courses/web-accessibility/#comment-481</guid>
		<description>You&#039;re right: my statement is too broad. Both NVDA and JAWS have logic where if the abbreviation has sufficient vowels to be pronounceable AND the phrase is not in their exception dictionary, then they may try to sound it out (i.e. an acronym), rather than spell out each letter (i.e. an initialism). These algorithms are more likely to spell out when the word is all caps, but you still won&#039;t necessarily get the result you desire: further discouraged by the fact that NVDA currently effectively ignores &lt;abbr&gt; and &lt;acronym&gt;, while JAWS ships with the user preference to expand them turned off.
     However, if you really want to make sure that a given abbreviation will be spelled out when the assistive technology and user preferences are ready to accommodate, here&#039;s the deeper best practice...
     In your CSS, specify these styles:
&lt;pre&gt;abbr, 
abbr.acronym {speak:normal;}
abbr.initialism {speak:spell-out;}&lt;/pre&gt;
... now that you have established a class that distinguishes initialisms, then for each abbreviation you would prefer spelled out, you would code like this example: &lt;pre&gt;&lt;code&gt;&lt;abbr class=initialism&gt;ISO&lt;/abbr&gt;&lt;/code&gt;&lt;/pre&gt; (note that you don&#039;t need a TITLE in this situation, as this assumes you don&#039;t want to present &quot;International Standards Organization&quot; in any case).

You could go even deeper, with a class for truncations, for instance.</description>
		<content:encoded><![CDATA[<p>You&#8217;re right: my statement is too broad. Both NVDA and JAWS have logic where if the abbreviation has sufficient vowels to be pronounceable AND the phrase is not in their exception dictionary, then they may try to sound it out (i.e. an acronym), rather than spell out each letter (i.e. an initialism). These algorithms are more likely to spell out when the word is all caps, but you still won&#8217;t necessarily get the result you desire: further discouraged by the fact that NVDA currently effectively ignores <abbr> and <acronym>, while JAWS ships with the user preference to expand them turned off.<br />
     However, if you really want to make sure that a given abbreviation will be spelled out when the assistive technology and user preferences are ready to accommodate, here&#8217;s the deeper best practice&#8230;<br />
     In your CSS, specify these styles:</p>
<pre>abbr,
abbr.acronym {speak:normal;}
abbr.initialism {speak:spell-out;}</pre>
<p>&#8230; now that you have established a class that distinguishes initialisms, then for each abbreviation you would prefer spelled out, you would code like this example:
<pre><code>&lt;abbr class=initialism&gt;ISO&lt;/abbr&gt;</code></pre>
<p> (note that you don&#8217;t need a TITLE in this situation, as this assumes you don&#8217;t want to present &#8220;International Standards Organization&#8221; in any case).</p>
<p>You could go even deeper, with a class for truncations, for instance.</acronym></abbr></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The New Standard on Web Accessibility: WCAG 2.0 by David Berman</title>
		<link>http://www.davidberman.com/courses/web-accessibility-course/#comment-477</link>
		<dc:creator>David Berman</dc:creator>
		<pubDate>Thu, 02 Feb 2012 03:34:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.davidberman.com/courses/web-accessibility/#comment-477</guid>
		<description>Hi. This could be one of several issues. Could you please email me a screen capture, and tell what OS version you are running, to make sure I am understanding correctly? Thank you.</description>
		<content:encoded><![CDATA[<p>Hi. This could be one of several issues. Could you please email me a screen capture, and tell what OS version you are running, to make sure I am understanding correctly? Thank you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The New Standard on Web Accessibility: WCAG 2.0 by sjw</title>
		<link>http://www.davidberman.com/courses/web-accessibility-course/#comment-443</link>
		<dc:creator>sjw</dc:creator>
		<pubDate>Tue, 31 Jan 2012 17:07:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.davidberman.com/courses/web-accessibility/#comment-443</guid>
		<description>Hi David,  I have a new question for you.  In IE8 when using a select box that contains more than one option there is a browser problem when zooming in to increase the size of the font for a user that has decreased vision.  The select box remains at a relatively stable size,  so the more the user zooms in the more the option displayed is cut off, and just shows the tops of the word.  Do you know of a solution to this issue?</description>
		<content:encoded><![CDATA[<p>Hi David,  I have a new question for you.  In IE8 when using a select box that contains more than one option there is a browser problem when zooming in to increase the size of the font for a user that has decreased vision.  The select box remains at a relatively stable size,  so the more the user zooms in the more the option displayed is cut off, and just shows the tops of the word.  Do you know of a solution to this issue?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The New Standard on Web Accessibility: WCAG 2.0 by sjw</title>
		<link>http://www.davidberman.com/courses/web-accessibility-course/#comment-441</link>
		<dc:creator>sjw</dc:creator>
		<pubDate>Tue, 31 Jan 2012 16:58:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.davidberman.com/courses/web-accessibility/#comment-441</guid>
		<description>Thanks for your response David.  It will help us to determining how we will implement this tag in the future.  In regards to your statement &quot;Untagged, the screen reader is going to read an all caps word as separate letters.&quot;, I have listened to our pages with both Jaws and NVDA and did not find this to be true.  Is there a setting in these readers that would be set to ensure that all caps words will be read as separate letters?</description>
		<content:encoded><![CDATA[<p>Thanks for your response David.  It will help us to determining how we will implement this tag in the future.  In regards to your statement &#8220;Untagged, the screen reader is going to read an all caps word as separate letters.&#8221;, I have listened to our pages with both Jaws and NVDA and did not find this to be true.  Is there a setting in these readers that would be set to ensure that all caps words will be read as separate letters?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The New Standard on Web Accessibility: WCAG 2.0 by David Berman</title>
		<link>http://www.davidberman.com/courses/web-accessibility-course/#comment-417</link>
		<dc:creator>David Berman</dc:creator>
		<pubDate>Mon, 30 Jan 2012 02:40:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.davidberman.com/courses/web-accessibility/#comment-417</guid>
		<description>Hi! I&#039;m glad you enjoyed our training session, and I thank you for these questions, as I&#039;ve received many inquiries about acronyms lately, and am eager to share some clarity.
You are correct that ACRONYM is deprecating in favour of ABBR, as an acronym is simply an instance of an abbreviation. Assistive technologies generally treat both the same way (a notable exception being around IE6 which alone supported ACRONYM yet not ABBR).
Therefore, in my responses to each of your statements I&#039;ll dwell on ABBR though my comments also apply to ACRONYM...


sjw: * The correct syntax of an acronym tag is Treasury Board Secretariat.
David: For HTML, the correct typical syntax would be &lt;code&gt;&lt;acronym title=&quot;Treasury Board Secretariat&quot;&gt;TBS&lt;/acronym&gt;&lt;/code&gt; for the acronym element, though I recommend you replace acronym with abbr.  For PDF, you would use an /E structure instead.

sjw: *All acronyms can be tagged but the title element is always used in the tag when present.
David: Almost true. Using the ABBR element to make an abbreviation clearer is one way of doing so, in which case the TITLE attribute should be present. However, there are some situations where an ABBR (or ACRONYM) isn&#039;t technically possible (for instance, within an alt attribute when providing a text description of an image) in which case it is best to simply spell out the term. Also, when an acronym is first used, it is a common technique to spell out the term in parentheses immediately following the acronym) for all to &quot;see&quot;: in such cases also using an ABBR or ACRONYM would by dysfunctionally redundant (as, for instance, someone using a screen reader would then wrongly hear the expanded form twice).

sjw: *All acronyms should be tagged to force the screen readers to read them as separate letters instead of a word but the title element should only be used in the first instance. For example: ISO.
David: Untagged, the screen reader is going to read an all caps word as separate letters. And I think that all instances should be coded identically (see my next response...)

sjw: *Once the first instance of the acronym has been coded with the correct syntax as in the first bullet, it is not necessary to wrap the other instances of the acronym in a tag.
David: Although there is a debate around whether to TITLE every instance or just the first instance, I&#039;m in the every-instance camp, for many reasons: 
	- there are cases where the same abbreviation will appear with two different meanings on the same page, for example &quot;Dr. Bombay, 123 Riverside Dr., Ottawa&quot;.
	- not every assistive technology is going to elegantly apply the one instruction to all instances of an identical abbreviation, and we are always seeking device independence
	- down the road a developer or algorithm may cut and paste a portion of your page into another page, and thus lose the rule
	- it is more difficult to do quality assurance if not all instances are handled the same way

sjw: *If the tag is presented without the title element most browsers present an indicator that there is attached info. However, for the sighted user this is incorrect but this does allow the unsighted user to get the acronym delivered correctly. Which way should have precedence in your opinion?
David: I recommend that you always include the title attribute. Also, don&#039;t forget the value of potentially also including a LANG attribute whenever the expanded version is not in the language of the page.

sjw: *Acronym tags are not mandatory in WCAG 2.0.
David: Nothing is mandatory in WCAG 2.0 . Rather, for the example of Treasury Board of Canada, their site is governed by the Canadian government&#039;s new Standard On Web Accessibility, which makes compliance mandatory for all WCAG 2.0 success criteria of Level A and Level AA (with some exceptions). Because the WCAG 2.0 success criterion for expanding on abbreviations (3.1.4) is designated Level AAA, including ABBR (or ACRONYM) is not mandatory under the Standard On Web Accessibility.

sjw: *Incorrect use of the acronym tag is a fail under Success Criteria 1.3.1 – Technique F43.
David: Yes, that would be a Level A failure. I think what we&#039;re getting at here is someone wrongly using ABBR or ACRONYM to force the visual dotted underline effect in many browsers. Of course, more generally, there are other success criteria which would also be failed with wonton miscoding of ABBR (or any element for that matter).


All around, ABBR elements are a blessing, and one can even control them further through CSS. And, although designated Level AAA, the folks in marketing for sites seeking A or AA compliance will also appreciate the potential control that the use of ABBR can give to how any abbreviated brand &quot;sounds&quot; online.

Final tip: don&#039;t forget that you can also use ABBR in the opposite way in table header rows, providing a more terse alternative heading that will have the benefit of reducing the read-out-loud time of phrases that will be read repeatedly by a screen reader.</description>
		<content:encoded><![CDATA[<p>Hi! I&#8217;m glad you enjoyed our training session, and I thank you for these questions, as I&#8217;ve received many inquiries about acronyms lately, and am eager to share some clarity.<br />
You are correct that ACRONYM is deprecating in favour of ABBR, as an acronym is simply an instance of an abbreviation. Assistive technologies generally treat both the same way (a notable exception being around IE6 which alone supported ACRONYM yet not ABBR).<br />
Therefore, in my responses to each of your statements I&#8217;ll dwell on ABBR though my comments also apply to ACRONYM&#8230;</p>
<p>sjw: * The correct syntax of an acronym tag is Treasury Board Secretariat.<br />
David: For HTML, the correct typical syntax would be <code>&lt;acronym title="Treasury Board Secretariat"&gt;TBS&lt;/acronym&gt;</code> for the acronym element, though I recommend you replace acronym with abbr.  For PDF, you would use an /E structure instead.</p>
<p>sjw: *All acronyms can be tagged but the title element is always used in the tag when present.<br />
David: Almost true. Using the ABBR element to make an abbreviation clearer is one way of doing so, in which case the TITLE attribute should be present. However, there are some situations where an ABBR (or ACRONYM) isn&#8217;t technically possible (for instance, within an alt attribute when providing a text description of an image) in which case it is best to simply spell out the term. Also, when an acronym is first used, it is a common technique to spell out the term in parentheses immediately following the acronym) for all to &#8220;see&#8221;: in such cases also using an ABBR or ACRONYM would by dysfunctionally redundant (as, for instance, someone using a screen reader would then wrongly hear the expanded form twice).</p>
<p>sjw: *All acronyms should be tagged to force the screen readers to read them as separate letters instead of a word but the title element should only be used in the first instance. For example: ISO.<br />
David: Untagged, the screen reader is going to read an all caps word as separate letters. And I think that all instances should be coded identically (see my next response&#8230;)</p>
<p>sjw: *Once the first instance of the acronym has been coded with the correct syntax as in the first bullet, it is not necessary to wrap the other instances of the acronym in a tag.<br />
David: Although there is a debate around whether to TITLE every instance or just the first instance, I&#8217;m in the every-instance camp, for many reasons:<br />
	- there are cases where the same abbreviation will appear with two different meanings on the same page, for example &#8220;Dr. Bombay, 123 Riverside Dr., Ottawa&#8221;.<br />
	- not every assistive technology is going to elegantly apply the one instruction to all instances of an identical abbreviation, and we are always seeking device independence<br />
	- down the road a developer or algorithm may cut and paste a portion of your page into another page, and thus lose the rule<br />
	- it is more difficult to do quality assurance if not all instances are handled the same way</p>
<p>sjw: *If the tag is presented without the title element most browsers present an indicator that there is attached info. However, for the sighted user this is incorrect but this does allow the unsighted user to get the acronym delivered correctly. Which way should have precedence in your opinion?<br />
David: I recommend that you always include the title attribute. Also, don&#8217;t forget the value of potentially also including a LANG attribute whenever the expanded version is not in the language of the page.</p>
<p>sjw: *Acronym tags are not mandatory in WCAG 2.0.<br />
David: Nothing is mandatory in WCAG 2.0 . Rather, for the example of Treasury Board of Canada, their site is governed by the Canadian government&#8217;s new Standard On Web Accessibility, which makes compliance mandatory for all WCAG 2.0 success criteria of Level A and Level AA (with some exceptions). Because the WCAG 2.0 success criterion for expanding on abbreviations (3.1.4) is designated Level AAA, including ABBR (or ACRONYM) is not mandatory under the Standard On Web Accessibility.</p>
<p>sjw: *Incorrect use of the acronym tag is a fail under Success Criteria 1.3.1 – Technique F43.<br />
David: Yes, that would be a Level A failure. I think what we&#8217;re getting at here is someone wrongly using ABBR or ACRONYM to force the visual dotted underline effect in many browsers. Of course, more generally, there are other success criteria which would also be failed with wonton miscoding of ABBR (or any element for that matter).</p>
<p>All around, ABBR elements are a blessing, and one can even control them further through CSS. And, although designated Level AAA, the folks in marketing for sites seeking A or AA compliance will also appreciate the potential control that the use of ABBR can give to how any abbreviated brand &#8220;sounds&#8221; online.</p>
<p>Final tip: don&#8217;t forget that you can also use ABBR in the opposite way in table header rows, providing a more terse alternative heading that will have the benefit of reducing the read-out-loud time of phrases that will be read repeatedly by a screen reader.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The New Standard on Web Accessibility: WCAG 2.0 by sjw</title>
		<link>http://www.davidberman.com/courses/web-accessibility-course/#comment-376</link>
		<dc:creator>sjw</dc:creator>
		<pubDate>Thu, 26 Jan 2012 20:10:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.davidberman.com/courses/web-accessibility/#comment-376</guid>
		<description>&lt;h3&gt;Abbreviations&lt;/h3&gt;My question relates to the use of acronym tags, however, I realize that this tag is being deprecated in HTML5.   Regardless, the use of the tag whether it be acronym or abbr remains the same.  As you know the federal government has its own language in acronyms and often page content can contain not just many instances of a particular acronym but also may have many different acronyms present as well.  Understanding the correct implementation of this tag will save hours of rework in the future.  Please correct any wrong statements and elaborate on the misunderstood statements below.

* The correct syntax of an acronym tag is &lt;acronym title=&quot;TBS&quot;&gt;Treasury Board Secretariat&lt;/acronym&gt;.

*All acronyms can be tagged but the title element is always used in the tag when present.

*All acronyms should be tagged to force the screen readers to read them as separate letters instead of a word but the title element should only be used in the first instance.  For example: &lt;acronym&gt;ISO&lt;/acronym&gt;.

*Once the first instance of the acronym has been coded with the correct syntax as in the first bullet, it is not necessary to wrap the other instances of the acronym in a tag.

*If the tag is presented without the title element most browsers present an indicator that there  is attached info.  However,  for the sighted user this is incorrect but this does allow the unsighted user to get the acronym delivered correctly.  Which way should have precedence in your opinion?

*Acronym tags are not mandatory in WCAG 2.0.

*Incorrect use of the acronym tag is a fail under Success Criteria 1.3.1 - Technique F43.</description>
		<content:encoded><![CDATA[<h3>Abbreviations</h3>
<p>My question relates to the use of acronym tags, however, I realize that this tag is being deprecated in HTML5.   Regardless, the use of the tag whether it be acronym or abbr remains the same.  As you know the federal government has its own language in acronyms and often page content can contain not just many instances of a particular acronym but also may have many different acronyms present as well.  Understanding the correct implementation of this tag will save hours of rework in the future.  Please correct any wrong statements and elaborate on the misunderstood statements below.</p>
<p>* The correct syntax of an acronym tag is <acronym title="TBS">Treasury Board Secretariat</acronym>.</p>
<p>*All acronyms can be tagged but the title element is always used in the tag when present.</p>
<p>*All acronyms should be tagged to force the screen readers to read them as separate letters instead of a word but the title element should only be used in the first instance.  For example: <acronym>ISO</acronym>.</p>
<p>*Once the first instance of the acronym has been coded with the correct syntax as in the first bullet, it is not necessary to wrap the other instances of the acronym in a tag.</p>
<p>*If the tag is presented without the title element most browsers present an indicator that there  is attached info.  However,  for the sighted user this is incorrect but this does allow the unsighted user to get the acronym delivered correctly.  Which way should have precedence in your opinion?</p>
<p>*Acronym tags are not mandatory in WCAG 2.0.</p>
<p>*Incorrect use of the acronym tag is a fail under Success Criteria 1.3.1 &#8211; Technique F43.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

