01.04.06
sIFR: Improving Link Accessibility (and Colors, Too)
sIFR and Anchors Can Be Friends! Marc over at the Crossroads blog (basically consisting of only the one post) provides an excellent article on issues affecting link accessibility and how to modify the standard sIFR Javascript and ActionScript to fix it. Great work.
Note, of course, that this pertains to accessibility for links in a sIFR context. One of the great boons of sIFR (aside from eliminating hours of boring Photoshopping) is that ascii text treated with it is 100% accessible. Er, except the link thing, to some extent.
Note: Well, that’s what I get for going off half-cocked. Turns out the anchor hack fails miserably in Firefox 1.5 — the sIFR-ized text has a tendency to disappear entirely (sometimes) in that browser. I’ll investigate further to see if I can jimmy the whosis. But meanwhile, caveat emptor and (always) test thoroughly before going live, kids.
Marc’s contribution makes a fine companion to Marko Dugonjic’s excellent two-color sIFR hack, so’s you can have more than one color in a block of sIFR-ized text. For that you’ll need the first article and the second part, which includes some more standards-compliant optimizations.
Note: A couple drawbacks to the 2-color hack are worth mentioning. Foremost, the second color must be encoded into the Flash file itself (via one of the ActionScript files). Changing your site palette will thus mean re-encoding the sIFR. (I’ve not tried hacking the hack to see if it can be repurposed to, say, a CSS class, tho I’m not optimistic since it relies on dynamically swapping in an olde school FONT COLOR=”foo” tag.) Also, integrating the hack is kinda cumbersome in a couple ways. One, it was created for an earlier version of sIFR, and so the “find this and replace it with that” stuff in many cases no longer explicitly applies — which means putting on your reverse engineering hat. Two, part two of the article is revisions to the previous revisions — which means you gotta reverse engineer the changes twice.
Both of these hacks are officially sanctioned included in the sIFR documentation wikki, but is not officially sanctioned by the creators of sIFR. (See comments, below.) I’m also pleased to report that the wiki appears to have been fixed and will now talk to you even outside of bankers’ hours. Hooray! (Or boo…that means I don’t have any excuses when working late or on the weekend.)
(If you don’t know about sIFR, then get thee to the official sIFR site right quick.)
Mark Wubben said,
January 20, 2006 at 8:20 am
The wiki is back in perfect shape now
Also, as it’s a wiki, a link there doesn’t mean it’s officially sanctioned. But yeah, cool hacks.
I’m wondering if this should be part of sIFR 3. The dilemma here being that I’m not sure if sIFR needs to fix the problems with Flash. It might also just not be possible with the way sIFR 3 is going to render the text, but that’s a later worry. What do you think?
Spencer said,
January 20, 2006 at 9:16 pm
Well howdy, Mark! It’s a pleasure to have you grace my lowly blog. Let me take the opportunity to thank you personally for sIFR. I was a fairly early adopter (ca. RC2, I think) and I love it. I’ve managed to use it for several projects at POP — if you’re interested: portions of the Steppenwolf Theatre Co. site (our first test case, saving me from creating over 300 headline GIFs for one section alone!), The Planetary Society, Oregon Shakespeare Festival, The Shakespeare Theatre in DC, and some other stuff still in dev.
Your point about the aforementioned hacks not really being officially sanctioned is well made and, silly me, obvious. I’ll update the post accordingly. I’m also thrilled the wiki is cured of its dispepsia.
As for inclusion in sIFR 3… My personal opinion is the 2-color hack — or some version of it — would be an ideal candidate. The benefits seem pretty obvious, and would make the designers I work with happier. As I mentioned in the post, in a perfect world the need to “hard encode” the second color into the Flash would be addressed somehow so that color schemes would be truly portable and XHTML compliant. I’ve not yet attempted my own workaround, but my suspicion is that may be a stickier wicket than one would prefer. Even still, I wouldn’t consider that a deal-breaker.
And it seems clear that something should be done to help address link accessibility issues, which I know have been belabored by many. Personally, I’m much less concerned about fascilitating right-click menus, but I certainly see the argument and the value there. Given the issues I ran into with Marc’s particular hack I’m unconvinced his is the real solution, at least in its current incarnation. But solving the link accessibility issue would remove one of the last few arguments against adoption of sIFR. Regardless, full accessibility is always good.
My only other headaches with sIFR, such as they’ve been, are the familiar ones: sizing can be a little kooky sometimes, especially with wrapping text (thankfully I’ve not yet had a client that’s rabid for pixel-perfect sizing No Matter What), and the problems sIFR can have in floated DIVs or following floated DIVs.
Hope this is useful somehow.
Mark Wubben said,
January 21, 2006 at 8:41 am
Man, lovely designs. Flash 7 (we’re dropping Flash 6) gives us Flash CSS. Send the CSS classes in the HTML to the Flash and we’ll have multi-color multi-style etc. I’ve also some tricks to improve the sizing, but it’s not until I’ve implemented them that I know if it’ll work. As for the floats, yeah, that’s really annoying. But it’s a browser problem, so we can’t really do anything about it.