[ic] Removing javascript from standard catalog checkout

[Mike Heins]

Quoting Angus Rogerson (arogerso at uwaterloo.ca):
> 
> Hello,
> 
> We are required to provide a non-javascript version of our website in order to provide access to people who use screen readers and other non-traditional browsers. Our catalog is based on the 'standard' store. Some research on the mail list only turns up variations on the solution of "tell the user to turn on javascript". This is an accessibility requirement so that is not really an option for us.
> 
> I think that the javascript code could probably be replaced using the 'mv_click' feature. However, in some cases javascript is used to change the form action and form profile when particular buttons are pressed. Although these changes could be made in the mv_click, the click is not processed until after the check_order is run for mv_form_profile.
> 
> So, for example, in the checkout process, we can have a mv_form_profile to validate the inputs on the shipping address. However, for the back key the mv_form_profile is turned off allowing 
> the user to hit back without having to get a valid shipping address entered.
> 		<input type=hidden name=mv_form_profile  value="Check_shipping">		<input type=button onClick="
> 					this.form.mv_form_profile.value='';
> 					this.form.country_reset.value='1';
> 					this.form.mv_action.value='back';
> 					this.form.mv_nextpage.value='ord/country';
> 					this.form.submit();
> 				"
> 				value="<-- Back" class=button3>
> If this were replaced with an mv_click
>                 [button
>                     text="<-- Back"
>                     class="back_button"
>                     ]
>                     mv_form_profile=''
>                     mv_action=back
>                     mv_nextpage=ord/basket
>                 [/button]
> 
> which produces
> 	<input class="back_button" type="submit" name="mv_click" value="<-- Back">
> then by the time dispatch() gets to turning off the mv_form_profile in the mv_click, the mv_form_profile has already been run.

Can't you detect which browsers have this need? If they do have
the need, remove the mv_form_profile yourself and just do the
checks via mv_click. You could also change the logic:

[if scratch accessible_browser]
	<input type=hidden name=mv_click value="Check_or_not">
	<input type=submit name=where value="<-- Back">
	<input type=submit name=where value="Next -->">
	[set Check_or_not]
	    [if cgi where =~ /Next/]
		address1=required
		city=required
		&success=ord/finalize
		&fail=ord/shipping
		&fatal=yes
		email=email
	    [else]
		&success=ord/basket
		&fail=ord/basket
		&setcheck=nothing nomatter
	    [/else]
	    [/if]
	[/set]
[else]
	(normal stuff)
[/else]
[/if]

> 
> I am considering changing Vend::Dispatch::dispatch() to add an mv_form_profile_after which checks form inputs, but does it after mv_click has had an opportunity to change some of them
> 
> >         if($CGI::values{mv_form_profile}) {
> >                 my ($status) = check_order(
> >                                                         $CGI::values{mv_form_profile},
> >                                                         \%CGI::values,
> >                                                         $CGI::values{mv_individual_profile},
> >                                                         );
> >                 return 1 if defined $status and ! $status;
> >         }
> > 
> >     my $orig_todo = $CGI::values{mv_todo};
> > 
> >         do_click();
> > 
> >     my $todo = $CGI::values{mv_todo};
> > 
> > +        if($CGI::values{mv_form_profile_after}) {
> > +               my ($status) = check_order(
> > +                                                       $CGI::values{mv_form_profile_after},
> > +                                                       \%CGI::values,
> > +                                                      $CGI::values{mv_individual_profile_after},
> > +                                                       );
> > +              return 1 if defined $status and ! $status;
> > +     }
> 
> Does anyone have any alternatives for providing a non-javascript option? Any comments on this proposal, in particular unexpected side-effects to watch out for?
> 
> Thanks
> 
> Angus
> 
> 
> ---
> Angus Rogerson, BMath, BScN, RN
> 
> Duct Tape Programmer
> University of Waterloo | Retail Services | Information Systems
> 
> Visit Us Online & Right On Campus www.retailservices.uwaterloo.ca
> 
> 
> 
> 
> 

> _______________________________________________
> interchange-users mailing list
> interchange-users at icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users


-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.765.253.4194  <mike at perusion.com>

There's nothing sweeter than life nor more precious than time.
-- Barney