A client of mine recently asked why the "skip to main content" link is hidden by default in Seven (and all other themes). According to them (major university that does a lot with accessibility), the preferred recommendation these days is to always show that link; just because someone's eyes are working doesn't mean their hands are, for instance, and they don't want to have to tab past 30 navigation links. (Their example.)

Curiously the skip link is well-themed already. We can easily show it by overriding the html.tpl.php template and just removing the element-invisible class, but then we're subtheming Seven just for that, which seems odd. Given that it's already themed out, making a checkbox in the theme settings page seems more logical to me.

Would this make sense to anyone else before I try writing it? And if so, could this be backported to Drupal 7? (Yes it's new UI strings, but only NEW strings.) I'd rather not have to give my client a patched Seven just for that.

Files: 
CommentFileSizeAuthor
#42 toggle_skip_nav_1328770_42.patch1.76 KBmgifford
#40 toggle_skip_nav_1328770_40.patch1.77 KBmgifford
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Invalid PHP syntax in core/modules/system/system.module.
[ View ]
#18 Screen Shot 2012-01-22 at 10.36.58 PM.png89.69 KBmgifford
#18 Screen Shot 2012-01-22 at 10.35.56 PM.png85.29 KBmgifford
#14 toggle_skip_nav_1328770_14.patch1.61 KBwatbe
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch toggle_skip_nav_1328770_14.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#11 toggle_skip_nav_1328770_11.patch1.6 KBwatbe
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch toggle_skip_nav_1328770_11.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
#7 toggle_skip_navigation_link_visibility_1328770_7.patch1.6 KBwatbe
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch toggle_skip_navigation_link_visibility_1328770_7.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Comments

I very much agree with the idea of making skip to navigation links visible. They are also useful for mobile users.

I see no reason not to expose this as a theme setting.

Title:Allow "skip to navigation" to be visibleAllow "skip to main content" to be visible

And of course I got the label of the link wrong... :-)

I'd love to see these links be visible to all. Currently they should appear (magically) on focus. But, that is terrible discoverability.

Alternatively a theme setting would be great.

My preference would be for having these be visible by default. There could be a theme setting to change that, but it would need to explain the harmful accessibility impact of doing so.

This is another issue, but navigation should come after the content in the source code. In some cases, it makes sense to have a skip to content as well as a skip to navigation link. Many sites also have local and global navigation: personally, I like providing a separate link for each.

Issue tags:+skip navigation

Adding tag after rethinking some of how we manage skip text - http://terrillthompson.com/blog/161

Title:Allow "skip to main content" to be visibleAllow "skip to main content" visibility to be toggled.
Status:Active» Needs review
Issue tags:+DDU2012
StatusFileSize
new1.6 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch toggle_skip_navigation_link_visibility_1328770_7.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

This patch allows the user to set visibility of the skip content linkwithout 'tabbing'. It defaults to being selected (so the link is visible). It that if the setting is not selected, the skip to main content link is still there (but requires TAB to focus).

I'm not sure about the naming of the variables or the setting so please review!

Status:Needs review» Needs work
Issue tags:-accessibility, -skip navigation, -DDU2012

The last submitted patch, toggle_skip_navigation_link_visibility_1328770_7.patch, failed testing.

Status:Needs work» Needs review

Status:Needs review» Needs work
Issue tags:+accessibility, +skip navigation, +DDU2012

The last submitted patch, toggle_skip_navigation_link_visibility_1328770_7.patch, failed testing.

StatusFileSize
new1.6 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch toggle_skip_nav_1328770_11.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Not sure what is wrong.. I'm using git diff > name.patch. Rerolled.

Status:Needs work» Needs review

Apologies for the spam, I'm still new to this.

Status:Needs review» Needs work

The last submitted patch, toggle_skip_nav_1328770_11.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new1.61 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch toggle_skip_nav_1328770_14.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I didn't checkout properly.

