<alastairc> agenda

<mbgower> scribe

<mbgower> scribe: mbgower

New starters or announcements?

I'm Peter Bossley. I'm a rep for Thompson-Reuters.

<Chuck> Welcome Alyssa!

Alastair: Anyone have any announcements?

WCAG 3 Review of revised conformance section survey https://www.w3.org/2002/09/wbs/35422/WCAG3_conformance_March_23/

Alastair: We're not going to go through every comment. We have a lot of editorial comments.
... We have suggestions from Bruce, Matt, John, Detlev.... Those have been accepted and integrated or Rachael has contacted them.
... We'll try to catch up with David over his more detailed comments.
... That leaves some more substantial points.

<AWK> +AWK

Alastair: Bruce had comments on FICO ratings.
... The goal was to step away from models and focus on pieces. The FICO didn't get a lot of support, but the current work does not exclude it.

<bruce_bailey> Thank you Alastair for that explaination.

Alastair: We can update the draft and prepare for questions from regulators, and then focus on the holistic model
... Does that sound like a reasonable approach?

<Chuck> +1

<bruce_bailey> +1

<jeanne> +1

Alastair: I will propose a draft resolution

<alastairc> draft RESOLUTION: Accept that we are presenting pieces without a 'integrated whole', in order to further discussion with stakeholders.

<Peter_Bossley> +1

<jeanne> +1

<Chuck> +1

<Lauriat> +1

<Laura> +1

<corey_hinshaw> +1

<Poornima> +1

Alastair: If you think that's not the right approach, we'll need to come up with something which we don't yet have

<Makoto> +1

<ChrisLoiselle> +1

<ShawnT> +1

RESOLUTION: Accept that we are presenting pieces without a 'integrated whole', in order to further discussion with stakeholders.

RESOLUTION: Accept that we are presenting pieces without a 'integrated whole', in order to further discussion with stakeholders.

Alastair: There's a comment from Wilco about terminology.
... We are proposing side-stepping the terminology for now, until we get to the method or outcome level.
... Wilco, is that all right?

Wilco: Yes, that's okay.

Gregg: This comes down to whether we're sticking with the WCAG 2 approach
... Do we create a continuum between levels, or separate by label (and thus filter).

Alastair: Our aim is to keep it integrated, but we're putting off a decision for now on how each bit fits.
... The next comment is from Jon

[Alastair reads the comment]

Alastair: Is Jonathan here?
... Does anyone else have comments on user process?

Cyborg: My comment is not about this. It is from the Google Doc about the Bronze, Silver, Gold classification. I have suggested we consider that all best practices be at silver level.
... Gold would be reserved for specific contexts.

Alastair: Was that comment noted in the survey or in a document comment?
... Is there anywhere for us to reference that?

<Chuck> Cybele, sounds like you had a personal distraction, we are making a note of your comments.

Alastair: Any other comments on the user process part?
... I think those were the main themes. Jeanne, did you pickup anything else?

Jeanne: No, I think you go them all.

<Cyborg_> hi Alastair - sorry, no, I was unfortunately experiencing a health matter and was not able to get that comment in last week (can be discussed privately). Here it is again:

Alastair: John Foliot had a fairly long comment. Rachael has responded. I think we've covered them all.

<Zakim> bruce_bailey, you wanted to ask about plain language summaries

<GreggVan> g+ to say " add to end of 2nd last paragraph in 4.1 Methods and test sets are located in a separate informative How To document so they can be updated over time and as technology evolvde

<Cyborg_> During CSUN and again now, I'd like to express the concern that Gold not be used as a bronze-silver-gold spectrum, as some will avoid doing "best" in favour of better (we know that is a phenomenon).

Bruce: Will this publish without the plain language summary?

Alastair: I'll make a note to check with Rachael. I'm guessing the aim is to be there.

<Zakim> GreggVan, you wanted to say " add to end of 2nd last paragraph in 4.1 Methods and test sets are located in a separate informative How To document so they can be updated over

<Cyborg_> Instead, we could reserve Gold for a specific class of practices that we anticipate will only be adopted by organizations likely to want to be at the cutting edge of accessibility and role models for others. We should not put things off to Gold that could be done at Silver.

Gregg: I think it is confusing that it defines an outcome as the results of tests and methods.
... We should add to the penultimate paragraph
... We shouldn't imply they are all normative.

<alastairc> Is that just above section 4.1.1?

Gregg: The methods are not in the outcomes. They're separate.

Alastair: Do you mean in the introduction in 4.1.1?

Gregg: Yes.

Alastair: I'm making notes. It is editorial, but we'll pass on.

<Cyborg_> My understanding is that Bronze = what we can test and prove to the point that it is possible for regulators to adopt it. Silver include better and best practices that we can incentivize but that require expert review and are therefore not possible to objectively measure in a manner that is easily replicated, and Gold could be used to specifically identify practices designed for role model organizations.

Alastair: Any other questions or comments?

Cyborg: I have added my comments to IRC. I wasn't able to get in survey due to health concerns.

Alastair: We will make a note and reference back.

