homepage Welcome to WebmasterWorld Guest from 54.167.138.53
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Visit PubCon.com
Home / Forums Index / WebmasterWorld / Accessibility and Usability
Forum Library, Charter, Moderators: ergophobe

Accessibility and Usability Forum

This 31 message thread spans 2 pages: 31 ( [1] 2 > >     
accessibility and <h1> header images
phranque




msg:3844968
 1:04 pm on Feb 8, 2009 (gmt 0)

i am struggling with the same issue that was described in this thread in the CSS forum:
Does hiding text with "Display None" affect SEO? [webmasterworld.com]
as swa66 noted, substituting an image for text is not very friendly.
however i lost this argument about switching a header image to text and i have to admit the font looks cool.
so i am trying to find the best possible solution that addresses accessibility, user agent degradation, semantics, seo, etc in the most optimal manner.
the accessibility/usability quandary is the css-disabled echo effect versus the image-disabled silence effect.

the header text, the alt attribute value and the text in the image itself are all equivalent in this example.
this works well for image- and css-enabled browsers:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Test H1 header with image AND text</title>
<style type="text/css">
<!--
.h1 { display: none; } /* so we can have some real text for accessibility and semantics AND the cool font/image */
-->
</style>
</head>
<body>
<h1><span class="h1">Header Text</span><img src="http://example.com/images/TT_headertext.png" alt="Header Text" width="222" height="33"></h1>
</body>
</html>

however if you disable css then you get an echo effect.
you will therefore also see the echo effect in for example the Semantic data extractor - QA @ W3C [w3.org].
in that case the alt attribute text is surrounded by square brackets so i wonder if that somehow indicates less trust in the semantic information provided.
i would be tempted to blank out the image alt attribute but then it wouldn't work well with images off and css enabled.

btw i tried the text-indent attribute suggested by swa66 in that thread and had no success since everything i tried also affected the image placement and that wouldn't solve the echo issue with css disabled, which is the primary purpose of this post.
you have to wonder about seo-related issues with using display:none; for the text...

 

encyclo




msg:3844984
 2:23 pm on Feb 8, 2009 (gmt 0)

The short answer is that you should insert the background image via CSS, meaning that if CSS is disabled only the
h1 text will show. Something like this:

CSS:

h1 {
color:#000;
background:#fff url(/images/TT_headertext.png) top left no-repeat;
height:33px;
}

h1 b {
display:none;
}

HTML:

<h1><b>Header Text</b></h1>

You may be able to use text-indent too (I've not tested it for the above scenario). If the image is comprised of text, you can also do it in Flash and use sIFR. :)

phranque




msg:3845060
 5:01 pm on Feb 8, 2009 (gmt 0)

i actually considered using flash and swfobject.

the css background means you lose the alt text so it's invisible with images off/css on.

i might play with z-index and try to get the image displayed over the text.

bedlam




msg:3845287
 2:08 am on Feb 9, 2009 (gmt 0)

Well if the question is this:

Does hiding text with "Display None" affect SEO?

Then, absent an actual answer, the solution should not contain this:

h1 b { display:none; }

'display:none' has also been known to hide content from some users [css-discuss.incutio.com] (though I can't determine the current status of this issue).

In any case, 'display:none' is not required for image replacement since there are at least two other methods of accomplishing a similar result:

With padding
<h1 id="replace_1">Lorem ipsum dolor sit</h1>

#replace_1 {
/* Hide the text */
height:1px;
overflow:hidden;
/* Make room for the background image (assuming 200px x 30px) */
padding-top:29px;
width:200px;
/* Show the background image */
background:transparent url(path/to/image.png) no-repeat top left;
}

With text-indent
<h1 id="replace_1">Lorem ipsum dolor sit</h1>

#replace_1 {
/* Make room */
text-indent:-999em;
overflow:hidden;
width:200px;
height:0px;
/* Show background */
background:transparent url(path/to/image.png) no-repeat top left;
}

With images instead of background images
<h1 id="replace_1"><img src="path/to/image.png" alt="image: Lorem ipsum dolor sit" width="200" height="30" />Lorem ipsum dolor sit</h1>

#replace_1 {
width:200px;
height:30px;
position:relative;
}
#replace_1 img {
position:absolute;
top:0;
left:0;
}

