disadvantages of using javascript to create form data

Question

On my current project the business owners are ramming AJAX, jQuery etc down my throat. There is a requirement for 4 seperate forms for different policy types.

They want the user to be able to switch between these without visible page refresh and also generate more form content when certain submit buttons are pressed e.g. when a parent adds a child to the form.

I have issues with this as i do not think it is accessible i.e. if the switching is done via AJAX without page refresh then how does a screen reader user know which tab/form they are on. Is there a way to make this accessible?

I also do not think it is secure as there will be database connectivity and therefore the user on the client side could alter the javascript and try to maliciously break the database/page.

I am trying to compile some reasons why it should not be done like this but was wondering if there was anything other than accessibility and security.

Also, as back up this will all be done on the server side anyway so i don;t really feel that javascript adds much here other than being quicker.

Answer 1

Accessibility - A lot of work has gone into this. One of the tools you may use is ARIA. For some basics, you can see this post on AJAX Accessibility. You may also want to look at Google's AXSJax project

Security - AJAX really has nothing to do with the security of your server. Either way, your server has to authenticate requests and make sure they can only access or modify what they're authorized to.

I find it odd that you say, "i don;t really feel that javascript adds much here other than being quicker." Speed is always an important goal - not the sole goal, but certainly an important one.

All in all, statements like "I am trying to compile some reasons why it should not be done" make it sound like you are looking for excuses rather than solutions.

Answer 2

While I applaud your upfront thinking about accessibility, the tone of your post seems like you have your back up about their requirements. I would advise not to get all holy about the "right way", and simply approach it from a business requirements perspective.

1. Does making the site accessible for screen readers give the business owners any advantages?
2. Does it increase development time?
3. Will your approach degrade the user experience that the site owners are looking for?
4. Is there a compromise approach that will preserve (at least most of) their requirements?

The great thing about jQuery is that you can make sites degrade easily for non-javascript users. You can create the site in a static way, and then use jQuery to change all your links to use fancy ajax functions instead of their defaults. Perhaps that would be a good compromise.

Answer 3

As to security, such a scheme is not necessarily a problem. Yes, the user can mess with the page, but as long as the server does not make assumptions about POSTs always being "right" then there's no problem. In a well-written site of that nature, the worst that an attacker should be able to do is screw up their own session somehow.

I think the accessibility question is a good one. Stackoverflow itself, for example, won't let somebody tabbing around get to the "add comment" facility, and I think that's unfortunate but I understand the challenges.