<Jennie> scribe: Jennie
AlastairC: Any announcements?
<AWK> +AWK
Chuck_: If you added your present plus before, please try again
AlastairC: We are trying to work
through the last few issues.
... We were trying to find a better way to say that the parts
of the focus indicator that don't meet the requirements are
ok
... Also how you test when you cannot inspect the code.
... There is a list of updates in the link
... Going through the comments
... Starting with Wilco's
... Wilco said accurately determine the shape of the interface
but not how
... You don't have an inspectable chunk of code to determine
the size in certain situations
... He is suggesting visible pixels of the control
... There was discussion about whether to use the pixels
... I was hoping we could default to it is the component
regardless of the pixels in it
... Then for the non-easy examples you can reduce down to the
visible size of the component
... I think that is what the note was intended to do
<alastairc> "Note: If the component has a visible boundary smaller than the hit area, or the size of the component is not available, the minimum area can be taken from the visible boundary."
AlastairC: Yes JF we did discuss
that
... We added that because the scenario where you have a link
within a card that makes the whole card clickable
... But it doesn't increase the size of the control
... You can have a small, visible thing, and you cannot access
the code to understand the hit area.
<Zakim> mbgower, you wanted to say the bounding box is of the area with sufficient contrast
mbgower: This is in regard to
Wilco's comment
... The bounding boxes is going to be the area that's meeting
the contrast requirements
... There are shadows, blended backgrounds - they will not be
included
... The contrasting area - the bounding box shape would be
AlastairC: Wilco's point is that
within the definition of bounding box
... which all the points of the shape lie
... they rely on the shape of the user interface control
mbgower: We have already said contrast ratio of 3:1
AlastairC: The shape of the control, whereas the contrasting area is the focus indicator that goes around the control
mbgower: In the scenario where the control is bigger?
AlastairC: I'm not sure
Wilco: You are right - that's
what I mean
... You don't have the shape of the user interface
component
... Which pixels are part of it, and which are not?
mbgower: We are talking about the focus indicator, which in most scenarios are the area we are talking about
AlastairC: But it's the base of
the perimeter
... It is defining the size of that for minimum bounding
box
... We are going back to if you are in HTML - you just pick the
boundary box
... But if you are in a Canvas element you will need to put it
around the visible pixels
mbgower: I can live with it, except when the focus indicator is inside
AlastairC: Focus indicator or control shape?
mbgower: maybe I'm just not understanding
AlastairC: Wilco - I raised using the note
(reads note)
scribe: Does that help?
Wilco: What is the visible boundary then?
AlastairC: If you have a border
or background within the component
... and you fit your boundary box around it, it would be
that
Wilco: I need to see the text again
AlastairC: I will go through other comments and come back to it
<mbgower> +1 to that change
AlastairC: Gundala's comment
suggests (reads her suggestion from the survey)
... It makes sense to me
... Any objection to the update?
<alastairc> Agree with Gundula's update to bounding box. "Where a component consists of visually disconnected parts, such as a link that wraps onto multiple lines in a continuous text, each part is considered to have its own bounding box."
AlastairC: We will proceed with
that one
... Andrew asked about why we are discussing adjacent
contrast
... It is because being sure it is adjacent to colors in the
component
... A dark pixel around a dark button makes it almost
invisible
<mbgower> We should ensure language in the Understanding document addresses AWK's question.
AlastairC: We originally had adjacent to all colors
AWK: This says the contrasting
area - the focus
... Has a contrast ratio of at least 3:1 in the focus
component
... Whereas non-text contrast just says against adjacent
colors
AlastairC: I think we had taken that not to be the case
<KimD> +1 to AWK
AlastairC: In non-text contrast there is some confusion between the actual element itself and meeting adjacent colors
<jon_avila> for sc 1.4.11 it could be any adjacent colors - you choose - background or component.
<david-macdonald> I could respond
AlastairC: I think we decided it is not applicable within the component, at least for focus
<mbgower> Adjacent to the component
AWK: Do we say in non-text contrast that the focus does not have to contrast against adjacent colors if they are part of the component?
AlastairC: I think so, yes
David-Macdonald: At the time, as
soon as focus indicator lands on the component, it becomes part
of the component
... Then it has to contrast with the background
... not the component itself - what was there before
<mbgower> "For user interface components 'adjacent colors' means the colors adjacent to the component."
<mbgower> that's from the Understanding doc
AlastairC: I remember there were other scenarios that didn't make sense if we did it the other way around
DM: took me a while to get my head around that it was part of the component
Jon_Avila: my understanding was
that if it was on the border, it says adjacent, but doesn't say
adjacent to what
... It would be up to the person testing or designing
<alastairc> acm mb
mbgower: The wording in
1.4.11
... We are talking about adjecence to user interface components
-
... We are talking about the background adjacent colors
... (reading from the text) means colors adjacent to the
component
... I agree that we should have pictures to make it really
explicit
AWK: OK, that sounds fine
... That makes more sense
... But, I agree about the Understanding content
... Because I have not looked at this and thought about it - I
didn't remember. It is possible that others will run into the
same problem
AlastairC: Yes
GN015: I remember that the
requirements also has the exception that it may be low as long
as the indication area is at least 2 pixels wide
... The indication is only that it becomes larger
... Mentioning colors explicitly here
... which is not tin the non text color requirement
... I am not happy as it is - but this is the difference in
having it explicitly here
AlastairC: OK.
... Going back to Wilco's point
... I was happy with it in conjunction with the note
... because it would be for the control, but if you can't tell
how big it is, then it is the size
Wilco: Why isn't it always about the size?
AlastairC: Because if you take a
typical link or flat design button
... You will have to do more calculations
... Compared to just saying "It's the link"
Wilco: Don't you have to do that
anyway?
... If the visible boundary is smaller than the hit area (Like
a text link)
... There is often padding around it - above and around
... This makes the visible boundary smaller than the box
AlastairC: What if you are
defaulting to it's the component?
... We are saying it can be taken from the visible boundary,
not that it is the default
... If the component size isn't available, or the hit area has
been artificially expanded
... But we are defaulting to the component size
Wilco: That's not how I
understood you previously
... If you have a rounded button - you are saying you would
take the border box, and not the circle around the button?
AlastairC: Is the border box larger than the circle?
Wilco: yes
AlastairC: Yes, but what we are saying is you can take it from the visible boundary if you taking that approach
GN015: I have a question about
the visible area
... You pointed out that if the hit area is not available
... If it is in the position of the end user - they may not
have the knowledge to retrieve the actual hit area
... Why don't we always allow to take the visible area?
<Zakim> mbgower, you wanted to say we need to be cautious of outliers overcomplicating the message
mbgower: I want to emphasize that
the easiest thing to implement is to put the outline around the
hit area and you have sufficient contrast
... Focusing on the outliers distracts
... Yes, we need to make sure they can be measured
consistently
<Zakim> AWK, you wanted to ask about the 4 CSS pixels and the 2 CSS pixels
mbgower: But we want to make sure the way most people will tackle it is easy to understand
AWK: In the shape section - can
you explain the 4 CSS pixel lin
... That is 4 CSS pixels thick?
AlastairC: Yes
<mbgower> the word "thick" was in there at one point!
AlastairC: It is an alternative
measure that makes sense when you have something like a thick
line
... that can have a variable width
AWK: This gives us a value that if someone decides the focus is a little star within the component - it gives something to measure against
<mbgower> Let's put the word "thick" back in
AWK: (reading from the
text)
... If the bounding box is 10 x 10
... or 10 x 20
... In that case: 40 CSS pixels in area
AlastairC: Yes
AWK: No thinner than 2 CSS pixels
says that whatever you wind up with has to have a thickness of
more than 2 CSS pixels
... If I have 40 as my area for my box
... And my focus is a diagonal line that is 25 pixels
long
... I made it thinner than 2 CSS pixels then it would fail
AlastairC: I think the intent is
that if you have a triangle
... An extended one with a thin area at the top
... 1 px wide, 10 px tall
AWK: I think the problem I have
is that we are saying the contrast area is at least as large
as...it makes for a very hard to parse sentence
... Let me think if I have suggestions
<KimD> +1 to AWK
AlastairC: This sentence has
expanded since we started
... We are looking for where we allow a smaller area
<mbgower> the area of a 4 CSS pixel line along the shortest side of a minimum bounding box of the unfocused component, and is described by a line or shape no thinner than 2 CSS pixels.
AlastairC: Mike was saying we are trying to keep the primary message as simple as we can
Wilco: We are trying to express
math in plain language - I'm not sure simple is a reasonable
expectation
... I don't know why we are trying to save the border box
AlastairC: We would be saying the
contrasting area is 1 CSS px thick perimeter
... Any changes would be on the definition of perimeter
... It will be difficult because what about those things that
don't have an easy visual boundary
... You would be making some sort of boundary around the
text
Wilco: We had discussed saying
either the exact outline, or a box drawn around - whatever is
smallest
... That is the perimeter
AlastairC: We would be relying on the minimum boundary box for both size rather than perimeter
Wilco: The perimeter of the minimum boundary box
AlastairC: Yes, but I don't want to use both if we don't have to
AWK: I have a suggestion
... It doesn't account for the perimeter bit
... It makes a couple of other changes
<AWK> https://www.irccloud.com/pastebin/yfdJocmg/
AWK: Instead of "atleast as large
as" in the top
... There are 2 bullets
... (reading from his suggestion)
... I changed the order of the 2
... the 2nd one becomes called out as the exception
... The concepts were being intermingled
... because the size comparison was in the introductory
text
*Thank you Chuck!
<Chuck_> awk suggestion: Minimum area: The contrasting area is:
<Chuck_> • at least as large as a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component and is at least 2 CSS pixels thick, or
<Chuck_> • at least as large as a 1 CSS pixel thick perimeter of the unfocused component
AlastairC: Is it the fact that it has an additional requirement on the shape?
AWK: yes
... We are trying to say there is a calculation you can make in
1 of 2 ways to determine the area
... a quick ring around the component
... or by calculating the area of a line around one line of the
component
... Then if you are doing it this way, it must be at least 2
CSS px thick
... But, someone could say they will calculate the area of a 1
CSS px thick unfocused component ...Perimeter:
56
... If I had a 1 CSS px wide line moving around the inside of
that component, that would satisfy it
AlastairC: Yes?
... It is a small component
AWK: Why does that get away with a 1 CSS px line?
AlastairC: It is larger
<alastairc> https://alastairc.uk/tests/wcag22-examples/focus-more-visible-5.html
AlastairC: If you have a
square
... That's where you come to a similar area
... Then once you start lengthening things out
... You get much less area
... Thinner = less area from the shape
... It depends on the shape
AWK: OK
AlastairC: We are defining a
baseline
... It should be in practice way simpler than the
discussion
... In terms of the suggestion - did you just swap them?
AWK: The lead-in text is
different
... Because it didn't separate out the "and no thinner"
... In the current one: shape - the area of CSS px line, and no
thinner...was tripping me up
... Contrasting area is, and 2 CSS pixels thick - makes it more
clear to me
... If people prefer the existing wording, that's fine. Just
offering this as a suggestion
<alastairc> Poll: Current wording (1), Proposed update (2) f
<alastairc> 1
<david-macdonald> 1 fine either way though
<AWK> 2
<Chuck_> 2, no objections to 1
<Wilco> no preference
<GN015> 1
<laura> 1
<ben> 1
<KimD> 2, but still complex
<JF> slight lean to 1, but either works
<Sukriti> 1
<jon_avila> Nothing in the new SC indicates that the minimum focus areas need to be consecutive
<Rain> 2
<johnkirkwood> 2
jon_avila: say we have something
that is 2 pixels wide, but it doesn't have to be
contiguous
... as long as the total area adds up to 4 pixels
AlastairC: Yes, you could do a checkered patter with blocks of 4 pixels
<Raf> 0
<AWK> 8:39 in IRC Mike
AlastairC: Yes, that is
possible
... but if it is at least more than 1 pixel it bumps it up
Chuck: I think 1 is the winner
AlastairC: OK, we will stick with 1
<mbgower> 2
<AWK> a tie
AlastairC: Let's continue with
Wilco's point
... For Wilco's point the change would be in the outline
bullet
<alastairc> "Outline: the area of a 1 CSS pixel thick perimeter of the unfocused component,"
<alastairc> "Outline: the area of a 1 CSS pixel thick line around the minimum bounding box of the unfocused component"
Wilco: sorry, that doesn't quite work
AlastairC: I am trying to figure out what that would mean in this context
mbgower: I do think that the
proposal could work - it seems to read more clearly
... I can live with either
AlastairC: I am in that state of
mind - we want to get something out for review
... Things have changed a lot
... I want to get through everything we can
<Wilco> 1 CSS pixel thick perimeter around the visible pixels of the unfocused component
AlastairC: Wilco - what would
work for that outline?
... Keep perimeter rather than minimum visible bounding box
Wilco: yes
... We can have a note in the Understanding Document
... to say that visible borders should not include shadows or
glows
AWK: This brings us back to
whether it is around the component, or part of the
component
... for that perimeter
Wilco: Around
AWK: In the definition of
perimeter it is calculated to be inclusive of the area of the
component, and I think
... we are saying additional to that, which would change the
calculation
... to 2y+4
<JF> +1 Andrew
Wilco: good point
<johnkirkwood> +1 Andrew
AlastairC: I think the bigger
change is that for components which have padding but no border
or background
... the requirement is then less
... which may not be a bad thing
... It just triggers more people to do calculations
Wilco: If they have a border around it, they are good always
GN015: If you discuss the perimeter of the text people might follow the curves of all the letters
Wilco: good point
<johnkirkwood> +1
Wilco: then we would still need the trigger of the boundary box
AlastairC: We still need some kind of word
Wilco: Bounding box isn't really a box
<Rain> "perimeter of the text area"
<AWK> Why isn't it a box?
Wilco: that doesn't need to be a box
AlastairC: We have box in the definition
AWK: I thought we were saying it was a box
<alastairc> "minimum bounding box: the smallest enclosing box within which all the points of a shape lie."
AWK: If there was a circle, with
a square bounding region
... there is still a box around it
<mbgower> maybe we should say rectangle
AlastairC: That does increase the requirement
<JF> AND it's always a box
<johnkirkwood> text area? highlight area?
AWK: But for a circle you could still have a 1 px thick perimeter of the visible component
<mbgower> bingo
<JF> @mgower in CSS they speak of the 'box-model'
AWK: You would be looking at one bullet, not the other one
Wilco: No you wouldn't
... Because of the 2 px requirement
... I tried to take out the 2 px minimum requirement and that
gets a lot more complicated
<david-macdonald> explain please
AlastairC: If you had a 100 pixel
square
... you have 400 pixels
... but with a circle you have 314 - quite a bit less
... It does increase the requirement for circles
<david-macdonald> why not a 1px around a circle.... ?
AWK: When we said perimeter of the circle
AlastairC: Previously we said it
was 1 CSS pixel of the focused component
... or whatever your browser would tell you about the size of
the component
... and the min area can be taken from the visible
boundary
... That was to try to cover the grey area
AWK: I don't understand the
problem with perimeter
... If you look at the continuous line which comes from the
visible boundary
... If you choose that instead of the bounding box
AlastairC: I agree with that, but Wilco wanted to have something in the SC text that is applicable across scenarios
<mbgower> It would be sufficient
David-Macdonald: Are we saying a circle with 1 px would be sufficeint because the hit area is a square?
AlastairC: In the current text I
would say that was sufficient
... If we go with the bounding box
... The area doesn't quite come up to the same
... The underlying code - that circle is within a square
<Zakim> Chuck_, you wanted to ask for scribe change at top of hour
<Sukriti> scribe:Sukriti
Alastair: current approach - you
can tell what size the control is and if there is a discrepancy
between underlying code and visible area, you can fall back on
visible size. Assumptions built in there
... Alternative is bounding box route and use as a default.
Different types of control will be different. Fairly
arbitrary
... If testing, bounding box approach better
... can't do both at the same time
davidm: testing with bounding box is a great win
Alastair: In other areas of the web page, might be harder
<mbgower> Is this a decision killer for anyone in either way?
<alastairc> Poll: Current text (1), Taking bounding-box approach to all sizing (2).
<mbgower> Either approach is okay, prefer 1
Davidm: could we phrase something
like. If you have a non-boxlike shape, you're basically going
to be doing 2 pixels
... is that a better way of explaining it
<JF> A complex shape liek that will still have a box-model hit region (unless it's an image map)
alastair: for a complex shape
like a star, 1 pixel outline along the shape is going to be
longer than a bounding box
... other shapes will be more
JohnF: in native html, everything
is going to use the box model
... in an image map, you can define a polygon region
<Wilco> There are more
JohnF: the other concern is
floating content
... z index layer than other content. Not measuring on the same
plane
... let's work with what we've got (box model)
<alastairc> Poll: Current text (1), Taking bounding-box approach to all sizing (2).
<GN015> prefer 1
<Chuck_> 2, struggle with 1
Alastair: star passes more easily, circle doesn't pass as easily
Wilco: buttons with rounded corners too, not just circle
<jon_avila> why can't we allow either?
Wilco: all would need a 2 px border if we go the bounding box route
JohnA: Can we allow either?
<JF> I like the either/or approach
Alastair: That's what we currently have. Open to objections
davidm: do we mean the visible unfocused component in the current wording?
Alastair: the area of the component in the code. If there is a visible boundary, the area can be taken from there
Davidm: The proposed language seems to say that
Alastair: 1 pixel perimeter
around the bounding box of the unfocused component
... doesn't take into account the shape of the component
... As an author if you can just say 1 pixel outline with a
contrasting color, won't be more complicated than needs to
be
JohnK: the border radius has
never been discussed
... visually highlights the focus area a lot
... default is 2-4 pixels
... this would make it less accessible
<Zakim> mbgower, you wanted to address Jon's comment
MikeG: they're going to have to
increase the border
... in css you would define the border as a 2 pixel solid
color. By introducing a border-radius, you're making the line
shorter
... you're going to have to bump to 2 px to accomodate
<alastairc> Current approach (1), Bounding box for everything (2)
<ben> 1
<mbgower> 1 preferred
<david-macdonald> 1
<Rain> 1
<jon_avila> Current approach
<alastairc> 1
<Wilco> ... 3?
<johnkirkwood> 1
<JakeAbma> 1
<Chuck_> 1
1
<Wilco> My option 3: Area: The contrasting area is at least as large as a 3 CSS pixels border along the shortest side of the unfocused component box.
Mikeg: Is there a problem with getting this out to the public and opening an issue?
Wilco: Don't mind if we can revisit
Alastair: Anyone objecting to current text?
RESOLUTION: Accept the amended updates to the SC Text and understanding document for Focus Appearance
<mbgower> is "thick" being added?
<mbgower> sorry
<mbgower> second sub-bullet
Alastair: Techniques are not too
complicated but defining visible is
... what we're discussing is not changing requirements
... focused on testing niche cases
Kim: Wording is more complex than
it needs to be
... we know more than a designer or developer
... if we see issues, not sure how someone without specialized
knowledge will parse
Alastair: The intent of the
understanding document makes it pretty clear
... if there is a way to make the wording simpler with same
requirements, all in
<Zakim> Chuck_, you wanted to ask about simplifying
Chuck: I like the idea of simplified but every try has been met with exposure to limitations
<david-macdonald> "make it a simple as possible, but no simpler" Albert Einstein
Alastair: Allowing a bit of
flexibility, got a AAA version that is harder to meet. Can also
explain in the understanding document
... will be voting against having this requirement at all
<alastairc> Poll: Accept response (1), Something else (2)
<Zakim> Chuck_, you wanted to ask about not including it?
Chuck: Simplest approach is to not include it because haven't been able to simplify further
<mbgower> 1 add suggest we will be updating hte Understanding document
<jon_avila> what is the resposne?
<GN015> 1
<alastairc> https://github.com/w3c/wcag/issues/1439#issuecomment-802405219
<KimD> 2 - same as my comment. But also agree that the concept is needed.
Melanie: Potential alternative. Include exception for using browser default focus indicator and leaving door open for custom indicator
<johnkirkwood> +1 to Melanie
<KimD> +1 to Melanie - that exception is a good idea
<jon_avila> The Firefox indicator is hard to see and we've tried for many many years and I have not been able to move it.
<Chuck_> 1, because we will have another round of review, and I'm not in favor of ditching (yet)
<ben> 1
<jon_avila> I am opposed to dropping the SC.
MikeG: It wouldn't hurt to say in the response that the understanding document will be updated
JohnA: If you were using the default focus indicator, and it meets the requirement you don't need a custom indicator
<Zakim> Chuck_, you wanted to ask say how we got to the possibility of dropping
Alastair: Likelihood of browsers updating indicators is higher if this is part of 2.2
Caryn: There have been
improvements but still difficult to understand. We have done
straw polls in the company
... current state is not clear to people
<mbgower> We don't have techniques in. that would help.
Alastair: Do the teams look at the understanding document as part of the process?
Caryn: We asked them to
<david-macdonald> most dev teams don't look at understanding in my experience.
RESOLUTION: Accept the proposed response to address issue #1439
Alastair: Will be CFCing the SC and looking at understanding document text
<alastairc> "The offset from A to B may be different than the offset from B to A, if the size of these targets differs."
Alastair: Did everyone get the A
to B aspect?
... with editorial changes incorporated, is everyone happy to
accept?
... to put in a CFC for wide review
<Chuck_> +1 to Alastair
<david-macdonald> +1 to amendment
+1 as well
RESOLUTION: Agree with the updated and amended SC text for Pointer Target Spacing
<jon_avila> Open issue related to the Firefox default focus indicator https://bugzilla.mozilla.org/show_bug.cgi?id=1284235
This is scribe.perl Revision VERSION of 2020-12-31 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/increase the radius/increase the border/ Succeeded: s/You're making the line shorter/By introducing a border-radius, you're making the line shorter/ Default Present: JakeAbma, Jennie, Sukriti, Raf, jon_avila, juliette_alexandria, alastairc, Chuck_, ben, Nicaise, johnkirkwood, MichaelC, JF, Rain, AWK, MelanieP, morr, MarcJohlic, mbgower, KarenHerr, stevelee, Wilco, StefanS, Laura_Carlson, Francis_Storr, oliverkeim, Rachael, GN, david-macdonald Present: JakeAbma, Jennie, Sukriti, Raf, jon_avila, juliette_alexandria, alastairc, Chuck_, ben, Nicaise, johnkirkwood, MichaelC, JF, Rain, AWK, MelanieP, morr, MarcJohlic, mbgower, KarenHerr, stevelee, Wilco, StefanS, Laura_Carlson, Francis_Storr, oliverkeim, Rachael, GN, david-macdonald, morr4, GN015 Regrets: Detlev, SarahH Found Scribe: Jennie Inferring ScribeNick: Jennie Found Scribe: Sukriti Inferring ScribeNick: Sukriti Scribes: Jennie, Sukriti ScribeNicks: Jennie, Sukriti 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]