Before we even get to talking about mobile devices, we need to talk some more about users. After all, users are the most important part of the equation when you’re making a website.

With the novelty of all the new types of mobile devices on the market and the new things that are possible in HTML5 and CSS3, it’s easy to get caught up in the excitement and spend time and effort developing exciting websites that show off all the things you can do.

But keep in mind that the purpose of a website isn’t to be as technologically impressive as possible. Learning to design and develop a website is not just about writing the code that renders the website. It’s about creating an experience for the people who will be using the website.

As much as all of us who work on the Web are talking about responsive design, making responsive sites, and thinking about responsive design, we need to remember that the average website user has no idea what responsive design is. And there’s no reason for him to.

All users want is a website that works well on the device they are using at that moment—which may not be the same device they are using at other times during the day. They don’t want to think about what device they’re using; they just want to have a website that works.

Users aren’t thinking about the fact that they’re using a mobile phone to visit a website on the way to work, a desktop computer during their lunch break, and a tablet when they’re browsing the Web while watching TV late at night. And it shouldn’t matter to them. They should just get a website that works, no matter which device they use to access it.

So when you’re designing a responsive site, keep in mind that your goal isn’t to create a responsive site, but rather to create a site that works well for users; responsive design is the tool you will use to create that site.

Users don’t care what’s under the hood. They just want a website that is going to give them the content and functionality that they want, with a minimum amount of fuss to get to where they want to go.

And always remember, it’s up to the user what device she wants to use, not up to you. You can decide what types of devices you want to support, but if your site doesn’t work on the device the user wants to use, you’ll lose that customer.

When the iPhone first came out and we started designing websites to work on mobile phones, there was this “myth of the mobile user” that came about: the idea that any person using a mobile device was “out and about,” on the go, in a hurry to get somewhere, in a hurry to get information. That typical mobile phone user didn’t want to browse the Web, he just wanted to get quick information, like a restaurant address or whether his flight was on time.

And at that point, the myth was probably true. It was hard to access websites on a smartphone. There weren’t yet responsive sites or even many mobile sites, so what you had was a tiny site you had to zoom in and out on to read anything. Users probably didn’t use their mobile phones to access websites unless they absolutely had to, and saved their web browsing for their home or office computers, where it was much easier.

But then websites started to change to accommodate mobile phones, and it got easier to do things on your phone. And then tablets came along, which were mobile, but not really, because a lot of them only worked on WiFi so you weren’t really mobile when you were using them.

And now people use their mobile phones all the time, whether they’re out of the house or sitting on the sofa at home with a laptop a couple of feet away, because it’s just easier to reach for the phone.

More and more people are relying on mobile devices as their primary or only way of accessing the Internet, so you can’t keep assuming that users only want to look up restaurant addresses or flight times. People want to do everything on their mobile devices that they could do on their desktop computers—that is, as long as you let them.

Although we shouldn’t assume that users of particular devices only want certain content or interactions, we can determine that particular parts of the site are used more often on certain devices, and make sure that content is very easy to access.

For example, we can’t assume that mobile device users only need certain content, because they aren’t necessarily “on the run” and looking for “on the run content.” However, they are sometimes “on the run.” And because it’s more difficult to navigate a website on a mobile phone using your fingers than it is to navigate a desktop site with a keyboard and mouse, we should make sure it’s easy for mobile users to get to the important things.

In Figure 8-1, a responsive website from Kiwi Bank in Australia, the narrow-width design has a few key links and pieces of information at the top. The login link is first—which is also prominent on the wider site, at the top right.

Following that, you see “Find a Branch,” the bank’s main phone number, and the bank’s opening hours. These are all things that some mobile users will want to get to easily and quickly when they’re in a hurry, so they are right there.

Figure 8-1. Using media queries, you can change what content is most prominent on the screen depending on viewport width.

But you don’t see “Find a Branch,” the phone number, or the hours when you look at the wider version of the site. They’re still there—you just have to click on “Contact Us” to get to them. A desktop user is likely not in so much of a hurry, so she won’t mind a couple of extra clicks, which are easier to make when you have a mouse.

