Our site has been up for years, and all the while we have wrestled with accessibility and standards compliance edicts. One hopes we have never blocked the way to any user.

The need for some form of user experience had pressed itself into being. What best could one do? Please experience this site with scripts enabled, and then without. Are we learning?

Site

In the home page copy, instead of linking dates, try the terms that describe the linked page ("Coins & Currency Auction" rather than "November 9, 2007").

__________________
Los Angeles Web Design
Medical Website Design
Law Firm Web Design

There are four links to each upcoming event on the home page, of which the most prominent is text, as you describe. Not sure if you refer to right or left of page.

The link list at left is constrained to a few characters, so the date was, for me, the most obvious choice, and most consistent, as well. It fits well, and the links have title attributes that describe the day's event, accordingly.

The link list at right is for the most part, window dressing, but it also serves to point to all events in 2007. The past dates are rather vague, since the title attribute reads simply, 2007-10-13 (archive) or similar, which is purposely this way to avoid confusion. The hover text is graphical, and has no value, text wise. The reasoning for this choice is again consistency, and the date fits, whereas other text will be smaller, and harder to read against the random background images.

The main link is given added graphical support, with a link and mouseover text (graphical).

The keyword phrase is in the main link at page center, and occurs in the title attribute of the others, which is almost like spamming the phrase, and does come into question. Perhaps a member can demystify this elementary point?

The above notwithstanding, we must also bear in mind that the date s rather more important than the nature of the event. Antique enthusiasts are marking their calendars differently than tool and machine enthusiasts. Furthermore, in our case anyway, it is the date that sets each event apart, even in the way the site is structured. To this end, we have tried to adhere to a basic color scheme to match the nature of the event.

lots of images with no alt attributes. You're worried about accessibility? You're not learning from past mistakes.

At least you have a doctype, which is more than most sites posted here for review! And it validates!

__________________
amorphic8
http://www.amorphicmedia.com

On the home page there are seven img tags, all with alternate text. To what do you refer?

There are 25 css images on the same page, but as I said earlier, this is window dressing. All a screen reader sees is this:As you can see, there really is no place to insert alt attributes, and the title attributes provide as much information as is needed to point the way of the link. What's not accessible about that?

Our visitors don't spend their time on the home page, they jump into the event sections.

The entire site is rich with text and images, even while it is disjointed as any list would be. Some alt and title attributes were left empty (in the past) to save on load times, but enough information has always been available. With today's high speed steadily gaining a user base, one supposes that page size will become less of a consideration.

We are now populating title attributes on image links (thumb or text) whose anchors contain a rel="lightbox" attribute. This provides caption text to the dialog. The problem I'm having, though, relates to a question (or hint of one) above concerning repetition of text. In the case of text links that are lightbox enabled, the title text and text node are pretty much identical. Is this spam?

One supposes I should have suggested a deeper look into the site. The home page is not where we expect our visitors to spend much time. The purpose of the site is purely information, and as that is arriving constantly, though not always in the mostly timely fashion, we are forced to let the site evolve. Our regular users simply bookmark it and check back periodically to catch up.

Sadly, all events come and go, and all the work that has gone into preparing a section is more or less behind us. The net result is a site that comprises of nearly four years of recorded events, most of which have passed.

But this doesn't seem to stop the search engines from referring our pages and images, especially our images. None of our pages escape the serps, no matter how old, during any given period. This would indicate that there is a steady interest in pictures of old and unusual things that come with some form of description.

People just want to know, so we leave all our stuff there, and occasionally pass a little upgrade down the line to mimic some form of continuity.

But I guess my final question would be to amorphic8: What didn't you find accessible (beyond the home page, of course)?

The first thing I do when reviewing a site after scanning the home page is turn off CSS, then I turn of images.
When I turned off images, the photos in the center column which I assumed were <img/>s disappeared and were not replaced with alt text. I now see that those images are background images, as opposed to <img/> elements. I was incorrect to criticize them for not having alt attributes, as alt attributes cannot be put on background images, but my new question is why are they background images? They appear to me to be contextual as opposed to decorative (like the man white-washing in the top left corner), so it seems to me that they should be <img/>s, not backgrounds.

Upon inspection of your source code I noticed a number of empty title attributes and in places where the titles had values, the value was merely duplicative of the <a/> element's text node. The title attribute is not required and is useful for providing additional information. When using them duplicatively or empty, there is no value to them, so they are not necessary.
Duplicative titles from the masthead menu:
While there is nothing technically wrong about including redundant titles, there is the potential (an accessibility expert can say definitively) that a assistive screen reader may read the link text AND the title text, therefore reading the same thing twice and potentially confusing a visitor.

The code above from the 'coins and currency auction' page demonstrates the uneccessary empty titles and also a place where you failed to provide alt text. Additionally, I am a bit confused what purpose these links serve at all, as they go nowhere.

On a more general note, your CSS contains a number of redundant rules and your HTML contains many classes with no semantic meaning, presumably as hooks for your CSS.

It is good practice to use IDs and Classes as minimally as possible, and when using them, the names should be semantically meaningful.
is semantically meaningful, while is not.

If you take some time, you could probably eliminate many of your class names and ids and attach your style rules by cascading down to target elements through the parent. For example, instead of using this on your child <div/>s of , target the child divs in CSS by writing a rules like:
then use a single class on each child <div/>, if you must to attach the style info you now have inline. Really, only the border colors are different, so you could take much of the inline rule and put it in the CSS example rule above.

You can remove much unnecessary markup by attacking examples like this found throughout your code.

So while most of your code is not technically incorrect, your code is valid (at least the pages I ran against W3C validation), it demonstrates bad practice in a number of places, some of which could potentially interfere with accessibility and/or lead to confusion. Valid code is a good thing and a great start, but valid does not necessarily equal accessible.

