Meeting minutes
New members and topics
RM: any new topics or member updates?
Bruce: noticed erata pages are out of date
ACTION: errata pages are out of date
<trackbot> Error finding 'errata'. You can review and register nicknames at <https://
Announcements and Reminders
Rm: we are behind on 2.2.
<Zakim> Rachael, you wanted to say demonstration
Rm: Please use q+
… will try to get through most of the surveys today.
… use +1's
… we need to speed up discussion.
<ShawnT> +1
<kirkwood> very clear. thank you.
WCAG 2.2 Focus appearance https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results
User-Interface Component as basis for size
Rm: been taking about this previously.
<bruce_bailey> wrt my comment about the errata pages, see: https://
Rm: MG: said "I'm assuming you mean "User interface component" and that this "User-interface control" in the survey question was someone asleep at the wheel."
<mbgower> yep
RM: Oliver said "User Interface Component" should be used consistently, also the "sub component", if the decision is to use "User Interface Component" although ISO Standards make use of "User Interface Element" and "items" for subordinate content.
… he noted some typos.
<alastairc> I think most of those were based on the rest of the doc, which will be translated to the understanding doc.
RM: reads Gundula's comment
… editorial comments.
… AC replied to other comments.
<GreggVan> +present
RM: reads wilco's comment.
<Rachael> https://
RM: wilco created a codepen.
<Detlev> @Rachael - please update survey
MG: edge cases do not mean the SC has failed.
… we are talking about a bad design to begin with.
… all examples failed the UIC
… we get benefit from this SC.
AC: I put in a list of comments.
… been focusing on edge cases.
RM: 9 agree in the survey.
User Interface Component (UIC) measure as visual basis
gregg: we have lists of items that put items into a toolbar.
<mbgower> I think you're talking about Focus Visible, not Focus Appearance, Gregg.
gregg: recoded links as buttons
Mg: this is on topic of focus indicator.
wilco: we are not saying that we are measuring visually.
… we are not telling people how to measure.
Ac: It based on UIC
… haven't had to ease that previously.
… we have encompassing component and all of the examples.
… it is a perceived component.
<Zakim> GreggVan, you wanted to say "I think it is fine to talk about visual focus indicators being based on visual appearance. As long as the focus is also programmatically determinable (another SC) we are fine. "
Gregg: I think it is fine.
<mbgower> It is also there in the bounding box part of the existing wording too
wilco: don't think it is obvious.
… we had a definition in the last draft.
<Zakim> alastairc, you wanted to say we included a note on that which did talk about the interpretation
wilco: I don't follow. It doesn't say visual.
Ac: we are talking about focus appearance.
… and how to interpret it.
… base it on the visual appearance.
… had a twitter poll.
Mg: we do have SC based in a functional need.
… trying to give muscle to focus visible.
<alastairc> "encompasses the visual display of the user interface component"??
Mg: has gone through a lot of scrutiny.
… we have a lot of examples.
<Zakim> bruce_bailey, you wanted to ask about adding preface "For UIC that have a visual appearance..."
Mg: it is working well.
Bruce: sympathetic to wilco.
Ac: prefaced by keyboard focus.
<mbgower> Do we have examples?
<mbgower> Say again, please?
wilco: if it is visible presentation lets say so.
<Rachael> straw poll: 1) Include the information about visual measurement in understandning and note only 2) include it in the SC text
<Wilco> 3
<GreggVan> 2
Wilco: we need to continue to work on this.
<GN015> 1
<Rachael> straw poll: 1) Include the information about visual measurement in understanding and note only 2) include it in the SC text 3) continue to work on a combination of visual and programmatic
<bruce_bailey> 2 (but okay w/ 1)
<OliverK> 1
Wilco: we have previously rejected visual appearance.
<myasonik> 1
<jon_avila> 1 or 2 is fine
Ac: we are building on top of focus visible.
<Rachael> 1
<alastairc> "encompasses the visual display of the user interface component"
<Rachael> +1 to learning as we work
Ac: could say visual display.
<Chuck> +1 to "visual display of the..."
<jon_avila> I would be good with visual display of interface component
<Rachael> +1 to this being visual
Gregg: have to break it down by the aspect you are working on.
… so say visual focus indicator.
<mbgower> adding "visual display of" to the first bullet seems okay
<Detlev> so we just need: When a user interface component has keyboard focus, the *visual* focus indicator:...
<Zakim> mbgower, you wanted to say its not just visual appearance, it's the focus indicator that is the key question in COMBINATION with the visual presentation of the UIC
Jon: 1.3.1 says convey though presentation.
<GN015> we allow circles to be focused by circles. The technical dimensions of a circle image usually are square or rectangle. So from our examples, the visual dimensions clearly have always been a source for the measurement.
mg: can add visual if that would help.
<mbgower> it IS written
Wilco: what we are saying now sounds circular.
<bruce_bailey> +1 to Jon Avila comment that SC (like 1.3.1) tend to presentation not visual presentation
<mbgower> no
Wilco: previously tried to work in target but backed out of it.
mg: target is the actual points that are interactive on the screen.
<alastairc> It isn't based on target, and it was not used because it didn't align with either visuals or the underlying code, and could create a negative incentive
mg: we aren't talking about pixels on the page.
… target can't work- too easy to fudge.
<GN015> +1 to Mike
mg: we assume the design is useful.
Gregg: sounds like a technical thing.
<bruce_bailey> +1 to Mike Gower that focus indicator relatively agnostic to target size
Gregg: some systems have group strategies.
<Zakim> Rachael, you wanted to say we should see the adjustment of adding visual as mbgower suggested
Gregg: success of approximation.
<Detlev> 1 visual can be i nthe first sentence
Ac: I updated: https://
<alastairc> When a user interface component has keyboard focus, the focus indicator:
<alastairc> encompasses the visible display of the user interface component
<mbgower> that doesn't work as well, Detlev
detlev: add visual in front.
<GreggVan> When a user interface component has keyboard focus, the visual focus indicator:
Ac: doesn't work. It is about the visuals.
<mbgower> bingo
<Zakim> GreggVan, you wanted to say "should we say visual focus indicator" in first line
<jon_avila> Agree with Alastair.
mg: focus indicator is a defined term.
(Reads definition)
<Detlev> OK I withdraw my sugestion!
<Rachael> draft RESOLUTION: Accept using User Interface Control as the basis of size with updated text
<Rachael> draft RESOLUTION: Accept using User Interface Component as the basis of size with updated text
<Detlev> +1
<ShawnT> +1
<alastairc> +1
<Chuck> +1
<JakeAbma> +1
<GN015> +1
<Rachael> +1
<jon_avila> +1
<kirkwood> +1
<Ryladog__> +1
<Francis_Storr> +1
<mbgower> I'm not sure I would have said "size" but okay :)
<OliverK> +1+1
<myasonik> +1
<GreggVan> +1
<bruce_bailey> +1
Laura: +1
<mbgower> that's fine
<alastairc> visible / visual ?
<Wilco> Accept using visible display of the User Interface Component as the basis of size with updated text
<mbgower> Accept the visual display of the UIC as part of the assessment for Focus Appearance
<Wilco> -1
<Rachael> draft RESOLUTION: Accept the visual display of the UIC as part of the assessment for Focus Appearance
RESOLUTION: Accept the visual display of the UIC as part of the assessment for Focus Appearance, with 1 objection that visual is not the correct approach
RESOLUTION: Accept the visual display of the UIC as part of the assessment for Focus Appearance
Rm: notes 1 objection.
<mbgower> that's fine too. WE can wordsmith it.
<GreggVan> +1 to visual presentation vs visual display
Note on sub-components / active descendants
rm: will continue to wordsmith
<Rachael> NOTE: Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), this Success Criterion applies to the item with keyboard focus
Ac: we added a note: NOTE: Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), this Success Criterion applies to the item with keyboard focus.
… The purpose is to make clear that when evaluating the SC you would use the item with focus rather than the parent.
… The other notes (that you can see in the editor's draft at the moment) have been removed as they do not seem to be needed with this version.
Rm: 5 agree
… Reads Oliver's comments.
… Reads Wilco's comments.
<Rachael> Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), the above requirements apply to the indicator of the active sub-component.
<alastairc> Wilco - were you aiming for that to be part of the SC text or as a note?
Rm: reads mg's comments.
Mg: +1 to wilco.
rm: reads Gundula's comments.
… Reads Detlev's comments
<bruce_bailey> anchor in survey: https://
<mbgower> Detlev, does Wilco's wording clarify things?
<Rachael> themes: lack of clarity on what is used in combobox, note vs. SC text, wordsmithing
Jon: apply to whichever one has keyboard focus.
<Rachael> Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), the above requirements apply to the indicator of the active sub-component.
<alastairc> Definition of focus (that we aren't using): https://
<Zakim> alastairc, you wanted to talk to Detlev's example
Jon: another option that it applies to anything.
<Wilco> suggest: also applies to...
ac: we came up with a definition of focus.
Detleve: it is ambiguous to me.
<Zakim> mbgower, you wanted to say the larger component can be good practice but I'm a bit leery of failing a lack of it
mg: leary of adding it to large and sub component
… could fail existing implementations.
<alastairc> "the above requirements apply to the indicator of the active sub-component when the user interacts with them"?
Rm: Could we clarify in understanding doc?
<Zakim> mbgower, you wanted to say it already says "active"
<alastairc> ok
ac: finishing of definition. Happy with clarifying understanding doc
<Rachael> straw poll: 1) use Wilco's wording and understanding document 2) Use wilco's wording, alastair's addition and understanding, 3) Something
<alastairc> 1
<Chuck> 1
<ShawnT> 1
<Wilco> 1
<Rachael> 1 or 2
Laura: 1
<bruce_bailey> 1
<JakeAbma> 1
<jon_avila> 1 or 2
<Detlev> 1 or 2
<Ryladog__> 1
<mbgower> 1
<MelanieP> 1
<GreggVan> 1 or 2
<kirkwood> 1
<OliverK> 1
<joeyang> 1 or 2
<mbgower> is michael on call?
<Detlev> unfortunately have to drop off at the full hour...
ac: topic came from wilco's comment.
Rm: wilco comfortable with a note?
<GreggVan> +1 to notes cannot be normative
<Zakim> alastairc, you wanted to say it is interpreting what a component is
wilco: notes are not normative. Needs to be in SC.
Ac: it is interpretive.
<Zakim> mbgower, you wanted to say this is interpretive
Wilco: I disagree. UIC is a single control as I read it.
<bruce_bailey> +1 that it is interpretive, seems similar in scope to other notes
Katie: example of a calendar.
<alastairc> It depends whether you see the function as "selecting a date" from a calendar, or "selecting THIS date" from a calendar. Same for a menu, you are selecting an item, that's the function.
katie: UIC with sub-components been around a while
GreggV: Areas of navigation, keyboard opening up child elements is not rare...
… tab to a big component, enter, tab to sub component of parent UIC
MikeG: As Gregg mentions, this note is not a new concept...
… if we put this detail into the SC, then that begs the question that UIC didn't mean what people used to understand.
<mbgower> I'm fine removing "Note" and putting it in as a new paragraph.
<mbgower> in the normative text.
Wilco: There is a definition in ARIA spec about descender elements, this interpretation deviates from that definition
<Zakim> GreggVan, you wanted to say "notes are explanatory of the text above it" but the content needs to be there in the first place"
<Wilco> https://
GreggV: Notes cannot add anything new. If something is already common practice, that should be reflected already by the term.
<Rachael> straw poll: 1) In SC text 2) As note
Alastair: I reviewed ARIA definitions earlier, and they are changing some of their terms, but we are stuck with some of our terms, like focus indicators...
<Wilco> 1
Alastair: some deviation is okay.
<ShawnT> 1
<mbgower> 2 but 1 is fine
<alastairc> 2, can live with 1
<MelanieP> 1
<JakeAbma> 2, 1
Rachael asks for straw poll.
<Chuck> 2, 1
<GreggVan> 1 if it is new
<joeyang> 2, 1
<laura> 2, 1
<Ryladog__> 2, 1
<jon_avila> 2
<Wilco> I will
<GreggVan> where is the exact text?
<Chuck> I will not
Rachael: who would object if note ?
<ShawnT> I will
<Rachael> Who would object if we make it SC text
<alastairc> Gregg - in the doc, "UPDATES from the meeting", the bottom note.
Rachael: who would object if SC text ?
<GreggVan> thx
<Chuck> I will not
Rachael: no objections to making this SC text, so in the interests of consensus, we can go forward there
<mbgower> :)
<Rachael> draft RESOLUTION: Add Wilco's text previously discussed into the SC text
Chairs agree that less friction, even though more prefer note approach.
<Wilco> +1
<GreggVan> +1
<Chuck> +1
<Rachael> +.5
<alastairc> +1
<JakeAbma> 1
<ShawnT> +1
<laura> +1
<jon_avila> 0
<MelanieP> +1
<mbgower> 0
<kirkwood> +1
RESOLUTION: Add Wilco's text previously discussed into the SC text
Not including the 1px perimiter metric
Moving to next topic, not including 1x perimeter metric
Alastair: The way we restructured, ignore top bit, it is much simpler. But there are some thing which do not pass...
So an analysis drops down to the exceptions. Which we also wanted to keep simple.
<Rachael> There is one change in scope compared to the previous version: When using the primary part of the new SC text, it does not allow for indicators with gradients, or thick indicators that lack adjacent contrast. However, the exception will cover almost every circumstance of that.
AC: ... there are edge cases that no longer pass. A circle is one example.
… the fail cases are where the author relies on a 1 px border.
… so trade off is between keeping prose as simple as possible , but fail some designs which might not actually be terrible (e.g. ovals).
Rachael summarizes voting from survey.
Mike Gower simplicity more valuable than allow edge cases, and one could make case that those should have 2 px border any way.
Alastair: Questions from Gundala and Oliver about drop shadows, but let us take that up in next survey.
Michail Ysonik: I would like to speak up for a little more complexity being better. We can address in Understanding or other materials.
Oliver: white background and shadows and radio buttons need more consideration.
<Wilco> +1 to GN, I spotted that too, it's strange
Gundala: The focus indicator itself might have a halo, but SC text is not clear if that would be pass or fail. I would like to add area of focus indicator to pass.
… Shadow does not decrease size of focus indicator, it reinforces size.
<Rachael> themes: Accounting for halos focus indicator, how many items now wilco,
<alastairc> Gundula - in the doc look for "Box shadow, 1px white outline inside the shadow"
<mbgower> potentially a cumulative note
Rachael: Hearing two themes: focus indicator and box shadow, and measuring non-rectangular shapes.
Melanie Philipp: If one has circular focus that replaces the indicator -- is that a fail?
<Zakim> alastairc, you wanted to talk about the halo, it's covered by the exception.
Alastair: 1 px fail for circle is fail because of need for contrast against two colors, so fall into the exception
… area of focus area has a size and contrast measurement, but thats 4 px which meets perimeter metric from previous for rectangle...
<Wilco> So a 1px outline around a checkbox is fine because it's square, but around a checkbox it fails because it's round
<Wilco> radiobutton
Alastair: but then for rounded corners, those will cut off some of that area, and not meet the previous area requirement we were working with.
MP: So is that only for shadows or the like.
AC: Crisp outline help, but also if the indicator is entirely inside the drop shadow or halo, so might not meet exception.
<Zakim> mbgower, you wanted to say "an area" is in the preamble text
Mike Gower: Maybe editorial, but "area of the focus indicator" might help resolve what is being measured...
… In the third bulllet, 3:1 contrast is against component, but that might result in same color as background instead of adjacent color.
<Wilco> +1 to "all", good catch
AC: In rewrite, change 3:1 against component to adjacent because AWK suggest for least overlap, dark outline against dark button.
… so re-write addresses that case.
MikeG: Still seems like it would be clearer with previous version.
<alastairc> MichaelG - I was just trying to minimise the difference between this and the previous version: https://
Rachael asks MikeG to propose something.
<Zakim> alastairc, you wanted to discuss the component/adjacent question and to
Gundala: Check boxes and radio buttons are not rare, and this version is requiring 2 px for radio button but 1 px for check boxes. I would prefer consistent requirment.
Alastair: I don't agree this version introduces inconsistency because it is only about shadows and halos and similar decorative effects.
MikeG passes on rerwrite.
<alastairc> I think it was 5 / 2 / 2 (Oliver changed)
Rachael: Coming back to survey, we have majority for simpler approach. I would like straw poll.
<Rachael> straw poll: 1) simpler SC text, some failures 2) more complex SC text, fewer failures 3) Go back to original wording
<Wilco> 3, can live with 2, object to 1
<mbgower> 1 then 2
<JakeAbma> 3, 2
<GN015> 2
<joeyang> 2, 3
<Chuck> 1
<ShawnT> 2
<alastairc> 1, 2 is ok (ish), object to 3
<Ryladog__> 2
<myasonik> 2
<MelanieP> 2
<jon_avila> 1
<laura> 1 or 2 are okay
Rachael: I read two as best way forward.
Chuck: Agreed.
<Rachael> draft RESOUTION: Add the 1px perimeter metric to the exception
<Rachael> draft RESOLUTION: Add the 1px perimeter metric to the exception
Alastair: The outcome of (2) means that what passes or fails will be as with previous version, so that is alignment...
… but we had so many people raise concerns with regard to complexity...
<Zakim> mbgower, you wanted to say where is the 1px going?
Alastair: multiple nested bullets might work
MikeG asks for clarification on direction
AC: Need to bring in previous bullets, might now be three level deep or complicated and / or
<Wilco> +1 to GN
Gundala: I would like parity between the 1 px and 2 px approaches.
MikeG; I feel like vote was for more complexity, but now ask is for less complexity.
Gundala: Hope we can eliminate question about halo because they could be outside of component, outside of the 1 px border.
MikeG clarifies wording about area.
Gundala: In the exception, yes, but not the SC body.
AC: I have inserted into the first of the exceptions, but that is not changing what passes or fails.
… if we go back to area in the SC body, that gets back to very complex portion at top of SC. Rewrite moves complexity into exception.
<Rachael> draft RESOLUTION: Add the 1px perimeter metric to the exception
<Wilco> 0
AC: complexity has to go somewhere, so idea is to have opening condition simple.
<joeyang> +1
<ShawnT> +1
<mbgower> 0
<GN015> + 0.8
<Rachael> 0
<alastairc> +0.5 (on the basis of moving on)
<JakeAbma> 0
<laura> 0
<MelanieP> +1
<Chuck> .5
<Ryladog__> +1
<myasonik> +1
<GreggVan> 0
<alastairc> It is in the doc now, under the "UPDATES from the meeting" heading
Rachael: seem to have some support in this direction
<jon_avila> 0
RESOLUTION: Add the 1px perimeter metric to the exception
<mbgower> decorations
<GreggVan> That is consensus - bingo
RM: did not get objections
Definition of Encompasses
<Rachael> Continuously surrounds, bounds or includes the whole of
<alastairc> https://
Rachael: issue from survey around if we include halo and decoration
Rachael: goes through agrees
<Chuck> +1 to mgower
MikeGower: concern that definition may be getting muddy if it includes decoration, so prefer to address with exceptions
Rachael: two agree with adjustment
Rachael: one something else, Wilco prefers we go back to previous version
<Rachael> theme: Go back to previous rewrite, decorative effects
<Zakim> alastairc, you wanted to talk to decorative effects / perception of UICs
Rachael, not hearing themes, other than going back, and decorative effects.
Alastair: Going back to the decorative aspect, going through examples, and not wanting to define decorative...
… discussed in Friday meeting, so it seemed better just to include the area of decoration.
… Folks on the call generally agreed to just consider the decorative parts part of the component. That whole area is the bounding box.
Gundala: Decorative is everything not needed to identify component...
… shadow example of effect that some people will not see at all, so why does that get to count?
<Zakim> Wilco, you wanted to ask if backgrounds are decorative
Gundala: Other components, like buttons, have very obvious edges.
Wilco: Does background count? Seems very arbitrary.
Alastair: You are going to get a variety of indicators, so whatever you perceive as the control, that is where you put your bounding box.
<alastairc> +1, or you put a 2px indicator in place and be sure you meet it.
MikeG: We have experimented with the phrasing. So if one put the bounding box around the whole thing, that is a pass...
<Rachael> straw poll: 1) Continuously surrounds, bounds or includes the whole of. 2) Continuously surrounds, bounds or includes the whole of except for effects that appear to be outside the boundary of the control 3) Something else
<mbgower> 1
<Wilco> 3
<joeyang> 1
<Chuck> 1
<Rachael> 1
<GN015> 2
<alastairc> 1, and anyone suggesting 2 will need to define that!
MikeG: and if one puts the bounding box through the shadow or halo, then you do a complicated area calculation. Author has a choice of their approach.
<ShawnT> 1
<laura> 1
<Ryladog__> 1
<MelanieP> 2
<Chuck> 9 1's, 2 2's, 1 3
<MelanieP> no
Rachael: more inclined to 1s, objections ?
<Wilco> already objecting
Rachael acknowledges Wilcos previous objection to visuals, and this is part of that.
Gundala: Are we discussing this again or not?
Rachael: We will come back with completed SC.
Gundala: My preference is to come back later, since I think there will be more conversation.
Alastair: Based on Wilco concern being tied to other issue, I recommend we keep moving this forward.
Wilco: How do you determine if graphical effect is part of the button or not?
Alastair: We have example of that in the document.
<mbgower> makes sense to me
Wilco: What about the button in div and div has the shadow.
<joeyang> same
AC: Criteria is if it seems like part of the button.
<Rachael> draft RESOLUTION: Accept shorter definition with 1 objection and a concern about handling focus on the whole page
<alastairc> If it is perceived to be part of the component...
Rachael: I am still tally support for the simpler approach, noting Wilco's concern.
<Rachael> draft RESOLUTION: Accept shorter definition with 1 objection and a concern about handling focus on the whole page
<Chuck> +1
Wilco agrees that minutes are okay.
<mbgower> +1
<Wilco> -1
<alastairc> +1
<Ryladog__> +1
<MelanieP> 0
<ShawnT> +1
<joeyang> +1
<jon_avila> 0
<Chuck> 7 +1's, 2 0's, 1 -1
RESOLUTION: Accept shorter definition with 1 objection and a concern about handling focus on the whole page
Rachael and Alastair discuss how proceed towards CFC
AC: I think we need Understanding document updated before CFC
<alastairc> If anyone can create a good definition of "decorative" aspects, that would be very useful...
Wilco: When will we be reviewing final SC text?
Wilco: Will we go to CR with such a significant change?
Rachael: Agree that we will need conversation, might be email
Wilco request review on final terms.
AC: Does not trigger new CR
<jon_avila> Thank you.
<mbgower> Thanks