About Accessibility and JavaScript
When I wrote yesterday's post about Domino and accessibility I wasn't sure what or how much feedback it would get. I wasn't sure what interest you guys have in the whole accessibility thing. Well, it seems you are interested and that there is some confusion. Mainly in how JavaScript relates to the accessibility guidelines. The following line (can't remember the source) sums it up nicely:
The Web Content Accessibility Guidelines require that content and functionality be accessible with scripting disabled.
Makes sense really, doesn't it. Sites should still work when JavaScript is turned off. Now, content aside, 99% of Domino sites will not function with scripting disabled. Mainly this is because developers haven't thought about it during the design process. Also it's because Domino won't let you. This is my gripe and that's what I was talking about yesterday - Domino can not meet current accessibility guidelines!
Using script to create fancy image rollovers is ok - it doesn't stop users without script using the site. Using script to validate a form is ok - it doesn't stop the form working. Using script to create fly-out or drop-down menus is ok - as long as the navigation is accessible in other ways. What isn't ok is using script as the sole means of interacting with a website. This is where Domino breaks down. Download the developer toolbar for IE or Firefox and use it to turn off scripting. Now surf the web and see how far you get. Large site like Ebay and Amazon will work fine. Try posting a new message at the LDD Forum though. Or simply try using the search form.
Ok, when I say Domino can't do accessibility, that's a bit misleading. Domino, as we all know, can pretty much do anything. But, only if you're willing to hack the thing to pieces and forego you professional integrity. What I want to do is achieve WCAG 1.0 without using any weird and wonderful trickery. All I need is a session with the server. Instead I am going to have to use a real document - saved to the database - as a temporary session.
More on this on Monday.
Skip to the 
You can subscribe to an individual
Word!
Read/write access a to session object/space is the first item on my feature wishlist
But when you suggest it, people tells you to use WebSphere and "it's not going to happen in domino anyway".
I can't understand why discussions/suggestions about a r/w session in domino aways brings up WebSphere. What does a session in domino have to do with J2EE?
(except that it's already available in Websphere - but hard to access from a form/docment directly from domino and therefor not the ideal solution many times)
I mean Isn't there a session in domino already? Can't it be extended? are there any major technical difficulties in doing so? I dont know, but i sure want it.
@ Fredrik
Would a simple session do it? It seems the biggest problem is Domino's marriage to Forms. You can't use the easy route like Jake wants because when you get to the server on a form submit, it's a document by default. What you're asking about is having forms submit and behave as the DocumentContext does, but you usually get to that by calling an Agent directly rather than submitting a form.
I think, Jake, that you have your session and it is accessible... you just need to make your form action point to an agent and hadle it there. The demo database I mentioned earlier today does this (and now I'm doubly determined to get it done tonight).
As promised...
{Link}
I know it's not push button simple, but as others have been saying, if you want to get where you want to go, it's going to require a different road than you have been travelling.
Jake
A final word(s) before I leave it alone :-)
Firstly, in getting to where we are don't forget that Domino came out of the corporate / business environment and was never designed or architected for 'public' consumption in the way that many other web delivery vehicles have been. Given that, it's hardly suprising that there are a few issues here and there when it's used in the web (as opposed to the intranet) world.
Secondly, guidelines that 'require' funtionality to be independant of scripting whilst apparently accepting that they cannot be independant of browser device seem bizarre to me.
Thirdly, JS is a *** standards based technology *** so it would seem that 'they' have 'approved' its use. Now why would 'they' do that if it wasn't necessary and there were acceptable alternatives ???
Because, of course, there are NO alternatives to client side scripting for certain jobs. PERIOD.
A simple example is drag and drop / drawing, expecially for things like workflow charts / interactive mapping etc Try delivering an application allowing users to select from a range of graphics, place them on a background and connect them together with an arbitrarily complex web (no pun) of lines. Then allow any one of the graphics to be dragged with full rubber banding of connecting lines. No JS ? No application (typical workflow chart) !!
But then 'guidelines' are just that. GUIDE - lines.They are not mandated, they are not the law, and anyway we all know that laws are for the obedience of fools and the guidance of the wise don't we ?
There are many times when compromises have to be made in the design of applications, indeed I submit that you ALWAYS have to make compromises somewhere or other.
Given that JS is 'safe' in a sense that eg ActiveX is 'unsafe' then requiring that users permit JS seems to me to be a reasonable constraint to be imposed for good and sound technical reasons, failing which the additional complexity and cost of development or the loss of functionality is likely to be unacceptable.
As such I will continue to use JS where I consider it appropriate, GUIDE-lines notwithstanding.
Cheers
PS I'd hate for this discussion to encourage anyone to stop using JS (or even Domino, God forbid !). I'd rather encourage those who don't allow JS to see the error of their ways.
PPS Can anyone give me a rational reason to dis-allow JS. Don't say 'security' as the security risks involved in simply using a (typically Windows) PC, especially attached to the Net, absolutely dwarf those relating to JS per se.
I agree with Ron.
What is the reason we are using a web client instead of using rich clients brought to user with java web start or similar technology?
Because the web browser is an ubiquitous client.
How long it took us that now the major browsers are quite near standard?
And now we are setting that standardization to null, because each user might dissable javaScript?
Domino web apps might be usefull for intranet stuff. It doesn't scale very well to a really large user population.
Though you might be one of the few people on our nice planet who might be able to implement such stuff, I can't see the rationale behind it from a business standpoint.
Writing your sites to work without Javascript seems like a waste of time to me. Also, it is exactly the opposite direction the web is currently headed. Ajax, prototype, BaseCamp, Ruby On Rails - this is the future and it depends upon JavaScript.
I can't believe that in this day and age people are suggesting that we just ignore anyone who can't use JS.
Yes, JS has security issues, but that's not the only reason to make your site/app work without it. What if a mobile browser is used to access your site? Or don't they matter either?
And to say that AJAX etc means we "need" JS is wrong too. I use plenty of JS in my apps but it's not for core functionality, it's for additional behaviour. I cater for those users who don't have JS available too though, and so should we all.
Some of the replies here remind me of a few years ago when lots of developers only designed for IE - "it's free, why can't everyone just IE?"
Fact is, accessible design should be the standard way to design. Sticking our heads in the sand is what got us into such a mess of bad practice in the first place. It is possible to design apps that aren't entirely reliant on javascript, it can also be damned hard work, but it's just another part of doing the job properly.
@Fred
I cannot imagine having programmatic session access would be difficult, but if IBM gave this kind of power to Domino nobody would bother with Websphere and IBM will not allow that to happen.
IBM has placed its bets and is forcing customers, that want a solid web development platform, to choose between IBM/J2EE/WS/DB2 and everyone else. Time will tell if the bet pays.
Ron. JS is standards-based? Are you sure?
Ok, I can see that we aren't getting the issue with accessibility. The
For me the wonder of the web is that it makes so much available to so many. The fundamental concept of the web is that it *is* available to all users of *all* devices. the future is bound to see an increase in the number of people using PDAs/phones to access the net (I've been doing this more and more recently) and we need to cater for this. There are very few reasons to rely on JavaScript. Do so at your peril.
Anyway, accessibility aside, my gripe is with Domino and the fact that its core functionality is needlessly tied to a reliance on JavaScript. I don't believe this has anything to do with WebSphere. I think it's merely because Lotus wouldn't have thought far enough ahead to envisage people wanting to do it any other way than their way. Session-based form behavious exists with the &Seq=1 thing, why can't we do this when JS is turned off!?
Jake,
even if you have clients which uses different flavours of html/scripting language to present the content to a user this does not necesarily mean that the generated markup remains strictly under the least common denominator of markup/script capability of the client.
You might create different views for different clients. At least I understand the hide-when for mobile clients options in R6 that way.
Other option is to generate only xml views and process that with different xslt based on client type (cocoon way, afaik). But this might be slow.
@Jeff: Afaik do modern J2EE component frameworks like JSF or tapestry rely heavily on JavaScript, too. Also Websphere has its strength more as an integration plattform than as a engine for dynamic websites. If you stick with pure dynamic webpages you might get happy with Tomcat, Notes, PHP, ruby-on-rails, whatever but not necesarily Websphere.
There is a standard for JavaScript called ECMA script.
{Link}
This spec starts with the sentence:
"This ECMA Standard is based on several originating technologies, the most well known being JavaScript (Netscape) and JScript (Microsoft)."
Maybe I am naive, but I live with the firm belief that every browsers strive for ecma-script compatibility.
I can see both sides to this.
Ideally, there is no reason why the functionality of an app cannot be captured using anything other than w3 compliant html. It would certainly make our lives easier, would it not?
From the Domino camp, we have to accept that Domino is an add-on to Notes and brings all the complications of that interface with it.
So I guess frigging a session *when using Domino* is valid, given that domino itself is never going to play by the w3 rules - it can't.
I'd like to see how websphere does it by the book too...
Bit of a p1553r, that, then!
BTW is your clock out re: the post times?