<a accesskey="s" href="#cpw_main" id="sfSkip" class="sr-only">Skip To The Main Content</a>

[programmer6]

FYI - The skip navigation link is a feature for sighted users with motor skills issues (ie not for the blind). So the people looking for this link are not using a screen reader. Screen readers have better ways to navigate a page/go to the content, most common of which is a feature that allows the user to navigate by heading tags.

Long story short you shouldn't style this to be hidden (or give it a misleading class like sr-only).

edit - this is on line 50(ish) in the twbs.master file.

[sitefinitydcx]

Hi Eric,

Is this is 508 explicit requirement? I'm by no means an accessibility expert but as far as I'm aware the acceskey attribute doesn't render/ouput in html.

<a href="index.html">home/a>

renders the same as:

<a accesskey="h" href="index.html">home/a>

So regardless of the disability, it's essentially never 'visible' yet works regardless of visibility, after all we're just hiding what's between the <a> </a> and not change functionality by adding the sr-only class.

The reason behind thesr-only class is so that screen readers will know they can skip over and thus not have for instance the full menu and slider spoken out to them. Same reason why on mobile, inline-form labels are marked as sr-only to give clues.

A quick Google didn't turn up a definite answer but take a look at Wikipedia's quote on accesskey attribute:

In a web browser, an access key or accesskey allows a computer user immediately to jump to a specific part of a web page via the keyboard.

So we're still adhering to that, after all functionality still works and the page continues:

...survey to see if implementing accesskeys caused issues for users of adaptive technology, especially screen reading technology used by blind and low vision users.

Leading me to believe the use of the sr-only class is proper.

I'd be more than happy to change it, reflecting better standards but until then I'm going to stick to the Twitter Bootstrap Accessibility section where they're using the same principal.

[programmer6]

Jochem, thanks for the thoughtful response.

There isn't really a "wrong" answer as accessibility guidelines are guidelines not rules. I feel that the twitter bootstrap folks have missed the mark here but the mere fact that they have something there and can say they attempted to be accessible is probably enough to meet the "guidelines".

Section 508 is a horrible minimum standard as it is very vague and often open to loose interpretation. It is my understanding that 508 has mostly been rewritten to adopt most if not all of the WCAG 2.0 standards and it will be officially enacted within the next 18 months or so.

So that all said here is the WCAG 2.0 guideline that covers this topic (scroll down to sufficient techniques): http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-skip.html

My personal preference is to use a skip nav that is set to visibility:none until it has focus as shown in technique G1 http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/G1: a skip nav that is the first element to get focus on a page and is visible to the user when it has focus.

I then combine it with technique H69 http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/H69: start each content block with a heading to provide easy navigation to screen readers (while keeping my headings nested).

This is exactly what the Twitter Bootstrap Accessibility http://getbootstrap.com/getting-started/#accessibility section you linked recommends as well. However in this section they make no mention of using access keys or hiding the navigation link in any way. So the poorish implementation is in the starting template not the framework itself.

Thanks, Eric Wilson

On Fri, Nov 22, 2013 at 1:57 AM, Jochem Bökkers notifications@github.comwrote:

Hi Eric,

Is this is 508 explicit requirement? I'm by no means an accessibility expert but as far as I'm aware the acceskey attribute doesn't render/ouput in html.

home/a>

renders the same as:

home/a>

So regardless of the disability, it's essentially never 'visible' yet works regardless of visibility, after all we're just hiding what's between the and not change functionality by adding the sr-only class.

The reason behind thesr-only class is so that screen readers will know they can skip over and thus not have for instance the full menu and slider spoken out to them. Same reason why on mobile, inline-form labels are marked as sr-only to give clues.

A quick Google didn't turn up a definite answer but take a look at Wikipedia http://en.wikipedia.org/wiki/Access_key's quote on accesskey attribute:

In a web browser, an access key or accesskey allows a computer user immediately to jump to a specific part of a web page via the keyboard.

So we're still adhering to that, after all functionality still works and the page continues:

...survey to see if implementing accesskeys caused issues for users of adaptive technology, especially screen reading technology used by blind and low vision users.

Leading me to believe the use of the sr-only class is proper.

I'd be more than happy to change it, reflecting better standards but until then I'm going to stick to the Twitter Bootstrap Accessibilityhttp://getbootstrap.com/getting-started/#accessibilitysection where they're using the same principal.

— Reply to this email directly or view it on GitHubhttps://github.com/jbokkers/SF-BOILERPLATED/issues/6#issuecomment-29054889 .

[sitefinitydcx]

Hi Eric,

I guess WCAG's the thing to read up on then :)

Regarding the intended use, if I look at the first WCAG 2.0 link you've provided they state the following at the top:

The intent of this Success Criterion is to allow people who navigate sequentially through content more direct access ... This is in contrast to a sighted user's ability to...

So we all seem to be on the same page regarding the 'intent' for screen-readers, yet leave out the people with limited motor-skills.

Have to say, I like the idea of show/hide when the link has focus yet I'm hesitating to put it in practice for two reasons:

• First because it affects the design of a page. Often when I browse to a page (say the w3.org links, a blog or news section) I use my mouse to scroll over the content and that would cause focus to never change - leaving the 'skip-navigation' always visible. Penalizing the majority for a small subset of users can't be the objective, but I'll think more about it.
• Secondly, (and this is sf-boilerplated/twbs specific) I've tried to create a starting point with this project that in no way influences, or forces design/interaction restrictions upon developers. I realize the .Master has <header>, <nav> and <footer> predefined and there's a separate 'script-placeholder' at the bottom but that's it. Regarding styles and interactions I've tried to keep out of the way.

---

Reading your outline comments, I realize there's room for improvement there on the .Master. With the current setup, due to the use of <nav> and <section> a nested outline gets created.

The <nav> in the .Master is essentially unnecessary because Bootstrap menu's are <nav> elements. The <section> element, although looking cool is simply useless and could potentially cause a wrong hierarchy.

Together with ensuring primary tab-focus I'll fix these issues on the next update and will add the proper ARIA attributes as well.

Jochem