As you've already pointed out, this is arguably one of the better methods, though the purist in me thinks a background image should be used in this context :)

For more information, have a look at some of these threads [google.ca].

-- b

lavazza




msg:3845323
 3:34 am on Feb 9, 2009 (gmt 0)

minor point:

<b> is deprecated (or slated to be so?)

<strong> is the new <b>

pageoneresults




msg:3845326
 3:43 am on Feb 9, 2009 (gmt 0)

minor point: <b> is deprecated (or slated to be so?) <strong> is the new <b>

I don't think <b> is deprecated. The <b> element is a "font style" element and <strong> is a "phrase style" element. They both have their uses. Same applies to <i> and <em> respectively.

How is an image alt attribute treated when the image is within a <h> element?

<h1><img src="/images/file.png width="200" height="36" alt="Heading Text" /></h1>

There is so much you can do with styling these days that jumping through those hoops just so you can have a graphic heading is a bit much for me. I know what you mean though, there are many font styles that cannot be replicated via CSS.

phranque




msg:3845391
 7:10 am on Feb 9, 2009 (gmt 0)

the <b> and <i> elements are purely presentational and are therefore semantically worthless.
if it's not deprecated it should be considered poor practice to use these.

How is an image alt attribute treated when the image is within a <h> element?

when using the Semantic Data Extractor:
the alt attribute text is surrounded by square brackets so i wonder if that somehow indicates less trust in the semantic information provided.

maybe the easy answer is still the best here, though.

There is so much you can do with styling these days that jumping through those hoops just so you can have a graphic heading is a bit much for me. I know what you mean though, there are many font styles that cannot be replicated via CSS.

sometimes it is simply not your decision to make.

phranque




msg:3845393
 7:25 am on Feb 9, 2009 (gmt 0)

@bedlam:

that was interesting information in that link.
however i had already tried that off-left technique and it doesn't work for some reason.

i had also tried the text-indent and padding methods you described but they both fail with images off:
the css background means you lose the alt text so it's invisible with images off/css on.

With images instead of background images

i also tried this technique but there is the css-disabled echo effect here.

bedlam




msg:3846139
 5:26 am on Feb 10, 2009 (gmt 0)

Well, the image replacement problem is tricky. One way or another, you've got to show an image and hide the content. And if it is necessary that there be some fallback from the image when images are disabled but not css, then there are still a couple of alternatives.

Positioned img element with empty alt attribute

The objection to using the image and positioning it over the text is that the content is doubled if images are disabled. However, this assumes that you've used the same content in your header and your alt attribute. In spite of the fact that that's essentially what I did in my sample above, I see no good reason whatsoever for doing so. Given that the text in the h1 (or whatever element) has not been removed from the page, an identical alt attribute must arguably be duplicate content. If an image is included for no other reason than to provide a more aesthetically pleasing version of the text content, then it is decorative. Its alt attribute can therefore be empty.

Using :before pseudoclass with content property

I was thinking about this problem this afternoon when I thought of a different approach. For a few minutes, I was pretty excited thinking I'd discovered a new image replacement method. But then I started searching through my bookmarks and discovered an article on the same method from more than three years ago. There are also numerous other mentions of it on the web [google.com].

The method is essentially to use the :before [w3.org] pseudoclass and the CSS content [w3.org] property to insert a background image before the text in the element. If you also restrict the element's size to the size of the image, it's possible to completely replace the image this way.

This method works well, but in spite of the intervening three or four years since I first read of it (and the almost eleven years [w3.org] since the CSS 2 spec was released), Internet Explorer has still not managed to add support for the content property in any shipping browser (I did not test IE8). Still, the technique might come in handy for any site with sufficiently low IE numbers or intranets.

Aside from IE, browser support is pretty good, though how browsers handle it with images disabled varies.* But given the lack of IE support, it's unfortunately of mainly academic interest. Here's a sample of the code:

