Category Archives: Jaspersoft Interface Framework

Getting Started with Accessibility

The Challenge

The paradox of web accessibility is that learning how to achieve it is not very accessible!

The problem is figuring out where to start. While there are a number of obviously relevant standards and examples available online, it was hard for me, as an accessibility novice, to sort through these guidelines to help our development team construct a set of concrete tasks that would return the greatest accessibility improvement for the least effort.

As it turned out, the thing I needed in order to understand how to prioritize our efforts, was to spend a day and a half sharing our upcoming release of JasperServer with a customer and that customer’s accessibility consultant. The results of this experience were both humbling and encouraging. The humbling part was the discovery that in its current state our brand new interface framework was not very accessible. The encouraging part was that with just a few hours work, once I knew what to do, I was able to use the systematic nature of our new system to make significant accessibility improvements.

The key to all this, of course, was the opportunity to work with experts in a real-world setting, and to be able to make changes and test them in real-time. While there will be no substitute for this experience, I’ve distilled my learnings into the following list, which I hope could be helpful to any web designer trying to understand how to begin improving the accessibility of his application.

Comply with Keyboard Standards

Users of screen reader software do not ever use a mouse for two reasons. First, they drive the screen reader software through keyboard commands so leaving the keyboard is awkward. Second, the rapid movement of the mouse tends to overwhelm the screen reader software which cannot keep up with the rapid change in input focus. While JAWS (a popular commercial screen reader) does have a ‘virtual’ mouse that permits a user to simulate a mouse click via the keyboard when nothing else will work, this cannot be relied upon because it is not part of any general standard. As a result, in order to be accessible, all required user events must have keyboard equivalents. In addition, these keyboard equivalents should meet the standard expectation (e.g. return key follows a hyperlink) to make them most useful and intuitive.

The key point here is that by using the screen reader experience as the baseline design context, we will also achieve accessibility for the larger community of users who are sighted but must, or prefer to, use a keyboard and not a mouse.

Embrace ARIA

The ARIA standard (Accessible Rich Internet Applications) is being widely adopted by the accessibility community. We tested ARIA markup with two screen readers, JAWS and NVDA (an open source screen reader) and found that both were well along in supporting the ARIA standard by providing appropriate context-specific instructions when encountering ARIA markup.

In general, adding ARIA markup is very low risk as it takes the form of element attributes that have no direct effect on rendering or behavior. Some of the attributes—particularly those targeted at improving orientation (ARIA ‘landmarks’)—improve accessibility instantly. Other attributes, such as those associated with what ARIA terms as ‘widgets’ can’t be added until supporting interactive scripting is also added because these attributes cause the screen reader to announce behaviors that must be supported with custom scripting.

Add Headings

Adding heading tags to the markup was a simple and effective method for improving a screen reader user’s ability to navigate pages. We also learned that it was not a problem for the headings and the ARIA landmarks to provide essentially redundant information. Screen reader users have the ability to navigate by heading or by landmark, often switch between the approaches depending upon what appears to be working best and don’t have a problem sorting out any redundancy.

Provide Non-Visual Feedback

It is common now in web applications for a user event to trigger an update to only part of a page. While this change is generally obvious to a sighted user, it is completely hidden from a blind user. There are ARIA standards for dealing with this exact issue by triggering alerts that will be spoken by screen readers. These attributes must be added to any scripting that dynamically updates pages, or generates error messages and alerts.

Fix Links

Web applications can be written to assign HREFs to anchor tags dynamically. Unfortunately, anchor tags without HREF attributes are not recognized by screen readers. This limitation can be addressed by adding empty or dummy HREF attributes to anchor tags but the implementation must be tested in all target browsers as there is inconsistency in how browsers treat the placeholder HREF attributes.

Develop Internal Best Practices for Accessibility

One cannot create an accessible application overnight. It will happen over time as long as an organization has a development culture in which accessibility is given priority. This can be helped along with simple tactical steps such as ‘Accessibility Checklist’ for developers and more strategic ones such as requiring that QA personnel, designers and developers build up a comfort level with using screen readers for testing prototypes and production code. In order for this to happen along with other priorities the best approach will be to establish that accessibility is neither an afterthought nor a special case, but part of creating semantically sound markup that benefits all users.

