- From: Wilco Fiers <wilco.fiers@deque.com>
- Date: Thu, 17 Feb 2022 10:41:36 +0100
- To: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, Alastair Campbell <acampbell@nomensa.com>
- Message-ID: <CAHVyjGPyxyfLBmXaMYKMb62OYWJW+J3wMe=6POKzwPehZTs2YQ@mail.gmail.com>
Meant to send this to the list: ---------- Forwarded message --------- From: Wilco Fiers <wilco.fiers@deque.com> Date: Wed, Feb 16, 2022 at 9:37 PM Subject: Re: Focus appearance To: Alastair Campbell <acampbell@nomensa.com> Hey Alastair, > Q1. User agents I'm workshopping proposed wording with Mike and Melanie on a separate thread. Will come back to this. > Q2. Suggested update for understandability I'm not opposed to the change, but I did think it worth noting it creates a fairly significant loop hole in adjacent contrast. I actually stumbled into a real-world example yesterday of this. Chrome's default focus indicator on default text inputs fails the wording of the current SC, but passes if we used Andrew's proposed wording. It has a 2px default focus indicator, with an offset of -1, which results in 1px of that indicator overlapping with the border, and only 1px sticking outside. That still leaves sufficient area for it to pass, but the effective change there is that a 1px grey border turns into a 2px blue border. I don't think that should pass, but am happy to go with the consensus of the group. > Q 3. Update to 'component' language take 2 I'm hesitant about using content. If we're serious about that direction, I think we have a lot of exploration of possible side effects to consider. For example on a card with an image, is that image content? Does it matter if that image is an <img> element or CSS background? I'm concerned if we're going this route we're going to need to define "content". I don't think this direction makes things any easier. > Q4. Time limited focus indicators I've asked and will continue to ask for evidence that a fading focus indicator is a substantial accessibility problem. Unfortunately, because of the way web standards have evolved I think it's a fair assumption that browsers will never be able to solve this with a permanent focus indicator. The best they can do, and I applaud them for having put in the work, is a focus indicator that fades out after some period of time to avoid permanently obscuring other content. If we're going to categorically reject that solution, we can't do that based on speculation. We should know to what extent a fading focus impacts someone's ability to using a page. We should know how the timing of that fade impacts that. We should know if it's impacted by whether or not magnification software follows / attempts to keep focus centered on the screen. ---- Lastly I want to request this issue be added to the WCAG 2.2 discussion: https://github.com/w3c/wcag/issues/2206 Whether or not user agents can, even in theory, solve for focus appearance with an accessibility option I think is important for this conversation. On Wed, Feb 16, 2022 at 12:01 PM Alastair Campbell <acampbell@nomensa.com> wrote: > Hi everyone, > > > > I’d like to make a bit of progress between meetings on this, based on the > survey I think we can come to a solid proposal for questions 2-4 on the > last survey. > > > https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results > > > > If you have a comment which I’ve tried to address your name should be > below. I’d appreciate it if you could scan for that and review the > rounded-up PR at the bottom. > > > > > > *Q1. User agents* > > > > Although that discussion is not resolved, it seemed reasonable to at least > add an exception for when the user-agent does not permit styling of the > component. > > > > > > *Q2. **Suggested update for understandability* > > > > This was Andrew’s overhaul for understandability in this PR: > > https://github.com/w3c/wcag/pull/2182 > > > > Most people agreed, except Wilco and I thought the “Adjacent contrast” > bullet had changed the scope slightly and would be better as it was > previously (just updating the term for the contrasting area). > > > > > > *Q **3. Update to 'component' language take 2* > > > > The conversation on this has moved on a lot in this thread, with > contributions from MichaelG, PatrickL and others (not on this email list): > > https://github.com/w3c/wcag/issues/2226 > > > > The new proposal is to keep the scope to User Interface Components, but > set the minimum size as a bounding box around the *content* of the > control, i.e. the text or icon. See > https://github.com/w3c/wcag/issues/2226#issuecomment-1040731857 > > for that specific update. > > > > That should help with the survey comments from Gundula, Wilco, MichaelG & > Bruce. However, the method of taking that size is new and might take a > little thought to analyse. Also, the new note could do with some refinement. > > > > > > *Q4. Time limited focus indicators* > > > > The scoping we had done to allow for focused items to be partially > obscured had opened up a loophole for fading indicators. There is a PR to > move that aspect to only apply to the ‘obscured’ clause. > > > > LawranceL: Patrick’s update was added. > > > > Bruce: We can’t move that into a bullet as the scope is different (the > focus indicator vs the item in focus). I tried to apply that here: > https://github.com/w3c/wcag/pull/2223#issuecomment-1041348009 > > However, IMHO that shifted the focus too much and made the intro very > long, I haven’t included that in the overall PR (yet, maybe someone can > think of a better way). > > > > > > *Overall PR* > > > > I’ve tried to wrap all of the above into one new version: > > https://github.com/w3c/wcag/pull/2230/files > > > > If rawgit is working (I get an error at the moment) that should appear > like here: > > > https://raw.githack.com/w3c/wcag/focus-appearance-content-term/understanding/22/focus-appearance-minimum.html > > NB: It doesn’t show the links to definitions there, but none are new > definitions. Also, the understanding document will need an overhaul if the > SC proposal is agreed. > > > > Kind regards, > > > > -Alastair > > > > -- > > > > @alastc / www.nomensa.com > -- *Wilco Fiers* Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force -- *Wilco Fiers* Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force
Attachments
- image/gif attachment: deque_logo_180p.gif
- image/gif attachment: 02-deque_logo_180p.gif
Received on Thursday, 17 February 2022 09:50:22 UTC