Meeting minutes
Chuck: Does anyone want to introduce themselves or have new topics?
WCAG 2.2 Page break navigation (Q1 only) https://www.w3.org/2002/09/wbs/35422/wcag22-page-break-nav/
Chuck: Our first question today is Revision to the definition of Page break locators #2155. [reads issue and results]
… reads agreements. Bruce reads with adjustment. Did you want to speak to that?
Bruce: I like that we are referencing a print page. Do we define page break elsewhere?
results - 5 agree with update, 1 agree with adjustments, 1 something else.
Bruce - Page break isn't meaningful in a web page.
alastairc: Not with our definition of webpage.
bruce_bailey: then I think we need to be a bit more descriptive. Its a page break location relative to something formatted for printing or hard copy.
Chuck: You said you had some thoughts but may still need refining.
<bruce_bailey> right, mostly digital documents (!) that reference a dead-tree version
alastairc: In answer to your question in the survey around are we talking about paper or not. Its not necessarily paper. It can be textbooks or PDFs. Its not printed out but has inherited the concept. That's why it says not a printed document but serves the same purpose.
<Zakim> GreggVan, you wanted to say can be edocs that have pages too. So printing isnt quite right. Maybe
GreggVan: Its something to say "Virtual pages in electronic documents, books etc" That is a lot of words. It seems like that could go in the understanding documents. Perhaps Virtual Page breaks.
… they are visually page breaks and referred to as page breaks. Or is it just ok to say equivilent of print page breaks which is pretty clear and then handle in understanding.
Chuck: Reads Wilco's comments
<alastairc> Topics: Does it cover page-break-after? Is it over-prescriptive.
<kirkwood> +1 to Wilco’s comments
Chuck: Wilco's comments open up a new line of thought. Bruce, is the current definition such that you strongly oppose it and want more work on it or do you have a hard no.
Gregg: I am still trying to digest Wilco's comment. It doesn't matter where the headers are. The page breaks help location not navigation
alastairc: I think there are several things there. Page break after - That is the opposite direction than what we are trying to cover. If you set a page break after in a webpage it dictates how the webpage is printed. That is the opposite of what we are trying to do which is to line the webpage up with the print version.
<bruce_bailey> current line under discussion:
<bruce_bailey> <p><a>programmatically determinable</a> destination markers that are arranged in a meaningful sequence to represent a locator serving the same purpose as page breaks in a printed document.
<Zakim> bruce_bailey, you wanted to say i favor having this sc in 2.2
alastairc: with regards to the classroom usage and whether it is overly prescriptive, I don't think it is because it is very narrow. I agree with Gregg that it assumes headings, etc. This was brought to us by edoc publishing group as a known gap because its not about e-readers. It applies to e style books rendered in a browser. Its clear in the understanding document. It applies to e-pub books when rendered in a browser. Its only when you are doing
this on a browser that this becomes an problem and its an author problem becuase there is no user agent mechanism. Browsers don't so it belongs here.
bruce_bailey: my concern is a general one. I think this is important for 2.2 for the reasons Alastair outlined.
<GN015> FOn platforms where it is no problem it may as well be applicable. Gives the chance to report a success (fulfillment).
MelanieP: I just wanted to mention Wilco is on holiday. I'm representing him a bit. I wanted to ask is there an answer to his question about would the normative cover the CSS property? The normative is written technology agnostic. The normative is what creates the requirements. It isn't clear to me that the normative plus the definition doesn't keep it out of scope. Potential for unintended consequences if the normative isn't clear.
<Zakim> alastairc, you wanted to say no, they don't have an ID
<bruce_bailey> I don't agree this is epub only.
alastairc: This isnt' epub. We are not trying to apply it to that.
… does it apply to the CSS attribute. I don't see how it could. There is no number so I don't see how it could be applied.
<Chuck> Poll: 1) I support dropping this SC. 2) I support keeping this sc (may need more work on definition)
bruce_bailey: There are important problems with word online, pdfs, and other things. Not just epub.
<alastairc> Bruce - the user-agents cover PDF/ePub/Word
<Ryladog> +1 to Bruce
bruce_bailey: My concern is that someone might say the document won't be printed so it isn't applicable.
MelanieP: The definition proposed. [reads definition] Is that not what the CSS property does? It came from epub and serves epub. Isnt' that in the understanding?
alastairc: Yes [reads definition alternatives]. Maybe that is a bit easier. The CSS property doesn't set a location for the thing. It says this is where to break a page in the previous version. Maybe we need to pull the language "in relation to others in a set". Maybe we don't make the change if it causes confusion.
… I think the part he wanted to get in was the "serves the same purpose" but maybe we need to keep the same language.
<Chuck> Poll: 1) I support dropping this SC. 2) I support keeping this sc (may need more work on definition)
<Zakim> bruce_bailey, you wanted to say "others is the set" is "other sets of WEB pages"
bruce_bailey: The problem as I understood it with the original definition. The alllusion to other pages in a set was confusing with the language we use for webpages. The other set is problematic.
<Ryladog> Collection of pages?
Poll: 1) I support dropping this SC. 2) I support keeping this sc (may need more work on definition)
<Ryladog> 2
<ShawnT> 2
<jon_avila> 2
<GN015> 2
<Chuck> 2
<bruce_bailey> 2
2
<Regina> 2
<alastairc> 2
<MelanieP> 1 representing Wilco
<kirkwood> 1
<Raf> +2
<Zakim> Chuck, you wanted to poll on dropping this SC
<alastairc> Ryladog - Doesn't work with our definition of pages, where a 'book' in a browser will generally be represented as one 'page'
Chuck: We have a couple of individuals who support dropping it but most are in favor of continuing to work it.
Melanie: consider moving it to AAA or mark it as at risk to protect the CR.
alastairc: I would need to check with Michael. I think things are at risk before CR but the idea is not to have risk going into CR. Shadi? Chair hat on: Having talked to experts in this area on this topic and they are in favor of the fact this is needed, our primary concern should be around fit. Not gathering in scenarious that are not intended. If its not doing that, I would trust their judgement as to its validity.
<MelanieP> https://
Shadi: Clarifying, I am no longer W3C staff. Michael would be the normative reference but unless the process document has changed, ideally we would not have at risk parts going into CR. It is possible that features are marked as at risk, it doesn't jeopardize it. Example of 2.1 with at risk examples. These were looked at during the CR phase. I think what Melanie is saying is correct but please double check with Michael.
MelanieP: I added a link to the process document about that topic.
Chuck: The sentiment of the group but John Kirkwood, not putting you on the spot bu if you want to speak, please do.
kirkwood: I am very much in alignment with Wilco on this. I have a difficult time seeing how this could move forward. I would love to do this properly but the amount of work to do this is huge. There is a lot to take on with this.
Chuck: For those who voted for dropping it, will keeping it likely lead to a formal objection? I would like to understand whether we should focus on.
kirkwood: I do think it could be reworked but I wish you the best of luck.
alastairc: In John's comments, my perception is that its very narrow. I'm curious as to why it presents such a difficulty. Its a niche but important scenario. I'm wondering what the concern is.
MelanieP: Answering Chuck's question. I think a formal objection is a distinct possibility.
Chuck: Then we should continue conversation on keeping or not. Regarding web pages, the one use case is in regards to documentation that is presented in html format where users have the option to either print them or use the documentation online. I think that's kind of a niche where this may be applicable.
<jon_avila> +1 to Bruce - strongly favor keeping it.
bruce_bailey: I think its also applicable to situations where you have pdfs where the author hasn't kept the visual print page in synch with the programatic print page. Even if people don't htink they could fail a perfectly formatted PDF, then I think this is a much needed feature.
MelanieP: I just wanted to reiterate the concept of marking it at risk so we can continue the conversation. Wilco is not here.
alastairc: I am not sure there is a need to mark this at risk because Wilco's comment just misunderstands the criteria. If we don't have a technical reason for marking it at risk, I don't think that's a valid route to go down.
… as you note, he's not here.
<Zakim> Chuck, you wanted to propose a path forward
Chuck: What if we leave the possibility of marking it at risk and we engage Wilco. We don't make a decision today. Or we can vote on definition and then circle back with wilco.
<alastairc> PRoposed: "<a>programmatically determinable</a> destination markers that are arranged in a meaningful sequence to represent a locator serving the same purpose as page breaks in a printed document."
Chuck: Current definition which hasn't changed.
MelanieP: A question on timing then. The holidays are here. Are you still trying to get to CR before the holidays?
alastairc: We also still have visible controls to get to in January so it will continue.
Chuck: That conversation will continue on. I would like to focus on proposed definition.
<kirkwood> - I am not willing to block, go with current consensus given Alastairs characterization
<bruce_bailey> PR link: https://
<kirkwood> +1
<Chuck> proposed RESOLUTION: Accept PR 2160 to address issue 2155, there will still be conversations regarding keeping or dropping this sc.
<kirkwood> +1
<Ryladog> +1
<ShawnT> +1
<Jemma> +1
<bruce_bailey> +1
<Chuck> +1
<alastairc> +1
<GN015> +1
+1
<jon_avila> +1
<MelanieP> 0
RESOLUTION: Accept PR 2160 to address issue 2155, there will still be conversations regarding keeping or dropping this sc.
WCAG 2.2 Focus appearance (New Q1, then Q2-4 you may have filled in already https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/ Chuck]
<Raf> +1
Question 1 - Focus appearance and user-agents
<bruce_bailey> Chuck: number of question, adjusting topics
<bruce_bailey> from survey: Following the discussion on focus-appearance complexity, a question was raised about whether the user-agents are fulfilling the user-need.
<bruce_bailey> Chrome and Edge (about 75% of desktop browser share) now include an option to add a forced focus indicator.
<bruce_bailey> There were also points made about the difficulty of implementing the SC, although this was contested both on the actual difficulty, and that we have got to this point by trying to balance the user need with the flexibility and complexity.
<bruce_bailey> Please consider how/whether an SC should account for browser variations. For example, is a (fairly hidden) setting in a browser fulfilling the user need? Would author effort on this SC take away from other requirements?
<bruce_bailey> One possible way forward is to add 'mechanism is available' language to explicitly allow for browser-based solutions. For example, "A mechanism is available so that when user interface components receive keyboard focus, an area of the focus indicator meets the following:"
<bruce_bailey> Do you think we should:
<bruce_bailey> Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
<bruce_bailey> Add 'mechanism is available' language.
<bruce_bailey> Drop both focus-appearance SC (i.e. you consider that the browser features fulfils the need).
<bruce_bailey> Drop the AA SC but keep the AAA SC.
<bruce_bailey> Chuck sumarizes voting: 6 for add mechanism
<bruce_bailey> 2 for carry on
<bruce_bailey> melonie voted to drop
<bruce_bailey> also long respons from wilco
<bruce_bailey> Melonie (from survey): Or allow an exception for relying on browser default as in 1.4.11.
<bruce_bailey> Also... I object to the characterization of a setting in a browser's Accessibility settings as (fairly hidden). If you are willing to assign the large effort of meeting (and testing) this SC to every site owner in the world, surely assigning a little effort on the part of users to understand the accessibility features of their user agent is... reasonable?
<bruce_bailey> Chuck: i am not sure how wilco voted
<bruce_bailey> Alastair: Wilco did not vote because answer depends on how we address next question, mostly due to testability
<bruce_bailey> Chuck: okay, wilco tentatively supports keeping it
<bruce_bailey> ... should we skip to next
<Jemma> 2. Using target-area as the basis for size metrics
<Jemma> Wilco would like to use the target-size of the component as the basis for size metrics.
<bruce_bailey> Alastair, most people consenssed on next question, but I prefer to skip dependance
<bruce_bailey> chuck: reading from AWK answers
<bruce_bailey> ... most responses favor keep but add "mechanism" language
<bruce_bailey> Alastair: paraphrasing AWK, we have moved language back-and-forth a bit already
<bruce_bailey> Chuck: reads from Jonathan Avila commen
<bruce_bailey> Jon concluded: Thus, you can just say ZoomText will always meet this and the author doesn't need to do anything - the SC is totally not needed.
<bruce_bailey> Jemma also agrees that no change is needed to SC, that question can be addressed in Understanding
<Zakim> alastairc, you wanted to talk to mechanism
<bruce_bailey> Jemma: drafting consider including "mechanism is available" but that weaken requirment
<bruce_bailey> Alastair: Mechanism is available is interesting because it does not actually change the SC requirement.
<bruce_bailey> ... i suggested this term because it makes it clearer that authors MIGHT rely on UA
<bruce_bailey> ... while surfacing the potential, does not change fundamentals of SC
<bruce_bailey> ... and we have UA which are poor on this detail
<Chuck> +1 GN
<Jemma> -1 all the users do not know how to use available mechanism
<bruce_bailey> Gundala: We have similar barrier where authors left off the hook because of high contrast modes available in there operating sytesm
<alastairc> Bypass blocks has similar language, which includes landmarks & screenreader...
<bruce_bailey> ... but this is still a gap. Allowing ZoomText as a "mechanism" is not consistant, because that is AT.
<bruce_bailey> Melanie: Agree that considering ZoomText or other AT as solution is not sufficient
<bruce_bailey> ... a user needing high contrast setting on a phone to adapt poor author content contrast -- that is one thing -- not great, but okay
<bruce_bailey> ... but focus is a UA function -- that is very different case !
<bruce_bailey> Jon Avila: language of mechanism is very different than User Agent default
<Jemma> +1 to Jon
<bruce_bailey> ... mechanism should NOT be understood to include add-in AT
<Jemma> +100 to jon
<bruce_bailey> ... agree that FireFox -- as an example which has been around and not addressed -- there is a gap
<bruce_bailey> ... mechanism is available -- has not been sufficient. We need pressure on browser makers.
<Jemma> +1 for easy fix with one line of css
<bruce_bailey> Kaie Haritos: Author can fix pretty easily via css. It is necessary for us to maintain as requirement
<bruce_bailey> ... It impacts end users.
<MelanieP> thanks Gregg
<bruce_bailey> GreggV: Melanie has changed my mind. Mechanism is available is not strong enough....
<bruce_bailey> ... old idea was that if enough browsers had feature, we could kind of wave off the requirement
<Chuck> Jemma, I think the conversation is slowly shifting.
<bruce_bailey> ... and per our definition, UA includes AT ... but over time that has not demonstrated to strong enough to solve some problems
<jon_avila> focus-visible allow the indicator to be shown only when the keyboard is used and not with the mouse.
<bruce_bailey> ... i have some concerns that this is putting onerous on designers that now have to pick defect from some browsers -- force all pages to have huge borders on fields?
<Zakim> alastairc, you wanted to say it's similar to text-sizing and bypass blocks
<bruce_bailey> ... but it seems wrong to require authors to fix a feature that all browsers should feature and make easy to adjust
<bruce_bailey> Alastair: When we started this, we assumed we would be able to hit a balance between user needs and browser defaults
<bruce_bailey> ... since then, some browser defaults have improved noteably, namely chrome and edge
<bruce_bailey> ... Safari not great and FireFox still insufficient
<bruce_bailey> ... i was thinking that "mechanism" implied author supplied settting for the page or site
<Jemma> may be difficult to test "automatically"
<bruce_bailey> ... can be difficult to test, if there are multiple hover styles, but not from my experience is not difficult to impliment
<bruce_bailey> ... what changes my mind is that "mechanism is available" is misleading
<Jemma> +1 alastairc
<Chuck> +1 alastair
<bruce_bailey> Rachael: chair hat off, i think the ideal state is that browsers impliment easy to find options, and authors cant breakit
<bruce_bailey> ... breaking might be hard, but be optimistic that browsers with provide sufficient solutions. Presure to developers good.
<Zakim> Chuck, you wanted to support "carry on the sc as it is..."
<bruce_bailey> Chuck: Hearing more support on this call for dropping "mechanism" but want to get through queue
<GreggVan> Thanks - forgot that they keyboard indicator is only visible when doing keyboard focus
<GreggVan> nav
<Chuck> Poll: 1) I support carrying on with SC as it is. 2) I support adding "mechanism is available". 3) Drop both focus-appearance SC. 4) Drop the AA SC and keep AAA sc
<bruce_bailey> Jon Availa: Example is heuristic browsers are using to hide focus indicators when one is only using mouse or keyboard (so focus indicator fades)
<Zakim> alastairc, you wanted to say that good browser defaults can pass the SC, they just don't 'yet.
<bruce_bailey> ... i think there is reason to be optimistic that browsers will mute unnecessary visual distractions.
<GreggVan> can you post - for the record - what "the SC as is" is exactly
<MelanieP> which option inncludes exception for default focus indicator?
<AWK> +AWK
<alastairc> MelanieP - if the default meets the SC
<Chuck> Poll: 1) I support carrying on with SC as it is. 2) I support adding "mechanism is available". 3) Drop both focus-appearance SC. 4) Drop the AA SC and keep AAA sc
<bruce_bailey> Alastair: Just want to note that browser behavior in flux.
<bruce_bailey> Chuck: tally in survey seems out of sync in this call, so straw poll
<Jemma> 1Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
<alastairc> https://
<Chuck> 1
<AWK> 1
<Jemma> 1
<MelanieP> 4 unless default focus indicator is allowed in the AA version
<jon_avila> 1
<Rachael> 1
<alastairc> 1
<GN015> 2, can live with 1
<Ryladog> 1
<GreggVan> 1
<bruce_bailey> Jemma: Carry on as-is implies authors can have confidence -- if they test browser behavior
<Detlev> 1
<ShawnT> 1
<bruce_bailey> Chuck calls on Melonie: similar to how we approach 1.4.11 -- can we add this to AA version ?
<jon_avila> I think that would be like a 5th option
<bruce_bailey> GreggV: We have been waiting for this like 20 years.
<Ryladog> +1 to Gregg!!
<alastairc> To be fair, some browsers have improved, but it's not consistent. Also, agree that if they do step up, this SC is passed.
<bruce_bailey> ... it only appears when keyboard nav. If the browswers ALL start doing this, then this provision will be met with default
<Chuck> proposed RESOLUTION: Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
<bruce_bailey> ... but after 20 years of trying to get browsers to fix, they have not, so we need to task the content authors.
<Ryladog> +1
<Chuck> +1
<Rachael> +1
<GreggVan> +1
<Jemma> +1
<alastairc> +1
<MelanieP> -1
<kirkwood> +1
<bruce_bailey> ... it is a barrier to end-users.
<ShawnT> +1
<AWK> +1
<alastairc> If anyone has a better way of saying it that what is in the understanding doc, please let me know... "The default focus indicators in some browsers can be difficult to see, such as a 1px dotted outline, or a blue indicator which happens to be on a blue background. It is generally best to either define a keyboard focus style which meets this criterion, or test the focus styles across the browsers that are relied upon for conformance."
<bruce_bailey> Chuck looking for feeling of formal objects.
<bruce_bailey> Deque demurs to the new year.
<Chuck> proposed RESOLUTION: Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it, noting that there is one objection.
<bruce_bailey> Rachael: recommend accepting resolution, notes that there is some concern
<bruce_bailey> Chuck asks Rachael to make resolution proposal.
<bruce_bailey> Shadi asks for summary for concern with "mechanism"
<bruce_bailey> GreggV: problem is that UA includes AT -- and people should not need AT for this need
RESOLUTION: Carry on with the SC as it is and provide guidance in understandings that browsers can fulfill the SC if you test it, with 1 objection requesting including a default indication. C
<Rachael> proposed RESOLUTION: Carry on with the SC as it is and provide guidance in understandings that browsers can fulfill the SC if you test it, with 1 objection requesting including a default indication.
<Rachael> proposed RESOLUTION: Carry on with the SC as it is and provide guidance in understandings that browsers can fulfill the SC if you test it, with 1 objection requesting including a default focus indicator
<bruce_bailey> Jemma asks about objection process.
<GN015> What does including the default focus indicator mean in this context?
<bruce_bailey> Alastair: we can deal with objections on CFC process
RESOLUTION: Carry on with the SC as it is and provide guidance in understandings that browsers can fulfill the SC if you test it, with 1 objection requesting including a default focus indicator.
<bruce_bailey> Jemma: We should not really be using word "objection" here -- and that is not what she asked
Question 2 - Using target-area as the basis for size metrics
<bruce_bailey> Melanie: it is okay, because I asked to add an exception
<bruce_bailey> Chuck reads from survey:
<bruce_bailey> https://
<bruce_bailey> Wilco would like to use the target-size of the component as the basis for size metrics.
<bruce_bailey> PR 2147 makes the change in the SC text. If we agree this, the understanding document will need updating.
<bruce_bailey> https://
<bruce_bailey> Should we: Change to using target size as the basis for measuring components. 9 votes
<bruce_bailey> Detlev (from survey): I don't see anything wrong with using target size as a basis for measurement if that can simplify an automatic approach to measurement (no one, I believe, is looking forward to start calculating the focus area of targets on a manual basis) but I may not be sufficiently aware of loopholes that might appear. So it might be worthwhile going through edge cases (Alastair will have some in stock, I guess) to see what this[CUT]
<Jemma> s/be using word "objectioin"/be using "requesting including a default focus indicator"/
<bruce_bailey> David McDonald (from survey): I don't have a problem with the proposed text. It add a bit of complexity to an already complex SC, but I understand that it may make it possible to evaluation the SC with automation.
<bruce_bailey> A precedence for this might be the complicated calculation for colour contrast becomes a black box and authors just use colour contrast tools. (but that calculation is not part of the SC language.)
<bruce_bailey> What would be ideal would be to have some sort of a name for the calculation and then reference it in the SC text...
<bruce_bailey> I don't object to alternatively updating the note if it accomplishes the same thing of making the SC evaluated automatically.
<bruce_bailey> Glenda (from surve): +1 to what David MacDonald said
<bruce_bailey> Wilco (from survey): 1. Target should be linked to the definition
<bruce_bailey> 2. Rather than remove that note, I think we should replace it with something like this:
<bruce_bailey> > Some components have an "extended" target, where both the component and a larger container are interactive. Even in such cases the minimum area is taken from the component's target area, not the container.
<bruce_bailey> Bruce (from survey): > Some components have an "extended" target, where both the component and a larger container are interactive. Even in such cases the minimum area is taken from the component's target area, not the container.
<bruce_bailey> s/My preference is for the PR, since having the text mention "area" is good. I am also okay with updating the note./My preference is for the PR, since having the text mention "area" is good. I am also okay with updating the note./
<bruce_bailey> My preference is for the PR, since having the text mention "area" is good. I am also okay with updating the note.
<bruce_bailey> GreggV (from survey): Absolutely. in fact having a small visual target and a large active area is a good technique for more accurate pointing. (and Notes are not normative usually)
<bruce_bailey> Chuck: That is all comments from survey supporting PR.
<bruce_bailey> ... two votes for Update the note
<bruce_bailey> Jon Availa (from survey): The target area could make it harder to meet and more confusing on how to test. This could mean potentially larger indicators if there are larger target areas.
<bruce_bailey> Jon Avila: Needs more consideration.
<bruce_bailey> ... could have situation where offset makes objects overlap
<bruce_bailey> [gives another example]
<bruce_bailey> Chuck: We also had 3 something votes.
<bruce_bailey> Gundula: target area is not right thing to be measuring
<bruce_bailey> ... overlaps was another example
<Zakim> AWK, you wanted to ask about standard checkboxes that use label properly
<bruce_bailey> Chuck calls to AWK for his clarification request.
<bruce_bailey> AWK: There must be a variety of cases where the target area is extended , maybe without visual indicators, but this is not a problem for a keyboard area
<bruce_bailey> ... that is provided as an accomodation , maybe for someone uses a mouse but with difficultly , i dont think we have all the cases sorted
<Zakim> alastairc, you wanted to talk through the change and to talk through the change, and target area isn't about white space
<bruce_bailey> ... another example is default with check boxes -- which are small -- but group border can be used to mee this SC -- and default controls are not typically problematic
<bruce_bailey> Alastair: Explains some of the oddities and difficulties trying to be addressed. Wilco has a neon sign example.
<bruce_bailey> ... Jake previously gave example with 4 px requirement which is rediculous on control easy to activate.
<bruce_bailey> ... we have example with cards and drop shadows that can be easy to activate inputs
<bruce_bailey> ... also example with input boxes which easy to select.
<alastairc> https://
<bruce_bailey> GreggV: We have SC which implications for the needs of testing tools, so manual testing does not have to be very easy.
<bruce_bailey> .. if target is used incorrectly elsewhere, fix that use elsewhere.
<bruce_bailey> ... to AWK point, if we need min height/width for string of radio buttons, then do that. It is still all target area.
<bruce_bailey> Katie: Real life use case: touch screen like a phone pad, RNIV tells us we need "well" between targets...
<AWK> That sounds like a different SC. https://
<bruce_bailey> ... but if someone using keyboard, the spaces get read by screen reading software, so that is not good, numbers should 7, 8, 9, etc. should just be read in sequence.
<Zakim> alastairc, you wanted to talk about target area and spacing
<bruce_bailey> ... so there is tension between phone pad for use on touch screen and visul presentation giving space -- and buttons not have white space via keyboard.
<bruce_bailey> Alastair: I don't agree we have incorrect definition else where. Please submit issue if you disagree.
<bruce_bailey> ... This SC is addressing target point of view spacing , so using well for target space is fine.
<bruce_bailey> ... But a script might change the presentation, so the focus indicator might need to adjust. Focus indicator might include spacing or might be for touch target, so those can be two different things.
<bruce_bailey> ... AWK gave example of check boxes, and this updates helps with that.
<bruce_bailey> Availa: I understand the concern for conflating target size with target area. I have been testing this...
<bruce_bailey> ... My experiments, I can click target, via mouse, on whitespace outside button.
<alastairc> It would be the size of the label, which is wrapped around the input
<bruce_bailey> ... so the target size propert is not exposed. The visual focus indicator, by contrast, is readily available for an audit.
<Zakim> AWK, you wanted to say that this will cause more problems then it solves. We are mandating that checkboxes must have focus around the entire label and checkbox and I don't think that we can/should do that.
<bruce_bailey> Katie: It can seem like a concern that a visual focus indicator is larger than the target. I don't agree it is a problem in practice.
<bruce_bailey> AWK: I have concern for the testabiltiy, and this conversation reinforces that. I don't think we should make this change. End with "component".
<alastairc> To quote Wilco: I think area of the component's target does exactly what we need here:
<alastairc> 1. It's technology agnostic
<alastairc> 2. for most technologies it can be programmatically determined
<alastairc> 3. it matches the border-box / browser indicated size in HTML and SVG (unless clipped, which is very rare)
<alastairc> 4. It doesn't require this problematic "visible area" thing as a fallback
<bruce_bailey> Meanie: Wilco would address better, but a programatically determinable target area needed for testing this.
<Jemma> definition: target offset
<Jemma> [New]
<Jemma> the distance measured from the farthest point of a target to the nearest point of the second target. Offset includes the target and spacing around the target. The target offset from A to B may be different then the offset from B to A, if the size of these targets differ.
<bruce_bailey> ... focus areas is just a browser feature. It is no conflating.
<Jemma> definition: target
<Jemma> region of the display that will accept a pointer action, such as the interactive area of a user interface component
<bruce_bailey> AWK: Disagree, as adding lable to checkboxes increases focus area. It is a useful technique.
<bruce_bailey> Detlev: If checkbox has accessible name, it is NOT necessary to use label.
<bruce_bailey> Alastair: There probably are cases where area of input are different from focus or target area. AWK example of label is one of them.
<bruce_bailey> ... to Jon Avila, area of label is readily available. So that is one aspect.
<bruce_bailey> ... We might consider exception for area being expanded via lable.
<bruce_bailey> ... see phrasing from my conversation with Wilco
<bruce_bailey> ... we need some fudge for either approach.
<Zakim> AWK, you wanted to discuss nintended consequence
<bruce_bailey> ... target size might be artificially expanded.
<bruce_bailey> AWK: One consequence for this is discouraging use of label.
<alastairc> Arg, dis-incentivising associated labels would not be good
<ShawnT> +1 to AWK that would not be good
<bruce_bailey> ... use of label makes meeting this SC harder -- and accessible name makes it not absolutely necessary...
<bruce_bailey> ... but it would be bad to discourage use of label
<bruce_bailey> GreggV: Not sure this discourages use of label. Not seeing a problem.
<bruce_bailey> ... SC does not say designers HAVE to do things a certain way.
<Zakim> Chuck, you wanted to propose a resolution
<Chuck> proposed RESOLUTION: Accept the change to using target size as the basis for measuring components.
<bruce_bailey> Chuck: I have prosed resolution...
<bruce_bailey> +1 to support
<bruce_bailey> 0 to tolerate
<GreggVan> I was confused with your argument so I am not pro or con
<AWK> -1
<GN015> -1
<bruce_bailey> -1 to not tolerate
<alastairc> 0
<ShawnT> 0
<kirkwood> -1
<GreggVan> +1
<MelanieP> +1
<Detlev> 0 sufficiently not sure to say zero
<alastairc> I think we'll have to come back to this, we need Wilco on the call and the examples to hand
<Rachael> 0
<jon_avila> +0
<bruce_bailey> Chuck: basically accepting PR
<Detlev> agree we need Wilco on the call to move forward
<bruce_bailey> GreggV: Is target size?
<Jemma> target
<Jemma> region of the display that will accept a pointer action, such as the interactive area of a user interface component
<bruce_bailey> Alastair: region of screen that can accept input
<Rachael> +1
<shadi> +1
<bruce_bailey> Chuck: no leave for Wilco
RESOLUTION: We love Wilco
<bruce_bailey> Chuck: we do not have consensus
Question 3 - Insufficient requirement for focus indication via enlargement #1858
WCAG 2.2 Page break navigation (Q1 only) https://www.w3.org/2002/09/wbs/35422/wcag22-page-break-nav/
WCAG 2.2 Misc https://www.w3.org/2002/09/wbs/35422/wcag22-misc/
Question 3 - Insufficient requirement for focus indication via enlargement #1858
<bruce_bailey> https://
<bruce_bailey> https://
<bruce_bailey> Ben opened Issue 1858 about whether the examples are sufficient.
<bruce_bailey> Alastair & David proposed a response, essentially - we agree but not allowing for those examples would create false-positives.
<bruce_bailey> Agree with the response 9
<Chuck> proposed RESOLUTION: Accept amended response from Alastair and David to address issue 1858.
<bruce_bailey> Agree with adjustment : 5
<bruce_bailey> https://
<alastairc> Overall, whilst it is a limitation, it allows for several types of designed focus indicator that are not a problem. It is also mitigated by the dynamic nature of focus indicators.
<bruce_bailey> Gundula: Amended still relies on insufficient indicatore
<alastairc> We can remove the last sentence
<alastairc> "Overall, whilst it is a limitation, it allows for several types of designed focus indicator that are not a problem."
<bruce_bailey> ... users might need to shift gaze from keyboard and back again...
<bruce_bailey> ... the focus indicator can dissapear during that change of gaze
<bruce_bailey> ... cannot rely on dynamic indicator.
<alastairc> https://
<Chuck> proposed RESOLUTION: Accept amended response from Alastair and David to address issue 1858.
<Chuck> +1
<bruce_bailey> Chuck: edit has removed that last part of the response.
<alastairc> +1
<Ryladog> +1
<Detlev> +1
<GN015> +1
<jon_avila> +1
<Rachael> +1
<Jemma> +1
<kirkwood> +1
RESOLUTION: Accept amended response from Alastair and David to address issue 1858.
<Ryladog> Happy Hollardays!!
<jon_avila> * Happy holidays
<MelanieP> Cheers!
<bruce_bailey> Chuck: Last meeting of the year. Thanks everyone!
<Jemma> Happy holidays, everyone!
<alastairc> https://
<ShawnT> Happy holidays! Stay safe!
<bruce_bailey> Alastair: next meeting is 1/4/2022