- From: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Date: Fri, 15 Apr 2016 20:58:25 +0000
- To: Detlev Fischer <detlev.fischer@testkreis.de>, "akirkpat@adobe.com" <akirkpat@adobe.com>, "gregg@raisingthefloor.org" <gregg@raisingthefloor.org>
- CC: "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
Detlev, > AND to the default state: While I agree with the sentiment I'm not sure that is covered by the current WCAG and this decision -- that is the focus and hover states need to have sufficient contrast but I don't think this decision is making any claims to a comparison between the luminosity differences between the default and hover/focus states. Since there can be other things that indicate focus and hover including under and borders as you point out that would allow it to sufficiently differentiated. Thank you for listing the useful practices as IMO this will help authors meet this requirement. Jonathan -----Original Message----- From: Detlev Fischer [mailto:detlev.fischer@testkreis.de] Sent: Friday, April 15, 2016 4:40 AM To: akirkpat@adobe.com; gregg@raisingthefloor.org Cc: w3c-wai-gl@w3.org Subject: Re: CfC: Issue 157 - note on contrast arithmetics Just one note on the difficulty of finding text colours for focus / hover states that both have a contrast of > 4,5:1 to the background AND to the default state: There are other options to clearly indicate focus that should (and I guess, would) be taken into accout in any practical conformance check of web content: - invert foreground/background colours on focus / hover - change both background and foreground colour to a value pair that has the required offset to the respective values of the default state AND meets text-to-background contrast - there should be thousands value pairs that can meet this requirement - use CSS to draw a outline with sufficient contrast around linked text or other interactive elements - use CSS to change text style to text-decoration: underline Provided that the default contrast is OK, any of these options would meet SC 1.4.3. Note that usually these changes should be relatively easy to make to existing sites (just changes to CSS). I support the CfC for issue 157 due to the reasons outlined by the LVTF and think the exception for content released before the date of the change of the understanding document would be a good solution to address Gregg's concern. Detlev -- Detlev Fischer testkreis c/o feld.wald.wiese Thedestr. 2, 22767 Hamburg Mobil +49 (0)157 57 57 57 45 Fax +49 (0)40 439 10 68-5 http://www.testkreis.de Beratung, Tests und Schulungen für barrierefreie Websites Gregg Vanderheiden schrieb am 14.04.2016 20:11: > Hi All, > > > it is still before the deadline - but I see this item was called. > > > l will post my concern anyway. > > > I am sorry to have to say - but I disagree with this answer / response. > > > It is my understanding — (and a general operating principle in standards) that the Working group cannot change the interpretation of a standard after the issuing of the standard. The understanding at the time the standard was passed, and the understanding released publicly and on which the public interpreted and commented on the standard, and the interpretation of the working group when it reached consensus on the provision must prevail. > > > From the discussion - it appears that it is the understanding that the Working Group meant it to mean one thing — and the new Working Group is deciding to change the meaning. This would constitute a re-interpretation of the standard — in a normative way — after adoption. > > > The interpretation of the standard at the time it was passed must stand as long as the provision stands. > > > Changing the interpretation - when it was clearly stated - is equivalent to normatively changing the standard after the fact. > > > The working group should always strive to interpret the standard as they believe the working group understood the standard at the time consensus was reached by the working group. > > > This is independent of whether this is a good idea or not. > > > ———————————————— > > > Now separate from that - -one should keep in mind - that this interpretation also conflicts with the conformance criteria which allow things to take different forms and only need to meet the guidelines in one form. For example a page can have one viewing option that is does not meet the success criteria as long as there is another viewing option that does. > > > Finally, due to the math - you cannot have two colors that both meet the SC at 7 and are still appreciably different from each other in contrast with the page. > > > I think that for future work (revisions) both of these issues should be taken into account before deciding. They were among the reasons the Working Group decided as it did last time. > > > However, with respect to WCAG 2., both of these latter are irrelevant if the group really believes that the WG meant it one way — and they are deciding to differ and are redefining the normative term (or its interpretation) after the fact. That is not really really appropriate to do without issuing a new standard because it is in effect making a normative change to a standing standard. > > > If I misunderstood something — let me know. (or if you disagree - I am happy to discuss whether I am right.) but I THINK that this is outside of the WG purview for the reasons above. > > > respectfully > > > gregg > > >> On Apr 12, 2016, at 6:43 PM, Andrew Kirkpatrick <akirkpat@adobe.com <mailto:akirkpat@adobe.com> > wrote: >> >> >> CALL FOR CONSENSUS – ends Thursday April 14 at 12:45pm Boston time. >> >> >> GitHub issue 157 related to the need for the focus and hover states to meet WCAG contrast requirements was discussed on the April 12 WCAG teleconference and surveyed to the group (https://www.w3.org/2002/09/wbs/35422/5April2016_misc/results#xi157 <https://www.w3.org/2002/09/wbs/35422/5April2016_misc/results#xi157> ). >> >> >> Proposed response: >> >> >> https://github.com/w3c/wcag/issues/157#issuecomment-208996348 <https://github.com/w3c/wcag/issues/157#issuecomment-208996348> >> >> >> If you have concerns about this proposed consensus position that have not been discussed already and feel that those concerns result in you “not being able to live with” this position, please let the group know before the CfC deadline. >> >> >> Thanks, >> >> AWK >> >> >> Andrew Kirkpatrick >> >> Group Product Manager, Accessibility and Standards >> >> Adobe >> >> >> akirkpat@adobe.com <mailto:akirkpat@adobe.com> >> >> http://twitter.com/awkawk <http://twitter.com/awkawk> >> >>
Received on Friday, 15 April 2016 20:58:57 UTC