<alastairc> https://www.w3.org/WAI/GL/wiki/Scribe_List#2020_Scribe_History
<Fazio> AC: WCAG 3 CFC closed objections being addressed
<Fazio> prepresent+
<Fazio> 9 issues for Focus Appearance
<AWK> +AWK
<Fazio> AC: some updated text but adjacent contrast still outstanding
<Fazio> AC: keep 3rd bullet or no? Not needed if relying on text contrast?
<bruce_bailey> regrets for most today's meeting, appologies i need to drop off at 11:30
<Fazio> AAC: 5 agree 1 with update 1 something else
<Fazio> AC: A lot of DM's comments were covered in discussion, buildup...
<Fazio> D McD: 3rd bullet ramifications are too high when compared with benefit. Developer would need really in depth knowledge of entire site... Very burdensome
<Jennie> *Is anyone else concerned that Alastair's display in Zoom indicates it is 3/11/2020?
<alastairc> Non-US dates, the right way to do it ;-)
<Fazio> D McD: talking about multiple disabilities, low vision plus manual dexterity impairment, complicates issue
<Jennie> *Thank you! Felt like being back at the beginning of all this
<Fazio> D McD: most sighted keyboard users can use mouse when stuck.
<Fazio> D McD: big direction change
<Fazio> Glenda +1's D McD
<Fazio> AC: low vision TF discussion finds keyboard focus useful on inputs and buttons
<AWK> Another +1 to DM's comments
<Glenda> Melanie P (who is only on the phone) added a +1 to what David M said.
<Fazio> AC: light or dark background not necessarily issue for designers. Thick border/outline dependent on color scheme. Component construction pretty straight forward. Balance in ease of understanding, was originally more confusing
<Fazio> AC: haven't tried to change core req's since wide review. Lots of stakeholder comments
<Fazio> D McD: government has more capacity to meet req's
<bruce_bailey> +1 to DMcD concern with small businesses facing lawsuits
<Fazio> AC: halo effect might create false positive
<Fazio> AWK: is concern always about contrast ratio with focused control?
<Fazio> AWK: Is it about adjacency to focused control itself?
<AWK> The pixels in the minimum focus indicator area achieve at least a 3:1 against adjacent colors in the focused control or have a thickness of at least 2 CSS pixels.
<Fazio> AC: similar contrast/color focus controls near each other may be issue
<david-macdonald> can you explain again Andrew...
<Fazio> AC: if focus indicator separated from control contrast should be sufficient
<Fazio> I have no idea what to scribe here
<Fazio> help!
<Fazio> AWK: 2 pixel or more focus ring sufficient, focus ring that meets internal/external ratios
<AWK> My language is to try to split out the contrast adjacency between the focus indicator against the control itself and the area around the control. 1.4.11 generally applies to the contrast with the area around it, and the case where there is a gap is when the focus is thin and needs to contrast with both.
<Fazio> AC: happy with AWK suggestion
<AWK> ... (more from AWK) so by specifically targeting the contrast against the control we can eliminate overlap with 1.4.11
<Fazio> AC: 1st and 3rd bullets both need to be met
<Fazio> Wow, this has my head spinning
<Fazio> DD McD: fall back suggestion: 1 pixel sufficient if dashed
<Fazio> AC: ,any complaints about 1 pixel dashed
<Fazio> AC: adjacent w/ control instead of all adjacent per AWK seems agreeable
<Fazio> AC: don't care about halo effect. AWK update resolves issue
<Fazio> Wilco is fine with it if everyone else is
<Fazio> D McD: complexity compromises goal of simplifying SC's
<alastairc> Updated text: The pixels in the minimum focus indicator area achieve at least a 3:1 against adjacent colors in the focused control or have a thickness of at least 2 CSS pixels.
<alastairc> https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html
<Fazio> AC: visual examples help. They do need update
<Fazio> Wilco: can complexity be resolved by moving some of complicated text into a definition?
<Fazio> AC: scroll padding property solves sticky header/footer issue
<Zakim> mbgower, you wanted to say I did a substantial edit on the Understanding document and added in a note about the user agent
<mbgower> https://github.com/w3c/wcag/pull/1501
<Fazio> D McD: SCsomeone gonna save me from scribing soon?
<alastairc> Poll: Do you agree with the update?
+1
<Rachael> +1
<david-macdonald> 0 I want to see what the community says...
<Fazio> 0
<Fazio> uh yeah
<alastairc> Updated text: The pixels in the minimum focus indicator area achieve at least a 3:1 against adjacent colors in the focused control or have a thickness of at least 2 CSS pixels.
<mbgower> +1
<GN015> +1, if typos are corrected
<AWK> one small edit... sorry
<AWK> The colors in the minimum focus indicator area achieve at least a 3:1 against adjacent colors in the focused control or have a thickness of at least 2 CSS pixels.
<Glenda> MelanieP is listening on the phone as she is driving. She feels strongly that we need to keep an exception for the default focus indicator.
<alastairc> Change of contrast: The pixels making up the minimum focus indicator area achieve at least a 3:1 contrast between their colors in the focused and unfocused states.
<AWK> The pixels in the minimum focus indicator area achieve at least a 3:1 against adjacent colors in the focused control or the minimum focus indicator area has a thickness of at least 2 CSS pixels.
<Fazio> new scribe time
<Fazio> please
I can do it
<scribe> Scribe: Detlev
AC: A gradient between focus and control would either count as 2px focus if contrasting enough or act as a separator
(AC working on codepen to create offset focus outline - where outline needs only be 1px sold since it is not adjacent to the button
AC: Various techniques available to meet it (inset, outset, with offset etc)
DMD: So you can use the global focus with double outline would meet it?
AC: yes
Wilco: what if focus is not adjacent to focus control?
Andrew: if not adjacent there is no problem
AC: Any objections to update?
<Wilco_> +0 would prefer an "if the focus indicator is adjacent to the control" in there
RESOLUTION: Accept the SC update as amended, and the understanding document update.
AC: That is we update we made
<mbgower> oops, sorry. Roof leading. A bit distracted.
AC: Came up in ACT discussion, draft resonse was: Yes focus indicators should be unique
<alastairc> Focus indicators should be unique and it is best practice to do make them so, but there are edge cases that may be sufficient also. The intent of this SC is not to force focus indicators to be unique by defining focus. Doing so would likely create more problems than it solves but the issue can be explored further in a future version of WCAG.
<alastairc> The ACT rule discussion appears to be talking about controls that appear in the same place, rather than focus indicators that are confusingly placed.
AC reading through survey responses https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates/
AC: any objections?
<Wilco_> +1 to Rachael's update
RESOLUTION: Agree with updated response
<alastairc> "When user interface components receive keyboard focus, all of the following are true"
AC: must focus indicator always
be displayed (not be non-permanent)?
... There has been an update since
... could mean that indicator is only in scope if focus is
received (so could fade??) Concerning..
MG: Focus still has to be visible after initiall yreceiving focus to make focus visible
AC: why the change?
MC: When users open overlay that may obscure user focus so in that case the focus would no longer be visible
AWK: Agrees that focus has to be visible - no indication that it can be temporary
<alastairc> Detlev: Prefer to avoid formulation about 'receives' focus, could encourage glow-fade style indicators.
<alastairc> ... If the user triggers actions that hide it, I'd rather that is excluded. Would be better to somehow cover that, rather than loophole
<alastairc> ... using the other SCs is awkward.
<Zakim> mbgower, you wanted to say that we have all the existing SCs covering visible focus
<GN015> +1 to 'has focus'
AC: Response needs slight
update
... We need to work out the update, can'Ät do on the fly
Issue is unreasonable to expact antialiased pixels to meet contrast requirements
AC: most agreed with update
DMD: Difficult to calculate antialiasing
AC: Firefox 1px dotted ouline is
nit good - dashed can be considered as half meeting the
requirement so needs to get thicker
... dashed has less antialiasing, a lot more with dotted
<alastairc> https://alastairc.uk/tests/wcag22-examples/focus-more-visible-3.html
AC: Look at Example 10 - 12
... we should encourage that id you use dotted you should have
2-2 px thick to meet requirement (be on the safe side - you
don't want to measuire the aliasing fringe)
2-3 p thick (correction)
DMD: Can we identify the bad practice?
AC: We have in the understanding
doc but we could add to it
... the difficulty is calculating the area especially when
things are aliased
... need to mention it in some form
... reading out answer about browser differences - basically
saying don't use dots, or make them thicker
... checking comments (AC going through them in survey)
... Wilco, we did not want to provide an exception for aliased
pixels
Wilco: that what it read
like
... yYOu have to decide whether you include them (in automated
tests)
AC: Aliasing could vary by thickness, by browser, is not very consistent
Wilco: But do we agree that aliased pixels do not count, should be exclude them from focus indicator area
<Glenda> +1 to excluding alias pixels in the SC normative
AC: We have text about gradiants
and drop shadows - the relevant aspect is contrast change
... alisasing is what browsers do so difficult to get hold
of
<alastairc> The pixels that are changed to visually indicate when a user interface component is in a focused state.
AC: Reading text
<alastairc> perimeter: the continuous line forming the boundary of a shape. The perimeter calculation for a rectangle is 2<em>h</em>+2<em>w</em>, where <em>h</em> is the height and <em>w</em> is the width. The perimeter of a circle is 2𝜋<em>r</em>.
AC: Alias px will be included in
focus indication area to the extent that they are meeting the
contrast requirement
... nit sure how to include or exclude aliased pixels in
programmatic approaches
Wilco: has the second bullet changed?
AC: I think yes
<alastairc> <strong>Change of contrast:</strong> The pixels making up the minimum focus indicator area achieve at least a 3:1 contrast between their colors in the focused and unfocused states.
Wilco: It is not clear now
AC: Suggestions for change?
DMD: If you have aliasing you need a bigger indicator
AC: Yes if you have a gradient or things like the dotted outline
Wilco: Do not seen the difference between current text and proposed change - what we have already addresses the issue
<alastairc> Where a focus indicator is defined in code as a certain size, e.g. 2px thickness, anti-aliasing can be ignored for the purposes of calculation. Dotted or dashed outlines have various levels of gaps depending on the browser, screen density, and thickness. For example, in most browsers a "dotted" line will have roughly half the number of pixels due to gaps. However, in some sizes or browsers it might be slightly less than half, so increasing
<alastairc> the thickness may be required.
AC: The question is are we happy with the update?
<Wilco_> +1
+1
<morr4> +1
AC: Any objections to update of understanding doc?
<david-macdonald> +1
RESOLUTION: Accept update #1493
Topic from Jake about non-modal dialog and the 'unobscured' bullet
<alastairc> "If the interface is configurable and the user can move non-modal dialogues around then only the initial position would be considered for testing & conformance."
AC: reads proposed answer and update to understanding dic
DMD: There is a technique for sticky headers and would fail if not applied
<alastairc> David: test page for stickies & focus: https://alastairc.uk/tests/wcag22-examples/sticky-footer3.html
What if there is a link behind the chatbox? Do you need to shift content underneath?
AC: if chatbox obsured links, its an issue
<alastairc> Not fully obscured: The item with focus is not entirely hidden by author-created content.
DMD: So are you alright if you can scroll the page? It sounds this would no longer be accepted
AC: That's why we said "not fully obscured"
DMD: What do we tell retailers that put chatboxes in the corner?
AC: Don't put links behind it?
DMD: this is a pervasive practice
(difficult sell)?
... We would fail every retailer's chatbox now
AC: If you have the option to
move the non-modal you would be alright
... It would fail if the initial position fails
<alastairc> If the interface is configurable and the user can move toolbars and non-modal dialogs around, then only the default positions of user-movable content would be considered for testing & conformance of the Unobscured bullet.
MG: made an addition
AC: default or initial?
MG: either works
... "If the interface is configurable so the user..."
<alastairc> "If the interface is configurable so that the user can move toolbars and non-modal dialogs around, then only the initial positions of user-movable content would be considered for testing & conformance of the Unobscured bullet."
Ajny objectino to addition to understanding?
RESOLUTION: Accept update as ammended
AC: There are more focus visible
issues
... lets move to other survey
... Tackling which controls are in and out of scope
... not many responses
<Rachael> Link to hidden controls if you need it: https://www.w3.org/TR/WCAG22/#hidden-controls
AC: several people thing text should be changed
<alastairc> There is enough demonstration that there are examples it is very difficult to call as in or out of scope, there needs to be some change. However, I have no idea how to better define the scope.
AWK: What is the gap?
AC: Quite a few apps with controls that only appear on hover - so non-text contrast can't be applied to the defualt
Rachael: There is a trend that scope need to be clarified - either by putting all in scope and create exceptions e.g. when alternative sare available; OR focus on the hover aspect and take the kb focus out
AC: That would not clarify which controls are in / out of scope
Rachael: Disallow controls that are only available on hover?
AC: There are examples where
showing all by default would overload the interface
... So it raises the question which controls are imporant and
need to be permanent
... should we replace process, find something else for scoping
? - but can't find something else yet
<alastairc> https://www.w3.org/2002/09/wbs/35422/
<david-macdonald> I created an issue about non modal dialogs https://github.com/w3c/wcag/issues/1502
AC: apart from Silver we will have more on focus visibility, keep an eye on the issues and surveys - avoid questions marked as donwe
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Default Present: AlastairC, Rachael, Francis_Storr, Raf, Nicaise, Sukriti, bruce_bailey, Laura, Matt, Orr, Fazio, AWK, sarahhorton, JakeAbma, Jennie, Glenda, MelanieP, Wilco_, Detlev, david-macdonald, mbgower, GN Present: AlastairC Rachael Francis_Storr Raf Nicaise Sukriti bruce_bailey Laura Matt Orr Fazio sarahhorton JakeAbma Jennie Glenda MelanieP Wilco_ Detlev david-macdonald mbgower GN015 Regrets: ChuckA JustineP JohnK CharlesH Found Scribe: Detlev Inferring ScribeNick: Detlev WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]