Feel the need for some networking, experience sharing, nerdy tech talk and some proper snow action? Well i’ve just got the right thing for you then ;)

gotoAndSki(); is holding its second installment in snowy switzerland (what better place for all things wintersport eh?) and there are still some tickets left.

What is gotoAndSki();

gotoAndSki(); is quite different from your usual conference. Instead of sessions and workshops during the day, you’ll have snow sports, fun and networking. The nice mixture of sessions will then start after the slopes are closed, in the chalet conference room, with dinner break (included in the ticket price) between the sessions.

Awesome Sessions

It looks like gotoAndSki(); will have a great mix of sessions, from more technical sessions, to more design and user interaction centric talks. So there is definitely something for everyone.

I’ll be there too & have something up my sleves

Yap, i’m getting the chance to talk at gotoAndSki(); as well. I’ll be talking about advanced Flash/Flex Accessibility Techniques and introduce a small but quite powerful Library i’ve been working on, that will simplify Accessibility implementations in your Applications/Games/whatever. By the way, just because i say it’s advanced, doesn’t mean that only experts will profit from it. Infact i’ll make sure that everyone will walk out with the same knowledge that i have built up, so that’s definitely something you might not want to miss out on ;)

See you there

I’m definitely looking forward to some snow action, great sessions and hanging out with old and hopefully new friends. So get your tickets now, there aren’t many left and the number of participants is limited to keep a nice and enjoyable atmosphere for everyone.

Head over to the gotoAndSki(); site to ensure you still get a ticket … right now! ;)

Oh boy oh boy, aren’t these exciting times to be a developer? :)

So, yesterday – on time for Adobe MAX 2010 – RIM released the BlackBerry Tablet OS SDK Beta for Adobe® AIR. Alongside the SDK they also released the BlackBerry® PlayBook™ Simulator Beta. Both come in a Windows or Mac flavor.

Why is this so exciting for us Flash Platform Developers? Well, you apparently missed the announcement at yesterdays Adobe MAX Day 1 Keynote. Check out the video:

See what they did there? Yup, Flash/AIR is a core functionality of the entire system. Now excuse me if i go all capslock on you all but HOW FREAKING COOL IS THAT!? :)

Now get the tools

So now that i hopefully have wet your appetite, how about we check all the new toys out right away. Thanks to RIM and their simulator we can actually do that quite easily. Head over to their developer website for the tablet os and download the simulator and the SDK for the OS you require.

Since i’m a windows user, my instructions will be very windows centric, infact, they will be Windows 7 64-bit centric, since i encountered quite a lot of problems on the way to PlayBook-bliss.

Setup / Installation

Installing the Simulator

If you are running a 32-bit Windows System go ahead and run the installers, they should work flawlessly and i would guess the same is the case for the Mac installs. If you run Windows on a 64-bit sytem though, you will be greeted by a not-so-friendly screen right at the start of your journey:

The Problem (i’m not quite sure actually) is either that the installer is not 64-bit compatible or since i noticed it uses Java it might just not support the 64-bit Java version. Either way, i haz a way around this little problem.

As any good windows user should, i would hope that you have 7-zip installed, simply because it is the best archiving / compression tool on windows AND it’s open source. So as it turns out, with 7-zip you can extract the content from the installer.

Now – what we want to extract from the installer is a ISO Image which we will need to setup the Simulator. The file in question is “InstallerData\Disk1\InstData\Resource1.zip” . It’s another zip which you have to extract, that contains two folders that in turn contains the image, which is called “BlackBerryPlayBookSimulator.iso” .

Great! Now that you have the image, we can finally setup the simulator, which actually is a virtual machine. For that, you can follow the installation instructions posted at the developer site by RIM themselfs – make sure to come back ok ? :P

Installing the SDK

So by now you should have a running instance of the PlayBook OS which is most likely looking something like this:

^{Pretty eh?}

