This interview with Niqui Merret and Aral Balkan makes good reading for those trying to work out the general situation regarding Flash and accessibility.
I’ll be keeping an eye on Niqui’s site in future too, as it looks like being a good resource for anyone looking at accessibility in general.
Quick feature list here, or Adobe’s take on things here.
I’m hoping the release smoothes the transition from ActionScript 2.0 to ActionScript 3.0 for designers, as I’ve a few workflow fears for what the new language may mean for production houses (especially if also using Flex 2.01). I don’t think Adobe’s claim that AS3 will enable production houses to “save time” will immediately ring true, going by initial research into Flex and some gotchas when combining AS1/2 content with AS3 content.
Adobe have released an alpha of Apollo (available here).
Their demo is worth watching if you’ve a spare 5 minutes; looks like it could target the range of web APIs out there to create some nice custom desktop applications. Mike Downey talks about the product here. Lynda.com have released nearly an hour’s worth of free tutorials here.
What’s interesting about the first video link above is that there’s a transcript provided underneath the video; haven’t seen Adobe do that for video content before. Perhaps the start of a trend towards more accessible Flash video?
Scary stuff here on photographer’s rights in the UK.
I’ve signed the petition just in case.
Over at OSFlash they’ve released a tool which aids in the detection of a screen reader (before throwing them tons of AJAX or incompatible Flash). After a quick squint at the code it seems they’ve accounted for Flash not returning correct values for screen reader presence until a few seconds have elapsed, so it looks like good stuff.
Check it out here.
It sounds like Flash may not work 100% as expected in Windows Vista unless a user’s using the latest version of the plug-in (9,0,28):
Senior Product Manager for Adobe Flash Player
It seemingly relates to a subset of specific functions which conflict with Vista’s security model:
- Shared objects (Flash cookies)
- Local Connection (Flash movies talking to each other)
- File reference (saving and opening files within Flash)
- Express Install (auto-updating a user’s version of the plug-in)
I haven’t a copy of Vista to check any of this unfortunately, although I’ve no reason to doubt it. It sounds like something that might only affect users upgrading from XP and retaining older versions of the plug-in, or developers, developers, developers…
I’ve been looking into whether better-quality Flash video is produced when sticking to dimensions that are divisible by 16. This seemingly has been the rule with older codecs, but I’ve had to investigate the issue for Flash 8 .flv video. Adobe doesn’t seem to think so, stating:
Although these ratios are standard, and should be used to avoid distorting the video, the size of the encoded video is not set in stone. The original web video sizes used heights and widths that were evenly divisible by 16. This was mandatory for many early codecs. Although this is not necessary for modern codecs, you should stick to even heights and widths.
This doesn’t quite tally with the advice on On2’s site (producers of the Flash 8 codec):
If you reduce your video size (image dimensions), your picture will be sharper. Another small factor you may consider is that optimal frame sizes are divisible by 8. That means that if your image dimensions (width and height) are divisible by 8, you will be wasting as few bits as possible on encoding data for portions of the video which do not actually appear. This is a complex issue relating to the way image compression uses 16×16 and 8×8 blocks to form an image.
A forum post by Zappu here enforces the 16/8 rule, as does this entry on MultimediaWiki. Conversations with Dave Curtis (hello Dave!) have been very helpful and also seem pretty conclusive on the “16 issue”.
It’s probably best to stick to dimensions divisible by 16, but not set in stone. Complex clips with lots of motion and/or panning would probably benefit from the 16-rule to a greater extent. I hope to produce some encoded tests myself, but if anyone has any in the meantime the links would be much appreciated.
Why is there so little clear information on this on the web?!?
I haven’t experienced this issue yet, but I’m glad it’s been highlighted and fixed before I do.
While the Opera browser on the Nintendo Wii’s still in Beta, this looks like providing a few additional widgets to make surfing a better experience.
Being able to capture the full range of wiimote movement and button presses in Flash would lead to some amazing content being developed, and it wouldn’t matter that the PS3 browser features Flash 7 too if you open up the API. Then the developer community wouldn’t have to resort to workarounds like Mario’s great efforts.
A couple of really helpful resources I’ve found on the net recently on osflash.org and documentation for xfactorstudio’s XPath API.