Nate Koechley

1) Non-semantic markup (endless divs, tables, etc)
2) onclick=”function()”
3) CSS classnames or ids named “redtopnav”
4) Font tags!
5) Tables used for layout
6) Over 2 CSS or 2 JS files
7) Images for headings instead of just using some good CSS & default fonts
8) Expressions to replace all png’s in a page with gifs (I’ve seen it!)
9) Content that is inaccessible to screen-readers or search engines (display:none; or heavy JS without graceful degradation)
10) 100% Flash sites. Most of the time only a small part of the site really needs to be in Flash.
11) Un-bookmarkable content. (No use of browser history management)
12) A general lack of LSM (Hard to quantify, but you know it when you see it)

I look forward to seeing the list!

-100 points for mentioning this site works with only browser X ;)

But seriously here’s what I’ve seen across the table in general,

1. -5 points for using divs or tables everywhere instead of using the appropriate paragraph, header, table tags where they make sense
2. -5 points for using the same color for visited, active links creating a confused user experience
3. -2 points for using images without the alt attribute, and an additional -3 for using them as submit buttons (again without an alt attribute)

I really like the concept here. I’ve always wondered about the same kind of thing, but always gave up on the “additive” approach. There’s just too much to do, and it’s so easy to forget or overlook some of the really fine-grained aspects.

However, there’s definitely a minimum bar of things not to do that makes a site usable in the technical sense of the term. I do think a significant part of it should be the browser-grading. It amazes how many “professional” sites for Fortune 500 sites don’t work in Safari.

Looking forward to see where this goes…

I too like your idea here. In particular talking about font resizing. many modern sites, even those built to web standards often don’t work well with simple resizing. A real annoyance for me!

I wonder if it is worth you creating an extension to Firebug, similar to how you guys provide the excellent YSlow!

Maybe this extension can be configurable to
a) allow additional factors to be added/removed by the user
b) allow scores to be modified by the user to suit their needs/preferences.

That would be quite a good code check. Of course, there will be some things that are quite subjective and not possible to detect properly through software alone, but maybe some things are useful to encode this way?

You should limit this to five criteria. Just five. If you can’t get those right, you’re in the wrong business. (But you’re probably doing better business than we are.)

Tables for layout is a gimme. demerit=–1 for tables=n, –2n for tables>1.

You have to be careful with the TABLE judgment. You’ll want to test for a TABLE that is the first and only child of the BODY element and for TABLEs that are descendants of other TABLEs.

Single TABLEs which exist within the content are perfectly acceptable, of course, but it is also possible to have a valid page that contains a semantic TABLE that is a direct child of the BODY (for instance, in the event that someone is just making a basic page with no need for divisions). In that case, however, it is likely (though not necessary) that the TABLE would have other block-level elements as siblings and the TABLE would (probably) not be the first element in the BODY (being proceeded by a heading of some sort or at least a paragraph).

In short, testing for abuse of TABLEs is a tricky undertaking. You may be best running a test to look for nested TABLEs, which _would_ be a layout hack.

@Ryan – great list. All of those belong on the final list.

@Gopal – thanks especially for the same-link-color one. While bordering on design, it’s important and sometime the result of poorly ordered CSS rules.

@Garrett – thanks for the “additive” word, that’s exactly right.

@Anup – great idea to make a tool of it. I’ll definitely consider that, or perhaps once I publish the list maybe somebody in the wild can take a crack at it.

@ Mr. Clark – solid advice to keep it lean. Thanks for that.

@Aaron – very good point, and some clever suggestions there for how to create a more viable test.

Thanks everybody! I’m glad you liked this idea, and I thank you all for your input. I’ll be writing more about this, so stay tuned and lets keep the converstation going.

thanks,
nate

Additional stuff I’d like to see on that list (in random order):

1. ‘href=”javascript:*”‘
2. Any transitional (like ‘font’, ‘bgcolor’, ‘target’, etc) markup.
3. Any ‘*frame’ element in the markup.
4. Transitional DOCTYPE.
5. Frameset DOCTYPE.
5. Huge lumps of inline JavaScript (should be shoved out to its own .js file)
6. Use of ‘document.write()’.
7. Use of ‘window.open()’.

- Using GET (as in links) to initiate a state change (as in delete or even logout)
- Requiring cookies
- Trying to forbid to view the page source

Maybe this is an obvious one and/or slightly off topic from this discussion, but I spent a lot of my early career maintaining templating systems designed to deal with these sorts of issues: It really bugs me when a website doesn’t have consistent headers/footers/navigation. Many websites out there still think of (and build) their site as a “collection of discreet pages” instead of a _homogeneous system_ that interacts as such. As a result, it’s pretty obvious when a website uses, for example, a cut-&-pasted header on multiple pages where the copies end up getting out of sync over time. This is obviously bad from a coding standpoint, but more significantly results in a negative and sometimes jarring user experience.

* 2nd on Dennis’s recommendation that requiring cookies is a problem — and ideally, the product would rewrite all URLs . . .

* All functionality show be exposed without requiring JavaScript…

Here’s the two rules I thought of while sitting in the Y! cubicle:

Check CSS for any occurrence of position or float. If they’re not there, the site uses table layout. (If they ARE there, the site might till use tables, though).

Check for empty elements. (  counts as empty)

Oops. Last line should read

<p> &nbsp;</p> counts as empty.

@Ryan:

I don’t think you should be subtracting for onclick’s on elements, especially for high performance sites. Attaching at DOM0 will always be faster than attaching to elements unobtrusively. While it’s idealistic, it’s not always practical.

Also, putting limits on JS files isn’t always going to be a great idea. While you’ll gain performance with less HTTP requests by concatenating your JS files, you also run a risk of hitting an error in your JS file; and when that error is hit it means the rest of your JS file won’t be parsed and won’t run. It’s a bit of a balancing act.

@Nate: Good idea though, you should post a follow up list.
-1 for no print stylesheet
… also I have a pet peve of blah

-1 for using spacer gifs
-1 for smart quotes
-2 for excessively large images
-1 for using the same title on every page of the site
-1 for missing shorthand opportunities like:

.foo{
margin-top:10px;
margin-right:10px;
margin-bottom:10px;
margin-left:10px;
}

These always get me:
- onclick=”javascript:someFunction();”
- a href=”javascript:window.location(someUrl)”

Speaking of, Nate – I had a related question for you related to fonts.css. I’m curious why you prefer to use the *property selector as a CSS filter for IE, rather than using IE’s conditional comment mechanism?

There’s been a lot of debate about Conditional Comments, CSS hacks/filters, and the like – and just was curious about your opinion.

-AP