Keep contrast in mind when styling your text. Not everyone has perfect vision, and as we age our eyes take in less and less light. Light text on light backgrounds, dark text on dark backgrounds, and any text against a visually-cluttered background will be hard or impossible for many people to read.
When styling text you can use WebAIM’s Color Contrast Checker to make sure your text can easily be read by everyone.
Making something accessible does not mean making it boring, unattractive, or plain. This is especially true on the web, especially now. With tools like flexbox and grid we have the ability to create incredible layouts without compromising the underlying HTML.
If you’re looking for an example of a beautiful website with great accessibility look no further than 24 ways. Want another example? I encourage you to make it.
Here’s the thing; people hate filling out forms. The simpler you can make your forms, and the easier they are to use, the more people will fill them out.
Think about all the forms you currently have (or plan to create) and ask yourself: What is the bare minimum amount of information you need to ask for? The answer should line up with the fields your form has.
Have a bunch of optional fields? Get rid of as many as you can (and you can probably get rid of most of them). Make each optional field fight tooth and nail for its survival. Every form field, optional or not, makes your form that much more daunting and intimidating. If people see a form with ten fields they’re going to move on long before they realize eight of them are optional.
And if some of those optional fields make the cut, make sure they’re visually distinct from the required fields. It should be crystal clear to your visitors which fields they can skip. One of the most frustrating experiences on the web is spending the time to fill out a form and hitting submit only to be faced with an error message and a bunch of fields outlined in red.
Take a few minutes to put yourself in your visitor’s shoes and go fill out all of your existing forms from their perspective. Don’t use autofill or other fancy tools to fill out your forms; many people don’t use them or don’t even know they exist. Be honest with yourself: Do you find your forms frustrating? Do you find yourself getting bored while filling them out? Did the thought of doing this exercise sound like a drag? Imagine how your visitors feel! If you don’t care to fill out your own forms, why should anyone else?
The simpler and easier you can make your forms the better they’ll work, for both you and your visitors.
Sometimes it can feel like your website is always sub-par. Maybe it could be written better have better copy, be more beautiful, or have more accessibility features.
There are two things you have to keep in mind when you feel like this:
There will always be another thing you can do to improve your website (that’s why I’m able to write a new tip every day!). You could spend years doing nothing but making your website the best website it could possibly be and it still wouldn’t be perfect. Perfection should be viewed as a guiding light, not a destination.
Here’s the thing: Your website doesn’t need to be perfect, it just needs to be good enough for the majority of your target audience. If most people are having a good time when they visit your site, you’re winning.
Improvements are always welcome, but don’t get overwhelmed by what you’re not doing. It’s okay to put up a website that lacks features or isn’t as accessible as it could be. One of the great things about the web is that it’s a dynamic, ever-evolving medium. If most of your audience is having a good experience today you can work on making it a great experience tomorrow.
Don’t think of the tips on this site or the information you read elsewhere about improving your site as requirements. Instead, view them as guidelines that should be prioritized and implememented according to your unique situation and your audience’s specific needs.
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?
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 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.
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:
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.
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.
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!