Now, the 64-bit problem also applies to the SDK Installer of course. Now this one was a little bit trickier since the installer actually generates the SDK for you. But with a little trickery that problem won’t stop us here either.

I have generated the SDK with AIR 2.5 integrated and uploaded it for your convenience to mediafire so you can download it from there. – at the time of this writing, the version of the blackberry tablet sdk is 0.9.0

This SDK is (mostly) like any other Flex SDK. So if you use Flash Builder, you can go to the Preferences > Flash Builder > Installed Flex SDKs and add the SDK to the existing ones.

That’s it! You have set up your environment for developing for the Blackberry PlayBook. In the next article, we will look into some more specifics of this SDK.

I leave you at this point with the link to the Blackberry Adobe AIR Development Guides and API Reference where you will find more information on setting up and creating your first project.

Hope this was of any help and make sure to come back for the next article on the Blackberry PlayBook. I’m sure we will see a lot more of it in the near future :)

So i’ve returned from this years Flash on the Beach Conference in Brighton and what an outstanding experience it was!

Not only was it great to meet up and network with all the great people in the community but for me
the obvious highlight was to participate in this years elevator pitches.

Day 1

The Conference was kicked off by Adobe delivering the Keynote with a bang by introducing a new feature that will make its way to the next Flash Player iteration. This feature will dramatically improve video playback in the flash player and thereby keep flash relevant in delivering high quality videos. You can read up on it over at Thibault Imberts Blog.

Of course Adobe will be keeping quiet until MAX to reveil more breathtaking features but the future for flash sure looks promising.

I next headed to Grant Skinners Session, which he titled: “ADHD FTW, LOL!!!” . A great session that reminds us to set some time aside to play and experiment which can lead to fantastic (and of course fun) results like Androideroids or the Android Wireless Slot Car Gas Pedal.

Next up was Andre Michelles great audio session “Pulsatile Crackle” in which he presented us great ways to use physics for sound sequencing. As expected his session was incredibly inspiring to me as an audiophile myself. He also announced the Tonfall Framework which i personally look forward to using.

The last session i had a chance to catch for that day – because i had to continue preparation for my elevator pitch – was of course Mario Klingemanns last talk before he takes a break from the speaker circuit, which he entitled: “So Long, and Thanks for All the Flash”. Marios talk was a great mix of code snippets that will allow you to easily spice bitmaps and about his current obsession of creating a jigsaw puzzle solver written in flash. Absolutely stunning and i can’t wait to see the end product :).

This wraps up my first day since afterwards i had to invest my time to actually finish my preparations for my elevator pitch and John and his awesome crew took us in, to go through a first rehearsal of our pitches.

Day 2

For most people the day started at 9am with the elevator pitches. But for me the day started nearly 2 hours earlier as we (the elevator pitchers) had to do a final rehearsal before actually doing it live.

First of, we all had two rehearsal of which both went horribly wrong for me. During the first try-out my pitch was too long so i had to cut it by half and on the morning before we actually had to do it live, my pitch went horribly wrong because of technical difficulties. But then when it counted, everything worked as expected and i had an absolutely amazing time. Here is the video of my pitch in which i presented the Flash Open Source Desktop Runtime for the first time to the public:

I highly recommend this experience to anyone who wants to carry some project of his out to the public. Doing the elevator pitch was incredibly scary but also highly rewarding. It is quite an emotional joyride between sheer panic and incredibly joy once you get your applause at the end of your talk. I also have to admit that doing a 3 minutes presentation had to be the hardest thing i have ever done. The incredibly tight timeframe leaves no room for any errors or second guesses. A terrifying yet incredibly adrenaline pumping experience. And do not underestimate the psychological pressure that talking infront of 800+ people gives you :). Eventhough funny enough, rehearsing infront of John was way harder than actually presenting infront of the entire crowd :)