Gregg: in the 4.1 section, we talk about outcomes, that are in one document, then tests, in another, then conditions, which is a subset of outcomes... Then we have assertions and procedures.
... so I think we're jumping back and forth. It's kind of confusing.
... Are you thinking we'll resolve this later?

Alastair: We're just trying to get the pieces on the tables, so we can discuss.
... I made a note to clarify which will go into which documents. Any other considerations before it goes into github as a pull request, and we'll have a final review.
... It would be best to raise anything substantial now.

<Cyborg_> my note references a shifts bronze-silver-gold from spectrum to a parallel approach - you can start building toward silver while working on bronze

<Cyborg_> perhaps the way to write it is to make them parallel tracks

<Cyborg_> and not about increasing quality

Gregg: issue severity seems to be... I think there should be a counterpoint that says "or whether all other guidelines are important to some individuals" or something.
... It doesn't provide any skepticism.

Alastair: If this is a phrasing quesiton, could you add that to the document?
... Just highlight the text and click the + symbol to add a comment. Bruce mentioned the document is locked.

Cyborg: I had the same issue that I couldn't comment either. Permitting that would be super.
... The language expressed seems to suggest Bronze is a certain amount, and silver is more, then Gold. I hear you saying that the proposal at CSUN is not jeoparized by that. But it didn't see the terms as a question of degree.
... Authors could start to collect silver points while working in bronze guidance. For instance alt text.
... There may be other elements of alt text that may be more difficult to have a test for, and so may be subject only to review.
... That could be accumulated while working on bronze. But the way it is written makes it harder to do that.

<Chuck> thanks Bruce, we will still need to call a break for mbgower

Cyborg: The proposal framed those differently.
... I'm concerned taht the language around these terms still contain this bias. I perceive it as conflicting with the CSUN presentation.

Alastair: We need a scribe change.

<Zakim> GreggVan, you wanted to suggests " Pass additional Outcomes and Assertions or points earned by going beyond just pass on Bronze outcomes."

Gregg: I pasted in a suggested wording to address the last comments.

Cyborg: I will need more time to consider that.

<Zakim> Chuck, you wanted to ask for scribe change

<Chuck> ok to hand off to bruce

Gregg: It would just be expanded to add a phrase. I was trying to include the extra part.

Alastair: This is going into the topic of how the pieces fit together. We're heading off topic.

Cyborg: Maybe there's a caveat underneath that these are not necessarily linear. There may be a non-linear approach to these, to be considered in the future.

<bruce_bailey> scribe: bruce_bailey

<Cyborg_> yes 4.3.1

Gregg: Is the 4.3 or 4.1. ? ....

<Cyborg_> In order to reach Bronze level, the scope claimed in the conformance statement must pass a subset of Outcomes and Assertions. The subset will require enough Outcomes and Assertions to improve equity across functional needs. Silver is a higher conformance level than Bronze. In order to reach Silver level, the scope claimed in the conformance statement must: Pass Bronze, and Pass additional Outcomes and Assertions Gold is the highest conformance level[CUT]

Gregg: Numbering seems odd, but we are talking about issue severability

<Cyborg_> yes that is the problem - thank you Gregg

<Cyborg_> EXACTLY

<Cyborg_> that is the problem I'm having

Gregg: the bronze / silver / gold does not seem to me to be an analog to A AA AAA ...
... which is why I made my editorial suggestion to explain more to that bullet

<Cyborg_> We should mention the qualitative differences between the colours

<Chuck> Thanks Jeanne!

alastairc: Editors have taken notes, so we come back to this. Any other conformance questions?

Gregg: 4.1.6 check order

<Cyborg_> *Caveat: Bronze is intended for testable regulatory purposes. Silver is intended to incentivize increasing use of practices and procedures that create greater accessibility and stretch beyond the minimum, using a currency (points or percentages tbd). Gold is intended as a means to identify those organizations that model best practices in accessibility.

alastairc: Survey is closed, please email editors if you please , and doc is reopened for comments

<Cyborg_> In order to achieve Gold, one must pass Silver, in order to achieve Silver, one must pass Bronze.

<Cyborg_> But Silver measures can and should be done at the same time as Bronze measures.

<Cyborg_> does that clarify???

alastairc: Reminder that surveys are closed in few days before call is scheduled

WCAG 2.2 Parsing survey https://www.w3.org/2002/09/wbs/35422/parsing-note-editorial/

<Cyborg_> I think the explanation is important.

<Cyborg_> so we don't replicate A, AA, AAA

<Chuck> https://www.w3.org/2002/09/wbs/35422/parsing-note-editorial/results

Chuck: I note that wcag3 segment is concluded, moving onto wcag 2 portion of call.

In previous discussions we have decided to add a note to the WCAG 2.0 and 2.1 versions of 4.1.1 parsing.

[from survey] The note in the CFC was:

This Success Criterion should be considered as automatically met for any content using HTML. Modern browsers all have automatic error correction for parsing errors, and issues such as incorrect states or names due to a duplicate ID, or missing roles due to inappropriately nested elements are covered by different Success Criteria. This criterion can therefore be ignored as being redundant. It no longer provides any benefit to people with d[CUT]

During the CFC an update was proposed to:

This Success Criterion should be considered as automatically met for any content using HTML. Since this criterion was written, the HTML Standard has adopted specific requirements governing how user agents must handle incomplete tags, incorrect element nesting, duplicate attributes, and non-unique IDs. Although the HTML Standard treats some of these cases as non-conforming for authors, it is considered to "allow these features" for the pur[CUT]

We'd like to gather any concerns or updates to the text before adding it.

<dan_bjorge> +1 for Wilco's adjustments, they seem reasonable to me

Six responses, one editorial from Wilco.

Wilco (from survey): Two minor points - Use "satisfied" instead of "met". The conformance section says success criteria have to be satisfied. - Please remove "automatically" from "automatically met". It hardly matters if this is automatically or if someone does this manually. It's a completely unnecessary qualifier.

<AWK> agree with "satisfied" instead of "automatically met"

ALSO: I think we need to talk about using this note in WCAG 2.2 in place of removal of the SC. This is substantial new information on the decision regarding the removal of 4.1.1. Even if we change nothing, we should have the conversation.

Parsing note wording

GreggV: +1 to removing "automatically" suggest "always met" instead

<kirkwood> +1 to Wilco’s comment

<Zakim> AWK, you wanted to suggest "accordingly" instead of "there" in the last line of the new version.

<alastairc> Suggestion for 1st line: "This Success Criterion should be considered as always satisfied for any content using HTML."

GreggV: last bullet seems like it needs a cap. Last sentence is a contradiction to idea that the SC should not be used or enforced.

<AWK> "should be reported accordingly rather than as 4.1.1 issues."

<Detlev> is it "always" even when scripts add not well-formed stuff after page load?

AWK: Seems strange to refer to SC in location. Maybe "reported according"?

<mikeGower> +1 to all tweaks suggested

Chuck checks with Alastair if he is able to capture suggestions. Alastair screen shares a working document.

<Zakim> GreggVan, you wanted to say "change there" to "under those SC" (rather than accordingly - which is good but ambiguous) and to say change "there" to "under those SC"

Chuck: I would like to severe question from 2.1/2.0 to the note in 2.2. [wilco concures]

<Zakim> AWK, you wanted to ask about SVG issues

GreggVan: Just that phrasing is a bit awkward.

AWK: Note refers to HTML. Does it need to so specific? Seems applicable to SVG for example.
... Might audits still be concerned for SVG assets on a page? If no known issues, does caveat need to be limited to HTML.

<mikeGower> The restriction to HTML was bugging me too

Chuck: Taking AWK under consideration.

GreggVan: Seems like "all markup languages" might be too broad. Does any one know?

alastairc: The way this note came about is that we know issue is covered by HTML but has not be considered for SVG or EPUB -- so changing to "markup language" might be premature.

Dan Bjorge: From SVG spec, the error recovery is different, and more open ended than HTML.

Corey Hinshaw: Can we open up the phrasing to include mark up languages -- similar to HTML -- so as to cover if needed?

Mike Gower: I agree with previous suggestion to flip wording so can be markup languages like HTML....

scribe: But HTML 4 does not exist so there is no grounding for 4.1.1 as phrased.

<dan_bjorge> Whether the AT or the browser is the "user agent" is an implementation detail

GreggVan: The flipping is that AT had difficulty that browsers did not have. Issue is NOT that browser repair things...
... Browsers still change things, but the change is that *AT* looked at the code and now its the DOM.

<alastairc> Don't forget epub, I'm not sure the user-agents are as advanced?

Wilco: I am not aware of AT parsing per se, but they do *not* only rely upon accessibility tree...

<kirkwood> Wilco is correct SVG and XML have not tolerence and won’t render unlike html

Wilco: I do not know about AT and SVG but I recommend keep scoping to HTML.

dan_bjorge: As I developed note, the phrasing I struggled the most with is "for any content using HTML"

alastairc: We did have some conversation on this previously, but from this conversation I have concerns for expanding beyond HTML to other markup languages.

AWK: HTML pages are taken care of, so the note is useful from that perspective and this is important as is...

<Peter_Bossley> +1 to Corey's suggestion of reversing the wording and using HTML as an example.

<Chuck> labels and instructions?

<Zakim> GreggVan, you wanted to say "4.1.1 was added only to address the problem of AT directly parsing HTML code. AT no longer does this. This provision is therefore redundant. All

<AWK> @juanita - sounds like a different SC issue

AWK: I appreciate that SVG being XML based means that 4.1.1 should not be a problem. But if we can flip the phrasing, that still seems better.

Jaunita George: Can any affirm that duplicate IDs are never a problem unless caught by another SC?

<dan_bjorge> -1 to this suggestion - it goes back to the note trying to override the normative conformance model. The note needs to be explaining why we think the existing normative exception applies, *not* saying it's okay to ignore the SC

GreggVan: Yes, duplicate IDs are not a problem unless they cause other problems.

<AWK> 4.1.1 was added only to address the problem of assistive technologies directly parsing HTML code. Assistive technology no longer does this within HTML content. This provision is therefore redundant. All other errors captured by

GreggVan shares long editorial suggestion.

<Zakim> Chuck, you wanted to ask about "sticking with what we have" and to also ask if we are certain that AT doesn't directly read html anymore

