views:

62

answers:

3

I've spend a fair amount of time on website optimization (YSlow, Google's Page Speed, etc), and now I'm thinking more and more about improving the accessibility of my websites.

However, it seems like that they are competing interests at times. If I include separate style sheets for screen readers, mobile devices, etc, those are additional files to download. Similarly, there are many files that would be unnecessary for visitors using screen readers, mobile devices, etc.

So where does that leave us? Server-side browser sniffing? I imagine that would only help in a limited set of cases. Are there teams out there (e.g. at Google or Yahoo) that are actively working on these issues or have come out with some recommended practices?

A: 

Well, I wouldn't worry too much about the stylesheets for the different platforms, since they're pretty much downloaded once and then cached. I would strongly recommend designing for accessibility first and optimizing the downloads second.

Dave Markle
I don't know. Maybe my bias is towards optimization even on that first visit, and if I can have both, I want both. Just a thought ... "Latency matters. Amazon found every 100ms of latency cost them 1% in sales. Google found an extra .5 seconds in search page generation time dropped traffic by 20%. A broker could lose $4 million in revenues per millisecond if their electronic trading platform is 5 milliseconds behind the competition." http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it
Keith Bentrup
Are you doing anything on that kind of scale? Does it matter if the site loads quickly if its not accessible?
micmcg
@micmcg, I don't think that you have to be of that scale to experience those relative effects. Also as I said, I want to have both. To "strongly recommend" one over the other without any data supporting their relative worth isn't that helpful. That's not to say that Dave isn't right to prioritize. He may be. It's just that I haven't seen any similar studies showing how certain accessibility features affect similar metrics. If you know of such resources, I would be very interested to read them. Thanks
Keith Bentrup
+3  A: 

One interesting approach that I read about for this optimizing the request size but maintaining accessibility is to store the accessibility class (screen reader, mobile device, etc.) in the session. In the case that the accessibility class is not stored in the session (for instance, first page load - session start), send all style sheets (etc), and detect the accessibility class using Javascript. Send this back and store it in the session for the future. Where the session does store the accessibility class, simply transmit only the appropriate style sheet (etc).

JoshJordan
+1 Interesting. Any JS frameworks using this already or sample code that you've come across?
Keith Bentrup
Nope, never done it myself. Just wanted to pas the idea along :)
JoshJordan
+1  A: 

Sniffing of user agent (browser or otherwise) is hardly a strange technique these days, and frameworks such as jQuery or dojo do it on your behalf anyway, so, why not take advantage of it? Just make sure you let your user override things by some explicit but simple action (for those times in which the sniffing heuristics get it wrong).

Alex Martelli
But that client side sniffing is already after the first page visit at which point they would have already downloaded a default page (and it's resources) rather than one that might otherwise be optimized for them - although certainly a combination of server-side and client-side sniffing would be appropriate for optimized, subsequent page views
Keith Bentrup
Right: you can do some sniffing from the headers in the very first request (server-side), and push just enough JS to do the rest.
Alex Martelli