Skip Navigation' should be in all core themes

Take a look at navigatio......n:
print t('Skip navigatio n')

:)

please, use height:0px; overflow: hidden; instead of positioning offscreen.

i've prefer this approach for a couple of reasons.

1) it is the easiest to override by (sub)themes (think of WAP, WII, NDS, iPhone etc...), simply by setting height: auto; or by explicitly setting height and overflow to auto or scroll.
2) the problem with the w3c example is that it actually does take space, therefor possibly confusing CSS developpers that wonder where that pixel went.
3) this method doesn't touch width, thereby allowing this to adhere to it's context.
4) usably in any design, floating, absolute or any other you can think off.
5) already proven track record, as part of unobtrusive javascript.
6) this is drupal core, so we should cater the unexpected ;)

BTW: any design using !important should be forbidden, as this is reserved for user-side implementation. (not client-side but USER-side)

This is just the thing for me. I have to add offscreen classes in all my sites and my coworkers that use out of the box core themes don't end up with skip nav links.

I've been following the various threads about hiding and showing content and after feeling a bit like I was trying to get on an speeded-up escalator I thought this might be a good place to start.

I think having some kind of skip link as part of core themes is a good idea (on the assumption that all core themes have the navigation first in the source code order), but it shouldn't be entirely hidden because it tends to benefit keyboard only users who don't use any kind of assistive technology more than users who have benefits that come with using screen readers or voice recognition packages.

My preference from an accessibility/usability point of view would always be to have it visible because it not only lets people know immediately that it's there but it can also give a very quick impression that accessibility has been thought of and integrated. That said, I know that some people don't like it on the grounds that they think it's messy. It is possible to integrate it into a site's design so it doesn't stick out like a sore thumb - as Carsonified have done at http://events.carsonified.com/ - but it isn't always easy so a good compromise is to have it hidden from view initially but becoming visible on focus.

If I was to have a wishlist for a skip link it'd be:

- it being the first or second link on the page (where the first link is to the home page)
- it becomes visible on focus (with the :active state included in the CSS declaration, to make sure it works in IE)
- it doesn't use display: none or visibility: hidden to hide
- it is phrased "skip to main content" because that's clearer about where you're going than "skip navigation" and because "skip to content" is read out badly by screen readers because of lack of context (skip to conTENT rather than skip to CONtent)
- it appears in a logical place (i.e., top left or along the top like on http://www.molly.com) so users don't miss it

In terms of how this could be integrated into drupal (and keeping all the various discussions on conventions for hiding content in mind) I'm not sure that there's a one size fits all hide/show class that could be used here, because of it's differing behaviour, so maybe it'd be better to just give it a class of skipnav (or something) and then define the link states based on that, which should also mean there isn't any javascript required to change the class.

Ann

Yay, Ann! Excited to see you in our issue queue. :)

I recently came up with a way that may suit Garland quite well. Basically it positions the link absolutely, then on :focus/:active it re-sets the position to fixed. Using position:fixed mitigates any scrolling issues; the link just appears *over* the content in its own layer.

This is rock solid in all A grade browsers including IE6. This code is actually from the Genesis theme (my starter theme) and is an option users of that theme can enable. Not all these declarations would be needed for Garland because in Genesis I need to override a couple of other default styles, but you'll get the picture:

#skip-nav a:link,
#skip-nav a:visited {
  height: 1px;
  overflow: hidden;
  position: absolute;
  top: -999em;
}
#skip-nav a:active,
#skip-nav a:focus {
  background: #FFF;
  border: 1px solid #C00000;
  color: #C00000;
  height: 2em;
  overflow: visible;
  padding: 2em 0;
  position: fixed;
  text-align: center;
  top: 0;
  width: 978px;
  z-index: 1000;
}

@webchick: thank you :) I'm still trying to get a handle on the way all this works but it's good to be here (even if I fall down rabbit holes of interlinked issues when trying to figure out where best to contribute).

I think I figured out email notifications earlier so hopefully I'll now be able to get updates rather than have to manually check for updates. :)

