<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>From Accessibility to Zope &#187; Accessibility</title>
	<atom:link href="http://blog.mauveweb.co.uk/category/accessibility/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.mauveweb.co.uk</link>
	<description>experiments in contemporary web development</description>
	<lastBuildDate>Thu, 18 Aug 2011 23:26:00 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Semantic Whitespace</title>
		<link>http://blog.mauveweb.co.uk/2009/09/07/semantic-whitespace/</link>
		<comments>http://blog.mauveweb.co.uk/2009/09/07/semantic-whitespace/#comments</comments>
		<pubDate>Mon, 07 Sep 2009 13:35:11 +0000</pubDate>
		<dc:creator>mauve</dc:creator>
				<category><![CDATA[Accessibility]]></category>

		<guid isPermaLink="false">http://blog.mauveweb.co.uk/?p=318</guid>
		<description><![CDATA[Perhaps a little-known feature of many applications, including most web browsers, is that as well as click-and-drag selection, you can often use double-click-and-drag word selection. There's also a triple-click paragraph or line selection that you may not be aware of. (Internet Explorer has a heuristic selection model that makes it easier to select words at [...]]]></description>
			<content:encoded><![CDATA[<p>Perhaps a little-known feature of many applications, including most web browsers, is that as well as click-and-drag selection, you can often use double-click-and-drag word selection. There's also a triple-click paragraph or line selection that you may not be aware of. (Internet Explorer has a heuristic selection model that makes it easier to select words at the expense of making it harder to select arbitrary amounts of text.)</p>
<p>Though little-known, it's extremely useful! A favourite trick is to double-click and drag to select words, then right-click and "Search <em>current search provider</em> for".</p>
<p>This word selection can show up an accessibility problem. Browsers and probably some search engines identify words by splitting the content on whitespace and block-level <acronym title="HyperText Markup Language">HTML</acronym> tags &#8211; not on inline-level tags! This is sensible. If I write <strong>H</strong>yper<strong>T</strong>ext <strong>M</strong>arkup <strong>L</strong>anguage (ie. highlighting initials in bold), I don't want the semantic content to be "H yper T ext M arkup L anguage"!</p>
<p>The accessibility problem is this. With <acronym title="Cascading Style Sheets">CSS</acronym> it's possible to accidentally write <acronym title="HyperText Markup Language">HTML</acronym> that is neatly padded to look like words, but which doesn't tokenize (split up into words) properly. For two words to be considered separate you need to include <strong>semantic whitespace</strong>. Sites as big as Facebook and Twitter still make this mistake!</p>
<p>If your browser supports proper word selection (Internet Explorer's word-selection model is useless here), try double-clicking near formatting changes to check that your website is semantically correct.</p>
<p>Try it out! Can you detect the difference between these?</p>
<p>without<strong style="padding: 0 0.5em">semantic</strong>whitespace</p>
<p>with <strong>semantic</strong> whitespace</p>]]></content:encoded>
			<wfw:commentRss>http://blog.mauveweb.co.uk/2009/09/07/semantic-whitespace/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Tip: Don&#039;t use uppercase/lowercase in HTML</title>
		<link>http://blog.mauveweb.co.uk/2009/01/14/dont-use-uppercase-in-html/</link>
		<comments>http://blog.mauveweb.co.uk/2009/01/14/dont-use-uppercase-in-html/#comments</comments>
		<pubDate>Wed, 14 Jan 2009 14:54:13 +0000</pubDate>
		<dc:creator>mauve</dc:creator>
				<category><![CDATA[Accessibility]]></category>
		<category><![CDATA[CSS]]></category>
		<category><![CDATA[Tips]]></category>

		<guid isPermaLink="false">http://blog.mauveweb.co.uk/?p=231</guid>
		<description><![CDATA[It's sometimes tempting to use case for emphasis: uppercase and lowercase are well within the repertoire of useful graphic design tools. Graphic designers know that uppercase is slower to read than lower case, but in isolated phrases that's unimportant. But on the web there's a penalty to using just upper- or lowercase: it's not as [...]]]></description>
			<content:encoded><![CDATA[<p>It's sometimes tempting to use case for emphasis: uppercase and lowercase are well within the repertoire of useful graphic design tools. Graphic designers know that uppercase is slower to read than lower case, but in isolated phrases that's unimportant. But on the web there's a penalty to using just upper- or lowercase: it's not as accessible. Writing in normal sentence case conveys information. Specifically, the semantics of the sentence &#8211; particularly abbreviations &#8211; depend on the use of case, as this photo shows:</p>
<div id="attachment_232" class="wp-caption aligncenter" style="width: 310px"><img class="size-medium wp-image-232" title="BBC News 24's old text panel" src="http://blog.mauveweb.co.uk/wp-content/uploads/2009/01/image01-300x225.jpg" alt="NUT CONFERENCE" width="300" height="225" /><p class="wp-caption-text">NUT CONFERENCE</p></div>
<p><acronym title="Cascading Style Sheets">CSS</acronym> provides a way around this: the <code>text-transform</code> property. This allows you to write your content in full-sentence case, and display it in full uppercase or lowercase as desired for stylistic reasons. For example, if your design calls for &lt;h2&gt; tags to be in uppercase, use</p>
<p><code>h2 <span style="color: #66cc66;">&#123;</span><br />
<span style="color: #000000; font-weight: bold;">text-transform</span>: <span style="color: #993333;">uppercase</span>;<br />
<span style="color: #66cc66;">&#125;</span></code></p>
<p>Of course, this allows you to simply remove the property if you change your site design; no content needs to be rewritten.</p>
<p>Some <a href="http://www.networkrailmediacentre.co.uk/rss/default.aspx?feedid={E05B7BCC-AA48-48E2-B4AB-2C2A8F98619B}">offenders</a> even publish an <acronym title="Really Simple Syndication">RSS</acronym> feed using uppercase titles. Never do this. People who want to syndicate your feed normally want it in sentence case, and there's no way to force that to happen if you aren't publishing the <acronym title="Really Simple Syndication">RSS</acronym> feed using proper sentence case.</p>]]></content:encoded>
			<wfw:commentRss>http://blog.mauveweb.co.uk/2009/01/14/dont-use-uppercase-in-html/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>WCAG + Samurai</title>
		<link>http://blog.mauveweb.co.uk/2008/07/09/wcag-samurai/</link>
		<comments>http://blog.mauveweb.co.uk/2008/07/09/wcag-samurai/#comments</comments>
		<pubDate>Wed, 09 Jul 2008 11:17:21 +0000</pubDate>
		<dc:creator>mauve</dc:creator>
				<category><![CDATA[Accessibility]]></category>
		<category><![CDATA[Web Standards]]></category>

		<guid isPermaLink="false">http://blog.mauveweb.co.uk/?p=152</guid>
		<description><![CDATA[The WCAG Samurai Errata to WCAG 1.0 is an independently-produced set of amendments ("errata" is not really the right word) that fairly accurately nail how WCAG is and isn't working for pragmatic but standards-compliant developers like me.
I stumbled across this while browsing Google for references while writing a proposal for a client. I was writing [...]]]></description>
			<content:encoded><![CDATA[<p>The <a href="http://wcagsamurai.org/">WCAG Samurai Errata</a> to WCAG 1.0 is an independently-produced set of amendments ("errata" is not really the right word) that fairly accurately nail how WCAG is and isn't working for pragmatic but standards-compliant developers like me.</p>
<p>I stumbled across this while browsing Google for references while writing a proposal for a client. I was writing my usual set of caveats about the Web Content Accessbility Guidelines (WCAG), in which I lament how rubbish they are in practice. My usual spiel goes along the lines of "WCAG 1.0 informs all of our work at Mauve Internet. However, because the WCAG is subject to intepretation, and is now somewhat dated, we do not warrant conformance." I would like to make a clearer statement of how and why but a specification isn't really the place to challenge sections of the WCAG.</p>
<p>Happily, I can now get rid of this kind of non-committal note when writing specifications, and offer a firm commitment to WCAG+Samurai.</p>
<p>I will also be revising my company website &#8211; indeed, my company policy &#8211; to recommend conformance to the WCAG guidelines as amended by the WCAG Samurai Errata where possible.</p>]]></content:encoded>
			<wfw:commentRss>http://blog.mauveweb.co.uk/2008/07/09/wcag-samurai/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

