Daily Tips & Tricks for Web Enthusiasts

UX & Accessibility

Users Can’t Have an Experience Until You Ship

Until you release what you’re working on the only person who can benefit from it is you, and you’re probably not benefiting very much because you haven’t released what you’re working on yet!

A painting no one can see is a painting that will inspire no one. A song no one can hear is a song that cannot bring a smile to anyone’s face. A website no one can visit has no impact.

So when should you ship?

As a general rule of thumb you should ship sooner rather than later. As a more concrete rule, ask yourself this question on a regular basis:

If I shipped today, would most of my target audience have a good experience?

If the answer is yes, it’s time to ship.

Note the word good in that question. I chose that word very carefully. I very purposefully did not choose words like great, outstanding, phenomenal, incredible, magnificent, or other grandiose terms alluding to some state at or near perfection. If any of those words apply, you’ve taken too long to ship.

If you have something that will provide a good experience to most people, trying to push it further beyond good is generally a poor use of your time and resources. When you release something good people will experience it, poke it, prod it, react to it, and give you feedback about it. The knowledge you gain from shipping will allow you to go from good to great much faster and much more easily than if you tried to do so on your own.

So, if you shipped your thing today, would most of your target audience have a good experience?

Make Small MP3s that Sound Great

If you create and share audio on the web you probably create MP3 files. MP3s enjoy wide support and have a lot of flexibility when it comes to how they’re encoded, making them a great choice for everything from sound effects to music and podcasts.

However, that flexibility can raise a number of questions, most of which boil down to a single concern: How do you strike a good balance between audio quality and file size? The higher the quality the better the listening experience, but if the audio takes too long to download there might not even be a listening experience, so it’s important to strike a good balance when encoding your MP3s.

The quality and size of an MP3 are determined primarily by three factors:

  • The sample rate defines the number of samples per second, and determines the range of frequencies that can be encoded in the audio. This should almost always be set to 44.1 kHz (44100 Hz), which will allow your audio to encompass the effective range of human hearing. Lower sample rates sound noticably worse, and higher sample rates waste bandwidth and disk space.
  • The bitrate determines the amount of data used to store each second of audio. A 128kbps MP3 uses 128k of space to encode a single second of audio, for example. The higher the bitrate, the more information is stored, and the better the audio sounds.
  • The choice between mono, stereo, and joint stereo determines how many audio channels the MP3 will contain and how those channels are encoded.

Joint Stereo

The joint stereo option warrants a bit of explanation, both because it’s usually the best option and because it does some neat stuff behind the scenes.

In most stereo audio both the left and right channels contain mostly the same information, with occasional differences. Joint stereo is designed to encode audio that fits this description more efficiently by encoding everything that’s the same between the left and right channels once, then encoding everything that’s different between the left and right audio channels separately.

Imagine a piece of music with the vocals and instruments distributed equally to both the left and right channels, with a short guitar solo in the middle that pans from left to right. A regular stereo MP3 will encode all of the audio twice, once for each channel, despite the fact that most of the audio (except the solo in the middle) is the same. Joint stereo, on the other hand, will only record the identical audio once, and then encode separate left and right channel information only when they differ. This results in smaller files (sometimes significantly smaller if most of the audio is the same across both channels).

To put it another way, if your source audio is mono (single channel) and you encode it as both a stereo MP3 and joint stereo MP3 (with all other settings being equal), the joint stereo MP3 will be half the size of the stereo MP3 because it’s not encoding the same information twice.

It’s also worth pointing out that there is no file size difference between mono audio encoded as a mono MP3 or a joint stereo MP3.

Joint stereo also has an important impact on how the bitrate applies to the audio. A 128kbps stereo MP3 is actually two separate 64kbps channels of audio. On the other hand, a joint stereo MP3 encoded at 128kbps uses all 128kbps for both channels when both channels are identical, and only splits the bitrate between the channels when there are actual differences.

My Recommended MP3 Settings

I always set the sample rate to 44.1 kHz (44100 Hz) for the reasons mentioned above. I also always use joint stereo unless I want to convert multi-channel audio into mono, in which case I’ll encode as mono to save myself a step.

As far as bitrates go, I use the following bitrates for these scenarios:

  • When I want a smaller file at the expense of some audio quality: 96kbps.
  • When I want to balance file size and quality: 128kbps.
  • When I want high quality audio at the expense of file size: 196kbps or 256kbps.

There is one exception to this. If you have audio that’s only people talking, with no music, 64kbps will do just fine, as pointed out by Marco Arment on Twitter. This applies to some podcasts, but if there’s music somewhere in there 96kbps or higher is probably best.

What About Variable Bit Rate MP3s?

So far all of the bitrate information I’ve talked about pertains to constant bitrate MP3s, meaning they use the same amount of information to encode every second of the audio. The MP3 format also supports something called variable bitrate, or VBR, which uses a variable amount of information for every second of the audio. Less information is used for less complex audio, and more information is used to capture more detail when the audio becomes more complex.

While VBR MP3s do tend to be slightly higher quality at slightly lower file sizes, the tradeoff is compatibility and a compromised user experience. Many audio players, even today, do not fully support VBR MP3 files. One common issue is skipping forward or backward in a VBR MP3 and finding yourself in a different place than you expected to be.

I do not encode any audio as variable bitrate MP3s, and I recommend you don’t either.

You Can’t Hover on a Touchscreen

