I mention Oracle in this post so as a reminder: my views are my own and do not necessarily reflect the views of my employer.

One nice thing about working at Oracle is that they take accessibility seriously. I have worked on web apps before that were supposed to be accessible but this is the first company I have worked for where I could actually get my hands on a (non-demo-mode) JAWS screen reader to do my own testing. You can try to follow all the best practices but you really do need to test with a screen reader to know how well you have done.

I have found that keyboard accessibility and screen reader accessibility are somewhat at odds.

If you do the right thing for keyboard accessibility (i.e. managing focus) and don’t use WAI-ARIA at all then you have a chance of being accidentally partially accessible in JAWS and probably other screen readers. This is assuming that you follow best practices for being accessible to screen readers (use label correctly, use native form controls – links, checkboxes etc. in semantically appropriate ways).

The problem is that all your keyboard/focus management logic is in vain since you are probably going to use arrow keys and JAWS is not going to give them to you (JAWS uses many keys for itself). The reason you have any chance of success is because the normal screen reading behavior of the arrow keys may be close enough and using native form controls will allow JAWS to access them in a reasonable way. How well it works will depend on the details of your rich control. The best you can do is to try to find the right balance between normal use and screen reader use. This should work OK with older browsers and screen readers depending on the various bugs and odd interactions between various browser and screen readers.

The other option is to go the full WIA-ARIA route. By using the appropriate ARIA roles and states and properties you can get JAWS version 10 (and presumably other new ARIA aware readers) to give you the keyboard keys you need. For this to work you need very recent versions of browser and JAWS. I have had some initial success with JAWS 10 and FF3.5. It looks like this approach will provide the very best functionality for all users. I have not yet tried the combination of JAWS 10 and IE8. The trouble is that the combination of JAWS 10 and IE7 works quite badly when you use ARIA. JAWS seems to get some of the ARIA information like roles but doesn’t get enough to work correctly. It gives up the keyboard keys but then doesn’t handle the ARIA based changes and therefore the normal JAWS arrow key functionality doesn’t work either. This is the worst possible behavior. Presumably older versions of JAWS that don’t know anything about ARIA will work fine with IE7 even if the rich control uses ARIA provided the ARIA support is on top of non-ARIA techniques mentioned previously. I have not yet tested this combination.

To me this means that if you are adding on to an existing app that must support older browsers or screen readers then using ARIA probably isn’t worth it yet. But if you are starting a new app that wont be released for a while then using ARIA is the way to go. You can still support older browsers but you would have to require that for screen reader accessibility an ARIA aware browser and reader must be used.

Another possible solution is to have an option to turn WAI-ARIA support on or off. I don’t like this because of the added complexity of implementation and testing.

Here are some resources that I found very useful in my recent accessibility work: Improving Accessibility Through Focus Management, WAI-ARIA Best Practices, and Delegating the focus and blur events.

Since my last post where I presented a number of ideas on a declarative domain specific language for implementing web applications, I learned about the language oriented programming paradigm.

I recommend reading “Language Oriented Programming” by M. P. Ward. It also claims programmer productivity as a benefit of what it calls the “middle-out” development style.

In a couple of recent posts I have argued that a higher level language is needed to
provide a significant boost to programmer productivity in the area of web applications. This is a topic I have been thinking about for many years. I’ve worked out some aspects of what I think the language should be. A little over a year ago I even started implementing a parser for the language in ANTLR. I worked on it for a few weeks before moving on to other higher priority projects. Higher priority simply means something more interesting caught my eye. It’s finally dawning on me that I’m not going to get a big enough block of free time to work on this any time soon. I guess I prioritize the smaller projects that have a better chance of getting finished.

Instead of mothballing the project completely I’m going to share some ideas from it. This his may be of interest to others and who knows, I may get back to it from time to time.
Continue reading…

Tools, languages or frameworks — which will have the biggest impact on developer productivity? I previously said that I thought languages could do better than frameworks in this regard. Now I’ll talk about at least one class of tools.

A good deal of focus around developer productivity is on visual editing tools. I think these efforts are misguided and unlikely to produce major benefits to developers. Clearly tools are useful. Humans are natural tool makers and users. Written language is arguably the most important tool invented by humans. Programming languages are tools.