This issue needs more input and discussion on whether it should be included. I don't think a backport is warranted because it does add new UI fields and would not respect current settings (as it defaults to being ticked).

So what are people's thoughts on this? I think from an accessibility point of view this is a necessary addition for people with motor disabilities but are not visually impaired (and thus not using a screen-reader). We should probably also consult WCAG

Issue tags:+wcag2

WCAG 2.0 recommends that the link be visible at all times but does not mandate visibility:

It is preferable for links to be visible at all times, since users navigating via the keyboard include switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software. However, Success Criterion 2.4.1 does not require that they be visible when they do not have focus, and links that are visible only when they have focus can meet this success criterion.

Quote from: http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G1

I think visibility is a good position as it will bring awareness to other themes as well. The recommendation makes sense and I don't find the link too intrusive.

A backport that defaults to off, while Drupal 8 defaults to on, seems like a reasonable approach to me.

Looks great. Here's a screenshot from Bartik & Seven.

It's a really simple addition.

I'm not sure if having differences between d7 and d8 defaults the right way, because it might confuse people upgrading?

Status:Needs review» Reviewed & tested by the community

Well, let's get it into D8 first. After that we can talk about how to bring it into D7. Might even be through the accessible helper module or something like that. http://drupal.org/project/accessible

Patching the accessible project seems like a good way forward for D7, it gives the current users control over the change. Thanks for reviewing it.

I personally think it is visually distracting and unusual. I'm not convinced this should be a theme setting. Why not let themes overwrite it instead?

Dries: Because it makes no sense to subtheme Seven just to enable an accessibility feature that we already have built into the template, especially since WCAG says that it should be visible. You should not have to subtheme Drupal's administration theme just to enable a feature to follow W3C guidelines on accessibility.

In response to the 'visually distracting' part, we could move the link off to the side to make it less intrusive. But otherwise I agree with Crell, this is a WCAG 2.0 recommendation and should be integrated as default. The location of the setting makes sense and could be easily turned off as well.

Status:Reviewed & tested by the community» Needs review

Let's look at moving the link to the side, it does look a bit distracting right in the middle of the screen like that.

@catch - this would be the placement then for the skip link in general, right. If we move it to the right or left we'll need to include CSS to reverse it for RTL langauges. I'm not at all opposed to the idea, but would like a design/ux person to propose what it might look like elsewhere.

Issue tags:+Usability

I agree with Dries, this is quite an unusual and distracting visual element on the page. This is a very important point, we should take into consideration, hiding it was a deliberate decision - because it is so unique and distracting. If you look at major other sites that implement it - its often tucked away visually (even the W3C site, which makes it nearly as discoverable as tabbing).

It is relatively easy to override, so in cases like Crell's where its desirable to show at all times - it is possible. I am not sure adding checkboxes, so people can choose to follow W3C rules or not is desirable - I have seen this in other systems, and it gets nasty quite fast.

I wonder with the inclusion of HTML5 ARIA roles, that this is even necessarily for D8? To me this always felt like a nasty hack, that should be solved by screenreaders not up to individual systems to include or not.

If we do want to show these links by default, we should actually design for it. Not just remove the "element-invisible" class. Which also makes me wonder, why this was put on RTBC without a visual review? I am a bit sad, that after repeating myself a thousand times in D7 that visual changes, should get visual review - it still happens, that visual changes get pushed to RTBC without review.

Hi @bojhan

I agree with Dries, this is quite an unusual and distracting visual element on the page. This is a very important point, we should take into consideration, hiding it was a deliberate decision - because it is so unique and distracting. If you look at major other sites that implement it - its often tucked away visually (even the W3C site, which makes it nearly as discoverable as tabbing).

W3C does not profess to follow the recommendations it supports. Using W3C or any other 'major' site as an example is an appeal to authority. You'll need to substantiate why we ought to use any particular site or group of sites as an authority, how do we know they have it right?