<kirkwood> +1 to Gregg to be upfront about reason. well stated

Chuck: A few people have said stick with what we have. But I am not confident that is "what we have" and there is some important editorial.

<Zakim> alastairc, you wanted to say we need the current reasoning

Chuck: I am all for 4.1.1 but are we sure no AT reads HTML?

alastairc: We changed note in that we are being careful about SC being satisfied rather than "not needed anymore".
... This is why we have this approach, which is in understanding document. But we are changing normative text, so we have approached cautiously...

<Wilco> +1 to "or XML"

<Chuck> akc Jau

alastairc: I suggest adding "or xml" since that seems safe and an important extention and covers more technlogy.

<Chuck> bruce_bailey: Scribe note, did your suggested edit get into IRC?

Jaunita_George: i have concern that people will read this note too broadly and also ignore , for example, duplicate IDs that *do* cause problems.

<Zakim> Chuck, you wanted to ask about point of order on scribing

<Zakim> alastairc, you wanted to say any further explanation should go in the understanding doc.

alastairc: any further explanation should go in the understanding doc.
... We are pushing our luck a bit even with this editorial change. Please make suggested for Understanding if at all possible.

[alstair screen share]

<alastairc> Mapping doc: https://docs.google.com/document/d/1MJ6FxO7ujQ4X9BQtAnDDoWyvpAKU44MR4h-bob9SG7M/edit

<Zakim> GreggVan, you wanted to say what we currently propose is long but doesn't work well -- it is overly technical and yet is ambiguous as to final outcome. also is not true if it

<Detlev> can you put in a link to the 4.1.1 mapping doc?

Junita: We need more into understanding.

<Detlev> ah sorry

alastairc: We have identified several technique which need to be updated to reflect this changes.

GreggVan: I still feel a bit of contradiciton with present wording...
... to say that "content meets 4.1.1" when other SC failures are present seems a bit contradictory.

<Zakim> alastairc, you wanted to say, we are dancing

GreggVan: but to be clear, i agree that "no content should be considered to fail this SC"

<Chuck> +1 with Alastair's interpretation, the first sentence covers it for me.

<dan_bjorge> +1 to alastair, first sentence already says that

<alastairc> Full note for the record: This Success Criterion should be considered as always satisfied for any content using HTML or XML. Since this criterion was written, the HTML Standard has adopted specific requirements governing how user agents must handle incomplete tags, incorrect element nesting, duplicate attributes, and non-unique IDs. Although the HTML Standard treats some of these cases as non-conforming for authors, it is considered to "allow

<alastairc> these features" for the purposes of this Success Criterion because the specification requires that user agents support handling these cases consistently. In practice, this criterion no longer provides any benefit to people with disabilities in itself; issues such as missing roles due to inappropriately nested elements or incorrect states or names due to a duplicate ID are covered by different Success Criteria and should be reported under

<alastairc> those criteria rather than as issues with 4.1.1.

alastairc: We are dancing around the point a bit because of how this is part of normative text. Greg's edit was considered, but seemed too strong.

Chuck: If GreggV reading Note this way, then others are likely to read similarly.

<Wilco> +1

alastairc: I like AWK suggestion [above in IRC] to move most of note to Understanding.

<Chuck> proposed RESOLUTION: Accept amended note on 4.1.1 for WCAG 2.0 and WCAG 2.1

Chairs agree that first sentence captures main idea.

Wilco: I am not clear on poll -- since on-screen is different than survey.

alastairc: text for consideration at :05 past hour.

<GN05> Can you propose the full text in the resolution? It s hard to keep track on the amendments.

<GreggVan> text is posted above in 3 pieces at 5:52 after the hour

<mbgower> I'd love to yank out the whole middle and just have it be the first 2 sentences and the last full 'sentence' following the semicolon

<kirkwood> too complicated?

alastairc: ONly change from survey is on screen (and above) as always satisfied -- and add "or XML" then "under those criteria" addition at end (as compared to survey text).

<mbgower> The other stuff can just go to teh Understanding doc

<GN05> Can the 'those Success Criteria' be explicitly mentioned?

<Rachael> +1 I support the simplified note.

Chuck: Any concerns for striking middle sentence (from note) and only having that in Understanding?

<mbgower> Moving it to Understanding, not deleting

<Wilco> +1 Dan. Prefer to keep it

dan_bjorge: No objection, but the sentence proposed for deletion is the hard tie to normative phrasing of SC.

<Zakim> Chuck, you wanted to say I like the middle part.

<Wilco> I like it split up in multiple paragraphs

mbgower: This is going to our base (normative) document so the main thing we want readers to come away with is not to test for 4.1.1. So the middle paragraph can move to Understanding.

<dan_bjorge> Agree paragraphs are nice

<mbgower> A 3 paragraph note? :)

<Chuck> +1 yes, a 3 paragraph note :-)

Chuck: I do like how breaking into separate paragraph adds clarity, but we might want to make an edit later which can only happen in Understanding.

GreggVan: I suggest breaking into multiple notes.

<dan_bjorge> The normative SC text is "except where the specifications allow these features". The normative SC absolutely is already based on conformance to other specifications.

