Re: Skip Nav (was RE: "Think EUO, not SEO"/Google)

The fact that skip nav links *are* typically "hidden" seems to cause several
problems: the Google issue; poor usability for sighted keyboard users; and,
probably, lack of widespread implementation because the standard is,
literally, invisible to most users and designers.

Given these drawbacks of the hidden link, would it make more sense to shift
the convention to visible skip nav?

Leslie


----- Original Message -----
From: "John Foliot - WATS.ca" <foliot@wats.ca>
To: "W3c-Wai-Ig" <w3c-wai-ig@w3.org>
Sent: Friday, June 13, 2003 6:21 AM
Subject: Skip Nav (was RE: "Think EUO, not SEO"/Google)


>
> David,
>
> I think that you may be missing something here - providing a means to skip
> over redundant information through a series of documents (web pages) is an
> accessibility aid to some users, not just those employing screen readers,
> but all linear devices, including but not limited to text only user
agents,
> or those with limited display real-estate (cell phones, PDAs, etc.)
>
> Structurally, all HTML documents are linear in composition; they start
<!DOC
> TYPE..> and they end </html>.  Within each of these documents however
there
> are blocks of content - the subject (the "good stuff") properly marked up
> using the semantic logic of <h1>, <h2>, <p>, etc., then there is
"supporting
> blocks" - copyright notice, author information, creator branding (aka your
> logo), and a means of navigating throughout the collection of documents
that
> is your web site (your navigation).
>
> Since all of these elements are to a certain extent important parts of
each
> document, content authors are then required to "prioritize" their
placement
> within the document, given that each document is linear.  What should come
> first?  Navigation or "the subject"?
>
> In the traditional method, navigational elements are visually placed
across
> the top or along the left hand side of a web page.  The reasoning for this
> is based in part on known behaviours of the current browsers/user agents
but
> also because, due to varying screen resolutions,  etc. the only real
> bankable visual constant is that each page "starts" at x,y axis 0,0.  So
> traditionally important redundant information linearly started there.  So
> here comes the navigation... each and every time, each and every page.
For
> users of screen readers and other linear user agents, this can be mildly
> annoying to down right frustrating. If each page on your site has a large
> number of navigational links, they must be "encountered" each time, before
> getting to the actual content.  Thus a means to skip over this redundant
> content (if the user desires) aids in the accessibility (and thus
usability)
> of the page.
>
> On the other hand...
>
> Assuming 100% compliant adherence to CSS positioning (a stretch, but work
> with it), it could be argued that placing the main content ahead of the
> supporting information (including navigation) in the linear composition of
> the HTML document would make more sense, and then style it to appear "at
the
> top" or "along the left hand side". For the visual user, this fits within
> the traditional model they have come to expect (see Jacob Neilson, Steve
> Krug(1), et al), but for linear users puts the reason for the page front
and
> center (to paraphrase a song title "don't bore us, get to the chorus").
But
> if the document content is "long", linear users must "read" the entire
page
> BEFORE they can get to the almost equally important navigational elements.
> In this case a "skip TO" navigation link should be the first thing
> encountered on a page, allowing new users to review their navigational
> options without the need to process the entire page content.
>
> In either scenario, the use of named anchors within a document enhances
it's
> accessibility and usability for users of these more linear technologies.
> You state: "I suspect that having pure navigation and pure content pages
is
> best, anyway."  How can this be done?  How can a content page be
> "independent" of navigational elements and still be part of a collection
of
> multiple documents?  Given today's "state-of-the-web"(2) I don't think it
> can, short of the dreaded Frameset, which over time has now proven to be a
> nightmarish scenario for usability/accessibility concerns as well.
>
> This thread posed the question of whether Google would "penalize" web
pages
> that used "hidden" skip nav (skipt-to-nav?) links on a page.  While a
> definitive answer does not yet seem to have surfaced, it does cause one to
> pause.  Given that the US Section 508 legally mandates this navigational
aid
> for compliancy(3), it occurs to me that there will be literally millions
of
> pages out there that will have "skip navs", not so much because the
content
> creators truly understand the why of it, but rather "just because" they
need
> to do it because it's "the law".  At any rate, indexing 'bots, Google or
> otherwise, which start to penalize pages/sites that include this type of
> content will start to exclude useful and relevant web documents from their
> databases.  As someone pointed out, Search Engines which do not provide
> their clients with "the best" results will drop from favour/usage, which
> means a hit to the bottom line.  So I don't think 'bots will penalize
based
> on hidden skip navs.
>
> That said, it is also worth considering that a "standardized" method of
> signalling this type of named anchor link within web documents would aid
all
> concerned; users, developers, 'bot-masters, etc.  Is this something the
> W3C-WAI should take up and champion?  Or perhaps Section508.gov, given
that
> this *is* a Section 508 mandate?
>
> --
> John Foliot  foliot@wats.ca
> Web Accessibility Specialist / Co-founder of WATS.ca
> Web Accessibility Testing and Services
> http://www.wats.ca   1.866.932.4878 (North America)
>
> ********************************
>
> (1) Steve Krug: http://www.stevekrug.com/buythebook.html
>
> (2) Web weenies using cutting edge browsers and familiar with the more
> intricate nuances of HTML development will point to the <link rel=""
href=""
> title="" /> capabilities and their implementation in Opera 7(4) and
current
> Mozilla(5) builds (we use it in a limited way on the www.wats.ca web
site).
> While this capability certainly allows for basic navigational structure,
it
> can also be argued that it does not completely address the full range of
> navigation requirements in sophisticated and extensive web site
> architectures.
>
> (3) "(o) A method shall be provided that permits users to skip repetitive
> navigation links."
>
> (4) In Opera, go "View >> Navigation Bar >> Auto" (or place it where you
> want it)
>
> (5) In Mozilla, go "View >> Show/Hide >> Site Navigation Bar >> Show Only
As
> Needed (or) Show Always"
>
>
>
> > -----Original Message-----
> > From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
> > Behalf Of David Woolley
> > Sent: Thursday, June 12, 2003 4:55 PM
> > To: w3c-wai-ig@w3.org
> > Subject: Re: "Think EUO, not SEO"/Google
> >
> >
> >
> > > ...Google [is] declaring all hidden links as
> > > bad and automatically checking every page for them...Most
> > > invisible links do fall into the spam category, but not all.  If you
> >
> > Unfortunately every marketing department in the world wants to get
> > their sites at the top of search engine results for any even vaguely
> > related search, but only a small proportion care about accessibility.
> >
> > That means that any feature that allows content to be hidden from the
> > majority audience will be used to stuff keywords.
> >
> > Traditionally Google has been relatively immune to keywords stuffing,
> > because it relies on citation counts.  I wonder if what they are really
> > trying to block here is invisible cross-citations?
> >
> > However, more generally, I feel unhappy with an environment that needs
> > such links.  At the first level, they should maybe be considered closer
> > to the first entry in the short form table of contents in some books,
> > and called "main text" (also consistent with the principle that links
are
> > nouns, whereas "skip navigation" is more in line with the marketing idea
> > that links are verbs).
> >
> > But, why is there navigation to skip?
> >
> > Part of this is a desire to try and lock people into a site.
> >
> > Part of this is limited support of style sheet positioning,
> > forcing visually
> > early material to be early in the document.
> >
> > But part of it is a dissatisfaction with the traditional publications
> > model in which catalogues and narrative books are separate.  Even
> > where both
> > are in a traditional book, the navigation (References) are
> > generally at the
> > end, rather than the beginning.
> >
> > I think, to some extent, the problem is with the user agents, in
> > not making
> > it easy to maintain a bookmark in the catalogue whilst reading
> > the main text,
> > and thus forcing the use of framesets and embedded navigation.
> >
> > However, having recently realised something that was too obvious to
> > consider was implemented by NS4, Mozilla and IE, I wonder if the problem
> > is really a failure to educate users in how to use their browsers.
> > The feature is that you can drag a link into another window and have
> > the link open in that window.  This means you only have to open a new
> > window once, for the first contents page.  You can then drag subsequent
> > content links from the navigation page into the same window.
> >
> > Once you know of this mechanism, I could argue that it is a much cleaner
> > metaphor than the click to open metaphor, although it makes nonsense of
> > the, too common, "click here" link text.
> >
> > This is a pointing device based metaphor.  For the blind user or
> > those with
> > limited screen real estate, I suspect that having pure navigation and
pure
> > content pages is best, anyway.  For those where control of the pointer
is
> > the problem, it might be desirable to have better keyboard options than
> > always to open in a new window.
> >
> >
> >
> >
>
>

Received on Friday, 13 June 2003 09:59:15 UTC