Work with an Accessibility Consultant

To achieve more than perfunctory accessibility compliance it is crucial to develop an ongoing relationship with an Accessibility consultant. There are several reasons for this. First, building a culture where accessibility is a core value requires that development personnel meet and observe individuals who rely on assistive technologies. Second, while QA tests can be created to validate standards compliance, observing real disabled users is the only way to know if an application has achieved real world accessibility. Third, as standards and assistive technologies are still in a significant state of flux, any organization, but particularly one where the understanding of how to implement accessibility is immature, will benefit from advice and guidance from an expert source.


The reality of accessibility is that it is no different from usability or simplicity or any other system characteristic: it can only be achieved by making it an ongoing and central priority.

While this might sound as if accessibility will then compete with other priorities, in fact improving accessibility helps to advance the quality of the user experiences for all client applications. In essence, accessibility is about delivering markup to assistive technologies that is appropriate for those technologies. Seen in this light, there is little difference between designing for accessibility and designing for mobile or any other experience. In all cases what needs to happen is that the application server delivers to each interface client code appropriate to its particular capabilities. As there is no doubt that support for a diversity of devices is the future for all software applications, all that needs to be done to improve accessibility compliance is to always consider assistive technologies in the mix of supported devices.

A Picture of Simplification

My friend and Jaspersoft colleague Matt Dahlman recently forwarded me a nice image he’d made that captures the essence of JIF, our new interface framework.  In Matt’s words:

The attached image shows the actual HTML code behind the menus that a user sees in v3.7 vs v4.0. It makes the idea pretty clear that a developer will find this new system cleaner, easier to customize, and generally better.

Thanks Matt, this is a great way to visualize the simplification JIF has brought to JasperReports Server.

Truth is, we’ve actually made things 3 times simpler than even this picture shows!

Matt is actually showing only one of the 3 different menu systems in 3.7.  Yes, believe it or not, in the bad old pre-JIF days JasperServer had 3 totally different menu systems, each used in different parts of the application.  These menus did not share markup, logic or presentation code and learning to customize one didn’t teach you a thing about customizing either of the other two.

JIF has a single menu system for the entire application with a simple, standardized method for customizing content and appearance.

Just what you’d expect from a state of the art interface framework.

Why Renovating the UI Layer is Hard


About one year ago I was extremely excited that my colleagues and I at Jaspersoft were about to embark on a re-design of the UI for our flagship product, Jaspersoft Report Server.

Actually, it was more than a re-design, it was a complete renovation of the UI layer.  All of our existing markup, styles and script would be replaced with a standards-based framework of our own creation.

I had conceived and sold this project to Engineering, Marketing and our senior executives because I truly believed this renovation was the required and foundational enabler for a host of initiatives.  Primary would be the development of a great user experience, but I also expected it would enable greater community involvement in our development process, more efficient development cycles, faster prototyping, and better stakeholder communication.

I still believe all that.

But man oh man, at what a cost!

The official project estimate was 6 months. My belief was that it would actually take 8. In reality, all said and done, it will take us 12!

We began the project with a team of 4.  We will end the project with a team of 12.

Words of wisdom from my former manager at Apple, Bob Baxley, ring in my ears daily. When I arrived at Apple (for my brief tenure there) the store website had just undergone a major re-design. Discussing that experience with me, Bob said “those of us who were here for the re-design feel more like it was something we survived rather than something we accomplished.”

With our UI renovation nearly behind me, I now fully appreciate the feeling that Bob was trying to explain.  I also have a pretty clear idea of why this project was so much harder than we expected:

  • We did not, and frankly could not, accurately understand the true amount of re-work that was going to be required
  • In trying to create a state of the art result, we sometimes had to innovate, but had not accounted for the time of the resulting iteration cycles
  • We could not always keep ourselves, or our internal partners, to the limited project scope we had set
  • We overestimated the efficiency that standardization would bring to the design specification process.