GreggVan: The reason for 4.1.1 is about AT and not HTML. HTML is *not* required in regulation. Our standard should not talk about conformance to *other* standards....
... So I agree with moving that sentence/paragraph to Understanding.

<kirkwood> +1 to split up for better understanding. Agree with Gregg.

<Zakim> Chuck, you wanted to propose the resolution

<Chuck> proposed RESOLUTION: Accept amended note on 4.1.1 for WCAG 2.0 and WCAG 2.1

GreggVan: It is true, and always have been true, that wcag is about accessiblity.

<Wilco> +1

<Chuck> +1

<ShawnT> +1

Chuck I want to straw poll on previous edit.

<alastairc> +1 (not too concerned about the split)

<kirkwood> +1

Wilco: Again, it is not clear which text we are voting on.

<laura> +1

<mbgower> +1 I can abide by any of these versions, so long it is clear we don't want people reporting against 4.1.1

<Detlev> no objection

alastairc: Only recent change is adding paragraph breaks.

<Rachael> +1 to what mbgower said

<AWK> +1 (same as Mike G)

<corey_hinshaw> +1

<dan_bjorge> +.5 - only hesitation is with "or XML" addition, would prefer Corey's version if we want it wider than HTML

<Makoto> +1

<GreggVan> +1 but first sentence should be broken out as own note for emphasis

Chuck: Noting we have no objections to three paragraphs so far.
... This is as in survey with minor editorial

<kirkwood> +1 to moving

<Wilco> Leave it please

<Chuck> POLL: Move middle paragraph to understanding document.

<Chuck> -1

<GreggVan> -1 to moving

<dan_bjorge> -1 to moving

<Zakim> GreggVan, you wanted to say Middle sentence explains whey 2nd sentence is there

<alastairc> -0.5

<Wilco> -1 to moving

<mbgower> 0

<AWK> -.1

GreggVan: I agree that middle paragraph explains second sentence -- and we all want to keep that.

<kirkwood> change vote: -1

<laura> -1

<corey_hinshaw> "any content using a markup language that has adopted specific requirements governing how user agents must handle [...] such as HTML"

mbgower: What gregg observes about second paragraph is true, which is why my preference would be to explore Dan's XML oriented phrasing a bit more.
... but HTML could be and *example* of why 4.1.1 is not useful

alastairc makes lite edit....

<Chuck> +1 to GV

<alastairc> +1, let's keep the start simple.

GreggVan: If i were a seller of noisy tools -- i would be happy with new edit since is still so complex and not unambiguous. We are moving in wrong direction...
... "this should not be a failure" is the main idea and it is not clear with more words after that idea.
... If not clear in a single sentence SC is still going to be caught by audits.

<Zakim> Chuck, you wanted to say back to the one that didn't have any objections plz

Wilco: Disagree slightly in that we have the main idea sufficiently captured.

<Chuck> POLL: Separate the first sentence into it's own note.

<mbgower> +1

<laura> +1

<Chuck> -.1 but won't object

<GreggVan> +1

<dan_bjorge> -.5, prefer one note

<corey_hinshaw> +1

<kirkwood> +1

<Wilco> - .5

<ShawnT> +1

alastairc: Greggs suggestion on screen. 1 note as always statisfied. 2 note is explaination.

<alastairc> +1, but not concerned either way.

<Wilco> yes

<dan_bjorge> ys

<dan_bjorge> yes*

<kirkwood> and Chuck?

Chuck: Need clarification to -1 ? Do i have concern correct?

<alastairc> Note: This Success Criterion should be considered as always satisfied for any content using HTML or XML.

<alastairc> Note 2: Since this criterion was written, the HTML Standard has adopted specific requirements governing how user agents must handle incomplete tags, incorrect element nesting, duplicate attributes, and non-unique IDs.

<alastairc> Although the HTML Standard treats some of these cases as non-conforming for authors, it is considered to "allow these features" for the purposes of this Success Criterion because the specification requires that user agents support handling these cases consistently. In practice, this criterion no longer provides any benefit to people with disabilities in itself.

<alastairc> Issues such as missing roles due to inappropriately nested elements or incorrect states or names due to a duplicate ID are covered by different Success Criteria and should be reported under those criteria rather than as issues with 4.1.1.

Chuck other concerns?

GreggVan: Notes should be numbered.

RESOLUTION: Accept amended notes on 4.1.1 for WCAG 2.0 and WCAG 2.1

Bruce clarifies that 1st note is stand alone

dan_bjorge: We still have Wilco's 2nd question.

Wilco (from survey): ALSO: I think we need to talk about using this note in WCAG 2.2 in place of removal of the SC. This is substantial new information on the decision regarding the removal of 4.1.1. Even if we change nothing, we should have the conversation.

<dan_bjorge> Chuck sounds good for me

Chuck: We had CFC, but we have new information.

GreggVan: All of the new information is convoluted only because of history. It makes other SC suspect.

<AWK> +1 to gregg

Wilco: Note does not say "automatically met" is satisfied only for HTML
... plan for 2.0 / 2.1 made before we finalized phrasing for 2.2

<Zakim> GreggVan, you wanted to ask "is there any known problem anywhere else?"

dan_bjorge: How certain are we that this SC should not be applied to, for example, PDFs?

