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

Hey everybody,

What I usually do is have this style for my "skip nav link":

.skipNav { display: none; }

So for browsers that understand CSS, it doesn't show up, but for text-
based browsers and those with CSS turned off, it shows up perfectly.

Mike


On Fri, 13 Jun 2003 07:05:08 -0700, Leslie K. Yoder wrote:
> 
> 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 10:19:30 UTC