When we are using keyboard only and tab through the website, the first anchor link for "Skip to a content" is shown to skip the navigation and focus to the main content which makes the web page accessible. It is easy to add such a feature on multi-page website where there is full page reload and the focus for the page resets. I am looking similar behavior on the React. How can we implement such behavior on a Single page application built on React?
I disagree with Graham that you shouldn't need a skip to content link. In a SPA, when the user navigates to a new "page," the focus remains on the link that was pressed. Every time your user wants to navigate, they're going to have to go through the remaining nav menu to get at the content.
You could either move focus to the beginning of the document so they hit your 'skip to content' link each time (has its merits because it's most like multi-page apps which they're likely to be familiar with) or move it to the content body itself and save them a click (seems more streamlined to me, but might be unfamiliar to your users).
componentDidMount() {
setTimeout(() => document.getElementById('your-element-of-choice').focus(), 0)
}
I'm leaning toward the latter, but this will work either way you decide to implement it. Don't forget to set the tab index on the element you want to focus on to -1 as well.
You shouldn't need a skip to content link on a SPA other than the one you already have (for first time load for return visitors).
Skip to content is for when you click a link to a new page, it helps avoid having to listen to the menu every time you navigate.
With a SPA that isn't an issue as everything is done via AJAX, when I click a link a region on the page will get updated with new content.
All you need to do is move focus to the region that is being updated from the menu item.
Certain screen readers will need explicit ARIA Live Regions in order to register the new content so make sure you test it with a screen reader.
Where you will run into accessibility problems pretty fast in SPAs are when you start thinking about delays.
What happens if I click that link and the page takes 3 seconds to load?
What happens if the page doesn't load at all?
Those are your bigger challenges with a SPA.
Related
I think this question was asked in a similar form before but I didn't get a clear understanding how to implement it properly.
I have a site, which has different pages on their own urls, like '/contact', '/about', '/products'.
What's the technique to put a top bar on the top like this one http://nanobar.jacoborus.codes/?
Here is what I need:
User clicks a link on the page.
JavaScript handles the click, shows the progress bar, starts growing it then passes the event to browser.
Browser starts loading the page. At this moment, page clears and becomes white and blank.
As the progress bar was in some position that is not zero, say, 63%, and now there is no information on the new page about where it was.
So, I can technically run some function on every page, like showGrowingProgressBar(value), but since I don't know where it left, I cannot put it in the same progress state as where it left.
How do I make it look natural, like the user didn't leave the page, but more like an SPA experience?
I guess you want to build an one page web application where things load in the same page without refreshing.
You can use AJAX to do this. you can populate a particular div with the new html without refreshing.
It can be handled more easily using Angular JS. You can define routes for every page and can also have templates for different page, and can load that template when user clicks on the link. It will just replace the container div with new html codes and you can also handle the urls easily.
Turbolinks seems to be what you are looking for. It dynamically loads your pages and shows a loading indicator.
Turbolinks makes navigating your web application faster. Get the performance benefits of a single-page application without the added complexity of a client-side JavaScript framework. Use HTML to render your views on the server side and link to pages as usual. When you follow a link, Turbolinks automatically fetches the page, swaps in its , and merges its , all without incurring the cost of a full page load.
Your approach is:
User clicks a link on the page.
JavaScript handles the click, shows the progress bar, starts growing it then passes the event to browser.
Browser starts loading the page. At this moment, page clears and becomes white and blank.
As the progress bar was in some position that is not zero, say, 63%, and now there is no information on the new page about where it was
Your approach should be:
User clicks a link on the page.
JavaScript handles the click, browser starts loading the page. At this moment, page clears and becomes white and blank.
New page shows the progress bar, starts growing it then passes the event to browser. The growth can be picturized by the no. of API call completed divided by total no. of api calls, required for that page.
We have designed the application with tabbed pages layout.
Tabbed Page Style
the tabs are page and are created on click of menu, these are and added in parent container as child DOM element,it is a new form which has input elements,we could have many tabbed pages at a time. my application is in Spring MVC ,PostgresSQL ,Jquery.
What happens when refreshed, lost all the added dynamic new tabs (tabs are pages and we lost the current state).
I could share the reference code if required.
Please suggest how could I manage the state of application.
Window reload/refresh is a pure browser event that ends the execution of the page, you can't really have script continuity after it.
One option is to attach an alert to window.onbeforeunload informing the user that the content will be lost if they reload - this will work with closing the window and refreshing it.
If, however, you need to be able to reload (eg, to load fresh data in the tabs) while preserving tabs, you can use window.onbeforeunload to prompt the user whether they want to save the data/layout before closing, and if so, execute an AJAX call to the server, where you save the tabs (associating it with the session). This would mean that on loading the page you need to first check if there is tab data associated with the session, and load from there.
Other option - and this would be my preference - is to use window.localStorage to save the data on user's disk, and on page load check if there is data in localStorage. It has pretty wide browser support at this point, and there are good libraries that make using it a breeze. I have used store.js and can vouch for its ease and reliability.
I have a page where navigation is handled by hiding and showing preloaded divs when users click on links. But, the users think they've actually changed pages, so they click on their browser's "back" button trying to go back to the div that was previously hidden. But of course, they go back to the page from which they came.
What's the best way to handle this? 90% of the traffic is from a login page. Should I just sandwich a redirect page in between the two? How is this done? Can I just change the browser's back button behavior?
If you are already using jQuery, why not simply add a history manager like jq-bbq or the hashchange or history manager? (Or, if you want to really go all out, switch to a MVC JavaScript framework like Sammy.) That way, the back button will work as the user expects, rather than hacking around their expectations by blocking the back button or throwing in redirects. (Unless you have a good reason to, of course :-) )
If you use a browser history plugin like the jQuery UI one you end up changing the history so that the back button doesn't actually unload the page.
http://yoursite.com
-> User clicks something
-> new address bar reads http://yoursite.com/#/something
because of the hash mark when user goes back it goes back to http://yoursite.com which should inturn fire your show previous div function
read more about the available history manager plugins available for jQuery. There are quite a few. Most if not all provide available callback functions that you can specify.
On change of the state of your page, write a unique set of parameters to the hash of your URL. You can change this via JS without causing the page to reload.
Set a timer on the page that checks the current location hash repeatedly, and if it changes (i.e. the user presses the Back button) then update the state of your page to match the URL.
I have this scheme working to great effect in a local application.
The jQuery Address library is another great alternative.
http://www.asual.com/jquery/address/
You can set the URL for different application states, and get the URL 'parameters' when the page reloads.
Two ideas:
1) onbeforeunload. Ask the user if they want to really go back.
2) Sandwidch a redirect page. Login -> redirect -> your page. A single back click would take the user to your redirect page.
The second is kind of a pain in the neck for people who know what they're doing though. I think the Back button (and all standard navigational elements) should be messed with as little as possible.
I would go with onbeforeunload:
function sure()
{
event.returnValue = "sure?";
}
...
<BODY onbeforeunload="sure()">
I'm creating a infinitely scrolled page that recursively loads and append the next page's content into the current page. I think the browsing experience can be great and immersive but the current method is not without usability drawbacks.
Incomplete progressive enhancement. It is always good to support the back button and provide deep linking when using Ajax. The current implementations of infinite scroll does not support this. There is no way a state can be bookmarked.
Some ideas on improving the UX of infinite scroll. Need opinion.
Change the URL hash with each load, e.g. /!#/2 -> /!#/3
Clicking the back button should scroll the page upwards. Clicking forward button should scroll it down.
Accessing a deep link should behave like it was before Ajax. Going to and also starting at page 3 should show only page 3 content and not page 2 and 1, since the user is not asking for them.
There should still be a way for him go to page 2 and 1, like if it was regular pagination. Since page 3 is loaded with scrollTop at 0, the scroll up event is not useful. For this we might still need a clickable link.
We need to check if the requested page number is greater than the current because we should not loaded page 2's content at the end of page 3.
What do you guys think?
Interesting question. I would suggest changing the URL hash in the form of #!/from/123/to/456, and increase the to ids as page loads.
Whether you are using hash or History API rewrite to modify URL, in UX sense, URL always represent the location of current content. For example, user will expect a bookmark, hitting reload, or copying the URL to other computer and click Go, will return the same page.
The only way for your infinite scrolling page to complete the logic of URL is the URL hash I suggested above. Otherwise just leave it; Twitter doesn't update URL hash on their home page.
I am trying a new functionality for my web site. I want to do simple navigation by hiding/showing <div> elements.
For example, when a user clicks a "details" button on some product, I want to hide the main <div> and show the <div> containing the details for the product.
The problem is that to go back to the previous "page", I have to undo all the display/visibility style changes, which is ok if the user clicks the "close" button in the newly opened <div>. But most users will hit the BACK button.
Is there a way to make the BACK button go back to the previous "state" of the page i.e., undo the visibility/display changes?
Thanks.
Yes. What you're looking for is called AJAX browser history.
There are a few open implementations out there, like RSH as well as plugins/modules for frameworks like jQuery and YUI.
to answer the question of your title (that's what I was looking for)
Using the BACK button to revert to the previous state of the page
and from the link from #reach4thelasers's answer, you have to set up a timer and check again and again the current anchor:
//On load page, init the timer which check if the there are anchor changes each 300 ms
$().ready(function(){
setInterval("checkAnchor()", 300);
});
because there's no Javascript callback triggered when the BACK button is pressed and only the anchor is changed ...
--
by the way, the pattern you're talking about is now known as Single Page Interface !
You need to add an anchor to the URL whenever a change is made
www.site.com/page.html#anchor1
This will allow the browser to maintain the pages in its history. I implemented it in my current site after following this tutorial, which works great and gives you a good understanding of what you need to do:
http://yensdesign.com/2008/11/creating-ajax-websites-based-on-anchor-navigation/
Your example in the comments won't work, because it works like this:
Page Loaded
Page Changed, Add Anchor to URL (back button takes you back to back to 1)
Page Changed, Anchor Changed (back button button takes you back to 2)
Page Changed, Anchor Changed (back button button takes you back to 3)
.... and so on and so on..
If there is, it sounds like a pretty evil thing to do from a UX perspective. Why don't you design a "back" button into your application, and use design to make it obvious to the user that they should use your application's back button instead of the browser.
By "use design," I mean make your application look like a self-sufficient user interface inside of the browser, so the user's eye stays within your page, and not up on the browser chrome, when they are looking for controls to interact with your app.
You can do this with anchors, which is how it's done in a lot of flash applications, or other apps that don't go from page to page. Facebook uses this technique pretty liberally. Each time the user clicks on a link that should go in their history, change the anchor on the page.
So say my home page link is:
http://www.mysite.com/#homepage
For the link that works your javascript magic, do this:
My Other Page
This will send the user to http://www.mysite.com/#otherpage where clicking the back button will go back to http://www.mysite.com/#homepage. Then you just have to read the anchors with
window.location.hash
to figure out which page you're supposed to be on.
Take a look to this tutorial based on ItsNat a Java web framework focused on Single Page Interface web sites