As someone viewing websites on the web, ad-blockers filter out adverts for “enhancements”, and a bunch of flashing, ugly advertisements. Not only this, but ad-blockers can help protect you from potentially sneaky and malicious code.

This is why one of the most popular downloads for Firefox is an ad-blocking extension.

However, have you thought about the reverse? What about the effect ad blockers have on your website or the sites you design for clients?

Is my coding style or design choices limiting what’s viewable to visitors because it’s being incorrectly identified as advertising content by ad-blockers?

Choose Your Class and ID Names Carefully

You may reason, “I don’t have to worry about ad-blockers because I don’t have any advertisements on my website”.

But do you really have to reason for concern?

While you may not have a single ad on your site, the names you give your classes and ID’s matter.

Classes and ID’s containing keywords like banner, ban, ad, advertisement, etc may get flagged incorrectly by a visitor’s ad-blocking plugin.

Important sections of information could never appear on the screen because of this.

Avoid:

<p class="panel banner" id="bannercontent1">Real content. Not an advertisement. But still blocked.</p>

Better:

<p class="panel section" id="section1">Real content. Not an advertisement.</p>

Remember, elements with classes and ID’s that contain any filtered keywords run a high risk of being blocked. In theory, an ID or class named ‘bandaid‘ may get filtered as an ad.

Safe Choices For Classes and ID’s

What are safe choices for classes and ID’s?

While there’s no way to know exactly what custom keywords people will add to their blocking list, a good rule of thumb would be to look at the keywords that are contained in the default filter list. This list can usually be found in the ad-blocking extension’s settings.

Avoid using classes or ID’s that contain any of the keywords on the filter list.

Choose Your Images Carefully

You should also pay attention to your choice of images.

Since ad-blockers cannot actually view the contents of an image, they identify advertisements by relying on both the image filename and image dimensions.

Image Filenames and Directories

Images that contain banners, ban, ads, advertisement, and so on in their filenames may very well get flagged as an advertisement and get removed.

You should also be aware of the directory names you choose. For example, using directories that contain words commonly used in banner advertisements are fair game for ad-blockers.

Image Dimensions

Your images’ dimensions matter. Images that have the same dimensions as common banner sizes run a high risk of getting wrongly blocked.

Common ad sizes (in pixels):

• 728 × 90
• 468 × 60
• 234 × 60
• 180 × 150
• 125 × 125
• 88 × 31
• 120 × 600
• 160 × 600
• 336 × 280
• 300 × 250

Source: http://www.iab.net/iab_products_and_industry_services/1421/1443/1452

If Unsure, Test

If you’re not sure, download an ad-blocking plugin for your browser and test your design before going live.

In a press release Thursday (Dec 11, 2008), the W3C has promoted the new WCAG 2.0 Web Content Accessibility Guidelines into the current recommendation.

The new WCAG 2.0 Web Content Accessibility Guidelines (current W3C Recommendation) builds and expands on the previous WCAG 1.0 Accessibility Guidelines released several years ago.

The WCAG 1.0 and WCAG 2.0 Checkpoint Comparison is a great place to start if you’re already familiar with WCAG 1.0 and are looking to implement the new changes.

Building Sites With Accessibility in Mind

The nice thing about the new WCAG 2.0 checkpoint list is that it explains the reasons behind and benefits of each checkpoint.

It also explains how to meet these criterion, and also how to fail to meet them. This helps designers and developers to not just rigidly go by the letter of the recommendation, but rather, adhere to the intent.

I think this will make for much more accessible sites in the near future because it stresses building sites that meet the intentions behind the guidelines instead of just having checkpoints to meet.

What do you think of the new WCAG 2.0 Recommendation? Have you started using these on any of your sites?

Keyboard shortcuts are vital for navigating and performing various actions quickly, and are very helpful for designers when working on projects. Firefox has a keyboard shortcut for just about everything.

Unfortunately, finding and remembering them all can be difficult. Also, shortcuts differ slightly between Windows, Macs and Linux versions of Firefox.

Firefox Keyboard and Mouse Shortcuts

Fortunately, AccessFirefox.org—a site dedicated to showcasing accessibility tools and features in Mozilla Firefox—has a great list of Firefox keyboard and mouse shortcuts. You can filter shortcuts by operating system (Windows, Mac, Linux) or view them all at once.

Accesskeys Keyboard Shortcuts

Some websites use accesskeys to allow people with disabilities to access site navigation links by keyboard. This is a requirement for most sites in the UK.

View our list of keyboard shortcuts for activating accesskeys in all major browsers and OS’s. This list contains the keyboard shortcuts to activate accesskeys in Firefox, IE, Safari, Opera, Google Chrome, Konquerer and Epiphany in Windows, Mac OS X and Linux (Ubuntu).

On the previous version of this site, I used accesskeys for the main site navigation. However, because of no clear standards and the chance of interference with browser shortcuts, I decided not to include them in the current version.

Leave us a comment and tell us what Firefox keyboard shortcuts you use the most.

7. Use Outline:0

Another small one but useful for FireFox. The CSS element ‘outline’ is what drives the dotted border around links in FireFox. While nice for text links, it can make things look bad when you use image links. Use outline:0 to remove the dotted border around images used as links.

Firefox, IE and Google Chrome all provide visual cues to let users know when text and image links have focus—Firefox and IE use a dotted border outline, while Chrome uses an solid orange border. This is particularly important when navigating with a keyboard. Now I agree, they can look kind of ugly, but they serve a purpose.

What About Accessibility?

I don’t want to just use a blanket term like accessibility without getting into specifics. In this instance, I’m talking about accessibility from the standpoint of a person with vision who uses a keyboard to navigate links. This would include people who are unable to operate a mouse and who Tab their way from link to link.

Ordinary, when you Tab onto a link in Firefox, IE or Google Chrome and that link receives focus, the outline gives a visual indication of what link will be activated when you hit Enter.

And that’s the whole point: If you remove the outline around links (by using CSS or any other means), this seems to me a big accessibility issue; especially if you’re removing the outline from image links. Even if you provide a text link that does the same thing as the image link, will that be clear to your users?

Using outline:0 probably isn’t going to affect people with vision-related impairments, but we can’t forget about those who rely on the use of a keyboard for navigation. The bottom line is: Don’t remove visual cues from image and text links unless you plan on providing an alternate way of showing that they have focus when navigating with a keyboard.

Note: There is no default visual cue in Safari or Opera browsers when a link (text or image) has focus.