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
Related
I am working on a site that gradually changes opacity on page text from 0 at the bottom of the viewer to fully visible by the time the user scroll has positioned the text mid-view. The text is able to be read by a screen reader. It also would meet contrast requirements once it reaches full opacity. Can anyone tell me if this violates WCAG 2.0 standards?
Sincerely, this is a very good question.
There is visible text on screen which is not readable and this requires the user to scroll in order to give it full opacity.
From a "visually" point of view, this is not choking. Despite that you are reducing vertical readable area, as long as you can zoom up to 200%, and still read upper lines, this might be acceptable depending on the size of the occulted area from a WCAG view...
The fact that this text is readable by a screenreader is a good point among a lot of accessibility considerations.
If you consider some visual or mental disabilities, this might be hard to understand. For instance, an old person with a glaucoma can not perceive that the effect of gradual change of opacity is not something caused by the disease. Requiring the text they read to be at the centre of the screen is not something evident. Do we move a book from up to down each time we read a line of it?
This also requires more scrolling, so it will ask more physical efforts to read. One click is not very much effort for many people, but clicking on the small arrow of a scrollbar is fairly hard for the elder generation (not everyone uses keyboard).
TL;DR: This might be considered valid from a WCAG point of view, but this does not help ergonomics
I think that this would violate the Contrast (1.4.3) criterion on the WCAG 2.0. Your text provides sighted users with a visual cue that color-blind users may not be able to see. It's possible that the text may be unperceivable to color-blind users until the minimum contrast requirement is reached.
The only exceptions to the color contrast criterion are if your text is incidental (i.e. decorative or invisible to users in general). I don't think this text could be considered incidental, however, since it sounds like it is the body content of the page and it remains (at least to some degree) visible to fully sighted users without requiring them to scroll through the content.
Trying to make my app WCAG complaint. There are a few places where text is displayed on the screen but not meant to be read by users. One is when an offer is not eligible, we show the offer but lower the contrast to denote the offer can not be made. The other is we show case numbers at the bottom of the app. These are captured by users in screen shots when they report bugs, and used by support to track the issue, but not meant to be read by users.
Is there any way to denote that these fields are not meant to be read by the user and therefore do not need to meet WCAG contrast ratios?
Let me rephrase your question...
How to markup a purely decorative text in order to make it compliant with WCAG?
WCAG does not have the notion of purely decorative text, as it might be subject to abuse.
At less, you have to consider using aria-hidden in order for the text not to be read by screen readers.
The difficult part of that is : how might a visitor understand that a text is not intended to be read? Is the assumption that a non readable text, with poor contrast, is something you have to ignore is really helping readability? No.
That being said, if you just want to fool automated tools, you have many possibilities like playing with transparency, replacing HTML portion with img canvas after load, etc. But this won't help accessibility, nor readability.
You're trying to convey one information ("do not read that") using only color difference, which is clearly targeted by the G182 technique : Ensuring that additional visual cues are available when text color differences are used to convey information.
It is a better solution to find a matching color to preserve the minimum contrast ratio for a given color (easy way : try black or white).
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.
It seems like there is an increasingly popular trend to style hyperlinks in a color that's barely distinguishable from body text. I noticed this just the other day on an SFGate blog page. Also notice that link just a few words ago. Are my eyes getting worse, or is that hard to spot?
I certainly understand styling hyperlinks to look better than browser default styles. But, if they're not easy to see, what's the point of having them in the first place?
My best guess is that designers (or whomever makes the styling decisions) are wary of interrupting eye tracking with colors or other styling that is significantly different than the body text. That would make some sense, but I feel that there's a lot more room for compromise - i.e., styling links to be different enough from the body text that they're easy to spot, while not making them so flashy that they attract the eye to the detriment of easy reading.
Would anyone make the argument that subtle hyperlinks are more effective than more obvious ones? Or, can you point me to any theories or testing conclusions that may justify their use?
#Mike Daniels: Thanks for clarifying that the color I'm having trouble differentiating on this site is the visited link color - I hadn't noticed that, but you're right. The unvisited link color is rather prominent, and it makes more sense to me that visited links would blend in more with the surrounding text.
On another note, I'm not sure that I buy the argument that a hover color/effect is enough to properly distinguish a hyperlink. I don't feel that it serves the cause of usability that a user should have to hover over a link to confirm that it is in fact clickable. I think that should be made obvious at a glance.
I actually have a very good IPS-panel monitor and near-perfect vision with my glasses on. I can see the visited links on this page and those on the SFGate blog if I scan for them, but my argument is that it would only take an underline, a different color, or another visual distinction to make the links stand out much more.
What I'm really wondering is why - assuming that the designer(s) on a high-traffic site like SFGate know what they're doing and have made conscious decisions about link colors - they would choose to style the links to resemble the body text so closely? Is there reasoning behind that?
I can see the reasoning behind not wanting to have hyperlink styles which strongly clash with the regular text, as they can be distracting while reading. But I think that's rarely a problem. If you look at a site like Wikipedia, the links are very visually distinct from regular text, but it doesn't at all make the text harder to read
So the only real reason to only subtly differentiate inline links from standard text is for aesthetic purposes. I think that's what the SFGate designer has done. The link colors they use are easily differentiable when they are not inline (e.g. the Recent Entries or Categories panes), but they are perhaps harder to pick out in the text.
Since they've already carefully chosen a good color scheme that works aesthetically, and you generally don't want to employ too many different colors in a design or use different-colored links in different places, there's not a lot of options. They could have:
bolded the links
underlined them
used dotted underlines (a nice compromise)
or use rollovers
All of which would help to differentiate links from text without needing to give the links a brighter color.
But you also have to take into account the type of page it is and the usage pattern of visitors. If you have a lot of inline links, or if users are mainly there to read an article, not follow embedded links, then you don't want the links to draw so much attention. The SFGate blog is more akin to a digital newspaper. It's not a standard news blog where links are the primary content, or Wikipedia, where the embedded links are also a major focus of the site. Basically, the few links in the blog posts are only there to provide a little supplementary info for the curious but are expected to be ignored by most readers. And they do stand out enough so that while reading the article, you will see the links as you come across them.
The main navbar is readable , and the sub-navbar is normal text with a while background giving the main navbar visual hierarchy. The page is actually alright.
It depends on what you're trying to accomplish. As a site owner, I might realize (via A/B testing) that a subtler link color increases CTR, reduces bounce rate, etc. .
I do, however, think that differentiating your links only by color might cause some problems for colorblind folks.
ok, in SO the visited hyperlink colour is a bit darker and is harder to distinguish from the unvisited hyperlink colour. But I think inline hyperlink design is a tough question to answer. I mean you want someone to know the hyperlink is there but at the same time, is it more or less important than your content? if its the ultimate destination then maybe making it stand out more (i.e. by underlining it) if its evidence for a point and therefore less important that someone clicks it theres no need. I'd argue a simple colour change would do, maybe make the visited/unvisited links a closer match so that they maintain their visibility in the content.
I didn't realize until Mike Daniels pointed it out that your issue is with visited links, not normally-colored links. Visited links have traditionally blended in more, it's not really a new concept. I think the theory is if you've already visited the link you must know it's there, so there's no reason to draw your attention to it anymore; there are other links you haven't visited yet that you're likely more interested in
I can clearly distinguish the link color from the text color. Maybe you should adjust your display settings? I suppose it could be a bit bolder to distinguish it from the surrounding text, but it's ballpark.
It would be nice if the SFGate blog page page used the hover property to provide another visual cue that the thing that I think is a link is actually a link.
Could be one of 2 scenarios, both of which I have experienced.
the design agency isn't web savvy and thinks that different coloured texts and (worse) underlines are unsightly and has asked the designer to make the links visibly uniform (you'd be surprised how often I get asked to do this).
the text has been SEO'd incorrectly by someone who's about 6 years behind the times and believes that you have to link every instance of a term on a page but with a consideration for the visitor, so they've been styled down.
I'm curious if, similar to something Chesterfield said above, someone is under the delusion that they should link lots of stuff on the page in order to improve their search engine rankings. And, because of that, they thought the page might look less ugly if they toned down the coloring of links so that they're more to game Google than for end users.
I'd be curious to see some stats for the number of links per article for under-emphasized links versus articles where the links are clear. Obviously it wouldn't be 100% scientific, but it might lead to more clarity on the issue.
maybe this could be a nice soloution
a {
font: inherit !imporant;
text-decoration: inherit !imporant;
color: inherit !imporant;
}
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.