Category Archives: Web Standards

How to Fix Your ExpressionEngine RSS Template

I began investigating the fascinating minutia of RSS when I couldn't find a reasonable answer in the EE forums to why Google Reader was re-posting every updated post on my site even thought the entry dates hadn't changed. As I went through the prevalent templates floating around the EE community line-by-line I noticed several things that could be improved upon. The only critical fix, in my opinion, is removal of seconds from the dates in the <item /> section. If you want your feed to validate you'll want to add the atom namespace. The rest are optional improvements.

If you want to skip the wheres and whys, I've posted the the updated (fixed) and improved RSS templates on Snipplr.com and in their entirety at the end of this article.

Existing RSS templates for ExpressionEngine

Resources

Methodology

I'm not going for a PHD in online syndication, I just wanted my RSS feeds to be error-free, work as expected in major aggregators and to use best-practices which could be determined within a somewhat low threshold of research pain. In addition to referring first to the RSS 2.0 specifications, I used the RSS feeds of some really large websites to serve as examples, making the assumption (I know) that these sites have probably done thorough research on this topic. Often my choices were the result of seeing if these "big players" were all doing the same thing. All the feeds are major sites with the exception of the Flickr blog. The Flickr blog is using WordPress.com. I figured with their huge user-base not only would the feeds have been thoroughly vetted, most aggregators will be able to read them due to the sheer volume of WordPress-powered sites out there. Also I chose a WordPress.com feed instead of a self-hosted installation of WP to make sure it was the well-tested standard feed. The feeds I used are:

RSS Feed Breakdown

Feed Format: RSS vs. Atom

As of mid-2005, the two most likely candidates are RSS 2.0 and Atom 1.0. Google reader supports either fully and they suggest choosing one or the other (not both) because most RSS readers support all major formats and offering both can confuse users. The Atom syndication format, whose creation was in part motivated by a desire to get a clean start free of the issues surrounding RSS, has been adopted as IETF Proposed Standard RFC 4287 and is used by Google. However, RSS 2.0 was the first to support enclosures and has captured the podcasting audience and is the recommended format in the iTunes podcasts specs.

I generally do as Google does when it comes to web optimization, and I am a big fan of standards. In some regards I would call Atom "the higher path". That said, I am also a big fan of simplicity and ease-of-use so I'm going with RSS 2.0 because:

  • I already hand-built an RSS 2.0 feed for podcasting (well, for iTunes) so would rather learn one standard / keep all feeds similarly formatted.
  • One less term that could potentially confuse end-users and "web lite" folk who might inherit my work later on.
  • A lot of really big sites that have probably carefully considered this topic went with RSS 2.0, including NYTimes.com, AListApart.com, Ebay.com, news.BBC.co.uk, and CNN.com.

RSS XML Namespaces

Here's where my first change kicks in. If you aren't actually USING a namespace in your RSS feed there's no need to include it - it's just cruft.

Before

<rss version="2.0"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:admin="http://webns.net/mvcb/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:content="http://purl.org/rss/1.0/modules/content/">

After

<rss version="2.0"
xmlns:dc="http://purl.org/dc/elements/1.1/">

Even Better

<rss version="2.0"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom">

The namespaces sy and content aren't used at all and can just be removed. Optional: I chose to remove xmlns:admin="http://webns.net/mvcb/" and the only tag that used it, <admin:generatorAgent rdf:resource="http://expressionengine.com/" /> - removing the admin namespace also eliminated rdf, which admin namespace depends on.

I'm not saying any of the removed namespaces are bad, just unnecessary. For example, admin is a very common namespace, but if you leave it in you should update the URI to include the EE version number (dynamically) and add the <admin:errorReportsTo rdf:resource="URI"/> pointing to a valid email address for errors. It may be beneficial to aggregators in reporting statistical reporting of web frameworks and content management systems delivering aggregated RSS feeds.

I rather admire the efficency and simplicity of the namespace declarations used by NYTimes.com, CNN.com and others - so again, this is personal choice.

The third option (even better) adds the atom namespace. The default EE RSS feed will not validate because it lacks the required atom:link tag containing the URI of the feed itself. There is some debate on whether this is actually necessary (some say the validator is wrong, not the lack of the atom tag)- read the article Adding Atom:Link to Your RSS Feed for background on this.

