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
Stephane Bouchard

Stephane Bouchard

Stephane Bouchard has not set their biography yet

In the previous post, “No Javascript – Part 2: Form submission and multiple submit buttons”, I discussed the issues with having multiple submit buttons on a form when Javascript is not used.  The post finished with the mention of one possible solution: the use of ASP.NET button controls.  I will look at this solution in this post.

An ASP.NET button control is typically defined as follows:

            <asp:Button id=”myButton” text=”Submit the form” runat=”server” />

The value of the attribute id is the button’s unique identifier, the value of text is the button’s label, and runat=”server” identifies this element as an server control.  Typically, for the button’s “Click” event you would define a handler function that would be called when the button is clicked, using the function’s name as the value of the button’s OnClick attribute:

            <asp:Button id=”myButton” text=”Submit the form” OnClick=”MyClickHandler” runat=”server” />

Hits: 30672
Rate this blog entry:

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=””>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=””>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,  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?

Hits: 77490
Rate this blog entry:

Many of you probably have an web application that works great and has done so for years. Well, that is, it works as long as the browser used to access the application has JavaScript enabled. Otherwise, it does not work at all, or at best, only some of its functionality works.  Your clients are now telling you that the content of their web site has to conform to certain accessibility standards, and unless your web application can conform to these same standards, they will no longer be able to use your application. You then learn that one of the rules of these standards is that your application must work without JavaScript.

Many web applications out there depend on JavaScript. Without JavaScript enabled in the browser, they either don’t work at all or have significantly reduced functionality. For example, if you try to use Facebook with JavaScript disabled you’ll find that you can’t do much. You’ll be able to see your news feed, but it won’t be updated automatically; for that you’ll have to manually refresh your page. You won’t be able to update your status, and you won’t be able to like or comment on others’ posts. You won’t even be able to see most of your own profile page!

As organizations all over the world, especially federal government agencies, are trying to make information available to everyone, you are likely to run into issues with JavaScript. Some people with certain disabilities need to use assistive technology to access the Internet and interact with the content of web pages. For some of these people, JavaScript, or actually the way it is used in web applications, prevents them from accessing information and interacting with the content of web pages using the tools that are available to them. In order to reach these people, a lot of organizations and government agencies require that all pages and applications on their web site follow certain accessibility standards, which usually have some kind of restriction on the use of JavaScript. In some cases, these standards are part of the law.

If your clients are part of the United States government, any application on any government web site has to follow the rules outlined in section 508 of the U.S. Rehabilitation Act. At the time of this writing, this standard does not require that a web application function without JavaScript, but it does impose some rules on how JavaScript can be used. Most organizations and governments around the world tend to have their own standards regarding accessibility, but for the vast majority, these standards encompass another standard called the Web Content Accessibility Guidelines (WCAG). These guidelines were developed by the World Wide Web (W3C)'s Web Accessibility Initiative (WAI). Version 1.0 of this standard became a W3C recommendation in 1999. In 2008, version 2.0 became the new recommendation. The first version was very clear on the use of JavaScript. Checkpoint 6.3 of WCAG 1.0 states, “Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.” Therefore, any application that wants to conform to this standard has to work with JavaScript disabled. Although there are ways to work around this by providing “alternative accessible pages”, most people want the actual functionality and not an alternative page. The standard doesn’t say that you can’t use JavaScript, but your application must work without JavaScript. If you use JavaScript, there are certain rules to follow.

WCAG 2.0, however, is not as clear as WCAG 1.0 on the use of JavaScript. It doesn't mention scripting directly. Instead, it refers to “accessibility supported technology” as being allowed, but it's not clear what technology is considered accessibility supported. It is possible to use JavaScript in an accessible way, but does this mean it's considered accessibility supported?  The WCAG 2.0 standard does not make any claims about any technology - it's left up to us to decide. In my experience, organizations following WCAG 2.0 want an application that works without JavaScript, providing full functionality. You can add JavaScript, used in an accessible way of course, but only to enhance the application and not to provide extra functionality.

Hits: 20309
Rate this blog entry: