Does Accessibility Belong on the Server-Side?
If you think you knew how to design or code a site with disabled people in mind, head on over to this National Institute of Standards and Technology accessibility study (via: Henrik Olsen) and find out exactly how much you don’t know.
Somewhere in Toronto, even Joe Clark is taking notes.
In a nutshell, Redish & Associates observed 22 screenreader users interact with a variety of web sites. Most were government sites, but Google was also included to represent search behavior. The results showed that most sites, whether or not they complied with the syntax of accessibility, were difficult to use based on the presentation of the content.
The study covers lots of ground, all the way from “skip navigation” links to recommendations against creating branded words like “LiveHelp” (apparently, screenreaders read that as “livahelp”).
One particularly humbling thing about the study is that it shows exactly how little effort goes into testing for usable accessibility. I’m guilty of it myself and so is 99% of the world. In fact, unless you are physically bringing in a person with a disability to test your site out, you really have no idea what sort of experience you’re offering. Installing screenreader software yourself isn’t really good enough because you’re not even close to a typical screenreader user. Even going so far as to put on a blindfold isn’t good enough because again, it’s just not your element; you’re going to be comparing everything to the visual world. Unless you’re willing to go a few months in a screenreader user’s shoes, your value as a tester is limited.
The other really interesting takeaway from the study is that visually-impaired users reportedly don’t want a “text-only” version of the site to use… a sentiment I’ve heard before. Here are two quotes from the participants explaining their reasoning:
“I never trust screenreader versions because the text version is never updated.”
“It’s double the work to do text and graphic versions. It’s better to make the graphic version accessible.”
With all due respect to the participants, I don’t buy either argument. The first reason cited is an execution problem and not a conceptual problem. If you are making a text-only version of your site for accessibility reasons and you’re not updating that content as often as the main version, you can’t even really call it a text-only version of the site anymore. It’s a partial shadow of your site, but it’s not a text-only facsimile of it. THAT, is what screenreader users resent… the lack of equal content. If we lived in a world where every site had a perfect text-only equivalent, which version do you think screenreader users would find more usable?
The second reason cited (the “double-work” rationale) is also an execution issue to me. At ESPN.com, we run our wireless site pocket.espn.go.com using the exact same data sources as our main site. With smart templating on the server-side, content can be served to our main site or our wireless site simultaneously with no extra effort. Since Pocket PCs and other handhelds have such limited support for XHTML/CSS/JS and all the other stuff we throw into graphical web browsers, it’s better to just not serve that stuff up in the first place. If you serve up a simple XHTML page instead with no extraneous elements, it takes a lot less CSS trickery (and a lot less bandwidth) to get where you need to be (more discussion on this subject is available in the comments of “Targeting Small Screens” over at Stopdesign). So I guess my argument is that it is very possible to have a simpler version of your site which doesn’t require double the work if you employ smart server-side templating.
And that brings me to the final thought of this entry: Does the advent of mobile web browsing help us in the quest to provide more usable sites for disabled people? I think that it does. In a pretty significant way. As our sites are viewed by more mobile users, the “mobile” version of the site (which is pretty acceptable to have) becomes more and more important to us, and thus we begin to put even more time into it. We also can’t help but thoroughly test it because we become handheld users ourselves. At the point where we have parity, won’t the mobile version provide a better experience to screenreader users than the version filled with Flash, sponsorships, and extra code for traditional web browsers? I think that it will. Designing for handhelds forces you to think like a screenreader user, and that’s a good thing.
Now, I realize that the whole “separate version” issue is controversial and before anyone jumps on my case, I do think that extremely simple sites can get away with one version. It’s just that for more complicated sites, I feel like it’s a lot less work to “prep” for accessibility on the server side. If you do things correctly, all you’re doing is hiding and rearranging content server-side that you would have done client-side with CSS. How is this a bad thing?
Thoughts?
(By the way, I fully expect to get beaten down on this by some camps. I am not an expert and I’m just throwing this out there because it makes sense to me.)
You’re absolutely right that the debate on this can get quite heated — I’ve written about my perspective on the issue having helped code a UK local government site that currently offers an “Easy Access” version delivered through our CMS.
The point of course, you separate ‘mobile’ browsers from ‘desktop’ browsers server side, something that is very hard to do, now, for ‘devices for less abled people’. How dou you gonna know if the user is viewing your site with Jaws through Internet Exploder, or using some alternate pointing device instead of a rodent (and keyboard) ?
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 :-)
I understand your thoughts, about not buying the participants arguments.
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.
good to see they’ve finally got an HTML version up. when i first stumbled across it they only had the >a href=”http://www.accessify.com/2004/11/guidelines-for-accessible-and-usable.asp “>article as PDF (which always makes me scratch my head…accessibility reports and such are usually disseminated in inaccessible formats…go figure)
Interesting article. As with the commenter above, I’m interested in how you see sites differentiating between users who are using technology that is unidentified to the web server.
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
Check out Eric Meyers recent post about deficencies in Closed Captioning and some of the comments that follow. It becomes evident that those with special accessabily needs just don’t trust that they’re getting the same quality content as everyone else. Unfortunetly, that lack of trust is justified based upon past bad experiences.
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.
I personally have no qualms with serving up multiple versions of the same site on the server side — as long as the content is kept fresh on all versions. If it works for you, and you don’t consider it to be an extra burden, then go for it.
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.
I just recently left the New York City Department of Ed. as a consulting Web Designer and one of the problems I had to tackle was that we needed a text version of the whole site. Luckily I was able to convince the management to drop the old table based layout and convert to CSS/XHTML, which put us in a good position to make a text-only version of the site using the same data, but use a different style sheet for formatting. Because of this there was no reason to keep multiple versions.
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.
No one should ever claim to know it all about accessibility. I was impressed a while back with DWWS when the big man himself said something to like of “You won’t learn it all in this chapter, because if you did, it would be a slap in the face to those whom it applies.”
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.
Mike, I think you’re looking at it from a different perspective from most Web designers. Pretty much everything you’re doing at ESPN is a Web application, from what I’ve seen. And that’s an area where most accessibility folks should admit they don’t know enough. But lots of sites that are really still brochureware (like, for instance, most government sites) have no excuse for not making their sites accessible straight-up.
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. :)
Phillipe: Thanks, I’ll try and add the custom font prefs to the textarea as well. Good idea.
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.
What do you mean I’m taking notes? I wrote a whole frigging article for Zeldman inspired by Redish’s study.
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.
Sorry about that Joe. I was actually pretty sure you had already read that study but “Somewhere in Toronto, even Joe Clark is taking notes” sounded better than putting it in the past tense. Just a writer’s liberty I took. A statement that you previously took notes upon your first reading of this study would have been more accurate.
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.
The whole idea of equal “Full” and “lite” versions of a site are excellent plans for any website, doesn’t matter what it is. Since most content ends up being server side to begin with, simulating content on two seperate site versions is no difficult task at all. I myself am guilty of not providing similar content across two versions of a site, and sometimes not even providing a “lite” site to begin with. Most of my sites are sadly not necessarily “high traffic,” thus my stats usually indicate almost uniformity amoung user browsers and I generally know who is visiting my site, so I’m prepare accordingly. I should be planning ahead, and after reading this, I probably will be more inclined to compensate for disabled users in the future.
Two years ago, I examined nearly 400 web sites for WCAG compliance. The majority of the text-only versions that I encountered did not have the same content and/or functionality as the regular version of the site. So I totally agree with the two quotes:
“I never trust screenreader versions because the text version is never updated.”
“It’s double the work to do text and graphic versions. It’s better to make the graphic version accessible.”
To answer your question in the heading: no, accessibility doesn’t necessarily belong on the server side. There is no easy fix for accessibility; taking it to the server side certainly isn’t the ultimate solution. In my experience, it is often poorly implemented and even more so used as an excuse for not caring about accessibility any further. “We don’t have to, because our site has an accessible text only version.” But it often turns out to be a second-class site, aimed at people that don’t desevre to be treated as second-class citizens.
What in my opinion should be done, is that the way web sites are produced is critically evaluated. The current ‘best practice’ is based on the shortcomings of browers that are no longer used (IE4 and NN4). In the past years a comprehensive and complex set of workarounds was developed in order to maintain the ‘look and feel’ across browsers, browser versions and platforms. The result: lack of accessibility, since most websites are disigned for one single purpose: display on a high resolutions screen, using the most popular browser on the most popular platform.
The current ‘best practice’ has proved useful, but the browsers they were developed for are no longer in use. Hence most workarounds are no longer needed, since the current generation of browers has decent web standards support (more or less…). So this is the perfect time to go back to the basics: thinks like simplicity, better standards compliance, separating style and content and semantic markup are the cornerstones of a next generation of web sites, where accessibility and sustainability are the logical results of a process of website making. The base is a ‘plain and simple’ version that is fully accessible and functional, and to which style (through CSS) and logic (through DOM) can be added and used when a browser supports it.
A couple of months ago, the Dutch government has introduced the ‘Webrichtlijnen‘ (web guidelines) for government websites. The core of the ‘Webrichtlijnen’ are the Web Content Accessibility Guidelines. The main principle that a government organisation cannot afford to exclude citizens from access to online information and online services, that are caused by (technical) choices that were made while developing the web interface. So it’s not only for people with a disability, but everyone that does noet (or can not) use a high resolutions screen, the most popular browser and the most popular platform.
Unfortunately, the ‘Webrichtlijnen’ is all in Dutch. But the site may help to get an idea.
(PS: Babelfish may be useful, but the translation is far from perfect).
Two years ago, I examined nearly 400 web sites for WCAG compliance.
Has so little changed in server- and client-side technology and deployment over the last two years that your findings are still 100% accurate?
Could it be that there are processes or technologies that can be implemented today that could not or were not implemented two years ago?
Not asking because I have an answer in mind, just looking for more information.
Raph: Thanks very much for the informative post. Lots of great information in there. For clarity though, I should point out that when I said “I don’t buy either excuse”, I didn’t mean that the excuses are not valid. I meant that the excuses are the result of poor implementation and not necessarily poor ideas. If BMW designs a great car in Germany but then cuts all sorts of corners in production, you wouldn’t blame the design… you’d blame the implementation. That’s all I’m saying. Providing a “lite site” is fine, as long as it truly is the same site, only styled differently. Most people attempt to do this with CSS… all I’m saying is that it may make sense fixing the problem a little before the pages even get to the browser. Hence, server-side content negotiation.
I think Tony also has a good point in that we seem to have made a lot of progress in the industry over the last two years, so the findings of the WCAG study may be slightly better today.
An answer to Tony’s question: Mike already pointed it out, part of it is poor implementation. And if it’s also poorly organised, you have the perfect recipe for aceessibility trouble. As for accessibility compliance: it was tested last November and we’ve seen a slight improvement overall. But the quality of the text only versions remains a problem.
The technology isn’t the problem; it’s what people do with it. That’s why the ‘Webrichtlijnen’ promote the development of a ‘light’ version that is beefed up automatically when a browser supports technologies and features that go beyond HTML. A new channel is only needed when you want to publish something else than HTML, or when ‘light’ applies to the content, instead of the markup.
When it comes to accessibility, the industry has made some progress, but not a lot: the majority of the web designs is still based on ‘old thinking’. Technology isn’t the major bottleneck; it’s the ‘single-purpose thinking’, instead of ‘multi-purpose thinking’.
I don’t think anyone’s mentioned the middle ground yet… I don’t see accessibility as being all about the extremes, although that’s obviously a major part of it. While a text-only version may be beneficial to people who have very different requirements to the average web user, I think it’s important to remember the huge number of people who, for example, wear glasses and like their text sized 14px or above. That’s a client-side accessibility problem… I know Mike’s not suggesting that all accessibility issues could be solved server side but I thought it would still be worth mentioning!
So, to me it is obviously a very different thing to serve up a different presentation and / or behaviour layer based upon users, rather than serving up a “text only version” site.
In fact many people are doing it already… has anyone out there ever added a purely presentational image and just left an empty alt tag (element, pfft!), well isn’t that just a crazy lojack version of the same thing?
But this does leave me with the question of just what would a different version be like? Who would it be best for? I’ve seen several demonstrations and tests of blind and low vision users and have seen almost as many variations in the ways that sites are used as users.
Which in turn leads me back to the subject of site specific styling, and now behaviours. It just makes sense that if all Mike is suggesting here is to change the presentation then just let the users do it. Then all we would need to do is make it easy for them to do just that.
I have to agree with Raph, although I’m admittedly partial as I’ve worked with Raph on the Dutch web guidelines. That aside, I’m glad you clarified your point, Mike; for a moment I thought you didn’t buy the experiences of the testers, but if I understand you correctly, you’re saying, “I don’t believe this must remain a problem.” Because it is a problem. There are plenty of websites with several actual separate versions, meaning that there can be significant differences in content, with the so-called “accessible” or “text-only” often being at least partially neglected.
I also agree with you, Mike: if you haven’t brought in actual disabled people to test, then you haven’t tested. Anyone wanting more insight into real-world accessibility outside of the literal implementation of the WCAG would do well to read Joe Clark’s fantastic book (if you have read it, read it again). If you can read Dutch, the Webrichtlijnen voor de Overheid is a good practical read as well.
Plenty of us advocate structuring information accessibly (and usably) in a basic open format (XML, XHTML), and that’s it. Then style that content for your chosen devices and visitors with stylesheets. Use that version only. Why not fully exploit the advantages of content/visual design separation.
Notice I said the separation of content from visual design. Because the un-designed information must still be designed. And it should be designed first. Simply meeting guidelines just doesn’t cut it. The accessible information must be usefully presented to me. If I walk into a library and all the books are in a huge pile, they’re still accessible, aren’t they?
I dont know about you, but I’m not using that library.
Unfortunately screen readers do not insert themselves into the browsers user-agent so much of this discussion is merely academic for me.
If you could detect screen readers it would be trivial for a server-side script to serve the user a different page, from the same URL. I think without that potential, You are asking blind users to jump through extra hoops to get at your content, And that’s just not good, The first visit to a site is often the most important, I would like that to be a smooth visit.
As for older people who want to adjust the size of the font etc, That is not very hard to accommodate in the “full” version, It’s not something that would compromise the page layout, so it’s not a problem.
The whole argument on whether dual-versions treats blind people like second class citizens or not is ridiculous in my opinion. I want to give my users the best possible experience whether they are blind or not. They are visiting the same *site* if my server sends them a file with less presentational markup should not be such an emotive subject. And I think that’s what a lot of it is about, A *site* centric approach, over a *page* centric.
I think the “One page to rule them all” (OTRTA) approach is not going to serve disabled people especially well at the end of the day, It’s not just a case of using pure CSS and having valid XHTML markup. An accessible page has to be designed semantically and in a very specific way.
I believe a fully able person is invariably going to spend a lot of time on presentational markup and design, Especially if they think in the back of their mind they can’t be criticized because they are using zealot friendly CSS/XHTML and therefore have accessibility ‘sewn up’.
Rather than trying to be all things to all people, For a person who cannot appreciate what it’s like to use screen readers and actually be blind, I think it is much easier for them to design an accessible site when they build it from the ground up for that purpose in a very simple fashion, Or use a CMS that serves the same content to the lite version.
The web is a place for amateurs to put up their own pages and have fun sharing their creations, As much as it is a place for the geeks and hard core design professionals who have people checking their work against standards. I know which method in reality is simpler for those people and what should be encouraged. However, It’s not going to get much support from certain crowds because it implies an alternative to trendy metrologies, therefore I think there wont ever be a standard that says screen readers have to identify in the UA. You can’t really do this properly without that.
Bookmark: Guidelines for Accessible and Usable Web Sites
Great insight from actual accessibility testing: Guidelines for Accessible and Usable Web Sites (via Mike Davidson)…
Accessibility from everybody
Mike Davidson asks Does Accessibility Belong on the Server-Side? But I say the best thing we could do for accessibility…
Accessibility from everybody
Mike Davidson asks Does Accessibility Belong on the Server-Side? But I say the best thing we could do for accessibility…
Tachipirina cialis erettile disfunzione 20 10 a mg vardenafil anni effetti rx farmacia italia alla consegna http://rxfarmaciaitalia.com