Depending on your site's content, your SEO practices and target audience, it is likely that you may need additional namespaces. A media-rich site, for example, would benefit from the media namespace. The media namespace is used to syndicate video, images and other media and can open up your feed to consumption by media-rich aggregators and services like Cooliris and Yahoo Video Search.

Channel Area

Most of the default template makes perfect sense - just make sure to take a look at your feed output to make sure all the EE fields used have valid values. Also, make sure you want to the {weblog_foo} tags - if you are providing a site feed that combines multiple sections you will probably want to hand-edit many of the tags in the channel area.

Dates

Important tip: make sure your feed is correctly reporting the timestamp of your entry date. If the seconds are changing on an item whenever you make an update this will cause many aggregators, including Google Reader, to repost the entry to your RSS feed. Either take the seconds off the time or replace '%s' with an arbitrary static value like '15'.

A search for 'RSS Updates' in the EE Forums will reveal that many people have had this problem. I tested all the date fields in my feeds (see this thread for details) and found that although the entry date day, hour and minute doesn't change on update (as expected), the seconds do! This weird behavior has something to do with how the dates are stored in the database and/or how the date is interpreted by EEs date tags. What it means is that if you go back and edit a post from three years ago, some aggregators will repost the item to your RSS feed even though you did not change the entry date. This can be especially troubling if you like to go back and tweak a post a lot right after publishing - you may go to your feed reader to see it reposted several times in a row.

pubDate vs. dc:date

<pubDate> is part of the RSS 2.0 spec. A lot of feeds out there still use <dc:date> and this either because they kept it from their RSS 1.0 template (for which dc:date was the only option) or they really like the very popular Dublin Core namespace or they prefer it because of the ISO 8601 date format which is much more prevalent than the (really old, as in ARPANET old!) RFC 822 date format that <pubDate> uses. On one hand it makes sense to stay with the spec and pull in namespace elements only as required. On the other hand, it makes sense to provide output in the most reusable way (updated date format). Feed readers parse either just fine, so this is judgment call on your part. Here's an agrument for each:

Based on my own survey of the feeds referenced above, I opted to switch to <pubDate>, replacing <dc:date /> in the channel with:

<pubDate>{gmt_date format="%D, %d %M %Y %H:%i:%s %T"}</pubDate>

And replacing <dc:date /> in the item declaration(s) with:

<pubDate>{gmt_entry_date format=&qout;%D, %d %M %Y %H:%i %T"}</pubDate>

Item <title ... />

The default tag is fine, but if your content people keep putting special characters in their titles (like mine do) then you might want to add the protect_entities="yes" attribute to the {exp:xml_encode} tag. For example the main EE site I work on uses &#187; (») and &amp; (&) a lot in titles.

Even after protecting entities I was still having a heck of a time getting a trademark (™) symbol that is used on a site in many post titles and in a category to consistently display on both the webpage and in RSS feed aggregators - after some digging I realized the character entity that was being used (&#x2122;) for it was not the UTF-8 reference (&#8482;) specified as the encoding for both the RSS and XHTML. So, make sure you (or your content editors) use the correct character encoding entities for special characters!

Item <guid ... />

As formated in the official EE RSS template the <guid> is not a permalink, and therefore should have isPermaLink="false" attribute added to it. Of course you could use your actual permalink and then you could leave that off or change it to "true".

"We recommend the use of the Atom and RSS 2.0 elements to unambiguously identify items. An item that is updated should keep its original ID, and a new item should never reuse an older item's ID. Changing IDs unnecessarily may result in duplicate items, and reusing IDs may cause some items to be hidden. "Tag URIs" make good IDs, since they don't change even when you need to reorganize your links." - Google Reader Tips for Publishers > Implementing Feeds

The above recommendatio explains the multi-posting of an entry on update issue I referred to earlier. Because of this, you will probably want to remove the '%s' from the formatting attribute as well. So, change the gmt_entry_date format string in the <guid> line to "%H:%iZ".

Optionally, you could just use the actual URI of your article and change the isPermalink attribute to true. EE won't let you post two items with the same URL title within a weblog/channel, so you are pretty safe there (EE adds a number to the end of URL title if one already exists).

Item <description.../>

This line is technically fine, but most people will change this to allow HTML formatting of their entries: <description><![CDATA[{summary}{body}]]></description>. This is what displays the bulk of your entry item and where most of your site-specific customization will happen, Customizing ExpressionEngine RSS 2.0 Template on 'A Blog Not Limited' is a great resource for this.

Categories

The template uses <dc:subject>. Your feed will be more interoperable with other systems and make more sense programatically if each category is in its own tag. You can do this using the <dc:subject> format, or you can switch to using the <category> tag for each as provided for in the RSS 2.0 spec.

Original Template

Code:

<dc:subject>{exp:xml_encode}{categories backspace="1"}{category_name}, {/categories}{/exp:xml_encode}</dc:subject>

Result:

<dc:subject>Architecture, Science, Workplace</dc:subject>

Separate using <dc:subject>

Code:

{categories}<dc:subject>{exp:xml_encode}{category_name}{/exp:xml_encode}</dc:subject>{/categories}

Result:

<dc:subject>Architecture</dc:subject>
<dc:subject>Science</dc:subject>
<dc:subject>Workplace</dc:subject>

Separate using <category>

Code:

{categories}<category>{exp:xml_encode}{category_name}{/exp:xml_encode}</category>{/categories}

Result:

<category>Architecture</category>
<category>Science</category>
<category>Workplace</category>

Updated EE RSS 2.0 Template

This includes what I consider minimal mandatory fixes to ensure error-free code and to prevent (re)posting problems.

{assign_variable:master_weblog_name="blog"}
{assign_variable:master_weblog_status="open"}
{exp:rss:feed weblog="{master_weblog_name}" status="{master_weblog_status}"}

<?xml version="1.0" encoding="{encoding}"?>
<rss version="2.0"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:admin="http://webns.net/mvcb/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <channel>
    <title>{exp:xml_encode}{weblog_name}{/exp:xml_encode}</title>
    <link>{weblog_url}</link>
    <description>{weblog_description}</description>
    <dc:language>{weblog_language}</dc:language>
    <dc:creator>{email}</dc:creator>
    <dc:rights>Copyright {gmt_date format="%Y"}</dc:rights>
    <dc:date>{gmt_date format="%Y-%m-%dT%H:%i:%s%Q"}</dc:date>
    <admin:generatorAgent rdf:resource="http://expressionengine.com/" />
{exp:weblog:entries weblog="{master_weblog_name}" limit="10" rdf="off" dynamic_start="on" disable="member_data|trackbacks" status="{master_weblog_status}"}
    <item>
      <title>{exp:xml_encode}{title}{/exp:xml_encode}</title>
      <link>{title_permalink=site/index}</link>
      <guid isPermaLink="false">{title_permalink=site/index}#When:{gmt_entry_date format="%H:%iZ"}</guid>
      <description>{exp:xml_encode}{summary}{body}{/exp:xml_encode}</description>
      <dc:subject>{exp:xml_encode}{categories backspace="1"}{category_name}, {/categories}{/exp:xml_encode}</dc:subject>
      <dc:date>{gmt_entry_date format="%Y-%m-%dT%H:%i%Q"}</dc:date>
    </item>
{/exp:weblog:entries}
    </channel>
</rss>
{/exp:rss:feed}

Improved EE RSS 2.0 Template

This includes optional changes that I added as a result of various articles, the RSS 2.0 spec and by examining the feeds of major professional news sites.

{assign_variable:master_weblog_name="BLOG"}
{assign_variable:master_weblog_status="OPEN"}
{assign_variable:master_rss_uri="http://PATH/TO/THIS/RSS/FEED"}

{exp:rss:feed weblog="{master_weblog_name}" status="{master_weblog_status}"}
<?xml version="1.0" encoding="{encoding}"?>
<rss version="2.0"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
    <title>{exp:xml_encode}{weblog_name}{/exp:xml_encode}</title>
    <link>{weblog_url}</link>
    <description>{weblog_description}</description>
    <dc:language>{weblog_language}</dc:language>
    <dc:creator>{email}</dc:creator>
    <dc:rights>Copyright {gmt_date format="%Y"}</dc:rights>
    <pubDate>{gmt_date format="%D, %d %M %Y %H:%i:%s %T"}</pubDate>
    <atom:link href="{master_rss_uri}" rel="self" type="application/rss+xml" />   
{exp:weblog:entries weblog="{master_weblog_name}" limit="10" rdf="off" dynamic_start="on" disable="member_data|trackbacks" status="{master_weblog_status}"}
    <item>
      <title>{exp:xml_encode protect_entities="yes"}{title}{/exp:xml_encode}</title>
      <link>{title_permalink=site/index}</link>
      <guid isPermaLink="false">{title_permalink="site/index"}#id:{entry_id}#date:{gmt_entry_date format="%H:%i"}</guid>
      <description><![CDATA[{summary}{body}]]></description>
      {categories}<category>{exp:xml_encode protect_entities="yes"}{category_name}{/exp:xml_encode}</category>
      {/categories}
      <pubDate>{gmt_entry_date format="%D, %d %M %Y %H:%i %T"}</pubDate>
    </item>
{/exp:weblog:entries}
    </channel>
</rss>
{/exp:rss:feed}						

Feedback

Please let me know if you have any suggestions for improvements on the basic template. I have already submitted these suggestions (as have others) on the EE Forums and I hope this article will soon be out-dated. For further information on customizing your RSS feed including adding Google Analytics tracking and additional fields such as author name, see Customizing ExpressionEngine RSS 2.0 Template at 'A Blog Not Limited' (if you use their updated template don't forget to remove the seconds from date fields in the item section).

Google Doctype Screams “Fork ME!”

The newly released Google Doctype is intended to be the Wikipedia of web design. There’s a video introduction on the landing page of Mark Pilgrim explaining what Google has been internally calling the the “Hitch Hikers Guide to the Web”. He’s been working on Google Doctype, said it is supposed to be the cross-platform alternative to MSDN. MSDN? I don’t know any web designers that rely on MSDN as the go-to spot for quality cross-platform client-side code! Maybe they’re targeting ASP.NET developers…and that could explain the very un-wiki linear treestyle navigation.

Google Doctype Screenshot

The Good

My own private wiki, largely comprised of web development documentation for my own projects, code snippits and links to online resources, is invaluable to me – so the potential benefits of an open wiki of this nature is obvious and I’ve often wondered why there isn’t one (with critical mass) out there already. Certainly this project, or at least the idea of it, could be an invaluable tool to professional web designers and client-side developers. Some take-aways:

  • “Written by web developers, for web developers” and by that they mean client-side developers…most of the current content is specific to JavaScript DOM stuff and cross-browser CSS considerations. I think this fills a knowledge gap as a lot of CSS and even Ajax resources are designer-oriented (lacking meaty technical details) and many developer resources gloss over or ignore web standards or a lot of the details professional programmers take for granted (like finding a viewport or using javascript to manipulate classes)
  • It’s built on the Google Project framework so you can download the whole thing via SVN.
  • The licensing is pretty unrestrictive, so you could SVN everything and put it up on an intranet statically or keep an off line copy, as was mentioned in the intro video.
  • Discrete code snippets. Rather than a long tutorial with examples that are specific to a given situation, many of the HOWTOs are broken down into more abstracted uses. This style of documentation will help a lot when your stuck on specific area of a bigger project. Personally, I learn more this way – I like the big step-by-step tutorials but when I cut and paste a lot I don’t retain very much.

The Ugly

Google suffers from chronic ugliness (IMHO) and this project is no exception. Don’t get me wrong, I’m GOOG fangirl all the way, but there always seems to be some basic user interface and user experience problems with their apps/portals/projects/whatever. And here’s where I think Google Doctype has need of improvement:

  • No indication of off-site links. Not only does a link to MSDN look just like the internal links, there are links to other Google Code project without any indications that you’re leaving Google Doctype, in fact, the logo is still Google Code. Navigation is a little confusing in general.
  • Lack of Style Guidelines. There is something to “just putting it out there” and I’m glad they did, but if a lot of people do start adding to this resource it could turn into quite a mess. It would have been ideal to have a written style established that would make sense for an open wiki. For example, statements like “generally, we recommend the following…” and “I’m not sure if this works on IE”. This type of thing would never fly on Wikipedia – now that the docs are open to the whole internets, such statements are ambiguous, lack authority and create a bad example that others are sure to follow.
  • Not really a wiki. First there’s the linear tree/node navigation pane (which seems to collapse by itself and disappear or reappear for no apparent reason) . There is no discussion page (although there are comments, sort of like PHP.net), no page history (but you can manually add a free-form line to a log file, if you notice the option), there’s no obvious way to check to see what links to a page, the list goes on.
  • Screaming “Fork Me”. A fork may be inevitable, and if a fork emerges using MediaWiki or any of a myriad of much more robust wiki platforms, I would be more likely to invest my time in that in spite of the Google mind share.

A Web Reference To Rule Them All

When I first read that Google published a web design wiki I was thrilled. I tried to think of other, similar resources. There are some great blogs, lists and forums out there but I’ve yet to find the one web reference to rule them all. If you know of one, please let me know! In the meantime I’m looking for domains…webwiki.com is just a db error, webwiki.net is a half-baked attempt at a wiki version of the Million Dollar Homepage. Hrm. If I come up with a load of extra time and a brilliant idea I will let you know. In the mean time, here are a few of my favorite web coder sites:

  • W3C.org – start at the top, right?
  • HTML Dog – very well organized reference and tutorials for CSS and (x)HTML
  • A List Apart – high quality articles published by those web standards freaks at Happy Cog.

Major Search Engines Agree to Sitemap Standard

Excellent news for web designers…there’s just one sitemap standard to worry about for all the major search engines. Google, Yahoo and Microsoft agreed, this bears repeating, agreed to use the same Sitemaps protocol to index sites around the web.  Visit sitemaps.org to learn how to create an XML file that tells spiders where to go and what has changed. If you’ve already been using Google sitemaps, it’s the same protocol.

Read more on TechCrunch.

Classic ASP vs. ASP.NET 2.0 Productivity

I’ve been doing a lot of .NET tutorials but hadn’t yet applied much to the real world. The one .NET app I’ve done for work so far was largely designed to the constraints of my experience, unfortunately. I was curious to see how difficult it would be to design a dynamic ASPX page that lived up to my usual standards – aesthetically, usability-wise and functionally. In this case, I wanted to add a summary table of all the data collected from a web form that was written in classic ASP, XHTML/CSS and Javascript.

Easier than I thought! I created a “new website” in the location of the old asp pages, Visual Studio automatically adds server extensions (an isolated app pool) and, though VS actually warned me, I had to manually set the directory to use ASP.NET 2.0 framework. The solution explorer view automatically included all of the content in the website project. I created a new web form page, copied the framework xhtml from another page in the directory (sans ASP) by viewing the source in a browser (there were a lot of logic loops so it was much easier this way), fixed a couple small errors that VS 2005′s intellisense picked up right away, and then went into design view – dropped an Access (OLEDB) datasource and a datagrid to consume it on the page, configured that, added CSS classes to make it pretty, and walah! I couldn’t flippin believe it
It’s so easy to expose database data and include paging and sorting automatically. That’s the power of the datagrid – displaying data from a database in ASP is no big deal (once you’ve worked out security issues and connection strings in your environment) but extra things like paging and sorting, while certainly doable, are no where near as easy. What surprised me the most, other than the shocking ease of creating a more or less XHTML compliant page using asp.net datacontrols, was how nice Visual Studio 2005 was as a general editor for old ASP pages and CSS files.

Kentucky Horse race, photo by flickr user Gearhart

It was timely coincidence that an article called Microsoft Visual Studio 2005: Productivity Study appeared on the top of the article stack that is presented to you on opening VS 2005. The article had a big callout stating:

ASP.NET 2.0 developers accomplished 113% more tasks in the same amount of time as ASP developers; ASP.NET 2.0 developers created web content pages up to 357% faster than ASP developers.

I actually thought the first number was low, if in fact they were using experienced .NET developers, as so much is automated, you have a full programming language to use and a plethora of built-in objects to leverage. But then the article continued:

The approach to this study was to recruit experienced developers in each of the development disciplines, ASP and ASP.NET 2.0. This resulted in two equal-sized developer groups, four developers in each group.

And then I stopped reading. I mean, why bother? A total of 8 developers made up their test case? WTF?! This is a pseudoscientific approach that is more like a raffle than a real study you can actually derive meaning from.

From my personal and to date, somewhat limited, perspective – I think it’s the paradigm shift and learning curve that makes new developers (like me) slow as molasses on .NET. There are a lot of developers who are really comfy in classic ASP and having gone from PHP to ASP for work, I can say it’s much easier than going to .NET…initially.

Once a developer has a good grasp on OOP and resources available in .NET framework I would guess the numbers are likely more disparate. Throw in a few different types of programming challenges, a larger test case, and make sure to include some projects the devs don’t already know how to do…then you start to see how much more (or less) developing in .NET is. I would like to read that report when and if it becomes available.

Learn Web Design

Web Design is not what it used to be. It’s now a sort of nebulous term that encompasses a LOT of technologies. No matter what sort of sites you plan on designing, I feel there’s no substition for a good understanding of standards-compliant xhtml and css. Of course, it helps if you know some graphics programs too, like Photoshop or the cheaper alternative, Paintshop Pro. Notice I didn’t mention any web design programs…well, I said learn web design not make a website real quick and dirty like.

Here’s some of my advice under ‘Learn Web Design‘ at 43things…a place where people tag, discuss and connect about things they’ve done and would like to do.

Getting started.
A word on web standards.

How to Save 2 Terabytes of Bandwidth A Day

Well, obviously, you first have to have a website that generates over 2 terabytes of traffic a day. Then, you have to have an old and/or poorly designed website, preferably with lots of nested HTML tables for display or over-use of Flash. The answer: Web Standards Redesign.  While most people don’t have the luxury/problem of that much traffic, the fact that switching to web standardards saved ESPN.com 2,000 gigs a day speaks volumes about the advantages of building with webstandards.  So now we standards-luvin’ designers have a large-scale, explicit, metrics-driven example to tell the accountants…there’s no guarantee it will similarly affect fancy visual gadget loving flash-addicts.

Read Interview: The ESPN.com Redesign.

Unrealized CSS Selectors

I just finished reading the Selectutorial. (Actually, I’ve read it before but my CSS skills were not developed enough at the time to make any of it relevant enough to me to remember.) I must say, now that I fully understand it, it’s an different sort of excercise in frustration. Why? There are a lot of really, really useful CSS selectors that can’t be used. At least, not on a client’s site. With every new selector my excitement would build, until the summary: "…not supported by Windows Internet Explorer 5, 5.5 and 6, but are supported by most other standards-compliant browsers."

Think child selectors, adjacent sibling selectors, attribute selectors and the :before and :after pseudo-classes are just for CSS geeks? They could be regular part of your web-design diet, simplifying things like adjusting spacing conditionally depending on whether an element is right next to another. I could have used the attribute selectors to make only my little ‘off-site link’ images inline for a recent site instead of applying a class in the structural code to every freggin image tag!

It’s a shame that the worlds richest software company, fueled with hiring power and a presumably very well-educated and/or skilled workforce can’t make their browser standards compliant. If it wasn’t for Internet Explorer’s bad but predominant browser, things could be so much more efficient for everyone. Though I’ve applauded the relative dissapearance of "This site is best viewed in…" statement, I think I would now welcome "Best viewed in a standards compliant browser (Internet Explorer, try Firefox ).

Monitors for the Color Blind

chosun.com reported yesterday that Samsun is planning to release monitors for the color blind:

Samsung announced … it is developing liquid crystal display (LCD) monitors that support color correction technology for people with dyschromatopsia or color blindness and will launch them in the first half of the year. People with dyschromatopsia have difficulty telling differences in color and need stronger stimuli than the normally sighted.

This is great news, not just for those with visual impairments, but for web developers, web site owners and in fact for anyone who develops a product to be viewed onscreen. With the advent of web standards and separation of display and content through proper use of CSS and XHTML great strides have already been made in making the web a more accessible place. The fact that search engine spiders are basically ‘blind’ users, is a major incentive as well. Unfortunately, considerations for those with less extreme visual impairments have been little implemented, though some tools do exist for developing web sites with that in mind, such as VisCheck.

Although at first this upcoming technology may only be available to those with a certain income level, it is still a major step in allowing more access to more content to more people and a comes as a great relief to designers who would like to design with a few fewer restrictions.

If you would like to know more about designing for accessibility, I highly recommend diveintoaccessibility.org. It should be required reading for anyone given publishing rights on any web server!