Facts and Opinion About Fahrner Image Replacement

by
Published in Accessibility, Browsers, CSS

Development of the Fahrner Image Replacement technique and its
analogues is moving faster than the destruction of the Berlin Wall.
This article provides some much-needed empirical data on how FIR actually works in screen readers.

Article Continues Below
Article Continues Below

Named after Todd Fahrner, apparently invented by C.Z. Robertson, and popularized
by Douglas Bowman (see his site for full coding
details) and Jeffrey Zeldman’s Designing With Web Standards, FIR is a standards-compliant technique that uses
stylesheets and ordinary HTML to provide a visible image, usually
consisting of text. The designer specifies, through CSS, that the
image will display in most cases; if it should not display for some
reason, the underlying structural HTML markup is supposed to take its
place.

Using FIR, it becomes possible to nicely typeset headlines and other
design elements while using markup no more complicated than inside
<h1>. The HTML plain text is concealed through a
stylesheet declaration of display: none
(canonically, at least – you could also use
visibility: hidden). The picture of text displays
as a CSS background image.

The advantages here are a nice graphical appearance most of the time
and markup somewhat more elegant than <h1>

, which is pretty much your only
alternative if, say, you want to use a picture of text as a headline.
Because it does not nest an image inside a heading, FIR is at least
superficially better for accessibility.

Screen readers#section2

As explained in a previous story for A
List Apart, screen readers are applications that read web pages, and
usually anything else on your
computer, out loud. They make a computer accessible to a person who
is blind or severely visually impaired, and have been used
occasionally by people with learning disabilities like dyslexia. They
are a form of adaptive technology – software or
hardware used to make a computer accessible to a disabled person.

The leading screen readers are:

  1. IBM Home Page Reader (which limits
    itself chiefly to web pages, web-based mail, and multimedia
    players)
  2. Jaws (Freedom Scientific)
  3. Window-Eyes (GW Micro)
  4. OutSpoken
    (ALVA Access Group; Windows and Macintosh, though the Mac
    version has been discontinued)
  5. Emacspeak (freeware for Linux; T.V. Raman)
  6. SpeakThis (Fonix)

Stylesheet interpretation#section3

In Fahrner Image Replacement, two CSS techniques are in typical use,
though only one relates to visual styling. That’s true even
though both derive from visual, not auditory, CSS media types.

display: none is our bugbear here. The W3C
specification states:

This value causes an element to generate no boxes in the formatting
structure (i.e., the element has no effect on layout). Descendant
elements do not generate any boxes either; this behavior cannot be
overridden by setting the ‘display’ property on the
descendants.

Please note that a display of ‘none’ does not create an
invisible box; it creates no box at all.

Hence, display: none really means
manifestation: none or
elimination: total. An item assigned to
display: none expunges itself.

There’s another option that can be used:
visibility: hidden, in which, the spec tells us,
“[t]he generated box is invisible (fully transparent), but
still affects layout.”

The visual distinction, then, is between nonexistence and an empty
bounding box. How should screen readers handle these?

User testing with screen readers#section4

I do not know the answer to that question, but, thanks to some user
testing, I can now tell you how screen readers do handle
them.

I asked various contacts and a few mailing lists (WAI
Interest Group, UVIP-Web-Test) to try
reading FIR-encoded text with every screen reader they could put
their hands on.

The test case was the rather simple intro page for Ten Years Ago in Spy, my
pæan to the now-defunct satirical magazine that Matt
Mullenweg had recently re-coded using CSS
layout and Fahrner Image Replacement. Two images on that page were
marked up with FIR. Previously, I had used ordinary img
elements.

Results#section5

I set up two test pages:

  1. Using
    display: none
  2. Using
    visibility: hidden

I was able to locate users of three versions of Jaws, plus
Window-Eyes, Home Page Reader, and another product, Hal. I was also able to get results for
the now-discontinued OutSpoken for Macintosh.

The results are unreassuring.

  Product

  display: none

  visibility: hidden

  Hal version 5.20

  Does not read

  Reads

  IBM Home Page Reader 3.02

  Does not read

  Does not read

  Jaws (4.02, 4.50, 5.0 beta)

  Reads

  Reads

  OutSpoken 9

  Does not read

  Does not read

  Window-Eyes 4.2

  Does not read

  Does not read

Analysis#section6

