Is it good enough that all text+background combinations pass the level AA contrast guidelines in their default states (i.e. contrast ratio of 4.5:1)?
We have some links and buttons where the background changes opacity on hover/focus and this then doesn't pass the contrast check. Can anyone confirm if that's a problem or if it's acceptable so long as the default state passes?
It's a major problem.
If WCAG requires you to have a contrast of 4.5:1 between background and text color, it obviously applies to focused links which are the very first thing a user will want to read when tabbing around a web page.
Related
WCAG 2.1 introduced success criterium 1.4.11 Non-text Contrast for UI components like checkboxes, sliders etc.
Would it be safe to ignore 1.4.11 for the background-colour within a button, as long as the text inside has sufficient contrast as well to the button as required by 1.4.3 Contrast, as to the surrounding background colour?
Somebody who couldn’t perceive the button shape due to the low contrast, they would at least perceive the text within – just as with a text-only button.
And text-only buttons exist in several widely used design systems. As the text is the only thing left visible, and text needs a higher contrast than UI components, it automatically suffices for 1.4.11 as well.
Now, I’m not only wondering for the practical implications, but also for an audit. Do you know sites that passed audits with such buttons, or with text-only buttons?
Short answer, most likely you're ok.
Your interpretation is how I conduct my audits. If the button's background color does not have sufficient contrast compared to the page background color (or whatever color happens to be "adjacent" to the button background color) (1.4.11), then if the text within the button has sufficient contrast with the button background (1.4.3), then the user still has enough contrast to know where to "click". It's nice to know where the edge of the UI component is but it's not always necessary to know where it is in order to interact with the element.
The key is:
(1.4.11) Visual information required to identify user interface components
So if I can't tell where the edge of the button is, can I still "identify" where the button is? If there's sufficient text-to-background contrast (1.4.3), then "yes", so 1.4.11 doesn't fail.
Now, a lot of WCAG can be subjective and you might find an auditor that fails the button with 1.4.11 but just because one person says it fails (or another says it doesn't fail), doesn't mean that that person's interpretation matches with yours.
You might disagree with the auditor and that's ok, as long as you can back up your interpretation.
Do you know sites that passed audits with such buttons, or with text-only buttons?
Yes, I pass sites all the time based on my interpretation of this success criterion but I often give a "best practice" that the button edge should be distinguishable but note that it doesn't technically fail.
For ADA compliance I've read we should have more than one effect on hover. For example, only changing the color wouldn't be good enough for someone who is color blind, so adding an underline would help them.
Does the cursor change count towards one of the hover effect? I tried searching for that in a few different sites but I wasn't able to find the answer. Does anybody know?
Another example: would a hover effect which adds an underline and changes the cursor to the pointer be compliant on any of the WCAG levels (A, AA, AAA)?
For ADA compliance I've read we should have more than one effect on hover
I'd be interested to know where you read that. WCAG, the official accessibility guideline, doesn't really say anything about hover effects. It does say, in 1.4.11, that "states" must have sufficient contrast, and hover is an example of a state, so in that respect, WCAG does address the hover effect. But nothing in WCAG requires a hover effect.
Now, if you're talking about WCAG 1.4.1 Use of Color, there is a recommendation specific to anchor tags (<a>) that if a link is embedded in a paragraph, the link color must have at least a 3:1 contrast ratio with the paragraph color and an additional visual cue must be specified upon hover or focus, such as an underline. You can see the full text in G183.
So it's tough to answer the question about a cursor hover effect until I fully understand what you're trying to do and which sources you're using for your information.
A best practice is that any hover effect you implement should also be available upon focus too. This is typically done in CSS by having the :hover and :focus point to the same rules in the CSS.
After a decade long hiatus I am dipping my toes into web development again. It still seems a very confusing heap of constantly changing standards to me, making it unclear which browsers support what and what the best practices are.
Currently, I am focusing on using the new semantic elements of HTML5. I found out the ASP.NET Core default Bootstrap template does not use the <nav> element for the navigation bar and was therefore looking into how to apply it properly.
The default navbar template in Bootstrap does recommend to use <nav>. However, I am confused as to what the purpose is behind the aria-expanded attribute applied to it. After learning about the benefits it offers to screen readers (indicating whether the navigation bar is collapsed or not, in this instance when the screen size is small, i.e., for smartphones), I am still confused as to whether it should be there at all. (And whether or not aria-controls should be applied, which it isn't in the default bootstrap template.)
Let me explain:
Some of these aria attributes seem to be describing visual behavior. Does it even make sense to describe something to the non-sighted which they can not see?
With the <nav> and <main> semantic elements applied correctly, don't the screen readers have all the necessary information at hand already to quickly skip the navigation bar (equivalent of hiding it for the sighted)?
Wouldn't a better alternative be to just hide the navigation toggle mechanism to the non-sighted altogether? Here my question then would be, how to go about this. Can a button be hidden using role="presentation" and/or aria-hidden="true"?
Using the example you cite at https://getbootstrap.com/examples/navbar/, it needs aria-expanded.
In the larger viewport, the "dropdown" menu hides all the sub-items. They are not only hidden visually, but hidden to screen readers as well. The aria-expanded helps give the user context whether or not there is more available, and also gives some clue about where the subsequent tab-stops may take the user.
In the narrower viewport, where the navigation becomes a hamburger, this still applies. Doubly so since it also applies to the hamburger itself.
This context is important since aria-controls support is poop (to quote Heydon).
There are cases where every item in a menu is available via tabbing, even if visually not there. In that case aria-expanded is not so important, but aria-controls would have more value.
Separately, that menu needs better :focus highlighting for sighted keyboard users, and DOM sequence for the menu versus logo in the narrow viewport (through that is my opinion).
Some of these aria attributes seem to be describing visual behavior. Does it even make sense to describe something to the non-sighted which they can not see?
That question should be the first to appear in any ARIA tutorial.
With the <nav> and <main> semantic elements applied correctly, don't the screen readers have all the necessary information at hand already to quickly skip the navigation bar (equivalent of hiding it for the sighted)?
And this one the second.
Edit: When I read those questions, I thought "that guy has already understood everything". ARIA tutorials rarely answer those questions because they are context dependent, but asking those questions must be the first step before using ARIA. Eg. image carousels are for blind people a very different user experience. Giving an aria-controls attribute to the "previous" button does not give more intelligence to a system based on visual effects. ARIA is not a miraculous panacea.
ARIA may be seen as a kind of magic potion for people wanting to make accessible something which is not accessible. In many cases it will be used ill-advisedly.
The aria-expanded can give a good user experience for screenreaders, informing whether or not an element can be opened to show more elements (for instance inside a dropdown menu).
You can't apply the aria-expanded directly on a nav element because it has to be set on an interactive element (like a button) to inform that this controls the visibility of another element inside the same container (which can be a nav).
The better alternative I can see is not hiding anything to also help people not using screenreaders. Instead of collapsing a navigation bar at small screen resolutions, it's perfectly possible to:
always show it
display a persistent menu icon to jump to the menu bar (or temporarily displaying it inside the viewport)
This has the benefit to enable the possibility to scroll to the menu bar (for people not understanding what that icon with three parallel lines may indicate) and let screenreaders users list all the internal links.
Of course, things are very different if you conceive a web application rather than a simple web site, and ARIA might be more useful in that context.
Are there any best practices or guidelines regarding contrast between link colour on a webpage, and the regular text?
I know there are contrast guidelines that refer to text vs background colour, but I'm also wondering if there are guidelines about the minimum colour difference that should exist between plain text, and link text.
For example, my background is white (FFF), my text colour is black (000) and my link colour is green (007C41)
Edit:
I realize it's up to personal preference to some degree. However, while my eyes may be able to tell the difference between #000000 and #000001 (they can't, but just for argument's sake), other's won't be able to. What I'm wondering is if there are any accessibility guidelines regarding what the minimum colour difference should be.
The only guidelines I was ever taught about links is this:
Make it obvious that it is a link. Do not do anything that might trick a user to click on something they didn't want to click on.
Make it obvious that it is different than the other texts on the page because you do not want your users to miss out on a link they might have wanted to click on.
Years ago, I was taught that all links should be underlined. Obviously, many, including our beloved SO, do not do that. Many now favor that links are underlined only when hovered over.
Basic guidelines from the US Department of Health & Human Services
http://www.w3.org/TR/WCAG-TECHS/G183.html (courtesy of steveax)
Make sure you have a color blindness emulator plugin for your browser. Inability to distinguish variations in hue is a semi-common condition. What looks "different" to you might not be obvious with a certain type(s) of color blindness.
Once you've addressed color blindness, ensure that colors with popular meaning (red, yellow, green) are used in appropriate or neutral contexts. For example, a "Sign me up!" link probably shouldn't be red (danger, critical) unless it's very clear that it is part of a theme (e.g. all links are red). A "Delete" link probably should never be green.
It's worth being familiar with proper color compliments. Even if you have made a highly readable, usable site, people react differently to different colors. Some colors/color combinations simply "look" better than others, and often there is a simple mathematical reason.
There are a couple of guidelines that combine to cover that scenario:
Color is not used as the only visual means of conveying information,
indicating an action, prompting a response, or distinguishing a
visual element.
Contrast (Minimum): The visual presentation of text
and images of text has a contrast ratio of at least 4.5:1
A good article on webaim explains that:
So if you combine these two requirements, in order to be Level AA conformant, your page must have all of the following:
4.5:1 contrast between the non-link text color and the background.
4.5:1 contrast between the link text color and the background.
3:1 contrast between the link text color and the surrounding non-link text color.
In other words, your link color has to be significantly different from the background color AND the surrounding text color, which also has to be significantly different from the background colour.
Overall, the easiest thing is to use more than colour, e.g. an underline, outline, or bold text, in which case you only have to worry about contrast compared to the background, not the surrounding text.
Most important considerations have been covered above. In addition to those considerations, I lean away from underlining (except on hover) because I like the option of using underline to convey emphasis or other contextual information.
Our self-proclaimed Usability Guru Nielsen at one time loudly exclaimed that all links shalt be underlined forever no matter what, and a lot of people who prefer to be told instead of do the thinking themselves gobbled that up. But most reasonable designers understand that such rules are nonsense.
I'm having trouble understanding the WCAG 2.0 criteria 1.4.8.
From what I understand it basically says that if I have for example a <div> that I define both background and text color in, I will have to either:
Provide a color picker tool for that div so that the user can change those colors
"G156: Using a technology that has commonly-available user agents that can change the foreground and background of blocks of text"
Providing a color picker sounds pretty far fetched, so I'm placing my hopes on "G156". Does a regular web browser (ie,firefox,opera etc.) qualify as such an user agent?
Another confusing part is the "common failure" where it says "F24: Failure of Success Criterion 1.4.3, 1.4.6 and 1.4.8 due to specifying foreground colors without specifying background colors or vice versa", which I sort of interpret as "as long as you specify both background and text color for that div, your safe".
Any thoughts on how to interpret this WCAG criteria?
Does a regular web browser (ie,firefox,opera etc.) qualify as such an user agent?
According to http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/G156, it seems so. It says:
Tests
Procedure
Open the Web page in a browser that allows users to change colors of
HTML content.
Change the foreground and background colors in the browser
settings so they are different than
those specified in the content.
Return to the page and check that that the new specified foreground text
and background colors in the browser
override the colors specified in the
content.
Expected Results
Check #3 is true.
"as long as you specify both background and text color for that div, you're safe"
I think so. It means don't just assume the background is white, because if you don't explicitly specify it, it might not be.