Mobile version (Display Regular Site)

Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

Made for All of Us

July 05, 2005

Accessible design, unobtrusive scripting, and terrible cell phone browsers.

From all accounts, the recent @Media conference in London was a smash hit. One take-away that has appeared everywhere is a renewed interest in accessibility issues. Given the creation of the WaSP ATF and resulting discussion, the eye being kept on the under-development WCAG2, the interest in zoom layouts, and even the questioning of what we know, there’s a lot going on right now.

At the moment, accessibility practices attempt to assist those with disabilities. This is a reasonable starting point. A founding goal of the web, after all, is to allow access to anyone, anywhere, at any time, on any device. It’s going to take a lot of work to get there, but if you’re looking for the ultimate definition of accessibility, that’s it. Over the long term, the concept of accessibility must become this broader definition.

During the recent North American long weekend, I spent time out of town, sans computer. Accessing any web site on the cell phone I’m cursed with is an exercise in frustration, however I had time one afternoon to make a determined attempt to use various sites. Those built with standards worked. Those built with accessibility in mind worked well. Those built by developers stuck in 1997-era development habits were completely useless.

One site in particular stood out. This popular web application is relatively standards-friendly, although built with AJAX in mind. I could log in. I could view my data. But the nag message informing me I really should enable Javascript hinted at what I quickly discovered: without script enabled, I couldn’t manipulate my data in any meaningful way. The developers had obviously tied the core functionality to the scripting, without providing a graceful degradation that would allow simple HTML form elements to get the job done.

As a normal user on a desktop browser, I observe no problems with this application. As a remote user without access to the same level of technology I’m accustomed to, I can’t even use it. Solving this problem would mean employing methods to make the site work without CSS, without script, and essentially allow unstyled and unscripted HTML to accomplish the same task. Funny enough, doing so would likely boost the overall accessibility of the site as well, allowing users with assistive devices to accomplish the same goals in a similar fashion.

Of course, this isn’t an easy thing to accomplish. Retrofitting an existing application is tough, and building the same thing twice isn’t cost-effective. Those advocating unobtrusive javascript will likely suggest that you should ideally build your application without script at first, and enhance with script afterward. Unfortunately this will collide head-on with most development schedules and methodologies. A middle ground is needed, some process of maintaining graceful degradation throughout the development of a project.

So for me, the obvious take-away in all of this is that, by building sites and applications in an accessible manner, the payoff will extend beyond the immediately obvious. The question remaining is, how do we go about doing so? Though there are lingering doubts about the effects of CSS on assistive technologies, a properly-built site will degrade gracefully when CSS isn’t rendered; there is clean-up work yet to do to solidify the particulars, but we have figured out that the separation of structure and presentation goes a long way to accomplishing this goal.

But what about scripting? The myth persists that Javascript is inaccessible, but it doesn’t have to be. There is yet plenty of work to be done toward figuring out just how accessible it can be made, but I’m willing to wager that the separation of structure and behaviour will ultimately prove a healthy start. I’ve yet to read the books on this topic by Stuart Langridge (published 2005) and Jeremy Keith (coming soon), but I’ll bet answers to my remaining questions start in there.

Mike D. says:
July 05, 01h

Glen C.: Thanks for the pointer to IYHY. I’m adding it to Stylegala right now. Great work B. Adam! It’s all about the server-side action…

I just compared a few sites of noted standards-conscious designers and without server-side preprocessing, they were all virtually unreadable on my Treo (hence my documented skepticism about using pure CSS to sculpt mobile devices), and after preprocessing on IYHY, they look fantastic.

July 05, 01h

Great article! One thing that we all must consider is to _just_say_no_ to this proliferation of UA-sensing apps, that send different markup depending on what browser you have to account for capabilities.

July 05, 01h

B. Adam - Foshizzle. 100% agree, but if we do our due dilligence, we can be prepared for when they catch up. Not taking the time now to develop for the future because “no one supports it” or “I want this functionality so I won’t support them” and placing the blame elsewhere (not saying you do, but some do) isn’t quite the answer. Graceful degradation and forward compatibility is.

Kerorin says:
July 05, 02h

If that application you wrote about is the one I suspect, I guess you should point out that _that_ service is still in beta. ;)

Mike D. says:
July 05, 02h

Dmitri: I don’t know about that. The evil side of UA-sensing is when people write major portions of their apps/sites with proprietary non-compliant code and serve up braindead garbage to UAs that can’t or won’t support that stuff… but the *good* side of UA-sensing is exactly the sort of thing B. Adam has put together: sending simplified code to devices at a clear rendering disadvantage from “the norm”.

There is nothing wrong with UA-sensing as long as you’re not using it as an excuse to write exclusionary code.

July 05, 05h

Mike, can I both agree and disagree with you at the same time? :)

I just fed one of sites I designed through IYHY, and guess what? The exact same markup came back, save for the lone IMG tag and an input element, which IYHY chose to strip (why, by the way?).

I am convinced that even with today’s UA limitations, there’s no need to do UI sensing on the server side.

It’s not kosher from the semantics standpoint, it’s not kosher from the REST architecture standpoint, and it gives devs to a false sense of comfort that leads them to developing the garbage you were talking about.

July 05, 05h

Ok, “I am convinced” sounds a tad too strong. How about “I believe”? Better yet, “I would really love to believe”? :)

Mike D. says:
July 05, 07h

Dimitri: While the site you coded is very well done (I’m not publishing the URL here because as you mentioned in your e-mail to me, it’s not public yet), it’s just over 40k when downloaded raw to my Treo and is tough to use because of all the horizontal scrolling.

