Clark, I agree 50%. I don't blame the protocol's slow advancement towards accessibility as the consortium has done wonders. But much of the problem lies with browser companies trying to display poor code better to win users. So, I put the blame on browsers, wysiwyg editors, and coders at least as much as the protocol.
I believe very stongly against any browser that will display a page properly with improper/non-compliant code. Getting rid of quirks mode would be the best thing in the world for this issue.
I also believe companies who develope wysiwug editors should be shot for what they have done. I may be ignorant in this area as I don't use them, but I have never seen good code produced from any one of them.
And don't get me started on coders, I don't have enough shells. I would go out on a limb and state only about 5% of current publishers have even a marginal clue about what they are doing.
Clark, take a good look at W3C's proposed HTML5 and you will be very pleased with where they are heading. You'll have exactly the tools you need to cover your concers. Lets just hope the browser companies can understand the importance of this and get off their butts and upgrade their software quickly to comply.
SOC -- pageoneresults, I applaude your efforts, but I need another accronym like a hole in the head. If coders had a clue this would not be an issue. Too many times I have had to fix code or explain to a client that it's not what you can do, it's what you should do. My point is don't worry about SOC unless it makes sence to the needs of the page.
Here's an example. I just opened Yahoo's homepage, over 100k just in code, not including any external files. HTML errors - 275, CSS errors - 254, accessability errors - 6. Just stupid, but thats another issue. How does SOC come into play on a page like that? It doesn't. I know Yahoo will deliver a different page depending on the browser, but thats not my point. The point is SOC is just not a player on a page like that.
So, where is SOC needed. I think mainly the concept can be used best in educating coders on how to develope a page that works properly regardless of the user agent. If you know what your doing, for the most sites, you don't need to give a different page for each user agent type. Develope you content, then apply styles later. But, for the most part, we, as developers, do things in the opposite. We develope these great looking templates then plug in content later. I think this is the wrong way to go.
Here is an example of a page (draft) I just finished for a client and I'll step you through the process I believe to be the right approach.
The client sends me a image file from the designer on what they want the page to look like. Ok, but thats not what I need. So I reply with an email asking for their intention/purpose for the page. They are selling a product. Ok, I reply as to the strong points of the product, why people need it, I research the market and competitors, this and that replies back and forth until I have a really good sence of what the page will need to get the point across, which is why a visitor should purchase and how to do it. I get headlines, content, and a list of strong point written out. Now I have a text file with nothing but text!
Now I comunicate with the client a little more to get a site structure established to figure out what links I need. A little seo research to get a keyword/phrase set established and I write out a final draft of headings, menu, content, list of strong points, etc. and add containers to build the page structure. Add doctype, title, desc, kw, html/head/body tags, a/div/span tags. Now I can view my content as content!
At this point I have no styling at all. No <b> tags, no images, nothing but headings, menu, paragraphs, maybe a list, a link or two in the content. Thats it. Thats my page. Thats contant for any user agent. My result is a page of 4k. Now of course I need a little branding so I add the logo with a good alt/title tag and any other (few) graphics the page needs to get its purpose across to the user. Such as a product image. Also, I may substitute a few small graphics to use inplace of text for seo reasons of if required for another reason like maybe a graphical submit button. These are the ONLY graphics that should be in the code. Anything else is styling and should be in the sylesheet!
Now I think a little on how I would read the content to an audience. Think about this one! If you were selling it, how would you emphasis your words. Now you can plug in the tags associated with a speach pattern. You may just find out, if your honest with yourself, that aural styling is very very close to visual styling. If done properly seo will be handled as a by product of this step.
I now have a finished product which will work in an user agent. I know as I tested it. My tools give me the ablity to view what a small screen would see, text only, non-graphical cell phone, aural reader, etc. Not to mention a search engine.
I now have a page with good content, it works for all, and it will rank well! Why is it this is usually the last step for publishers. Ignorance? Lazyness? It's not as fun? BAH, this is your job, do it first.
Now to style it is no trouble at all. I have a graphic to slice images from to apply to backgrounds, set margins and padding, choose fonts, color, weight, line-height, indents, etc. Apply floats or positioning. I'm done for screens. Now work on a print style. Others are not needed as SOC just handled it right!
By others I mean cell phones will just show my text and alt tags. Aural readers the same. My content started out this way and didn't change so I don't even have to worry about it. Same with spiders! Small screen display will ignore the backgrounds so I will show the needed graphics in the page and the stlying graphics gone.
I view the page in all 6 formats and it's just right. It will work/sell/inform or whatever it's purpose on any user agent. For SEO the file size, text/code ratio, kw desity, all of it is perfect. This is just too simple if you go about it the right way. Don't start with layout and graphics, start with the content. That's what the page is about anyway. SOC, we don't need the accronym, we need people to just understand what they are doing. Which is presenting content, not graphic arts...
I just think worrying about whether a page follows the concept of SOC is an extra step that should be taken care of by default if the content is written out first. Keep it simple somebody...
I wonder, am I way off or is that educational, or maybe just a rant?