Musings of a Trained Monkey

I’ve been doing some research into providing support for section 508 accessibility compliance for a simple file browser available inside a web browser. There really is a dearth of information available on the topic from a software implementation stand point.

Java Applets seem to pay lip service to providing support for accessibility by the addition of tons of code labels that would need to be maintained with each release. Certain activities don’t seem to be supported at all for users with accessibility needs (opening tree nodes for example). The most recent documentation I could find on Applets and Accessibility on Sun’s website is called What’s new in Accessibility and is dated October 30, 2000 clearly Sun took their role as an industry leader in web technology very seriously…back in 2000. (As an aside is referring to a user of an applet as a Robot just a little offensive to anyone besides me?)

Adobe Flex, however, seems to view accessibility as a core issue in the design of their product. So much so that they provide a very simple xml attribute for MXML files (<accessibility>true</accessibility>) to turn on a host of accessibility features. This requires almost no extra effort on the part of a software developer. There are a small number of caveats to their support, but they have taken the steps to detail them and best practices for accessibility on their site including a functional understanding of how Flex works with JAWS and Braille screen technologies. Adobe even maintains a current website dedicated to the accessibility of their products.

I am a huge fan of Jetty for Java web application development. Love how fast it loads, reloads, and generally kicks the crap out of Tomcat. The Jetty team seems to follow the JEE specifications that they do implement (not all of them) much more strictly than Tomcat. This makes it a very good testbed for developing applications that will be eventually hosted on WebLogic Server .

Until you need to do something like run Message Driven Beans with WLS special performance enhancing sauce. Jetty has it’s jetty-plus configuration which supports JNDI and some other JEE niceties. If you really want to use the full on BEA JMS/MDB combo though you have a problem.

Including the weblogic.jar in Jetty’s classpath is not the answer. This will cause all sorts of confusion about which implementations of java. * and javax. * packages to use. Within the WebLogic Server distribution’s server/lib directory there is a wlclient.jar. Again this won’t work right in your overall classpath, but it will work if you put the wlclient.jar inside of a webapp’s WEB-INF/lib directory. Your code will just need to make a small accommodation for connecting to WLS JNDI constructing the InitialContext with the WebLogic specific properties:

    Properties props = new Properties();
    props.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
    props.put(Context.PROVIDER_URL, "t3://localhost:7001");
    InitialContext ctx = null;
  try{
      InitialContext ctx = new InitialContext(props);
       (...Lookup JMS Queues, place Messages, etc...)
  } catch (Exception e) {
     (do something!)
  } finally {
       try{ ctx.close() } catch (Exception e) { (eek! just have to eat this one!)}
  }

This gives you the flexibility of using Jetty configured JNDI objects as well as leveraging WebLogic JNDI objects without having to eat huge WebLogic redeployment startup times for your web application.