I don't get the part about my site not working properly with screen readers, though. If it can be navigated easily with a text-only browser such as Lynx, then how can a screen reader have trouble with it?
You don't have numbered headings to navigate through the sections with, or your content text marked as paragraphs, AND it's marked up with "tables for layout" on which things like JAWS can completely choke. Having it scream "TABLE CELL!!!" between every major section of your home page gets tired REALLY fast. Is that tabular data? No, then why is it in a table? Simple, tables for layout something that was bad practice 20 years ago when it was introduced.
... and that today there's no reason for other than a lack of understanding CSS layout or being stuck doing something like HTML e-mails where the client software is too stupid to use CSS or anything newer than HTML 3.2 properly.
Thing is, "semantic markup" is really just a sick euphemism for "using HTML properly" -- or more specifically using it the way Tim Berners Lee originally intended prior to the disaster that was HTML 3.2 and the browser specific tags that followed. The entire reason HTML even exists is something we all should be behind 100% being retro guys! At the time professionally written documents like scientific papers, whitepapers, etc were being sent between machines of wildly different capabilities -- from printers to teletype to 21x22 VIC-20 to 80x25 text to 512x384 Mac to the 1120x832 monochrome graphics of the NeXT workstation he was sitting in front of.
He came up with the idea of taking SGML style formatting and creating a specification of "semantic tags" who's purpose was NOT to say what things look like, but what they ARE or would be in a professionally written document. There are things you do when writing professionally that some devices aren't even capable of -- italic for book titles, bold for proper name references, different size text for different level headings -- that many of those devices can't even do. By using tags to say what it SHOULD BE in a professionally written document, it could then be left to the "user agent" (what today we call "browsers") to best figure out how to convey that within the capabilities of that device. We aren't supposed to be saying in the HTML what things look like, we're SUPPOSED to be saying what things ARE or should be. That means if you have a GRAMMATICAL paragraph you wrap it in a <p> tag. Numbered headings correspond to heading levels in pro writing where the top-most heading H1 is what all content on the page is a subsection of which is why EVERY page should have one and only one H1. A second level heading like H2 indicates the start of a subsection of the H1, H3 indicates the start of a subsection of the H2, and so forth down the line... Horizontal rules -- HR -- indicating the start of a subsection where a numbered heading is unwanted/unwarranted. HR does NOT mean "draw a line across the screen" since a dividing "rule" can be anythign from a centered elipsis to a string of asterisks to just a page-break; in that same way numbered headings do NOT mean "bigger text of different sizes" it means "these are the start of subsections". THAT's using HTML "properly" to it's original intent.
The above actually oversimplifies and it ain't quite right -- a browser is always a user-agent, but a user-agent isn't always a browser.
Then along came Nutscrape and Microshaft to piss all over that from orbit. Suddenly everyone pretty much ignored what HTML was even FOR and started only caring about "what does it look like on a VGA resolution display" to the point of telling anyone else to go plow themselves.
The very notion of semantics and accessibility was thrown out the window as more and more idiocy like FONT, CENTER, TARGET, BGCOLOR, FACE were added to the specification resulting in REALLY big redundant code.
It didn't take long for it to be recognized what garbage was resulting - so along came HTML 4 (the real 4 later to be renamed STRICT) and CSS to try and fix things. HTML could go back to saying what things were FOR, with CSS saying what it would look like for different targets like screen, handheld, print, or even to provide hinting for non-visual UA's with targets like Aural. It was also crafted to remove pointless redunancies in the specification to make it simpler. DIR and MENU were redundant to UL. ISINDEX was redundant to INPUT, FONT and CENTER were redundant to CSS, APPLET and EMBED were redundant to OBJECT...
Laughably for the 'real' HTML 5 that never materialized IMG was also supposed to be on the chopping block as redundant to OBJECT, so we wouldn't be locked into image formats that browser makers just happened to feel like supporting. So along comes the dipshits at WhatWG with their alleged HTML 5 introducing all sorts of new redundancies including AUDIO and VIDEO to promote vendor lock-in of whatever the browser makers happen to feel like supporting.
The problem was many considered the change "too radical" so they created this thing called "4 transitional" -- allowing in a bunch of the vendor specific browser crap and the worst of HTML 3.2 to be mixed with the new stuff. In theory tranny was created -- like most pre-op's -- to allow older existing sites to use the stuff introduced in HMTL 4 like forms in a mix-and match, while HTML 4 "strict' as for creating all new websites. If it didn't exist or was "deprecated" in STRICT, you weren't supposed to be used at all.
So naturally what did people use to make new websites for the next decade and some change? That's right, transitional -- either out of ignorance, apathy, or just plain wishful thinking. People continued to use tables for layout, use headings incorrectly or not at all, slap paragraphs around things that are not grammatical paragraphs, abuse lists when they have headings, not use lists around obvious shortlists, etc, etc...
Frustrating for those of us who embraced 4 Strict, practice separation of presentation from content, and all the other good practices of the past decade and a half that mean faster loading better gracefully degrading sites. The REAL joke of it all being that if you used HTML 4 STRICT properly pages would view better/more reliable in pre-css browsers than they do in early CSS (IE 4 and 5.0, NS4) browsers from that "transitional" period.
... an even bigger joke being the steaming pile of manure known as HTML 5 just lets the sleazeballs who continued vomiting up new sites in Tranny to keep on using their broken nonsensical BS, slap the new lip-service doctype on thier bloated slow loading crap, and pat themselves on the back over how "modern" they are with their bleeding edge of 1997 coding practices.
Just to show what I mean, I'll use one of my sites as an example:
http://www.ewiusb.com
Which is about six years out of date code-wise, but was one of the first "responsive" sites I've built using the new CSS3.
(which is NOT HTML 5 no matter how many jacktards slap all the cool stuff from the new JS and CSS under it's banner!)
In non-CSS capable browsers because it uses semantic markup, it gracefully degrades extremely well:
http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNoCSS.jpg
The semantic markup with logical heading orders makes the document structure very clear and navigable in UA's that support it (like REAL Opera -- as opposed to the pathetic crippleware known as ChrOpera):
http://www.cutcodedown.com/images/ewiUSB/headingOrders.png
While with CSS for desktop targets the max-width prevents long lines from getting hard to follow -- so called "semi-fluid" layout:
http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNormal96.jpg
... and since font sizes, column widths and max-widths are declared in EM's, they auto-scale to user preferences properly without the ugly image resizing that diving for the zoom would involve. That's called "elastic layout"
http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNormal120.jpg
The layout being semi-fluid scales down the content column to fit:
http://www.cutcodedown.com/images/ewiUSB/ewiUsbCom800Wide.jpg
While the use of media queries lets it on modern browsers strip off columns and gets rid of presentational imags that don't fit when the screen is too narrow. This is called "responsive layout"
http://www.cutcodedown.com/images/ewiUSB/ewiUsbCom640wide.jpg
Which can work down to really REALLY tiny widths.
http://www.cutcodedown.com/images/ewiUSB/ewiUsbTinyMobile.jpg
Which does become painfully long to scroll through, but that's what heading navigation and accesskeys is SUPPOSED to be for.
It also uses image-replacement techniques for any presentational images, which is why it gracefully degrades in a useful (though less attractive) manner when images are blocked or unavailable. Also gives screen readers and search engines something to look at since they can't "read" images.
http://www.cutcodedown.com/images/ewiUSB/ewiUsbCom800WideNoImages.jpg
All from ONE HTML codebase with a markup to content ratio of 3:1... where most people still sleazing out 4 tranny and slapping 5 lip-service around it seem to think there's nothing wrong with MtC ratio's of 20:1 or more. (or HTML+CSS+SCRIPTS to content ratios of 1000:1 or more!)
... and since CSS is cached I use monolithic CSS files to pre-cache the appearance of sub-pages since an extra 8k of CSS is piss in the pan, particularly if it makes the only thing sub-pages have to load when visited is the new markup and any content images; which also means so long as visitors go to more than one page on the site it saves bandwidth as well.
... and also good for a laugh, that site is bloated/outdated by my current standards; but as I often say if you aren't disgusted with your own work from even just a year ago, you're in the wrong business!
It gracefully degrades to crappy IE versions (5.5 through 8) reasonably well, though it loses a lot of the shading and rounded corners (OH NOES, NOTS THATZ!!!)... It is only the intermediate versions of IE (4 through 5.01) and NS (4) and Opera (4 through 6) that really have issues since again, that whole era of site development and browser design was flawed.
Another laugh being a "properly" done website using semantic markup and separation of presentation from content usually gives the finger to those late 90's browsers, but would work just fine in something like LYNX, Mosaic or pre-CSS versions of those same browsers... well, other than forms... since anything pre HTML-4 usually means no form support.
Nope, I'm not long-winded or preachy AT ALL...
