Mike Davidson has written a great article about the apparent false truths of accessibility through CSS and standards. It’s a great roundup and assessment of the recent discussions popping up about whether CSS is actually helping the disabled or not (seems to be negative, ghostrider on that one).
Anyway, here’s something Davidson proposed as a solution to all of this:
>I’ve talked about it a few times before but I feel like if your content is abstracted well enough from a database and templating perspective, you can serve up entirely different code to these groups of people and not rob them of any of the content. Your core navigation remains untouched as does anything else essential to use the site, but gone is the javascript, the Flash, the visual distractions designed to make you explore, and what you’re left with is a clear path to content.
Um … pure content, no flash, no javascript, no fuss. Wow, that sounds like an RSS feed to me. No need to re-invent the wheel and create a crazy server-side solution, we just need to educate! My guess is the disabled (along with most people and their moms) have no idea what an RSS feed is or how that would be huge for them.
Here’s some questions we should ask ourselves: Has there been an increased usage of RSS feeds by the disabled? Should we be focusing on an RSS education campaign for the disabled? How well do the OS screen readers work with feed readers?
How is RSS a solution when you will need to interact with the site. What if a disabled person is searching for a job on Monster.com and wants to apply. Granted he could get the job in RSS but he would need to visit the site to apply.
I love how the pefect solution is often the lowest hanging fruit. I agree entirely that RSS might be this solution, and that education is going to be the key to adoption.
As an alternative content system, its only starting to have an impact outside early adopters (aside: RSS early adopters have been early for like, 4-5 years …).
But as OSs build RSS deeper into their core, including their browsers, the alternative delivery method, and the abstraction from primary design will be sitting right there.
As a possible answer to Brian’s question above, I would suggest not thinking about RSS in terms of newsreaders, as we largely experience it today, but instead on the browser/OS level, where interaction with a site would take place much as it does with XHTML. The browser would just request the RSS page instead of the designed, scripted alternative.
At some stage you would need to display form fields and deal with accessbilty issues.
Think about an application like SalesForce.com, RSS in its current form cannot handle it.
RSS as means to replace washingpost.com, that is fine. A little XSL and an add-on to tell the browser not to read the HTML but instead auto discover the feed and you are set.
Thanks for linking to my article Kevin. In a sense, the solution you speak of (RSS) already is a server-side variation. All an RSS publishing module is doing is pulling certain content from your database, turning it into XML, and then spitting it out.
I’m proposing basically the same thing: abstract your content out well enough so that you can publish similarly bare pages for people with special needs or mobile devices.
The problem with “RSS” as a solution for this is that RSS is best used as a notification technology. I.E.: “There is new content you should see and here’s the gist of it”. It’s not really meant to be navigable at all, as a web site is.
I agree completely that RSS, as we think of it now, is a poor interface for people trying to get around and do stuff. They’ll probably never be able to really handle forms or complex web app-type stuff, but I can’t see why navigating / browsing a site is an impossibility for RSS.
Because you’re right, Mike, RSS for 99 percent of the people out there is a server-side solution based off of template-driven architectures. If that’s the case, making the content portion of any page RSSized should be easy as adding xml to your url.
And so why couldn’t we just manipulate those templates so that it adds a list of navigation points to each entry? Google is putting ads in there, why not links to other RSSized pages? If your non-web-based RSS reader is set as the default (and especially if it’s Tiger’s Safari), it should be a seamless experience to go from the about RSS page to the news RSS page to the RSS page that contains your current contact information or even the RSS page of other RSS feeds on your site.
Obviously, that MIGHT be getting a little crazy, but never say never. My big wonder, though, is what makes an RSS page better than a standard’s based site with CSS turned off? Maybe the solution might be reversing the flow of humane text filters like Markdown and Textile so they turn HTML into human-readable documents that screen readers would love to chomp down on. To see some of that in action check here:
http://www.aaronsw.com/2002/html2text/
I guess the difference for me comes down to permanence. An RSS feed is just a slice in time of what content happens to be on any particular site. There is no permanence to it. A URL, however, is a permanent thing (at least in theory).
To answer your question of what makes an RSS entry better than a standards based site with CSS turned off: The RSS entry has all the crap removed from it on the server-side while the standards-based page serves up the crap but attempts to hide it client-side with CSS (or by absence of CSS/JS).
Part of the reason I wrote that entry was to help dispel the notion that using purely CSS, you can manipulate content dramatically enough to where it’s ideal for disabled people and/or ideal for mobile devices. We now know that many screenreaders don’t really read code per se… but rather read what they see on the screen. And mobile devices don’t deal with CSS very well yet either.
So my solution basically says, why try and hide crap with CSS when you can just not serve the crap to begin with (much like what RSS does).