I have been googling this for a while and can't find any solution... I am wondering if it is possible to keep a navigation menu in the browser cache eventhough there is an active element that changes from on page to the other (highlighted menu item when on it's page). I m pretty sure browser cache menus to avoid the user to always download the same menu but it doesn4t seem to work on the website I am working on : http://2degreesproject.com.au/Connection
Thanks for you help !
You could consider loading all your other content with ajax. That way you never have to reload the menu. Otherwise, you'll need to pass a bit of information from one page to the next using your server side language or an ajax post. You could always set a cookie and change the value of it on each page to keep track of what the last page was. That's probably the standard way of doing this. Look into how to set cookies, and how to change their values (usually you just unset and reset with a different value, I believe).
Related
I'm adding a blocking modal (ie one that covers the screen and prevents interaction while an API call is processing) to my company's design library.
As part of that, I modified our modal so that clicking on the grey backdrop will NOT hide the blocking modal, but I want to make sure that doesn't violate accessibility guidelines. I haven't been able to find anything online about this. Does anyone know if this this violates accessibility requirements?
Short Answer
The answer is 'it depends'. Basically if the modal is not dismissable in any way it becomes a 'keyboard trap' and so would violate WCAG.
However if you structure it correctly a modal that blocks the page while an API loads is perfectly valid (and can't be dismissed while the page is loading), but there are a few things you need to do to make sure this is accessible.
1. Make sure that when this modal loads, nothing else on the page is focusable.
The biggest issue I see on most modals is that they allow focus outside of them.
You can't just stop users using the tab key as that is not how most screen reader users navigate the page (they use shortcuts for headings (h1-h6), hyperlinks etc.).
For this reason make sure your modal sits outside of your <main> and the hide your <main> and other major landmarks that contain information with aria-hidden="true" and by adding tabindex="-1" to them so nothing is focusable.
Obviously this depends on your document structure so you would need to test it, but a properly structured HTML document will work with the above method.
2. Make sure that a screen reader user knows that the page is busy and something is loading.
There are a couple of ways to do this. The best is to use an aria-live region
Adding aria-live="polite" and aria-busy="true" to the section you are updating is one way (if you are updating one part of the page).
However in your circumstances I would make a section within the modal aria-live="assertive" and not use the aria-busy (as you will be hiding all the content in step 1 so aria-busy would not be applicable).
I would then update the message every second or two for long loads (i.e. 'loading', 'still loading', 'nearly loaded' etc. Or better yet a loading percentage if your script allows.)
Once the page content has loaded, you do not need to say 'loaded' instead make sure you have a heading for the section or page that has a tabindex="-1" added on it that accurately describes the content that has just been loaded in.
Once the load completes, programatically focus this heading and the user will know that the load is complete.
3. Make sure that if the API call fails you feed something meaningful back to screen readers
When your API call fails (notice I said when, not if!) make sure your JavaScript can handle this in a graceful way.
Provide a meaningful message within your modal aria-live region that explains the problem. Try to avoid stating error codes (or keep them short, nothing worse than hearing a 16 digit string on a screen reader for an error code), but instead keep it simple such as 'resource busy, try again later' or 'no data received, please try again' etc.
Within that region I would also add one or two buttons that allow to retry / go back / navigate to a new page depending on what is appropriate for your needs.
4. For long load times, let the user know what is happening.
I covered this in point 2 but just to emphasise it, make sure you feedback to users that things are still loading if there is a long load time by updating your aria-live region.
Nothing worse that wondering if the page has loaded and the developers forgot to tell you.
5. Give the option to cancel an API call so it doesn't become a keyboard trap.
Obviously the big problem with a whole page modal is it is a 'keyboard trap'.
To ensure this isn't an issue make sure you provide a cancel button.
Make sure it is clear that this will cancel the loading of the page, but don't rely on JavaScript alone.
Instead make this a <a> styled like a button that either points to the current page or the previous page (yet again depending on your needs) and add role="button".
Then intercept this click with JavaScript so that it can function like a button.
The reason for this is that when your JavaScript fails (yet again - when, not if) the user still has a way to get to a meaningful page, thus avoiding a keyboard trap.
This is one of the few times you should use an anchor as a button, as a fallback!
By doing this you ensure that the user always has a way to escape the modal.
You may also consider allowing a user to use the Esc key to close / cancel but that is yet again down to you and your circumstances.
im nearly ready to launch my website but i have a problem i cannot sort out.
ive built the whole website using wordpress and buddypress.
due to the picture in my header being very big and ending 450px down the page, you have to scroll down to access the buddypress menu in the relevant page (the one above the activity stream etc) which is exactly where i want it, removing my header is not an option, now the only problem i am having is that when i click the tabs in the buddypress menu say from activity stream to say my messages instead of the page laoding and taking me back to this section it takes me to the very top of my header so i have to re-scroll back down to the page i was after.
I need the page to stay at the same point after page reload so that the menus can be flicked through without having to scroll down to it again everytime a link is pressed. how do i achieve this? can you please help me sort this out….i have no problems adding or editing codes if i know what code needs changing and what to add to make it do this. thx
Im guessing that if you look in the url bar it is adding a # to the end of the url. You need to override the default click event on the a tag so that it doesnt jump you to the top. Im not sure how that will affect the stuff that is going on in the BuddyPress plugin.
I have an iframe that displays thumbnail images from Flickr in my web application. The problem, I see is when I reload the page, sometimes, I see the same set of images being appended to the earlier set of images. So I get two sets of every image and on a subsequent reload, I get 3 sets of images.
The images are part of a form. So I see multiple submit and cancel buttons as well. Any suggestions on what might be causing this and how I can avoid this from happening?
Pardon my ignorance. I was not resetting my server side variable after the fetch and hence I was seeing the above weirdness. Firebug helped me debug this.
Is there a way to make it so the page doesn't shoot to the top of the site when clicking different links in the navigation bar?
e. So say I'm browsing my site and I'm scrolled down a little bit. Then I click on a link that navigates to a different page on my site. It automatically scrolls to the top. Is there a way to make it not do that.
instead of simply linking to a page, you could link to an anchor on that page using
link text
if that anchor is placed properly on the target page, you will not experience the jump back to top every time you link to another page. hope this helps
If this is the problem I'm picturing:
Change your links to point to <a href="#"> or <href="javascript:void(0);">
If you're going to different pages, you can use a link like:
My Link
Down in the page:
<div id="Section5">
Stuff!
</div>
This is the way that the web works. But still you can do a few work a rounds but each one will take a little work.
First option:
When you click on any link on the page, get the margin of the link from the top, then add it as a parameter to this link, and only then do the navigation. (the format of the line will be like page.html#margin-from-top).
Then in the new loaded page, you can look for this value and do the scroll. (I prefer the scrolling with a little duration).
Second option:
Another idea is to stay always on the same page and only change the content of it. you can do that with a little effects too.
It seems, too, like you might want to use a mooTools ScrollTo affect or possibly even invoke an AJAX method like SWFAddress.
Depending on exactly what you're trying to do, you may be able to accomplish it without using any fancy javascript, but it will depend on the inclusion of labels/etc. on your target page (as has been mentioned before).
I've seen this weird behavior on several sites recently: I scroll down a page and follow a link to another page. When I click the Back button and return, I am left back at the top of the previous page, not at the link. This is very annoying if I'm clicking on links in a search results page or a list of "10 Best Foo Bars...".
See this page as an example. Strangely, the page works as expected in IE6 on WinXP, but not on FF2 on the same machine. On Mac OS X 10.4 it works in FF2, but not in FF3. I checked for any weird preference settings, but I can't find any that are different.
Any idea what is causing this?
Many sites have a text box (for searching the site, or something) that is set to automatically take focus when the page loads (using javascript or something). In many browsers, the page will jump to that text box when it gets focus.
It really is very annoying :(
Typically this behaviour is caused by the browser cache set by the site having a small or no time before expiry.
On many sites, when you hit "back" you get brought back to the link you hit, as your browser is pulling the page from your cache. If this cache has not been set, a new page request is made, and the browser treats it as fresh content.
On the page linked above, the "Expires" header seems to be set to less than a minute ahead of my local clock, which is causing my browser to get a fresh copy when I hit "back" after that expiry time.