<h1>Lorem ipsum!</h1>

h1 { width:200px; height:30px; overflow:hidden; }
h1:before { content:url(../path/to/image.png); }

-- b [700!]

*Firefox still shows the image and Opera shows a placeholder that says "Image". Only Safari gets it right and shows nothing at all.

pageoneresults




msg:3846149
 5:55 am on Feb 10, 2009 (gmt 0)

I too have been doing a little bit of research into this. Years ago I got on the WEFT bandwagon.

WEFT - Web Embedding Fonts Tool
[microsoft.com...]

And then we have EOT.

Font Embedding on the Web - Font Embedding with EOT
[blogs.msdn.com...]

Embedded OpenType (.EOT) Font Format Submission Request to W3C
[w3.org...]

And now, as of 2008 September, the W3C may set up a WG to take this further...

For and against standardizing font embedding
[w3.org...]

I know this doesn't help out much in this current situation but it appears that some of this technology is supported and further support is expected.

the alt attribute text is surrounded by square brackets so i wonder if that somehow indicates less trust in the semantic information provided.

I believe the square brackets just means that the content within them was found in an alt attribute. Whether it was on an actual image, image map, whatever. Those will typically appear enclosed in [brackets].

I'd really like to know how that Alt Attribute is treated within an <h1>. I think I know because I've seen the results of my "float" technique which combines an image and heading text into an <h> element. This is strictly a design technique and ended up producing some rather interesting results. The image is usually related to the content that surrounds it, including that <h> element. :)

From the one IEBlog article link above...

However, anyone who has a copy of Windows Vista, Office 2007 or Mac Office 2008 already has a great set of fonts they can embed in Web pages. They’re called the C* fonts (because they were optimized for ClearType, and thus all given names which began with “C” J): Calibri, Candara, Consolas (a monospaced font for coding), Cambria (which also contains a set of 4000 Math characters), Constantia and Corbel.

I think I know because I've seen the results of my "float" technique which combines an image and heading text into an <h> element.

I'm going to go out on a limb and say that the bot sees the alt attribute the same as text if the actual text is not present. And, if the text is present in this hiding technique, that there is a replication taking place that "may" or "may not" be a good thing. And, that jumping through all these hoops to get this just right is a fruitless effort as they say. Just drop the image into the <h> with appropriate alt attribute and be done with it. The bot sees the same thing as if you were browsing your site with images off anyway. ;)

Is it possible there are some if/else type routines performed in this type of situation? Meaning, if the text is not present, fall back to the alt attribute or other accessibility attribute that is present?

pageoneresults




msg:3846197
 8:03 am on Feb 10, 2009 (gmt 0)

I'm in the process of writing an article pertaining to this whole image replacement technique which I don't think is necessary. Not based on the guidelines for the use of the alt attribute. I really don't think you need to jump through the hoops that you are to make all this happen when all you need to do is use the alt attribute. ;)

Use the alt attribute to describe the function of each visual - Quality Web Tips
[w3.org...]

If your code has the alt attribute set in its images, most of these browsers will display the description you gave instead of the images.

Search engine bots belong to the two above categories: if you want your website to be indexed as well as it deserves, use the alt attribute to make sure that they won't miss important sections of your pages.

I think the bot falls back to the alt attribute when indexing a document in this type of <h> scenario, I really do. In fact, any and all images present are an integral part of the structure and that is why using that alt attribute effectively is imperative.

If the image presents a lot of important information, try to summarize it in a short line for the alt attribute and add a longdesc link to a more detailed description.

Ya, what happens when your heading crosses that 80 character threshold for the alt attribute? It's probably too wordy to begin with. ;)

Seriously though, you can't expect to use the longdesc in this scenario, that would be too tedious and I'm not too certain there is much benefit with that one in this case. Not unless the architecture of the site supports its use. Also, I believe the longdesc is deprecated in HTML 5 if you plan on making that transition.

phranque




msg:3846996
 5:46 am on Feb 11, 2009 (gmt 0)

