<?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: Standards.Next: cognition and accessibility</title>
	<atom:link href="http://www.brucelawson.co.uk/2009/standards-next-cognition-and-accessibility/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.brucelawson.co.uk/2009/standards-next-cognition-and-accessibility/</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: Best Practice: Use native form elements whenever possible - Space Ninja</title>
		<link>http://www.brucelawson.co.uk/2009/standards-next-cognition-and-accessibility/comment-page-1/#comment-675832</link>
		<dc:creator>Best Practice: Use native form elements whenever possible - Space Ninja</dc:creator>
		<pubDate>Tue, 22 Jun 2010 20:52:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.brucelawson.co.uk/?p=2094#comment-675832</guid>
		<description>[...] Form styling and accessibility [...]</description>
		<content:encoded><![CDATA[<p>[...] Form styling and accessibility [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bruce</title>
		<link>http://www.brucelawson.co.uk/2009/standards-next-cognition-and-accessibility/comment-page-1/#comment-639456</link>
		<dc:creator>bruce</dc:creator>
		<pubDate>Thu, 29 Oct 2009 07:44:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.brucelawson.co.uk/?p=2094#comment-639456</guid>
		<description>Ben - in the real world of commercial web development, people won&#039;t use any of the new form input types if they look ugly and can&#039;t be styled to fit the rest of the page.

jQuery UI http://jqueryui.com/ has some great-looking widgets faked in JavaScript; no incentive for devs to move from that.</description>
		<content:encoded><![CDATA[<p>Ben &#8211; in the real world of commercial web development, people won&#8217;t use any of the new form input types if they look ugly and can&#8217;t be styled to fit the rest of the page.</p>
<p>jQuery UI <a href="http://jqueryui.com/" rel="nofollow">http://jqueryui.com/</a> has some great-looking widgets faked in JavaScript; no incentive for devs to move from that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben Millard</title>
		<link>http://www.brucelawson.co.uk/2009/standards-next-cognition-and-accessibility/comment-page-1/#comment-638707</link>
		<dc:creator>Ben Millard</dc:creator>
		<pubDate>Sat, 24 Oct 2009 20:52:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.brucelawson.co.uk/?p=2094#comment-638707</guid>
		<description>&lt;blockquote&gt;Unfortunately, I see nothing in CSS that allows me to style calendar widgets for input type=&quot;date&quot; so I could (for example) style weekends in red and weekdays in black, or change the way the pointer looks on input type=&quot;range&quot;.&lt;/blockquote&gt;

Indeed. That&#039;s why I think the money should be going on the long-term CSS solutions to these things, instead of band-aid-to-HTML solutions like WAI-ARIA.

&quot;Do it once, do it right.&quot;</description>
		<content:encoded><![CDATA[<blockquote><p>Unfortunately, I see nothing in CSS that allows me to style calendar widgets for input type=&#8221;date&#8221; so I could (for example) style weekends in red and weekdays in black, or change the way the pointer looks on input type=&#8221;range&#8221;.</p></blockquote>
<p>Indeed. That&#8217;s why I think the money should be going on the long-term CSS solutions to these things, instead of band-aid-to-HTML solutions like WAI-ARIA.</p>
<p>&#8220;Do it once, do it right.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alberto Calvo</title>
		<link>http://www.brucelawson.co.uk/2009/standards-next-cognition-and-accessibility/comment-page-1/#comment-636596</link>
		<dc:creator>Alberto Calvo</dc:creator>
		<pubDate>Sun, 11 Oct 2009 08:18:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.brucelawson.co.uk/?p=2094#comment-636596</guid>
		<description>Another stuff that I want to aboard is the ugly default style for HTML5 forms on Opera, which I really hope they can be changed in the future. Using colors and complicate metaphors are bad ideas. What about using a set of default SVG glyphs that change its color depending of the input&#039;s color property? Of course, that SVG glyphs, should be able to change to via CSS :)

In example, you could check http://www.culinaryculture.com/ . Don&#039;t check the source, but the glyphs. IMO, they&#039;re pretty much well integrated with every page design. They&#039;re neutral with the design and very meaningful to the user.</description>
		<content:encoded><![CDATA[<p>Another stuff that I want to aboard is the ugly default style for HTML5 forms on Opera, which I really hope they can be changed in the future. Using colors and complicate metaphors are bad ideas. What about using a set of default SVG glyphs that change its color depending of the input&#8217;s color property? Of course, that SVG glyphs, should be able to change to via CSS <img src='http://www.brucelawson.co.uk/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>In example, you could check <a href="http://www.culinaryculture.com/" rel="nofollow">http://www.culinaryculture.com/</a> . Don&#8217;t check the source, but the glyphs. IMO, they&#8217;re pretty much well integrated with every page design. They&#8217;re neutral with the design and very meaningful to the user.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bruce</title>
		<link>http://www.brucelawson.co.uk/2009/standards-next-cognition-and-accessibility/comment-page-1/#comment-636409</link>
		<dc:creator>bruce</dc:creator>
		<pubDate>Sat, 10 Oct 2009 08:01:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.brucelawson.co.uk/?p=2094#comment-636409</guid>
		<description>Ben, the source is an email.

I can&#039;t see what the main point of your comment was; if it was to tell me that you disagree with my markup choices, then: noted.

I agree with you that &quot;Native controls are natively accessible. Styling them with CSS is consistent with styling anything else in HTML.&quot;

Unfortunately, I see nothing in CSS that allows me to style calendar widgets for &lt;code&gt;input type=&quot;date&quot;&lt;/code&gt; so I could (for example) style weekends in red and weekdays in black, or change the way the pointer looks on &lt;code&gt;input type=&quot;range&quot;&lt;/code&gt;.

Until these can be styled by designers, they will use the jQuery-like UI libraries that allow such styling as they &quot;fake&quot; the form controls. This means potentially less accessibility, more code and slower uptake of the native form controls.

If it were up to me, I would like the browser manufacturers to get together to agree a temporary measure for solving designers&#039; natural wish to style. Perhaps something like vendor specific CSS but instead of a vendor prefix, something like -html5-slider-pointer that could be given a background image, colours etc.</description>
		<content:encoded><![CDATA[<p>Ben, the source is an email.</p>
<p>I can&#8217;t see what the main point of your comment was; if it was to tell me that you disagree with my markup choices, then: noted.</p>
<p>I agree with you that &#8220;Native controls are natively accessible. Styling them with CSS is consistent with styling anything else in HTML.&#8221;</p>
<p>Unfortunately, I see nothing in CSS that allows me to style calendar widgets for <code>input type="date"</code> so I could (for example) style weekends in red and weekdays in black, or change the way the pointer looks on <code>input type="range"</code>.</p>
<p>Until these can be styled by designers, they will use the jQuery-like UI libraries that allow such styling as they &#8220;fake&#8221; the form controls. This means potentially less accessibility, more code and slower uptake of the native form controls.</p>
<p>If it were up to me, I would like the browser manufacturers to get together to agree a temporary measure for solving designers&#8217; natural wish to style. Perhaps something like vendor specific CSS but instead of a vendor prefix, something like -html5-slider-pointer that could be given a background image, colours etc.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben Millard</title>
		<link>http://www.brucelawson.co.uk/2009/standards-next-cognition-and-accessibility/comment-page-1/#comment-636255</link>
		<dc:creator>Ben Millard</dc:creator>
		<pubDate>Fri, 09 Oct 2009 13:05:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.brucelawson.co.uk/?p=2094#comment-636255</guid>
		<description>Bruce, what was the original source for that quote? The &lt;code&gt;cite&lt;/code&gt; attribute is absent from the &lt;code&gt;&lt;blockquote&gt;&lt;/code&gt; and the preceding paragraph only points to the homepage of the author.

I tried some searches using that website&#039;s search box but couldn&#039;t find a page with the content you have quoted. For example, there were &lt;a href=&quot;http://www.zeroedandnoughted.com/?s=BSkyB&quot; rel=&quot;nofollow&quot;&gt;no results from a search for &quot;BSkyB&quot;&lt;/a&gt;.

As for whether an ordered list should use &lt;code&gt;&lt;ol&gt;&lt;/code&gt;, well, I thought semantic markup was a good thing? :P

If you are quoting from speech rather than from a written source, conveying the structure of that speech using markup is appropriate. Especially since text loses the manner and timing with which it was said. (The absence of speechmarks mean I&#039;m not sure speech was the source, either.)

Adjusting poor form when quoting material is also a valid thing to do, so long as the edits are marked. This includes correcting typos, removing invalid or presentational markup, changing the visual style and replacing URLs-as-link-text with proper link text. All come under the editorial prerogative of a site owner who chooses to quote from another source, AFAICT.

Such edits do not change the meaning. On the contrary: they make the meaning more apparent.

Did you have any thoughts about the main body of my comment?</description>
		<content:encoded><![CDATA[<p>Bruce, what was the original source for that quote? The <code>cite</code> attribute is absent from the <code>&lt;blockquote&gt;</code> and the preceding paragraph only points to the homepage of the author.</p>
<p>I tried some searches using that website&#8217;s search box but couldn&#8217;t find a page with the content you have quoted. For example, there were <a href="http://www.zeroedandnoughted.com/?s=BSkyB" rel="nofollow">no results from a search for &#8220;BSkyB&#8221;</a>.</p>
<p>As for whether an ordered list should use <code>&lt;ol&gt;</code>, well, I thought semantic markup was a good thing? <img src='http://www.brucelawson.co.uk/wp-includes/images/smilies/icon_razz.gif' alt=':P' class='wp-smiley' /> </p>
<p>If you are quoting from speech rather than from a written source, conveying the structure of that speech using markup is appropriate. Especially since text loses the manner and timing with which it was said. (The absence of speechmarks mean I&#8217;m not sure speech was the source, either.)</p>
<p>Adjusting poor form when quoting material is also a valid thing to do, so long as the edits are marked. This includes correcting typos, removing invalid or presentational markup, changing the visual style and replacing URLs-as-link-text with proper link text. All come under the editorial prerogative of a site owner who chooses to quote from another source, AFAICT.</p>
<p>Such edits do not change the meaning. On the contrary: they make the meaning more apparent.</p>
<p>Did you have any thoughts about the main body of my comment?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

