as sometimes a form seems to validate without it but other times not. (I haven't worked out a pattern.)
Here's the pattern (haha):
In HTML4, a legend MUST accompany a fieldset. In XHTML, this requirement has been (strangley) dropped.
if you are using blocks (divs, p's) to wrap label-input pairs with an HTML4 doctype, the validator misses it when you leave out legend. If you remove the divs and still have no legend and re-validate, you'll get the error message you're expecting (fieldset not followed by a legend). I just assume I should always have a legend with my fieldset, BUT there are times where I can't think of non-redundant text. In these times sometimes I consider leaving the thing blank. I haven't decided even today what is best, and some of my forms start with "fill in" (where later fieldsets have useful legends because then grouping-by-type starts).
By sub legends, do you mean that there is a main fieldset + legend for the whole form, and then within that sub fieldsets each with its own legend?
<legend>Rate your Coffee Addiction</legend>
some random questions who have nothing to really group them, but have to do with coffee addiction
<legend>How often do you consume coffee?</legend>
<input type="radio" name="rate" id="never" value="never"> <label for="never">Never</label>
<input type="radio" name="rate" id="daily" value="daily"> <label for="daily">Daily</label>
<input type="radio" name="rate" id="hourly" value="hourly"> <label for="hourly">Hourly</label>
<input type="radio" name="rate" id="iv" value="constant"> <label for="iv">Constantly via IV drip</label>
rest of form...
"How often do you consume coffee?" may be read out before each question. Depends on the reader and again I thought you could also turn it off.
I always turn off CSS to see how the page flows. Is this the equivalent, or is there some special advantage of trying Lynx etc?
Hm, Lynx has its own ways of showing me where I am, what's clickable, how tables and forms are set up... whereas turning CSS off (if you do it with the web dev toolbar) you may still have that default browser-specific stylesheet. But, not sure if it matters, they are often all similar to each other. When I'm using Lynx, I'm in the terminal, and I kinda just get into a text-terminal mood : )
This almost seems to suggest you think this is a waste of time? I presume seasoned users have quicker ways to jump to content? Perhaps by jumping from header to header?
Once you are familiar with both a page and your reader, you will use all sorts of ways to navigate. Jumping by header is very nice (assuming the page is well-built and has headers), but navigating through a site... you may want to get to the main menu on each page until you find something you're looking for.
You can use ARIA attributes (set role of "navigation" to site navigation, "main" to main content, "banner" to a block of info usually containing logo/site name and utility menu and tagline or whatever, "search" for the site search area...) as landmarks to jump to things, or you can use the Quick Keys to jump to things:
next (or prev) header
next (or prev) list <-- often the menu
next (or prev) non-link text
next (or prev) form <--often a log in form or search
next (or prev) table
more about ARIA: http://www.nomensa.com/blog/2010/screen-readers-and-aria-landmark-roles/
These are usually faster than tabbing around or hoping the author left some skip links for you... in fact I tend to keep skip links around for sighted keyboarders who aren't using Opera (since i usually pull the things off-screen, Opera does not offer them as a tabbable option) where they do appear onscreen once focused on.
Try a page like Wikipedia. You can get really quick at getting where you want.
I tend to stay away from accesskeys though SitePoint uses them and users have used them (but a site you revisit often like a forum or news site is more likely to have accesskeys actually benefit users... for a one-off site, you run more risk of people not wanting to memorise them and that they possibly interfere with some other command... like 1-6 can quick jump to that header level).
Cripes, I've never even heard of them! How is that different from page zoom? I think there are some pretty powerful page zoom facilities on the Mac.
Imagine the only part of a web page you can see is the size of a credit card.
Now imagine you've clicked on a link and you don't see anything happening.
Because AJAX changed something... on the other side of the browser. You missed it.
So it's like extreme zoom, depending on how much magnification you need. The problem with it is how it limits the amount of page you can see at once without moving around. So it mostly affects things like user notification.
I'm sure there's a WCAG rule about where user focus and notification shoudl go.
On that note, adding updates to a page with AJAX (no refresh) also is a good idea to put the change (or a notification of the change) under/after where the user was focussed.
2006, so is not entirely true for newer readers: http://articles.sitepoint.com/article/ajax-screenreaders-work
Again readers without a virtual buffer don't have to worry about updating that buffer... they'll just continue reading the actual page (Orca).