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).
Related
I've been working on a few websites that have beautiful color palettes but do not provide high enough contrast between text and background for accessibility. I love to make sites usable for everyone, but as a designer, I feel bummed that so many awesome color combinations are totally off the table. Would providing an obvious way to toggle into a high contrast mode be an acceptable alternative?
Lots of users would benefit from a high-contrast color scheme, including many who don't regard themselves as disabled. You can certainly let yourself off-the-hook, legally speaking by providing a WCAG compliant color scheme alongside whatever awesome swatch you prefer. I would advise starting with the WCAG-compliant one first, and make it the default, so you always have that as a base to fall back on.
You could even use the forced-colors media query, although this is not yet standard. There are a few other related media queries offered by Microsoft, as mentioned here
https://blogs.windows.com/msedgedev/2020/09/17/styling-for-windows-high-contrast-with-new-standards-for-forced-colors/
But before you start working on a new color scheme, it will be more worth checking how your 'regular' site looks like with some of the system-level contrast mode settings enabled. These are available on most platforms, and there are a number of browser extensions which also manipulate color/contrast (each works slightly differently).
Please note that it's perfectly possible to make the UI unusable using system level "high contrast" features with 'extreme' settings. Mac OS's contrast slider can almost bleach out the entire screen if pushed to the edge! I can't help wondering who this is supposed to benefit.
WCAG does not require that content should be perceivable within the broad limits of every single high contrast gadget on the market, so in general, if these kinds of problem only occur when the gadget is enabled, they are not (strictly) WCAG violations.
However, given that the success criteria "Focus Visible", "Text Contrast" and "Non-Text Contrast" are already met, any contrast "failures" which only occur when High Contrast gadgets are enabled are usually best understood as possible violations of SC 1.3.1 Info and Relationships, because they do not "ensure that information and relationships that are implied by visual formatting are preserved when the presentation format changes". You might also have some violations of SC 1.4.1 Use of Color if any distinctions are made by color alone. (e.g. if all headings are the same font and size as body text, but in red).
Therefore the important thing is to try your content with some of the default schemes in (say) Windows High Contrast Mode. Check that everything is still distinguishable, especially including focus indicators and UI states (e.g. text labels, disabled controls, checkboxes and radiobuttons, thumbs on sliders and scrollbars, data views etc.). It will probably not be very beautiful, but that's not the point. Again, it's not a WCAG violation if you don't offer perfection in Windows High Contrast Mode, although you should probably mention any howlers in any Accessibility Conformance Report or VPAT.
As a small tip, I will mention that Windows High Contrast Mode will try to color-code UI borders to reflect certain states. (e.g. a button with a disabled attribute might be drawn with a green border). Therefore: Make sure your UI controls have borders of at least 1px. If you don't want a visible border in the regular scheme, use a transparent color. Similarly, make sure any non-decorative SVG content uses some kind of stroke to be distinguishable in Windows HCM.
That way, if someone enables HCM, the boundaries of content, and also the state of the controls will still be perceivable.
I've been learning to code for some time and I've sure learned quite a lot, but styling has always been a pain in the ass for me (it's very embarrassing, I know). I absolutely have no idea how many pixels a nav bar should have or how wide any component should be. If it's just too small/big for me, I'll resize it. Size units? No idea. Don't get me wrong. Percentages, ems and metrics - I'm aware of its existence and what they do, but I do everything in pixels. I'm not saying that things I code look horrendous and not responsive. It's all try and error until things look aesthetically pleasing and it takes me so much time to make things look pretty.
Let's say I need to make something simple like a popup modal in CSS. I might wrap the hidden content in a div, with a class of modal, its content in a div with a class of modal__content, make a button to close it and some text in it. Semantically correct HTML is not a problem. Animations and colours? Fine, you got it. I just have no clue how to style it. That's when I realise I know CSS just in theory. I can code it, but I just have no idea if the modal should be 300x200 px box for a desktop screen or maybe use percentages?
If you have some saved articles or a book you could recommend, I'd be very very grateful.
I've used Bootstrap and Semantic UI. These are very cool and convenient tools, but I wish to know some in-depth guidelines when it comes sizing since I don't really know what something should actually look like. Most of the time I'm just eyeballing all font sizes, paddings and margins etc.
I'm not a good at graphic design either. Few people excel in both graphic design and in programming/scripting.
SitePoint has some books worth reading on the subject, the first especially (each available in paperback and as an ebook):
The Principles of Beautiful Web Design, 3rd Edition
Sexy Web Design
The Universal Principles of Design is likely to cover topics such as those you're asking about, although I haven't read it.
Graphic design relies a lot on convention (which is usually a good thing), fads (less so), and the preferences of the designer and client. However, there are various guidelines that are important to know. I'll mention a few here.
Large or bolder type, motion (videos and other animations), and contrasting borders and backgrounds draw the eye. Be careful not to give such visual emphasis to too many elements at the same time. (This is a common problem for home pages of organizations that many factions competing to highlight the thing most important to them.)
Adjacency implies relationships. For example, it's typically better to give headings, e.g. <h2>, a larger top margin than bottom margin.
Elements tend to need a comfortable amount of space between them without using too much screen space. When large spaces between content sections are desired, it's usually best to scale them down for mobile devices.
Animations serve multiple purposes. There are the various pulse/"throbber" animations to indicate that content is being loaded or some other kind of processing is taking place. There are transitions that show a non-instantaneous change between states, e.g. a menu opening/closing or change is views of a content/image slider. While others are mostly for aesthetic reasons, to add visual interest.
I'm glad you mentioned semantics. Do you use <label> elements where appropriate?
P.S. Too many people who call themselves "web designers" don't know, or refuse to acknowledge, the differences between graphic design for the Web and for print.
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
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.
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;
}