At this point i would like to extend my thanks to John Davey for giving us this great opportunity and the stage to express ourselfs and of course for organizing this fantasic event. My thanks go also to the entire crew who oversaw it all: Andy, Chris and Tal, and the crew Rich and Neil. They made sure that us pitchers got thrown to the wolves and got dragged back out without any technical hiccups or passing out of sheer panic :)

I also would like to extend my thanks to underbelly for sketching us elevator pitchers. I got a really good laugh at the fact that they managed to catch my anti-apple essence in that picture perfectly :)

The rest of the day kinda flew by on me after the elevator pitches and all the great feedback i have gotten from people. At this point THANK YOU ALL for the kind words, i appreciate it highly.

Of course i couldn’t miss out on Joa Eberts session which he entitled: “1 1 7 11 21″ – A great session about his work on Apparat, JITB and all the other nice little tools that Joa has been working on. I probably should mention that the highlight definitely was Joa showing his OpenGL implementation within JITB which inspired me to consider bringing OpenGL functionality to the Flash Open Source Desktop Runtime in the foreseable future.

I ended the second day by attending the “Inspired Session” held by Brendan Dawes, entitled: “Makers of Things”. Which essentially can be summarized in this picture:

Day 3

The third day sadly went by too quickly. First of all we kinda slept in because we partied a wee bit too much and we sat down with the guys of the Milan User Group to discuss some projects. But there were two session i definitely did not want to miss out on. The first one i wanted to attend was Ralph Hauwerts awesome session which he entitled: “UnitZeroOne :: The Discontinuity” . Ralph astonished the audience once more with awesome visuals and great approaches. I especially loved that he mentioned the awesomness that is the Amiga Demoscene. He once again showed us his oh so yummy Distance Field Demo and his recent work into auto-generating volumetric clouds which looks absolutely astonishing.

Last but not least i attended the ending session which was given by Jared Tarbell who is an incredibly inspirational person and has done great visual work in processing as well as actionscript. One of my all time favorite has to be Substrate. Jared definitely underlined the general vibe of the conference that you should absolutely follow your ideas and put them out there, because only good things can come from it (at worst, nobody can get hurt :P ).

Wrapping up

I was very fortunate to have had the joy and pleasure to get to know / hang out / discuss / have a drink with many talented people, of which i admire many like, Marc Thiele, Jens C Brynildsen, Chris Pelsor, Thibault Imbert, Ralph Hauwert, Andre Michelle, Mario Klingemann and Jared Tarbell only to name a few but great names within the grand melting pot that we call the flash community. I also got the chance to meet many new people, forge new friendships and i am looking forward to see you all again at one of the next conferences.

It was an absolute delight to have attended FOTB for the first time and i’m looking forward to attending it again next year. Brighton you have been a great host and thanks for all the Flash.

A big shout out also to the Italian Crew representing at FOTB, you guys were awesome! Here’s a picture of me proudly wearing the FlashPlatformGeeks Glasses after attending Peter Elsts Session about the Litl Webbook.

Last but definitely not least, i would like to extend my outmost gratitude to my employer Liip for letting me attend FOTB and infact paying for all the traveling costs and accommodations. How awesome is that?! They even went so far as paying extra just so i would travel eco friendly by using the train. Much respect for this effort!

With Twitters Basic Authentications deprecation starting today and the latest release of the Tweetr Library, it is time to give you a heads up on how to integrate OAuth without having to use the PIN Method.

First of all, make sure to download the AIR Example used in this Tutorial. The zip contains a Flash Builder 4 Project Folder as well as a Flex Project FXP File so you can import the code easily if wanted. If you don’t have Flash Builder 4 you can always just look at the code in the src folder within the zip. As you will notice, the example uses the awesome doomsdayconsole. The code for it is not included in the example but can be retrieved from its googlecode site. You will also need the AS3Crypto Library which also is not included in the example.

Without any further ado, here are the steps neccessary to get pinless OAuth working.