I apologize that my first post, based on an incorrect assumption, wasn't very helpful; I hope you find this review more meaningful and helpful.

__________________
amorphic8
http://www.amorphicmedia.com

Thanks for taking a closer look, amorphic8. You raise some points that deserve attention and a little discussion.

I have a philosophy about alt attributes which may not go along with the letter of the recommendations: No alternate text if the image carries no meaning. The attribute is there, but empty.

The section containing the eight image segments is an example of meaningless images (though I could state the name of the coin, eight times). This set of links is intended as an optional in-page navigation to categories listed below the fold. In some cases they are never used, and I agree that the attributes, empty as they are, are superfluous.

Per your suggestion, this is what it looks like now:This way, the section can be skipped. When not in use, there is still the question of its value above the fold, one supposes for another design thread, but now that it's there, well, it's there. Pure window dressing. In my view, it's really not hurting anything.

This is not a high traffic site, our audience is quite select and within driving distance of our locale, and it's very unlikely that we get visited by users with screen readers, though I'd like to think even they can garner as much information as we currently have available.

The empty attributes are there, awaiting caption text in many cases, and in some cases it's very likely I just never got back to them. Being a hand coded site, there is always work to do, and as a solo hobbyist, my time is limited. My bad.

The duplicative text is a real thorn because now that we have Lightbox Plus and Descriptive Tool Tips added to the site, the duplicative text cannot be avoided. What's more, it's a tonne of work putting all of it in, and I would dearly love to avoid that, but now that the die is cast...

In the example you use, I'd have to agree with you, again, that it may render twice in a screen reader. I'm sure our site wouldn't be the first to do this. A person who spends all their time on the web aided by a screen reader is more than likely quite used to this. One supposes there are ways to suppress this level of verbosity if it becomes a problem.

It further comes down to tool tips. Are they a nuisance? Should they be avoided? What should the tool tip read?

I'm mostly concerned about how SEs will view it: Is it spam, or not? Can the robot determine that there is an abstract purpose for the title text; i.e., feature scripts?

A really convoluted example of repetition is the slide show pages. Here you will find description text in triplicate: Unordered lists in the flow, and in the <noscript/>, and array data in the Flexi Slide Show script. Each have their own purpose.

If styles are off, the list (id="longdesc") displays above the slide show, with links to jpegs. The main purpose is not to display as a list, but to supply link text to Google AdSense. Under normal conditions none of it is visible as it is positioned under the slide show.

If scripts are off, the noscript list displays, with links to jpegs. My question here is, does Google's AdSense spider see this text (and links) in the noscript, whereby the above could be eliminated?

The text that normally displays is the caption text from the array data. I'm certain that spiders don't see this, since for a month there were no context sensitive ads. So one of the above lists is supplying the text, I just don't know which one.

Now on to classes and ids... As I mentioned above, this site has evolved over nearly four years, consists of nearly 500 pages and draws upon a varied range of style sheets that have themselves evolved. The variations and techniques applied are numerous, which has resulted in a good lot of custom code populating the CSS. Since the main overhaul of the site is largely complete I can now spend some serious time analyzing and paring the styles, and as you suggest, combine some of the properties.

The difficulty in this is just as stated above, customization; this on top of global properties which are pretty much unalterable without impacting the whole site. I'll be keeping your advice in mind as I do the review.

Next, background images... Why did I choose to use CSS images, rather than <img/>s? Simple, for the mouse-over effect. Most of the background images have two parts, one of which displays, while the other remains hidden, and vice-versa on mouse-over. This is fashioned along similar lines to Douglas Bowman's Sliding Doors of CSS method. It's javascript free, uses a single image and doesn't require <img/> tags. The drawback is the lack of descriptive text when images are off, though a tool tip does still display on hover. The reason the placeholder and border remain (images off) is because the anchor is display:block, with width and height properties set. Not sure how I would add alternate text.

After spending the last several months doing an overhaul and re-design (transparently on the live site) I'd like to think there are a few things that were done right. I don't agree that there are so many bad practices that they should overshadow the things that meet their designated purpose while sticking as closely to guidelines as possible.

Everything requires compromise, and this site is chalk full of loose interpretations of the guidelines. I am content to pass automatic testing for accessibility. There has to be a limit, especially when our audience is largely known to us. You should have seen the site when the pages were rife with inline styles and scripts. It still validated, but was definitely not unobtrusive. There were scripts and noscripts everywhere. They have all been cleaned out, now, and moved to external scripts with load events (Dean Edwards addEvent()).

Nothing is apparent in the HTML except a few empty divs. All links to slide show pages are scripted, to prevent access when scripting is off. You won't find any links to slides.html in the source code, but you will in the generated source. The sub menu at left and the section headings in the content contain these links, as well as the footer navigation of catalog pages. Of course, my scripting leaves a lot to be desired, even while it does function as required. This is an area where I am completely newbie.

Thanks again for your suggestions. I hope you might find the time to dig a little more under the hood and draw my attention to still more deficiencies, as they must surely exist on a site such as this.

This allows me to leave the title attribute out of the source code on any link with a 'rel' attribute, which is the trigger for lightbox plus. Running the script before loading lightbox will populate the required title attributes and caption text copied from the anchor text node. Works like a charm.

This is a typical link:The generated source looks like this:This solution will at least remove the majority of offenders, though I'm still at odds on tool tips in navigation, in general.

The demo version is in the December 1 page, until I can go through the entire year's events and remove all the titles. Once that's done, it will be in main script, not in the document.

Sometimes the best breakthroughs come when we stick our necks out. Thanks for clarifying this problem, amorphic8.