- From: Robert Jolly <jolly.robert@gmail.com>
- Date: Thu, 3 Aug 2017 11:37:42 -0400
- To: Brian Stevens <bstevens@ilsworld.com>
- Cc: w3c-wai-ig@w3.org
- Message-ID: <CAPjvVVwzE0H_1zpYQ6ktV=E=D4xKpni6se9ihSRc7JVUcLUgBQ@mail.gmail.com>
Hi Brian, My understanding of this is your approach is OK, as long as it’s it’s understood that the contrast settings are available in the settings panel/modal. It’s good to hear you’re working on a design with good contrast integrated. :) HTH -Robert ----- Robert Jolly Sr. Web Accessibility Strategy Consultant knowbility.org | @knowbility <https://twitter.com/knowbility> *Equal access to technology for people with disabilities* On Aug 3, 2017 at 9:14 AM, Brian Stevens <bstevens@ilsworld.com> wrote: Hello, We need to meet contrast requirements for 1.4.3 - Level AA. My team is considering using a style switcher as a temporary fix. Since our web-app already has a modal settings window (which is contrast compliant), we prefer to place the switcher under our settings. The only problem is, I can’t figure out whether tucking it under settings is allowed. The relevant techniques (G174 and C29) just say that the link or control needs to be “on the page.” Technically the settings window exists on the same page. Is that good enough? Is there some precedent for this? Here are the relevant techniques: G174: Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast <https://www.w3.org/TR/WCAG20-TECHS/G174.html> C29: Using a style switcher to provide a conforming alternate version <https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/C29> Side-note: For the future, we are planning a contrast-compliant redesign, but we need a short-term solution to meet a deadline. Thanks, Brian Stevens
Received on Thursday, 3 August 2017 15:38:08 UTC