The mobile user still gets everything that you see on the wider design—he just needs to scroll down on the narrow-width site to get to the navigation and all the content. A mobile user looking for interest rate comparisons is probably not in as much of a hurry as a mobile device user who needs the branch hours, so he won’t mind the extra scrolling.

If you’re reading this book, it’s likely you have a job where you spend a good part of your day in front of a desktop or laptop computer. You can browse on the Internet whenever you want. It’s easy to forget not everybody has that desk job experience. People who work in service jobs, for example, generally don’t spend their work time in front of a computer. Some of them have computers at home, but some don’t. And some that do have computers just prefer to use mobile devices.

The rise of smartphones means that more and more people are going online from mobile devices. According to Pew Internet, 57% of Americans said they’d used a mobile device to access the Internet in 2013. A surprisingly large number—34%—of these mobile Internet users said that was the primary way they accessed the Web.^[3] This is a large and growing audience.

Teens are increasingly mobile-primary users. Although many of them have access to a desktop computer at home, they have a greater sense of privacy on a mobile phone, which just belongs to them, as opposed to a desktop computer shared with other family members, where they may get little privacy. They also aren’t sitting in front of a computer all day like many office workers. Teens may not be a big part of your target audience, but as they grow into adults, they will continue to be comfortable using their phones for a majority of their web browsing.

So what does this mean? Your website has to work on all devices. You can’t assume that if something is too “complicated” for a small screen, you can just ignore the issue because users will switch to a larger screen for that activity. Not all of them will.

And don’t think that just telling users they need to switch to a desktop browser is enough. It’s not up to you what devices users choose; it’s up to them.

It may not be possible to make everything easy to use on a small screen, but at least don’t make things not usable. Unless, that is, you are willing to lose a portion of your users or customers.

One thing to consider as you’re making a responsive design that works across screen sizes is that any given user may visit your site from different devices at different times.

Although you’ll use responsive design to change how the website is displayed at different screen widths, you want to make sure that the experience feels the same even on different screen sizes. Users should be able to go to the site on different devices and not be unsure if it’s the same website. The color scheme, imagery, and fonts should be similar, no matter what device they are using.

Something like the navigation may be displayed very differently depending on screen size, but the same options should be available, using the same information architecture to organize them in the navigation.

As early as the mid-1990s, phones were available that could access the Web—although it was only text-based web browsing, a far cry from what we enjoy today. Web access on phones became more common through the early 2000s, although it was still only a limited version of the Web.

A smartphone, such as the iPhone, is really a miniature computer, with a mobile operating system that allows the user to install apps.

Feature phones, on the other hand, are not very much like your computer. These are the phones that people used a lot before the iPhone came out. They can access the Web, but when you view websites, they look nothing like they do on a monitor screen. Feature phones have fewer capabilities than smartphones and often don’t have a touchscreen, and you may have to navigate using a little button like in Figure 8-7.

But feature phones have not been replaced by smartphones. In the United States, 58% of adults own smartphones, while 32% own feature phones.^[4] Some countries have much higher rates of smartphone penetration, such as the United Arab Emirates and South Korea, which are at about 73%, while other countries, such as those in sub-Saharan Africa, have many more feature phones than smartphones.^[5]

