AGWG Teleconference -- 22 Feb 2022

<sarahhorton> I can scribe

<Rachael> scribe: sarahhorton

Agenda+ New members and topics

<AWK> +AWK

Rachael: New members? Name, where work, short intro

Announcements and Reminders

Rachael: Moving maturity to APA, surveying APA today
... TPAC, hybrid, what do we think? Meet in person?
... chair think yes to in person
... In Vancouver
... would you attend? What factors influence decisions
... will email tomorrow to get feedback

Agenda+ New members and topics

Rachael: announcing in taskforces

WCAG 2.2 Focus appearance (2 questions, 1 new) https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results

Rachael: Just 2.2 today

Focus appearance and User-agents, again

Rachael: continuing from last week

<Rachael> Minutes are at https://www.w3.org/2022/02/15-ag-minutes

Rachael: putting responsibility on authors when should be on user agents

<Rachael> https://github.com/w3c/wcag/pull/2225/files

Rachael: came up with exception, in PR

<Rachael> Exception: The focus indicator is defined by the user-agent and cannot be adjusted by the author.

<Rachael> Draft RESOLUTION: Carry on with the SC with the exception from PR 2225 added.

Rachael: had draft resolution, pick up with today
... two new comments
... reads Wilco's response
... reads Bruce's response
... reads David's response
... anyone else?

<johnkirkwood> David’s response is reasonable.

GreggVan: Same mind as David, so many people making pages don't know CSS, kids, teachers, small business
... no idea can change focus indicator

<jon_avila> This is not asking for JavaScript

GreggVan: browser problem, huge problem but asking authors to add CSS a bit much

<johnkirkwood> agree with last commentor

mbgower__: Updated comment, go ahead but trying to bring in user agent exception

alastairc: Re David's comment, usability testing with general population, unusual for people to know which browser, never mind have CSS

<jon_avila> This idea that authors aren't technical and we shouldn't ask them to change CSS would go for anything like alt text or any WCAG requirements.

alastairc: RE Gregg, authors don't know CSS, using WordPress, could use accessible theme
... browsers have changed, Wilco's point about defining it, then browsers step up and do it

<Rachael> Draft RESOLUTION: Carry on with the SC with the exception from PR 2225 added.

Rachael: Seems to be compromise to create exception and continue with SC

<mbgower__> +1

<Wilco_> -1

<MelanieP> -1

<alastairc> +1

<Rachael> +1

<laura> +1

<bruce_bailey> 0

<jon_avila> +1

<Chuck> +1

<GreggVan> -1 due to need to know css

<GN015> +1

<Azlan> +1

<ShawnT> +1

<Raf> 0

<MarcJohlic> +1

<AWK> -1

<Detlev> not sure

<GreggVan> like the exception -- but it goes too far -- and templates are not always available that do that

<Chuck> I count 10 yes, 4 no

Rachael: Requirement to ask people to use CSS

GreggVan: Likes exception for when can't override, should be that unless you are overriding, it you're changing the browser you need to meet SC, but if you leave browser default don't
... push for setting that people can set

<AWK> having a little phone issues

Rachael: 3 people think exception should be don't alter HTML and CSS, should pass

<Zakim> bruce_bailey, you wanted to ask about MG rewrite -- seems to be on track to solve

bruce_bailey: MGowers proposal might help, exception with careful crafting

<Rachael> https://docs.google.com/document/d/18a4_iDprrXty2Mh4LwNqwKKC7nuklMtNkk0bueFyo9M/edit?usp=sharing

<GreggVan> Mgowers language addresses my concern

<AWK> Sorry, I think that I had my response backwards. I like the exception, so should have put in +1 for that

Chuck: Can we review MG's proposal?

<bruce_bailey> +1 to GreggV idea that exception with modification could be an approach

alastairc: Exception both focus indicator and background, would want exception to apply to overriding focus indicator and background
... key part is background

<AWK> Mike G's approach seems to be on a good path

<Rachael> q

Wilco_: If focus indicator contrasts with itself, background doesn't matter

alastairc: Can hide double one

MelanieP: appreciate Mike Gower's compromise, doesn't satisfy, asking content authors to do what browsers should do
... doesn't help situation for myriad author scenarios