after a couple of days of study i am also of the opinion that the "keyword echo" would have a more detrimental effect than a possibly discounted alt attribute value without the "hidden text".

an apparently fruitless effort, indeed.

pageoneresults




msg:3847302
 4:24 pm on Feb 11, 2009 (gmt 0)

I'm really surprised I didn't create a backlash of some sort. Maybe some haven't read the fine print or between the lines?

Did you know that there are at least 9 published methods for Image Replacement? These people are so passionate about the subject, that the techniques are named after them. I mean, here is the current list based on my research...

  1. Classic FIR
  2. Single Pixel <img> Replacement
  3. Radu Method
  4. Leahy/Langridge Method
  5. Phark Method
  6. Dwyer Method
  7. Gilder/Levin Method
  8. Lindsay Method
  9. Shea Enhancement

That's a lot of man/woman hours flirting about up there. But why? What is their goal? Ever read any of the guidelines for creators of UAs and other applications? There are some very interesting insights as to how the UA interprets documents based on guidelines and protocols.

This one single quote sums it all up and is the reason for me to believe that using "just" the alt attribute in the <h> image is all you need, it is treated the same as text and should be based on the guidelines. Not only the guidelines many of us usually read but, other guidelines which go a bit deeper.

"Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the user."

Okay, so I need to know what I'm missing in this equation so I can come down off my high horse. Why is there so much difficulty being injected into something that HTML provides an alternative for? Why? What the heck did I miss in the hours upon hours of research? ;)

discounted alt attribute value

I don't think it is discounted given the right implementation.

This...

<h1><img src="/images/accessbility-and-h1-header-images.gif" width="300" height="20" alt="Accessibility and &lt;h1&gt; Header Images"></h1>

Is the same as this...

<h1>Accessibility and <h1> Header Images</h1>

"Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the user."

^ Images on? Get the visual. Images off? Get the alternate content. It really is pretty simple. And, the bot browses with images off. :)

phranque




msg:3847698
 4:09 am on Feb 12, 2009 (gmt 0)

relying on alt text with images off/css on means you can't style the text to look as similar as possible to the image.

so i'm using the "shea enhancement" with the "phranque blanque" and as far as i'm concerned it handles everything properly:
<html>
<head>
<title>Test H1 header with image AND text</title>
<style type="text/css">
h1 {
position: relative;
font-size: 24px;
color: #ABCDEF;
background-color: #012345;
}
h1 span {
position: absolute;
width: 100%;
height: 100%;
}
#HeaderText {
width: 123px;
height: 32px;
}
#HeaderText span {
background: url(http://example.com/images/TT_headertext.png) no-repeat;
}
</style>
</head>
<body>
<h1 id="HeaderText" title="Header Text"><span>&nbsp;</span>Header Text</h1>
</body>
</html>

- should work with accessible browsers (and ie6 works)
- works with images off/css on
- works with images on/css off
- works with images off/css off
- not sure of image transparency issues
- with images off/css on you can style header font and background for similar effect to missing image
- the title text gives similar hover behavior to the alt attribute (this is the "shea enhancement" of the "leahy/langridge method")
- the additional &nbsp; in the span element (the "phranque blanque") is because i'm not AFRAID of Validation? [webmasterworld.com]
=8)

the only downsides i see are:
- use of the semantically worthless span element
- scalability and maintainability issues with using images for text in general

swa66




msg:3847814
 10:32 am on Feb 12, 2009 (gmt 0)

I'd be a bit concerned about

#HeaderText {
width: 123px;
height: 32px;
}

It means that people not needing a screen reader or a braille output, but needing bigger fonts might run into trouble if they set a user stylesheet in their browser to force bigger fonts.

OTOH, modern browsers like FF3 have a zoom feature that is maybe good enough at zooming images as well as text to help out those that do not need extreme font sizes.

In the end this is always going to be a compromise where accessibility looses a bit, no matter how hard you try.

phranque




msg:3847928
 1:41 pm on Feb 12, 2009 (gmt 0)

didn't consider that!

