What's wrong with YOUR website - Part 1, Layout and Design

1.1 Fixed width layout

The most common reason so many websites are useless to me as a user, and can be blamed on two simple causes, laziness and ignorance. Net result is typically that the site is broken or useless on my netbook, and a tiny little stripe on my desktop. It most always means adding responsive layout is a pain, and if the user needs to zoom they quickly find themselves in the same boat of useless design as the netbook and tablet users.

Given the plethora of screen sizes and browser options, using design elements that require a fixed width, fixed height around content text, or fail to be deployable across multiple layouts/resolutions completely misses the point of HTML and the Internet!

A fluid or semi-fluid layout that adapts to the users screen, with the new 'responsive layout' concepts added atop it or the older 'msSwitchy' javascript assisted layout are vastly superior on every front, and take a much more 'content oriented' approach to development.

As such fixed width designs are 100% garbage. The only reason they've become so commonplace is laziness on the part of developers and 'designers' who don't know how to do anything besides painting pretty pictures in Photoshop generally don't know enough about usability, functionality or the Internet as a whole to be designing a blasted thing!

Anyone who asks "what width should I make my website" or says things like "860px" or "976px" have failed to grasp what a website is in such a grandiose fashion, they should do the world a favor and go take up something a bit less dangerous like macramé.

1.2 fixed metric fonts

Fonts declared in pixel sizes do not automatically expand for users that expect them to... LIKE ME. I've run the 'large font/120dpi' setting since Windows 3.0. Originally I did so as a kind of poor-man's anti-aliasing by simply running my displays one resolution higher than most people were comfortable doing on that size display. Displays have only increased in size and unlike some people I prefer not to sit with my face plastered 6" from the screen. Didn't your momma ever yell at you about that ruining your eyesight?!?

Both iterations of the Web Content Accessibility Guidelines -- from this point on refered to as the WCAG -- say fonts should be declared in %/EM, so they automatically adjust to the user's default preference WITHOUT having to dive for the zoom. Given how piss poor zooming is (particularly if combined with #1 above) in browsers (Opera being the only one that seems to even TRY to do it 'right') this remains fairly important, and will only become more so as screen resolutions continue to climb. Case in point the 27" 2560x1440 display I have has roughly 20% higher pixel density than my pair of 19" 1920x1200 displays. (evidenced by them being roughly the same physical height!)

Just as the layout should be able to auto-adjust to the screen width, it should be able to handle your content's font changing size without the layout changing. This is why px metric elements, particularly fixed height ones, are accessibility rubbish... and why a LOT of the things that fall into what I call "Non-web deployable" and "But I can do it in Photoshop idiocy" just lead to broken layouts and inaccessible design.

PX metric fonts should be used with an eyedropper behind things like image replacements for logos, and whenever possible should be as large a size as is reasonable. Otherwise, use %/em.

... and whoever it is out there saying there's nothing wrong with saying 12px or smaller as font-size, you need a good swift kick in the crotch!

1.3 Illegible color contrasts