<Wilco> How familiar is anyone with LaTeX?

<alastairc> dan_bjorge - PDFs don't count as a markup langauge

GreggVan: Is there any known problem? No, and we have been looking. That answers the question as to if we should have speculative SC.

AWK: PDF not a mark-up language, so not applicable.
... We have to have affirmative reasons to keep in 2.2.

<Zakim> Chuck, you wanted to say CfC'd

AWK: That said, I still have concern for revisiting unwinding a previous CFC decision.

Rachael: We could straw poll about revisiting on this call. So, not reversing anything on this call.

Chuck asks Wilco to suggest poll phrasing

<Chuck> POLL: Explore using the notes in WCAG 2.0 and WCAG 2.1 in place of removing 4.1.1 from WCAG 2.2 (no prior decisions will be recinded at this time)

<GreggVan> -1

<Chuck> -1

<mikeGower> -1

<Rachael> -1

<Wilco> +1

<AWK> -1

<kirkwood> -1

<dan_bjorge> -1

<alastairc> -1

<Detlev> can' tell

<Jaunita_George> -1

<laura> 0

<ShawnT> -1

<Zakim> GreggVan, you wanted to say "we should always be open to changing a decision --- but it has to meet a high bar and say there is new information to consider"

<Francis_Storr> -1

Chuck: -1 have clear majority on this call

<Makoto> 0

GreggVan: +1 to Rachael's suggestion and what we just did -- never wrong to ask ourselves if we have new question

Wilco: Can we have resolution to the negative?

<GreggVan> +1 to that suggestion

<Chuck> proposed RESOLUTION: Notes on 4.1.1 for WCAG 2.0 and 2.1 will not be used for WCAG 2.2, and 4.1.1 will be removed from WCAG 2.2

<Chuck> proposed RESOLUTION: Notes on 4.1.1 for WCAG 2.0 and 2.1 will not be used for WCAG 2.2

<GreggVan> +1

<AWK> +1

<Jaunita_George> +1

<Rachael> +1

bruce asks to drop second phrase

<ShawnT> +1

RESOLUTION: Notes on 4.1.1 for WCAG 2.0 and 2.1 will not be used for WCAG 2.2

<Wilco> - .5, can live with

<GreggVan> Chuck: RESOLUTION: Notes on 4.1.1 for WCAG 2.0 and 2.1 will not be used for WCAG 2.2

[alastair reconnects and chuck summarizes]

AWK: The note for 2.0 and 2.1 -- do we need a CFC? When would this note go into spec?

<Chuck> I had assumed we need to CfC

alastairc: These new notes would be part of the 2.0 / 2.1 republishing -- which we have already CFC agreemetn.

s/agreementn/agreement

GreggVan: Will 2.0 also be republished?

Target Size

alastairc: 2.1 republished agreed to, as was errata. 2.0 republished is not yet decited.

<alastairc> Spacing Alternative: Targets that are not 24 by 24 CSS pixels are positioned with sufficient spacing so that if a 24 CSS pixel diameter circle is centred on the bounding box of each, none of the circles intersect another such circle or target.

<dan_bjorge> ed: "centered"

Other WCAG 2.2 issues survey, Q3-5 (not new) https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/

alastair screen shares for call

<dan_bjorge> Yes, and so did the old version

Gregg: Does this allow 1 px target?

<mikeGower> Every version has allowed that

<mikeGower> Not purpose of survey

alastairc: Yes, but we previous addressed 1 px target "loophole" previously and come to terms with that.

<mikeGower> Chair?

GreggVan: I disagree that 1px target should ever be permissible. It is not just about hardware compensating for finger.

Chuck: That is separate topic, and do not want to derail this conversation.
... AAA version scheduled to be revisited.

<mikeGower> Undersized

dan_bjorge: I know we discussed previously, but is there path to resolve this in 17 min ?

<mikeGower> No

Wilco: I think 1 px target excluded by edit to exceptions.

GreggVan: AA allows for 1 px sized targets?

alastairc: We discussed extensively previously.

Chuck: Min size not a topic for discussion today.

<Zakim> Chuck, you wanted to suggest we reset if the indivduals who inspired this aren't satisfied with the proposal

dan_bjorge: The present phrasing is to avoid having to draw target circles on every target -- only where/when necessary to use exception.

Chuck: Do we need a reset? Wilco is not confident that his edit is not exactly aligned with exeception.

mbgower: Reason for "not 24x24" replaces "undersized" but is last option in exception, so we think it is okay.

<mbgower> yes

<mbgower> yep

mbgower: We still have an issued with "centered" and there was concern for adding "bounding box" because there are some odd consequences.

<Chuck> q

<JenStrickland> +1 to Wilco

Wilco: I am still not clear on phrasing. Only less three words make exception applicable?

mbgower: Correct, the intent is to only allow last exception in narrow cases. Understanding documents will have several illustration.

<mbgower> This began "Undersized targets are positioned..."

Wilco: Phrasing does not say what you want. The qualifier belongs to front of bullet, not at end.

JenStrickland: +1 to wilco's concern that this is too hard to grok...

<Zakim> Chuck, you wanted to ask Alastair to explain his "proposal"