i also wonder how much this statement applies to headers (vs anchors):
With alt attributes, the amount of relevance information voted for those words is a lot less than the power of true anchor text would be

tedster [webmasterworld.com]

pageoneresults




msg:3847944
 1:54 pm on Feb 12, 2009 (gmt 0)

relying on alt text with images off/css on means you can't style the text to look as similar as possible to the image.

But that isn't true! I sent you a link to my test page, did you notice that alt text sits right on top of the image element when you turn images off in Firefox? And, that it takes on the styling of the <h> element naturally once images are turned off? You can't tell that there is text there but it is there and it is treated just as if it were regular text according to the specifications for the alt attribute.

With alt attributes, the amount of relevance information voted for those words is a lot less than the power of true anchor text would be, but at least it is there.

You know, tedster is one of the most knowledgeable people around here when it comes to Google. I'm going to have to disagree with him on this one. My research shows otherwise.

Now, how do you test something of this nature?

P.S. phranque, why are you still overengineering this? ;)

phranque




msg:3847949
 2:01 pm on Feb 12, 2009 (gmt 0)

phranque, why are you still overengineering this?

1. Classic FIR
2. Single Pixel <img> Replacement
3. Radu Method
4. Leahy/Langridge Method
5. Phark Method
6. Dwyer Method
7. Gilder/Levin Method
8. Lindsay Method
9. Shea Enhancement

you talking to me?
=8)

pageoneresults




msg:3847958
 2:25 pm on Feb 12, 2009 (gmt 0)

1. Classic FIR
2. Single Pixel <img> Replacement
3. Radu Method
4. Leahy/Langridge Method
5. Phark Method
6. Dwyer Method
7. Gilder/Levin Method
8. Lindsay Method
9. Shea Enhancement
10. phranque blanque method
11. P1R Method

I want to send smoke signals to the other 9 on the above list and see if we can get them involved too. I want to know why they felt it was necessary to do all this.

I am convinced that there is only one way to handle this...

<h1><img src="/images/file.png width="200" height="20" alt="Heading Text"></h1>

It passes all the other tests that seem to be going on. The only one that it hasn't officially passed is the "value" test. And, according to the specs I'm reading, it does pass that test too...

"Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the user."

Now, if I can convince everyone that the bots browse websites with images off and that the alternate content replaces the images/elements naturally and that there is no value lost, then we'd have a winner! But, that ain't going to happen. Not with all the man/woman hours invested in all the above Image Replacement Techniques. I'm thinking we can add this IR thing to the list of SEO Myths. ;)

Let me add that when you are constructing your alt attributes, and they are replacing important text, you should pay very close attention to proper case. It should match the image version exactly.

I think this video confirms my explanations above. It is 8+ minutes but well worth every minute. Listen carefully to how JAWS is interpreting the page he is using as an example. You can tell when JAWS encounters an image as a heading and it processes it just fine and alerts the user that it is a heading graphic and if it is linked, it will let the user know it is linked. Linked headings seem to have a little more juice in the overall equation. ;)

Importance of HTML Headings for Accessibility
[youtube.com...]

<added>

Text as images
[cs.tut.fi...]

