W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2003

RE: Possible problem with Fahrner Image Replacement

From: Aaron Smith <aaron@gwmicro.com>
Date: Mon, 21 Jul 2003 08:59:29 -0500
Message-Id: <6.0.0.12.0.20030721085840.039126b8@127.0.0.1>
To: Mike Rundle <phark@phark.net>, WAI-IG <w3c-wai-ig@w3.org>

Just to toss another match on the fire, using text-indent: -100 (or the 
value of your choice to move the text "offscreen") is another work around.

Aaron

At 07:54 AM 7/21/2003, Mike Rundle wrote:

>On Mon, 21 Jul 2003 11:53:24 +0100, Lauke   PH wrote:
> > Apologies for barging in late on this, but I've been on holiday...
> > One thing that struck me in this discussion was Mike Rundle's comment
> >
> >>  if you set the color of text to
> >>  transparent, the browser usually renders the color as the "default
> >>  color" for that type of text
> >
> > What do you mean exactly by "set the color of text to transparent" ?
> > If you're referring to a CSS similar to color: transparent,
>
>exactly, color: transparent; I know it doesn't work, but it would be
>useful(?) if it was implemented.  During some testing that I did,
>the color that showed up was a "default blue", the kind reserved for
>default
>link colors.
>
> > I would like
> > to ask how supported this is, as - unless I'm misreading the W3C spec -
> > "transparent" can only be used for background, and not for color.
>
>Exactly, that's the *wishful* thinking part of my post, however after
>reading
>many different designer's views on the current problems with Fahrner
>Image
>Replacement idea (screenreaders passing by the text altogether), these
>are the
>current ways people are getting around this:
>
>         1. Use the background-image CSS rule, and color your text 
> manually to
>not be
>            visible against the background, e.g. white on white.  Then, by 
> ways
>of CSS
>            positioning, move it off one way or another so that the 
> background
>image
>            shows, however the text cannot be seen (but still inside the
>containing element).
>
>         2. Have the background-image placed, but move the text so far away
>(inside the
>            containing element) that it expands the width or height of the
>element.  Then,
>            set the overflow property of the containing element to hidden so
>that the text
>            does not show at all, and the initial dimensions are not skewed.
>
>For right now, I'm trying to implement the first idea in the sites I'm
>developing,
>however, when a better method (less of a hack job, IMHO) comes my way,
>I'll gladly
>throw that into my code instead.
>
> >
> > Incidentally, what happens if display: none (which causes the problem
> > in FIR) is changed to display: hidden ? Hmm...may have to do some 
> testing...
> >
>That's what accessibility experts and designers alike are wrestling
>with right now,
>what display: hidden; does to text reader applications and if that
>property is useful
>in any way.
>
>-Mike
>
> > Patrick
> > ________________________________
> > Patrick H. Lauke
> > Webmaster / University of Salford
> > http://www.salford.ac.uk
> >
> >

--
To insure that you receive proper support, please include all
past correspondence (where applicable), and any relevant
information pertinent to your situation when submitting a
problem report to the GW Micro Technical Support Team.

Aaron Smith
GW Micro
Phone: 260/489-3671
Fax: 260/489-2608
WWW: http://www.gwmicro.com
FTP: ftp://ftp.gwmicro.com
Technical Support & Web Development 
Received on Monday, 21 July 2003 09:59:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:10 GMT