So what do I mean by visual editing tools? My definition may be a little fuzzy but here it is: I’m talking about tools for creating software that don’t have an underlying text based language or completely hide it. They usually involve working with pictures, diagrams, or forms. Some examples:

• Business Process Workflow editors
• Property editors
• Visual UI layout editors

These are some of the general problems I have found with visual editors. Not all of them have all these problems and I’m not signaling out a specific tool.

• Scale — Sometimes the visual editors don’t take scale into consideration. They work well for small programs but break down when used on larger programs. The breakdown may be due to implementation details or a more fundamental limit in ability to comprehend the visualization at large scales.
• lock in — This is when a tool requires you to use a particular platform, IDE, tool set, library or framework. The same lock in is possible with languages but it tends not to be; at least not for the more popular languages. Perhaps that is what makes them popular. As a developer I’m very skittish when it comes to lock in. It is much easier to share (and reach agreement on) a language specification than it is a GUI specification.
• Poor source control integration — Being able to track changes to software source over time is very important. Some tools make arbitrary text changes that confound source control systems. The worst example I have seen is a visual work flow editor that changed all ids in its XML format source file every time you saved it. Binary formats are a definite no-no.
• Lack of flexibility — When writing software in a text based language you are free to write in whatever order your thoughts come to you. Tools that force you to translate your thoughts into specification in a fixed way will end up frustrating users.
• Inefficient — I tend to find that visual editors get in the way after a while (if not right away). They tend to require a lot of mousing around. Once I know what I’m doing typing is much faster.

Good editing tools assist you while working with a text based language. The most basic editing such as random access to the text, insert, delete, cut, copy, paste etc. is sufficient to get the job done and has the benefit of working equally well for all text languages. Advanced features such as syntax coloring, unobtrusive flagging of errors and warnings, context sensitive completion, access to language and API help, type based searching and navigation, refactoring, template insertion/completion, bracket pair matching, indenting etc. are very useful and don’t replace or get in the way of the text.

Diagrams can help visualize aspects of programs but programs are too complex and multidimensional to be fully represented in any picture or diagram so it is a mistake to think that the visualization is the program and can be edited directly. Being able to draw (or even edit) diagrams is a nice add on for a language but the language must come first and stand on its own.

Some tools claim to have an editable underlying text format when in fact it is just the tool’s internal model serialized as XML. This doesn’t count. Not because its XML but because it tends to favor ease of serialization and the needs of the tool over the ease with which humans can read and write it. XSLT is a good example of a language that uses XML syntax. It was clearly designed to be edited directly by humans. The fact that it can’t be fully described with XML schema is probably a good indication of this. I like XSLT but I also agree with Terence Parr when he says “I implore everyone to please stop using XML as a human interface!” (see his excellent book “The Definitive ANTLR Reference”) .

The best development productivity tools help the user write in a given language not replace language.

My first computer was a Texas Instruments TI-99/4A. I got it just before going to college. I had been interested in computers since junior high but this was the first time I could afford one. The primary programming options were Extended BASIC and assembly. Writing interesting programs required assembly (because BASIC was too slow) so I learned TI TMS9900 assembly language. I went on to learn a few others including PDP-11 and 8080.

If you have programmed in any assembly language you know how tedious it is. There are so many details to be concerned with that have nothing to do with the problem you are trying to solve — simple instructions, addressing modes, managing registers, and maintaining the call stack to name a few. Because the instructions are so simple you write volumes to accomplish little. Often you would be dealing directly with hardware devices so at the same time as dealing with the many details of the processor’s instruction set you had to understand the idiosyncrasies of the device IO registers.

Once you got some small useful thing working like writing a character to the screen you made it into a reusable library routine so that you didn’t have to write that code again. Libraries helped but the big leap in productivity came with higher level languages. Frederic Brooks wrote in No Silver Bullet: Essence and Accidents of Software Engineering:

“Surely the most powerful stroke for software productivity, reliability, and simplicity has been the progressive use of high-level languages for programming.”