Ok, here's an updated patch for Garland, think we should do Garland and Stark seperatly since Garland needs a specific implementation.

This is my own idea and is not widely known (I probably invented it) so needs some testing as per usual. It follows the concept in #13 and degrades gracefully in IE6.

Changed link text to "Skip to main content", and inserted a named anchor because I think we need to skip over the breadcrumb and highlight and there's no id on the $content wrapper.

Pretty much the same deal with Stark/system page.tpl.php, except no CSS. Used a named anchor again, could have hooked in the the id on the h1 page title but that seems a bit hacky.

tagging

Re-roll, failure with Garland patch after #306358: Add $classes to templates with new theme_process_hook functions was committed.

I support this but we need to document it better; e.g. add a reference to the accessibility standard so we don't forget what this is about.

Normally, we don't abbreviate things to 'skip-nav' -- we'd use 'skip' or 'skip-block' or 'skip-navigation' but no 'nav'.

Ok, good points, I'm thinking this falls under:

http://www.w3.org/TR/WCAG10-HTML-TECHS/#group-bypass
Checkpoint 13.6 http://www.w3.org/TR/WCAG10-TECHS/#tech-group-links

Someone want to confer on that, then we re-roll with a new class, thinking "skip-link", its not abbreviated and says what it is.

Change status

I like Ann's recommendations in comment 10.

As for offscreen / inline hiding of content for screen-reader users http://webaim.org/techniques/css/invisiblecontent/
explains that some screen-readers do not handle "height:0; overflow:hidden;" well. Unfortunately the article gives no examples. Testing with three modern
screen-readers, (Voiceover, JAWS and NVDA) this class successfully hides content visually, while displaying it to a screen-reader. Can more examples and
clarification be given on the pros and cons of using this vs. the absolute offscreen positioning solution? These are really the only two options and one
will need to be chosen over the other.

Finally, I am not sure that skip-link is the semantically best description for the class, as there are likely alternative uses for the class and not all implementations of skip links will use this class. Off the top of my head I cannot think of better wording.

subscribe

Curious if we are still going to attempt to implement skip links for the three core themes (garland, stark and seven). If so.

1. Will the link be "Skip to content" or "Skip navigation"?

2. Will the links be hidden off-screen unless focus, active or hover? Or, will the links always be visible on-screen?

IMO:

Yes, lets do it.

Garland - hidden
Stark - showing
Seven - dont know, probably showing

Text should be "Skip to main content".

Agreed. Tell where the link goes, not what it avoids. So, "Skip to main content."

I have had a chance to read through. This is very good discussion. Also, it's important to note that we should code to WCAG 2.0. Some (most?) regulations still refer to WCAG 1.0, but anything that passes WCAG 2.0 in this regard will also pass WCAG 1.0.

Another relevant section of WCAG 2.0 is Guideline 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.

In this issue, to meet that guideline, we are specifically implementing Success Criterion 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A) But skip links are only one way to achieve this. Take a look at the sufficient techniques listed on that page, and you will see that the second class of techniques involves proper use of headings.

I have seen elegant accessible designs that require no skip links. The main content is the first part of the body of the html, even though CSS may position it elsewhere in the visual display. I'm not saying we should give up on skip links; instead, I'm noting that we should recognize that there are other ways to achieve this goal. In a way, you have done that by using a small fix that a designer who is intent on using a different valid approach can easily find and remove. I hope our documentation for this will recognize this possibility.