wonder with the inclusion of HTML5 ARIA roles, that this is even necessarily for D8? To me this always felt like a nasty hack, that should be solved by
screenreaders not up to individual systems to include or not.

'Skip' links are far more important for sighted keyboard only users than they are for screen-reader users. The overwhelming response from accessibility professionals (again an appeal to authority) is that skip links are necessary and that it is recommended that they be visible.

@Everett We have had this discussion before, on a lot of the other visually impacting accessibility issues. We are not to draw conclusions from how other, even major sites implement these features - but are required to implement it because we otherwise violate the WCAG. I understand this position, but I am also a bit lost how other than our own experience - we are meant to make decisions on this.

The reason we look for authority on this, is because I have no experience of seeing people use these links - nor do I know of any solid usability research that explains how people use these. If we design something, we should always be fully aware of who we are designing it for and what their behavior and desires are.

I would like to explore this more, because you mention they are necessary - but do not express in what context of use (it was my impression it was mainly for screenreaders, am I wrong?). I do still wonder, why other websites tuck them away; 1) is it because they are only implemented, to follow WCAG, 2) is it because users specifically look for the keyword, hence not express an ordinary browsing pattern, 3) is it because of positioning, people look for the skip links in a specific place? etc.

@Bojhan

You are correct, there is little usability research on this that I am aware of.

1. Will a lack of skip links cause a site to fail WCAG 2.0? Yes, although this is actually subjective, the majority of accessibility pros that I know would likely build consensus on this.

2. Will a skip link visible only on focus cause a site to fail WCAG 2.0? No, WCAG 2.0 is explicit about this.

Many people do wish to make the link visible, which they believe to improve the experience of some users. We do not need a UI option for this, and I don't know if it should be included in core (no opinion).

Screen-reader users are not the primary audience of a skip link, although some do use them. Sighted keyboard only users (users who can see, and cannot use a pointing device) are a major constituency for skip links.

You are 100% correct, if we are going to implement this we must do it right, and that requires research into where the link should be positioned. I also think that the link should be visible on focus by default, and admins should have to enable it to be always visible. ** This is not because I think that this benefits accessibility, but that it benefits product adoption.

If I recall rightly when we first put these into D7 there was a lot of discussion on this topic, and in fact when I wrote the first patch for Seven the link showed by default, it was smaller and over on the right, at the very top. That got the axe pretty quickly and we did not argue because we had so many other a11y issues and we really needed the skip-links-in-core patch to land.

Now, the reason it was moved to the center and is quite large is simply... toolbar. Toolbar is a major visual distraction, and if you have shortcuts module on then even more so. If it was only going to show-on-focus then it needed to stand out like proverbial dogs balls. I wanted it to be visually brutal (there is no point in being coy when it comes to contrast or color clashes when working in accessibility), however to appease the designer in me I chose complimentary tones and colors. When it shows its obvious but not clashing with the surrounding theme. Look at Bartik, we even used rgba to give a subtle tone to the dark transparent background of the link. So the combination of size, colors and position achieve the design goal - to be obvious when focused.

What should be clear is that we thought a lot about the design of the skip link from the perspective of it being hidden by default, and that it should a) be noticeable enough so its not easily missed when focused and b) generic enough to be visually appealing in most color schemes - talking about Bartik here, in Seven I chose warm grays to compliment Sevens palette.

If this should show by default in Seven then it needs to be redesigned - the current patch is an abomination, a travesty of design and lack of understanding of basic design principles. Its a simple design principle that something that is little used but occurs frequently should be minimized - even to the point of being hidden altogether until required, which is why this argument is so controvertible.

If this is going to show by default, which in theory I support, it should be as small as we can get away with, as low contrast as we can get away with and offset right to lower its prominence. It can show more vibrantly on focus. Take inspiration from our "Show row weights" link on tables - its small and offset to the far right so as to minimize visual pollution.

