For the last six months of 2009 I was working with a team of Flex developers at the Irish Revenue Commissioners on the next version of their innovative PAYE Anytime application. A key objective of this phase of the project was achieving a level of accessibility equivalent to the WCAG ‘AA’ standard.

The application incorporates a number of general features for improved accessibility:

  • Support for “keyboard-only” users
  • An alternative high-contrast style-sheet for vision-impaired users
  • A zoom feature for vision impaired users

We also added features specifically aimed at improving the experience for screen-reader users:

  • Focussable static-text to allow screen-reader users to peruse all content using the tab key
  • Additional announcements to describe each new view as the user navigates
  • Additional verbosity to clarify the meaning of buttons and other controls
  • A skip content feature to allow large areas of content (lists, grids, etc) to be jumped

You can view the application here, but only people working in Ireland and registered for PAYE are able to log-in. Otherwise, you can experience many of the accessibility features on the log-in page or the accompanying product-tour.

There are still fundamental problems that can limit the accessibility of applications developed with Flex. We found fixes for some issues, but we often had to resort to monkey-patching to apply them to the framework.  Other issues have workarounds, but these often require an unnatural change in the browsing behaviour of screen-reader  users. This remains a problem for Flash and Flex: Improving accessibility at the expense of usability is nonsensical.

In addition to problems with the architecture and implementation of accessibility features within Flex there is a general lack of good documentation, articles or tutorials on the subject of accessibility. Many of the tutorials and presentations I’ve seen offer simplistic advice that is inadequate for the development of anything but the smallest of applications. Adobe’s own Flex applications do not appear to achieve anything close to a WCAG level of accessibility and I’ve struggled to find any third-party accessible applications online. To help correct this, I hope to share some of our learnings in future blog entries.

However, despite the cheeky title of this post, I doubt this really is the first attempt at an accessible Flex application, so where are all the others?


Datagrid fans may be pleased to hear that as of version 3.4 of the SDK, the dataField property of DataGridColumn supports nested properties. This has been an oft-requested feature of the list-based classes, as evidenced by a long-standing issue in the bug-tracking system.

Looking at the framework source, the changes to DataGridColumn source code do not differ greatly from the community-contributed solutions that already existed. Some optimisations have been introduced such as the parsing of the dataField property once when the property is first set rather than every time the field is evaluated.

Performance concerns appear to be the main reason for omitting this capability from earlier versions. The feature can be expected to be sub-optimal when compared with alternatives such as a labelFunction or custom renderer. However given popular maxims on the evils of premature optimisation, and the availability of more efficient alternatives should the need arise, it seems unnecessary to discard a feature for this reason alone.

My main concern with using dataField for complex expressions is the lack of compile-time checking. A labelFunction may require more code but you’ll get more help from the compiler if the expression is incorrect. An invalid expression in a dataField property is likely to fail silently and may not be noticed until your testing phase, or perhaps even later. However, if you are generating your columns dynamically or binding to an XML data-provider, then the lack of compile-time checking may be less of an issue.


Recently there have been a few questions raised in the Flex Forums relating to code-hinting problems with Flex Builder. A quick search on google reveals similar issues reported on other forums and blogs.

The problem is known to occur for users of Flex Builder version 3.0.1 who are compiling with version 3.2 or later of the Flex SDK. The solution to the problem is to install the Flex Builder 3.0.2 updater available here.

The cause of the issue is a recent change to the flex-config.xml file that ships with the SDK. Both Flex Builder and the mxmlc compiler use this configuration file during compilation. The change in question is the addition of the “targetPlayerMajorVersion” token into a couple of path-elements. This token is substituted with either “9″ or “10″ depending on the Flash player version you are targetting in your build. This in turn causes the compiler to include a particular version of playerglobal.swc during compilation. Although the addition of this token did not prevent earlier versions of Flex Builder from performing builds, it did interfere with code-hinting for many of the core Flash API classes.

If you are unable to install the updater you can also fix the problem by manually removing the targetPlayerMajorVersion token from your flex-config.xml file (located in the frameworks directory) and replacing it with either “9″ or “10″ depending on your target player version.


Moving on

It’s been a quite a while since my last set of blog posts and since then I’ve left Adobe to strike out on my own and found a new home for my musings (which rather conveniently, is right here).


So far we’ve looked at possible unit test strategies for presentation models and supervising presenters. Now I want to turn my attention to the Autonomous View pattern. By leaving state and logic in the view, the Autonomous View pattern is arguably one of the simplest presentation patterns to understand and implement. But is it so easy to unit test?



In my last entry I took a look at unit testing the classes of a simple Presentation Model application. In this entry I’m going to turn my attention to a functionally-identical Supervising Presenter application. If you cast your mind back to my original investigation of these patterns you’ll remember that the main difference between Presentation Model and Supervising Presenter is that the former extracts both state and logic from the view whereas the latter only extracts logic. So in order to receive user events and manipulate view state in response to these events, supervising presenters maintain a reference to their corresponding view.



As mentioned in the introduction, I’m going to attempt to unit test my presentation model example application first. Of all the presentation patterns I’ve looked at, I’m expecting the presentation model to be the easiest to unit test.


By extracting view state and logic from the view, presentation model classes do not have any dependencies on view classes. They do sometimes have dependencies on each other, so test doubles may be required to isolate the functionality in one presentation model from functionality in another.



You may have caught my last series in which I looked at six different patterns for organising view logic in a Flex client. In this series I’m going to take the demonstration applications for three of those patterns and look at the changes required to effectively unit test them. The aim of the exercise is to gain an insight into how amenable each pattern is to unit testing and hopefully wrestle with some common unit testing challenges along the way.



Towards the end of last year I took a look at six contrasting patterns for organising presentation logic. Some of these patterns are well known and popular in the Flex community, others are very rarely discussed. If you know of any other presentation patterns that you feel are worth looking at more closely it would be great to hear about them.



Like the Supervising Presenter, the Passive View pattern is a derivative of Model View Presenter (MVP). Martin Fowler split MVP into separate patterns to highlight two common approaches for realising MVP.

The Passive View pattern also has some similarities with Code Behind since both achieve a complete separation of ActionScript and MXML.