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.
Related
I am creating a rating component , and wanted to add accessibility feature to it. What all aria-attributes has to be added? What are the tab navigation required?
i.e how it should behave on right/left arrow click or click on other keys?
There is probably no unique definitive answer to this question. You may design your component rather differently, depending on the exact desired behavior.
Is your rating component read only ? Can the user rate only once for all or change his mind at any time ?
When the user sets or changes a rating, is it taken into account immediately or does he have to click an OK/save button ?
Are three of the few questions that may change things.
For example, probably the simplest:
you may view your component as a serie of radio buttons labelled 1, 2, 3, ... 10.
If you use true radio buttons <input type="radio"/> with accompagning labels, you have very little to do to make your component accessible.
A bit harder, you may see your component as being a slider. IN this case it's going to be more difficult because you will probably need to use some ARIA.
Refer to W3C authoring practice for implementing it correctly.
This was for a component allowing input. Now if your component is read only or become read only once the user has given a rating, remember that, after all, a rating is just a ratio between two numbers, the rate obtained and the maximum possible rate.
How fancy you present the result to the normal user has finally little importance as long as you give the two numbers in text somewhere, e.g. "4/5" or "4 starts out of 5" in a place and in a form where it can be read as is. The rest is pure optional decoration.
However, if you really don't want to give the numbers in clear somewhere, you are going to fail. For example, color blind won't see if it's green or red, screen readers users won't figure out the size or number of bars, etc.
I can well understand the willing to hide exact numbers for many reasons, but it's a bad idea for accessibility.
I have a component which presents an x/y axis plane and a nub that users can move around within the plane. Some aspects of accessibility here seem pretty straight forward: the nub should be focusable; keyboard up/down/left/right should move the nub by some interval to increment the x/y values in the appropriate directions. Even with a secondary text input, these behaviors for the widget-proper may be helpful regardless of whether users are employing assistive technology.
But when I began investigating how I should mark this up aria-wise, I wasn’t sure what the appropriate role/roles should be, or what the best way to communicate the available functionality is.
The closest match for a role appeared to be "slider":
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_slider_role
However the slider role as described on MDN seems like it may be specific to single-axis sliders.
A slider is effectively 1D only, so it isn't the appropriate role.
To convaince of this, read the description of slider in ARIA 1.1.
http://www.w3.org/TR/wai-aria-1.1/
Nothing in the description mentions that you may use something else than simple numerical values, comparison between values should be unique and total (for 2D points it is not), and it also reads the following:
Elements with the role slider have an implicit aria-orientation value of horizontal
It's horizontal; it may certainly be vertical; but definitely not both at the same time.
By the way, by default, Jaws for example announce more or less this for a slider: "left right slider. Use left and right arrow keys to adjust the value" which is wrong for your case.
IF you were in a discrete plane, I would have suggested grid/row/gridcell. But since you are selecting coordinates in a continuous plane (or almost),
your case is special / unconventional, hance there doesn't exist a predefined ARIA recipe you can apply.
IN such a case where there is no really adequate role, tehe best play is probably to not indicate any role at all for your component.
An assistive technology will therefore not confuse the user by telling him what your control is not really, nor by giving him wrong indications on how to use it. No indications at all is probably better than wrong ones.
You must of course still use aria-label/aria-labelledby to give your component a label, make it focusable and keyboard usable.
You should also ideally compensate the absence of predefined role by giving precise keyboard usage instructions. For this, keep it rahter short in aria-describedby (which might be read each time the control is focused), and if needed / if the control is quite complex, explain it longer somewhere else with plain text.
IF it's really too complex, you are also allowed to give up, as long as you provide an acceptable alternate input mean giving equal possibilities. For a color chooser, enter RGB value or #XXXXXX code would certainly be acceptable and sufficient alternate input means.
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.
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.