Certainly this should not be shown by default in Bartik. That I would sternly object to. Seven, OK, I think its doable, but, and its a big but, it has to work with Toolbar and Shortcuts - these are big meaty visual distractions and the design of Sevens header is supposed to be very clean, it does not lend well to dumping a link in there. There might be an additional reason here to completely rethink Sevens header, if its not being worked on already (which I know it is). We all know the right aligned tabs are all but invisible - something to consider.

We don't need a theme setting for this - that would be an excuse for poor design in the first place, albeit a perfectly reasonable and logical solution from a programmers perspective. If we can get the design right it will work and everyone will be happy - that is the objective and task of the designer, so lets design, and stop writing code until we have the design perfected. We can't just dump in this link, the entire header design has to work - design is never good when something is simply tacked on the side.

the current patch is an abomination, a travesty of design and lack of understanding of basic design principles

I don't know how carefully you read the thread, but the current patch represents the work of a new contributor (thanks watbe!). Heated rhetoric like this doesn't make the issue queue any friendlier.

If we can get a design that leaves the skip link visible and makes everyone happy then that's great. If we fail at that, I'd at least like to see the theme setting get in, so people don't have to subtheme.

OK ok, its rhetoric, but passionate also, and not meant to criticise watbe, but rather my own design. Welcome watbe, my fellow kiwi!

I have some design ideas I am working on now. There's another issue open regarding the visibility of the tabs and breadcrumb position, in which Bojhan and Jeff Noyes have presented some interesting redesign ideas: #763720: Visiblity of primary & secondary navigation, ideally other issues should be taken into account, i.e. a holistic approach to redesign the header area.

The toggle is a reasonable compromise but more UI and just more stuff to get to grips with in theme settings. We're at that interminable crossroad of whose "X" is more important. FWIW I would prefer toggle settings went away entirely in D8, rather than adding more. Other issues, I know.

I wonder if there could be a compromise here where the skip links were always visible, but were diminished so that they didn't interfere with the usability of the page. If the link is smaller & without the contrast that it presently as when it is on focus right now. When a user navigates (without a mouse) to the skip link it would have some basic animation that would make it resemble what it does now. It would be more discoverable without being that much more clutter on the screen.

It would be interesting to see in contributed themes & in live Drupal 7 sites how often skip links are preserved. It's in core because it is a best practice. It's a best practice as @Crell (essentially) states to have it visible all the time.

Priority:Normal» Minor

At the A11ySprint we all agreed this was a great idea. However, it's not a major challenge, so dropping it back to minor.

Status:Needs review» Needs work
Issue tags:+Usability, +accessibility, +skip navigation, +wcag2, +DDU2012

The last submitted patch, toggle_skip_nav_1328770_14.patch, failed testing.

Title:Allow "skip to main content" visibility to be toggled.PLEASE STOP!!!

It's awful!!!
This "skip to main content" was indexed as main content by Google, not as NAVIGATION, i mean russian version to be exact.

Sites without Description (i guess) meta-tag have this exact phrase in Google's SERP!!!

It is a deadly sin from SEO's point of view.

To verify it by yourself try to search "Перейти к основному содержанию." (exact phrase in quotation marks): "Перейти к основному содержанию."

http://www.google.ru/search?q=%22%D0%9F%D0%B5%D1%80%D0%B5%D0%B9%D1%82%D0...

more than 9 millions results!!!

Title:PLEASE STOP!!!Allow "skip to main content" visibility to be toggled
Priority:Minor» Normal

Resetting title.

Issue summary:View changes

Correct the string we're talking about.

Issue summary:View changes
Status:Needs work» Needs review
StatusFileSize
new1.77 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Invalid PHP syntax in core/modules/system/system.module.
[ View ]

needs more work, but...

Status:Needs review» Needs work

The last submitted patch, 40: toggle_skip_nav_1328770_40.patch, failed testing.

StatusFileSize
new1.76 KB

arg.. cut/paste problems.