It seems clear that any element given a style of
display: none should not be rendered, read, or
manifested at all by any device in any modality. Hal, IBM Home Page
Reader, OutSpoken, and Window-Eyes are behaving properly under this
interpretation, while Jaws is misbehaving.

It seems also that an element styled with
visibility: hidden, because it generates a box with
invisible contents, should not be read by any device whether visual
or not (that is, either a graphical browser or a screen reader). The
sole difference between the two stylesheet declarations is the effect
on the rendered layout, which a browser must obey but a screen reader
could theoretically ignore. (Recall the difference between
display: none, which takes up no space, and
visibility: hidden, which does.)

An exception could be a case where the bounding box styled with
visibility: hidden affects reading order or some
other consideration that is perceptible in a sequential voice
presentation, in which case a screen reader could alter its voice
output in some way. Perhaps some uses of FIR fall into that category.
We could use some test pages to examine that theory.

In any event, it seems that no screen reader should work
with Fahrner Image Replacement except in rare cases. The fact that
the dominant such program, Jaws, and the smaller-market product Hal
actually do understand FIR is an accident we should not rely on for
the future.

Improving CSS#section7

A little-known feature of Jaws, Window-Eyes, and Home Page Reader is
the ability to synchronize voice output with either onscreen display
(scrolling the screen and/or highlighting sections as they are read)
or Braille or both.

  • Window-Eyes release notes call it a “surfing with sighted friends” feature.
  • IBM Home Page Reader
    “is synchronized with a moving cursor to make reading even
    easier.”
  • Jaws and Window-Eyes can both
    produce Braille instead of or concurrent with voice.

Thus, screen readers in widespread use are multimodal devices.
They are clearly at odds with the current CSS media-type definitions because their
behaviour is multimodal, for which the existing screen,
aural, and braille media types are not really suited.
Perhaps it’s time for a new media type that screen readers in
actual use today could comply with – one that gives clear
guidance on how a system that displays, talks, and produces Braille
should handle real-world style definitions.

I suggest here that the World Wide Web Consortium fail to repeat its
mistake with embed, a widely-used and still-supported
element that was never made legal in the (X)HTML spec. The multimodal
behaviour of current screen readers should be explicitly legal
according to the CSS spec even if that requires adding to it.

That wouldn’t require overturning the existing spec, which
already says, “Media types are
mutually exclusive in the sense that a user agent can only support
one media type when rendering a document. However, user agents may
have different modes which support different media types.” It
doesn’t look like a tough job to expand these definitions to
provide for multimodal output.

With a media type that relates to the way screen readers in wide use
actually behave, we’d have a stronger basis from which to
insist that screen-reader manufacturers comply with stylesheet
specifications. A full discussion of that would, of course, require a
separate article.

Not an accessible technique#section8

Unfortunately, Fahrner Image Replacement cannot be said to be an
accessible web technique when used for text. Screen-reader
users either already cannot read any text marked up that way or will
not be able to in the future when the software is updated to
interpret CSS correctly. Other people with disabilities will probably
never be adversely affected by its use, and many will benefit the way
nondisabled people do, since a lot of disabled people online have
normal vision and enjoy attractive websites. But we cannot exclude
screen-reader users from a conception of accessibility.

For that reason, standards-compliant designers should use FIR only
for images that could be called “nonsemantic,” that is,
not meaningful. Background patterns might be one example, or a
company logo that is reproduced in plain text (possibly as a heading)
somewhere nearby. Use your common sense.

Help for developers#section9

This case of a standards-compliant technique, advanced by the most
sophisticated developers, that nonetheless hits an iceberg and sinks
when it comes to accessibility at least has the benefit of
highlighting a few deficiencies that need to be remedied. In
particular:

Acknowledgements#section10

  • Brandon Bowersox
  • Douglas Bowman
  • Rich Caloggero
  • Tomas Caspers
  • Antonio Cavedoni
  • Tantek Çelik
  • Tom Croucher
  • Bob Easton
  • Todd Fahrner
  • Chris Hofstader
  • Michael L. Johnson
  • Andrew Kirkpatrick
  • Eric Meyer
  • Will Pearson
  • Seth Rothberg
  • Dave Shea
  • Aaron Smith
  • Jim Thatcher
  • Léonie Watson

