- From: Joshue O Connor - InterAccess <josh@interaccess.ie>
- Date: Wed, 13 Jun 2018 17:41:36 +0100
- To: John Foliot <john.foliot@deque.com>
- CC: David MacDonald <david100@sympatico.ca>, 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: <5B214940.3020101@interaccess.ie>
John Foliot wrote: > Any Mac users familiar with this: https://www.focusingly.net ? Thanks for that John, useful. Josh > > 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 > <mailto: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 <mailto: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 > <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 <http://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 <mailto: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 <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 <mailto:john.foliot@deque.com> > > Advancing the mission of digital accessibility and inclusion > > > > > -- > John Foliot > Principal Accessibility Strategist > Deque Systems Inc. > john.foliot@deque.com <mailto:john.foliot@deque.com> > > Advancing the mission of digital accessibility and inclusion -- Joshue O Connor Director | InterAccess.ie
Received on Wednesday, 13 June 2018 16:42:06 UTC