Going Mobile: Development and Preparation

Posted December 1st, 2006 by Joe Dolson

We’ve talked about the two “camps” of accessibility: accessibility for everyone (Camp 1) and accessibility for the disabled (Camp 2). One question which tends to be a significant element in this discussion is about user agents. When you’re targeting screen readers you’re addressing issues which fit easily into both schools of thought. If you’re planning on making your website usable with a handheld browsing device, well, you may be overshooting the mark for Camp 2. Nonetheless, there are a number of issues related to mobile development which are important for both sides of the discussion.

If accessibility is about ensuring your visitor’s ability to use and enjoy your website, then it’s not an unreasonable goal to develop a site to be usable in the maximum variety of situations. Once you become aware of the overlap between handheld browser compatibility and accessibility, it hardly seems like a major step to jump into mobile device compatibility. With the rapid growth of the handheld browser market, it’s unwise not to at least consider mobile browsers while developing your website.

Planning for Handheld Compatibility

The first step in planning for any project is to be aware of the limitations for that medium. Unlike the common desktop, you’re not planning for a minimum viewport width of 800 pixels. At best, you’re looking at around 240 pixels: and in order to hit the more common denominator, you’ll need to be thinking around 120 pixels. One of the most common screen sizes is a square 128 pixels by 128 pixels — Nokia Series 40 devices have this screen size. The actual page size, however, will be smaller than the total screen, since, as with desktop browsers, the browser chrome takes space. But screen size, as apparent as it is, isn’t the sole limiting factor. Among the more relevant handheld device limitations, you should consider:

  • JavaScript incompatibilities.
  • Slow processors.
  • Slow and expensive data transfer.
  • No mouse, no keyboard.

Handheld devices encompass a vast ensemble of hardware and software: different compatibilities are rife. Hypothetically, testing your design on every device would be a brilliant solution. But, practically speaking, you can’t do it. Hundreds of devices, dozens of software choices: custom software, custom interfaces. The variety of possibilities are incredible. The best you can do is to be considerate of the certain limitations of the technology.

Take JavaScript, for example. High-end devices are likely to have pretty decent support for client-side scripting. However, as with screen readers, there may be no way to trigger JavaScript events such as onclick — it’s a mouse-specific method. Furthermore, if you’ve designed your website to be compatible with these high-end devices, you may be restricting access to the vast majority of users with cheaper, more basic devices.

How Dealing with Accessibility Helps

The limitations of a screen reader are somewhat similar to those of a mobile browser. Like a handheld device, page navigation with a screen reader can be challenging: “skip links,” providing navigation past content, past navigation, and back to the top of the page can be incredibly valuable for both types of user agent. When you reduce an article (such as this one) to a width of 120 pixels, and then add in the difficulty of scrolling with whatever navigation tools your phone’s browser has provided, you’re looking at a significant barrier to use if you haven’t provided internal page navigation.

Use of alt text is your friend. It has roughly the same benefits for handheld devices as with screen readers. Remember that bandwidth is expensive: mobile browsers are likely to be charged by the amount of data downloaded. They are, perhaps, even less likely to see your images than a visitor on a dial up connection. An appropriate alt text will tell them whether that image is worth fetching; or convey the important information the image would otherwise communicate. Use images, by all means: but keep them small, explain what they are, and don’t require them.

What do Mobile Browsers do to Your Site?

The vast inconsistencies in support for stylesheets add up to create a very confusing approach for mobile web design. Some devices will apply your “handheld” style sheet. Others will specifically target your “screen” style sheet. Some will pick and choose (apparently) from your available style sheets. So what’s a designer to do?

You should make use of the “handheld” media type:

 <link href="handheld.css" media="handheld" rel="stylesheet" type="text/css" />

Although it may not always be used, when it is applied, this gives you the maximum ability to avoid problems. Make certain your handheld styles are as minimal as you can. There’s only so much design you can retain in a handheld browser screen, so don’t try to get too fancy.

When you’re styling your site for handheld browsing, try and keep these basic elements in mind:

  • Handheld devices are likely to respect your background-color specifications, but they are also also likely to discard your styles for links: your links will probably be basic blue and underlined. (On color screens, at any rate.) Keep this in mind when choosing background colors.
  • Use tables cautiously; and absolutely avoid tables for layout. Using <div>s for your page organization is great: if the devices use them, they can re-flow the divisions to create one long page. If not, the page will be linearized. With tables, you’re likely to end up with extensive horizontal scrolling. Despite the fact that tables can make use of fluid dimensions; they still need to fit all columns into a single horizontal space. With only 120 pixels available for viewing, this can make for very difficult reading. And compound this with the minimal power available to handheld processors, and the table may not only look awful, but take forever to display that way!
  • Headings are your friends. For a full screen browser, you may have carefully crafted your layout so that each section of your site is crystal clear. You may have applied different background images, borders, padding and generous margins to make the divisions of your page obvious. On a mobile browser, however, when everything is presented in one long, narrow column, where you’ve removed that padding and those margins because a 120 pixel screen minus your 15 pixel margins is way too small, appropriate use of <hn> tags will really help define the organization of your site.
  • Don’t depend on spatial relationships. Instructions like “Select from the menu on the left” may become uninterpretable when that menu has slid above or below the instructions.
  • Keep it lean and mean. If you don’t need a tag, then you don’t want the tag. Leave it out.
  • Absolute positioning. Think about it: if you’ve absolutely positioned an element 300 pixels from left it’s off the screen and inaccessible. This won’t cause side-scrolling — you just won’t be able to see it at all! Some handheld browsers don’t support absolute positioning for this very reason — but don’t depend on it.
  • Fixed dimensions. A lot like the above: you fix it, they’ll break it. With fixed widths, the site should still be usable — but it could be more usable.

My Handheld Browser Doesn’t Behave Like You Say it Does

No, that’s quite likely. As I’ve said above: there are hundreds of mobile browsing devices and dozens of software packages — at least. We can’t easily verify any single statement with 100% accuracy, because that would require far more testing than we have the resources for. So you can’t ever make assumptions that your application will actually work on any given mobile device just because it works on yours. Support varies. That’s the only real rule of thumb you can trust for certain.

You can endeavor to do some testing, even without a mobile browsing device available. Opera provides their “small screen” view so that you can check how your site will look with their mobile rendering. They’ve also made a Java-based simulator available so you can at least get a sense for how your site might actually function in a mobile situation.

You can be pretty confident in developing for Opera Mini — Opera has provided extensive instructions to help you design for Opera mini. Many of these guidelines will hold true throughout mobile development.

But Opera’s tools will only give you one mobile view of your site. For further testing, you can download several other simulators for use off-line:


Although they aren’t equivalent challenges, as a developer you need to consider many of the same issues in order to create a website which is usable by handheld devices as you do to create an accessible website. The major issue in handheld development is device compatibility: since it’s impractical to test a website on all devices, you need to target a relatively minimal feature set in order to make your website or web application usable by the greatest variety of users.

Sources and Further Reading:

Would you like view comments on this article?

Sorry. Comments are closed.

Note: This is the end of the usable page. The image(s) below are preloaded for performance only.