When run through IYHY, however, it’s only 7k and looks perfectly formatted for a wireless device.

My point here being: You are a very good coder. You did everything you were supposed to do with regards to separating style from content. And yet, because of the inadequacies of the mobile world, your site still doesn’t work optimally on wireless devices without some server-side preprocessing.

July 05, 09h

JavaScript is not inaccessible in itself, but relying on client-side scripting can make a site inaccessible to certain groups of users.

With a web application, it may sometimes be difficult to get by without js, but with regular (static) pages you shouldn’t have to have js to be able to navigate the site.

( seems to show my site as-is minus the CSS, but it also changes the encoding declaration which makes the Swedish version quite hard to use.)

Glen C. says:
July 05, 12h

Funny you should mention this because Benjamin Adam Howell just found out the solution for his mobile problems ( I know it’s a bit of a tangent, but it’s still relevant.

Dave S. says:
July 05, 12h seems to be exactly what I was thinking of creating for myself after this weekend, before I decided the effort probably wasn’t worth the use I’d get out of it. Good find, I’ll have to bookmark it on my mobile browser!

July 05, 12h

Very interesting thoughts, indeed. I’ve recently had some trouble convincing others (and myself) at times of the benefits of accessibility in web application development. It always comes down to a combination of audience, budget and client needs.

However, I’m right there with you on the benefits of doing something right up front, so Making It Work won’t be so hard down the road.

A very popular web app developed with AJAX in mind (probably the same you referenced) shortly after release, publicized a mobile version. My thoughts were “Why not develop with accessibiliity and standards in mind so alternate versions and rework aren’t necessary?”

A number of the recent projects I’ve completed have been 95% done by the time the client said “Oh, and we want it to work on a Blackberry” to which I was able to say “it already does.”

B. Adam says:
July 05, 12h

Thanks for the plug, Glen. But I don’t write tangents, I write “thought provoking pieces” ;)

The great thing about IYHY is that it makes all our sites (meaning CSS and web standards-oriented designers/developers) look great when compared to Amazon, Ebay and all the other table-based monstrosities.

A CEO may never view source and his eyes might glaze right over when you utter the word “semantics” in a meeting – but maybe showing him what a site like Mezzoblue looks like in IYHY when compared to Amazon will get his attention. Maybe.

Lance: Us developing sites for mobile browsers won’t ever be the problem – it’s everybody else’s refusal to spend the extra time and money to make mobile browsing better that’s the problem. That’s the main reason I made IYHY.

July 06, 02h

Progressive enhancement is probably the best strategy when building standards based websites. The main reason why is that it is designed to serve the biggest common denominator first. You can enhance your web pages with CSS or JavaScript for those who support it, but for those who don’t, it it just plain vanilla (X)HTML, offering a basic interface that consists of text, images, links and forms.

When it comes to DOM scripting, unobtrusive techniques and feature detection are techniques that fit well within the philosophy of progressive enhancement.

Progressive enhancement is probably a better strategy than graceful degradation, because with the latter you often only figure out afterwards how to make your page accessible and often only for certain support scenarios. Besides that, it doesn’t really offer a common solution on how to make pages accessible, this will often be dependent on the context.

Does it fit into development budgets? Why not? With progressive enhancement the main implication is that you have a generic starting point and that you design for multiple scenarios. However this doesn’t automatically mean this would double the cost. If you want to have a styled page, you would have to develop a style sheet anyway, if you want your site to behave a certain way, you would need to develop a DOM script. Developing and testing for accessibility would probably only cost a little bit extra.

If it comes to complex AJAX based applications using a one page interface, the implications could be bigger. If you would have to start with multiple page forms and enhance this into a one page dynamic interface, this could mean you would have to develop two different applications. Is it ok not to offer a complex application for those who don’t support JavaScript? It probably is.

IYHY is the best solution I have seen since Opera’s small screen rendering, and I bet I am going to use it a lot. It nicely solves display issues in this huge percentage of cases when a handheld’s web browser doesn’t support standards well enough and/or if designers have not designed their pages with mobile browsers in mind. On the other hand it currently doesn’t discriminate between this negative scenario and all positive cases where pages are designed for handhelds and run in browsers that do support standards well.

July 06, 04h

Mike: You and your realities ruin everything! :) Of course you’re right. I see exactly what you mean.

July 06, 07h

Hi, I’m not clear on one of the early parts yet… why is it that you’d like to rename device-independence as “accessibility”? That’s the part I don’t really understand yet, thanks.

Martijn says:
July 06, 11h

I have a Sony Ericsson K500i telephone with a (X)HTML compatible browser.

The real problem is screenwidth on that thing: it accepts the CSS width attribute and everything is unreadable at once.

I don’t think I ever will read full length websites on it, but it is nice to take a quick look the train services webpage to see if I can expect trouble on my way home or not (which happens a lot).

However, using some pretty simple styling when attaching a handheld style solves all problems on the phone. If every phonemaker/device maker would make sure that handheld stylesheets can be used, that would make a huge difference in practical use: webpage or web application.

Gollum says:
July 07, 05h

I really think designing websites for cellular phones equiped with a browser is just too much. Of course text-based information such as weather, agenda, etc…. is surely ideal for PDA, cellular phones.

But I will never use such a device …

Jon says:
July 22, 03h

What kind of phone did you try with and was it Opera on it? Opera has this thing of reformatting the page to fit the small screen, but I have never tried it.