Rachael: Not requiring two-tone focus indicator, talking about default, can hide any, can change among browsers
... everyday user, straights HTML no CSS, makes sense, most people doing that using CMS or other tools
... CSS requires templates to address issue

<Jem> +1 to Rachael's use case such as CMS content author

jon_avila: Address problem where indicator is darkening of background, telling different between unfocused and focused, hard to tell which is focused, would help make more obvious to compare between two things
... e.g., darken background to make look focused

<Jem> +100 to Avila for exemption argument

jon_avila: exempt people, would need to exempt from lots of things, table headers
... arguments are counter to goals

<Zakim> GreggVan, you wanted to say I think Mgowers works if you add "and the focus indicator contrasts the content on both sides of it. this may mean a two color focus

<alastairc> Gregg - should be the same for focus styles, if you have a reasonable 'tool' (template)

GreggVan: Understand, but user doesn't have to mark up table, automatically marked up, no way to create table that's not accessible
... key is focus indicator has contrast with content on both sides, keeps from putting indicator that doesn't contrast with background or button

<Jem> I think AG spec is also about educating people about accessibility, not necessarily about tooling - which right tools people should pick.

GreggVan: in some cases going to be able to see no matter what, in some cases put a gap or make it double ring

Wilco_: user agents can decide what contrast to give focus indicator
... dark light dark, browsers can solve this, haven't done it, we define it and they will get better
... not that common to see focus indicator adjusted on inputs, text areas, yes on highly designed systems, but others use browser settings

MelanieP: difference between exempting default and other examples of other SCs, hold content authors responsible for what they make, not things they didn't author

<Zakim> mbgower__, you wanted to say I support the notion that someone writing correct unadulterated html should not fail wcag

MelanieP: function of user agent

mbgower__: Basic principle, correct HTML, should not have them fail WCAG, cover back door problem, focus indicator and background color are defined by user agent
... not as comprehensive as when overriding link experience, but now lots trying to override focus indicator

<Jem> +100 to chuck

Chuck: All have different experiences, all acting in good faith, make sure we all have respect and understanding, all good

<Zakim> Chuck, you wanted to say that we have different opinions and different experiences, and we may not agree, but we are all acting in good faith

<Zakim> alastairc, you wanted to say that author can do better than UA.

<jon_avila> If people rely on the default then they will generally meet this requirement with some exceptions that we could add in.

alastairc: User agents could do a good job, aren't at moment, are areas with authors do custom things, dropdowns, where difficult for user agent to get right

<Jem> +1 to reality check.

alastairc: uses custom override, runs into issues

<ToddL> +1 to Alastair. I run into the same thing daily during every audit at my job.

alastairc: if we did have exception, if author hasn't overridden, what would be difference in effect
... people who write basic websites, some browsers would fail by default, if we have exception those basic sites would pass

<Zakim> bruce_bailey, you wanted to say that foreground / background might be appropriate threshold

<Rachael> draft language from mbgower: The focus indicator and background color are determined by the user agent and are not modified by the author

bruce_bailey: Let authors write content and not be responsible for presentation, rare to allow authors to select font, etc, let end users pick defaults, moot point now, likes idea, if changing then you have access should be able to write code for it, straightforward

<alastairc> I'd refine to the background of the indicator, rather than any background

<Jem> +1 gn

GN015: Authors capable, authors who are not, those not capable still need to use template/service, not doing themselves, can choose what they use, responsible for choice

<alastairc> Noting that Wordpress (30% of the web?) and Wix have sections for accessible template e.g. https://www.wix.com/accessibility/templates

ToddL: Tailwind CSS, issues in Chrome, Firefox, Safari, different in each browsers with focus indicator

alastairc: different issues in each browser? likely not changing defaults

<Rachael> draft RESOLUTION: Move forward with SC with an exception "draft language from mbgower: The focus indicator and background color are determined by the user agent and are not modified by the author."

<Chuck> +1

<bruce_bailey> +1

<mbgower__> +1

<MelanieP> -1

<ShawnT> +1

<alastairc> +1, would refine to "The focus indicator and its background color"

<jon_avila> +1

<laura> +1

<SuzanneTaylor> +1

<Wilco_> -1

