I am trying to create a site with high rankings in accessibility and one of the things i have come across is. My live search (that makes a ajax request and shows suggestions from what you type in the search bar on "keyup").
The list of suggestions i full of links that will take you to the page you are looking for meaning there is no submit page containing your results you just click the links therefore a submit button would be in my opinion redundant and useless.
My question therefore: Is it possible to make a form ex a live search without a submit button without the site being ranked lower than if it had a search button?
Is it possible to make a form ex a live search without a submit button without the site being ranked lower than if it had a search button?
You have to read WCAG Success Criterion 3.2.2 On Input
The first technique proposed is G80: Providing a submit button to initiate a change of context
But there's another technique which would not require a submit button:
G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
TLDR: yes, but.
Its usually considered good practice to have a 'fallback' scenario. Say, for instance, the user is not using JS (god forbid) or if the user is using a screen reader of some sort - the search box should direct the user to a new page with listed results.
A helpful guide to building accessible sites can be found at (https://www.w3.org)[https://www.w3.org/TR/WCAG20-TECHS/]
Related
We have a website product that allows users to search rental inventory, view results and then click through to a details page.
On the results page, we also allow users the option to refine their search via bedrooms, bathrooms, price, etc. When the form changes, we do not reload the page, we use Ajax to run a new search query and load the new results into the container.
For example, when the user first did a search, they got back 100 properties. Then they refine their search for 3 bed, 5 bathrooms, view = oceanfront and they get back 10 properties. Once the user finds a property they like, they typically click through to the details page. But, let's say they change their mind and click the browser 'back button'.
When that happens, all of our search params that were loaded via Ajax are now gone and our property count is back to 100 instead of 10.
So what I have realized is any data loaded via Ajax is not being cached in the browser so the original search is loaded not the refined search.
After doing some research, I think using history.pushState() and history.popstate() might be the solution but I'm having trouble wrapping my head around how to implement it for our problem.
Is there a better solution? If not, will history.pushState() work?
I'm in the process of upgrading a couple of sites to Universal Analytics and need some help setting up goals for conversion tracking...
I am now using auto event tracking (click listener) to see where users are clicking on the sites' forms, but I'm not sure how I can create goals for form submissions as the URL does not change. (Previously I was sending virtual pageviews when the submit button was clicked, but I don't think it's possible to do this in Universal Analytics?)
I know by using the click listener I can still see how many times the submit button of the form is clicked, but I need to set this up as a goal so I can monitor the cost per conversion of my AdWords campaigns.
Any help appreciated!
loop, if you are using GTM, you can simply use Form Submit Listener:
This listener then could fire an event tracking, which will serve as the condition for any conversion goals you might need. Just keep in mind when setting the conditions for goals, ALL of the Event-related dimensions (category, action, label) need to match, even though you can use only one (for example category = form submitted) as well.
ASP.NET MVC noob here
I was writing a quiz application where a user can select her preferences (e.g. difficulty, number of question etc.), and once she hit a submit button - she got a new page with questions.
The preferences are represented as a "Preferences" object, and the questions are IEnumerable of Question.
This all worked well.
Now I decide both parts should be in the same page - and I don't know how to accomplish that:
Should I have a new model class that is a composition of these two parts?
And also - How will I make the "questions" part appear only after the user completed filling up her preferences and clicked a button?
Should I use AJAX?
I also read a little about partial views and RenderSection.. But I really couldn't understand which approach is the most appropriate for my scenario.
So how should I draw two parts of a page, where the second is only displayed after the first is submitted?
Thanks.
How familiar are you with AJAX? If I had to guess I would think a good way to do what you want to do is to have an AJAX call which is linked to an action when the user submits their preferences. The action can then return a partial view which you can have appear on the page without a reload via AJAX.
I have a request concerning Drupal 6.x
I'd like to have this behaviour:
imagine to have 2 columns, on the left a list of nodes (only titles for example) and on the right a view showing just one of the contents on the left.
My idea would be to achieve this with an AJAX-fashion: clicking a link in the list on the left updates the view on the right with the actual node.
Which is the best way to handle this?
My idea is to use Panels, make 2 column panel with 2 views, one (left) filtered on content type, with no arguments, and one on the right which takes in as an argument the node id to be displayed.
But how to link the 2 views with AJAX?
(or, better, how to update the view on the right with an AJAX call?)
is this possible?
Any help or idea is really welcome
Thanks!
Cheers
Mauro
You also can do a quick hack, which is quite flexible, because it allows you to change your views without changing code.
I have had a similar task recently and for your task I would do the following:
for your right column, create a exposed filter (node id) and hide whole exposed filter form using CSS.
using jQuery, attach a click behavior to titles on your left column.
the click behavior takes the node id, finds the attached exposed filter at the right column, enters the node id into the input field and executes form's .submit().
the .submit() triggers the build-into-views well debugged ajax request which refreshes your right column.
this is certainly possible, and not very difficult to do.
Your task can be divided into two main parts:
Providing a 'callback' URL in the Backend that takes a node id (nid) and returns the markup to display the node in the right panel in a format that can be processed by javascript. This will be done in PHP within a normal Drupal module. The main point is not to return a full Drupal page as usual, but only the markup for the node.
Create logic for the Frontend that, when triggered by clicking a link in the left panel, retrieves the new node markup via the URL callback above and replaces the content of the right panel with it. This needs to be done in javascript, using the Drupal javascript API with jQuery.
You can find an introduction and example for AJAX in Drupal here. (This does almost exactly what you want to do, only with images)
You should also look at this more general entry point for JavaScript in Drupal.
I am familiar with several approaches to making the back button work in AJAX applications in various situations, but I have not found a solution that will work gracefully in my specific scenario.
The pages I am working with are the search interface for a site. You enter terms in a normal search box, click "go and wind up at a search results page. On the search results page there are a ton of UI controls for filtering/sorting the search results to find what you are looking for. Some of the operations triggered by these controls may take a (relatively) long time to complete (e.g. several seconds).
This latency is fine in case where the user is initially filtering/sorting their results... there's a nice AJAX spinner and so on... however when the user clicks on a search result and then clicks on the BACK button, I would like the page to instantly be restored to the state it was in when they clicked through.
I can restore the states using IFRAMEs/fragment identifiers as a dictionary of page history, but what ends up happening is that when the user first hits the back button the initial page is loaded, then it (re) makes the AJAX query to get the page state back, which triggers the AJAX spinner and another wait of possible several seconds.
Is there any approach that does not require this kind of two-stage load of the page when the user returns to the page via the BACK button?
Edited to add: I am partial to jquery but I'd be happy with solutions that depend on other libraries/toolkits or that are standalone/raw javascript.
Edited to add: I should've added that I'm trying to avoid cookies/sessions because this prevents people having multiple brower windows/tabs open and manipulating different sets of search results at the same time.
Edit: Matt, can you elaborate on your proposed solution (triggering a page change event via fragment identifer)? I see how this would help with BACK button clicks across the same page but not coming BACK to the search results page after clicking on a specific result.
Just use a cookie.
Have you investigated the YUI Browser History Manager?
Try to use localStorage object. Here is crossbrower libs jStorage and WEBSHIMS json-storage
Would it help to trigger a page change event using the "Add some info to the # at the end of the URL approach".
That way, clicking the back button shouldn't actually change the page, and you should be able to restore state without the first page load.
Use something persistent that is tied to the user's profile.
Cookies and sessions are good ideas, but you can also keep those stuff in the database. That gives you an added advantage of being able to save the user's filtering preferences accross different browsing session.(if, for exampple, he was looking for something in the office and then decided to continue searching when he is back at home).
It all depends on the complexity of the filters and weather or not it is something you think that the user will want to use accross diffrent browsing sessions..
Edited to add: I should've added that
I'm trying to avoid cookies/sessions
because this prevents people having
multiple brower windows/tabs open and
manipulating different sets of search
results at the same time.
You can create a random token and assign it to the fragment identifier.
on first page load create a token if no fragment identifier is set
before navigating out, store all the temporary ajax data in a cookie with that token as index.
when hitting back, if you have a fragment identifier set, load the data from the corresponding token in the cookie.
you can even add a "time" field to expire tokens, etc...
sample cookie (JSON):
{"ajaxcache":[{"token":<token>,"time":<time>,"data":<data>}, ... ]}