On the other hand, an img element may appear inside other markup. It is allowed wherever text-level elements are allowed, e.g. within a H1 element (indicating first-level heading). Thus, you could write <H1><img SRC="logo.gif" ALT="FooBar Company"></H1> and you probably should do so, if the image actually plays the role of an overall page heading (e.g., on FooBar's main page).

johnnie




msg:3848065
 4:23 pm on Feb 12, 2009 (gmt 0)

Isn't CSS 3 supposed to be allowing standardized font embedding? That would solve a lot of these problems, except maybe for bandwidth purists.

alias




msg:3848207
 6:54 pm on Feb 12, 2009 (gmt 0)

CSS3 with its ability to embed custom fonts is the way to go. everything else is just stupid tricks, forcing HTML and CSS to do stuff it's not supposed to do.

but for now those tricks do the job. sadly.

phranque




msg:3848293
 9:06 pm on Feb 12, 2009 (gmt 0)

Let me add that when you are constructing your alt attributes, and they are replacing important text, you should pay very close attention to proper case. It should match the image version exactly.

interesting you should mention that.
the font in the image that started this whole discussion is all upper case.
the "uppercase" letters are "tall" and the "lowercase" letters are "short".
does that semantically imply upper/lower case?

Seb7




msg:3848308
 9:23 pm on Feb 12, 2009 (gmt 0)

This method is currently working really well for me, as the website I use this on holds top position for its niche.

<div id="title"><h1><img src="img/logo.gif" alt="header text"></h1></div>

Also recommend making sure the alt text is very relevant to the image, as I'm hearing rumors that Google takes points off for miss-match alt text.

pageoneresults




msg:3848328
 10:02 pm on Feb 12, 2009 (gmt 0)

CSS3 with its ability to embed custom fonts is the way to go. everything else is just stupid tricks, forcing HTML and CSS to do stuff it's not supposed to do.

I agree and that is why we are in this very deep discussion right now. This particular Image Replacement Technique was an official standard as of 1995 November. ;)

the font in the image that started this whole discussion is all upper case. the "uppercase" letters are "tall" and the "lowercase" letters are "short". does that semantically imply upper/lower case?

Heh! I think that would visually imply SMALL CAPS and I'm not too certain there are any semantics involved there. ;)

It would be nice to have this huh? {text-transform:smallcaps;}

This method is currently working really well for me, as the website I use this on holds top position for its niche. <div id="title"><h1><img src="img/logo.gif" alt="header text"></h1></div>

Whew! Sure glad to see you drop in. :)

Also recommend making sure the alt text is very relevant to the image, as I'm hearing rumors that Google takes points off for miss-match alt text.

Whether they take points off or not should hopefully be of no concern to those participating in this topic. I'm sure all of us are well aware of the importance of the alt attribute. And, even maybe more so now? I know I am.

^ If I were a search engineer, I'd be taking off points for improper element and attribute usage. Yup, I surely would.

phreakin phranque got me digging through documents that have dust an inch thick on them. SEOs don't read this stuff, they really don't! I've decided that I'm not an SEO either. ;)

bedlam




msg:3848343
 10:29 pm on Feb 12, 2009 (gmt 0)

I'll jump back into this later, but I couldn't let this one pass:

It would be nice to have this huh? {text-transform:smallcaps;}

What's wrong with font-variant:small-caps; [w3.org]?*

-- b

*I have no idea how well it's supported, and I don't exactly care: it's always a disaster to let software modify the letterforms of a decent font. Making small caps using font-variant is as good a justification for image replacement as anything I've ever heard :)

pageoneresults




msg:3848893
 5:07 pm on Feb 13, 2009 (gmt 0)

I'll jump back into this later, but I couldn't let this one pass:

I wouldn't have either. :)

And, can you believe I actually used that at one time on a client site. I had to go do some digging but I found it, and it is still live. There are for sure some inherent issues with that smallcaps font variant. It looks nice but there are differences in display (interpretation) between browsers.

Okay, I'm adding another Image Replacement Technique to the long standing list of methods that are out there. I've been testing every day now since phranque posted this topic. My test page has passed every single one of the tests that the others may have failed. I'm still sitting here thinking "what have I missed?". And, until someone comes along and says "Edward, this is why the HTML Method does not work", here we go...

HTML Method using the alt="" Attribute
1995-11-01 - RFC 1866: Hypertext Markup Language - 2.0
[tools.ietf.org...]

"ALT: Text to use in place of the referenced image resource, for example due to processing constraints or user preference."

Do we have any naysayers? And yes, this HTML Method has been around for 13+ years. I'll admit, over the years I'd tend to agree with some of the statements pertaining to the value of the alt attribute. These days my thinking has changed. I've watched too many JAWS and other assistive technology demonstrations to think otherwise. There are some very strict guidelines and protocols for the developers of UAs, applications, browsers, etc.

The W3 is a black hole of information. If you dig deep enough, you will find things that make other things all of sudden "click". In this instance we are talking about "alternative content" which is treated the same.

Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the user.