<Detlev> (+1) still sitting on the fence a bit

<AWK> Wasn't Mike G's language more than just the exceptions?

<ToddL> -1

<GreggVan> +1 with addition to the next phrase in MG's

<Jem> +1

<Raf> +1

<Azlan> +1

<Chuck> I count 13 yes and 3 no

<AWK> +1

<Chuck> 14 yes and 3 no

<johnkirkwood> “find move forward with SC” to vague to vote on

<Detlev> what browser default would *not' be black and white?

bruce_bailey: Support principle, taking about bare bones browser defaults, not common web, default presentation, black and white text

<Jem> I see Bruce's point

bruce_bailey: default for every authoring environment

GreggVan: If you play around and make sure there's a contrast, should say needs to contrast with both sides
... add language to second item

<Detlev> Providing a gap seems far too specific

Rachael: For next question

ToddL: On same page with Melanie and Wilco

<Zakim> alastairc, you wanted to say that if the browser default meets the non-excepted text it would still pass.

<johnkirkwood> Same page with Melanie and Wilco as well -JK

alastairc: if exception, people who aren't adjusting are exempt, basic website, browsers styles can meet SC, not sure what problem is

Rachael: Reworded is not meeting need

Wilco_: Browsers have full access to painting/rendering, can ensure focus indicator has sufficient contrast, can invert, detect what works, can do lot to make it work, not doing it, can't hold content authoring responsible

<ToddL> +1 to Wilco

<bruce_bailey> Okay, nevermind my concern for "browser defaults". I just did a test. IE / Edge / Chrome present bare-bones HTML as black-text-on-white background.

<alastairc> (Not q+ing as I think Michael's go it.)

<bruce_bailey> My immediate concern with the phrasing is moot.

<Zakim> mbgower__, you wanted to say yes browsers can do things, but they don't

Rachael: Browsers can do many things we have SCs for, by covering straight HTML and having the details, there are many ways to meet this, struggle with browser can do it so shouldn't have SC for it

mbgower__: Browsers can but they don't exception allows straight HTML not to fail
... but if modify, become responsible
... -1s, puzzled why getting stronger when language is becoming kinder to user agent

<alastairc> +1 to Michael, browsers could, but haven't. (But if they do, great)

MelanieP: Nothing more to add, unless author messes with default, browser function, if mess with it, then yes
... not because of WordPress template they chose

Rachael: New technical point?

<bruce_bailey> @SarahHorton -- i will pick up scribing as soon as this item concludes

<johnkirkwood> can we have the exact text we are voting on in IRC?

<Rachael> draft RESOLUTION: Move forward with SC with an exception in principle of "The focus indicator and its background color are determined by the user agent and are not modified by the author."

<mbgower__> +1

<bruce_bailey> +1

<Chuck> +1

<SuzanneTaylor> +1

<alastairc> +1

<laura> +1

<MelanieP> -1

<ShawnT> +1

Wilco_: Reverts case to PDF, where don't control focus indicator, that problem is now back

<AWK> +1 - this addresses the PDF situation also

<Azlan> +1

<SuzanneTaylor> +1 to Wilco's point, still need the other exception

Wilco_: saying author didn't adjust, before author couldn't adjust

<Rachael> draft RESOLUTION: Move forward with SC with an exception in the principle of "The focus indicator and its background color are determined by the user agent and are not modified by the author." and "The focus indicator is defined by the user-agent and cannot be adjusted by the author."

AWK: If say determined by user agent, focus indicator would adjust

<Jem> I like Rachale

<Jem> 's second draft better.

Rachael: In PDF where can't

AWK: because you can adjust background color, both things wouldn't be true

<Zakim> Chuck, you wanted to ask for a scribe change

<bruce_bailey> scribe: Bruce_Bailey

<Chuck> I will back Bruce up if and when he wishes to contribute

Rachael asks for other technical concerns.

AWK: two are different
... cant verus are not

<Jem> I am confused whether we vote for "can not" or "are not"

<Chuck> that's how I read it

MGower: simpiest for time being is two different exceptions

Rachael: we are talking about both

<Wilco_> This addressed the technical issue I raised

<Rachael> draft RESOLUTION: Move forward with SC with an exception in the principle of "The focus indicator and its background color are determined by the user agent and are not modified by the author." or "The focus indicator is defined by the user-agent and cannot be adjusted by the author."

Rachael: both situations included

<mbgower__> +1

<Chuck> +1

<AWK> +.95 (-.05 deduction for reduced comprehensibility)

<ShawnT> +1

<Jem> +1

<alastairc> +1

<Rachael> +1

<MelanieP> -1

<Azlan> +1

<GreggVan> +1

<SuzanneTaylor> +1

<jon_avila> +1

<laura> +1

<Wilco_> -1

<Francis_Storr> +1

<ToddL> -1

<Chuck> 14 yes (almost), 2 no

GreggV: 2nd seems redundant with 1st

RESOLUTION: Move forward with SC with an exception in the principle of "The focus indicator and its background color are determined by the user agent and are not modified by the author." or "The focus indicator is defined by the user-agent and cannot be adjusted by the author."

Racheal: Intend for final wording is to make two more disticnt

Focus appearance updates

https://docs.google.com/document/d/18a4_iDprrXty2Mh4LwNqwKKC7nuklMtNkk0bueFyo9M/edit

survey summary: 6 agree, 2 update, 2 adjustment

https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results#xq39

Rachael reads David M's comment.

GN from survey: The requirement should also be reflected in the User Agent Guideline, so that the exception for user-agents does not come into action.

Gundula: As I understand this, this more of user agent guidance.

Jon from survey: I generally agree with the updates - but I'm still sure not of the impact of bounding box of content vs. the component.

JA: I am not sure how this works for complex UI

Bruce: ending requirement should be moved up to beginning

Wilco summarized from survey, and: "content of component" needs more consideration

scribe: also timing aspect at end is not clear

<Rachael> https://docs.google.com/document/d/18a4_iDprrXty2Mh4LwNqwKKC7nuklMtNkk0bueFyo9M/edit

MikeG: My rewrite is trying to address concerns previous listed

<Rachael> Issues: Ordering of text, note, bounding box, content of components and timing changes

<Zakim> alastairc, you wanted to explain the bounding box change

alastair: content bounding box is a key change, so we need to talk about that, figure out the size metric we are starting from

MikeG: Yes, i the bounding box size metric is something am trying to address

Alastair: Setting the stage as reminder, component term is oriented to the perception of the end user...
... I had been leading to code-oriented approach as being best objective way to refer to size, but that runs into contridictions...
... one example is just a box with rounded corners which would then be smaller than the html element
... there are other examples on github thread

MikeGower: As a reminder, we started our focus on the target offsets, but that ran into a dead end. We made some progress moving those to exceptions, but it is still not solved...
... one problem is that the thing where focus moved might be large or not even notable to end-user

<jon_avila> Focus indicators don't need to be enclose or bound - the idea is that they can be anything.

MikeGower: so recent drafting is more following pattern from 2.4.7...
... so current re-write might look very different from previous, but requirements are not changed...

by putting the requirements into bullets, we call out everything we are looking for

scribe: then the exceptions call out the situations which are problematic
... Also one requirement is now a NEW sc

GreggV: i like direction, have concern that it allows 1 px border and an assumption that there is unfocused item nearby
... if only difference is 1 px , that is not discernable

<Zakim> alastairc, you wanted to ask about the adjacent case

GreggV: there is need for item with keyboard focus to distinguish on its own without comparison to another item.

Alastair: The 1px border as focus is not sufficient in isolation
... but another concern is that a thick border (just on its own) with current wording is no longer sufficient

GreggV: 20/200 is 10x distance, so if you think 1 px works as stated, step back from your screen.

Wilco: The contrasting background color now needs to do more work. I like the direction, but I think we need more testing.

<alastairc> https://docs.google.com/document/d/18a4_iDprrXty2Mh4LwNqwKKC7nuklMtNkk0bueFyo9M/edit

Rachael proposes straw poll.

<mbgower__> or both :)

<Rachael> straw poll: 1) continue with existing SC wording 2) change over to Mike Gower's proposed approach

<AWK> 2

<mbgower__> 2

<Chuck> 2

<alastairc> 2

<Rachael> 2

<SuzanneTaylor> 2

<Jem> 2

<Detlev> 2

<sarahhorton> 2

<Francis_Storr> 2

<ShawnT> 2

<GN015> 1

<jon_avila> 2 as long as it doesn't derail things

<Ryladog> 2

<ToddL> 2

Gundula: I prefer keep working from current wording as we are getting pretty close, proposed exceptions listing still need work, and it does not seem starting over...

<johnkirkwood> 2

There are common example, like tool bars and drop downs that won't work well with the new approach.

<david-macdonald> ok with 2 wonder regarding loosing the edge case...

Rachael: Other wording has had more time to mature, so stepping away is a risk.

<mbgower__> I was trying to channel my friend and colleague Carolyn MacLeod when presenting this today; trying to better emulate her kind, reasoned approach going forward, as she's no longer with us

Also common solutions might meet rewording -- but they are not suffient

Gundula: The approach for inside focus of the component is not as clear, for example drop-down box

<Zakim> alastairc, you wanted to say we need to check there is reasonable equivelence with the exception

Alastair: We did consider inside focus, so that is shifting a little.

<david-macdonald> "... and its background color are determined by the user agent" ... I'm guessing that means it would have to be offset...

Alastair: We have some unresolved details, like drop-shadow, very thin elements, one other

<Wilco_> yes, content box

Alastair: I have concerns for timing, so want to come back.
... WRT timing, we started off "when it receives focus" as kicking off the condition...
... that lead to partially obscured content, with one moving around the screen. On the other hand, if the end-user is moving a pallet around ...
... that is obscuring thing with focus, but would not be expected to be a barrier.
... so the focus of the SC moved to when the focus was recieved

Wilco: I still have concern that some approaches which seem reasonable, like the new Chrome keyboard focus indicator, lead to a requirement for persistence.

<Jem> https://github.com/w3c/wcag/pull/2223

We have browsers others moving in the correct direction, but do not seem to be providing them encouragment.

<AWK> -1 to Mike's change - I think that this has been clarified in the U doc.

MikeGower: Agree we want to solid warning, but I am not sure we have concurrance.

<AWK> Prefer to have language that is aligned with other SC whenever possible

<jon_avila> +1 David

DavidMacDonald: The Chrome option is good, and adds to focus visible, but I am not sure it enough for what this new SC is trying achieve.

<Jem> +1 to David

<alastairc> "The focus indicator must not be time limited, when the keyboard focus is shown it must remain."

<jon_avila> +1 to Gregg

Alastair: I am hearing concern for persistence with the focus indicator. But we might remember that between 2.0 and 2.1 we added persistence to Understanding because it was not in mind for 2.4.7.

<Ryladog> Maybe "....must remain persistent during focus"

<jon_avila> +1 to Gregg

GreggV: Our requirements must assume that in the context of low vision, the end user is always looking away...
... Takes so much time to re-orient, and can be so time consuming. Every use of tab key can be like a new page...

It is timed content and a fading keyboard focus would not be good enough for 2.4.7.

<alastairc> suggested resolution: "We do not wish to prevent or discourage additional options, but for focus-appearance there should be a baseline of a persistent indicator."

Chuck: Seems like turning this setting on might fail 2.4.7 when page passed without the accessibility feature?

<jon_avila> Not all people with low vision use magnification.

Rachael: Framing is that feature is in addition to default behavior, so conformance with 2.4.7 is not effected.

<jon_avila> Moving indicators are problematic for people with motion sensitivity.

Wilco: As a person with low vision, I have found this Chrome feature to be extremely beneficial. Not having the fade effect would make the feature less useful to me.

<Zakim> mbgower__, you wanted to say this shouldn't curtail against animation or fading focus indicators

<Zakim> alastairc, you wanted to say that we're specifying a baseline, not an ideal.

Katie: I do have concern for how this overlaps with our SC which address animation timings.

Alastair: This is baseline, so we are not trying to require that authors have huge default indicators. It is not a heavy lift. 1px min is still under discussion,
... but this SC requirement is compatible with the Chrome feature.

<Rachael> Options 1) Change to "When a user interface component has keyboard focus" 2) Do not change the language but include persistent focus in the understanding document 3) Allow a fading focus indicator in this SC (while acknowledging other SC do not support it)

GreggV: One of the new data points is that we now know we have people with low vision resisting AT of any sort, built into browser or not, so they are just putting nose to screen.

JonA: Agree that we need to consider 2.4.7 implying persistence via Understanding.

Rachael invites discussion on draft proposed straw poll.

GreggV: Just a reminder that Understanding is not normative.

AWK: Disagree slightly, as Understanding is authoritative. Best informative resources.

GreggV: But Understanding should not add new requirement.

<AWK> Agree that U Doc doesn't add new reqs

<Rachael> Options 1) Change to "When a user interface component has keyboard focus" 2) Do not change the SC language but include persistent focus in the understanding document 3) Allow a fading focus indicator in this SC (while acknowledging other SC do not support it in their understanding)

Alastair: The conversation about persistence included many other situations, such as the page being resized. Persistent is not that different from other assumptions.

DavidM: Is the discussion of implied assumptions correct to have here?

<Ryladog> +1

DavidM: We have requirement *when* focus -- but want keyboard focus to stay

<Chuck> bruce: When, if we put persistence into this sc, I have concern that this means it's not in 2.4.7

<AWK> +1 to Bruce

<jon_avila> persistent language needs to take into account the user has scrolled out of view or obstructed it

Bruce: If persistance in new SC, then implication is NOT is other SC.

<Rachael> Options 1) Change to "When a user interface component has keyboard focus", add persistence to the SC language 2) Allow a fading focus indicator in this SC (while acknowledging other SC do not support it in their understanding)

Alastair: Question with this SC is not really about persistence, so drop one because persistence is not really under debate.

AWK: asks for clarification , one adds one prohibits

<alastairc> "When user interface components receive keyboard focus,"

AWK: MikeGower proposal is "when keyboard focus is visible"

<Rachael> Options 1) "When a user interface component has keyboard focus" 2) "When user interface components receive keyboard focus" 3) "When the keyboard focus indicator is visible,"

Alastair: So that relies on 2.4.7 being passed.

<GreggVan> 1

<Wilco_> 3

<AWK> 3

<Ryladog> 3

<Rachael> 1

<SuzanneTaylor> 3

<alastairc> 1, ok with 3

<sarahhorton> 1

<jon_avila> 1 or 3

<david-macdonald> either 1 or 3

<GN015> 1

<mbgower__> 3 then 1 (can live with either).

<Chuck> 3, ok with 1

<OliverK> 1

<MelanieP> 3

<ShawnT> 3

<ToddL> 3

<Detlev> can live with 1 or 3

<StefanS> 1

Rachael: with the conversation here, 3 seems the most support
... not voting, but MikeGower will keep working

<jon_avila> unless the user has scrolled it out of view or the user obstructs it.

DavidM: paraphrases, chairs agree

<Chuck> +1 as a separate sc

<Rachael> straw poll: Explore content obscured as its own SC

<SuzanneTaylor> +1 to separate - they are separate issues

<alastairc> And everyone is welcome to discuss this on Friday...

MikeGower: asks about 2nd sc for not obsured

<Ryladog> +1

<Detlev> not sure

<ToddL> +1 as separate issue

<mbgower__> +1

<Wilco_> +1

<GreggVan> +1 for separate

<OliverK> +1

<StefanS> +1

<ShawnT> +1

<alastairc> +1. although I might change my mind if it becomes a nightmare!

<jon_avila> +1 to explore

<david-macdonald> +1 for simplifying this one with separate SC

<MelanieP> +1

<laura> +1

<Rachael> https://www.w3.org/TR/WCAG22/#focus-visible

GreggV has question about tie to "indicator visible"

<david-macdonald> i think 2.4.7

<mbgower__> it is not explicitly covered in normative language, IMO. But 2.4.7 has wording about it

Yes, we are relying on Focus Visible per 2.4.7 phrasing

- DRAFT -

AGWG Teleconference

22 Feb 2022

Attendees

Contents

Agenda+ New members and topics

Announcements and Reminders

Agenda+ New members and topics

WCAG 2.2 Focus appearance (2 questions, 1 new) https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results

Focus appearance and User-agents, again

Focus appearance updates

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output