Accessible Web Forms With Domino
What I like about being a web developer is the constant need to learn. If I were to move away from Domino, one of the driving factors would be the feeling that I've learnt everything there is to know. It gets boring for me once I'm no longer learning new things. Although, that said, every now and then, I surprise myself and learn some simple new trick that's evaded me for years. Domino never stops surprising me in that way.
A comment posted yesterday inspired me to come up with a brilliantly simple solution to the problem of multiple buttons on a form which doesn't allow JavaScript. Jeff Crossett reminded of me of an important fact: that a button with a name is submitted to the server as a name/value pair, just like a normal field is. After all, a button is in fact just another type of <input> element.
A normal submit button created by Domino looks like this:
<input type="submit" value="Save">
Notice it has no name attribute! This is why it doesn't get sent to the server with the other fields. But, you can create your own buttons that do have names, like this:
<input type="submit" name="Action" value="Approve" /> <input type="submit" name="Action" value="Reject" />
Depending on which of these is pressed the browser will send its name and value to the server. Say we press the Approve button it would POST the following information to the server:
This is exactly the same information that would have been sent if we had the following normal field on the form:
<input type="text" name="Action" value="Approve" />
Jeff suggested that we could work out which button was pressed by examing the Request_Content field using LotusScript. Thankfully, this isn't necessary. We don't need any script at all. Because the button is submitted just like a normal field, that's all we need, a normal field on the form with the same name as the button. In the above case we'd add a field called Action and this would have a value of either Approve or Reject, depending on which button was pressed. This field can be accessed by any WQS agent and the logic for processing the form can use its value. Magic!
I've put a very simple demo Form online. Look at the source. Note there's no JavaScript used! There's not even a WQS agent. This form is as accessible as they come. It would even work in text-only browsers like Lynx.
I plan on extending this demo with more in-depth examples of this technique, as well as showing other ways of making Domino sites accessible to all. You might not appreciate it, but accessibility will become increasingly important in the future. Rather than a passing fad it's a law.
Is this yet another hack? I don't think so. If it is a hack, it's an elegant hack. I'm fussy about what hacks I use and I'd have no qualms with using this one. All I've done is over-ride Domino's default button. Is it such a hack that I should think about whether to use Domino in the first place (as a couple of you suggested yesterday)? Not at all! I'm still using every other facet of Domino, just not its HTML.
Skip to the 
You can subscribe to an individual
Fields with the same name.......
That's brilliant Jake. Very cool indeed.
No, it's not a hack. You're actually writing your HTML form in the way it should be written.
As for what's going on "server side", I think even I might be able to pick up that code.
Especially if you put a comment in. ;->
Jeff. The best solutions are always the simplest. If you only want one button you can actually turn a field in to a button by adding "type=\""submit\"" in the field's HTML Attributes. How cool is that!?
Thanks Arka. The more I think about the way I develop the more I think it's actually easier for a new-comer to get to grips with. I only really use forms, views and agents. No pages, outlines, navigators, applets, folders or framesets. My code is just HTML with fields intermigled. How hard can it be to understand that?
I don't know the hell why, i always thought a form could only contain one and only one submit button. I've just read the specs, and it isn't the case :
"submit buttons: When activated, a submit button submits a form. A form may contain more than one submit button."
My life has just changed.
>My life has just changed.
Mine too YoGi. This has definitely changed the way I create Domino web forms henceforth.
Here's an interesting page that talks more about this technique link
Now THAT is a pain in the butt with Struts, and so elegant and simple in Domino. :-) Thanks, Jake!
Well now, this is marked depart from AJAX stuff you were tinkering around with. =)
I wonder, how much different is this than using newer xhtml only versions of form? I've seen some wicked non-javascript stuff being done in that space, but I don't recall ever thinking, "would lynx work with this?".
I guess as a general question - and also as a measure of my own ignorance - what's the level that you're going to in regards to accessibility?
For instance, the majority of corporate websites (external) are really more functions of Marketing, Advertising & Corporate Information. In this regards, as a read-only type app, the use of Javascript, Flash, are things done to enhance the base presentation. All sites, I would assume, should degrade at the very least to a larget text blob/block. Hence, the basics of alt tags, etc. play a part.
That being said, the use of extranents as a function of corporate business/supply chain management, now those sites I've always assumed, would NOT necessarily play a part for accessibility. Wouldn't extranets, etc, be ... I guess more "exempt" from such laws?
Wouldn't a bigger problem be, imo, multi-lingual support? Would multi-lingual support be more in lines with accessibility than the use/non-use of javascript?
Honest questions, I assure you. =) I look forward to hearing opinions.
Hi Bill. The level of accessibility I am going to is a functional one I suppose. My hope is that it will all work without the need for script. The other element is down to designers and deals with contrast between colours and how colour-blind users will see it etc. I'll leave that bit to the experts. I just need to make it function.
I agree that extranets may appear to be outside the remit of the WAI, but I don't see any reason we can't apply these rules to any type of application we choose. Why knowingly create a site that won't work in every situation when it's so easy to make sure it does!?
Really though, this is all farely new to me and I don't feel qualified to argue either way what's right or wrong.
JavaScript is great. AJAX is amazing. There's no need to use it for the sake of it though, especially if it means it breaks a site for some users.
Thanks Jake for your ideas, again. I would agree with you on the forms, views, and agents, but would have to add Script Libraries also to the list just because I like to reuse code.
I am currently working on taking web development one step future and making it document based. Here ({Link} was my first list of specs for fields which has dramatically changed now. Some would say that this is taking it to far, but it would reduce development and maintenance time. Once the forms are done I will be making the views configurable through documents also!
Your button idea is the next on my list of things to implement, so great timing. Keep the great ideas coming.
It's been great to discover this blog! How many interesting things to learn! I told you this by e-mail the first time I met you.
I didn't supposed it was possible to use NOTES as a back-end database, but this is what you do here. But, in fact, I suppose you can still use Groups and Roles (Workflow, I mean) that is probably de only thing Ok in Notes. I wonder if you'll be able to use Author and Reader Fields (don't know if you call it like this in Spanish)
Jose. Not sure I get what you mean. Do you mean that you didn't know this all worked in the web browser?
Jake. I'd argue that what you're doing here is one of the fundamental principles of AJAX (especially on the CSS end). To create a web-based application which can degrade gracefully when used in a feature-disparate browser, or when functionality has been, or has to be reduced for security or accessibility.
An example is trying to use DWA in Safari. Safari will swear up and down that it can't properly use DWA, but then voila, a stripped down (and ugly) version of the DWA application appears. It is usable, and --while I haven't tested this, is looks like it could pass muster were a screen reader to pass over it.
And we all know the best addition to DWA over the past few versions, right? AJAX of course. Maybe not the best example of AJAX, but AJAX nonetheless.
Now having said that, I wouldn't prefer to use DWA this way, but when I'm in a pinch and need to grab a PDF from my mailbox, and I have nothing but my friend's Powerbook, DWA still does what I needed it to do, even if it has to degrade it's quality to do so.
My $.02,
@Jake - The way you've done it creates a dependency on the specific value of the button (ie. it's text). This means if for whatever reason you change the text of the button you need to change the code.
I would recommend giving the buttons the name of the action eg. name="approve" and name="reject", having two matching fields and then a third computed field that checks which contains a value to determine what was pressed.
Samuel. DWA = Domino Web Acess? Is that what they call iNotes now?
Macin. Good point and good idea.
No Jake, the other way around: iNotes is what they call Domino Web Access now. ;-)
No, "Domino Web Access" is the new name for what used to be iNotes in the R5 days. And I think the single name/multiple values approach is better, since it is maintainable with code only, and adding new permitted actions can be handles with a config doc -- only one field needs to be maintained on the form, while multiple buttons can be easily created in passthru (or "treat as") with the simple expedient of fetching values from a config doc. Not that I think forcing server-side activity for all actions is a particularly good idea -- I'd rather it be seen as a fully-degraded condition of the page. Accessibility should not come at the expense of anything else.
I strongly agree with Stan. Not only on the DWA part :-) , but especially on the one name vs. multiple names issue for the very same reason. And, err ... well yes, on his last point, too.
And just in case, anybody got so interested in Domino Web Access (or Shimmer, as it was codenamed), and fired up Designer to have a look at how Lotus did it: Forget about it. DWA was not developed in Domino Designer. It more or less just happens to use Domino as the technical plattforms. Not only does it use completely obfuscated JS (albeit for performance reasons), but also lot's of "precompiled" actions that seem to be passed uuencoded or something. There is (at least) one redbook on customizing DWA and some tools in the sandbox for doing so, though.
Great technology and nice looks, but not really a reference application even for the above-average Domino developer.
Stan. I'm not sure you can put too high a price on accessibility. What's wrong with server side actions for each button? Doesn't any _doClick() involve some level of work back at the server?
Accessibility and JavaScript are not mutually exclusive. Haven't been for years (although it seems difficult to persuade the "experts" that specialised user agents have progressed beyond Lynx). But that's not the argument I'm making -- I'm saying that everything that CAN be done in the client (keeping in mind both client capability and data security) SHOULD be done in the client. Putting the onus back on the server is exactly the same wrong-headed philosophy that reduces seating on buses by forty percent, doubles transit operating costs and makes scheduling impossible by failing to use the simple, (relatively) cheap and effective expedient of operating parallel systems for persons with mobility problems. (And lest anyone go off on a "you don't understand" tirade, I spend rather a lot of my time with canes, a walker, or in a wheelchair, depending on how much mobility my injured spine allows me on a given day -- I like to be as unencumbered and "normal" as I can be. Nobody should have to be late for work because I need to be in a chair today.) You can't achieve fairness by handicapping the undisabled (the "Harrison Bergeron" approach), so if you're going to go to all of the trouble to bust out of the Domino mould, then you might as well do it for a really good reason. The "special bus" only needs to be there for the people who need it.
Very nice and elegant. The only problem? I see with this approach might be in multilingual solutions or similar. "value" is displayed on the button (the label) and perhaps also used programatically in code (@if(action = "Draft"; ...) this means that we need to have localized code in the backend or a "dynamic" variable to test against. It might also be a bit messy if you want to enter something longer than just a word as value or decides to rename some of the buttons for example: from "Add to Shopping Cart" to "Add"
(as Marcin mentioned)
...but its indeed a very clean solution.
Just as an additional FYI, on the topic of accessibility is Jakob Nielson's latest newsletter
{Link}
i tested this example (http://www.codestore.net/apps/accessible.nsf/Test?OpenForm) by http://validator.w3.org/check, and this is not accessible. do you have more information for me.
i must to do web site accessible with lotus domino 7.02. but domino create automatically tags. what can i do?
Best regards,
Luca
Hi Luca. When I say it's "accessible" I merely mean it doesn't rely on JavaScript. Making it pass accessibility checks is a whole different kettle of fish. As far as I know there's no real way to get vanilla Domino to pass the tests. Not without a *lot* of hacking!
I'm learning to program using Domino Designer. So far I have developed a desk top application. Can I see you code for the 'simple demo form online'.
Thanks.