Structured statements replaced compares and jumps. Expressions took the place of numerous instructions. The vast (well not so vast by todays standards) stretches of memory locations were replaced by data structures. The compiler took care of pushing values onto the call stack and popping them on return.

The details were interesting to a point and there was satisfaction in having the level of knowledge needed to program in assembly language. Making the switch to a language like C meant giving up some control but it was well worth it because of the productivity gain.

The switch from assembly to high-level languages didn’t happen instantaneously. Trust had to be won. Early compilers had bugs. People thought they could do better optimization than the compiler, and at first they could, but compilers got better and better. Compilers could also do something that assembly programs couldn’t — they could compile your program so it could run on different types of CPUs.

Writing web applications today reminds me of assembly language programming because there are so many details to be concerned with: HTML, CSS, JavaScript, HTTP, and browser incompatibilities and idiosyncrasies. Then there is the server side technology; pick one of Java servlets, CGI, PHP, .NET etc. and perhaps a framework or two. Also you probably need to know SQL if your application data is stored in a database. Cross cutting issues such as usability, accessibility, security, performance and internationalization add additional dimensions.

The details can be interesting and sometimes frustrating. Do I really need to know that IE make the href attribute an absolute URL when inserting an anchor into the DOM while Firefox does not? (This usually doesn’t matter since if you use the href property you always get the absolute URL but it bit me once.)

I would like to create web applications without having to worry about many of these details. When I say HTML is the assembly language of the web I’m including CSS and JavaScript. I see the Browser as the processor (CPU) and HTML, CSS, and JavaScript as the instruction set. I get the feeling that we should be programming at some higher level.

There are plenty of libraries and frameworks available that help. Some are getting to the point where you don’t need to know much about HTML or JavaScript (GWT, JSF come to mind). JavaScript libraries like jQuery or Dojo are making it much easier to write cross browser code.

So whats wrong? Like I said, some of these frameworks abstract away HTML so you can think in terms of higher level “components”. The problem is they are still just libraries (for the purposes of this article frameworks are just really big libraries). I believe that larger productivity gains are possible from languages rather than libraries. The languages may be domain specific — for creating web applications — but thats OK. The languages could be compiled or interpreted or some combination of both.

One very important thing that happened with the move from assembly to high-level languages is that one relatively small group of people were able to focus on implementing compilers that did great optimization following the best practices for the particular CPU type while another much larger group of people focused on building their applications.

Imagine if best practices like using a hidden token to protect against CSRF or using the POST-Redirect-GET pattern were built into the language.

Imagine if cross cutting concerns and decisions that usually have to be made up front were compiler switches or runtime options. Examples:

• What level of functionality do old browsers get?
• Is the back end going to be PHP or J2EE?
• Do my users have to have JavaScript enabled?
• Should session state be kept on the client or server?

There are huge opportunities for performance optimizations – on the client, over the wire, and on the server. The optimizations can improve over time independent of the applications. Imagine if css, js, and images were automatically combined, minified, and compressed such that overall response time was minimized.

Yes the abstractions will leak. It will take time for the language implementations to get good enough and for programmers to trust them. I would like to see this happen.

Some may wonder if I actually read “No Silver Bullet” or just pulled a quote from it. After all it says that languages are not a silver bullet. I’m not arguing that they are. I’m saying that they can do better than frameworks. There is enough accidental complexity in building web apps today that a domain specific language could be a big help.

So why hasn’t it happened yet? Perhaps its just that the right framework hasn’t come along yet. Thats the thinking that has given us at least 57 frameworks in Java alone. I think some believe that tools are the answer. It used to be that you could charge money for a compiler. Not so anymore. But that can’t be the problem since most of the frameworks are also free.

Perhaps it is already happening. I have not dug into Links but it sounds just like what I’m talking about.

I plan to write more on this topic in the future.

Recently I had some not so nice things to say about jQueryUI while still professing my love for jQuery. What didn’t come across in that post is that I am hopeful that jQueryUI will become as great as jQuery.

Now it seems I have good reason to be hopeful. John Resig tells us the good news that Paul Bakaus (the lead developer) now works full time on jQueryUI at Liferay and that a new release is due out soon.