Ian Anderson wrote:
I find a useful rule of thumb is to imagine what the page should look like in an ideal situation if you were to print it. The site name would be no more than a footnote repeated on each page.
And that's probably where some other people (notably site owners, perhaps) may disagree. If you imagine a page being looked at in complete isolation, the user may well question what the particular section relates to. Imagine for instance a contacts page. If you just got it as an unstyled printout or something, it wouldn't make much sense unless you knew whose contact details these are.
Different schools of thought, different ways of looking at it...I don't think we'll get to a consensus on this.
Links are the primary means for screen reader users to scan a page to try to derive context and an overview of the content.
Hmmm...not necessarily. Many of the screen reader users I've observed and spoken to get up a list of headings, which gives far more information about the current document than links, which traditionally point to *other things*. Why would I get up a list of links to know what the current page is about, unless I knew for a fact that those links were all in-page links?
Almost all links on a page are to unrelated items,
Unrelated only insofar as they may be pointing to other documents on the same site?
and the worst thing is that there is no means for the screen reader user to identify the few in-content or downward links from the mass of unrelated links that clutter most web pages.
Purely from looking at the links, probably not (although they will be able to discern if something has a link text that sounds like a traditional site section, like "about us" or "contacts").
All the site tools, extra cruft and navigation are best bundled up and either skipped over by a skip navigation link or placed at the end of the document.
Or bundled up in something like a list or similar container element, which can be skipped in one single step (with a "move to next block level element" style command, although availability and implementation of these commands may vary depending on AT used).
Note that placing this material at the end of the document may slow screen reader users down for key tasks, such as finding contact details, since they are used to going to the end and working up to find addresses and phone numbers.
And it also goes against a certain amount of learned knowledge they user may have on how most other sites are structured, so may cause an initial bit of disorientation ("where's the navigation?")
I'll close with an observation from user testing; many screen reader users give framed sites extremely high marks for usability and perform tasks much faster in these sites compared to unframed versions, because of the encapsulation and separation of content from the superfluous links of navigation and other tools. Framed pages often provide the perfect, stripped down content that screen reader users enjoy, as do pages found in popup windows.
The core of your argument is certainly a valid one. HTML itself is limited in that it doesn't offer a way of cleanly separating the current document's content from the site-wide context this document is in. Certainly, a lot can be done with LINK elements, but user agent support isn't that hot (out of the box anyway), and overall just using LINK elements can be very limiting. But I do agree (incidentally, had a long - partially alcohol fuelled - discussion with Andy Budd on exactly this issue not so long ago).
P -- Patrick H. Lauke __________________________________________________________ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __________________________________________________________ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __________________________________________________________ ****************************************************** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ******************************************************