JenStrickland: From Human Interface Guidelines has simpler phrasing [reads]...
... Where is abstracted language coming from?
... can I work with Wilcon drafting?

Wilco: We have drafting, so think we are very close.

<mbgower> Much of this is illustrated in a PR version of the Understanding document

<GN05> what about adding "any" or "any other" before "target?

<Zakim> mbgower, you wanted to say talking about spatial orientation in language is challenging. We have been through multiple approaches

alastairc: We had date pressure. The SC starts with basis requirement for 24x24 ... so spacing exception says dont intercept other targets.

JenStrickland: Will we get more feedback from public?

<alastairc> we've had 3 rounds already, this is much simpler than the current version

<GN05> +1 to alastair

mbgower: This is a option for replacing the CR phrasing -- which is more complicated and requires "target offset"...
... it is going to be hard to express this in text.

<mbgower> "another" is already in it

<dan_bjorge> The written form is already "*another* such circle or target", no?

<Wilco> none of those circles intersect another target, or the circle for undersized targets

<alastairc> GN05 - I'm not sure which bit?

Gundula: Listening closely, I still have trouble following.

<JenStrickland> Apple identifies, "Give all touchscreen controls and interactive elements a hit target that measures at least 44x44 pt." https://developer.apple.com/design/human-interface-guidelines/foundations/accessibility#interactions

Wilco: I suggest including "undersized targets" because it ties metric to new bullet

Chuck: Alastair drafting on screen.

alastairc: We don't have Gundala's suggestion.

<GN05> In the last sentence of the exception as currently shared in zoom, I suggest to add "any other" or "another" in front of the word *target* (last word).

mbgower: Recent drafting removed "undersized targets" because that that seems a confusing phrase. But if no objection to that term, we can keep working this

<mbgower> No, it says it at the very start

Wilco: We are almost there. The problem is "undersized at end". Leave second use of undersized.

<mbgower> me too

Rachael: I disagree with change, because we are not defining -- we are just expressing condition.

<dan_bjorge> agree, I think this needs the original "targets which are less than 24 by 24 CSS pixels" text if our intent is to define undersized here

<Chuck> I must leave, someone else must moderate.

Rachael: also catches undersized targets which Gundala is concerned for.

<GN05> I like "Spacing Alternative", as either the target is large enough or it has enough space around it.

mbgower: I am okay to add even if redundant or repative , but I do not think it changes the exception...
... adding length also increased cognitive complexity

Wilco: I do think it is clear.

<alastairc> Undersized targets are positioned with sufficient spacing so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, none of those circles intersect another target or the circle for another undersized targets.

<GN05> -1 to the screen suggestion

alastairc: I do not think the version on screen is exactly what wilco has concern for

<mbgower> the name of the bullet does not define it

<Rachael> scribe+

<GN05> if the circle may not overlap other ircles, it still may overlap big targets.

<Rachael> Wilco and Alastair discuss defining undersized target.

[discussion on what is being considered]

<Rachael> mbgower: Looking back at what was originally considered.

scribe-

<Rachael> alastairc: I think Wilco's concern was getting the beginning and end to work together. If we say undersized target at the beginning and then at the end.

<Rachael> mbgower: I can live with any variation but I feel the longer it is the less likely people will get to the end. I'd like to focus on the principle.

<Rachael> ...I didn't hear Wilco object to that principle.

<Rachael> ...maybe we dig at that.

<Rachael> alastairc: I will need to move this to list and have another go

<Rachael> GN05: I thought the other order was to understand. I think "another targets" should be singular.

<Rachael> alastairc: That would be correct. For me, this has gotten very long. I'm not sure its saying anything different.

<Rachael> ...I will try to break it down to a couple of versions and send it to the list.

<Rachael> mbgower: Do you have the PR that Patrick made applying the circles to the understanding? That may help.

<Rachael> [looking through that]

<alastairc> https://raw.githack.com/w3c/wcag/patrickhlauke-target-size-minimum-issue3089-companion/understanding/22/target-size-minimum.html

<alastairc> https://raw.githack.com/w3c/wcag/patrickhlauke-target-size-minimum-issue3089-companion/understanding/22/img/target-spacing-toolbar.svg

<Rachael> ...Looking at the understanding may help better understand how it works.

<Rachael> alastairc: These are to scale so give a better understanding of how small a target we're talking about when they do fail.

<GN05> I love these examples!

<Rachael> mbgower: You can see the first example pass. The second the circles do not overlap so they pass. The third, the circles overlap so this fails.

<kirkwood> shouldn’t we say ‘overlap’ instead of intersect? they do indeed intersect when the pass. hmmm.

<alastairc> Technically targets cannot overlap, one of them will be on top and the other target isn't part of that anymore.

<Rachael> ...then if you go to the next example, there is a target that sits over the other target. In the first, both targets are 24x24 so pass.

<kirkwood> in the examples we say ‘overlap’

<Rachael> In the second one, the target is smaller and the circle overlaps so it fails. In the next one, the circle around the undersized target still intersects so it fails. In the last example, the smaller target is far enough away that that circle no longer overlaps and so it passes.

