I pointed out these issues at Lotusphere. There's no structure to the html and an over-reliance on javascript. Switching off CSS and Javascript means that the pages look a mess and don't work. You can create accessible XPages but you have to use the code view to start to add back the missing items (like a links, marking up navigations as lists etc).

But that's the problem: it's hard to do the right thing with XPages as the default is this mess, but it should be the other way round: make it easy to build proper modern and standard complying pages and hard to build a mess.

I really don't buy this "it shouldn't be JavaScript dependant" argument, this day and age.

Javascript is ubiquitous now! If you're building an application that needs to work on a 10 year old Nokia, write a separate interface.

There's a million things a user or company can do to sabotage their experience. Like unplugging their monitor. Should x-Pages have a special mode for when people unplug their monitors?

Am I right or am I 9/10th's right?

Tell that google... Or screenreader (Wasn't there a law in some contries to make your websites accessible in certain circumstances?) There is a difference between using JS everywhere to enhance your browsing experience and leaving out a way to use it without JS.

I do not see this as a priority:

1.) the HTML created by an XPage highly depends on what the developer does with the XPage. You code directly in the markup and fix many things if you want to.
You can even disable the automatic code generation and put out completely customized HTML if you like.

So, from my point of view things are not that bad.

2.) for a high volume public website I agree that it should work basically without JavaScript.
But that'a not what XPages are for. XPages are for building *applications*, not websites. And if a user wants to use an application, he needs Javascript and a modern browser.
With the same argument you could ask for support of Internet Explorer 5 or Lynx. Both wishes are out of the question.

3.) I agree that supporting Accessibility should be delivered in the near future.

4.) Passing the HTML validation test without error would be nice. But how important is that really? When all modern browsers (IE 7,8 / Mozilla, Webkit, Opera) work with a XPages application, what point is there really to have 100% valid HTML?

And, take for example this very ideajam page. How valid is that? It has 92 errors in the validation test. And how votes for "making ideajam 100% valid"?

Take a page from amazon.. I just validated amazon.de Homepage and it has 1635 errors.

Even google.de has 42 errors.

So again: how important is 100% valid HTML?

Any software (XPages or something else) should not generate worse code than I can do myself. Better code also is lowering your risk that new browser releases will break your site. I find it is a huge disadvantage that nearly every new browser release is causing major headaches for many IBM products like Quickr or Sametime.

@Julian Buss: The Idea itself is not about standard complient (I let that out on purpose, as I know that this is a fragile argument), but I would argue, that standard compliant reduces your risk to blow up future browsers (see @6), makes the code easier to read, cleaner and smaller, and also accessible. Also, I don't see any reason to not do it in a framework: if you can do it as easily standard complient than not, why risk the non standard complient way? Why make it hard for people to do it properly?

Not every page needs to be standard complient, but xpages is not only not comliant by design, it goes a long way to discard any proper coding convention there is in modern web dev.

For the JS issue: xpages will be used in web pages (see this ideajam or the IamLug website) and people will complain if their pages will not get into google, because goole won't see the content. Again: why make it hard to be a good guy?

A Framewokr should make good code easy and not hard.