- From: John Foliot <john.foliot@deque.com>
- Date: Wed, 13 Jun 2018 08:50:38 -0500
- To: David MacDonald <david100@sympatico.ca>
- Cc: Alastair Campbell <acampbell@nomensa.com>, WCAG group <w3c-wai-gl@w3.org>, LVTF - low-vision-a11y <public-low-vision-a11y-tf@w3.org>
- Message-ID: <CAKdCpxxo_0DS5Oo0a=9bdAcY_RffneDvpikXagJAL-vJ0zHY6A@mail.gmail.com>
David's bug thread also provides the current 'status': michael-n-cooper <https://github.com/michael-n-cooper> commented on Sep 28, 2017 <https://github.com/w3c/wcag21/issues/298#issuecomment-332865121> This is out of scope for WCAG 2.1, but we will look at this sort of issue again in Silver. To my mind there are differences between technical compliance and "practical" compliance, and while it is true that you can wiggle you way out of the Mac problem using a technical reading of WCAG (David's point), I suspect that for most designers (who are likely using Macs anyway) that we should teach them the 'optimum' and down-play the minimum (i.e., be pragmatic, fix the problem on the Mac platform - Alastair's point). I think framed right, designers are going to want to do this right anyway (most designers I've met want to control all aspects of the design, on all platforms), and we can re-enforce the idea that different platforms have different focus indicators in the Understanding document, and that designers *should* carefully consider this fact when creating new designs/focus indications. JF On Wed, Jun 13, 2018 at 8:28 AM, David MacDonald <david100@sympatico.ca> wrote: > > I’m a little confused in what you mean, the technologies relied on in > this case would be HTML, CSS etc. > > The technology relied upon in WCAG is the tools that users are expected to > use to get the benefits of the WCAG conformance. There is no obligation to > make things work in every browser with every screen reader and AT... There > just has to be on stack of technology i.e. Windows, Firefox, NVDA. We're > not talking a about HTML/CSS here we are talking about the expectations for > a user. One must remember that for most of WCAG Apple was a non starter. > There was no assistive technology and no initiative by apple to do anything > about that, and back then is was basically JAWS, Windows and IE ... so of > course we couldn't say that so Conformance requires just one combination of > user technologies work. If we change that in WCAG 2.1 (and we haven't) we > are talking about a completely different set of requirements than WCAG 2.0 > in 2.1. > > This stuff is important. > > > I’m probably biased by the UK/EU context where these things are > generally interpreted in fairly practical ways, it would be odd to exclude > a popular browser or platform and claim that it works. > > Hmmm.... when was the last lawsuit that had any effect in the UK? > > We simply cannot require content to work on all or many combinations. I > raised an issue to explore that an the WG decided to stick with WCAG 2.0 > conformance requirements. > > https://github.com/w3c/wcag21/issues/298 > > This is critical, and I simply won't be able to provide consensus to this > interpretation without a wider discussion of its implications. It is at > odds with our own documentation for 2.1. > > Cheers, > David MacDonald > > > > *Can**Adapt* *Solutions Inc.* > > Tel: 613.235.4902 > > LinkedIn > <http://www.linkedin.com/in/davidmacdonald100> > > twitter.com/davidmacd > > GitHub <https://github.com/DavidMacDonald> > > www.Can-Adapt.com <http://www.can-adapt.com/> > > > > * Adapting the web to all users* > * Including those with disabilities* > > If you are not the intended recipient, please review our privacy policy > <http://www.davidmacd.com/disclaimer.html> > > On Wed, Jun 13, 2018 at 8:34 AM, Alastair Campbell <acampbell@nomensa.com> > wrote: > >> Hi David, >> >> >> >> Thanks for looking through, on your points: >> >> >> >> > The #1 statement has 2 bullets. Is the proposal that these are an AND >> statement or and OR statement, we need that explicit, its a big difference. >> >> >> >> It is an and/or, i.e. you could use any combination of text, graphical >> content, background/border etc. >> >> >> >> If you look at the first assumption, I put: >> >> For "Visual information required to identify user interface components >> and states", it is flexible as to what the indicator(s) is/are, the author >> can decide. However, if the indicator is "required to identify" the >> component, then it must have contrast. The main differences are that: >> >> - Buttons and links can be identified simply by text; >> - For controls which are more interactive (e.g. checkboxes / radio >> buttons) that would require more than text. >> >> >> >> Perhaps that first step needs splitting up to distinguish the types of >> control, and incorporate that assumption? >> >> >> >> >> >> > For the last #4 item... this will be an undue burden to test and >> remediate, with disproportionally few benefits to the end user ... WCAG has >> not traditionally wandered beyond the default and focused state, these are >> split second states. >> >> … >> >> > Instead, I think we should say that momentary transient states are not >> visible/noticeable to many people and therefore out of scope. >> >> >> >> I’m not sure how to square that with the SC text & definition of states, >> we’ve already been through that conversation with hover. >> >> >> >> However, the mitigations are that: >> >> - A change of pointer can count as an indicator (for hover); >> - If a control doesn’t visually change for a particular state, it is >> not required to (because there is no visual information). >> - Most components don’t have that many states. >> >> >> >> In the examples most of that failed did so due to default indicators or >> focus state, not the other states. >> >> >> >> >> >> > On the call I mentioned that Technologies relied upon for conformance >> is a critical consideration when failing/passing default states. If Safari >> is not relied upon for conformance, then it is not a failure of WCAG that >> it's focus ring doesn't pass. If there is a stack that works, it passes. >> >> https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html >> >> >> >> I’m a little confused in what you mean, the technologies relied on in >> this case would be HTML, CSS etc. There is also the aspect of what you >> claim to have tested on, in the ‘Optional components of a conformance >> claim’, but I’m not sure what you’d interpret as “If there is a stack >> that works, it passes”? >> >> >> >> I’m probably biased by the UK/EU context where these things are generally >> interpreted in fairly practical ways, it would be odd to exclude a popular >> browser or platform and claim that it works. >> >> >> >> -Alastair >> > > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion
Received on Wednesday, 13 June 2018 13:51:07 UTC