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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

RainbowArray’s picture

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

ksenzee’s picture

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

Crell’s picture

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

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

Everett Zufelt’s picture

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.

RainbowArray’s picture

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.

mgifford’s picture

Issue tags: +skip navigation

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

watbe’s picture

Title: Allow "skip to main content" to be visible » Allow "skip to main content" visibility to be toggled.
Status: Active » Needs review
Issue tags: +DDU2012
FileSize
1.6 KB

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.

watbe’s picture

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.

watbe’s picture

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

watbe’s picture

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.

watbe’s picture

Status: Needs work » Needs review
FileSize
1.61 KB

I didn't checkout properly.

watbe’s picture

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

watbe’s picture

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.

Crell’s picture

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

mgifford’s picture

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

It's a really simple addition.

watbe’s picture

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

mgifford’s picture

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

watbe’s picture

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.

Dries’s picture

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?

Crell’s picture

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.

watbe’s picture

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.

catch’s picture

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.

mgifford’s picture

@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.

Bojhan’s picture

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.

Everett Zufelt’s picture

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.

Bojhan’s picture

@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.

Everett Zufelt’s picture

@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.

Jeff Burnz’s picture

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.

ksenzee’s picture

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.

Jeff Burnz’s picture

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.

mgifford’s picture

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.

mgifford’s picture

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.

mgifford’s picture

Issue tags: -Usability, -Accessibility, -skip navigation, -wcag2, -DDU2012

#14: toggle_skip_nav_1328770_14.patch queued for re-testing.

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.

TLT-IX-Ilya’s picture

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!!!

Jeff Burnz’s picture

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

Resetting title.

Jeff Burnz’s picture

Issue summary: View changes

Correct the string we're talking about.

mgifford’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
1.77 KB

needs more work, but...

Status: Needs review » Needs work

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

mgifford’s picture

arg.. cut/paste problems.

mgifford’s picture

Status: Needs work » Needs review

I think this is going to get bumped to 8.1, but that last patch didn't get tested.

Status: Needs review » Needs work

The last submitted patch, 42: toggle_skip_nav_1328770_42.patch, failed testing.

mgifford’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Needs work » Postponed
lauriii’s picture

Issue tags: +Seven

Tagging seven since that is related

mgifford’s picture

Status: Postponed » Needs review
lauriii’s picture

lauriii’s picture

Issue tags: -Seven2 +Seven

Status: Needs review » Needs work

The last submitted patch, 48: allow_skip_to_main-1328770-48.patch, failed testing.

lauriii’s picture

Status: Needs work » Needs review
FileSize
4.61 KB

Last patch was based on 8.0.x.. New one with 8.1.x

Status: Needs review » Needs work

The last submitted patch, 51: allow_skip_to_main-1328770-51.patch, failed testing.

Jeff Burnz’s picture

Correct if I am wrong, but I don't think we can change classy, core yes, but not stable or classy?

lauriii’s picture

@Jeff Burnz: I think we should be able to add this even for classy because we don't change the default behaviour; by default the classes and the visibility will be the same. If someone has a overridden html.html.twig template it is not a problem because the setting doesn't work but the site is still working.

Jeff Burnz’s picture

I think the question here is - does this pass the BC test? I'm not so sure it does because as you point out it can create a bug (not to mention it could show a link with no style and potentially break the sites design). I'm all for the change tbh, just raising the issue as something the should be discussed because this is Classy and something we consider to be un-changing for D8 lifecycle, at the very least fully BC if changes are made.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

RainbowArray’s picture

Present me is going to argue with past me.

I don't think we should make the skip link visible by default.

Having the first tab be a skip link is a common pattern. Somebody who uses a keyboard to regularly navigate websites is not going to find this to be a strange pattern, but instead a common convention. So making this visible by default for the sake of learnability does not seem justified to me.

I can also think of very few sites where the client would find showing this link by default to be acceptable.

Creating a theme setting for this also seems unnecessary to me. If somebody really wants to change the visibility of the skip link, they should be able to do so by modifying the markup and/or CSS. I don't think that changing skip link visibility is a common enough task that it should appear on every theme settings page alongside configuring logos and favicons, which are far more common tasks.

Unfortunately modifying skip link markup right now is a bit of a pain because it required overriding the entire html template in order to do so, which seems like wielding a sledgehammer to kill a fly.

What I would like to see us do is to register a new skip-link template where the skip-link markup can live. In preprocess_html, we can then set up a render array that uses that template and pass that as a variable that could live in the html template in the same place where the html markup currently lives.

That would make it far easier to tweak the markup of the skip-link if you want to modify the appearance and/or visibility of this link for a particular theme.

I don't know that we could do that in Classy and/or Stable at this point. Probably not. But we could do so in core/Bartik/Seven to demonstrate how to use that pattern.

I'd suggest we open a separate issue to tackle that change, as it's a different focus than what's been discussed so far in this issue.

helenasue’s picture

After a lively discussion over at the sprint between @mdrummond, @mgifford, and myself about this, we identified that a more important issue with the skip link is that it points to a region that isn't natively focusable. This means that it often doesn't work unless you manually fix it by adding tabindex or another method. I'm going to open an issue for us to take a look at that.

Update: Neat, this was already fixed in D8. :)

andrewmacpherson’s picture

@helenasue In D8, all versions of page.html.twig (in the System module, and all themes except Stark) already contain an anchor element, and this is where the skip-link points.

<a id="main-content" tabindex="-1"></a>.

The tabindex of -1 is there to make it work with Webkit/Blink browsers. It's working fine in Firefox 47, Chrome 50, Opera 38, IE 9-11, and Edge. I'm not sure how well it works in Safari - IIRC there were problems in older versions of Safari where focus didn't go to the anchor even with the tabindex.

For D7, we already have #1529814: Fix skiplink behavior for Webkit browsers, but that issue hasn't been looked at for a while.

helenasue’s picture

@andrewmacpherson Yeah, I see that it's been fixed in D8. Yay! :)

I was looking at that issue and commented that I think the problem might be divs. It looks like along the way the patches made on that issue changed the divs to anchors. Did that fix ever make it in, though? If not, my guess is that that's what's wrong there.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mgifford’s picture

Issue tags: -wcag2 +wcag

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mgifford’s picture

Status: Needs work » Postponed
Issue tags: -wcag

I'd like to see some user research behind visible vs hidden skip links. I don't know that we can make the decision based on the discussions here thus far.