Let’s take a look at the important parts of tweetrAIR.as:

1
2
3
4
5
6
7
8
9
10
11
12
13

oauth = new OAuth();
oauth.consumerKey = "YOUR_CONSUMER_KEY";
oauth.consumerSecret = "YOUR_CONSUMER_SECRET";
oauth.callbackURL = "http://your.callback.url";
oauth.pinlessAuth = true; 
 
oauth.addEventListener(OAuthEvent.COMPLETE, handleOAuthEvent);
oauth.addEventListener(OAuthEvent.ERROR, handleOAuthEvent);
 
var rect:Rectangle = new Rectangle(50,50, 780, 500);
htmlLoader = HTMLLoader.createRootWindow(true, null, true, rect);
oauth.htmlLoader = htmlLoader;
oauth.getAuthorizationRequest();

As you see there’s not much to do configuration wise. First of all, we create a new OAuth instance and then assign our consumer key and consumer secret which we get from twitter (line 1-3).

The important parts here are the callbackURL and pinlessAuth at line 4 & 5. You need to set the pinlessAuth Boolean to true in order to enable (obviously) pinless authentication and you need to define a callback url for which your AIR app will be listening for. The callback url can be anything on the internet that does not redirect any further, for example “http://google.ch” or “http://yourdomain.com/static.html”. Twitter will append some GET parameters to this url for which your OAuth instance will be listening for.

Pinless Authentication for AIR Desktop Applications requires you to pass a HTMLLoader instance to your OAuth instance (see line 11 & 12). Once you have done that, you can call getAuthorizationRequest to start the entire process.

The OAuthEvent Handler Method will assign the oauth instance to twitter once an OAuthEvent.COMPLETE event is received, meaning that authentication was successful:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

private function handleOAuthEvent(event:OAuthEvent):void
{
    if (event.type == OAuthEvent.COMPLETE)
    {
        // removes the authentication window
        htmlLoader.stage.nativeWindow.close();
 
        tweetr.oAuth = oauth;
 
        // prints username, user id and the final tokens
        trace(oauth.toString());
    }
    else
    {
        trace("ERROR: "+event.text);
    }
}

And that’s it. From here on out you can call any tweetr method you want. Here’s a short video of the example code running:

_{WATCH IN 800 x 600}

With Twitters Basic Authentication deprecation starting today and the latest release of the Tweetr Library, it is time to give you a heads up on how to integrate OAuth without having to use the PIN Method.

First of all, make sure to download the AS3 Example used in this Tutorial. The zip contains a Flash Builder 4 Project Folder. If you don’t have Flash Builder 4 you can always just look at the code in the src folder within the zip. As you will notice, the example uses the awesome doomsdayconsole. The code for it is not included in the example but can be retrieved from its googlecode site. You will also need the AS3Crypto Library which also is not included in the example.

The Actionscript

The Pinless OAuth process in the library uses the ExternalInterface to communicate with the Webpage
that embeds your flash application. Let’s take a look at the important bits of tweetrAS3.as:

1
2
3
4
5
6
7
8
9
10

oauth = new OAuth();
oauth.consumerKey = "YOUR_CONSUMER_KEY";
oauth.consumerSecret = "YOUR_CONSUMER_SECRET";
oauth.callbackURL = "http://tweetr.swfjunkie.com/dev/verified.html";
oauth.pinlessAuth = true;
 
oauth.addEventListener(OAuthEvent.COMPLETE, handleOAuthEvent);
oauth.addEventListener(OAuthEvent.ERROR, handleOAuthEvent);
 
oauth.getAuthorizationRequest();

As you see there’s not much to do configuration wise. First of all, we create a new OAuth instance and then assign our consumer key and consumer secret which we get from twitter (line 1-3).

The important parts here are the callbackURL and pinlessAuth at line 4 & 5. You need to set the pinlessAuth Boolean to true in order to enable (obviously) pinless authentication and you need to define a callback url which will be opened once authentication has succeeded on twitters side. Last but not least we define some eventlisteners and call getAuthorizationRequest to start the entire process.