Great work! (Ann, your input was especially valuable. If you haven't joined the Accessibility Group, please do!)

After re-reading through How to Meet WCAG 2.0 (2.4.1) it would seem to me that providing skip links is not * necessary * for WCAG 2.0 compliance, as core themes use headings to mark the beginning of content. Changing issue status.

@Everett, just to clarify, you're changing the category of this issue (from "bug report" to "feature request"), not its status (which remains "needs work"), right?

@Mike, regarding "skip-link," I wonder if we should play off the title of the related WCAG 2.0 success criterion. That would give us "bypass-block." And actually, that's the function: The link bypasses a block of content (although not necessarily in the Drupal sense of "block"); it doesn't skip a link.

Just a thought.

@Mike et al, doesnt look like anything there for Stark / Drupal core page.tpl.php, are we holding off on that?

@Cliff, I'm kind a liking that idea, could be tad confusing with Drupal "blocks" and all.

Stark uses the core tpl files:

/modules/system/page.tpl.php

I agree about not dragging out a conversation on this, Mike. I wonder if simply "bypass" or "bypass-for-accessibility" would be better. But so we can avoid dragging it out here, I've created a new discussion in the Accessibility group.

Let's figure out the best name for the class there and save this space for patches that get us closer to fixing the technical issues. Sound good?

@Cliff, actually I don't agree about moving the converstion over there, skip-link or skip-navigation is well understood by everyone and the vast majority of themes (drupal or not) use something like that - the end game of getting this into core is more important right now than some semantic back and fourth over class naming.

Just google both terms - "bypass block" will earn you nothing about accessibility, whereas googling "skip link"...

Sorry to be so blunt Cliff but this has been dragging on for 8 months to get basic skip links into core, lets move on.

I dont see any reason to stick to the version 4 CSS, if something better comes along or different then great, the molly method looks solid.

Why CSS for system.css - I mean why are we hiding this in Stark? I really think this should show.

Mike, I have some time this evening and can test out the molly method.

OK, so looks like I've been away from D7 dev for a while... and it kind of slipped my mind about html.tpl.php and $page_top, so first off I would contend that the skip link no longer belongs in page tpl but must go in html.tpl.php so that it comes before the new dashboard for logged in users.

This would actually simplify things since all 3 core themes pull the default html.tpl.php from the systems modules directory.

The second thing is that it could be very tricky to support hover and tab/focus in the existing themes, Seven I think we can forge a change for but Garland I am less sure about.

@Jeff: First, I must admit that I hadn't thought of searching the Web for "skip link." Perhaps if the person who first proposed the term had pointed out that a search for "skip link" (in quotes) produces 527,000 hits, the overwhelming majority of which deal with precisely this matter, neither Everett nor I nor anyone else would have given a second to trying to come up with an alternative. Both of us could have used that time to reflect on better answers for vertical tabs.

But I have to take a minute here to say something else.

<venting>
It's odd: Developers and reviewers get grouchy when people who have an interest in an issue but can't contribute to the code add their concerns about semantics, their "+1s," their insight into usability issues, and similar comments here in the issue queue. It raises a flag that there is a new comment on the issue, and reviewers and developers alike burn precious minutes finding and reading a comment that turns out to be of little interest to them.

But we also can't discuss these concerns elsewhere. So how, then, are the non–propeller heads among us to offer our expertise — which would cover the stuff that doesn't affect the tags so much as it affects what goes between the tags?

I know a lot of people are burning a lot of free time trying to get things done before freeze. I myself have been getting far too little sleep the last two weeks and using my lunch break to stay involved during the day.

But telling people not to have discussions that interest them is not a way to ensure that Drupal is more usable. And it's certainly not a way to encourage more and broader participation in keeping the community plumbing working. ;-)

And if the semantics can be addressed after code freeze, what does it hurt for those of us who are deeply interested in semantic issues to hash things out a bit so we can have a more well-formed idea ready for the rest of you to review when time comes to think about (if only as a final check) these matters? You don't have time to talk about it now, but perhaps we won't have time to contribute our thoughts later.
</venting>

Ok, heres a first crack at moving the skip link to html.tpl.php. We need to do this so its the first link on the page no matter what, otherwise the dashboard is above it in the source order.

I kept the v4 styling for Garland as this seems to work, if we have a suggestion for a method that can support hover/focus that would be great.

For Seven I went a different route and made this is permanent visible link, like a button.

Stark/default gets no CSS.

From what I can recall of my earlier testing with the Garland method it was solid across browsers, bu the Seven stuff is all brand new and I have only used this theme for about 2 hours, so we really need some browser testing.

Dang nabbit, the above patch (v6), I forgot to add in the name anchors for page.tpl.php.

V7 is the one:

I like it. (In other words, it does everything it should.)

Great work, Jeff!

Unless someone can really quickly code the option Mike mentioned (the one that would work with hover in Garland), I say we move this on to RTBC.

Tested the skip to main content link in stark, garland and seven. Appears to be positioned and working correctly.

I have a strong preference that the link remain visible on all themes, it absolutely must remain visible on stark, as this shows themers the most appropriate implementation.

subscribing

Visible on focus is acceptable. It's also accessible.

For the more visually inclined, here are some screenshots:

Seven:

Stark:

Garland: N/A. It's invisible by default, and although the replies here seem to imply that it should become visible when it gains focus, that doesn't appear to ever happen for me in Safari when I'm Opt+Clicking around the page. What am I missing?

I'm curious what was the justification for having the skip link visible in Seven? This comes from the source code of the great W3C.org itself:

<span class="invisible"><a class="bannerLink" title="Skip introductory links and the mission statement" href="#technologies">Skip to Technologies</a> |</span>

And on canada.gc.ca, it's styled to be invisible (by making the font the same colour as the background).

It seems like it adds more visual clutter to the page, and pushes the contents down unnaturally for the 90%+ of users who will never use it.

Feel free to point me at specific replies that cover this, but I scanned through and only saw what looked like some personal preferences from Ann and Everett.

I messed about with Chrome and came up with a variation that works, at least, in Chrome, appears that if an element is height:0; webkit cant focus it.

Keeping links on the screen is the best possible scenario for users who do not use screen-readers but rely on skip links to bypass navigation blocks. There are many issues that surround this, far to many to debate here in this queue.

On the http://www.w3.org/WAI/ site skip links are shown by default, but in the test procedure for passing WCAG 2.0, Bypass Blocks 2.4.1 the wording tells us skip links should either be visible all the time or at least visible on focus. http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G124.html

The thinking to show by default is why not - showing by default can be a great help to many disabled users. As for visual clutter - well, the skip link is lot smaller than the dashboard, which I would assert, for this user at least, is little more than visual clutter ;)

