Domino Can't Do Accessibility
Abstract: Domino can not do accessibility. Whether or not this sounds like me whining again, this really is a big deal.
Remember I wrote an article about server-side validation? Remember it had this demo form that went with it? The idea of this form was twofold. Firstly it aimed to show how you could prevent users bypassing validation. Secondly it was meant to show how you could validate forms even when there was no JavaScript support. Well, the form still works in combatting the first of these worries, but, as I've since realised, fails miserably in addressing the latter issue.
The form I used to show how you could validate data without using JavaScript relies itself intrinsically on the use of JavaScript. How does its Save button work? With a _doClick() call! Now I think about it I feel quite foolish and even embarrassed about having ever suggesting it could address accessibility issues.
This all ties in with the accessibility research I've been doing recently. I am fast coming to the conclusion that Domino can not achieve the fundamental requirement that sites work equally well with no client-side scripting. Apparently stats show that users with no JavaScript account for about 11% of us. People like Lillian.
What's the problem? Well, take JS away from a form and you only have a submit button that will simply post the name/value pairs for each field to the server. There's no _doClick() and no way of appending &Seq=1 to the URL.
When you do things the Domino way you can have a button with code like this:
@Command([FileSave]);@If(hasErrors;"";@Command([FileCloseWindow]))
There are two outcomes of pressing this button. If hasErrors is true the form simply recomputes and becomes ?OpenForm&Seq=X. If hasErrors is false the $$Return fields kicks in and the user sees the resulting document.
In my demo form I used this button code in conjunction with a WQS event, which set SaveOptions to "0" when hasErrors was true. The document was never saved until hasErrors was false.
Take JavaScript out of the equation and there is no way of doing this. Domino won't allow you to have a two-way session with the server. By session I mean that we submit the field values to the server and it lets us send them back to the browser using the same form, so that the user can make corrections, but without ever saving the document until validation is passed. Like the whole &Seq=X thing.
What might be a workaround for this? My only idea so far is to simply save the unvalidated document, but with some kind of draft/unvalidated flag field on it. These documents exist in limbo until validation is passed. If this doesn't happen an agent runs and removes unvalidated documents created more than a couple of hours ago. Every view will have to omit these documents. What a hack that is! Why can't we have some kind of session with the server where field values are remembered until the all clear is given to commit the document to the backend? As I see it, Domino does not work without JavaScript. Hence, Domino is not accessible. Hence all Domino sites fail to meet with the growing set of regulations in various countries around the world.
Somebody tell me I'm wrong!
Skip to the 
You can subscribe to an individual
I do not think you are wrong. One of the biggest failings of the Domino web platform is that developers do not have access to the browser session information that other platforms enjoy. The ability to take the fields the user has entered and place them in memory until they are needed, is what you need but can only achieve via a temporary save with disk I/O.
Technically this is the way things were done with CGI scripts 10 years ago, and it is only Lotus that has not kept up with the times. With writing values into a memory heap, they are automatically deleted when the servers session timeout is met.
I humbly submit that in the year 2005 there is no good reason for anyone, yes, I said anyone, to be using a browser that does not support JS or for that matter have a current jvm installed. It is time for users to upgrade rather than insist that companies pay developers to code down to their level simply because they don't want to or don't know how to install a jvm or use a JavaScript enabled browser. Having the knowledge to know that these things are required is no longer and option, it should be a hard and fast requirement. It is time to start holding users to a higher standard! OK I feel better now.
Jeff. Thanks for confirming my suspicions. All we need now is a way round it.
Curt. I agree, but that's not the point. If your site is governed by the guidelines you need to meet the criteria within them. Domino can't do this.
I do not agree Curt. Accessibility is important. And not only for blind men : nowadays one can connect to the Internet with lots of devices such as mobile phones, which actually, for lots of them, do not support javascript (nor any jvm!).
Today, checking your mails or surfing properly your favorite websites with your mobile phone is not toying, it's pretty affordable (at least in France), and it works. I believe this trend will grow up fastly while new mobile phones become cheaper. You cannot exclude that population by marginalizing them.
You could post to an agent, which creates the document if all went well -
or sends (creates) a new html form with the fields that were correct already filled in, and with the error fields empty. You could even add comments to the fields that didn't validate :-)
Jake,
A couple of years ago I was involved in a project making intranet websites accessible, and back then none of our so called 'Accessibility Experts' said anything about javaScript breaking accessibility rules.
You could very well be right, but where is this rule stipulated?
Yogi...My rant was mostly in jest. I know that we as developers can/should make sites accessible. I have seen phones/blackberries that download and play mp3s, take/play video, take/send still images, IM/email. I have to say that the only thing a mobile phone does well is allow me to have a conversation. Using it for any of these other tasks means settling for what you get, low resolution, pain in your thumbs from trying to use the sorry excuse for a keyboard, Oh and don't forget the glasses/contacts you will need by age 20 from spending countless hours reading your 2x3 inch screen! Sorry, I know I have deviated from the topic. My point is just because you can, doesn't mean you should.
WAI Priority 1 states that:
6.3 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.
WAI Priority 2 states that:
6.4 For scripts and applets, ensure that event handlers are input device-independent.
This means that:
i. if you use Javascript, provide an alternative for non-JS browsers
ii. if you use Javascript, as well as providing an alternative for non-JS browsers, ensure that the JS you use is not dependent on things such as mouse clicks etc...
Therefore, onClick is bad (although being able to tab to a button and use return may not be), but client-side validation (e.g. onBlur) may not be, provided that:
i. you can navigate away from the field you wish to validate without relying on your mouse (e.g. using tabs)
ii. you provide an alternative client-side validation for non-JS browsers.
Bearing the above in mind (i.e. the need to always provide an alternative method) it makes sense to provide only one method that works (i.e only provide the alternative) to cut down development and maintenance time. However, this means that developers are often stuck with the option of providing a less satisfactory method to appease the non-JS browser market.
I'm not sure that Section 508 has these specific JS restrictions.
Creating dynamic and interactive sites without JS is a major pain, and removing JS is often to the detriment of type of functionality that can be offered (IMO). That said, removing JS in Domino is probably more difficult than in other applications.
Cheers all
Jonathon
Cheers all
Jonathon
Hi Jake,
First off, you are right that domino does not comply with accessiblity rules, but this is only in the case of when a user "creates" or "edits" a document. It can be easily made to comply when the document is in "read" mode.
The best way to solve your problem, would be to create the form yourself in HTML and submit it to an agent. The agent could then do the validation and print out the form again (if any validation failed) with the fields and their values!
You might call this a "HACK", but it should work. Domino may not be the best at some things, but it certainly does alot for "one" server! It's like the old saying.... "You can be a jack of all trades and a master of none!".... Which would you prefer?
(NOTE: I created a website (about 4 years ago), for the Department of the Environment in Ireland (www.environ.ie), that had to comply to W3C WAI Level 3. There is alot to get your head around and since these are "guidelines", some of the steps you can easily do, whilst others are very vague!)
Later
Patrick
Jake
I must be missing something here as I don't understand what 'Accessibility' has to do with any of this.
JS is not proscribed by any Accessibility guidelines that I know of, nor should it be, Accessibility is fundamentally determined by the way technologies are deployed rather than the technologies themselves.
1. You can design the form without JS for those that are not allowed JS though I suggest that if there is much application complexity then I personally would not bother. (Users have to go some of the way)
2. You can validate at the backend using SaveOptions etc etc
3. You can notify the user of any failure via an agent 'Print' message
4. They can use their Back button to go back to the form, still with the field values visible, correct and re-submit.
?? Where is the 'Accessibility' issue ??
It's perfectly possible to re-create the user page, 'merge' the field values and send it back to them, but it's a shed load of work, why bother when they have a back button !
Those who do not use JS or other client side scripting cannot expect as slick an experience as those that do.
BTW I continue to enjoy the blog, keep it up.
Regards
Jake - that's a fundamental problem with domino architecture that it dosn't provide user session management.
Accessibility/javascript myths:
{Link}
..and this:
{Link}
Ron - I was thinking the same thing. I admit to not keeping up with the latest tech industry jargon, but it appears that somewhere along the way the term "Accessibility" started meaning accessible by all kinds of devices/browsers/etc. rather than the traditional meaning of being accessible by users with physical conditions (blind/deaf/etc.). Is that what you where thinking?
Jake,
The method (or, by your words, "hack") you describe is how I do it, i.e.
1. The Save button does a straightforward submit.
2. WebQuerySave agent validates the submitted form.
3. If validation fails, the document is saved with the relevant error messages and a different form. The user is then re-directed to edit this document, which displays all their data and the error messages.
4. If the document validates OK, it's saved with the appropriate form.
A scheduled agent mops up the 'error' documents.
If the user has JS enabled, they get client-side validation (yes, that's duplication - but for their benefit).
Like everyone said earlier in this thread, if Domino gave you access to the session, you wouldn't have to do this.
Oh and it's possible to write the validation so the JS shares error messages with the server-side validation.
@Bernie
Accessibility means accessible by anything and anybody: could be someone using a screen reader, someone using a mobile phone or a search engine. That's not "someone using a search engine" but a search engine robot.
Another thought...
You can write servlets, and run them using the Domino servlet engine. It ain't great, but it'll do the job, and give you access to the Java session programmatically.
1. Build your own "New" or "Edit" form using HTML, submit to the servlet.
2. Use the servlet to validate. If valid, save.
3. Forward to the URL of your choice, which can just go to a plain old Domino form or document.
Good idea?
Search engines have no business submitting forms, so that's a pretty red herring. And screen readers can handle JavaScript and modified DOMs just fine. The problem isn't actual accessibility, but accessibility guidelines based on outdated technology. Laws relating to the computer world will ever be thus -- by the time legislation can be draughted and passed, a couple of Moore's Law cycles have gone by. But if you're working under a guideline, it really doesn't matter whether or not the guidelines are technically current, they're still The Law.
You can get a perfectly good old-school server-side validation going without _doClick(), but it involves printing the form back to the browser from your WQS (after setting SaveOptions to "0"). That can be made a whole lot less painful if you keep your major passthru HTML stuff in profile docs and use computed text (or CFD fields) in passthru on the form -- you can use the same profiles to generate the printback form. No sequence number is necessary, since your action will either be CreateDocument or SaveDocument.
Shame. I was hoping somebody would offer me the simple alternative I was looking for.
Come on though guys, do you really think I'd use print statements to alert users of errors and then expect them to press the back button to correct them!? This is 2005. Have we come no further than this with Domino. I just want an &Seq=1-like feature, which gives me a session with the server. Not too much to ask surely.
If I wanted to print all forms to browser I wouldn't be using Domino. All my Domino solutions rely heavily on the use of subforms to break down the HTML of the pages. If a part of the site changes I change one subform. Can you imagine the headache of then having to think about all the HTML embedded in the "Form Agents". I mean, come on.
If I printed the error to the browser would it have to be in a frameset so that the standard navigation elements were in place? Or would the form submit result in a blank unstructured page with nothing but the words "Please press the back button and enter your email address" on it. Would this really be a suitable solution to present to a client. The web has come further than this. It's a shame Domino can't keep up.
I suppose one could fudge the cache and print back an error (and instructions as to how to use the backspace key) -- but if the app is used for rapid-fire multi-document creation, cached values may not clear when the new form loads (Mozz had a bit of a problem with that a while back). You could use a (cough) frameset if you were averse to doing an "include" via some sort of profile doc, yes, or you could redirect to a form that uses the query string to raise an error message (pass in a terse message, say &err=email, then look up the long version for display).
And the profiles are not incompatible with the subforms. A bit more effort, yes (well, more than a bit), but that's what you get when you turn off all of the features. (I had to say it, Jake -- the Devil's looking over my shoulder.)
Disclaimer: I haven't tried this.
Don't call an agent, call the same form you are validating and execute the agent on the webqueryopen event, only if there is a parameter &submit=1 in the URL.
The default values for the fields should include @urlquerystring(@thisname), and you should have hidden text lines with the errors, that only show when the field has an error, and &submit=1. This way you would have a pretty validation webpage that is easy to build.
The caveat here is that we must show the user a success webpage if the values he submited are valid, and I don't know if we would be able to redirect the user in the webqueryopen event. However, if any of you have an idea for this, I think that we would have good solution.
On second thoughts: maybe submit initially to an agent, that redirects you to the success page or to the same form (passing the same parameters the agent received) if there was an error?
P.S. There is also the problem that you wouldn't be able to upload attachments with this method, but this is not a problem (at least for me) for most webpages.
Hi Jake,
I think i have the another solution for you!!!... All that it requires is a WQS agent and a WQO agent!
I now it runs along the lines of what you suggested, but you can use the WQO to delete the original document (i.e. step 6).
Steps
************************************
1) User enters a new form and submits it to the Server.
(e.g. test?openform)
2) The WQS agent saves and validates the form.
3) If the validation fails, the WQS redirects the user to the same form with a URL parameter that is the UNID of the saved document!
(e.g. test?openform&unid=###...)
4) When the form opens you check to see if a UNID has been passed to the form... If it has you call the WQO Agent.
5) The WQO Agent, gets the original saved document, populates the fields for the form!
(NOTE: You can delete the document at this stage, but if the user refreshes the form, they will lose all the data they entered!)
6) The form is now populated with the data the user originally entered, plus it contains the validation message you want to display!
7) When the user attempts to save again, you can
a) update the original document
OR
b) create a new document and delete the previous one!
8) This cycle can be repeated as many times as you like and should be fairly easy to implement!
************************************
I have tried the process above and it works pretty well.
Again, you will have to have a scheduled agent to delete the "non-finished" documents!
Later
Patrick
P.S. Let me know what you think!
For information, i've tried to use a RequestDispatcher (towards a domino form) with a servlet, but it does not work (error 500)
Patrick beat me to it. I was thinking a lot about this last night, even drafted a blog and started a demo database I'll try to get done tonight.
Coming from the corporate world (as a subcontractor) the reality is: Domino is GREAT for R.A.D. I built a skills assessment system that was use as the template for an oracle backe peoplesoft app (not the best choice, but out of my hands). My proof-of-concept idn't take long and was fully functional... but the underlying architecture, standards mode, accessibility, maintnance, all made hellish by the plethora of hacks it entailed. For real "must meet all criterion" work, JSP, JSEE, Struts... these things are the future. Maybe Ruby on Rails.. not sure... it appears to have a lot of the same canned functionality that we today curse in domino (was once standard or near, but now lags).
All is not lost, though. Domino can still be the template. We just need to realize when it's time to up the game a notch and start bringing more complex architectuers into play. I hope to illustrate this can be relatively painless in my demo and blog later.
Cheers
Am I missing something here? I'm currently working on a system that allows the user to edit unlimited numbers of documents all shown at the same time on the same screen something akin to a spreadsheet. Obviously this is something Domino doesn't do (i'm using R5, but I suspect it's no different in R6).
The solution I came up with was a Ls Agent. the user clicked a link that just opens the agent. The agent can tell this is a GET request so renders the page for you in full html. When you "submit", the browser merely POSTs back all the name/value pairs to the same agent. The agent then validates the data.
if it's not looking god, then the agent merely redraws the screen again filling in the values you posted into the INPUT fields and an appropriate error message. So the user gets back all the info they typed in previously, including the error messages and nothing has been saved to any documents.
if the submit was valid, then the agent merely creates a document (or in my case many!) and pushes all the (relevant) fields onto the document.
Now admittedly, this is a serious amount a code. And it's taken me a while to write it. but in the proces, I've written quite a good framework of functions that can be placed in a script library and you merely call them from another agent. Each agent then only needs to do the html and call common functions for the value of the input fields (who are blank for a GET or filled in with anything POSTed).
And my agent does more in that the agent actually runs with a parent unid as a url parameter and displays back the details of the children documents as a spreadsheet and on submit it updates them accordingly cutting down on needless saves.
Personally, I write a hell of a lot of html as the Domino html sucks, so I love writing web agents. This has to be the slickest way I've seen to allow you to edit 20+ documents at the same on the same web page with only one post to a domino server - and I can't see any reason why it can't be used to solve the accessibility issues you have...?
Patrick. That's similar to the solution I dreamt up. Some variation of the two will get used.
H. What you're missing is the fact that I want to use Domino's RAD environment to create my solutions. Not because I am lazy, but because any system should be easily maintained by the next developer to work on it. Forms should be forms and not HTML streamed from an agent. If you're not going to use even the most basic of Domino design elements, why bother using it at all?
For the past few weeks I've been working on a generic solution to field validation in Domino, and I think it might be of some help with regard to the server-side validation issues. The basic overview works like this:
once the form is submitted each field validates itself and saves validation information to the form as flags eg. field1InvalidChars:=1, field1InvalidNumber:=0. When the WQS runs it checks if any of the validation flags has been set to invalid, and if not sets SaveOptions to true. If SaveOptions is not true, then the form is invalid, and $$Return sends the user back to the form with something like "?OpenForm&field1=Some_Stuff&field1InvalidChars=1&field1InvalidNumber=0".
This means that not only is the user returned to the form with the fields populated with their previous entries, but also that the validation flags can be used in computed fields to show which fields are invalid and display help associated with that field.
In my app I abbreviate all the validation flags in the url (&f1ivc=1&f1ivn=0) - as you can imagine, the URL could get very long, and it looks like 2048 characters is the maximum for the path component. I have got the InputValidation event of the form generic enough now so that it only requires a few lines of individuation at the start of each field, and then the relevant validation limits are populated from a profile document, and each field not only records its own validity state, but also adds itself and its values to the user values to be returned in the url and adds its validation flags to the list to be returned in the url. Now validation control and user feeback are controlled on a field by field basis from a profile document.
I don't need to avoid JavaScript for this app, so I have never really looked at that URL command. I think this is still going to require JavaScript when it comes to saving the form (I'm still calling a _doClick()). So it doesn't answer that 'accessibility' problem. However, surely there is some way round this using the ?SaveDocument URL command?
I hope this is of some help to you. Over the past few years I've learned a lot from people like you and Stan, and I'd be chuffed to give something back.
"I don't need to avoid JavaScript for this app, so I have never really looked at that URL command..."
Sorry, that refers to the ?CreateDocument command. My initial thought is that or ?SaveDocument could be of use.