The HTML/Javascript

As i said earlier, the library uses the ExternalInterface to communicate with the browser back & forth, thereby we need to add a JS File to our HTML that embeds the Flash and some little snippet of JS Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<html>
<head>
    ... 
    <script language="JavaScript" type="text/javascript" src="js/tweetrOAuth.js"></script>
    ... 
</head>
 
<body>
 
    <div id="flashContentDiv">Your Flash might be in here..</div>
 
    <script type="text/javascript">
        OAuth.setFlashElement("myFlashID");
    </script>
 
</body>
</html>

As you see you have to include the tweetrOAuth.js file and (optimally at the end of your html) tell the OAuth Javasrcipt the ID of your flash element so that javascript can communicate with it by calling OAuth.setFlashElement.

When your Flash application calls getAuthorizationRequest from your oauth instance, it’s going to make an ExternalInterface call to the embedded javascript file which will open a popup window for you to be able to authorize the application. Once this is done, it will redirect to the callback url you have defined in your actionscript code. This Webpage should look something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<html>
<head>
    ...
    <script language="JavaScript" type="text/javascript" src="js/tweetrOAuth.js"></script>
    ...
</head>
 
<body>
    ...
    <script type="text/javascript">
        OAuth.verify();
    </script>
    ...
</body>
</html>

As you see, once again we integrate our tweetrOAuth.js file. This time we call OAuth.verify since we should have received the required tokens from twitter back to our callback url. These tokens will be extracted and send back to our Flash application via ExternalInterface and the popup-window should be closed automatically.

And that’s it. When the javascript passes the token, your oauth instance will do the rest and eventually trigger an OAuthEvent.COMPLETE event in which you can pass your fully authorized OAuth instance to your tweetr instance, like so:

private function handleOAuthEvent(event:OAuthEvent):void
{
    if (event.type == OAuthEvent.COMPLETE)
    {
        tweetr.oAuth = oauth;
        // prints username, user id and the final tokens
        trace(oauth.toString());
    }
    else
    {
        trace("ERROR: "+event.text);
    }
}

Here’s a short video of the example code running:

_{WATCH IN 800 x 600}

So here we are again, time for another beta release, this one comes in time for twitters start on deprecating basic authentication.

What’s new

• Pinless OAuth for AIR (Desktop) and pure AS3 (Web)
• Javascript/HTML Template for Pinless OAuth for Web apps
• Minor bug fixes

You can grab the latest files as usual from the tweetr downloads page.

Notable Changes

This release marks the first time that we have two different SWC files. The tweetrWEB.swc is meant for Flex / AS3 Applications, while the tweetrAIR.swc is solely meant for Desktop AIR Apps.

It is discouraged to use the source code from this release on since it requires conditional compiling in order to get it working correctly. Use the specific SWC instead. I will continue providing the source code though in zip format.

The Documentation is now valid for all versions of the Library. AIR only methods and properties will be marked as such.

How to use pinless OAuth

Glad you asked, i’ve prepared two tutorials on how to use pinless OAuth:

• Pinless OAuth in AS3
• Pinless OAuth in AIR

What’s next

Next release will definitely include the Mobile AIR version. Any further plans are quite open since i have plans on refactoring the library to make it more modular, so you only integrate the bare minimum of what you actually use. Which will benefit mobile versions as of course all other versions as well. If you have any urgent requests of features you would like to see, please let me know via the google groups site.

That’s it for now, hope you enjoy the pinless freedom you are getting and as always, if you have any questions/suggestions you can post them on the google groups site if they are tweetr related. In any other case, leave a comment or contact me via mail or twitter.

I just wanted to share with you the current progress in the Tweetr Library. Since a video says more than a thousand words, here’s a quick example of the pin-less OAuth authorization process that the library allows now.