Dang, I was banging on so much I forgot to attach the new patch...

Fixed for Chrome (hidden link in Garland wouldnt take focus). Need to test in Safari and Opera.

@webchick, the rationale for making the skip links visible is to make them available to sighted people with mobility impairments and people who simply prefer to navigate with the tab key. That is an often overlooked population when people think of accessible design. I could go on, but perhaps these synopses (on 456 Berea Street) with links to other discussions will enlighten better than I could:

• Skip links: Visible or hidden?
• Skip links need to be at least temporarily visible

Or for even more, Google "visible skip link".

Bottom line: Everett and Ann aren't expressing personal preferences; they're encouraging us to go where few have, but all should. By the way, this layer of accessibility will in and of itself make a site work better for people viewing it on mobile phones and other small-screen devices. That's more than a small percentage of users these days, right?

I like the way you put it there Cliff - "they're encouraging us to go where few have, but all should", that is what I tried to say with "why not", that is what I mean.

My approach in Seven was to incorporate the skip navigation as a design element, as an intrinsic part of the overall design, to not relegate it offscreen because it doesn't fit our sense of divine aesthetics. It should be, and needs to be, part of the new aesthetic.

Cool, thanks for the resources behind the decision. That's what I was missing.

I'm fine committing this when it's back to RTBC (assuming that Garland issue is fixed).

I'd just like the reiterate that the issue raised in #60 is a browser issue not easily solved in Drupal if at all, the same thing happens when you click the comments link in node teasers - the page will "jump" to the comments but tabbing thereafter begins at the top of the document, this is a webkit flaw which Chrome has not yet fixed.

Huh. I totally forgot I'd said I would commit this before. ;P The screenshot at #60 scared me because that looks oog-lay, but I just checked and after clearing the cache the link remains visible. I did confirm that it shows up with CSS disabled though, which I presume should be good as far as screen readers are concerned.

