I have been following the discussion on high contrast mode and background image sprites but I have a more basic question about inline images and HCM. For low-vision users without a screen reader on HCM, will they have difficulty seeing the inline image because it may not have sufficient contrast? Or are they expected to use a browser plugin to replace the inline image with its alt text?
I understand screen reader users will benefit because the alt text is read out? But, what about low vision users without a screen reader?
For low-vision users without a screen reader on HCM, will they have difficulty seeing the inline image because it may not have sufficient contrast?
Sometimes while in High contrast mode the images change as the color is defined, so a white background on an image is turned black. I don't know if this is dependent on the image type or something else. There are a number of disabilities that involve color wash, and it would be pretty hard to cover all bases 100%. I would say it is a good idea to create images with color ratios of 4.5:1 as defined in WCAG 2.0 to cover as many bases as you can.
Or are they expected to use a browser plugin to replace the inline image with its alt text?
I don't know any that do this off hand.
I am going to try to answer my own question: I think low vision users in HCM would turn off images as described here: http://kb.iu.edu/data/acpv.html#ie to show just the alt text and that's why inline images are accessible.
You might be interested in reading Image Sprite Technique Comparison, as there is no single best way. However I will state that assuming HCM users use or do not use images is a bad assumption. The focus should simply be on the technology: if the sprites or images are or become content, then they need to have alternate text. You can't think about them being background and unimportant when in HCM they become actual content that is modified and affects the user's ability to obtain information.
Related
I am using http://achecker.ca to validate my HTML/CSS and verify that I am WCAG 2.0 compliant. I'm quite happy with it for the most part but it is giving me an inappropriate error that is frustrating my efforts to get a clean validation. I was wondering if anyone had a suggestion for getting around that?
It's complaining about the contrast of some text I am displaying, saying that the background color and the text color are too similar. That's actually true - background-color is #f2eecf and text color is #f2f2f2 - but it isn't really relevant because I have a photograph appearing above the background color so there is actually good contrast between the photograph and the text color. Also, I've added a 1 pixel black text-shadow around the text to make it even clearer. Unfortunately, the tool doesn't seem to take the shadow or photograph into account. (It makes sense that it wouldn't know how to handle the photograph since it is not a uniform colour but I'm disappointed that the text shadow doesn't help.)
Is there something I can do to my HTML or CSS to help satisfy the tool? The website doesn't seem to have any way to contact the people operating the website or I would have asked there first.
Should I just ignore the "errors"? Or should I use a different tool? I'm just getting started with WCAG compliance checking - I realize now that I'm rather late getting into this - so maybe there are better tools to use. If so, I would appreciate any recommendation, especially for free tools.
I certainly want my pages to be WCAG compliant but I can't spare money for tools right now.
I have a photograph appearing above the background color
So your text has a transparent background color or it has a background-image? A code snippet would help.
I'm guessing you're getting this error: https://achecker.ca/checker/suggestion.php?id=301
If you look up "achecker.ca" on https://www.whois.net/, you get:
Administrative contact:
Name: Iris Neher
Email: ineher#ocad.ca
If you're using a decent accessibility checker, then you should not try to fake out the checker. I have not used achecker so I can't comment on how accurate it is. But if you post your code example, I might be able to tell if it's really a problem.
You can also try
http://www.brandwood.com/a11y/ - which specifically checks text on images.
https://chrome.google.com/webstore/detail/color-contrast-analyzer/dagdlcijhfbmgkjokkjicnnfimlebcll?hl=en - chrome plugin
Short Answer:
Best practices is that if you are going to composite text over an image, the image is in a container with that container having a background similar to the image.
Longer Answer:
There are a variety of reasons that an image will not load. A site doing things such as placing live text over an image needs to ensure that text remains readable regardless of the load state of the image.
Also keep in mind that a user must be able to zoom up the text in size without breaking the site, meaning keeping the text over the image or BG so it is still readable, etc.
Outlines & Shadows
As for outlines and shadows: while they may assist contrast, they should be used to enhance and not for the sole basis of contrast. In part because the rendering of these properties is far from consistent among different browsers.
Resources
WAVE Automated Checker
APCA Contrast — the new contrast method for WCAG 3
As a web developer, I have to cut a layout similar to this (example website by Ruben Bristian):
Should I bother with cutting multiple small images like a logo:
a label:
and so on? Or should I just make one big background image with all elements like this:
and make a positioned <a href> with display: block; for a linked logo?
A single image has smaller size than multiple elements altogether. What are the other pros and cons?
Use separate images.
Here are a few reasons why:
Maintenance:
It's going to be much easier to maintain in the future, if/when there comes a point when you want to build on what you already have. Furthermore (and subjectively), the background image is not critical to the design. It wouldn't look broken if parts of the background were clipped. It would look broken however, if the logo were distorted.
Bear in mind also that newer, sharper displays are being developed. It's much easier to display the standard resolution background (it's already blurry, so clarity is not essential), and maintain two versions of the logo. One for standard displays, one for HD.
Semantics: What if the user has images disabled? Sure, it's unlikely, but what about Google? You should have some proper markup with real content. Your site needs real textual content in order for Google's crawlers to gather information about it. Use CSS image-replacement techniques to build the interface.
Another note on HD displays:
It's convention to serve larger images to HD (retina) displays, and use CSS to downsize them, effectively increasing their dots-per-inch. If you use just one image, the user will have to download a considerably large image. More bandwidth used by you, and slower experience for your users.
Furthermore, the text will look horrible on HD displays. It makes much more sense to allow the browser to render razor-sharp text to the user.
Accessibility: For a start, screen readers won't have a clue what your site is about. That might not be so relevant in this case, but it's best practice to build and accessible website. If you want to include some smaller text on the site, some users may be unable to read it. Normally they would increase the font-size, but if you use images, they're powerless.
I may have over-dramatised this answer, but the advice is well-intentioned.
I would honestly try a little bit of a different approach. The "photo" part of the image would be one image, the logo another, and maybe the double bar on either side of the heading another (but might not be necessary.
I would use the photo part as a bg image on a div, and within code the rest.
I wouldn't make the text part of the image at all. Try using a service like Google Web Fonts to get a good font.
The approach will save you lots of maintenance time, and also help with performance.
PROS:
Total bytes loaded is lower.
You do not have to worry about how little images are put together to become the total image.
if you just use 1 image you will find that it will be much easier to maintain the fluidity of the layout. You will not have padding/alignment issues, rendering issues, etc. Realistically the load time should be the same either way, maybe a tad longer for multiple images as the browser would have to render more css, but i imagine it would not be very noticable. In the end it really comes down to what is better for the job. I pretty biased towards 1 clean image :)
I guess you have to think about how you are going to use each element individually, and how they are going to change in the future.
You might want to change the logo, animate it, or want to re-use it elsewhere. The background image might change, or become multiple images in some sort of transitional gallery.
If this its never going to change (unlikely), then, yes, flatten it in a single image.
I personally would have as a separate background image. Then perhaps have the logo and the label on another transparent png and utilise css sprites to re-use them throughout the site. This will halve the number of requests required to download the logo/label, and allow you to optimise each image separately ie the complex background photo, and the more simple logo/label.
In other topics I've found that IE/FF doesn't print background images by default. Now that's a shame, because background images add some possibilities that are very difficult to reproduce with classical <img> tags:
You can align them both horizontally and vertically
You can crop them if they are larger than the target element (which also enables the idea of CSS sprites)
Now, it's not impossible to do, but it will require me to have different HTML layouts for printing and normal page, and the printing layout will be quite overcomplicated (since I'll have to use <table>s to achieve vertical alignment). Also, the benefits of CSS sprites will be lost.
Is there any hope? I gather that #media print doesn't help, but isn't there something else, maybe browser-specific, that would allow one to say: "Yes, this isn't a normal background, it really needs to be there even in print view"?
Not possible. You would have to some how convert your background images to img or use Canvas. Of course using canvas depends on which IE you supporting.
Its a browser setting which restricts the printing of background images. I think the logic behind it was that the vendors wanted to give the users the option of printing background images and ensure that the web developer could not alter these settings through some sort of script.
As a general rule, background images should be reserved for adding to the page design but aren't essential to understanding the content. Therefore it shouldn't matter if they are missing when the page is printed. If something (such as a product shot) is important, then it should be included as an actual image (which has the added bonus of being more accessible).
Could you look at including the image, then hiding it using CSS and duplicating is as a background image (perhaps dynamically using JS)? That way, you can ensure the image itself shows in your print stylesheet, and you get the benefits that having a background image brings. I've created a very simple example here.
Is there a method to include CSS background images in print?
If i use image replace techniques for (which is considered as a best practice) Logo then logo doesn't come in print.
and many places in site CSS background is saving bandwidth and my time both. but client is asking to include many things in print also.
And many places where i used background images but now client need background too at some places but on some places not.
What should i do?
Can we do anything with print css?
None of the browsers I'm aware of print backgrounds by default (to save ink/toner). I would also suggest that this is a time when using an image replacement technique is a little overkill -- for a logo the image could appear in the document (and with the relevant alternate text, still accessible)
I have an internal web app with an image at the top of the page, currently containing some english text with drop shadows. I now need to provide localized versions of this page for various languages. My main choices are:
Have a different graphic per supported language, containing the localized text.
Use CSS to position localized text over a plain image, with a complex CSS technique to get drop shadows in most current browsers.
Are there other options? This is for an educational environment, I don't get to control the browser used by the students.
I did try both removing the drop shadows from the graphic, and also moving the text into in a header in the HTML, but neither was appealing. People said it looked like a cheap knockoff of the current page, which wounds my pride.
Personally I'm a big fan of CSS techniques for visual effects like this. The big benefit is that you are offloading the processing of the effect to the client side, saving you bandwith and content creation time (custom text images for each locale is a big order!), and making the page download faster for the user.
The only reason to avoid it is if you absolutely MUST have the drop shadows on very old (IE5) browsers with next to no CSS support.
Edit: Just thought of something - I a few cases like this where I need a specific font or some exact text effect I've used PHP to render the text, with effects, to an image and cache it server side. That way you avoid the content creation process and gain wider browser support in exchange for bandwidth and server CPU time. It's your call if the tradeoff is acceptable.
Generate the images on request server-side for each language, complete with shadows. Cache them as needed.
If you can use Image Magick, you can refer to this tutorial for generating text + shadows...
Maintaining images with text can be a pain - even without localization, I'd avoid it.
Two choices that I would attempt before going with your options are:
Looking for a free program that generates drop-shadow images that you can have your program utilize whenever it detects that new text is available for the title
Using a shadow image that can be repeated as a background image underneath the text
If those don't work, I'd try the CSS, but test it in as many browsers as you can yourself before going live with it.
Well, Safari supports a proprietary CSS property for drop-shadows, but it won't work in other browsers. CSS3 will have drop-shadows, too (actually only one for boxes, but maybe it can be used for text, too, e.g. when the box has a transparent background).
But seeing that most browsers don't even have a 100% CSS2 support so far, I guess you need to go with one of your two options. Of course, there is a not so complex CSS trick to get a drop shadow:
Drop Shadows for Everyone
But they don't look as nice as a real shadow, since they are not blurred. Further you need to have the text twice in the HTML for these to work.