One positive aspect of the development of ‘mobile’ browsers, small screens, etc, is that the designer/developers will eventually be forced to think about the whole thing. Maybe. ‘Mobile’ browsers are sexy, while testing for accessibility isn’t.

BTW, your readability widget should affect this textarea as well. Can’t barely read the text… (having set the font to Lucida Grande, 14px for the body :-)

That’s the problem though. You HAVE to listen/trust the users. They’re the user(s). If they don’t trust the text-only, that’s the problem. It becomes more than a technical issue on your end. You (us) have to rebuild that trust to the user.

Would this be perhaps providing a link at the top that says “text-only version” and redirecting that to the text site (which can then be bookmarked for future referece by screenreader users)?

How do you get them to click that link to start with, given the history of text-only versions of sites being pretty bad on content?

What about low-vision users?

Thanks,
Tony

As web developers (or whatever we call ourselves), we know that we can serve the same, accessable HTML and dress it up with various style sheets. We know that everone is getting the exact same content from the exact same file. It’s just being displayed differently based upon the users needs. However, they do not know this. All they know is that it looks different. If it looks different, it must be different. Given the fact that they are already lacking trust in so-called special version made just for them, they have no reason to trust that an unstyled text version of a site contains content identical to the styled version.

Sure, we could explain that it is, in fact, not really a different version of the site, but actually the same file, just displayed differently; but we shouldn’t have to explain whats going on in the background, and they probably don’t want to have it explained. It all comes down to building that trust. How do we do that? That’s another matter for another time.

That having been said (and this is similar to what other commenters have brought up), the one downside I see is that you’ll never be able to provide perfect support for all devices this way (or maybe, any way). For example, a text-only version of the site may work great on many mobile devices, but leaving out the images means that people who have, say, a a high-end phone or other nice, aren’t making full use of the device they have (which is more than capable of displaying images). Similarly, if you choose not to serve XHTML and CSS to mobile devices, you’re ignoring the fact that there are PDAs and similar devices out there that have some CSS support. Finally, you’re ignoring the possibility that the useris using a device you haven’t accounted for, which means they’re going to get some pre-chosen version of the site which may or may not be appropriate for them at all.

Now, I realize this is probably the case with nearly any method you’d choose at this point. Therefore, I think server-side versioning is as good a method as any — but it’s not perfect.

The website will never fully validate (due to their CMS system) but it it much more accessible then any site they had before and probably any other State run site. Its not perfect, but its a simple solution with little maintenance. So I definitely agree with you Mike, its the execution.

You can’t bundle up accessibility in one article, so you make a good point Mike. It doesn’t surprise me when I hear someone like Joe Clark out there taking notes. It’s not because he doesn’t know something…well…actually it is. He knows he doesn’t know something, so he learns more. He wouldn’t be an expert today if he didn’t continue to stay involved.

As far as the separate version, I try my best to make it accessible for normal folk who use graphical browsers etc etc… If I didn’t do that then I’d really be screwed. The templating system needs to work across all platforms though like you said. I do, however, offer separate style sheets so that folks can set a prefered style over another. One is more text based, the other uses more graphical elements. A few other style switchers just modify the text.

All in all, I don’t think you deserve to be beat on by the camps. Anyone who yells at someone who says “I just don’t know” is one of those wanna be know-it-alls.

One important thing to remember is that there’s a term for singling out individuals based on collective traits and putting them all in some place together. It’s called a ghetto. It’s bad business to ghettoize users unless you’re damn sure you have a good reason to. Most text-only sites have different URLs for the same content. So, if I’m blind, and my friend isn’t, or vice-versa, we’re sharing completely different (and often incompatible) views of the Web if we’re emailing or blogging our experiences. This is less relevant in Web apps, since they often abstract the user from URLs, but for most of the Web, that’s important stuff. If you’re going to be serving up different content, better to serve it from the same URL.

Then there’s the issue of discovery. Who knows what sites have accessible versions and what ones don’t? A good chunk of users with disabilities doesn’t know that, say, Amazon’s “accessible” version is over at http://amazon.com/access . It’s like finding a secret passageway a lot of the time.

Lastly, accessibility is not all about blind and low-vision users, and creating a secondary site is not a license to ignore any accessibility guidelines on the main site. There’s a whole range of disability, including changes that come with age, and perhaps most people who use large fonts or keyboard navigation don’t think they’re “disabled,” and so won’t bother even looking for a secondary site.

Okay. This is already too long. I have a whole blog of my own for this kind of ranting. :)

Tony: Differentiation can be done in several ways. Firstly, you should always offer a choice (‘Full’ or ‘Lite’). Secondly, you can indeed sniff for user agents, although I’m not sure if screenreaders insert themselves into the UA string (they definitely should though). Thirdly, for sites where a user may have an “account”, you can store their pref in a profile. And fourth, when it comes to mobile devices, you can detect screen resolution.

Waylan: I think you’re right that you can never insure that all users see the absolute optimal stuff for their setup, but that’s the case even when you throw accessibility totally out of the equation. If a mobile device supports a lot more than simple HTML and CSS, that doesn’t mean you have to serve it a lot more. Usually, a simple version does the job better. With mobile devices, context and physical interface are very important, and generally both of these factors require that you dramatically simplify things anyway… regardless of what the device can technically “handle”.

Matt: Your point about ESPN being an extremely complicated example is right on and I definitely agree that much simpler sites can probably get by with one version, but I can’t agree about the ghetto thing unless you, as a developer make it a ghetto. It might surprise you to know that a good deal of our fully abled users at ESPN actually prefer the lite site. Picture it this way: Let’s say you are at your house and you want to go to a beach that is a couple of miles away if you walk in a straight line. There is, however, also a nice scenic route which is ten miles long if you happen to be driving a car. Which route you prefer depends on what your choice of transportation is. People whose only option is to walk will always pick the quicker, simpler route. Both routes will lead to the same destination (the beach, or the “content”) but one is intentionally simpler and filled with less distractions.

I’m all in favour of server-side variations, BTW, or at least automated ones, which was the thrust of the zoom-layouts article aforementioned.

Note that I demonstrated that the activities of handheld designers and zoom-layout designers are similar and overlap significantly, but are not the same. Prior art, Mike.

And by the way, it’s only prior art to me if I’ve read it. I’ve been comparing the handheld experience to the low-vision experience internally for about three years now. Doesn’t mean I don’t think others haven’t already done the same.