<?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 Are Not Just Stuff and Nonesense</title>
	<atom:link href="http://john.foliot.ca/standards-are-not-just-stuff-and-nonesense/feed/" rel="self" type="application/rss+xml" />
	<link>http://john.foliot.ca/standards-are-not-just-stuff-and-nonesense/</link>
	<description>...my perspective - without apology</description>
	<lastBuildDate>Sun, 22 Jan 2012 07:27:46 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Raph de Rooij</title>
		<link>http://john.foliot.ca/standards-are-not-just-stuff-and-nonesense/comment-page-1/#comment-83</link>
		<dc:creator>Raph de Rooij</dc:creator>
		<pubDate>Tue, 06 Apr 2010 14:54:54 +0000</pubDate>
		<guid isPermaLink="false">http://john.foliot.ca/?p=131#comment-83</guid>
		<description>Standards are not just stuff and nonesense. You&#039;re absolutely right by that. But where would the web be without widely used specifications that don&#039;t meet all requirements that make it a standard. 
Examples are:
* HTTP (http://tools.ietf.org/html/rfc2817 - status: proposed standard)
* URI (http://tools.ietf.org/html/rfc4395 - status: best current practice)
* CSS 2.1 (http://www.w3.org/TR/CSS2/ - status: candidate recommendation)

Another example is WAI-ARIA. This is a very important specification to ensure accessibility of rich internet applications. The now available version of specification is already implemented in the major browsers. But no HTML specification is available in which the attributes are defined that WAI-ARIA relies upon. That makes it rather complicated if you care about accessibility and be standards-compliant at the same time. The simple fact that you use the aria-required attribute on this page proves my point...

I&#039;m with you that standards are really important. Sounds logical, since I work for the national government, have a J-O-B job, and mortgages, groceries, four kids ranging from 6 to 24 and a retirement portfolio that is still too weak to allow retirement at age 55. 

But your story doesn&#039;t convince me.

Why? 
1. Because today&#039;s web wouldn&#039;t even exist when only standards were allowed to be used;
2. And because most claims for standards compliance are a farce. Most web pages don&#039;t even validate against HTML specifications that are declared in the document itself, are open standards and haven&#039;t changed for over a decade. 

When it comes to web accessibility, the situation is even far worse. Since October 2008, I&#039;ve examined hundreds of websites for Self Declarations of Conformity (SDoC&#039;s) in relation with the Web Content Accessibility Guidelines. More precise: WCAG 1.0, priority 1 checkpoints; this is the bare minimum for web accessibility. In all cases, the claim could not be confirmed. Only claims proved to be trustworthy that were based on a test carried out by an independent third party. 

I still believe that &#039;the industry&#039; is able produce valid SDoC&#039;s. But first the majoririty of web companies has to get its act together. 
This is also the case for website owners, since they accept claims that are solely based on the _assumption_ that claims are true.
In other words: the current system of checks and balances simply doesn&#039;t work. It&#039;s not a technical problem, but a management problem that managers cannot make technical specialists responsible for.

In my opinion, only using standards sounds logical, but on the web it easily leads to numerous complications for website makers. Policy makers should be aware of that. Instead of requiring open standards for the web, they could also consider allowing open specifications that are widely implemented (open specification = all requirements of an open standard, except for the requirement that it is _approved_ as an open standard).

This is why I like the approach that thw W3C has taken in WCAG 2.0. Requirement of Success Criteron 4.1.1. is that web pages can be parsed. Page validation is a &#039;sufficient technique&#039; (www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-parses.html). This way, useful specifications such as WAI-ARIA can be applied, while maintaining the integrity of the markup language. It uses the property of browsers that elements and attributes are ignored that are not supported. 

Accessibility issues (such as the  element...) may occur, but those issues can be dealt with in WCAG 2.0 in a similar way as technologies such as Flash, preferably using a &#039;layered construction technique&#039;. That&#039;s the term we use for &#039;progressive enhancement&#039;. It&#039;s not about creating fallbacks for people with disabilities, but about creating enhancements for browsers that support it and thus create a richer experience.</description>
		<content:encoded><![CDATA[<p>Standards are not just stuff and nonesense. You&#8217;re absolutely right by that. But where would the web be without widely used specifications that don&#8217;t meet all requirements that make it a standard.<br />
Examples are:<br />
* HTTP (<a href="http://tools.ietf.org/html/rfc2817" rel="nofollow">http://tools.ietf.org/html/rfc2817</a> &#8211; status: proposed standard)<br />
* URI (<a href="http://tools.ietf.org/html/rfc4395" rel="nofollow">http://tools.ietf.org/html/rfc4395</a> &#8211; status: best current practice)<br />
* CSS 2.1 (<a href="http://www.w3.org/TR/CSS2/" rel="nofollow">http://www.w3.org/TR/CSS2/</a> &#8211; status: candidate recommendation)</p>
<p>Another example is WAI-ARIA. This is a very important specification to ensure accessibility of rich internet applications. The now available version of specification is already implemented in the major browsers. But no HTML specification is available in which the attributes are defined that WAI-ARIA relies upon. That makes it rather complicated if you care about accessibility and be standards-compliant at the same time. The simple fact that you use the aria-required attribute on this page proves my point&#8230;</p>
<p>I&#8217;m with you that standards are really important. Sounds logical, since I work for the national government, have a J-O-B job, and mortgages, groceries, four kids ranging from 6 to 24 and a retirement portfolio that is still too weak to allow retirement at age 55. </p>
<p>But your story doesn&#8217;t convince me.</p>
<p>Why?<br />
1. Because today&#8217;s web wouldn&#8217;t even exist when only standards were allowed to be used;<br />
2. And because most claims for standards compliance are a farce. Most web pages don&#8217;t even validate against HTML specifications that are declared in the document itself, are open standards and haven&#8217;t changed for over a decade. </p>
<p>When it comes to web accessibility, the situation is even far worse. Since October 2008, I&#8217;ve examined hundreds of websites for Self Declarations of Conformity (SDoC&#8217;s) in relation with the Web Content Accessibility Guidelines. More precise: WCAG 1.0, priority 1 checkpoints; this is the bare minimum for web accessibility. In all cases, the claim could not be confirmed. Only claims proved to be trustworthy that were based on a test carried out by an independent third party. </p>
<p>I still believe that &#8216;the industry&#8217; is able produce valid SDoC&#8217;s. But first the majoririty of web companies has to get its act together.<br />
This is also the case for website owners, since they accept claims that are solely based on the _assumption_ that claims are true.<br />
In other words: the current system of checks and balances simply doesn&#8217;t work. It&#8217;s not a technical problem, but a management problem that managers cannot make technical specialists responsible for.</p>
<p>In my opinion, only using standards sounds logical, but on the web it easily leads to numerous complications for website makers. Policy makers should be aware of that. Instead of requiring open standards for the web, they could also consider allowing open specifications that are widely implemented (open specification = all requirements of an open standard, except for the requirement that it is _approved_ as an open standard).</p>
<p>This is why I like the approach that thw W3C has taken in WCAG 2.0. Requirement of Success Criteron 4.1.1. is that web pages can be parsed. Page validation is a &#8216;sufficient technique&#8217; (www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-parses.html). This way, useful specifications such as WAI-ARIA can be applied, while maintaining the integrity of the markup language. It uses the property of browsers that elements and attributes are ignored that are not supported. </p>
<p>Accessibility issues (such as the  element&#8230;) may occur, but those issues can be dealt with in WCAG 2.0 in a similar way as technologies such as Flash, preferably using a &#8216;layered construction technique&#8217;. That&#8217;s the term we use for &#8216;progressive enhancement&#8217;. It&#8217;s not about creating fallbacks for people with disabilities, but about creating enhancements for browsers that support it and thus create a richer experience.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sarah Bourne</title>
		<link>http://john.foliot.ca/standards-are-not-just-stuff-and-nonesense/comment-page-1/#comment-77</link>
		<dc:creator>Sarah Bourne</dc:creator>
		<pubDate>Fri, 15 Jan 2010 23:00:28 +0000</pubDate>
		<guid isPermaLink="false">http://john.foliot.ca/?p=131#comment-77</guid>
		<description>Hi, John, from the land of beleaguered government web workers-

Yes, it&#039;s as you say: we need nice, stable, open standards for any work we do. We are beholden to our taxpayers to ensure that our output is available to all, regardless of what browser they use and whether or not they also use screen readers or magnifiers or speech synthesis. We also need to do our work so that it doesn&#039;t have to be redone all the time to use the Stupid Web Trick du jour, or to recover from having done so before. We have about 350,000 pieces of content (not including navigation pages!) on Mass.gov - whimsy is not very attractive.

But there&#039;s more. We don&#039;t use HTML just for &quot;websites&quot;. HTML is becoming the standard interface for our mission critical applications. Despite efforts to keep the presentation separate from the business logic, there is always some markup that gets muddled in with the business logic, where it is risky to make changes.

From an overall IT perspective, web pages are just another source of data, so we are interested in metadata standards that will work with them as well as with more structured applications.

Indeed, the impression that I get is that HTML5 is being crafted with the bespoke, stand-alone website in mind, and perhaps won&#039;t speak to the other, more utilitarian uses of HTML.

If it doesn&#039;t meet legal and practical needs, it&#039;s unlikely to be adopted as a government standard, and what good is a specification that governments and large corporations can&#039;t use?</description>
		<content:encoded><![CDATA[<p>Hi, John, from the land of beleaguered government web workers-</p>
<p>Yes, it&#8217;s as you say: we need nice, stable, open standards for any work we do. We are beholden to our taxpayers to ensure that our output is available to all, regardless of what browser they use and whether or not they also use screen readers or magnifiers or speech synthesis. We also need to do our work so that it doesn&#8217;t have to be redone all the time to use the Stupid Web Trick du jour, or to recover from having done so before. We have about 350,000 pieces of content (not including navigation pages!) on Mass.gov &#8211; whimsy is not very attractive.</p>
<p>But there&#8217;s more. We don&#8217;t use HTML just for &#8220;websites&#8221;. HTML is becoming the standard interface for our mission critical applications. Despite efforts to keep the presentation separate from the business logic, there is always some markup that gets muddled in with the business logic, where it is risky to make changes.</p>
<p>From an overall IT perspective, web pages are just another source of data, so we are interested in metadata standards that will work with them as well as with more structured applications.</p>
<p>Indeed, the impression that I get is that HTML5 is being crafted with the bespoke, stand-alone website in mind, and perhaps won&#8217;t speak to the other, more utilitarian uses of HTML.</p>
<p>If it doesn&#8217;t meet legal and practical needs, it&#8217;s unlikely to be adopted as a government standard, and what good is a specification that governments and large corporations can&#8217;t use?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jen</title>
		<link>http://john.foliot.ca/standards-are-not-just-stuff-and-nonesense/comment-page-1/#comment-76</link>
		<dc:creator>Jen</dc:creator>
		<pubDate>Fri, 15 Jan 2010 05:19:41 +0000</pubDate>
		<guid isPermaLink="false">http://john.foliot.ca/?p=131#comment-76</guid>
		<description>&quot;I do take umbridge with your comment (colored as it were by my specialty and focus) that “There are cases where it (accessibility) is less applicable”. Never! Accessibility must be foundational, and it should be every users right to access your (or your client’s) content equitably...&quot;

I have a specific case, a painter&#039;s portfolio. There&#039;s a point at which the accessibility is impacted by the subject matter of the site. That&#039;s what I referred to. Titles and alt tags and tabindices, etc, aside... nothing would deliver the paintings to absolutely everyone.</description>
		<content:encoded><![CDATA[<p>&#8220;I do take umbridge with your comment (colored as it were by my specialty and focus) that “There are cases where it (accessibility) is less applicable”. Never! Accessibility must be foundational, and it should be every users right to access your (or your client’s) content equitably&#8230;&#8221;</p>
<p>I have a specific case, a painter&#8217;s portfolio. There&#8217;s a point at which the accessibility is impacted by the subject matter of the site. That&#8217;s what I referred to. Titles and alt tags and tabindices, etc, aside&#8230; nothing would deliver the paintings to absolutely everyone.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