Committed to HEAD. Great work, all!

This should be documented in the theme upgrade guide: http://drupal.org/update/theme/6/7

I added a link to http://drupal.org/update/theme/6/7#element-hidden

I am somewhat dazzled by this commit. It seems like even the resources, point out that its an unpopular design decision. Why would core enforce such a standard, if we already are already aware that many people won't like it at all? The resources are worse, in the perspective that none of them seem to actually implement their own suggestions? I am really not getting this patch, the actual usability argument is very questionable..

I am really getting worried by large visual patches, getting only accessibility feedback and none whatsoever on the large ascetic changes that are made.

> Most people won't see it at all.

- I's part of Seven, so you will see it in all admin pages

I really do not want to duck accessibility issues here: not-visible anchor link is great to have in core and it helps to follow best practices (and it makes sense in Stark), but I really doubt introducing a visible skip link in Seven is making us a favour here. Extra confusion for mayority of users and visual/ux noise imho does not justify the decision. I tested 2 users (not visually impaired though) and confirmed every time the case 'Clicking it on "skip to main content" does not "do" anything'. It is definitely not representative enough but I'd strongly suggest to remove the visible link from Stark. D7 looks and feels complicated enough, every new UI element introduced makes things worse.

I think kika means Seven and not Stark. I'd like to keep it in Stark, so it's in themers' faces as something to care about.

However, I'm inclined to agree. We probably do indeed need to hide this link by default with Seven's CSS. :\ Esp. with the Overlay this gets really confusing.

I tend to agree with Webchick et al regarding Seven - the original patch (from my point of view) was a demonstration and was meant to spark discussion and debate, and I am glad it was committed as it has had the desired effect.

For Stark I'd like to see it stay as is, but I have opened a new issue/feature request to add a new theme setting to show/hide skip nav like the other UI elements (site name, slogan etc) - #639460: Evaluate CSS of #skip-link, .element-focusable, and upcoming "disable overlay" links for their impact on contrib/custom themes

@mcgifford The resources pointed out in #57 and this part "Bottom line: Everett and Ann aren't expressing personal preferences; they're encouraging us to go where few have, but all should. By the way, this layer of accessibility will in and of itself make a site work better for people viewing it on mobile phones and other small-screen devices. That's more than a small percentage of users these days, right?"

I think that kind of paints what I want to say, its going somewhere few designers go - for good reasons. And the usability standpoint, fails mostly on the assumption we need to explicitly optimize core themes to mobile devices.

For Seven I think thats the implementation I don't like, I just saw the screenshot for Garland in #60 wasn't actually implemented. We are adding to much in the header.

Maybe that's the best approach then. Make the Skip to Main Content visible only on focus as per Garland.

Yep, that's what I'd recommend. I do definitely like that it's visible by default in the core page.tpl.php file, because that means that themers will take it into account. But I agree with Bojhan on the clutter aspect, as well as kika in that most users will click it and experience "the link didn't do anything." The usability trade-off is not good.

For the Overlay accessibility issues, we can discuss that in the other issue.

+1 for @mgifford's suggestion to make 'Skip to Main Content' invisible until it receives keyboard focus.

The concerns about cluttering Seven's interface are valid. If we adopt this suggestion, keyboard-only users who tab onto this link are the only ones who will likely see it appear, and they will greatly appreciate a link to jump right to the content. The visual appearance and location look good as-is, so long as it starts out invisible.

Good, so can we remove it from Seven header then? Is it complicated?

Yes, that addresses my concerns.

Example patch to hide skip link in Seven, might want to wait on #639460: Evaluate CSS of #skip-link, .element-focusable, and upcoming "disable overlay" links for their impact on contrib/custom themes possibly.

I knocked it up in Fx3 in 1 minute so needs rigorous testing in browsers, loath to post another failing patch today as Eclipse has decided to go nuts on me and use win line endings...

@Jeff: Could you screenshot that please?

Also, needs review.

Attached screenshot.

This is a rough idea really, just a proof of concept and needs discussion.

