We need to come up with a good name for a CSS class, but I don't want this discussion to clutter up the issue queue. (Let's reserve the queue for presenting and discussing patches that fix functional or programmatic problems.) So I'm posting this item to see if we can develop an idea that is better than the ones we've already come up with.
An important feature request for Drupal 7, Skip Navigation' should be in all core themes, provides one way to ensure that Drupal-based sites can comply with WCAG 2.0 Guideline 2.4.1, Bypass Blocks:
A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.
Part of this patch involves naming a class for the links that perform this function. The working name for this class, "skip-nav," is bad because:
- The abbreviation "nav" raises problems.
- This function can actually be used to let people skip any part of the Web page, not just a navigation menu. (So "skip-navigation" doesn't work, either.
So, we're wondering: What would be a better name for this class? Following the name of the WCAG Guideline we are addressing would give us "bypass-block." But, because "block" has a more specialized meaning in Drupal, that doesn't quite work.
How about simply "bypass"? Or "bypass-for-accessibility"?
Or a better idea of your own?

Comments
goto-content-area, scroll-to-content-area
My bet is to focus on the thing you'll get by following such a link, not the thing you're trying to bypass.
Still, better in the issue queue
It's not clutter, it's what it's meant for, and changing this class name would require a patch just the same. We've seen a couple of times now where solutions are thought of outside of the queue, only to see the whole of the discussion get repeated in the issue queue. Just a bit of friendly advice :)
Hmmm.... "where" and "what"
@yoroy, I appreciate the advice, but I'm confused. You were just complaining about my having brought up usability under another item in the issue queue. By moving this discussion here, I'm yielding to @mgifford's request that we not have this discussion there. The way I see it, he's doing the heavy work on this item, so it's important to respect his wishes. He doesn't want us to tie up his time having to check posts that are only about hashing out what words he uses for this class name. For those who are interested in both this discussion and the coding aspects of this issue, just as I linked to the item in the issue queue from this discussion, I linked to this discussion from that item. So those folks can easily find both discussions, and Mike and anyone else who needs to focus on the coding doesn't have to waste valuable minutes finding out that the last umpteen comments for the issue all had to do with the name of this class.
@markus_petrux, if we were talking about terms that would appear in the link text, I would agree: Identify the destination, not the stuff you're avoiding. But for this class name the problem with identifying the thing you'll get is that it varies. In fact, it's conceivable that links that use this class will take you around content to get to navigation — or around content to get to a form. The destination depends on how the themer has built the theme and how the developer has built the page. (The same situation makes it difficult to specify what you're avoiding.)
That said, almost always this element will be used to bypass content that is repeated on similar pages. Usually that would be navigation. Sometimes it might be a toolbar. It might also be one or more blocks in the Drupalese sense of the term. Isn't "chrome" used to refer to that kind of stuff — the stuff that stays (mostly) the same page to page and frames the part that changes?
So how about "bypass-chrome"?
Ah well I meant 'not in this
Ah well I meant 'not in this specific issue' but in another, new issue, and I would guess mgifford implied the same. If I sounded complainy in the read-more issue it's because how that specific issue went down: 100 useless +1s, then actual life and activity, then rtbc at comment 200, then the beginning rehash of part of the discussion, where I was aiming to get that patch back to rtbc-able state first instead. So it goes.
All of which means we need to rethink the issue queue
People should be able to +1 issues they care about. But developers and reviewers shouldn't get the same signal ("X new comments") from a +1 as they get from a patch. So there ought to be essentially a polling widget for each issue, where people can vote +1 or -1. And maybe after you reach some threshold of +1s have an automated message go out to all who did so: "You said Drupal needs frilly lace, and 24 others have agreed with you so far. What expertise can you contribute to solving this issue?"
For that matter, it should be possible to have a discussion about semantics or look-and-feel separate from code. So maybe each issue needs multiple forks:
(That last item seems to have the password-checker issue chasing its tail. It would be real nice for the structure of the queue to make it clear that all the functional concerns have been addressed and that the only active discussion involves what brand of sparkling wine should be smashed across the bow.)
I just don't see how making the wording a separate issue, which will cause people who are new to following issues to have trouble piecing the whole picture together, is better than saying, "Hey, let's chase this rabbit without inflating the main thread and bring whatever decision we reach back here when it's ready." If the patch gets committed before the wording gets worked out, then start a new issue.
Here's an illustration of the problems that arise when small variations get interpreted as being different issues: I've been participating in the issue about accessibility of vertical tabs for a month or three. Just today I discovered that there are about a dozen other issues related to vertical tabs. Some of them seem to be working the same ground we've covered. After a quick check of a couple of them, I see that they clearly have implications for accessibility of the interface. But I need more time to sort it all out, especially if I'm going to stay up to speed on the password checker, the skip links, and all the other issues I'm invested in.
Those relationships between issues can't be easily recognized with the current system. It's like the fable of the blind men and the elephant, except that in this case we have no idea that we're all working on the same beast.
.skip-links
These things are usually called "skip links," so how about we call the class "skip-links"? I suspect that's what people with readers are expecting to hear, and it allows us to put in all kinds of links -- not just nav-related ones.
Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross
"Bypass" v. "skip"
Just caught up on the debate in the issue queue re: "bypass" v. "skip." Not only have I always heard these referred to as "skip links" and have never, ever heard "bypass block," the very pages cited as guidelines for this feature consistently say "skip links" or "skip navigation":
http://www.webaim.org/standards/wcag/checklist#sc2.4.1
http://www.webaim.org/techniques/skipnav/
The latter is an especially clear example. The word "bypass" only appears twice on the page (once as "bypassing"), and every example of actual implementation uses the term "skip."
I say we stick with "skip links." It makes intuitive sense, is in wide use, and is the terminology used by the guideline authors.
Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross
Good points, Todd. Thanks!
The more I think about it Todd, the more I agree. "Bypass Blocks" comes from the newer guidelines, WCAG 2.0, and the W3C's own guidance. But, still, I think "skip links" is fairly well-established terminology. Besides, the point of this CSS class is to style the link that lets you skip over something to something else. As mentioned above, "something" and "something else" can vary widely, so there's no point in even trying to address that concept in the class name.
page-links
Lately, I've been re-thinking skip links as page links. Instead of skipping to the content or skipping to the navigation, these links point to the most common destinations on the page.
For example, I used to have:
And now I use:
These links are still hidden for most visitors, but screen readers and mobile users now have more meaningful links to what their looking for on the page.
@dcmouyard on Twitter
Great approach!
dcmouyard, your solution shows that you really get the point of the guidelines. The purpose of these links is to get people to the information, not to get them around stuff.
Themers could take it a step further by building a flow something like this into the html behind their themes:
In other words, regardless of where CSS makes each of these sections appear on the page, make sure that the tab order and the order of appearance of each section in the page code is as shown above. Then all kinds of users will be able to get to the heart of the page quickly.
The point of this guideline is to get folks straight to the content they want. Designing the page with that in mind is so much better than leaving obstacles (site navigation, site search, and so on) in the way and then adding a bypass so people can avoid them.
Stick with skip-nav
I come to this issue linguistically. "Skip-nav" is the term now used. It's not perfect, but it's not so bad -- it's unique, hard to confuse with any other concept, and most of all, it has spread throughout the accessibility community and its resources. If you change it completely, many people will not know what you mean, will wonder why you changed the term and if that change implies some new concept (which it doesn't). Think of the hundreds of times someone will say "What the heck is [new term]?" "Oh", comes the reply, "that's what the Drupal folks call skip-nav." And the thousands of times there will be no reply.
In my experience even the
In my experience even the most carefully considered and straightforward class names aren't understood by everyone.
Would it be worth considering a hierarchical naming scheming .. where classes specifically implemented for WCAG, are perhaps prepended with WCAG?
That way, the developer / coder would have a prompt to check the specific meaning of the class via a google search or by referencing documentation.