44 Reader Comments

  1. What if the user has images turned off and views a page with FIR?

    Unfortunately that user views nothing more than white space. Stuart Langridge has featured his own FIR called “A new image replacement technique.” Instead of abolishing the text with display:none, we can just use an empty tag to place an image over the text. Although this adds a small markup, this method allows users with CSS on and images off to read the text.

    To get to my point, wouldn’t this method work in all the screen readers? I would think so because the text is always there.

  2. I was surprised not to see any mention of the Leahy / Langridge hack, which has been public for a while now (there was even a link from Jeffrey’s web site…) Testing this one would have been interesting, as it seems to fail only in the “CSS but not images” scenario.

    Just in case: This alternative technique consists in pushing the text down with a padding as high as the image, and hide the characters using the overflow property. More at:
    http://www.moronicbajebus.com/playground/cssplay/image-replacement/
    http://www.kryogenix.org/code/browser/lir/

    Anyway, congratulations for the redesign. It looks cleaner. And it validates, apparently 😉

  3. Great article!

    I just posted the below message to Douglas Bowman/stopdesign:
    ——-
    Thanks for a helpful article.

    My concern is not only with screen readers, but also search engines. As you might or might not know, title tags are vital to search engine indexing. I’m designing and building web solutions based on my own CMS, and i work closely with a colleague whose focus is on SEO (search engine optimization).

    SEO is not my trade, so I don’t know how i.e. Google works, but I can’t risk the title not being indexed/disregarded because it’s hidden (visibility: none). Any thoughts/experiences on this?

    Final thought. The Fahrner image replacement technique makes the text unselectable. This could be overcome using a script to swap the image with the text, eventually hide the image if it’s just an overlaying layer.

  4. That’s the beauty of Stuart Langridge’s FIR at Kryogenix. The text is “always on” and available for screen readers or search engines and visible with images off. I use his technique on my website.

  5. I am not familiar with aural stylesheets, but conceivably a similar technique could be used to render (play) some sound file instead of the element’s text, using the cue property for example.
    Also, screen-readers might need to have speak:normal in addition to display:none to selectively read a FIR’d element.

  6. The article went through many betas in the summer, and then I left it in J the Z’s hands for the ALA relaunch. There’s been as much development on FIR since I wrote the piece as there had been immediately before, as the first graf states.

  8. Your article doesn’t mention the differences between imported and linked stylesheet for the screen-reader. It seems to matter.
    Anyway, the problem of screen reader is already solved by the Leahy / Langridge hack. Even better if we use negative text-indent instead of padding. Another way of addressing the problem, working only with flat color images, is to use font-size: 1px, eventually with negative letter-spacing, and same font-color than the background color of the image.
    Just one problem remains: css on + image off. But is this really an accessibility problem? I’m not sure. Bye!

  9. I use FIR sporadically throughout our site.

    Due to the fact that the machines here running ie 5.0 also are usually set to 480×600, the desired effect tends to fail. So I’ve implemented the Tantek hack.

    Wouldn’t this also suffice for screen readers?

    Thanks for the article,

    Andy

  11. One notion I haven’t seen mention of is what happens when you run a web page through a translator, such as Babelfish? The text does get translated, but of course the images stay the same. So when you use FIR and display a translated page, you don’t get the translated headers — but the translation is there! It would be nice to have a way of getting the text version to show up in the form of a tooltip, or use some other device to force the text version that is replaced by the graphic to show up, so the page can be understood.

  14. I feel honored that the Sitepoint article (mentioned in an earlier comment) discusses the method that I use and popularized. The author did a great job talking about both the up and downsides to it.

    Made For All (www.madeforall.com) will soon be coming out with Issue 5 which includes my take on image replacement.

    Joe — I’m glad you referenced C. Z. in your article as the “originator” for the image replacement code. I spoke with him after the late-summer hoopla regarding image replacement, and he was surprised that I actually took the time to figure out he was the first.

    As for the holy-grail of image replacement — complately semantic, totally accessible, and usable for those with images turned off — I don’t believe it has been developed yet. CSS implementation on the world’s most popular browser will forever limit us, and until CSS3 content rules work in IE, the holy grail will stay hidden.

  15. Correct me if I’m mistaken, but isn’t a screen reader, in difference from an aural rendering engine, supposed to represent what is displayed on screen? An aural rendering engine would try to render the page in aural media, and naturally also handle aural stylesheets and not be affected by screen stylesheets, but shouldn’t a screen reader just try to represent the visual data in aural format? Thus, an image might be represented by it’s alternative text which is made for medias where it can’t be displayed, but the stylesheets for screen should still apply.

  16. Is a screen reader an aural device, yes?! then it should work with aural stylesheets but it does not. If it did then we could style it with one style for screen readers (aural) and one for browsers (screen). Great article Joe. The FIR technique is a great study to make us think. W3 and screen readers please get together before the next recommendation. W3 we may really need multimodal devices but what if the style sheets conflict in implementation? Keep it simple – keep it seperate I rekon. But to be sure we need user testing. This needs scientific research – maybe a university could start. Testing, testing, one, two, three, come in, over.

  17. This css hack could lead a search engin to consider your document as hidden keyword Spamdexing.

    Accessibility appart, i really think it’s a bad usage of css :

    – First, it sounds like a repetition of the alt or longdesc well know alt’s img attributes combined with a css.

    – Second, sometimes you have to break words in part, wich mean nothing or bring noise in your speech, goat and boat could be a good sample of nonsens (in cas of first-letter).

    – Third, you have to double tag and by the way bring weight for nothing.

    In conclusion, accessibility, search engine misinterpretation, repetition, noise and weight don’t make me think this is a usable css hacks, but let me ask another question…

    What about svg ?

  18. A method i have been using is to shrink the text down to a pixel and colour it the same as the image (a CSS background). Of course this will only work with certain images and non I.E browsers can resize the text. I have used this method on my department’s intranet — “standardized” to I.E. with a few rogue Mac users (me included), so it is a bit of a controlled system.
    The upside of this is the text is not hidden but just teeny-tiny so it *should* still be read by a screen reader.
    Anyway, it is at least another trick in the bag.

  19. FIR, FEAR, FIRE… | by Boris Meyer
    >This css hack could lead a search engine to consider your document
    >as hidden keyword Spamdexing.

    This might be true once SE spiders interpret css,
    then it would apply to any other css technique hiding text as well,
    making most of css driven nav systems or pure fancy effects spamdexing.

    I don’t think SEs could afford to cripple designer’s css options to that extend;
    punishing font coloured the same as the containing element’s background in ye olden times
    didn’t harm designer’s choices as this method hasn’t any conceivable benefit regarding
    layout and design. (except for very sloppy and inept coders)

    Instead, a more sensible approach would be to simply ignore hidden text for indexing;
    in fact most of spamdexing nowadays doesn’t relay on hiding text but of link farms whose
    visible text qualifies as spam because of it’s semantics.
    (or lack thereof to human readers,
    spammers don’t care much about that, it’s not meant to be read by humans)

    Concluding,
    hunting for spamdexing will force SE’s to rely on semantic analysis,
    hiding text by css (or script) should be harmless in times to come,
    as for now, I haven’t heard of css parsing bots.

    An -hopefully- educated guess,
    Marek Moehling

  21. Very insightful article, and kudos for using actual screen readers to research accessibility principles.

    I have one, minor, philosophical difference with the article:

    >> Hence, display: none really means manifestation: none or elimination: total. An item assigned to display: none expunges itself.

    I’m not sure about this interpretation. “Display” certainly seems to imply a visual issue, especially since the other options are “block,” “inline,” and “list-item.” If “display: none” means screen readers should ignore it because it has expunged itself, how does that interpretation of “display” square with the other options?

    The only reason I bring this up is because there is a difference between stating what screen readers actually do and what screen readers *should* do. I’m not sure I’m convinced that screen readers *should* ignore a display:none.

  22. I’ve always intepreted display:none as “don’t render me visually at all”. It would be nice if screen readers conveyed the document structure, like a text browser, as opposed to what the user agent renders. But then, it wouldn’t be a “screen” reader.

  23. FIR, FEAR, FIRE… | by Boris Meyer
    >This css hack could lead a search engine to consider your document
    >as hidden keyword Spamdexing.

    I looked into this issue a while ago and was told that the only real risk here is if one is clearly abusing display: none. Spiders (AFAIK) don’t parse CSS, so the site in question whould have to be reported to a search engine administrator and an actual human being would have to determine that CSS was being abused to increase a site’s ranking. It seems doubtful that would happen with FIR.

    Justin

  24. Two variants that I’d been wondering about, that I didn’t see mentioned above.
    1. If you were using this to replace an h1 with a image, what if you duplicated what is in the span in the title of the H1? Do screen readers catch things like that?
    2. What if you put specific media rules in for screen readers that make that span an inline element?

  25. What about making the CSS content property not be restricted to :before and :after pseudo-elements? This was the first thing that occured to me when I saw FIR.

    #foo { content: url(foo.gif); }

    Foo and Bar

    It seems that usage of the content property should replace any content in the markup. Now, we may still have the issue with screen readers that has to be resolved, but at least we get rid of those damned span tags.

    With that change you could also do something nifty like:

    img[src] { content: url(att(src)); }
    object[data] { content: url(att(data)); }

    in the browser’s default stylesheet to make those elements that don’t use XLink render without needing special HTML processing. Caveat: I don’t know if it’s currently legal to nest the att() in a url().

    Anyway, I’m just brainstorming.

    As a side note, a problem with is that you can’t mark up the text in the alt attribute (like in my example). Also, technically is deprecated, and if it wasn’t for IE I would have switched to the Foo and Bar long ago.

  26. Problems seem to come from programs like JAWS awkwardly falling somewhere between “screen reader” and “aural web browser”, neither simply reading off the display or working from the markup (and, ideally, aural CSS).
    I can’t see how selectively parsing a few bits of CSS clearly aimed at graphical browsers is helpful or reliable, am I missing something?

  27. You’re definitely right, Greg. As soon as FIR came out, many people (including Tom Glider) started discussing how pretty much all image replacement techniques are non-semantic hack jobs. When browser’s widely support the content property, that will be the preferred “weapon of choice”.

    Mike

  28. Surely the main reason that we’re embarking on such a convoluted series of hacks is misplaced.

    If font embedding had matured as a technology, we wouldn’t even need to find ways of supplying GIFs and hidden text as headings.

    Rather than doing FIR of any sort, why don’t we start using embedded web fonts and therefore provide impetus to getting this better supported as a technology.

    Embedding fonts + CSS type control was for me the most exciting potential application of CSS back in 1998 – what the heck happened that we all ignore this approach?

    Just my £0.20 (inflation, you know…)

    Cheers

    Ian

  29. Correct me if I’m wrong about how this works..

    I don’t think the type foundries would be too happy about us embedding fonts, making them available for everyone to download.

  30. In reply to Justin Peters…

    >I looked into this issue a while ago and was
    >told that the only real risk here is if one is
    >clearly abusing display: none.

    So exactly what FIR could lead to… how a search engine could make the difference between ?

    You could also put text in a div with a tiny-tiny width/height couple, or have the same color of your background…

    Today those well know spamdexing technics are known from Search Engine…

    Do you think they won’t find this one ?

    >Spiders (AFAIK) don’t parse CSS, so the site in
    >question whould have to be reported to a search
    >engine administrator…

    I don’t think so as css is a language, this can be analysed.

  31. My biggest question is what is wrong with the alt attribute? It seems like that is what it was specifically designed for, right?

    I can see one drawback in that some screen readers may preface the alt attribute by saying ‘image: (alt text)’.

    As for the screen reader comments, I agree that the screen reader’s job is to read the screen. Jaws, for instance, is an OS-level screen reader. Not an aural web browser.

    As for font embedding, that never took off, and probably never will. Type foundries can be a bit paranoid (take a look at some of the font embedding restrictions with PDFs).

  32. Nothing is wrong with alt, but

    tag has much more importance for a SE’s spider… and with normal html you can even format that text separating from the main title, the subtitle (

    ) etc.

    However i agree with Phil Ledgerwood, I really think that screen readers should not consider css at all… (i mean visual css offcourse).

    Not parsing visual css at all i think cannot lead to problems, if they just are visual element, how can a blind user need’em?

  33. And about font embedding I agree that Type foundries would not be happy of this, but I think problem would even be another too… why should I download a font (sometimes they are quite heavy) just to see some text? Even embedding just used chars (as you can do with flash) I don’t think this two problems could be solved.

    I think a more limited but lighter solution would be very easy: implementing the ability of use antialias on text alone, would be enough to avoid 90% of text images, then combinig it with a stroke effect, a pattern fill effect (to place a backdrop inside a big text) and a couple of other such as dropshadow or glow, would really low the need for images.

    I think all this effects are quite easy to implement and not so heavy for the CPU, and offcourse for the bandwidth -coz most of them are procedural. Even without embedding fonts, but just using standard font with this effects applied, designers possibilities would raise a lot.

    Byez [and sorry for bad english]

  34. I have a suggestion for solving the problem in a very easy way. It should work for screen readers, images turned off and seo:

    Header Text

    img { display: block; }
    h1 { height: [height of image]; overflow: hidden; }

    what do you think about this?

  35. Nice, but…
    making so you have got picture and text… the picture in in the html, but it’s better to have the picture just as backdrop image, because it’s a non-structural element, but just a graphical one

    instead of this put pic just as h1 background and not in html, and to h1 say also

    padding-top: 100%;
    overflow: hidden;

    as explained some post before

  36. I think, the feature ‘z-index’ makes pages with image-replacement more accessible than hidden visibility or ‘display: none’.

    The only problem is: what if a user enlarges the text under (!) the image. Than you can set the text smaller, or set the box of ‘span’ to ‘overflow: scroll’.

    [html]

    H1
    SPAN (text) /SPAN
    /H1

    [css]

    h1 {
      background-image: url(‘/pic/h1.gif’);
      …
    }
    h1 span {
      z-index: -1;
      …
    }

    But, I prefer the tag ‘image’ with the alt.

  38. I wonder if we can make the method accessible.

    Let see.

    instead of using visibility: none;

    why not making a height and width equals to 0px.
    I’m pretty sure, it will generate other issues. but at least it’s accessible to screen readers.

  39. But I thought the whole point of this technique was that it enabled you to create different stylesheets for the same content, one (for normal browsers) which shows the image and not the text, and one (for old browsers and screen readers) which shows the text but no image. The correct stylesheet could be selected using client-side or server-side user agent detection, or just using media types in the case of the screen reader.

    In the light of this surely worrying about screenreaders not reading out the hidden text is a bit pointless since you would provide an audio stylesheet which didnt hide the text? or am I missing something else?

  40. Using text-indent. Setting it to a ridiculously high negative value (like text-indent: -100000) would prevent the text from ever displaying in a Visual Browser. But it’s still there. And the image is there.

    However the issue of displaying the image when images are turned off in web browser and showing text, still applies. Haven’t really tried this technique out full-scale, so I don’t about browser compatability or being valid.

    Maybe someone can shed a light on it?

  41. FIR is just a hack to make our CSS “pure” by seperating images (which are style) from our content, while still making the content of the image (usually text) available to people using screenreaders. Lame, ugly, and a hassle – all for the sake of fickle “purity”.

    CSS 3 is more capable of seperating eye-candy images from content, so I intend to use old-fashioned tags until CSS3 is widely supported.

  42. Just an aside…

    While all this discuss on FIR is very interesting and useful, the biggest issue I can see with FIR is a purely design one: images are not fluid in size like text is.

    The image is going to stay the same size when you resize the text using the browser’s text size (unless some doofus has used pixel font sizes in IE) so the beautiful design work which required FIR in the first place is going to break down the moment a user wants to view bigger/smaller text.

    Purely based on that I’m going to stick with text for text 😉

  43. There may well be a lot of issues which reveal themselves after testing on screen readers. For example, at least one release of Jaws 4 does not read the contents of the alt attribute if a graphich is smaller than 10×1 or 1×10.

  44. To clarify, the non-reading of the alt attribute on small graphics was an intentional feature of that release of Jaws 4. Since I don’t have access to Jaws 5, I don’t know whether it is still a feature.

    (As to why someone would do this, we use small transparent graphics with alt attributes to provide instructions to be read by screen readers, but which are not visible to sighted users, such as “skip navigation” or “content begins here”.)

    It is also not sufficient to ask someone to test a page in their screen reader using their settings. Jaws (and possibly other screen readers) offers a choice of modes for reading the page, at least two (one is called Virtual Cursor Mode). The different modes may give different results for specific coding techniques. So this actually multiplies the number of tests one must do.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

User Research Is Storytelling

by
At a time when budgets for user experience research seem to have reached an all-time low, how do we get stakeholders and executives alike invested in this crucial discipline? Gerry Duffy walks us through how the research we conduct is much like telling a compelling story, complete with a three-act narrative structure, character development, and conflict resolution—with a happy ending for researchers and stakeholders alike.

I am a creative.

by
A List Apart founder and web design OG Zeldman ponders the moments of inspiration, the hours of plodding, and the ultimate mystery at the heart of a creative career.
Career