Beyond 2020 twitterBeyond 2020 BlogBeyond 2020 Linkedinbeyond 2020 youtube

Tap in to your data’s intelligence

Beyond 20/20 Blog

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that has been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Team Blogs
    Team Blogs Find your favorite team blogs here.
  • Login

Experiences in Web application accessibility - No Javascript - Part 2: Form submission and multiple submit buttons.

Posted by on in Blog
  • Font size: Larger Smaller
  • Hits: 77491
  • 0 Comments
  • Subscribe to this entry
  • Print

In this second part of the “No JavaScript” series of blog posts, I’ll discuss how to submit a form using multiple submit buttons, that is, buttons declared in HTML using  the <input type=”submit” /> element, and why you would want to do this.

In a typical web site, when you want to allow a user to go from one page to another you add a link to the page that references the other page.  This is usually done by adding an anchor tag and specifying the new page’s URL as the value of the tag’s href attribute, for example  <a href=”http://www.mysite.com/mypage.html”>Beyond 20/20></a>.  If you want to submit extra information to the referenced page, you pass it as a parameter on the URL. For example, the web page could accept information that allows it to be displayed in a printable mode, like <a href=”http://www.mysite.com/mypage.aspx?print=1”>Beyond 20/20></a>.  Note that in this case you can’t use a link to a “static” HTML document; you need to use a server-side language/framework such as PHP or ASP.NET in order to process the information passed on the URL.

In some cases however, it is not possible to pass all the information you need to pass in the URL.  The main reason for this is that there is a limit of approximately 2,000 characters allowed on the URL and this value is different for each browser type (see, for example, http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers).  If the information you need to submit to the server exceeds this limit, you can’t use this method.  This may seem like a sufficient limit, but in some cases it’s not.  One such case is when you are building a web application that needs to use client-side state management, which means that the web application has to maintain user choices for the duration of the user’s session without storing them on the server. In this case the state is typically stored in hidden form fields, that is, HTML elements declared as <input type=”hidden” name=”var_name” value=”var_value” /> in the <form> element.  The form and its hidden fields are submitted along with the request to the server and the hidden fields are returned in the HTML response.  No information about the user’s current session is stored server-side.  Take for example a web application that allows a user to select multiple items from a very large list, for example a list of tens of thousands.  The user selects some items and clicks a button that sends a request to the server.  The server then merges the user’s selections with previous selections and writes them to hidden form fields in the HTML it sends back to the browser.  The user can then select more items and we keep track of the selections in the same way.  This is pretty much how the view state works in ASP.NET web forms.  To submit the form, you simply need to add one of the following button elements to the form: <input type=”submit”>, <input type=”image”>, <button type=”submit”>.  Selecting one of these buttons will submit the form to the server.  The form will be submitted to the page specified in the value of the action attribute of the <form> element, e.g. <form method=”post” action=”mypage.aspx”> (or to the current page if action is not specified).

This seems simple enough when we have only one button to submit the form.  What if we have a menu with many menu items, each of which is supposed to take us to a different page, and we want to submit the form to any of these pages?  Typically, menu items are implemented as <a> tags, each with a different value for its href attribute.  However, since we want to submit the form, we have to use submit buttons instead of <a> tags.  The problem is that the value of the form’s action attribute is set to a specific URL, so clicking any of the submit buttons will send the request to that one page.   This would be simple to fix with JavaScript.  We would create a JavaScript function that would be the onclick event-handler for each submit button.  We could even do this with JavaScript and <a> tags.  This function would change the form’s action attribute to be the URL of the appropriate page and then submit it.  Many JavaScript-dependent web applications use this method of submitting a form.  But what can we do without JavaScript?

If you were using HTML 5, you could use the new formaction attribute of submit buttons.  This attribute specifies where to send the form, overriding the URL specified in the form’s action attribute.  The issue is that this attribute is not supported on all versions of all browsers. For example, at the time of this writing it is not supported by Internet Explorer 9 and earlier versions, but only by the latest version, Internet Explorer 10.  Furthermore, some institutions will insist on XHTML 1.0 or 1.1 as the markup language to use, which do not have a formaction attribute.  Therefore, at this time this approach is not sufficient.  What else can we do?

One possible approach is to have one form for each button and have a copy of the hidden fields in each form.  This can work in cases where the amount of information stored in hidden fields is small or when the number of submit buttons is small.  However, when you have a menu with many entries, it is hard to make such a menu look good when each menu entry is on a separate form.  Even if this were possible it’s not a desirable approach, especially if there is a lot of information to store in each form

One of the answers to our problem is the use of ASP.NET button controls, which I’ll discuss in the next post.

Rate this blog entry:

Comments

  • No comments made yet. Be the first to submit a comment

Leave your comment

Guest Monday, 22 July 2019