I’ve worked with Adobe Flash for years and never had to develop with screen readers in mind until recently. Making a swf that would play nice with screen readers was more involved than I’d have imagined. The challenges included operating systems that disregarded de facto standards, browsers fussy about the embed code used, and what seemed like glaring oversights in Adobe’s own product. Let me share with you some of my experience in the hope it will make it a little easier for the next guy.
I also want to thank aut0poietic for his help in this little effort. He blazed the trail before me and was kind enough to loan his map.
For all that Amazon.com does, and the sheer size of their audience, you’d think they would be very careful about the design decisions that go into their website. I’ve used Amazon rarely over the past three years, but lately more often, and I found that parts of their site design — especially their login — make no sense to me.
Even after years of application development experience there are still those times where you realize you’ve done something monumenally noobish and the only recourse your left is to face-palm, admit the mistake, and refactor. I’ll share this story in the hopes that it will help someone avoid a similar snafu.
One of the things I’ve always thought was missing from Flash was access to a browser’s cookies. I can understand the argument that cookie access is unnecessary for sites that are primarily flash based. After all Flash’s Local Shared Objects make persisting data across sessions or page views fairly painless. However for hybrid sites where the server passes information to the browser via cookies a developer must jump through a few hoops to get any important data sent from the server via a cookie into Flash.
There are times when I need to listen to an object’s event for just a single dispatch and then be done with the listener. When I’m faced with this situation I tend to want to define the event handler as a closure or an anonymous function as opposed to adding yet another class method to handle the dispatch. A complication with this approach comes from the fact that I also want to explicitly remove my event listeners for the sake of good garbage collection. So, to have my cake and eat it to I created a proxy class that takes care of listening to the event and cleaning up after itself once the event has been handled.
An inline box is a dom element that is laid out inline, like span tag, but has a defined height and width like a positioned div or image. Actually, the img tag is a fair example of how an inline box should be have. So if you can imaging a block level container tag that has all the layout behavior of an image then you have a good idea of how an inline box behaves.
I worked on a photo album project where I needed something like an inline box. I wanted a square container that could take a border, that could hold a smaller image centered within it, and that could be aligned left, right or center in the normal inline flow of the page. Something that I could layout in a grid that would grow or shrink as the width of the browser was changed. The problem I faced at the time was only IE 7 supported the css display:inline-box; rule. Shocking… isn’t it.
At my current job, we have a website with many Asian members who, of course, post content in Asian double-byte characters. We’ve jumped through a few hurtles to make sure that our site correctly stores and displays these characters: making sure data is UTF-8 encoded, making sure that we run our text through a combination of escape(), unescape(), encodeURIComponent() and decodeURIComponent() depending on whether we’re saving or retrieving data. For the most part, our site has no problem. Then we had to go and add Flash into the mix, and things got a little weird.