- From: Jonathan Avila <jon.avila@levelaccess.com>
- Date: Wed, 16 Jan 2019 16:39:01 +0000
- To: Chuck Adams <charles.adams@oracle.com>, Detlev Fischer <detlev.fischer@testkreis.de>, Alastair Campbell <acampbell@nomensa.com>
- CC: "WCAG list (w3c-wai-gl@w3.org)" <w3c-wai-gl@w3.org>
- Message-ID: <DM6PR03MB4281AD18AD1EA6FC0F0CE53AF1820@DM6PR03MB4281.namprd03.prod.outlook.com>
Hi Chuck, what we are trying to say is that the minimum can be calculated by skipping over the decorative/superfluous artifacts if the identifying factors continue to exist when contrast is provided by other adjacent points/outline, etc. So it’s more about skipping over the decorative part when making the comparison rather than just exempting decorative content (which is already done). Jonathan From: Chuck Adams [mailto:charles.adams@oracle.com] Sent: Wednesday, January 16, 2019 10:55 AM To: Detlev Fischer; Alastair Campbell Cc: WCAG list (w3c-wai-gl@w3.org) Subject: RE: Color contrast principle How about… When an object or component contains differences in color which are decorative, do not convey information, and do not alter the functionality of the object, color contrast minimums are not required for the different colors within that object or component. The converse statement would also be true: When an object or component contains differences in color which are not decorative, do convey information, or alter the functionality of the object, color contrast minimums are required for the different colors within that object or component. Regards, Charles Adams From: Detlev Fischer <detlev.fischer@testkreis.de> Sent: Wednesday, January 16, 2019 1:39 AM To: Alastair Campbell <acampbell@nomensa.com> Cc: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org> Subject: Re: Color contrast principle I think that is fine, and it is important to allow cases where (thin) outlines can be disregarded if the colours they separate have enough contrast between them. It might be necessary to define the upper limit of the line thickness though, in some way, not sure how (3 or 4 CSS pixels? Could appear arbitrary.) Sent from phone Am 16.01.2019 um 01:04 schrieb Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>: Hi everyone, There was some confusion on the call about the second example under the “Adjacent colors” heading here: https://cdn.staticaly.com/gh/w3c/wcag/non-text-contrast-updates/understanding/21/non-text-contrast.html?x=5<https://urldefense.proofpoint.com/v2/url?u=https-3A__cdn.staticaly.com_gh_w3c_wcag_non-2Dtext-2Dcontrast-2Dupdates_understanding_21_non-2Dtext-2Dcontrast.html-3Fx-3D5&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=b-9TIC95K-nLEKIDibNXAN_FKV-iXhLlAW2Zc3ebV_c&m=gHYPoD56iagWi01xHZqz3JFGixNtZ3T4aGndEZe8J4I&s=MY09SdOgx5dMebVZN95V7Xgg6D48fTNm1J7ZU-hsb2s&e=> <image002.jpg> The aim was to show a general principle of measuring adjacent colours, perhaps it needs some adjustment? The principle is that: If there is a non-contrasting colour between two contrasting ones, assume that it merges with the non-contrasting colour, then does it pass? In that case, assume the silver border merges into the blue background, so it is essentially white vs dark blue. This is important because it meets the user-need and allows for many more design possibilities. (Designs that would fail the SC without causing an impact on people.) Without that, it would essentially mean two-colour only controls. There is a similar principle going on for the radio-button example (selected / not-selected) further down. <image005.jpg> All of those pass, but the middle two demonstrate the principle that if the middle contrasts with the outside, we can ignore the outer circle of the radio – it is a change of shape. If anyone can think of a better explanation for the understanding doc… I’m all ears! Kind regards, -Alastair -- www.nomensa.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.nomensa.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=b-9TIC95K-nLEKIDibNXAN_FKV-iXhLlAW2Zc3ebV_c&m=gHYPoD56iagWi01xHZqz3JFGixNtZ3T4aGndEZe8J4I&s=7kJLiAWYode8CSBBDbvAZ5eNDtz_4YZe_GWrTLW6aTc&e=> / @alastc
Received on Wednesday, 16 January 2019 16:39:27 UTC