We knew from the outset that we were going to replace every single line of markup and css during this project.  We also knew we were going to replace the lion’s share of the javascript. We even anticipated that we would be creating a new kind of an ‘API’ between the javascript and the css selectors to be able to use class names to trigger certain UI behaviors (e.g. anything with class ‘button’ will automatically get mouse event handlers applied).

We actually did a decent job estimating this work, and we even structured the project schedule to include two entire phases devoted to designing the CSS/Javascript API and then testing it by building two workflows before applying the new framework to the entire product.

However, the piece we did not truly consider in our planning was the cost of re-writing all the logic embedded in the markup itself.  We are a Java shop, so we use JSP files to create the markup delivered to the browser.  In this project we did not correctly estimate the time cost to re-think, replace, and modify the logic in these files.  I think our mistake was to base our estimate on an extrapolation of our experience converting over a few pages.  The problems with this procedure were, first, that in our test pages we did not actually change all the little things we needed to change in the production version so we ended up with an overly optimistic effort/page factor.  Second, the ‘average’ page was a myth.  Every page took at least as much time to re-write as our ‘average’ estimate and many took far, far longer.

Cutting Edge or Bleeding Edge?

Our goal in this project was to create a modern UI framework, comparable in concept, if not scope, with YUI or Dijit/Dojo or MochaUI.  Why we rolled our own is another post, but the point here is that these things are still quite new and it isn’t always clear what is the best way to solve the various issues involved in creating them.  While we could rely on standards documentation to help us conceptually, transferring those conceptual ideas to an actual implementation involved innovation and risk.

For example, we had ambitious goals with respect to improving the accessibility of our interface during the re-design.  However, as we progressed we learned that without experience doing this work, ambiguity in the accessibility standards documentation meant that we spent a considerable amount of time debating the best implementation approach, testing ideas, re-doing work and even ultimately giving up on some goals as we ran out of schedule time.

Scope Creep

The agreed scope of this project was to renovate completely the interface framework, while leaving the fundamental application navigation and workflows intact.  In practice it turned out that we could not keep to this restriction for 3 reasons.  The first was simply that sometimes it was not possible.  Our new framework includes forward looking design concepts and interactions and in some cases we could not map our older, circa 2002 UI directly onto the new framework.

The second reason was sometimes it was just too painful to leave the old design in place.  For example in situations where it was clear that we could replace a 3 step wizard (complete with 3 page loads) with a single, reasonably simple form, we went ahead and did just that.  Each time we made this kind of usability improvement we cost ourselves the time involved in re-writing page logic.

Finally, our internal partners had trouble keeping to the original scope agreement.  During this project nearly the entire marketing team at the company turned over and the new team chose to re-open some of the design decisions we made with the previous team.  Discussing and implementing these changes cost us several man-weeks of effort.

Not Cookie Cutter

A major driver for this project was to improve the consistency of our interface.  The old UI had been built up over several years by different developers working without any design management so different sections of our product had different design conventions, interactions and even look and feel.

Our assumption was that cleaning up this inconsistency would be straightforward once we had designed and built a systematic layout structure and a standardized set of components.  In practice we found that the application of these standards to our existing pages and workflows was more time consuming than we expected.  As we began to convert pages we found that we were missing both layouts and components.  We also learned that even our augmented set of standards still only applied about 80% of the time–nearly every page had some particular feature that required some custom layout work or specialized markup.

There were also a few unfortunate cases in the oldest part of the application where what was expected to be a simple task turned into days and days of unplanned code re-factoring.  This occurred where our state of the art approach to  separating the logic, structure and presentation layers of the UI required us to untangle monolithic server code.  For example, in the section of our application that displays paginated reports, the trivial sounding task of making the pagination controls into a general component, instead of a custom element embedded in each report, took literally 10 times the expected effort.


Anyone who has ever been part of renovating a house has experienced the budget-busting moment when opening up a wall reveals an entirely unexpected set of existing conditions.  These painful moments serve as humbling (and expensive) reminders that it is simply not possible to anticipate all the risks involved in a truly complex project.

We discovered that a home renovation was an excellent analogy for our experience replacing the UI layer for JasperReports Server.  The project took far longer than we expected, and was much much more painful that we anticipated.  The outcome, however, like a lovely new kitchen, will be a pleasure to work with for years to come.