<Rachael> alastairc: I will put together a few examples. We used overlap previously but it led to objections which is why we moved to "intersect"

<Rachael> mbgower: We need to update understanding documents to match new language.

<Rachael> kirkwood: Intersect is typically a single point.

<Rachael> alastairc: overlap, abut, they all come down to a similar concept.

<Rachael> dan_bjorge: I think they all mean similar things but we can explain in understanding. I will support whichever language reduces objections.

<Rachael> alastairc: I will pull something together that removes controversial points.

<alastairc> https://docs.google.com/document/d/1N38qrHOJSXW-OrJI7GiSjQwaYZxh5OBDJ36No7p2Ax4/edit#

<Rachael> dan_bjorge: What if we move undersized target to definiton?

<kirkwood> “undersized target” is less than 24x24 is assumed?

<Rachael> mbgower: I think we can mash it up. "targets with less than 24x24 pixels have sufficient spacing. "

<Rachael> [wordsmithing document]

<Detlev> it's confusing - can we simplify, shorten?

<Rachael> GN05: discussion about plurality in text.

<alastairc> see the other versions above, it started shorter...

<Rachael> q

<GN05> +1 to Detlev, I am not happy with the term 'undersized spacing' either.

<Rachael> +1 to not using "undersized spacing".

<Rachael> Detlev: Concern about "undersized spacing"

<Rachael> [Discussion about removing "undersized"]

<kirkwood> Targets less than 24 x 24 pixels are positioned such that the active target area is at least 24 x 24 pixels.

<Rachael> [discussion of "active target area"]4

<alastairc> Target: region of the display that will accept a pointer action, such as the interactive area of a user interface component

<kirkwood> argets less than 24 x 24 pixels are positioned such that target is at least 24 x 24 pixels.

<GN05> I liked naming the spacing, as it helps the visualization in mind on what is meant here.

<Rachael> mbgower: Suggested removing the "sufficient spacing" phrase and led group converation around intersect vs intersects

<alastairc> Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, none of those circles intersect another target or the circle for another undersized target.

<GN05> we might say 'centered in the bounding box'

<Rachael> GN: The original text focuses on the singular. This is now addressing multiple.

<Rachael> mbgower: We need to focus on all of them.

<Rachael> GN: We used to compare a single target against all the other targets.

<Rachael> [discussion of plural vs. singular]

<dan_bjorge> Singular version: "Spacing: The target is positioned so that if a 24 CSS pixel diameter circle is centered on the target's bounding box, the circle does not intersect another target or the circle for another undersized target (less than 24 by 24 CSS pixels)."

<kirkwood> +1 to removing language “centered on a bounding box”

<dan_bjorge> Singular version: "Spacing: The target is positioned so that if a 24 CSS pixel diameter circle is concentric with the center of the target's bounding box, the circle does not intersect another target or the circle for another undersized target (less than 24 by 24 CSS pixels)." (oof)

<dan_bjorge> Singular version: "Spacing: The target is positioned so that if a 24 CSS pixel diameter circle is centered on the target, the circle does not intersect another target or the circle for another undersized target (less than 24 by 24 CSS pixels)." (oof)

is "centered within bounding box" different than "centered on bounding box" ?

or center *of* bounding box ?

<dan_bjorge> intention is center of bounding box

<Rachael> GN: I prefer having "centered on the target's bounding box" because of star and moon shaped targets.

+1 to "centered of the target's bounding box" -- is least bad

sorry, centered ON target's bounding box

<mbgower> Thanks, folks!

<Rachael> No wcag 2 meeting on Friday!

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/annoucnements/announcements/
Succeeded: s/explainationg/explaination/
Succeeded: s/"authored in html"/"for any content using HTML"/
Succeeded: s/no AT reads AT/no AT reads HTML/
Succeeded: s/complicaatd/complicated/
FAILED: s/agreementn/agreement/
Succeeded: s/to fail/when they do fail/
Default Present: ChrisLoiselle, Jennie, Lauriat, Laura_Carlson, MichaelC, ShawnT, GreggVan, Chuck, Ben_Tillyer, Peter_Bossley, Cyborg_, corey_hinshaw, bruce_bailey, jeanne, alastairc, mbgower, Raf, Makoto, Francis_Storr, Wilco, kirkwood, AWK, Poornima, mgarrish, Katie_Haritos-Shea, Jaunita_George, wendyreid, dan_bjorge, Rachael, JenStrickland
Present: ChrisLoiselle, Jennie, Lauriat, Laura_Carlson, MichaelC, ShawnT, GreggVan, Chuck, Ben_Tillyer, Peter_Bossley, Cyborg_, corey_hinshaw, bruce_bailey, jeanne, alastairc, mbgower, Raf, Makoto, Francis_Storr, Wilco, kirkwood, AWK, Poornima, mgarrish, Katie_Haritos-Shea, Jaunita_George, wendyreid, dan_bjorge, Rachael, JenStrickland
Regrets: JenniferS
Found Scribe: mbgower
Inferring ScribeNick: mbgower
Found Scribe: bruce_bailey
Inferring ScribeNick: bruce_bailey
Scribes: mbgower, bruce_bailey
ScribeNicks: mbgower, bruce_bailey

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.)