Microsoft added many features to Internet Explorer over the years. Several revolutionized the web forever (XMLHttpRequest, the DOM, XML tools, font embedding, browser add-ons). Some never caught on. Some were truly awful.

The team intends to remove several of the less-successful legacy features in IE10 (perhaps they read #7 in 10 Ways Microsoft Could Make Us Love IE Again?) I suspect you’ve never coded XML Data Islands and Element Behaviors, but you’ve almost certainly used Conditional Comments. They’re about to disappear from IE forever.

Conditional Comments 101

Ensuring you web site or application works in all browsers is tough. It’s made particularly difficult when you have to support older editions of Internet Explorer. IE6 was released in 2001, IE7 in 2006, and IE8 appeared in 2009. Whatever your opinion of Microsoft, it’s unreasonable to expect a 10 year old browser to render the same as Firefox 5 or Chrome 12.

Web developers are particularly scathing about IE6. Many months are spent building fantastic web sites and applications only to find they break in IE6 at the eleventh hour. Fortunately:

  • IE6 bugs are well-documented and it’s possible to overcome the majority of issues — especially if you test early and often.
  • Microsoft provide Conditional Comments so developers can add custom CSS and script fixes which target a specific version of IE.

Examine the source of almost any HTML5 page and you’ll find this code in the head:

<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>

It loads a shim in IE8 and below which allows the developer to style new HTML5 elements such as header, article, and footer. It’s not required in IE9 and other browsers with native HTML5 support — they ignore the script.

Conditional Comments are incredibly useful but, personally, I always felt a little uncomfortable using them:

  1. They smell a little like browser sniffing — which stinks.
  2. They’re rarely necessary. The majority of IE6 problems can be solved with a display:inline; here or a position:relative; there. While competing browsers don’t require those properties, they don’t have a negative impact other than a few bytes of extra bandwidth. I prefer my CSS properties in one place rather than distributed between two or more files.
  3. Conditional Comments are abused. I’ve had the misfortune to work on systems where developers created three or four separate stylesheets which targeted individual browsers. Simple property updates required changes to every file.

Why Remove Conditional Comments?

IE8 is normally well-behaved and you’ll only require the HTML5 shim (see above). With a few CSS3 exceptions, IE9 renders as well as any other browser. Hopefully, IE10 will catch-up — or even overtake — Firefox, Chrome, Opera and Safari.

Conditional Comments are not required. There’s no need for “[if IE 10]“ because pages will render (mostly) the same in all modern browsers.

That said, it’s not the end of feature detection and progressive enhancement. Not every browser supports CSS3 transformations, web sockets, geo-location and client-side storage. Even with support, the user can often disable or refuse permission for an operation.

In addition, Conditional Comments will not disappear from IE6, 7, 8 and 9. You can still target those browsers should the need arise but it will become less necessary over time.

I applaud Microsoft’s decision. It’s a bold move since they could have easy kept Conditional Comments and I suspect its removal will horrify some developers. However, the company is adhering to its “same markup” philosophy and ensuring HTML, CSS and JavaScript just work regardless of the browser or version.

It’s the right thing to do. Let’s hope the demise of ActiveX, Compatibility View and the old IE7 toolbars won’t be too far behind!


Web designers and developers need techniques that work now while keeping an eye on what lies ahead. To do that, I’ve had one focus in every workshop I’ve taught over the past seven years: getting the best real world solutions for creating accessible websites and applications into the hands of developers and designers.

What do I even mean by real world? It’s very simple: Accessibility doesn’t and shouldn’t exist in a vacuum. The real world is messy. It isn’t black and white but every shade of grey in between. This applies to accessibility but also to our craft in general. We have to make compromises. We have to make choices. We have to change tactics mid-stream. And we have to have it finished yesterday.

And that’s why we focus on Real World Accessibility. You need to know what works now so that you can make informed decisions when you’re implementing modern web technologies. For the last two years, we’ve focused on Real World Accessibility for HTML5, CSS3 and ARIA—the workshop we’re bringing to Australia this month.

In preparation for the @feather Tour Down Under 2011 (I’m @feather on twitter) we crafted a page highlighting the content and details of what you’ll get. It isn’t the first HTML5 site/page we built, but we wanted to do something that created a unique design, was accessible, and gave us an opportunity to test out a few modern techniques for web design and development.

Every time we build something with HTML5, we get a chance to take a closer look at how accessible it is right now and we get a glimpse of what accessibility will be with new technologies.

HTML5 Semantics

I’m a fan of the new semantics that HTML5 brings us, for the most part. It opens new doors for us—authors around the world are excited to use the semantically sound elements that were introduced in HTML5.

And everyone knows that foundation of accessibility is semantics, right? Right.

So what happens when you combine a reasonably semantically rich language like HTML5 with browsers and assistive technology that was written before the semantics of HTML5 were even considered?

Nothing. And that’s the problem.

The advantages that the semantics of HTML5 bring to us are not really the boon to accessibility that they should be—yet. (To follow the development of which HTML5 elements are fully exposed by browsers and pass through to the accessibility APIs of different operating systems, be sure to check out HTML5accessibility.com.)

Accessibility continues to evolve in HTML5. There’s a team at the W3C dedicated to HTML5 Accessibility. And while accessibility for HTML5 continues to develop, I’m going to do my very best to ensure that what we’re doing for accessibility isn’t just about what will work in the future, but also about what works in the “here and now.” Why? Because we have “support” for HTML5 in browsers now. And that means that people are going to use it now. Which means it needs to be accessible now.

Here’s the real world situation with HTML5 accessibility as of this writing:

  1. We can use the new elements (article, section, aside, header, footer, nav to name a few) in our websites and apps right now.
  2. We can trick browsers that don’t natively understand those elements exist by using the HTML5 shiv. Yes it uses JavaScript and no, that’s not a reason not to use it. Yes, you need to consider the “JavaScript off” scenario, but we’ll talk more about that later.
  3. We must know that the semantics of HTML5 are NOT expressed or interpreted right now by existing assistive technologies. That’s okay—support will be coming, but it will take some time.
  4. While we’re waiting for support for emerging technologies such as HTML5, we need to find solutions that work now.

Web Content Accessibility Guidelines

I’m happy that we’ve moved on from WCAG 1.0, but I miss one of its hallmarks: the Interim Solutions Guideline. That told us to:

“Use interim solutions.

Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly.”

Let’s be clear: I don’t like the specific interim solutions that were advocated in WCAG 1.0. These checkpoints were all about “Until user agents” allow for X or have the functionality to do Y, use these techniques. User agents now do those things, so we don’t need to worry about them with WCAG 2.0. They’re so unimportant I’m not even going to mention them here.

But the idea behind using interim solutions was all about recognizing that certain techniques may not have full support in older assistive technologies or browsers and that we must think about those scenarios.

And that’s the case with HTML5 right now.

So what “Interim solutions” can we use with HTML5 to help assistive technology understand the semantics?


ARIA (Accessible Rich Internet Applications) is a technology that is used to help specify programmatically what web a user interface component (or “widget”) is more clearly, so that assistive technologies can provide more meaning to its users.

It is often referred to as a “bridge technology” —in that it helps us bridge the gaps between the past, the present and the future. In short, if we have an existing legacy web application that uses older markup and coding practices, we can help make that more accessible by applying ARIA attributes to the markup without rewriting the entire application with more modern languages.

Here’s how ARIA helps.

Consider this Google Maps implementation: http://examples.furtherahead.com/aria/slider/index-3.html


Note that we’ve used a custom set of controls on the map that allow for excellent keyboard accessibility. We’ve also implemented a custom slider control to replace the standard Google Maps control.

We don’t have a native slider element in HTML (at least not at present), so we built the slider with HTML, CSS and JavaScript such that it approximates the visual appearance and functionality of a slider control. The problem is that when we do so, we’re really creating a complex user interface component that is comprised of semantically meaningless divs, spans, images, links and buttons.

  1. For any complex user interface component, we need to know three basic pieces of information:
  2. What is this thing? (its role)
  3. What general characteristics does it have? (its properties)
  4. What can you tell me about it right now? (its state)

The whole is greater than the sum of its parts; taken together, those divs, spans, images and links create something more (a slider). ARIA lets us precisely specify the meaning of the whole so that assistive technologies can better understand the whole instead of breaking it down and trying to understand its individual components.

Traditionally we might have used markup something like this:

<a href="#"

The link gives us a focusable control that we can use for the slider’s “thumb” that will slide along the rail. The link text tells us the current zoom level (11), which is also displayed on the screen. We’d use a foreground or background image for the “rail” to make it look like a slider, and then we’d apply the appropriate JavaScript to allow us to  manipulate the thumb with the mouse and they keyboard.

To assistive technology though, this is just a link with some text in it. There’s no indication of what the link is about or what it does.

How can we make this better? We add some ARIA attributes:

<a href="#"
      aria-valuenow="14" >

The markup is fairly simple. We did a few things:

  1. indicated a role for the component (role="slider"),
  2. used aria-orientation="vertical" to specify that it is oriented vertically in the page, and,
  3. added several properties to that slider (aria-valuemin="0", aria-valuemax="17",aria-valuetext="14", and aria-valuenow="14").

When we use JavaScript to change the position of the thumb on the rail we also change the value of aria-valuenow and aria-valuetext to match the zoom level. The ARIA properties are updated, and provided we’re using the right pieces of assistive technology, we get the appropriate announcements or interaction with that interface component. A screen reader user, for example, will hear that the user interface component is a slider, and they will hear values being read out as the value changes in response to moving the thumb along the rail.

This is what ARIA gives us: the ability to provide better programmatic accessibility for complex user interface components. There’s a lot more detail to it, but that’s ARIA in a nutshell.

Now, then … I told you that to tell you this.


Remember we talked about the idea of Interim Solutions? That’s where ARIA and HTML5 come together.

ARIA has decent support in assistive technology. It isn’t perfect, but screen readers and magnifiers and other technologies are much further along in supporting ARIA than they are supporting HTML5. Why? Quite simply, even though ARIA is still “new,” it is older than HTML5. Assistive technology vendors have implemented support for certain parts of ARIA, and that support continues to grow.

Because of this level of support, we can add ARIA to give us some of the semantics that HTML5 should give us, but isn’t supported in or exposed to assistive technology just yet.

We use ARIA to complement the semantics of HTML5 in the sites that we build. We relaunched our accessibility focused site Simply Accessible in October of 2010 and defined a number of ARIA landmark roles that help give meaning where it can’t be delivered via HTML5 yet.

We added role=”main” to the main content on the page that is also marked up with HTML5’s <article> element. We used role=”complementary” on the <aside> element for the related content in the sidebar. And we used role=”navigation” on the <nav> elements at both the top and the bottom of the page.

See how it works? We are still using HTML5’s elements, but we’re supporting that with ARIA for those assistive technology and browser combinations that don’t “get” HTML5 yet.

We consider things in this order:

  1. What is the most semantic HTML5 that we can write to solve a problem?
  2. How can we convey as close to the same meaning with ARIA for technology that doesn’t understand HTML5?
  3. How can we convey as close to the same meaning for technologies that don’t understand either of HTML5 and ARIA?

Let’s wrap this up with one final example.

Figures in Web Pages

In a recent article Accessibility and HTML5 Block Links I talk about some of the issues that the block link structure creates with screen reading technology. In that article I use an HTML5 figure element to express the relationship between the image and the caption that is below it:


      alt="Screenshot of block links with Voiceover on the Mac.">
<figcaption id="figcaption1">
<strong>Screenshot</strong>: We use block links on the promo page...
In other screen readers, parts of the link aren’t read at all.

This structure creates an explicit relationship where it didn’t exist before. The parent <figure> element contains a <figcaption> element with a sibling <img> element. This HTML5 structure formalizes what people have been doing for years — placing an image in the page and including a paragraph of text after it in the markup.

How does this work for a browser and assistive technology combination that doesn’t understand HTML5? Well, a browser that doesn’t understand an element just skips that element. So when we don’t have full HTML5 support, we fall back to the association by proximity: the image and the paragraph are siblings in the source code, so they must be related.

What can we do, though, for assistive technology that understands ARIA, but not <figure> and <figcaption>? We can create a programmatic association by adding the aria-describedby attribute:

      alt="Screenshot of block links with Voiceover on the Mac."
<figcaption id="figcaption1">
      <strong>Screenshot</strong>: We use block links on the promo page...
      In other screen readers, parts of the link aren’t read at all.

Now there is a stronger association than just having the two pieces of content related by proximity, created by adding ARIA. The value of the aria-describedby attribute does just what you think it does: it contains an id value of the node in the page that describes the content. The detailed description of the <img> is provided by the node with the corresponding id—in this case, the <figcaption>.

What about the case where we have no HTML5 or ARIA support? We fall back to the age-old method of association by proximity: the image and the description are right next to each other in the code.

And that’s Real World Accessibility. It works now and will work better in the future.

Working through these kinds of scenarios is a pragmatic way to learn about Real World Accessibility, and these are exactly the kinds of scenarios we explore—in about as hands-on a way as you can imagine—in our full-day workshops. If you’re in Australia, you can register today, otherwise keep a look out for when we’re in your part of the world.

And in the meantime, let me know what you think about all this.

Hello again and welcome to episode eight of the Design Festival podcast. This week with web standards advocate and champion Derek Featherstone of FurtherAhead.com and most notably WebStandards.org . Derek is a teacher, speaker, writer, developer, designer, and strong proponent of accessibility and web standards.

More here:
DesignFestival: Design Festival Podcast #8: Web Standards with Derek Featherstone

compass image

Anybody who’s built a website of any size knows how quickly CSS can get out of hand. Style sheets can grow bloated and lengthy, making it difficult to find things, introducing redundancy and producing an end product that makes code maintenance tedious. Let’s face it — CSS is not very well-designed.

Over the years, a number of solutions have cropped up that attempt to deal with these problems. One of the most popular is the CSS framework, COMPASS.

Below, we’ll give you a quick introduction to how COMPASS works, and some tips on how to make it work for you.

What is COMPASS?

COMPASS is an open source CSS authoring framework written in Ruby that attempts to fix a lot of the shortcomings of CSS. It also streamlines development by providing a number of utilities and tools to make writing your CSS files easier and faster.

Those features include:

  • Support for variables and mixins.
  • SASS-style nesting of CSS rules.
  • Helper functions for images, fonts, colors and more, including mathematical calculations.
  • Flexible tools for ensuring cross-browser compatibility and graceful fallback states.
  • Integration of a Blueprint module, including several default styles for rapid prototyping and styling commonly used elements.

With all that and dozens more tidbits to offer, COMPASS provides a robust authoring environment for CSS creation that automatically monitors your code as you write it, compiling it down to pure CSS for use on your site. So while the COMPASS gem is needed for authoring, your website needs no special software or libraries to display CSS written in COMPASS.

How Does COMPASS Work?

Now that we’ve gone over what COMPASS is and discussed a few of its features, let’s take a look at some of them in action. In this, we’ll use a few variables and a custom mixin, as well as an image helper and nesting to show how COMPASS makes it easy to reuse content throughout your CSS files.

$dark-accent:   #333;
$light-accent:  #eee;

@mixin default_fonts {
    font-family:    helvetica;
    font-size:      10pt;
    color:          $dark-accent;

#info_box {
    width:      400px;
    height:     300px;
    padding:    10pt;
    border:     1px solid $dark-accent;
    background: $light-accent;
    @include    default_fonts;

    input[type=button] {
        background:  image-url('button.png') top left repeat-x;
        color:       #fff;
        font-weight: bold;
        border:      none;

Here you see that we’ve set up a couple of variables (dark and light accent) which we use in the mixin, in addition to the CSS rules for our info box.

Next, the mixin itself contains the rules for our default fonts. After that comes an example of how nesting works. The rules for our input button, in this example, only apply to those found within the info box.

Finally, the image URL helper here is used to generate the output for the background image, so we don’t have to type the full image path each time (path information is defined in a small config file that sits in the root directory of your project).

Now let’s take a look at the COMPASS-compiled output:

/* line 10, ../sass/demo.scss */
#info_box {
  width: 400px;
  height: 300px;
  padding: 10pt;
  border: 1px solid #333333;
  background: #eeeeee;
  font-family: helvetica;
  font-size: 10pt;
  color: #333333;
/* line 18, ../sass/demo.scss */
#info_box input[type=button] {
  background: url('/images/button.png') top left repeat-x;
  color: #fff;
  font-weight: bold;
  border: none;

As you can see, the mixins become included, variables substituted, image URLs generated, and inheritance is determined via the nesting. When generating the CSS, COMPASS also includes comments that clearly show us where each element is defined in its corresponding CSS file. If there’s an error at the time of generation, COMPASS will drop a helpful stack trace right into the CSS file where the error occurs.

At first glance, the original COMPASS code may look more verbose than the generated CSS output, but when you consider that those variables and mixins can be used throughout your entire project, you begin to see the advantages. COMPASS all but eliminates the need for adding presentational classes (e.g. “align-right” or “big-text”) without making you constantly repeat yourself. In addition, it’s feasible to completely change a color scheme for an entire project simply by updating a few variables and perhaps changing an image path or two.

This is only a small example of the power and flexibility COMPASS offers, but you can begin to see its amazing potential.

Where to Go From Here

If you’d like to learn more about COMPASS, you can check them out at compass-style.org. The documentation is particularly well done.

Keep in mind that COMPASS uses SASS and Blueprint, so you may want to read up on those as well.

You’ll also need a working installation of Ruby and RubyGems to install and use COMPASS.

Finally, we recommend taking a look at the Setup & Install Guide on the COMPASS website.

More About: coding, compass, CSS, dev & design, framework, web design, Web Development

For more Dev & Design coverage:

templates image

Over time, every web developer gathers a collection of tools — useful libraries, code snippets, reference materials and images that get re-used over and over. They make life easier by shortening development time and handling common, often mundane tasks. This frees up time and brain power for more complex tasks.

In this post, we’ll take a look at a small collection of boilerplates, templates and resets that you can incorporate into your workflow. They simplify the process of setting up a new project by providing a clean slate and often useful utilities.

1. HTML5 Boilerplate

Arguably the most popular HTML5 “starter templates” out there, HTML5 Boilerplate aims to provide a cross-platform, future-proof HTML/CSS and JavaScript base template for web development.

In addition to cross-browser normalization and graceful degradation, Boilerplate also includes more advanced options for caching, JavaScript profiling, unit testing and handling of AJAX events.

2. Boilerplate Mobile

If you’re doing mobile app development, you may also want to check out HTML5 Boilerplate Mobile; a specialized version of the main boilerplate with additional features and functionality specifically for mobile web development.

Boilerplate Mobile includes additional code to assist with viewport optimization, improved font rendering, quickly adding home screen icons and cross-platform support across a number of mobile devices.

3. HTML5 Reset

HTML5 Reset is a more lightweight base template that gives developers a clean slate to work with while setting and taking care of some cross-browser issues, such as CSS inconsistencies and IE-specific CSS rules.

The HTML5 Reset developers also provide a blank WordPress theme using their system, which can be uses in building custom WordPress templates from the ground up. Both flavors of the reset provide clean, semantic code and tons of flexibility.

4. YUI2 CSS Reset

Yahoo’s YUI2 CSS Reset is a set of drop-in stylesheets to begin your next project. The reset eliminates cross-browser inconsistencies in element rendering so that you can explicitly declare your own rules for these elements.

A useful tool in ensuring cross-browser design consistency, the reset is fully documented with lots of great examples and large community backing.

5. Eric Meyer’s CSS Reset

An oldie but a goodie, Eric Meyer’s CSS Reset was one of the first templates to make the rounds and gain popularity. This popular reset has now been updated for HTML5.

Designed to be generic in nature, this stylesheet gives you the bare minimum, but in some ways also provides the most flexibility. It removes default rules set by the browser, eliminating inconsistency and leaving you with a completely clean slate to work with. All browsers are on even footing.

6. Starkers

Starkers is a “completely naked,” bare-bones WordPress HTML5 starter theme. The theme gives you a blank canvas to build upon, removing unnecessary code and providing clean, semantic markup for WordPress as well as support for menus, dynamic components, custom sidebar widgets and more.

Starkers also implements the YUI2 CSS Reset mentioned earlier, so all of the setup is done for you. All you have to do is start building.

7. Roots

Roots is another WordPress starter theme that takes things just a bit further. Built upon Starkers, HTML5 Boilerplate and the Blueprint CSS framework, Roots gives you a robust set of tools for rapid theme development while incorporating tried and true technologies for ensuring cross-browser support for CSS and HTML 5.

Other Roots features include some bundled jQuery plug-ins (Cycle, Fancybox, etc.), an SEO-optimized robots.txt file and support for easy integration of social media content from Facebook and Twitter. Roots has a larger footprint than some other “blank slate” WordPress themes but if you’re interested in quickly building large, robust, and full-featured WordPress sites, it’s definitely worth a look.

More About: boilerplate, CSS, dev & design, HTML5, resets, template, web, Web Development

For more Dev & Design coverage:

The Web Designer Series is supported by Wix.com, a free Flash online builder that makes website creation a breeze. Click here to create your own website now.

There are plenty of Firefox add-ons at your disposal that can extend the browser’s core functionality. The types of add-ons you’ll encounter have a wide range of utility, from productivity tools that monitor the amount of time you spend on the Internet, to social media tools that conveniently give you in-browser capabilities for using popular services such as Twitter and Facebook.

The Firefox browser is a popular choice for web designers, and there are plenty of add-ons that can make the day-to-day work of web design significantly more efficient and fruitful. Here are 10 highly recommended, top-notch Firefox add-ons for web designers. Let us know what other Firefox add-ons you use in the comments.

1. Web Developer

The Web Developer Firefox add-on is a huge suite of web design tools packed with massively useful functions that will help web designers perform tasks more efficiently. By default, it displays as a toolbar towards the top of the browser, presenting you with various menus such as CSS, Resize and Cookies.

Whether you need to inspect the CSS of page, discover information about a webpage (such as seeing all the alt attributes of images on the page), quickly validate a web design for W3C compliance or measure design elements, Web Developer will likely have a convenient tool for you.

2. Firebug

Firebug is such a popular web design/front-end web development Firefox add-on that there are actually add-ons for it (see no. 5). And if you were to ask any web designer or web developer what Firefox add-on they can’t live without, chances are he’ll say Firebug.

Firebug is an open source add-on that gives web designers powerful tools for inspecting and debugging a web design. It can help you figure out what CSS styles affect certain elements (in case you’re having trouble with a style rule that doesn’t seem to render properly), inspect the document object model (DOM) to learn about the structure of the web page, determine attributes such as color, width, height of HTML elements and much more.

The extension can take a while to learn (trust me, it’s worth the time), but the creators have some helpful documentation to get you started.

3. MeasureIt

This Firefox add-on has a single purpose: It gives you a ruler that you can use on any web page for measuring items. Since web design critically relies on the proper sizing of design elements, this is a valuable tool to add to your collection of Firefox add-ons.

4. ColorZilla

One thing that web designers frequently work with is color. This add-on includes a color picker (much like the one you see in Photoshop) and an eye dropper tool so that you can sample and identify the colors used on any web page. A similar Firefox add-on to check out is Rainbow Color Tools.

5. CSS Usage

CSS Usage is an extension for Firebug (thus requiring you to have Firebug installed) that uncovers unused CSS style rules. It works by identifying the CSS you use and don’t use, pointing out what unnecessary parts can be removed to keep your CSS files as lightweight as possible.

6. Page Speed

A website’s speed is important for usability and the user experience. Research has shown that website visitors hate slow websites, so you should do the best you can to design sites that are lightning fast.

Page Speed is a browser extension (for Firefox and Chrome) developed by Google that analyzes a web page and tells you where improvements can be made to increase the site’s speed. It’s a great tool for
testing a web design’s ability to render fast. Alternatively, you can use Page Speed Online, which is a web-based version of the add-on. You can also check out YSlow, which functions similarly to Page Speed.

7. HTML Validator

This nifty Firefox add-on helps to make sure that you’re writing well-formed HTML. It checks your markup for standards compliance, and if it catches anything that doesn’t cut it, the add-on tells you why so that you can update the code.

8. IE Tab 2

Web designers are always concerned about the cross-browser compatibility of their work. IE Tab 2 is a Firefox add-on that allows you to view any web page using Internet Explorer without leaving Firefox. All you have to do is right-click on a web page, and then choose “View Page in IE Tab” in the contextual menu.

9. Screengrab

Taking screenshots in the browser is a common task for web designers. Screengrab is a simple tool for taking full-page or partial-page screenshots. You can copy the screenshot to your clipboard, or save it to your hard drive as an image file.

10. SEO Doctor

Search engine optimization should begin in the design phase, when the site’s HTML is still malleable and open to change. SEO Doctor is a convenient tool for checking any web page’s SEO.

SEO Doctor gives you a score between 0 and 100% and highlights areas in the web page that can be optimized for search engines. One neat feature is that you can export the data for spreadsheets for further analysis and logging.

What other add-ons do you use? Let us know in the comments.

Series Supported by Wix.com

The Web Designer Series is supported by Wix.com, which brings amazing technology home to everyday people. Discover the amazing simplicity of its online Flash builder and enjoy creating beautiful websites with powerful drag and drop interface.

More Design Resources from Mashable:

A 12-Step Guide to Fostering Your Creativity
8 Powerful & Inexpensive Desktop Design Apps
HOW TO: Get Started with the Less Framework
8 Essential Web Typography Resources
HOW TO: Turn Your Foursquare Data Into an Infographic

More About: CSS, Firefox, firefox add-on, firefox plugin, html, web design, web designer series

For more Dev & Design coverage: