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

As Bill said, this causes a problem for screen readers.

It is also a hassle for people who use a CSS-capable browser with a 
keyboard (Opera, IE and Mozilla/Netscape have all had a lot of work put 
in so people can do this).

Personally I think it would be better to display the thing.

cheers

Chaals

On Friday, Jun 13, 2003, at 15:18 Europe/Zurich, Mike Rundle wrote:

>
> 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.
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
--
Charles McCathieNevile                          Fundación Sidar
charles@sidar.org                                http://www.sidar.org

Received on Friday, 13 June 2003 10:42:13 UTC