When CSS was new the vast majority of web browsing took place on a desktop or laptop computer with a mouse attached. Thus, when the :hover pseudo-class started to have wide browser support, many people figured out how to stretch it to its limits. People created everything from tooltips that revealed important information when hovering over an element to dynamic, multi-layered cascading menus powered by CSS alone. Many people wrote articles and blog posts showing others how to stretch :hover to its limits and do some amazing things, and those posts are still floating around today.

However, just because you can do these things it doesn’t mean you should. Today there are a huge number of people browsing the web who can’t hover, either because their device doesn’t have a mouse cursor or the way they’re interacting with the web doesn’t involve a mouse. If you use :hover for any critical functionality you’re excluding a significant portion of your audience, and the number of people that fall into this category is climbing.

The biggest and most obvious group of people who will never see any of your :hover styles or functionality are people using smartphones, but they’re not alone. A lot of tablets are touch-only. Many people, either by choice or by necessity, navigate the web with only a keyboard. There’s also no concept of a mouse cursor when you’re blind, or have impaired vision, and are browsing the web using a screen reader.

The :hover pseudo-class is great for anything that isn’t critical. Enhancing the appearance of links and menu items, highlighting rows in tables so they’re easier to read, and other visual enhancements that are not critical to the way your site functions are great applications for :hover. Go ahead and use them, but be sure to keep people without mice in mind!

Use What You Build

Have you ever come across something that didn’t work well because the person who built it didn’t actually use it? Don’t be that person. Use what you build.

Use it on your computer. Use it on someone else’s computer (preferably one with a different operating system and web browser). Use it on your phone. Use it on someone else’s phone. Use it on a tablet. Walk into an Apple Store and use it on a bunch of different devices.

Don’t just take a quick look. Use it. Actually use it. Find the rough edges. Figure out what’s broken. Take notes. Now prioritize the problems, get to work, and make what you built better for everyone.

Use Caution when Changing Default Outline Styles

Most web browsers apply a distinctive visual style to the element that’s currently in focus. This usually manifests as a prominent outline around the element, which is usually applied using the outline CSS property behind the scenes.

If the default outline style for focused elements clashes with your design you might be tempted to remove them using something like this:

:focus {
    outline: none;
}

Do not do this! Those default outline styles are there for a very important reason: accessibility. They help people who don’t (or can’t) use mice and people with visual impairments navigate your site. Removing the default outline styles without replacing them with something else will make your site harder to use for a lot of people.

Want to find out more? Good news! There’s an entire site dedicated to this issue, and it includes suggestions for alternative focus styles to use instead of the defaults: OutlineNone.com.

Write Great Alternative Text for Images

The <img> element has an alt attribute that should be populated with text describing that image. The content of an image’s alt attribute is used in various situations:

  • Search engines can’t see images the same way people do, so they’re going to look at the content of the alt attribute instead.
  • When people have their browsers configured to not load images (which is more people than you might think; many have restrictive data and/or bandwidth limits).
  • Non graphical browsers, including screen readers, will use the text in the alt attribute in place of the image.
  • If the image fails to load, or the image format is not supported by the browser, the alternative text will be displayed instead.

If you find yourself wondering what you should put in an alt attribute ask yourself this question: If you were describing this website to a friend over the phone, and they had no way to view it, how would you describe this image? The answer is what you put for the value of that image’s alt attribute.

Some image elements are not integral to the content of the page, like decorative images. If you wouldn’t mention a particular image to your friend on the phone that <img> element should still have an alt attribute, but its value should be an empty string, like this:

<img alt="" src="...">

An alt attribute with an empty string indicates that non-visual browsers, like screen readers, can simply ignore the image.

For images that are a key part of the content, but have no appropriate textual description, the alt attribute should be omitted entirely (but this is almost never the case).

Text Readability Basics

There are five primary factors involved when it comes to designing text that's comfortable to read on the web:

  • Font Family
  • Font Size
  • Font Color
  • Line Length
  • Line Height

Font Family

Generally speaking, for body copy, you should use a serif or sans-serif font designed for large blocks of text. The usual suspects here are font families like Helvetica/Arial, Times, and Georgia. Avoid fancy script font families, typefaces designed for headlines, and the like.

Font Size

When it comes to the size of text on the web, the biggest misstep to avoid is making text too small. Most web browsers default to a font size of 16px for a reason; don't go much smaller than that.

Font Color

Font color is important for one reason: contrast. In order for your text to be readable it needs to have a decent contrast ratio. Be wary of placing light text on a light background, or dark text on a dark background. Not everyone has perfect, or even good vision. As we age our eyes take in less and less light. Just because you can read something doesn't mean everyone can.

Line Length

The optimal length of a line of text is a matter of some debate, but most people agree that the acceptable range is somewhere between 50-75 characters long, including spaces. You should avoid going over 80 characters long at all costs, as doing so will have a severe impact on the readability of your text. As a general rule of thumb, and depending on the font family being used, you'll want to aim for a width of 25em to 35em as a good starting point, and then tweak things from there.

Line Height

Like line length, line height is another subjective area, but most people agree that something between 1.2-2 times the size of your text is best. One thing to note here is that, in CSS, the line-height property will take a value without a specific unit, which makes sure the line height is always relative to the size of the text in question. So, avoid line-height: 1.5em and use line-height: 1.5 instead.


This tip barely scratches the surface of typography on the web, but it’s a start. Get these basics right and your text will be comfortable for the majority of people to read, and the more comfortable people are reading your content the better!