High-contrast button: fully accessible or just 1.4.3/1.4.11? #4894
Unanswered
JuliaTol-properaccess
asked this question in
Q&A
Replies: 1 comment
-
|
From a WCAG perspective, if the button had no accessible name and wasn't keyboard operable, it would fail those requirements. So that button is already failing for SR users and keyboard users. Under the EN perspective, while I can see the argument that high contrast implies a sighted user needing high contrast, and therefore only contrast requirements are relevant ... I'd also say that there will be sighted or partially sighted users that need high contrast and also navigate with a keyboard, or use a screen reader even though they have partial sight. It's not necessarily cut and dry. So personally, I'd note that as a failure even for EN. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
As part of an evaluation according to EN 301 549, we need to assess section 5.2. This section says:
“Accessibility features must be accessible to the people they are intended for.”
For example, a high-contrast button should itself have sufficient contrast.
So far, I’ve also been testing this button against 4.1.2 and 2.1.1. If the button had no accessible name and wasn’t operable via keyboard, I evaluated the website as if this button wasn’t there at all. Am I being too strict?
Even though I personally still feel that this button should be accessible to everyone, I also want to stick to what the standard actually requires.
I’m curious about your opinion. How do you handle a high-contrast button?
Beta Was this translation helpful? Give feedback.
All reactions