Another concept would be to do a more "floating" type link such as Garland has now, and position this center top (mabey 100px or so from the top) so it appears to float over the over content, I will write a patch for this second concept as I think it looks better and is more usable.

For now heres a screeshot that shows the effect of the code in #79

using FF 3.5, the link does not show on hover for me, nor do I see any way to get it to appear by tabbing. It does, of course, hide the link.

BTW, I have no idea how to get Firefox to navigate to all links while using the tab key. And a google search failed to find anything useful for me.

However, using Safari you can Option-Tab to navigate all links on a webpage. The first link that you tab to should be the skip link.

Unfortunately, something about overflow:hidden, I think, was totally preventing Safari to navigate to that link. It would skip straight to the toolbar links.

If I use the CSS from Zen 6.x-2.0-beta1 for the skip-link-focus effect, Safari can navigate to the link. I haven't tested in IE/win.

Here is re-roll of Johns patch,

just a few minor changes:

1 - centered the link in the middle (see screenshot below)
2 - added width: auto to #skip-link {}, which gives better support to IE6, which aint that good to be frank

Otherwise its pretty much the same, I did use left: -999px instead of top negative margin to hide it, but not sure if it really makes any difference, I cant see horizontal scrollbars in any browser.

I'm stumped as to how to keyboard navigate Safari in windows, cant find anything on it at all.

Let the bot god be with me...

Thanks Mike, just to be clear here (for webchick et al) this patch hides the skip link in Seven by default and then it shows on tab/focus

Works perfectly as is in Firefox and IE7/8, works sort of in IE6, Safari (windows) I cant work out how to tab anything, Opera's shift + arrow navigation fails.

Committed to HEAD. Thanks!

Heres my blurb from Skype...

modern browsers can use the ID, so if theres an ID on the wrapper div we need to jump to you can use that, I think Garland did not have an ID, such as #content, which is what the dedicated anchor was added
[04:30:48] Jeff Burnz: which is why..
[04:30:51] Jeff Burnz: sorry, its late
[04:31:44] Jeff Burnz: eg in Genesis theres no named anchor, it uses the ID on the wrapper div around content
[04:33:57] Jeff Burnz: at a pinch in Garland we could use id="center"
[04:34:27] Jeff Burnz: which is pretty close, although the breadcrumb is below that in the souce which may not be a bad thing
[04:35:30] Jeff Burnz: in core page tpl its easier - use id="content"
[04:35:51] Jeff Burnz: so what I am saying is simply remove <a name="main-content" id="main-content"></a>
[04:37:53] Jeff Burnz: the problem here is Garland is inconsistent with the core page tpl id naming and does not have a html.tpl.php file to special case in...
[04:39:48] Jeff Burnz: let me try another work-around...
[04:43:18] Jeff Burnz: well this seems to work in Firefox at least and validate...
[04:43:20] Jeff Burnz: <p class="element-invisible"><a id="main-content"></a></p>

You forgot the link in modules/system/page.tpl.php, attached patch fixes it. RTBC, IMO.

Checked this out on @mgifford's test site. The patch solves the problem it's intended to solve. That the page fails W3C validation turns out to be an unrelated issue, http://drupal.org/node/655306. @Frando, thanks for pointing out this new issue.

Restoring name and category of this issue and setting to RTBC.

Committed to CVS HEAD. Thanks.

+++ themes/seven/page.tpl.php
@@ -1,7 +1,7 @@
-  <a name="main-content" id="main-content"></a>
+  <p class="element-invisible"><a id="main-content"></a></p>

Why a paragraph? And not a DIV container?

I'm on crack. Are you, too?

Please do :)

A DIV will be better since its unlikely to require any special CSS to override a global margin or padding applied to paragraphs, which is pretty normal to do. My original P was just a quick test to see if the named anchor would still work with element invisible applied to its wrapper (it needed to be a block level element and P sprang to mind at the time). Apologies I cant write a patch at this moment.

Committed to CVS HEAD. Thanks.

Looks like this needs a review.