Figure 8-7. Example of a feature phone (photo credit: Rodrigo Senna, http://www.flickr.com/photos/negativz/38422354/).

Part of responsive design is making sure that your site will work on any device, not just adapt to the screen size. As we talked about in Chapter 3, by starting with good HTML and using progressive enhancement to add CSS and JavaScript for devices that support them, you can make sure your site is usable on the most basic feature phones.

If your site has a lot of complex interactivity, it may not be possible to have your whole website work well on every device, down to the oldest browsers and devices, but do what you can.

For example, perhaps you can’t make a restaurant website’s online ordering work on the oldest phones, but you should be able to make the page with the restaurant’s address and phone number work on pretty much every device, without a lot of extra effort.

Tablets have become increasingly common in recent years. They’ve been around for many years, but didn’t become popular until the release of the iPad in 2010. The iPad is by far the most popular tablet, with other brands like Amazon’s Kindle Fire trailing far behind.

Tablets are mostly very similar to modern smartphones, generally using the same operating systems, like iOS and Android, and allowing for the installation of apps.

Many tablets only have web access via WiFi, not by cellular networks, so they aren’t technically classified as mobile devices. But that really doesn’t matter. The lines are so blurred that it’s no longer helpful to stick everything into categories of either mobile or nonmobile. It’s more of a vague continuum, with phones on one end (mostly mobile) and desktop computers on the other (mostly not mobile).

Ereaders are devices that are meant to be used primarily for reading downloaded books, but many of them now include web browsers and are marketed more as a tablet (like the Kindle Fire). Some ereaders, such as more basic versions of the Kindle, have built-in browsers with limited functionality but use e-ink instead of a traditional screen, so everything appears in grayscale.

Many game consoles now have built-in web browsers, allowing you to access the Web on the screen connected to your console.

Some of them have very primitive browsers, meaning that what you see on the screen may not be exactly what the designer intended. But as with feature phones, as long as the site starts with good HTML and then adds CSS and JavaScript as progressive enhancement, it should be usable on these devices as well.

You never know where a web browser is going to show up. For example, WiFi-enabled refrigerators have been available for several years (it’s kind of like having a small tablet embedded on the front of your fridge). Currently, they have a limited operating system that only supports certain apps, but I imagine it won’t be too long before you have a full web browser in front of you in the kitchen.

There are also now watches with browsers, browsers in cars, and Google Glass, which puts a browser directly in front of your eyes. These all have very different interfaces, and you can’t plan for all the possible devices that might exist in the next few years. But luckily, that’s where responsive design comes in. Your goal is to design a site that’s future-friendly, that will work on any screen size and any device, no matter the capabilities.

Until a few years ago, our access to the Web was limited to desktop and laptop computers. This is the setup all of us are probably most familiar with:

We often think of these devices as having fast connections, but that’s not always true. Many home Internet connections are not all that fast, and laptops are often used in hotels, coffee shops, or other locations with slow WiFi. Some people in rural areas don’t have access to broadband, and use satellite Internet to connect.

Since the advent of the iPhone, the primary input method on smartphones has been a capacitive touchscreen.

Capacitive means that the screen works by measuring electrical charges conducted through anything touching the screen, such as a fingertip. The human body conducts electricity, but not all objects do, which is why touching a smartphone screen with something like a pen or a gloved finger has no effect. However, you can buy special styluses made of conductive material, or even gloves with conductive threads on the fingertips.

Older devices were sometimes made with resistive touchscreens, which have two thin layers that come together when the user presses on the outer surface with a fingertip or stylus. The screen is able to determine the precise location of the pressure. One disadvantage of this type of screen is that some amount of pressure is required, and the screens will often not register when a touch is too light. The screens are also more prone to damage.

Although phones with touch interfaces had been around for years by the time the iPhone was introduced in 2007, the iPhone was one of the first with a multi-touch interface, which allows the screen to recognize more than one point of contact simultaneously. This allowed for much more complex interaction with the screen, such as the pinch-to-zoom motion.

Modern smartphones use gestures as a way to interact with the screen’s content, giving users a “hidden” way to use the interface, so less of the valuable screen real estate has to be taken up with controls.

The pinch-to-zoom gesture is one of the most common, allowing an intuitive way to zoom in and out on things like maps. If you were viewing the same map on a laptop/desktop, you would see a slider with plus and minus buttons taking up part of the screen.

Some gestures, such as zooming in and out on a web page, are built into the browser or OS. Others, such as swiping sideways to go to the next image in a slideshow, have to be added to a web page using JavaScript.

Although you could skip that step and require users to tap or click arrows to navigate a slideshow, adding in gesture support can make a site much easier to use on touchscreens. Adding functionality for devices that support it, where it would enhance the experience, is a key part of responsive web design.

You can find several JavaScript plug-ins to add swipe behavior, such as TouchSwipe (http://labs.rampinteractive.co.uk/touchSwipe/demos/) or Swipe (https://github.com/thebird/Swipe).

Touch events is a phrase used in the context of JavaScript to describe any interaction the user makes with the screen, whether it’s a simple tap or a multi-finger movement. There are three basic touch events, touchstart, touchmove, and touchend, which can be used to define pretty much any interaction.

In addition, a touchscreen device will recognize JavaScript events that were designed for a mouse, such as click.

For people using touchscreens to access your site, one of the biggest usability issues is touch target size (i.e., the size of the link or other element they need to select by tapping).

When using a mouse to click a link this isn’t nearly as important, because (for most users) it’s easy to get the cursor to exactly the right spot to click on a link or other element. But for users touching a screen, keep in mind that a finger is a lot bigger than a cursor, and if everything on the screen is really small, it’s hard to hit the right spot.

If a target is all by itself, that’s not a big deal, but if targets are very close together it’s easy to accidentally hit the wrong one, sending you to a page you don’t want to visit, or taking an action that you don’t want to take.

You’ll notice that when using a touchscreen, users actually tend to use the pads of their fingers (where the fingerprint is), not the fingertip (the very end of the finger). That can actually be a pretty wide area, depending on the person.

If a user is trying to hit a very small target he may sometimes use the fingertip instead of the finger pad to be more accurate, but this will slow the user down and make him work harder, which you don’t want to do.

The average index finger is 1.6–2 cm (.6–.8 inches) in width, according to a study by the MIT Touch Lab. That converts to about 45–57 pixels. Luckily, smartphones are pretty smart when it comes to taps, and even though your finger might be touching many pixels on the screen, it can usually figure out what you were trying to tap. But if the target is too small, your success level will go way down.

Phone manufacturers actually have guidelines in place for how large an element should be so that users can easily select it on touchscreens. Apple’s iPhone Human Interface Guidelines recommend that your touch target be at least 44 × 44 pixels. Microsoft Windows Phone recommends 34 pixels wide, with a minimum of 26 pixels. Nokia suggests your target should be at least 28 × 28 pixels.

That’s a lot of variation, so what numbers do you use? If targets are right next to each other, I recommend making them at least 44 pixels wide if at all possible.

As you’re testing your site on various mobile devices, make sure to check if links are easy to select on the touchscreens. And keep in mind that other people may not have fingers as limber as yours—some people have larger fingers, and older users may have more difficulty tapping precise points on the screen.

Increasing touch target size

You can use CSS to increase the size of touch targets. One way is to make sure any space around a link is padding rather than a margin. You’ll need to go back to the box model you learned about in Chapter 3, which explains the difference between padding and margins.

Consider this list of links in Figure 8-8. The links are close together and likely are difficult to hit with your finger, depending on the text size. I’ve outlined each link so you can see which part is the clickable/tappable area.

Figure 8-8. A list without styling has the links very close together.

How can we improve this? To start, you can make each link display: block, which will make the <a> element a box that extends to the full width of the containing element, as in Figure 8-9, rather than stopping at the end of the last word:

ul a { display: block; }

Figure 8-9. Making each link block instead of inline makes the touch target boxes extend to the full width of the containing element.

To increase the touchable area, you can also increase the padding (not margin) of each <a>, which increases the touch target size in whichever directions you choose, as you see in Figure 8-10:

ul a { display: block; padding: 3px 5px; }

Figure 8-10. Adding padding increases the touch target size in any or all directions.

Don’t apply the padding to the <li>, or that will leave empty, non-tappable space between the links, as in Figure 8-11:

li { padding: 3px 5px; }

Figure 8-11. If you use padding on the list items, that leaves empty space between the links and makes the touch targets smaller.

You should make use of all the available space; there’s no need for empty spaces to separate the links. Mouse users will click directly on the links, so there won’t be any confusion.

For links inside blocks of text like paragraphs, it’s a little trickier. By making sure there is enough space between the lines, you can keep links a bit further apart (we’ll look at how to do this with line-height in Chapter 9). Try not to have adjacent words be different links. Not only does that make them harder to click, but on touchscreens the users may not be able to tell there are multiple links, because they are not able to hover and see their targets.

Additionally, keep in mind this is going to be tricky for the smallest screens, where there’s not a lot of available space. If you need to make your touch targets smaller than you’d like for small screens, you can use media queries to change the target size for different screen sizes. In the preceding example, if your padding of 3 pixels and 5 pixels just won’t fit on a small screen, you can use media queries to give slightly less padding for the narrow screens and more ample padding for tablet size or wider.

While the navigation on websites and desktop applications has naturally evolved to appear at the top of the screen, with key elements like the home button or search box in the top corners, this layout is really only optimal if you’re using a mouse to get to the targets. With touchscreens, we enter a whole new usability world.

You know from using apps on a smartphone that navigation on apps often appears at the bottom of the screen, making it easier to hit those buttons with your thumb if you’re holding the phone in one hand.

It’s not just phones—with pretty much any touchscreen, it’s easiest to touch the part of the screen that’s closest to your hand. Even on a desktop touchscreen, it’s physically easier and less fatiguing for users to touch elements near the bottom of the screen.

And not only does placing controls at the bottom of the screen make them easier to reach, but it also has a bonus effect: your fingers (or your arms, with a desktop touch monitor) aren’t blocking the rest of the screen, so you can still see it.

This is a difficult topic, so we’ll touch on it only a bit in this book. In Chapter 10, we’ll look at an example of a website with navigation at the bottom of the screen. Although this adjustment to the standard user interface isn’t often used, it’s bound to become more common as web usage moves further away from traditional keyboard and mouse devices.

If you’d like to learn more about the idea of optimizing navigation for touchscreens, check out Josh Clark’s blog post, “New Rule: Every Desktop Design Has To Go Finger-Friendly” (http://globalmoxie.com/blog/desktop-touch-design.shtml) or Luke Wroblewski’s “Responsive Navigation: Optimizing for Touch Across Devices” (http://www.lukew.com/ff/entry.asp?1649).

A common problem with mobile apps—and less so with mobile websites—is that they don’t rotate.

A website should rotate to be usable in either the vertical or horizontal screen orientation. Sure, it’s nice to be able to design for one orientation, but an issue we have is pull-out keyboards, as you see in Figure 8-12.

Figure 8-12. For phones with a pull-out keyboard, the site must be usable in the horizontal orientation.

On phones with a pull-out keyboard, apps and websites can only be viewed in horizontal orientation (unless you don’t need to use the keyboard).

It’s also frustrating to users to tell them a website isn’t available when they’re holding their devices in their preferred orientation, such as in Figure 8-13. Again, remember that it’s up to the users to choose their devices and how they hold them; it’s up to you to make the site responsive to accommodate the users.

Figure 8-13. Some sites require that they be viewed in a particular orientation.

Because most of us think of using a computer or mobile device as primarily a visual experience, it stands to reason that one of the main impediments to using a computer or mobile device is not being able to see the screen, or not being able to see it well enough.

Color contrast

The color of the text on your website has a significant effect on its legibility.

Black text on a white background is straightforward and classic, but you may want to get a little more interesting.

However, you need to keep in mind that people visiting your site may have difficulty reading text if there isn’t enough contrast between the background color and the foreground color. This will include users with low vision, including many older users, and also users who are color-blind. Even for someone with perfect vision, low contrast can be a problem when trying to read on a tiny mobile phone screen with light glaring on it.

Keep in mind that the visual design of your site is meant to sit on top of your content, not overwhelm it.

The Web Content Accessibility Guidelines (WCAG) recommends that the contrast ratio of text color to background color is at least 4.5 to 1. For large text, such as headlines, the contrast ratio needs to be only 3 to 1, because it is easier to read large text with less contrast. For more information on this, see “Understanding WCAG 2.0 - Contrast (Minimum)” (http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html), from the W3C.

You generally won’t be able to tell if the contrast is acceptable just by looking, but you can use an online tool such as the Color Contrast Checker (http://webaim.org/resources/contrastchecker/) from WebAIM to check if there is enough contrast between two colors. You simply enter the hex codes of the two colors, and it will tell you the contrast ratio and whether it passes or fails for both normal and large text.

Another tool is Color Contrast Check (http://snook.ca/technical/colour_contrast/colour.html) from Jonathan Snook. After entering the numbers, it lets you play around with sliders to adjust the RGB settings, hue, saturation, and value of the colors, to see how you can get to a set of colors that passes.

To check everything on your website all at once, use CheckMyColours (http://www.checkmycolours.com) from Giovanni Scala. It will test every single element on a web page and give you a list of which colors pass and which fail.

Even gray can be a problem. It’s trendy for text to be gray instead of black—it looks more elegant—but it’s often hard to read.

The text in Figure 8-14 is pure black (#000000), and two shades of gray (#777777 and #AAAAAA). Both of the grays fail the contrast test.

Figure 8-14. The two shades of gray text fail the contrast test.

Most of the Web is visual, but there are also bits that are audible, such as videos and audio clips. For users who are deaf or hard of hearing, this information needs to be presented in a different format to be accessible.

Videos should have captions whenever possible. Unfortunately, although creating videos requires very little technical skill (pretty much anybody can do it), captioning is quite a bit more difficult. If you aren’t able to caption videos, providing a transcription is an alternate option. It’s not as good, because the user can’t match the visual images with the words at the same time, but it’s better than nothing.

Audio clips should, of course, have a transcription.

This doesn’t only help users who can’t hear the content. Other users may just prefer to read rather than listen (it’s faster), or perhaps they are in a loud location where it would be hard to hear the content, or a quiet location like a library where they can’t play the audio out loud and they don’t have headphones.

Although users with visual disabilities are the most obvious category of people who use assistive devices to access the Web, there are also people who have no trouble with vision, but who can’t physically use a keyboard and/or mouse in the same way that most of us do.

People with cognitive disabilities are an often-ignored portion of a website’s user base.

Providing clear and simple language, which we talk about in Chapter 2, is a great start to making your website more accessible to these users. This also helps users for which your website is in a language other than their native language.

You can also help users by having consistent design patterns throughout the site, such as using the same navigation options on each page. If you redesign a website, some users will have to “relearn” how to use the site—it’s not simply a matter of finding where different things have moved to.

Another issue is animated graphics, which can be distracting for users with dyslexia or ADHD. It’s best not to have anything on a web page animated by default, and make sure you don’t use animated GIFs to communicate information, as some users use browser settings to turn off animations entirely.

If the world was perfect, every company that makes websites would have a device lab, a collection of a wide range of mobile devices that designers and developers could use to test the websites they’re working on. But unless you work at a large company with a big equipment budget, you’re probably not that lucky.

You can probably ask around and come up with at least a few coworkers who will let you borrow their phones, but they’re likely to have similar devices, and you probably won’t find all the device types you want to test on.

The open device labs that have started cropping up in the past few years are one solution. An open device lab is a place where you can find a collection of mobile devices that are available for the community to use. Some device labs are owned by web agencies or other companies that have generously made their labs open to the public; others are community organizations or nonprofits that rely on donated resources.

There are open device labs in cities around the world, although most are located in major cities of Europe and the United States. You can find a list of device labs on OpenDeviceLab.com (http://opendevicelab.com).

What you will find in a device lab will vary. Some labs may only have a few devices, while others may have several in a wide range of operating systems and form factors (physical interfaces). Some device labs charge a small fee for access, but many are free.

Although it sounds expensive to buy devices to use for testing, there are ways to get some of them cheaply.

Having to pay for a cellular plan to go along with each phone can be prohibitively expensive, but many phones can be used on WiFi without having to pay for a cellular plan. This is generally adequate for testing purposes, although it won’t allow you to test performance over a mobile connection.

You can get many older phones used off of eBay, Craigslist, or other sale websites, or even ask friends and coworkers. Not all mobile providers have a way to “trade in” your old phone when getting a new one, so people tend to just stick their old phones in a box in the closet, as it just doesn’t seem right to throw away that once-expensive piece of equipment.

You probably already have, or can easily borrow, both an iPhone and an Android phone; it’s worth having a 7” tablet and a 10” tablet on hand for testing too, so you can get a feel for actually using a website on that size screen, as opposed to just viewing it on an emulator.

One of the first things you should do to test your site is validate your code. This can catch code errors right off the bat, and save you a lot of time troubleshooting things that don’t display correctly.

Validation tools are built into web developer add-ons for major browsers, or you can use an online service to validate your code, such as the W3C Markup Validation Service (http://validator.w3.org) (for HTML) and the W3C CSS Validation Service (http://jigsaw.w3.org/css-validator).

As you’re designing or coding a responsive website, you’ll certainly be resizing your browser window to see how the design looks at different viewport widths. Although this is useful—and where you should start—it’s not necessarily going to give you an accurate picture of what the site will look like on actual devices.

However, browser window resizing gives you an advantage you don’t get on mobile devices: you get to see how the design looks at every possible viewport width, not just the widths of whichever devices you test on. And no matter how many devices you test on, you’re not going to be seeing every possible device width, so the browser window may be the only place you can see some weird layout quirk that happens only between 643 and 647 pixels.

Browser tools

When you start your testing in the browser, there are a few tools you can use to make the job a little easier.

Although changing the window size gives you an idea of how the design looks across all viewport widths, you’ll also find it useful to see the site in the exact size of common devices.

In Firefox, this is easy; there’s a built-in tool. Go to Tools → Web Developer → Responsive Design View, shown in Figure 8-15. After loading a page, you can use a drop-down menu to choose among several different preset screen sizes, and there’s even a button to allow you to take a screenshot of the web page.

In Safari, there’s an extension called Resize (http://resizesafari.com/) that lets you resize your browser window to configurable preset sizes.

For Chrome, try the Windows Resizer (https://chrome.google.com/webstore/detail/window-resizer/kkelicaakdanhinjdeammmilcgefonfh).

Figure 8-15. Responsive Design View in Firefox.

A few years ago, we only had to test our websites on two operating systems (Mac OS and Microsoft Windows) and a handful of browsers (Firefox, IE, Safari, and maybe Opera).

Now, however, there are several mobile operating systems and many mobile browsers to consider as well. Here’s a list of the major mobile operating systems and the default browser for each:

For each operating system, you should test on the most recent version of the OS, and if possible also test the previous major release, especially for iOS and Android.

You may also wish to test the Symbian OS that runs on Nokia devices; it was the most popular OS worldwide until 2010, and many Symbian phones are still in use. Several open source mobile operating systems are also available, including Firefox OS, Sailfish OS, and Ubuntu Touch OS.

The Kindle Fire runs Fire OS, which is a custom version of Android.

Every mobile phone comes with a default browser, such as the ones just listed, and many users don’t even realize that they have the option to install other browsers on their phones, just as they would on a desktop computer. Besides the default browsers already listed, you may want to test:

And don’t forget about desktop computers. In addition to testing on both Microsoft Windows and Mac OS X, make sure to test on all the major browsers:

If you don’t actually have a particular device, you can still test on that device by using a mobile emulator or simulator, which will allow you to use your desktop monitor to view what your site would look like on a particular device.

The difference between an emulator and a simulator is that the former will show you how the device would behave, while the latter only shows you what the device’s screen would look like.

Many of the mobile operating systems and manufacturers have emulators or simulators you can download; check out Maximiliano Firtman’s “Mobile Emulators & Simulators: The Ultimate Guide” (http://www.mobilexweb.com/emulators) for an extensive list.

However, rather than having to download a lot of different software, you may find it easier to use a browser-based tool that will allow you to test many devices or operating systems at once.

Two of the most popular and comprehensive are BrowserStack (http://www.browserstack.com) and Cross Browser Testing (http://crossbrowsertesting.com). These have a monthly fee based on users or usage. You can find many others, some free, by searching the Web.

Don’t forget that some users will be coming to your site using assistive technology, such as screen readers.

To make sure these users are able to access your site, you should test in at least one screen reader. If you don’t have the budget to buy any of the popular commercial software options, there are several free options available.

Mac OS X has a screen reader built into the operating system: Voiceover for OS X (http://www.apple.com/accessibility/osx/voiceover/).

You may also wish to try the Fangs Screen Reader Emulator (https://addons.mozilla.org/en-US/firefox/addon/fangs-screen-reader-emulator/), an add-on for Firefox.

Even before testing in a screen reader, you can start by viewing your site without the images—replacing them with the alt text—to see if the site still makes sense. Web developer add-ons for the major browsers will give you this option.