I am doing a lot of work with accessibility and WCAG at the moment but one thing I am trying to get to work well for all users and especially those using keyboard navigation, is a skip to content link.
This sounds simple to do, throw a link to an anchor in the top of the page and people can 'click' it to skip navigation or other largely unimportant content.
The issue is, though, when you 'click' an anchor link using your keyboard and then hit the 'tab' key again, you get taken to the element directly after the 'skip to content' link and not the next element in the main content area. Ie, the anchor you linked to has not received focus.
It seems that this is a common problem, because I am yet to find a site with a 'skip to content' link that has this working correctly. Even the Vision Australia site has this problem.
I was hoping that somebody knew of a technique/hack/library to make this work as it should.
EDIT: I can confirm that this issue occurs in Chrome and Safari, but not Firefox on my mac.
Most browsers scroll down visually to the target of the same-page link, but don't actually place keyboard focus on that link. You can use JavaScript (or JQuery, as in the example below) to give focus to the target:
$("a[href^='#']").not("a[href]='#'").click(function() {
$("#"+$(this).attr("href").slice(1)+"").focus();
});
However, there's a bug in WebKit that prevents even this solution from working in WebKit browsers such as Chrome and Safari. I wrote a blog post on this about a year ago, and several others have built on it:
Terrill Thompson blog post
More from Damon Muma
A JavaScript-only solution by Zegnat
WebKit Bug Report
Chromium Bub Report
You may place an another element just above the content you want to receive the next focus. Then skip to that element and hide that from view using diff ways like, font-size 0 or a p tag with no content etc.
<div class="skip-nav-container">
<a class="skip-to-main-content" href="#mainContent">Skip to main content</a>
</div>
<nav>
<!--skip this content-->
</nav>
<div class="skip-nav-target">
<p class="skip-nav-target-content" id="mainContent"></p>
</div>
<main>
<!--next element in the main content area-->
<!--main content-->
</main>
Related
I have anchor links in the menu that go to an anchor on the page, however in Firefox the anchor seems to go above the actual anchor - however in Chrome, it takes you exactly to where the anchor is - from a little testing i've done, it seems that the issue is related to the padding.
You can see the issue here; www.anjoykitchen.co.uk/
Click on Menu & Takeaway or About in the menu and it will (in Firefox) take you to the anchor with a gap at the top; yet on Chrome it takes you to the exact place you'd expect it to.
You have the same ID that your linking to on two different elements:
<section id="menu" class="menu-container">
<header class="menu-title">
<h2 id="menu">Anjoy Kitchen Menu and Takeaway</h2>
ID's should be unique on a page, only appearing on one element in the DOM.
I am trying to create a menu using HTML5 ( type toolbar ). It turns out that no browser currently supports the toolbar type. (Thanks Zach for pointing me at this) What would be the best implementation that works for Chrome and Firefox ?
Currently, I am thinking about continuing using the menu element as per HTML5 spec and using CSS to style it as needed and JS to add behaviour.
The following mailing list posting explains the current intent for menus of type toolbar:
Toolbars are nothing more than a with the element name .
There's no magic at all, no special content model, it's all CSS for
styling, you use regular form controls to fill the toolbar.
from http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0264.html
Hence, I am daring to say, that I can use menu for all browsers, even if a browser does not explicitly support the HTML5 semantic of the menu element, because it will still display it as a block since the user agents, I have checked ( i.e. firefox,chrome,safari,ie) , style menu with display:block.
If you're open to using a bit of jquery, and if i understand your question, then a simple
<div data-role="footer">
<div data-role="navbar">
<ul>
<li>Summary</li>
<li>Favs</li>
<li>Setup</li>
</ul>
</div><!-- /navbar -->
</div><!-- /footer -->
would do the trick.
read more about navbar widgets here: http://demos.jquerymobile.com/1.4.1/navbar/
I would take a look at the bootstrap menu, it works (IMO) much like a toolbar, and it's got a wide support on a lot of browsers.
It's also got glyphicons so you can give your buttons icons beside the labels easily
I have markup like this on somepage.html:
<div class='someclass' id='hashtag1'>
<h1>somecontent</h1>
</div>
<div class='someclass' id='hashtag2'>
<h1>somecontent</h1>
</div>
<div class='someclass' id='hashtag3'>
<h1>somecontent</h1>
</div>
And links like this on another page (let's call it someotherpage.html):
<a href='somepage.html#hashtag1'>first content div</a>
<a href='somepage.html#hashtag2'>second content div</a>
<a href='somepage.html#hashtag3'>third content div</a>
However when I click on one of these links I don't see the expected behaviour - the page loads as normal but the scrollTop of the window doesn't match these divs. I've tried changing the IDs as they had hyphens in the to start with, this didn't make any difference - I've also tried changing what element the ID is on, i.e changed the <h1> to have the ID, then changed the <h1> to an anchor, but no luck.
When I'm already on the page, if I edit the hasthag and hit enter, it works as expected - changing the scrolltop of the window to the element with the ID of the hashtag without refreshing the page - but it doesn't work on the first hit.
Am I missing something obvious here?
EDIT:
Using FF 9.0.1 on Mac OSX
Turned JS off using web developer toolbar
changing or removing CSS doesn't seem to make any difference
UPDATE:
This works fine if I enable javascript - which is exactly when it doesn't need to work.
I have this as a catch for users with no javascript / disabled js. WTF, firefox?
Given your specific example, it seems to me that the scrollTop only changes when the page is already long enough to require scrolling.
When all the content is in view, the scrollTop position remains at the top of the document however when the page requires some scrolling, the scrollTop scrolls as far as the document can already scroll.
If scrolling to the required ID does not exceed the total possible scroll position, then the element in question will apear at the top of the page, otherwise the document will only scroll to it's maximum (based on its content).
Hashtags don't work with ids. You have to put a tags like this: <a name="foo"></a>. Then you can link to them using go to foo. Same goes for linking between multiple pages.
My company is starting to move toward adding the iPad as a browser i have to test my work on. This got me thinking...
Since touch-based clients don't have a :hover state are pure CSS dropdowns going to go away?
Then i thought even if you add some javascript to make the menus popup on click... What happens when the menu item (that expands to another menu) is also a link. How do you tell the difference between a click to see the menu or a click to go to that link?
What's going to happen with dropdown menus when touch based clients become more ubiquitous? Are there any workarounds out there yet?
Pure CSS dropdowns are possible on touch devices thanks to the :target pseudo-class. Basically, the pseudo-class is active for objects that have an id matching the current URL fragment. This means that the URI fragment can be used to store and share state with CSS. For example, let's say we're on http://example.com/, which has the following HTML and CSS:
<style>
#menu {
display: none;
}
#menu:target {
display: block;
}
</style>
Show the Menu!
<div id="menu"> ... </div>
The menu is hidden by default. Clicking or tapping the link will change the URL fragment to "menu" (full URI: http://example.com/#menu). Because now there is an element with an id equal to the URI fragment ("menu"), the :target pseudo-class applies, and the display property is changed.
Further reading:
Usage and Example at Mozilla Developers Network
Implementation of a touch-friendly pure CSS dropdown
This is kind of a design issue forced by a technical issue. I'd probably redesign/reorganize my content into one of three ways:
1- Click-activated mega-menus (example). The downfall here is that you might have real estate issues.
2- Top-Level Category links that lead to Navigation Pages. The downfall here is that it requires an extra page load to get to the content.
3- Make each Menu Item consist of two buttons, one to navigate to the page (the text) and one to expand the child menu (an arrow.) You'd still need, though, to provide the child navigation, if present, on the page the user goes to when they click a menu item.
my nav bar has this functionality (collins.class401.com/nav) for the crap you need
its a modified version of TJK_DropDownMenu http://www.tjkdesign.com/articles/keyboard_friendly_dropdown_menu/default.asp
their version (and mine) uses visibility for :hover
their version also only supports having <a>'s as menu items, while mine also supports <span>s (though using spans breaks their keyboard navigation) if you want something like a form, or a button in your menu, like i have
their version usually works for :hover on ipod touch, as long as you click in the 'white space'
my version is much more friendly to touch devices, and has the clickable arrows to toggle the display using prototype.js,
or, if they can't hover, and javascript is off, setting a php session and reloading the page, then inserting a style to the style tag at the end of the page which will overwrite the visibility and display according to whether the clicked to show or hide
Does anyone know how to fix (or what causes) the page up/down bug in FF when contentEditable is present on a div?
See an example
Navigate to contentEditable article with FireFox (3 or 3.5) and use the Page Up/down arrows on your keyboard. You should be unable to scroll to the bottom of the page, and it should appear to flicker and jump back up.
I think it's a bug of Firefox which even exists in the newest version, 3.6.8.
For the sample page there are 2 ways to make the page up/down buttons work:
Change all the three DOM node's contenteditable="true" to false.
Find the id="main-content" node, and delete the style float: left;.
Seems the problem for Firefox is contenteditable="true" conflict with the style float:left;.
The only way i can see is to use an iframe... like TinyMCE and CKEditor WYSIWYG editors, they both use iframes. However content loaded in an iframe does not posses the styling rules of its parent. Therefor has to be adapted ... the reason to herald the contentEditable div in the first place.
Since no one answered i'm going to sulk and play with matches