The user everyone has been trying to appease in this instance is the bot. If the bot cannot see images, then that means the alternative content fulfills the same function upon presentation.

I've used a host of online tools to test this. I can confirm that it is performing as it should from every accessibility checkpoint I've tested.

What have I missed phranque, anyone?

bedlam




msg:3848979
 7:12 pm on Feb 13, 2009 (gmt 0)

We've confounded P1R :)

I want to send smoke signals to the other 9 on the above list and see if we can get them involved too. I want to know why they felt it was necessary to do all this.

What have I missed phranque, anyone?

There are two questions at work in this thread:

  1. Does using an img element and no text (besides the contents of the alt attribute) incur any seo-related penalty? and
  2. Why do people use image-replacement techniques rather than just using the img element?

P1R, with respect to the first question you seem to have empirically confirmed (thanks!) what I'd have guessed: namely that an img with an appropriate alt attribute inside a heading element is interpreted by search engine spiders and assistive devices the same way as text.

The answer to the other question is simple: the point of image replacement is just to take that final step in removing presentation-related graphics to the stylesheet.* Now the necessity of doing this is certainly open to question, but it does make plenty of access-related tasks easier--since the presentational parts of the document are not part of the document, it's possible to offer print stylesheets, high-contrast stylesheets, big print stylesheets, and stylesheets for mobile devices without altering the markup.

Using an img element instead of replacing a text element with a background image or the content property has the significant disadvantage that, though you can style the image out of the markup, when you do so, it's simply absent--there is no alt attribute or anything else to deliver the content. This is, IMO, awfully similar to the criticisms leveled at image replacement.

I agree that the eventual goal must be some kind of method for delivering fonts with documents just as we deliver images, but until that's possible (i.e. widely supported) I still think image replacement is a pretty good option.

-- b

*This assumes that there are cases where one kind of necessity or other (usually a client...) compels us to do whatever we can to render text with an alternate font etc...

pageoneresults




msg:3849043
 8:24 pm on Feb 13, 2009 (gmt 0)

I agree that the eventual goal must be some kind of method for delivering fonts with documents just as we deliver images, but until that's possible (i.e. widely supported)

It looks like this EOT may be something to keep a close eye on. There is even a website devoted to the cause...

Font Embedding
[fontembedding.com...]

Ascender believes that although not perfect, EOT represents the best current solution for type designers and font foundries to protect their Intellectual Property. It is the only web font embedding solution that respects font embedding permissions, uses an industry-proven subsetting and compression mechanism, and ties embedded fonts to specific web sites.

I still think image replacement is a pretty good option.

Okay. I still think no image is really the best option. Just avoid the misinterpretations altogether. If the client is that particular about a font, hopefully they will have educated themselves on the pros and cons of forcing its use in certain media. If they haven't, that's where we come in. :)

Knowing "succinctly" what I do now, I wouldn't give it a second thought. No argument, just use the imagery and the alternative content methods available. The alternative methods take on the same meaning as the element they are wrapped in. It's a pretty simple process. Anything beyond that and my rates go up 100%. ;)

pageoneresults




msg:3849171
 12:51 am on Feb 14, 2009 (gmt 0)

Okay, I think I've found the one inherent flaw with the HTML Method using the alt="" Attribute.

You cannot select the alternative text. That was the one thing that was throwing me off, I couldn't figure out why the alternative text was showing but, it was behaving like an image. So, I would guess this to be a somewhat significant accessibility challenge. Maybe that is what I was missing?

I can use my right click function and go to the Element Properties and there is an Alternate Text label there that I can cut and paste.

phranque




msg:3849330
 9:23 am on Feb 14, 2009 (gmt 0)

i think the accessibility issue with image replacement revealed by swa66 [webmasterworld.com] versus the accessibility issue with alt text described by pageoneresults above are the primary downfall of each technique.

i'm still vacillating but leaning toward the alt only now - neither solution is perfect.

This 31 message thread spans 2 pages: 31 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Accessibility and Usability
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved