Read RSS Feeds and Blogs in Google Reader Offline with Google Gears

Tonight I sat down after dinner to read about what was happening in the blogsphere. I opened Google Reader. After a few minutes, I noticed a new feature. You can read your RSS Feeds and Blogs with Google Reader offline.

First you download the Firefox Extension Google Gears. Second you download the latest 2000 entries within Google Reader. Finally disconnect your computer from the Internet and you can read away.

It’s pretty nice.

I’m surprised I haven’t seen this mentioned yet on the Google Blog Reader Team Blog or the Google Corporate Blog. This is a neat feature.

Has anybody else gotten this yet?

Update: Apparently this is part of a larger movement on the part of Google. Their Google Gears browser plug-in is an open source application they’re releasing with the hope that developers will use it as a platform to build more offline applications. I wonder how easy it is to develop with. When will they have this incorporated into GMail?

Update:  Chris Wetherell of Google has posted something about the new features up on the Google Reader Blog.

Lee LeFever and Common Craft’s “Video: Wikis in Plain English”

After the massive success of the video “RSS in Plain English,” Lee LeFever and the company Common Craft have put out another video, “Wikis in Plain English.” If you’re not familiar with wikis, know someone who is not familiar with wikis, or just an avid wiki user, you’ll love this video.

I hope they will do many more videos.

Shawn L. Henry is speaking on “What’s new, WCAG 2.0, and current issues” on June 5th in London

If you haven’t already heard,  the W3C WAI‘s Outreach Coordinator and recent author of “Just Ask: Integrating Accessibility Throughout DesignShawn L. Henry is going to be in London on June 5th doing  a talk “What’s New, WCAG 2.0, and Current Issues” for a RNIB Web Access Center hosted event. She is going to be covering a wide variety of topics, everything from the latest on WCAG 2.0 to WAI-ARIA.  The event is FREE but you must RSVP.

I really wish I could be at the event but I can’t afford the trip across the pond.  I’m hoping that some of you will go and take a lot of notes and pictures.

This blog is blocked in China

According to the site Great Firewall of China, this blog is blocked in China. I didn’t realize information about Web 2.0 and a copy of my resume was a threat to the Chinese government.

Update: According to a recent commenter, my blog can be accessed in China. Maybe I’m only blocked in one part of China or the Great Firewall of China test just isn’t accurate.

My blog is blocked in China

Web Community Seems a Little More Positive on the Latest WCAG 2.0 Draft

I have been keep my eyes on the blogosphere for reaction and comments to the latest draft of the W3C’s WCAG 2.0.

It has been pretty quiet. Typically the blogosphere only gets in a frenzy when they have something to complain about.

There has also been a bit of positive feedback. Jack Pickard wrote the following…

It’s usable, it’s a vast improvement on the previous draft, and it’s an improvement on WCAG 1.0 as well.

Ok, it’s not perfect, not by a long chalk — it’s significantly lacking in relation to cognitive disability for example, and I’d like to see this improved before the final release — but it’s still pretty damn good nonetheless.

I agree with Jack. I think the latest version of WCAG 2.0 is a big step forward.

In an era of Web 2.0, having a set of Web accessibility guidelines that will be relevant and current with the times is CRUCIAL. Its our responsibility as the Web community to grab a tasty beverage, sit back with WCAG 2.0, and give it a read.

What are your thoughts? Do you think its an improvement? How could it be better?

Are you using a WCAG 2.0 Accessibility Supported Technology to make your Web site?

One thing that you won’t see in the latest draft of WCAG 2.0 is the concept of a baseline.  The community in unison pretty well dismissed the idea as not comprehensible.

It has been replaced with the idea of Accessibility Supported Web Technologies.  We all use different building blocks to put together our Web pages, whether it be HTML, DOM Scripting, AJAX, or Flash.   We need to use Web technologies which are going to support Web accessibility.  Assistive technologies (screen readers, screen magnifiers, braille reader, etc) have to be able to progrogrammitically assess the meaning on content which we’re trying to get across to the user.

So the next question you’d ask is how do you know if a Web Technology supports Accessibility?  The document gives some general guidance but nothing that a layman could easily assess.   I’d assume that all W3C Technologies support Web accessibility.

Shouldn’t the W3C create a list of accessibility supported Web technologies?  I’d think so.  Well they’ve passed that job off on us.  According to the Understanding WCAG 2.0 document, “Anyone can create a publicly documented list of “Web Technologies and their Accessibility Support.”

With so many new Web technologies being created all the time, maybe the W3C doesn’t want to be in the position of holding the official list of what is and what is not accessible.  Maybe the Web Standards Project (WaSP) and their Accessibility Taskforce would be a good keeper of this list.

I just don’t feel comfortable with developers (generally people not that familiar with assistive technologies) judging whether or not a Web technology supports accessibility.  I’d like to see some other organization with more expertise in that area step up.

WCAG 2.0 is Technology Independent

One of the first things that you’ll notice when you start reading WCAG 2.0 is that it is “technology independent.”  Well what does that mean?  The guidelines and success criteria are not tied to any particular Web technology.  They apply to all technologies (HTML, CSS, Images, Flash, JavaScript).

Within the main WCAG 1.0 document, there is practical advice for how to make your Web site accessible.  For example, Guideline 5 is “Create tables that transform gracefully.”  you’re not going to see practical advice like this at this level of WCAG 2.0.

To get the practical advice that deals with one technology or the other, you have to look one level deeper at the supporting material like Understanding WCAG 2.0 or Techniques and Failures for WCAG 2.0. The main WCAG 2.0 guidelines document acts more as the foundation for the other practical techniques that you’ll find.

