sIFR and accessibility
Home / Site Building & Testing / sIFR and accessibility
is sIFR a good thing for accessibility?
yes
66%
[ 6 ]
no
33%
[ 3 ]
Total Votes : 9
I'm wondering what the general feel in the accessibility aware community is regarding sIFR as a technique for using non standard fonts in web pages.
http://www.mikeindustries.com/blog/archive/2004/10/sifr-2.0-release-candidate
It seems like a wonderful solution for producing accessible text that previously would have to have been implemented using images and alt text.
It uses flash and javascript but if either of these components are not available the text is just displayed as straight html. sIFR text is resisable, selectable and available to screen readers as its embedded in the html file just like any other text.
The only downside I can think of is the slight delay in displaying sIFR text when a page is loaded, rendering it useful only for important headings or small bodies of text. It also doesn't work very well for links.
Any opinions out there guys n gals?
Share: 
The only 'problem' I can come up with is that the proportion of users with no Javascript (or rather those who have it disabled due to security concerns) is higher than the proportion with a non CSS-capable browser, at least according to the stats I've seen.
This would mean that sIFR is seen by less people than FIR (or whatever image replacement technique you happen to use). How much of a problem that is for you is down to individual opinion.
Personally, I think:
Pros - scalability (resizeable) is the main one that makes sIFR a GOOD thing
Cons - thumping great big Javascript file needed on every page (although once it's cached it's not such an issue), and availability as noted above
I haven't used it myself yet, but I'm considering it for my next big project.
_________________
The Watchmaker Project - my personal blog
29digital Design Studio - freelance web design/development
Share:
I think it is fully accessible. It's also nice that you can select the text that is replaced, which you can't do with an image. (Well, you can perhaps select the whole image, but not just one word within the heading.)
The only downside I can see is that it's a bit slow, and that there are many people who won't see the nice font. But that's not an accessibility issue...
_________________
Simon Pieters
Share:
I ended up using this instead: http://www.stewartspeak.com/...
I couldn't get sIFR to scale properly and when the tweaking became tiresome I switched to DTR and found that the results were more easily adjusted to fill the necessary space.
I think I will give sIFR another try though. See if I can get it to fill the area of the original text. It could be the fonts I'm using...I do like how you can select and copy the text.
Now you all got me thinking again. Could mean trouble.
Share:
Dave Shea covered this very topic a while back,
http://www.mezzoblue.com/...
and the comments proved illuminating too...
_________________
Stuff I do
******************************
Design: http://www.stuffandnonsense.co.uk
My book: http://www.transcendingcss.com/
Share:
I went and spent some more time with it and the tweaking takes some doing (a lot of experimentation) but it is a nice way to get things done.
The DTR has a setting where you can set the size of the text which is MUCH easier to set up but it makes unselectable graphics.
Share:
Thanks very much for your thoughts. I'm thinking about using sFIR (sparingly) in my next big project which will be a university website. Its good to hear your opinions on the matter.
From my quick scan of the relative merits of DTR vs sFIR it seems that sFIR is the better option from an accessibility standpoint (which is the primary concern) as the results are dynamically scalable and selectable. Shame about the large javascript but I think its acceptably small now.
Thanks for the links....I'll go and have a play. Maybe I'll encounter similar problems as Triumph.
Share:
i've held back on answering here, because i wanted to double-check on JAWS here at work first, but...a problem with sIFR that is quite glaring: when javascript is enabled (as even screenreader users may not always turn it off), the replaced elements are inaccessible. just tested http://www.shauninman.com/ and, instead of the proper heading text, JAWS simply hits those replaced flash headers and reads out "http://www.shauninman.com/swf/type.swf"
it may be worth noting my version of JAWS is 4.02 - newer versions may fare better?
sure, one could now argue that screenreader users should have js turned off...but in the meantime it *is* a real issue.
_________________
Patrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
ah....good point well made redux, I havn't got an up to date version of Jaws to test it on but you're right, this does seem like a real issue.
Nothing's ever simple is it!?
Share:
| redux wrote: |
| sure, one could now argue that screenreader users should have js turned off |
go on ..?
Share:
Page 1 of 1
All times are GMT
You cannot post new topics in this forumYou cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum