- From: John Foliot <john.foliot@deque.com>
- Date: Wed, 13 Jun 2018 09:00:40 -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: <CAKdCpxx=072mPp0_bHnOWU8DFaOVZ56M7ABxNrv9aOPoZH-LiA@mail.gmail.com>
Any Mac users familiar with this: https://www.focusingly.net ? I wonder aloud if it addresses the problem we're discussing (Mac's inaccessible native focus ring). JF On Wed, Jun 13, 2018 at 8:50 AM, John Foliot <john.foliot@deque.com> wrote: > 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 > -- 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 14:01:11 UTC