The technique used is quite simple really. Tweetrs OAuth uses a ExternalInterface Bridge to communicate with Twitter and the redirect after successful authorization.

If you feel adventurous, feel free to try the above example yourself.

Since AIR, Web and Mobile versions all require a different approach for pinless authorization, the next release of the library – for the first time – will also come in 3 different flavors, regardless of flavor though, the API will be the same to ease development processes.

For a quick look at how OAuth will work for mobile, check out Mark Dohertys AIR 2.5 StageWebView Demo where he shows off pinless OAuth on an Android Mobile Device.

I would like to extend my thanks to Mark at this point, since thanks to a short-notice debug session over Adobe Connect, i think we both learned pretty quickly that there wasn’t much to change in the library itself to get Pinless OAuth working :)

I also would like to thank Joe Rheaume (aka @Chronotron) for providing me with his Pinless OAuth Solution. I ended up implementing my own solution because i had already forgotten that i had his approach in my email :) As it seems i ended up doing more or less the same thing as he did without realizing though :). So once again, thanks for that.

There will most likely be another week or two before this new version wil be released as i have a backlog of things that still need to get done before i can release this version. Be sure to keep an eye on SVN though if you want to try out the latest code bits.

Overview Part #2

In this two-part blog post i will cover the technical, as well as overall aspects of implementing accessibility into the EventManager Project. And not just any form of accessibility – the Game has earned the AA+ Certification from Access For All (their highest certification grade conform to WCAG 2.0).

Go here for the first blog post on accessibility. This second part will cover all the technically nitty-gritty, blood and tears that went into implementing accessibility for this project. :)

Some Resources First

Throughout my research and while developing the accessiblity implementation for EventManager i’ve collected useful resources on the web which i’m glad i can share with you via my delicious. There are notes for all the links available that will tell you what type of information you will find behind the click.

Accessibility Introduction

If you haven’t worked with accessiblity in Flash or Flex yet, here’s a short introduction on how it all works.

Flash has it’s own package responsible for all the accessibility features. This package is situated under flash.accessibility.*

Within this package (as of this writing) you will find three classes:

• Accessibility
• AccessibilityProperties
• AccessibilityImplementation

The Accessibility class is a static class that allows you to do three important things. From that class you can check if the user is actually using a screenreader and if it is available or not (Accessibility.active). It also allows you to make sure that all accessibility properties are updated if you change any of their values (Accessibility.updateProperties()). The third and in my opinion most important bit of this class is the capability to manually submit an Event to the MSAA API (Accessibility.sendEvent()).

The AccessibilityProperties class is the place where you define the properties, such as name, description and shortcut that are being presented to accessibility aids. You can also set some properties that control the behaviour of your object towards screenreaders. AcessibilityProperties can be attached to any type of DisplayObject.

The AccessibilityImplementation class, is a bit of a special one. It is the base class in Flash that allows for the implementation of accessibility. This class you will never really use directly, since Adobe advices us not to instantiate it but instead extends AccImpl (which again extends from AccessibilityImplementation) in order to create our own implementation for any custom component we might create. The AccImpl class exists in two versions, one for flash and one for flex.

More Than a Million Words

Instead of boring you any further with details and long paragraphs of information, i figured it’s easier to understand how this all works by actually showing you. Enjoy the videos, if the quality is a bit low and you would like them to be sharper, make sure to head over to the vimeo site itself to download the original videos directly from there.

A Basic Example

_{WATCH IN 800 x 600 | DOWNLOAD EXAMPLE SOURCE CODE}

A Basic AccessibilityImplementation Example

_{WATCH IN 800 x 600 | DOWNLOAD EXAMPLE SOURCE CODE}

The Final EventManager Accessibility Approach

_{WATCH IN 800 x 600 | DOWNLOAD EXAMPLE SOURCE CODE}

Preamble

