The fact that you don't know whether the user has images enabled or not is a real problem with image replacement. You can't hide the existing text if images are disabled as the user will just end up with nothing, the standard way to handle this problem is to keep the text visible and have an image bigger than the text and place the image over the text, if the user doesn't have images they will still see the text. This is only ok if your replacing a header where the image is bigger than the text, but no good for any small images like icons where the text is always going to be bigger.
One way round this is to only add images if your sure the user has images enabled and to keep the text in the HTML flow for screen reader users.
One way of testing for images is to use JavaScript and set a class name on the HTML element if image are enabled/supported, then you can apply styles based on the existence of this class name, using this technique you'll only do image replacement if the user has JavaScript, CSS and Images enabled which is a good thing. If the user doesn't have any of these three you probably don't want to mess with the UI at all.
See the image replacement test page for some uses.
Showing posts with label accessibility. Show all posts
Showing posts with label accessibility. Show all posts
Wednesday, 16 December 2009
Sunday, 8 March 2009
Icons and image replacment
Generally speaking i'm not a fan of image replacement, but for inline icons it seems to work a treat. We had this issue that users with screen readers where struggling with our icons that we use liberally in our pages. For example, the "More information" icons that we use on some links to indicate that there is more detailed information available, looks something like this.


Although this looks quite reasonable it was causing problems for screen readers as they list out all images which means the user will get a list of images all saying "More information" (so a bit like having a list of links all saying "Read more..."). This is a problem with using images as text (an icon is really short hand text) if you look at them out of context they don't make sense.
Using image replacement as a way of hiding images from screen readers works quite well, as they are background images and not img tags. If we look at the same link using image replacement...

I tend to use nested spans for image replacment, you may prefer to use a single span with a combination of overflow hidden and a text-indent value, depends what browser support your after. If you don't need backwards compatibility you could just use the CSS "content" property instead.
Although this looks quite reasonable it was causing problems for screen readers as they list out all images which means the user will get a list of images all saying "More information" (so a bit like having a list of links all saying "Read more..."). This is a problem with using images as text (an icon is really short hand text) if you look at them out of context they don't make sense.
Using image replacement as a way of hiding images from screen readers works quite well, as they are background images and not img tags. If we look at the same link using image replacement...
I tend to use nested spans for image replacment, you may prefer to use a single span with a combination of overflow hidden and a text-indent value, depends what browser support your after. If you don't need backwards compatibility you could just use the CSS "content" property instead.
Friday, 27 February 2009
Is the NoScript tag the tag of the devil?
I came to the realisation today that the noscript tag is the sporn of the devil. It encourages developers to think of JavaScript in black and white, it's either on or off, the users support it or they don't. Unfortunately this simplistic approach can leave your users frustrated and thinking your site is broken. Consider this over heard conversation...
Project manager:
"Why doesn't the site work on my Blackberry?"Developer:
"We don't support the Blackberry"Project manager:
"but I thought you said it works without CSS and JavaScript?"Developer:
"yes it works fine without CSS and JavaScript, we've built it in semantic HTML"Project manager:
"so it should work on anything that understands HTML?"Developer:
"... yes ..."Project manager:
"so why doesn't it work on the Blackberry??"Developer: ".... err ....
The NoScript tag has struck, pretty much all user agents support JavaScript. Much better to use progressive enhancement instead.
Consider this:
<noscript>
<p>
Important information for users without JavaScript
</p>
</noscript>
<script type="text/javascript">
if (document.getElementById){
// do funky things
...
}
</script>
We have just created a crack down the back of the sofa which has swallowed every user-agent that supports javascript but doesn't support document.getElementById or doesn't get the JavaScript in the first place. These users don't get the JavaScript enhancement and they don't get the noscript fallback : (
Saturday, 21 February 2009
JavaScript support, who does, who doesn't?
JavaScript or lack of is a thorny issue, but if we take a quick look at some of the user groups that this effects:
1: User agents that don't have JavaScript enabled. As a lot of user tracking software relies on JavaScript to work so it's hard to tell how many users actually don't have JS, but in the beginning of 2009 it could be about 6%. Made up of user-agents that don't support JS, user-agents that have it turned off as part of company policy and user-agents routed though a proxy (e.g. public proxies normally don't support JavaScript)
2: User-agent that you haven't tested your JavaScript on. Just because a user-agent supports JavaScript doesn't mean your script will work (ever done this: if (!document.getElementById){return} ? ), even the four (webkit/moz/opera/ie) main desktop browsers diverge radically in some areas, meaning that there is a good chance that you scripts may not work on anything you haven't tested them on.
3: User-agents where your script is meaningless. e.g. if the user is using a small screen (or zoom software) and they click on a DHTML link that moves some page content from out of view left (eg. margin-left:-9999px) to out of view right (e.g. margin-left:800px;). In these cases JavaScript is no help to the user.
4: Assistive technologies: Most assistive technologies like screen-readers run on the top of your normal browser so although the browser understands JavaScript the assistive technology may not. They may not see things you have written in with JavaScript rendering your JavaScript content inaccessible.
There are probably other user groups effected, will add when they come to mind...
So our user groups fall in to a number of categories...
1. users with browsers that don't support JavaScript at all, or have JavaScript turned off
2. users with browsers can't run your scripts (they error or don't support DOM)
3. users accessing your site though anal proxy, firewall etc...
4. users for whom your JavaScript is redundant (not really any help)
5. users for whom your JavaScript is actively blocking access to content
1: User agents that don't have JavaScript enabled. As a lot of user tracking software relies on JavaScript to work so it's hard to tell how many users actually don't have JS, but in the beginning of 2009 it could be about 6%. Made up of user-agents that don't support JS, user-agents that have it turned off as part of company policy and user-agents routed though a proxy (e.g. public proxies normally don't support JavaScript)
2: User-agent that you haven't tested your JavaScript on. Just because a user-agent supports JavaScript doesn't mean your script will work (ever done this: if (!document.getElementById){return} ? ), even the four (webkit/moz/opera/ie) main desktop browsers diverge radically in some areas, meaning that there is a good chance that you scripts may not work on anything you haven't tested them on.
3: User-agents where your script is meaningless. e.g. if the user is using a small screen (or zoom software) and they click on a DHTML link that moves some page content from out of view left (eg. margin-left:-9999px) to out of view right (e.g. margin-left:800px;). In these cases JavaScript is no help to the user.
4: Assistive technologies: Most assistive technologies like screen-readers run on the top of your normal browser so although the browser understands JavaScript the assistive technology may not. They may not see things you have written in with JavaScript rendering your JavaScript content inaccessible.
There are probably other user groups effected, will add when they come to mind...
So our user groups fall in to a number of categories...
1. users with browsers that don't support JavaScript at all, or have JavaScript turned off
2. users with browsers can't run your scripts (they error or don't support DOM)
3. users accessing your site though anal proxy, firewall etc...
4. users for whom your JavaScript is redundant (not really any help)
5. users for whom your JavaScript is actively blocking access to content
Labels:
accessibility,
HTML,
interface development,
javascript,
UI
Subscribe to:
Posts (Atom)