Using Two Submit Buttons For Accessibility
Getting back to the form I was talking about last week. Some of you may have been wondering why there are two type="submit" buttons on it. Then again, maybe you didn't. Karen visited here last night to see what I've been "going on about" and soon realised there was nothing of interest, declaring it all boring. She's probably got a point!
Anyway. I was using two submit buttons on the form to make it accessible, as per the client's request. If it's going to be accessible we can't use JavaScript and have to rely on the form to submit itself. The only way to do this is with a submit button.
If you have two buttons on a form - Back and Next - then you can give them both a name and have the clicked button's value sent to the server, where all actions are performed.
Here's the HTML for the buttons:
<input type="submit" name="Go" value="« Back" /> <input type="submit" name="Go" value="Next »" />
At the server, in the WQS event we code the following (don't forget we can use straight @Functions there):
@If( @Contains(Go; "Next":"Skip"); @SetField("CurrentStep"; CurrentStep+1); @Contains(Go; "Back"); @SetField("CurrentStep"; CurrentStep-1); @Contains(Go; "Submit"); @Command(ToolsRunMacro; "(Submit)"); "" )
So, if we're working through each step the WQS simply adds one to the numeric "CurrentStep" field, which is used in the Hide When formula of each section of the form. If the button pressed contains the word "submit" then the actual WQS agent runs and we're done.
Note that this actually creates a document right from step 1 of the form. The $$Return simply points to ?EditDocument of the document created. There's no longer the notion of a session with the server when not using __Click. This leads to dead documents! To get round this I've been having to have the final submit action mark the document as completed. There's a nightly agent that removes incomplete documents more than a day old.
There's no denying that designing for accessibility is a pain. Domino doesn't make it easy for us in the slightest. However, using some carefully crafted trickery and hackery it can be done.
Skip to the 
You can subscribe to an individual
Using the same document but stepping through it with multiple submits is exactly the process I use for United Publications. {Link}
It's only right at the end Confirm stage when the document is complete. In fact that final completion step actually changes the Form field from "TemporaryOrder" to "Order". I have a tendancy to process these steps with Agents as there is some pretty heavy stock control (not to mention credit card processing - Code 10 validation is a pain) going on behind the scenes.
Yes we do get Dead documents. I just checked because I've never bothered tidying them up. We have around 110 documents over the four years that the new site has been active. Not bad I suppose. Time to hit that delete key. One less agent for the server. (^_^)
Using the submit buttons in this fashion is something Struts would pretty much choke on. Chalk one up for Domino RAD.
p.s. IMO, it's not hacking if you are finding a creative way to get what you want out of the tools provided. Hacking is an outdated term that implies ill fitted switches and rough edges. Your implementation wouldn't appear to have any visible rough edges. If it's a hack, it's a righteous hack. :-)
Jake,
Don't you run into problems when you use fields that refresh automatically? Hence, if you had a DDL that would auto set five other computed fields on a form. Or would you in javascript run the submit and press the button, like say the "Skip" event. Or have I confused the issue?
I'd probably have problems if I used auto refresh and suchlike. I don't though. I avoid as many of the Lotus "make it easier for them" features as I can.
Thankfully, I've yet to work on a complicated form that auto-updates and required no JS accessibility.
I like the approach of doing more with the basic tools (submit buttons instead of javascript, say), and I absolutely support accessible web applications. But I'm stuck on why javascript can't be "accessible"?
It seems like javascript can make your site *more* accessible, and by restricting your site to no-javascript, you will end up with less of a site. Any words on how/why you choose to leave out the javascript?
Have you played at all with the mac's "Voiceover" screen reader? I've been meaning to, but haven't yet-- I'm looking forward to seeing how it handles different UI elements. Would make for some great articles!
Seth
Seth. Maybe my no-js-to-be-accessible thing is mis-guided. I'm not 100% sure, but I am sure I remember reading about it in more than one place. Basically, to be accessible, you need to a site to work in "browsers" such as text-only Lynx and screen-readers like JAWS. Lynx for one has no JS option.
Maybe I'm wrong?
re: accessibility - it's a matter of reach. Who will reach the application? What is the liklihood that you really need to support a Lynx user? If you don't know, the answer is usually do, for now anyway.
So far as I understand it, though, Lynx doesn't support CSS either - which makes your button reversal from yesterday confusing (invisible) to the Lynx user.
I'm also liking the use of more non JS methods to get what you want, but also feel you can make an interface "more" rather than "less" with the addition of JS, so long as there is a usable non-JS version of the same.
And I'll again make the same comment last time - the way you're doing it creates a dependency on the value of the buttons. If you change the content of the button then your code breaks. This is a Bad Thing.
The better way to do it is give your buttons two different names, only the one that was actually pressed will be submitted. Create two fields with the same name as the buttons and then you just check which of the fields contains a value (any value) to determine which was pressed.
Misguided, perhaps, Jake, but not entirely. WCAG and Section 508 require that the same functionality be accessible to users without JavaScript. It doesn't have to be identical (obviously, AJAX sans JS would be a bit of a bear to pull off), but it does have to offer the same basic functionality. And if you have to follow WCAG 1.0 for legal reasons, then JS can never be more than icing on the cake. Both WCAG 2.0 and Section 508 allow for "alternate functionality", meaning that a JS-driven page may be replaced with a more server-intensive version for users who cannot (or will not) use JavaScript*, rather than trying to shoehorn the same functionality in a different way on the same page.
I've got to go with Marcin on the value-versus-name thing, though. Since the value of a submit-type control is its label text, it would be too easy to inadvertently break an application because some PHB doesn't like the wording you've chosen over six months of focus groups and marketing interference.
*Laws and guidelines governing accessibility consider users who are administratively incapable of enabling scripting in their browsers, such as corporate users whose settings are administratively controlled over the network, and users who will not enable scripting because of a perceived threat, to be "disabled" for the purpose of the law (Section 508) or guideline (WCAG).