The greater part of last year i was heads-down-busy developing the EventManager Game which i had the pleasure to build at Liip for Postfinance. EventManager is an educational but fun game, that approaches topics such as budgeting, financing and investing in a modern way (read: not boring you to death).

Today i want to talk to you about the new iteration of the game that we just released a couple of weeks ago. What is new you ask? How about: Accessibility! And not just any form of accessibility – the Game has earned the AA+ Certification from Access For All (their highest certification grade conform to WCAG 2.0).

Overview Part #1

In this two-part blog post i will cover the technical, as well as overall aspects of this endeavour. This first part will cover a brief history of accessibility within the Flash Platform and its current state and hopefully useful insight if you are considering to add accessibility to one of your projects.

Accessibility History in Flash

Thanks to Adobe (and of course Macromedia back then), the Flash Platform has been sporting accessibility features since Macromedia released Flash MX back in 2002. For those that remember, this used to be Flash Player in version 6 and just introduced the Vector Drawing API (ahh, nostalgia.. but i digress).

Over the years obviously the feature set has vastly improved and Adobe (rightly so) can be proud of the level of accessibility that the Platform has today, since it allows you to:

• Create your own tab order
• Set alternative text (naming & description text)
• Set shortcuts
• Set element focus (also visually if needed)
• Communicate statuses to screenreaders.

As you see, there is really not much to wish for left here. In fact, if you use the Flex Framework, all these functionalities and features are just a step away from you. But that’s not all, Adobe has made it quite simple to build your own components within the flex framework, that can with little work, implement the accessibility layer. If that wasn’t enough you even have the capability to manually trigger an event to tell attached screenreaders that something has changed within your application.

For us developers, this means that we have the tools and capabilities to fully fullfill the guidelines proposed by WCAG 2.0.

Dark Side of the Accessible Moon

One of the “limitations” when it comes to the Flash Platform and accessibility, is that it’s only available for the Windows Platform.

There have been many voices that critisized Adobe for “only” implementing the Microsoft Active Accessibility (MSAA) API, yet to this day it seems that it is the only documented and standardized API out there. Also it is to be said, that the most popular and wide used screenreader applications have their home only on the Windows Platform.

Misconceptions & Half Truths

Question: So, since the Flash Platform supports accessibility so well, how come there are only a few accessible flash sites out there?

This question is usually met with one of the following answers:

ANSWER: Costs for implementation too high

There is no denying that implementing accessibility into a flash application is a high cost investment, if you do not already have a developer with prior such knowledge.

This has multiple reasons. Depending on your application it will require an entire different approach than just the straight forward making «Your-Standard-RIA App» or «Form-based GUI App» accessible. Which obviously, unless you have done it before will require tinkering, information gathering, experimenting and lots of testing. Hence, it will take time and thereby cost money.

ANSWER: Too difficult & lack of documentation

I have good and bad news. The good news is if you are considering making your RIA accessible, rejoice! Most of the information / documentation on accessibility for the Flash Platform is actually directly aimed at the Flex Framework and at RIA development.

And here is the bad news: if you want to make something completely custom – like a game – accessbile, make sure you have enough time at your hands, you will need it :). But since you are reading this, hopefully i’ll be able to provide you with enough information to ease your pain :).

The main problem lies not in the fact that implementing is difficult or complicated, it’s the fact that real in-depth documentation is either missing, hard to come by and that examples usually only cover little ground. So the difficulty of implementing accessbility really only comes from the fact that you will have to invest lots of time into testing and debugging.

ANSWER: No time / No money within the project

This really is a convergence of the previous two points. Lack of knowledge and the possible cost of implementation, compared to the percentage of users who actually will benefit from that step, leads often – and here we have to be honest to ourselves – to the quick dismissal of accessibility within projects.

ANSWER: What? Flash is accessible?

Yes genius, have you missed the memo? In fact a few years back when i took Macromedia’s Certified Flash Developer exams there was already a huge part dedicated to accessibility within the exam. Go read up, right now!