Ever notice that certain combinations of colors are hard if not impossible to read -- like pure blue (#00F) text on pure red (#F00) backgrounds? This is due to a lack of contrast. Time and time again you'll see artsy/attractive design that's completely USELESS to visitors because you can't read a blasted thing. Again, WCAG to the rescue as they even provide you with a formula for figuring out how to avoid it -- and that formula pre-dates HTML since it was developed at the same time as the EGA card and Color Mac's when IBM, Microsoft and Apple did a joint study on usability that was passed on to the hardware built at that time.

The version found in the VGA specification is the easiest to implement for determining 'luminance' -- the difference between your background and foreground luminance determines if it's going to be legible or not. 50% difference is the minimum, 75% is the ideal, and above 90% can often seem too harsh to some people. (I've never had a problem with it, but I'm weird)

The formula is:
Y = 29.9% red + 58.7% green + 11.4% blue.

Notice this is NOT the formula paint programs like Photoshop use to determine luminance. Paint programs are designed for print media, even if we've been using them for screen for quite some time. As such they use the REFLECTIVE formula for luminance based on a CMYK colorspace -- this makes their luminance useless for displays, which are an emissive visual source. (Emits light instead of reflecting light). The above formula isn't just for emissive, it was created specifically for 24 bit color displays. (laughably the WCAG actually lists the reflective formula - but that's the W3C for you)

So let's take that pure blue on pure red... that's easy. 29.9% and 11.4% -- only 18.5% difference, so of course you can't read it! It's like Carlos Mencia gray (#DDD) text on a Antichrist gray background (#666)... If you plug each color channel into the above formula you get 221 and 102 on a scale of 0..255... the difference is 119, which is only 46.7% difference, just under our 'minimum' -- darken the bg to #555 or increase the text to #EEE and you're golden.

One nice side effect of doing this is the result also tends to be 100% legible to the color blind.

The issue has only become more pronounced with the use of "font" smoothing technologies that are designed to remove the "jagged edges" from fonts using a technique called Anti-aliasing. Unfortunately this often makes the font renderer blur or even do two pixels at half the intensity side by side as the single pixel the font says it needs straddles the edge of both "by the math". That's why WCAG 2.0 AAA works out to that 75% or more minimum.

1.4 Serif Fonts

There is an old typography study generally accepted as fact that serif fonts make text easier to read. IMHO this is completely true in PRINT, where you have either analog output (movable type) or high resolutions (300dpi or more) with which to render those extra teardrops, ears, spurs, stems and loops. No joke, those are actual names of serif type elements on a glyph!

But that falls apart miserably on screen devices where 'real world' a normal display is only around 75ppi (pixels per inch) a high resolution desktop display like your typical 24" 1920x1200 display barely touches up to 90 ppi... even my hot-shit 27" IPS at 2560x1440 only delivers 120 ppi. You could say that Apple's retina displays are paving the way, but that's for shorter viewing distances of more content per inch. There just aren't enough pixels in your typical 1/6th of an inch of display height on these devices for 16px or even 18px serif fonts to be well formed and promote legibility, much less the 14px or less a lot of people seem to be favoring.

A sans-serif font has simpler glyphs that are more easily hammered into pixel boundaries. They also typically lack elements that could overlap or be poorly rendered hampering the ability to recognize the shapes or even where one letter begins and the next ends, and just makes the renderering engine not have to work as hard.

That's why Serifs are for print, sans-serif is for screen. Now, I'm not saying you can't use serif fonts at all, just be sure if you do they are declared large enough (20px or more) and are not on your primary content that people might actually sit there and try to read.

The above four are the most common accessibility failings I come across on poorly designed and/or developed websites. A shame since a lot of sites with these failings are often genuine works of art... but people do not visit websites for the graphics you hang around the content, they visit for the content... and if your choices have made that content painful or even impossible for visitors to use, they are quite likely to simply go to some other website.

1.5 Overuse of Webfonts

The new sick trend'in "gee ain't it neat" site bloat, webfonts are seen by a great many as a wonderful thing... I have to say I'm not one of them. The majority of fancy fonts designers get all excited about are as a rule designed for print where higher resolutions allow for more complex shapes, but just as with serif fonts those fancier glyphs just cause legibility issues at the low pixel density of the average screen.

Font renderers also tend to handle webfonts differently -- the same font that looks great in IE might look like someone wiped their backside and smeared it on the screen in Opera or Firefox. What looks good on a Mac could look like trash on Windows and vice-versa, and don't even get me STARTED about the train-wreck that is the Freetype renderer used by the various "flavor of the week" Linux/BSD/Unix.

... and that's before we talk file sizes and memory overhead, where a typical 'clean' sans-serif type font lowballs around 50k -- two thirds the limit I'd allow for an entire site template (HTML+CSS+SCRIPTS+IMAGES) and can easily reach half a megabyte for more complex shapes. (Almost a megabyte if you include the SVG version of the font) -- completely unacceptable filesizes.

So as a rule -- My advice is to use them with an eye-dropper... and if CSS3/IE5 style webfonts are bad, don't even THINK about bloated broken inaccessible train wrecks like SiFR or Cufon. Honestly that I'm still coming across people building new sites trying to use something OTHER than CSS3 for webfonts is just mind-numbing.

Like any number of fancy effects, when it's new and trendy people throw it at everything with little regard for if it's useful -- when a subtle minimalist splash here and there can be much more effective.


  • elementals.js
    A lightweight JavaScript library focusing on cross browser support, ECMAScript polyfills, and DOM manipulation.
  • eFlipper.js
    An image carousel script using elementals.js
  • eProgress.js
    A JavaScript controllable progress bar using elementals.js. Based on the nProgress project that relies on the much heavier jQuery library.


Browse code samples of people I've helped on various forums. These code snippets, images, and full rewrites of websites date back a decade or more, and are organized by the forum username of who I was helping. You'll find all sorts of oddball bits and pieces in here. You find any of it useful, go ahead, pick up the ball, and run with it.