Meeting minutes
<Chuck> Alastair, Michael or Rachael, I can't get logged into the telecon info page, with the zoom link. If you have it, can you email it to me?
<Rachael> Can you send it to me as well?
<Chuck> will send direct.
<Chuck> OK, we should not send to list
<Chuck> so send them to IRC maybe, and then we can update the minutes and remove the link from the minutes after.
<Chuck> //j/?pwd=///j/pwd=
I can't get to the zoom call-in info page, it times out...
<Rachael> +1
Chuck: Want to introduce yourselves?
… Announcements?
<AWK> +AWK
Google Focus appearance research presentation
Rachael: There will be a 2 weeks survey tomorrow or Thursday for WCAG 3
Julia: I am researcher at Google
Julia: (sharing screen)
Focus states: research and solutions
Chuck: can you share URL
Julia: sharing Google research on focus states
… first share research, clarify understanding that may contribute to WCAG
<MelanieP> The meeting page on w3c is timing out for me and Wilco. Can you please drop the zoom link info here? Thanks!
Julia: what is a focus indicator? (Julia explains)
Julia: sharing SC text 2.4.11
<MelanieP> Thank you!
understand, align, even exceed guideline
Julia: contrast and failing that, 2 pixel width
… may be difficult to see
… want to research optimal focus state indication
… part 1 behavioral task (fundability)
part 2 user opinios
part 1 was focusing on response time and accuracy
… click highlighted element as past as possible
… starting at the centre, one of the buttons around it being highlighted
… modifying color shape outline weight
… 1080 participants
some with some without disability
… no particular design was helpful for one group over another
… 1dp outline inside and outside button did not perform well
… confirms WCAG stance on non conformance
… 1 dp seemed to not perform well throughout
… with extra padding and more weight targets performed better
(please refer to presentation for details :) )
… dropping weight of outlines increases response times
Luis: Example of solution 3 dp outline with 2 dp padding and good contrast
Luis: (summarising SC 2.4.11 requirements)
… some components can't have padding
like list and menu components - so 3 dp outline rremains
Luis: showing different schemes and what targets look like there
… referencing the way it meets SC
Julia: what does this all mean?
… WCAG allowed design may lead to focus states that are difficult to find
<GreggVan> sorry for being late -- the w3 server isnt giving out the dial in number -- and it only just occurred to me I could get it here. can someone post it please? thx Gregg
Julia: recommendinng requiring a weight of 2 dp instead of 1
… but could be tough as a minimum requirement
Julia: there are benefits to exceed requirements - (google intends to do that)
<Zakim> Chuck, you wanted to ask what is a dp
Chuck: Julia - what id dp?
Julia: it is a virtual pixel measurement
<jon_avila> device independent pixels
<Zakim> AWK, you wanted to ask what we are allowed to do with this presentation, as it is marked "confidential and proprietary"
roughly equals CSS pixel (?)
AWK: is it confidential - you showed it to a public WG...
Julia: There is legal approval to share the doc
Jon: Goof to take into account the to find indicators
… where participants Google employees?
… what requirements you find difficult to meet?
Julia: This was not Googlers, but anyone
… second question: problem when indicator does not fully enclose the target
Luis: in some components the focus ring could not encompass / be visible all around the component
<GN015> 40 dp equals 24 CSS px
Luis: but contrast and size criteria where met
<Zakim> alastairc, you wanted to ask about non-outline indicators
Jon: (inaudible
Alastair: Thanks, good to see, lines up with session on developing criterion
<jon_avila> Can you please share any details on the percent of participants with low vision? Thank you.
<Zakim> Chuck, you wanted to ask about the final recommendation
Alastair: you were looking at outline - did you also look at non-outline?
Julia: this focused on outline, most common
Luis: Main concern wanted to look at good differentiation of focused / non focused - change of background seemed less useful
Dan: one case was against mixed background - these were not uncommon in reality, and most difficult to treat
… any recommendations for this?
Julia: this had light theme / dark theme focus
Michael Gilbert (Google): Goal of having inner and outer ring was to make it accommodate variable backgrounds and with adjacent contrast it would always be sufficiently contrasty
… wogen on white and black background because you'd see at least one or the other of the outlines
… works on arbitrary design without impact on design
<chinshaw> So, the recommendation from the research was minimum 2dp, which would be equivalent to 1.2px (CSS pixels)?
<Zakim> bruce_bailey, you wanted to discuss slide 27 do we agree that 3 of 4 fail 2.4.11 ? -- I think top two are presently a pass ?
<bruce_bailey> https://
<mbgower> agreed
Bruce: don't agree the top two examples fail the current SC language
<dan_bjorge> I agree, I think the top two pass clause 2 so long as the rings meet 3:1 with the button color
<Zakim> alastairc, you wanted to say that's down to the 4px shortest side, not encloses.
if subcomponent is too weak it would pass on the main component
<AWK> Would be good to know what the button looks like unfocused
<bruce_bailey> encloses the user interface component or sub-component that is focused, and
Alastair: they probably pass the 4 px along the shortest side metric
… that's wha I asked about the non-online indicators
… people may use different quite visible indicators
<Zakim> mbgower, you wanted to say can you comment on the level of difficulty your team had interpretting the SC wording
Mike Gower: would like to hear about difficulty of interpreting the SC text in the team...
… agrees that example does pass SC via the 4px case
… while others (?) might fail (unclear which examples this refers to)
<AWK> "is at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component or sub-component, or is at least as large as a 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component or sub-component, and"
Michael (google): we need some level of interpretation - the req that the size of the focus state inside the component would need to be equal or greater than the perimeter of the component
… is that correct?
<jon_avila> Maybe they were looking at old version of the criterion
Alastair<<<<. only correct for perimeter but SC can be met also by the 4px at shortest side of the perimeter case
<alastairc> Two interesting things there - it doesn't perform well, and it wasn't understood.
Chuck: Thanks for presenting the research
<jon_avila> Thank you Google team.
<bruce_bailey> yes, thanks for this work and feedback !
WCAG 2.2 Focus appearance Survey: https://www.w3.org/2002/09/wbs/35422/focus-appearance/
<mbgower> I was unable to save my responses due to the w3c timeouts
Alastair: results of focus appearance survey - currently at risk - issue is complexity
… Microsoft raised an issue that was resolved - different type of research, testers rating different examples
… dotted and dashed outlines presented a problem because different browsers present this differently
… some mistakes happened, like thinking perimeter was required, failed color inversion
… another problem was determine whether default browser indicator is at play or not
… various issues, that may be covered in understanding doc - table of safe and non-safe indicators
… in summary we can go through comments - the survey seems to indicate that testability is the main issue
… no proposal to solve that without creating some fall big loophole or constrainig design to using outlines
<Zakim> Chuck, you wanted to ask about Alastair's proposal
Alastair: could be triple AAA
Chuck: So your proposal would be to move it to AAA?
Alastair: there are three objections to continue with it as is
… no objection to move to AAA
… Does it impact on moving Focus visible - does it need to be moved back to AA?
Chuck: Going through comments.. Dan
Dan: Fine with with move to tripple A or remove - but should never mandate outline - cases that uses grading non solid background would be outruled
Chuck: Reading Kiara's comments
Alastair: Option suggested was not on the table
Chuck: (reads Gundula's comment)
Chuck: (reading Jon's comment)
Chuck: (reads Melanie's comment)
<alastairc> jon_avila - would that suggestion be for if we were continued with it a t AA?
Chuck: (reads Alastair's comment)
<Zakim> alastairc, you wanted to suggest the alternative option (move to AAA and keep second part only).
Alastair: Have spent a lot of time on this would like to keep guidance on level AAA focusing on the second part of the S
<bruce_bailey> i did not submit survey but +1 with some move to AAA
<Zakim> Rachael, you wanted to say if we move this to AAA, can we increase the requirement to better match the user needs?
Alastair: make it shorter (if not simpler)
<Zakim> Chuck, you wanted to say I'm concerned about moving and tweaking
<Wilco> +1 Rachael
Rachael: Would rather keep it in - but if AAA is the way to go we should increase requirement to move thickness to 2 or 3 CSS pixels
<ShawnT> +1 Rachael
Chuck: Concern about moving I level up AND taking it - need to be careful
<laura> +1 Rachael
<bruce_bailey> +1 to rachael comment that by moving to AAA we can strengthen and simplify
Chuck: lov to in-areas weight requirement
Mike Gower: Thanks to all who did this even if it is to become AAA
… it is still valuable, can be pointed in, used in in-house testing
… increasing the threshold - needs clarification from MichaelC if this is an option
Dan: big +1 to folks who worked on this - good to move this forward - interesting that perimeter requirement was misinterpreted even by an expert
<bruce_bailey> +1 to Dan Bjorge observation that google SME has trouble reading SC
<Zakim> Chuck, you wanted to ask for a scribe change
<Zakim> alastairc, you wanted to comment on the options at this stage and to also mention a quick update.
Alastair: on options to make changes: hard to make changes at AA and higher now. will check with Michael Cooper tomorrow
… did previously have a version of focus appearance at AAA, was part of first wide review, so wouldn't be completely unexpected
… think a AAA change would be feasible if it's what group wants
Mike: Suggest pulling out entire first clause, create a technique for two-color contrasting indicator that meets updated requirement
<alastairc> Suggest: When the keyboard focus indicator is visible, an area of the focus indicator meets all the following:
<alastairc> - is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and
Mike: maybe offer google research as supporting doc
<Zakim> Chuck, you wanted to say that if we are tweaking, we need to craft it and review it as is
Mike: Clarifying that such a two-color indicator would fail part 1 of the existing requirement text. Think that eliminating clause 1 might cut down on interpretation difficulty
Charles: Unsure how to craft a poll about exactly how to change, may need to craft if offline and come back
Wilco: Thinks we would likely need another round of CR if making substantive changes to the text
Alastair: Thinks in AAA area we have more flexibility, likely to be non-problematic if we're taking substantially the same at-risk requirement and moving from AA to AAA
… Will double check, but thinks it's likely the best option
<Wilco> No, I don't think changing to level AAA requires another CR Mike
<Zakim> SuzanneTaylor, you wanted to ask if we should consider a very simple sub-set of the
<alastairc> Poll: Assuming we don't trigger another round of CR, do you approve of moving a sub-set of the SC to AAA?
Suzanne: Asks if we can take a simple subset of the requirement and put that at AA. Maybe "some portion of the focus indicator has 3:1 contrast, either change or adjacent".
<Zakim> alastairc, you wanted to say we have that in non-text contrast
<bruce_bailey> +1 to poll at 12:06
Alastair: Think we already have that as part of non-text contrast. Lacks change-of-contrast, but is close to that suggestion already
<Chuck> Poll: Assuming we don't trigger another round of CR, do you approve of moving a sub-set of the SC to AAA?
<mbgower> +1
<ShawnT> +1
<alastairc> +1
<AWK> +1
<GN015> -1 not without knowing which kind of subset
<Chuck> +.9
<Ben_Tillyer> 0 joined call too late to understand the nuances
<Rachael> .5 if we can't change the requirements, .9 if we can increase them
<Zakim> bruce_bailey, you wanted to ask if we already polled for AAA ?
<Wilco> -1 Agree with GN
<laura> +1
+1 in principle, but depends on sub-set
<chinshaw> +1
<Caryn> +1 in principle, but depends on sub-set (thanks Dan for the copy/paste)
Bruce: Should we do separate polls for "move to AAA" vs "what update to make at AAA"?
<GN015> at the moment we have the area of a 1px thick perimeter, haven't we? Increasing to 2px means a substantive change.
Alastair: suggests preview of proposal for AAA text that is essentially "the second clause of the current text", but increasing the area requirement to "area of a 2CSS pixel thick perimeter" with no "smallest side of minimum bounding box" clause
<alastairc> This is for those who weren't sure what the sub-set would be
<Zakim> Chuck, you wanted to say that this is a "spoiler" of what an AAA might look like, and we are not voting on this NOW, just that we will try to craft one that may look like this.
<Zakim> Chuck, you wanted to ask for clarity on the Bruce and Mike ask
Mike: Can see scenario where moving AA to AAA might be fine without CR, but changing wording along with move might trigger new CR. From that standpoint, would be nice to see if group approves "move to AAA" separately from "change text" or not
<AWK> Unfortunately changing the text of the SC doesn't seem to be allowed as it is a Substantive Change: https://
<AWK> After CR you can go to "Proposed Recommendation, if there are no substantive change other than dropping at risk features"
Bruce: agree with Mike's restatement
<Chuck> Poll: Agree to explore moving a modified version of the SC to AAA
<bruce_bailey> +1
<ShawnT> +1
<Chuck> +1
+1
<SuzanneTaylor> +1
<chinshaw> +1
<GN015> +.5 only if it is ensured that the new version is not more restricting than the current version
<laura> +1
Mike: Would like to get a vote in on moving it to AAA. Can do a separate resolution on changing text.
<Chuck> proposed RESOLUTION: Move the SC to AAA
<Wilco> +1
<mbgower> +1
+1
<ShawnT> +1
<alastairc> +1
<Chuck> +1
<bruce_bailey> +1
<laura> +1
<MelanieP> +1
<Rachael> +.5
<chinshaw> +1
<AWK> +1
+1
<GN015> -1 without knowing petnetial changes, dropping might be better then, so the option to drop should be kept
<Ben_Tillyer> Just so I'm super clear, voting a -1 would most likely end in removal of SC?
<alastairc> yes
RESOLUTION: Move the SC to AAA
<Ben_Tillyer> 0
Chuck: Not sure we need a second resolution at this moment, may want to craft proposal for language update and come back
Alastair: Wants to discuss "if we are able to modify it, what modifications would we want to make?"
<bruce_bailey> might have resolution to agree to continue considering phrasing -- so long as CR not risk
Corey: Loves increasing the minimum area like Alastair's preview from earlier. Wants to discuss dp vs px from google talk earlier
<Chuck> proposed RESOLUTION: Explore removing the first part of the SC and strengthening the second part without trigging another CR
Corey: Wants to follow up with Google researchers and clarify about difference in units before specifying specific language for new area
<GN015> increasing the area means a substantial change and invalidates many options which comply with the prior version. It invalidates many creative focus indicator options. I feel it is not justified by specific cases with a strongly colored button.
Wilco: Andrew put a link earlier for the W3C process around whether we can make substantive changes or not, and it seems clear that we couldn't make substantive changes beyond "dropping at risk requirements".
… are we trying to talk about what we'd want to change if we can get approval to go around documented process?
Chuck: Maybe some of these changes could be considered non-substantive?
<Chuck> +1
Mike: Need more clarity on whether AAA-specific changes can be considered as "non-features" or not for the purposes of deciding what changes we're allowed to make
<GN015> by substantive I meant to say considerable, striking, with a lot of effect, maybe substantial? (sorry, I am no native speaker)
Rachael: Is there value in asking (in another poll) if we like the changes enough to trigger a new CR? Not necessarily advocating that, but wondering about keeping options open
Mike: For example, if we pull away part 1 and do nothing else, we're clearly not adding new features, so that's less likely to trigger CR than something like increasing the area required by part 2.
Wilco: Thinks we're maybe framing question wrong. Is not about "does it trigger or not trigger CR", is "do we want to give the public an opportunity to respond to these changes?" That's what we're really saying by not going to CR.
… those processes are in place to make sure that there's broad support for the work we're doing. Trying to hit the edge of what we're allowed to release or not doesn't feel in the spirit of that.
<bruce_bailey> Just noting that CR called out this SC as being at risk: https://
Ben: Agree with Wilco, wouldn't sit right to not go out to CR if we're making changes. If it did go to CR, suspect we'd see similar objections at AAA that we're discussing now at AA.
Gregg: If this is a controversial change and we aren't putting it out for CR, that's one thing. You're allowed to put out normative changes after CR, but you need good justification.
… for this one, want to think: is it improved? Does it get rid of a problem we had? Then I think that's good. We want public review, but we aren't making it weaker, trying to make it better, and that's within judgement of working group (with review of folks above us to verify we aren't abusing that judgement)
<Zakim> Chuck, you wanted to recommend a way forward
Gregg: Think we should look at merits of change more than formalities of process
<Rachael> +1 to figuring out what hte group wants to do independent of the CR
<MelanieP> +1
<Chuck> proposed RESOLUTION: Explore removing the first part of the SC and strengthening the second part
<GreggVan> this is the last 2.x so lets do it right
<Wilco> +1
<bruce_bailey> +1
<mbgower> +1
+1
<GreggVan> +1
<alastairc> +1
<ShawnT> +1
<SuzanneTaylor> +1
<AWK> +1
<MelanieP> This is for the AAA version?
<laura> 1
<Rachael> +1 assuming we are moving to AAA
<kirkwood> +1
<chinshaw> +1
can' tell
<Chuck> +1
<GN015> -1 can't make such a decision without evaluating the consequences first
<MelanieP> +1 if AAA
<Caryn> +1
RESOLUTION: Explore removing the first part of the SC and strengthening the second part
<AWK> I've verified that between 2.1 CR and PR and Rec there were no changes in level for any SC, FYI.
<Ben_Tillyer> 0
<alastairc> The default position now is at AAA.
<ShawnT> +1 to GreggVan "this is the last 2.x so lets do it right"
Alastair: Will try to get outstanding 2.2 issues resolved asynchronously where possible. Let's move on to WCAG2ICT
WCAG2ICT Survey: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-First-AGWG-review-4-sc
Alastair: Will re-open applicable postponed WCAG 2.2 survey(s) per Bruce's ask
<maryjom> w3c/
Mary Jo: On review of background section:
… incorporated editorial changes into PR already.
… had some trouble getting numbering updates Jon A suggested addressed, but intend to continue working on them
<Chuck> proposed RESOLUTION: Approve the amended background section of WCAG2ICT
Question 1 - Review of Background section
<bruce_bailey> +1
+1
<mbgower> +1
<maryjom> +1
+1
<ShawnT> +1
<laura> +1
<Ben_Tillyer> +1
<Chuck> +1
<kirkwood> +1
RESOLUTION: Approve the amended background section of WCAG2ICT
<GreggVan> +1
Question 2 - Success Criterion 1.3.4 Orientation
Mary Jo: Jennifer had comment about applicability of physical devices that are fixed in place but still rotateable (like rotatable monitors with fixed bases)
… Jon A had a comment that I think is resolved by a new PR I created, along with Jennifer's on orientation
… Not sure I've addressed consideration for "tools, authoring tools, and documents" completely
<Zakim> mbgower, you wanted to say it should apply as written
Ben: So if I rotate my monitor from landscape to portrait, does my "resolution" change for the purposes of this text?
<Chuck> +1
Mike: Thinks text applies as written after Mary Jo's PR for PDFs/etc, think we're good
Chuck: Asks for clarification on Ben's question, not sure it's been addressed
<Chuck> proposed RESOLUTION: Approve the amended Success Criterion 1.3.4 Orientation guidance
<mbgower> +1
+1
<Chuck> +1
<laura> +1
<maryjom> +1
<bruce_bailey> +1
<ShawnT> +1
+1
RESOLUTION: Approve the amended Success Criterion 1.3.4 Orientation guidance
Mary Jo: On Identify Input Purpose, comments:
… Jan and Kim both discussed that this doesn't talk about different keyboard types that a device might switch between based on input type specification
… The SC doesn't really talk about this, so addressing that would probably require expanding the SC criteria, which the ICT task force doesn't really have the ability to do
… Not sure what to do about this given that we aren't at liberty to add new requirements
Question 3 - Success Criterion 1.3.5 Identify Input Purpose
<Zakim> Chuck, you wanted to say we cannot add that
Gregg: It's not really a "user need" to have a separate keyboard - not sure it's something getting worked up over, especially given that we can't add to the SC in the task force.
<bruce_bailey> I would note original WCAG2ICT finessed keyboard issues -- so i think its okay.
Chuck: Agrees with Gregg, out of scope for the task force.
Melanie: Similar to earlier discussion from web where *only* popping up a correct keyboard isn't sufficient for the SC even in web
Mary Jo: Detlev commented about being confused by phrase "the terms for the input purposes would be the equivalent terms provided by the technology used."
… I tried clarifying in PR #128
<maryjom> w3c/
Andrew: One of the reasons the SC doesn't specifically demand the exact HTML input types is because even in web, we'd want non-HTML technologies (like PDFs) to use semantically equivalent types appropriate for the format, not necessarily exact matches with HTML
<AWK> https://
Detlev: Not sure how it would apply or what it would mean for testing non-web content where the technology only allows an incomplete set. Would anything ever fail?
OK that's clear then, tanks
Andrew: Would be required to use the ones that match. If all a technology supports is a subset of what the SC specifies, you'd have to use that subset which is supported by the technology.
<Chuck> proposed RESOLUTION: Approve the amended Success Criterion 1.3.5 Identify Input Purpose guidance
<Ben_Tillyer> +1
<bruce_bailey> +1
<maryjom> +1
+1
<Chuck> +1
<MelanieP> +1
<laura> +1
<ShawnT> +1
0 - even as amended, think first note is more confusing than similar SC text
RESOLUTION: Approve the amended Success Criterion 1.3.5 Identify Input Purpose guidance
<mbgower> +1 and Dan can give more feedback later
Mary Jo: On Character Key Shortcuts:
… Kim suggests that in applications, more important to be able to change/save/share shortcuts. I think this is something we can't address in WCAG2ICT since we can't increase the scope/requirements of the SC
… Made PR #125 addressing inconsistency Dan noted
… Andrew also had an editorial suggestion addressed by the PR
<Chuck> +1
<bruce_bailey> +1
<maryjom> https://
<Chuck> proposed RESOLUTION: Approve the amended Success Criterion 2.1.4 Character Key Shortcuts guidance
+1
<mbgower> +1
<Ben_Tillyer> +1
<maryjom> +1
+1
<Chuck> +1
<bruce_bailey> +1
<ShawnT> +1
<MelanieP> +1
RESOLUTION: Approve the amended Success Criterion 2.1.4 Character Key Shortcuts guidance
Mary Jo: On Guideline 2.5 input modalities:
… one comment about missing pointer to intent, but that's intentional, this is a guideline not an SC
<Chuck> proposed RESOLUTION: Approve the 2.5 Input Modalities guidance
+1
<Ben_Tillyer> +1
<maryjom> +1
<Chuck> +1
+1
<ShawnT> +1
<laura> +1
<bruce_bailey> +1
RESOLUTION: Approve the 2.5 Input Modalities guidance
Mary Jo: On 2.5.4 Motion Actuation:
… only comment is that linked "Processes" definition needed an update. Addressed in PR #127 to apply definition of Processes as-is and omit note about being specific to a requirement.
… looked at SC 2.4.5 and already said something substantially similar to the guidance that was previously in the Processes defnition
<maryjom> w3c/
<bruce_bailey> good catch on process definition
Mike: Clarifying whether any of the removed processes text is still necessary?
Mary Jo: Meaning was already captured in 2.4.5
… Since message was already captured there and "process" definition is used elsewhere in many other SCs, think it's more appropriate for definition to be general and to apply across the board as-is
<Chuck> proposed RESOLUTION: Approve the amended Success Criterion 2.5.4 Motion Actuation guidance
<mbgower> +1
<maryjom> +1
+1
+1
<Chuck> +1
<ShawnT> +1
<laura> +1
<AWK> +1
RESOLUTION: Approve the amended Success Criterion 2.5.4 Motion Actuation guidance
<Raf> +1
Chuck: Thanks all for attending! We are all set for this week.
<bruce_bailey> +1
<Rachael> a//
<Rachael> s/583945521?/