I think having WCAG 2.0 be technology independent is pretty smart.  It seems like every couple of months some new Web technology is announced.  There is some new way for Web content to be authored and experienced.

It would have been hard if practical advice would have been woven into the main WCAG guidelines, like in WCAG 1.0.  It would have to be ever evolving and ever changing.  Within the main WCAG 2.0 document, the guidance is more abstract and high level so that it can apply to just about everything.

What do you think of WCAG 2.0 being technology independent?

“Call for Review: Updated WCAG 2.0 Working Draft”

Please check this out:

W3C WAI Director Judy Brewer’s “Call for Review: Updated WCAG 2.0 Working Draft“…

Dear All,

The Web Content Accessibility Guidelines Working Group (WCAG WG) invites you to comment on an updated draft of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0), published on 17 May 2007. WCAG 2.0 addresses accessibility of Web content for people with disabilities.

The updated WCAG 2.0 Public Working Draft incorporates changes in response to comments received on the 27 April 2006 WCAG 2.0 Last Call Working Draft. Because there were a number of substantive changes, WCAG 2.0 has returned to Public Working Draft status. We expect to advance WCAG 2.0 to a second Last Call Working Draft after this Public Working Draft.

W3C/WAI encourages you to review this document and submit comments on any issues which you feel could present a barrier to adoption and implementation of WCAG 2.0. The Working Group seeks feedback on the following points for this draft:

– Are the guidelines and success criteria clear? If not, can you
suggest clearer wording?
– Are there any success criteria that you feel are not
implementable or testable? If so, how could they be improved?
– Are there any success criteria that you feel would not improve
accessibility as written, or that might hinder it? If so, how could they
be improved?

Comments on this Working Draft are due by 29 June 2007. The Working Group requests that comments be made using the online or downloadable comment form available at
If this is not possible, comments can also be sent to . The archives for this list are publicly available. (Please note that if you submitted comments during the 2006 Last Call Working Draft review period, you will be receiving an email with a response to your individual comments.)

The following document provides an overview of all the WCAG 2.0 documents:
* Overview of Web Content Accessibility Guidelines (WCAG) 2.0 Documents

The primary document for review is:
* Web Content Accessibility Guidelines 2.0

A key tool for reviewing and working with WCAG 2.0 has also been updated:
* WCAG 2.0 Quick Reference

These supporting documents have been updated as well:
* Understanding WCAG 2.0
* Techniques for WCAG 2.0

A summary of changes to WCAG 2.0 since the previous draft will be available:

Information on how WAI is developing WCAG 2.0 is available:
* How WAI Develops Accessibility Guidelines through the W3C Process

Additional information about the WCAG Working Group is available:

Feel free to circulate this message to other lists; please avoid
cross-postings where possible.

Please let us know if you have any questions. Thank you in advance for your comments.

Loretta Guarino Reid, Co-chair of WCAG WG, and Computer Scientist, Google Inc.
Gregg Vanderheiden, Co-chair of WCAG WG, and Director of Trace R&D Center,
University of Wisconsin-Madison
Michael Cooper, W3C Team Contact for WCAG WG
Judy Brewer, Director, Web Accessibility Initiative, W3C

NOTE: I plan on doing a thorough review of this draft of WCAG 2.0 and publishing my thoughts on this blog.  Make sure you’ve read WCAG 2.0 also so we can start a conversation.

The Power of “View Source”

Just recently, I started working a tutoring program here in DC. I’m showing this really cool high school guy how to make a Web site.  On Thursday, we started by learning tags and attributes.  We’re learning standards-based design.

One thing I told him about and showed him was that most Web browsers allowed you to see the HTML which made up a Web site.  You just had to go, “view source.”

We started going through some of his favorite sites.  He was recognizing some of the tags we’d been talking about on some of these sites he loved to visit.  He also started asking questions, “What does that tag do?  What does that element do?”

I had forgotten about the power of “view source.”  When I was learning HTML, I’d use it all the time.   I just wanted to expose myself to the language as much as possible.  I’d study the patterns.  I’d get a feeling for how people were doing things differently.

The high school guy I’m tutoring may not fully understand all the HTML he’s seeing when he goes “view source” but it all helps with him getting used to look at it.

The “View Source” button is critical to the learning process.   It demonstrates the power of the open Web and how people need to be able to learn from what others are doing.

Facebooks Makes Web Accessibility A Secondary Priority

The Facebook Gift Shop is a page where you can purchase little profile widgets for $1 a piece and send them to your friends.   It has become apparently quite popular among Facebook users.

According to a recent Facebook blog post, they’ve recently received lots of user complaints that the Gift Shop isn’t accessible to blind users.  The Facebook team inturn decided to launch a screen reader accessible version of the site.

From the blog post, it seems that Facebook has the delusion that visual disabilities, particularly blindness, is the only thing they need to pay attention to.  We know this isn’t the case.  If you make you Web site accessible, users with different disabilities will be able to access the Web page.

Facebook’s first reaction to an inaccessible page isn’t to make the primarily used page accessible.  They make an alternative version of the page.  Who wants to have to use an alternative version of the page?  Didn’t we learn a long time ago that “separate but equal” is a fallacy?

Also… What does it say that Facebook users have to bring to their attention the fact that their page is inaccessible?  Is accessibility checking not part of the development qa process?

So is accessibility a priority of Facebook or not?

If it is, Facebook should post a Web Accessibility commitment statement so we know what to expect.