Adobe followed in Macromedia’s footsteps and continued to improve accessibility, updating the accessibility features once more in their latest Flex 4.0 Framework and implementing their entire accessibility layer into the freshly released AIR 2.0.

The Challenge

Coming back to our topic at hand, for EventManager i was confronted with a game that had many requirements.

The game’s flow for example, does not allow a regular tab order, it just wouldn’t work. There were also many interactions that would take place without any prior user action and those had to inform the player obviously about what is happening.

Depending on where you were in the game or what you wanted to do, the keyboard had to apply a different layout/scheme that is tailored to the task at hand. For example, when you are on the eventgrounds, you need to be able to place/manipulate constructions, which obviously has an entire different control scheme than for example having to bid on an artist in the auction part of the game.

To make the matter worse, the game has a strong mix of pure flash elements and flex components. Oh, and everything had to be multilingual of course :)

Finding a Solution

Keyboard accessibility was pretty clear from the start. We needed a class that allows us to set a specified keyboard layout/scheme to be active when we needed it.

For user-interactions, it was generally agreed that a context-menu would make most sense and thereby should be used for building constructions and general interaction with the eventgrounds in the game.

When it came to implementing screenreader accessibility the concept had to change a couple times, obviously here the lack of knowledge was a problem and forced me to try out various things until finally finding a working and valiable solution.

At this point i would like to extend my most grateful thanks to Adobe’s Accessibility Evangelist (congrats on the new position!) Matt May , he was of incredible help and was able to give me just the right hints, that helped me resolve some key issues that were plaguing me during my quest for accessibility.

The Final Solution

The final solution can be broken down into three essential parts:

• A global Keyboard Controller that allows applying different control schemes at will.
• A single class from which we can communicate with a screenreader to manipulate its focus, send text to be read via speech synthesizer or displayed on a braille device.
• Last but not least a custom context menu component, that allows us to display a menu of possible actions the user can undertake depending on the situation.

I’ll be covering all the technical details and attempted approaches in the second blog post: Flash & the Quest for Accessibility – Part #2.

The Information Hunt

I’ve invested countless hours in information gathering and hunting down resources concering accessibility and possible ways of implementation so that most screenreaders are supported.

Sadly, as it turns out, supporting all available Windows screenreaders seems to be impossible (see these tests). Thereby i concentrated on JAWS and ZoomText since these two applications seem to be the most widely used, when it comes to assistive technologies.

The resources gathered throughout the project that were useful are publicly available via my delicious account. They have notes as to what information was useful and/or if parts of the information was incorrect or not valid anymore.

Conclusion

All in all, getting the chance to implement accessibility in such a big flex application was an incredibly rewarding experience in multiple aspects.

Getting the chance to actually implement accessibility was a great, allbeit, at times nerve-wracking experience that gave me new and invaluable knowledge.

The most rewarding aspect of the entire project though, to me personally, was to receive the excited feedback from our targeted end-users audience. A big thanks also here to Access4All, the entire team at LIIP and everyone else involved in this big effort and of course to Postfinance for giving us this great opportunity.

Feel free to leave comments or get in touch with me if you have any further questions about flash, flex or accessibility.

I just wasted 4 hours on this problem and figured i might aswell document it, so that if someone else is going to run into the same issue, they won’t have to suffer the same 4 hours that i just did.

If you use AIR Applications under Windows and all of sudden those apps can’t connect to the internet anymore, make sure that your Internet Explorer is not “Working Offline”. You can check in the Menu of Internet Explorer under Tools -> Work Offline. If it has a checkmark, remove it and your apps should be working fine again.

I’m really suprised that the Windows Version of AIR apparently retrieves it’s Network Capabitilies via Internet Explorer and that this behaviour is in no way documented anywhere. Hopefully Adobe will changes this or atleast make sure that people now about this.