<jeanne> scribe: jeanne

new members and topics

<Rachael> https://www.w3.org/WAI/GL/wiki/Upcoming_agendas

RBM: If anyone wants to introduce themselves or new topics?
... we track topics

Who can attend next week’s meeting?

<JF> +1

<Chuck> +1

<Wilco_> +1

RBM: Next Tuesday is 2 days before US Thanksgiving

<laura> +1

<Detlev> +1

<JakeAbma> +1

<shadi> +1

<alastairc> +1

<ShawnT> +1

<Lauriat> +1

+1

<Fazio> +1

<tink> +1 to attend next week.

<GreggVan> +1

scribe: enter +1 if you can attend

RBM: We will meet next week

Plan for upcoming meetings

<Rachael> Schedule https://docs.google.com/spreadsheets/d/1yzR1H0SnNFRELGchb_BJr4Necsrj6xVjDF1n7Tc0kTc/edit#gid=0

RBM: I want to walk people through the plan for the next few meetings
... [above] is a link to the schedule
... we will revisit in a few months
... we are working off the issues in Github
... we are working on measurement based on proposals we received.
... if any of the subgroups are ready to bring something back to the main group

<Rachael> group-ag-plan@w3.org

RBM: If you are ready for feedback from the main group, let the chairs know

<Rachael> https://www.w3.org/events/meetings/fdb72858-31c8-4507-b12b-c72a3fcafdaa

RBM: There will be an all-day session to close WCAG 2.2 issues. Please particiipate by survey if you can't participate in the all day session
... Friday December 3

AC: The Friday group has been working hard on closing issues

<alastairc> https://www.w3.org/2002/09/wbs/35422/

AC: look at the survey page to see some of the work done and prepare for that meeting

WCAG 3.0 Requirements https://www.w3.org/2002/09/wbs/35422/WCAG3_requirements/results

Does the Silver scope covers closed systems / kiosk UIs?

RBM: We are working on WCAG 3.0 Requirements.

<Rachael> https://github.com/w3c/silver/issues/225#issuecomment-818826260

RBM: the issue asks if we include kiosk

<GreggVan> +1 to that since some kiosks use Web technologies

RBM: five agreements, and two disagree
... [reads JF comment] on kiosks being user agents and therefore are included

<JF> https://www.w3.org/TR/wcag-3.0-requirements/#wcag-3-0-scope

JF: On "Support for the Operating Systems and Other Platforms" that there will probably be something, but we don't know what it will be yet.

<Fazio> +1JF

JF: we expect it to be the web technology stack. WCAG has been used to validate kiosks in the past

RBM: [reads Laura's comment] to not go backward in 3.0 and keep the door open a bit
... [reads] that will include kiosks as user agents
... [reads] Alastair's comment

AC: We want the scope to be more broad but we have to be careful what we say about it.

<Detlev> typo "venders"

<Rachael> Topics: options of do not adopt closed systems, adopt closed systems with web technologies, or adopt all close systems

GV: We need a 4th option for closed systems

<Rachael> Topics: do not support closed systems, support closed systems with web technologies, or support all close systems

GV: we have to differentiate between "These guidelines are useful for" and "this guidelines are applicable to"
... WCAG2ICT applies well but does not work with closed products. Because they have to make it accessible to assistive technologies. On a closed product may not be able to be accessed by assistive technologies
... if we include kiosks, we have to also have physical access considerations, like reach and wheelchair access to a booth.

<Fazio> My argument is that kiosks are supported by the web (cloud)

GV: W3C is a web standards body, and we may find a backlash from other standards groups who say that W3C is exceeding their mandate.

<AWK> +1 to Gregg

<AWK> +AWK

<alastairc> Good point that 'closed systems' are different from "native platforms".

<Fazio> +1 Leonie

LW: JF made a good point about existing language. GV also said we would have to include physical access if we specifically discuss kiosks. Best not to ruffle feathers of other groups when we should focus on writing good accessibility standards

JF: IN Requirements for WCAG 3.0 (https://www.w3.org/TR/wcag-3.0-requirements/#wcag-3-0-scope), we mapped out what we hope to achieve. I don't like the final sentence "It doesn't apply to closed systems". We don't know that yet.
... it was a difficult negotiation of the charter, the browsers didn't want us to stray into their territory.

DF: During audits, we encounter code that is running in the browser that we have no access to. Would we include that under closed content.

<alastairc> Suggested re-wording on Rachael's last 2 sentences: " It may apply to closed systems that utilize web technologies, but it would not tackle the physical aspects or user-agents of those systems."

<JF> +1 to Judy

JB: I recommend that the group to keep the language consistent with the charter, particularly with what is given as examples.
... the language of "applies to" couild cause concern. The language "is useful for" is better.

<alastairc> Re-suggesting: "WCAG 3.0 could be used with closed systems that utilize web technologies, but it would not tackle the physical aspects or user-agents of those systems."

JB: the W3C is expanding into areas that are not traditional web based, like automotive and virtual reality, but they are web technology based.

<Zakim> GreggVan, you wanted to say "closed does not relate to locking browser in kiosk mode or not -- it relates to whether the user can install AT on the device. "

<Detlev> thanks for the clarification, makes sense

<Zakim> alastairc, you wanted to suggest updated response

GV: When we talk about kiosks, we have to be able to plug in assistive technologies. So that the content could technically meet WCAG, but be completely inaccessible to someone who needs assistive technology.

AC: We aren't going to give the answer of specifically whether we are going to write requirements for kiosks or petrol pumping stations. We have to give an answer that is not specific.

<Zakim> GreggVan, you wanted to say "can help in making closed products accessible but do not include many provisions that would be needed for closed products"

<JF> I can live with Alastair's proposed edit

GV: If you just put issues in there, instead of user agents and physical.

<Rachael> draft RESOLUTION: respond with "WCAG 3.0 could be used with closed systems that utilize web technologies, but it would not tackle the physical aspects or user-agents of those systems."

<Ryladog> +1

<ShawnT> +1

<Rachael> draft RESOLUTION: respond with "WCAG 3.0 could be used with closed systems that utilize web technologies, but it would not tackle issues around the physical aspects or user-agents of those systems."

<GreggVan> +1

<Nicaise> +1

<ShawnT> +1

<Ryladog> +1

GV: Issues around, not just physical aspects

<kirkwood> could we include “does not include assistive technology of such systems”?

<alastairc> I'm updating the issue response here: https://github.com/w3c/silver/issues/225#issuecomment-818826260

JB: I think the proposed language could be misunderstood and that it matters. It could be applied to the web response as well.

<JF> +1 while recognizing Judy's nuanced concerns

JB: when we try to answer that it would have to be addressed in a new charter.

<Rachael> "WCAG 3.0 could be used on the web-based portion of closed systems that utilize web technologies, but it would not tackle issues around the physical aspects or user-agents of those systems."

<alastairc> I'm not clear what an update would be?

<Wilco_> +1

<Wilco_> Also yes, prefer "useful for"

<Rachael> "WCAG 3.0 could be useful for on the web-based portion of closed systems that utilize web technologies, but it would not tackle issues around the physical aspects or user-agents of those systems."

JB: I think that is better. I also recommend "is useful for"

<Rachael> "WCAG 3.0 could be useful for the web-based portion of closed systems that utilize web technologies, but it would not tackle issues around the physical aspects or user-agents of those systems."

<Chuck> +1

<GreggVan> +1

<JF> +1 to latest proposed edit

<laura> +1

<kirkwood> +1

+1

<ShawnT> +1

<Judy> +1

<Ryladog> +1

<Nicaise> +1

<Wilco_> +1

<Rain> +1

<AWK> +1

<MarcJohlic> +1

<alastairc> +1

<Rachael> scribe: Rachael

<tink> +1

RESOLUTION: Respond with "WCAG 3.0 could be useful for the web-based portion of closed systems that utilize web technologies, but it would not tackle issues around the physical aspects or user-agents of those systems."

<scribe> scribe: Wilco_

<scribe> scribe: Wilco

Backwards Compatibility Question

<Rachael> Response: https://github.com/w3c/silver/issues/424#issuecomment-966166500

<Fazio> I feel like here's where a Maturity Model is helpful

Rachael: 5 agreements, 4 agree with adjustments
... JF has a word-smithed response.

JF: In particular the middle paragraph helped clarify this in my mind.

Rachael: Andrew Summers added suggestions as well.
... Gregg agreed with some adjustments... Reading comment.

<Fazio> I think the response needs a yes or a no

Gregg: The other comments are good. The idea of harmonization, should be added. The fact that they're harmonized, they don't contradict each other is something to put in.

AWK: I think we might be able to mitigate their concern. To Gregg's comment, some things may be incompatible and may not be able to harmnoized, for example color contrast.
... We need to allow ourselves to make those decisions, even if they're hard decisions to make.
... We need to minimise that and be transparent about that.

<alastairc> Suggested addition from AWK's comment: The group intends to work on a mapping from WCAG 2.x to 3.0, which should help organisations update their testing procedures.

<Rachael> Topics: Wordsmithing of central sentence, add idea of harmonization, add a mapping to reduce testing burden

<Zakim> alastairc, you wanted to note side question of backwards compatibility AFTER WCAG 3.0 is published

Alastair: Happy to take on JF's version of the middle paragraph.
... As Andy's not here, I wanted to mention what the person isn't asking, but have we considered backwards compatibility after WCAG 3 is published.
... WCAG 2 is backward compatible, which has been stringent. Don't need to discuss that today.

<JF> OOOH! I'd strongly votge for backward compat for WCAG 3.x as well

<Zakim> Chuck, you wanted to support both JF and GV suggestions

Fazio: I don't see a clear yes, no, maybe answer. I think that's problematic, why can't we just tell them?

Chuck: I like JF and Gegg's suggestion. Andy's suggestion was a bit too heavy-weighted for me.

<alastairc> Updated response: https://github.com/w3c/silver/issues/424#issuecomment-966166500

<alastairc> which includes JF's middle sentense, and a new mapping comment.

Gregg: Andrew's comments about mapping is really important. If there's a chance we're not going to harmonize we should not commit it, or say that every attempt will be made to try.

<Zakim> GreggVan, you wanted to say Agree with andrew's comments 1) about mapping and 2) about AVOIDING the use of harmonization until we are sure that it is possible (reversing my

<Zakim> alastairc, you wanted to talk to the yes/no

<Fazio> I feel like we should clarify that from the first sentence

Alastair: I'm not sure we can provide a yes or no. What we can say is that we're not backward compatible between 3 and 2. I wouldn't want to mention harmonization.
... Things around contrast, and various things may not be compatible.

JF: We're looking for harmonized outcomes. It's not about guidelines / techniques. Any defined outcome from 2.x is going to carry through in 3.x.
... I think that's the term to focus on.

<Zakim> Rachael, you wanted to request we create an issue against requirements to discuss 3.x backwards compatibility

Rachael: Chair hat off; I don't know that we've talked about 3.x compatibility across versions. Can someone open an issue on that?

Alastair: I'll open an issue on it

<Rachael> Updated response: https://github.com/w3c/silver/issues/424#issuecomment-966166500

Rachael: Here's an update to the response.

<Chuck> +1, and am supportive of using "mapping" instead of harmonizing.

Rachael: Any changes needed for the response?

JF: In the word paragraph, there's a verb tense to harmonize.

Rachael: Alastair has fixed.

<Rachael> draft RESOLUTION: adopt updated response https://github.com/w3c/silver/issues/424#issuecomment-966166500

<Chuck> +1

<Ryladog> +1

<laura_> +1

<Rachael> +1

<Rain> +1

<jeanne> +1

<JakeAbma> +1

<MarcJohlic> +1

<alastairc> +1

<ShawnT> +1

<Fazio> 0

<JF> +1

+1

<kirkwood> +1

RESOLUTION: adopt updated response https://github.com/w3c/silver/issues/424#issuecomment-966166500

Request to add Do No Harm to requirements

Rachael: 6 people who agree, 2 who disagree

Alastair: I got a sense from Jeanne's comment that it would be difficult to do. It's something we've tried to do. I don't think it's problematic

Jeanne: The example that comes to mind is color contrast. It benefits some people, and cause problems for some others. Setting this as a requirement is something that can't be achieved

Wilco: I think my comment is clear.

<Chuck> I hear one topic: Moving target (can't define or test)

AWK: Harm is not defined, if it was, we could better evaluate

<Rachael> Topics: Is this a measurable requirement, how define topics

JF: I agree with the concept, also agree with Jeanne, Wilco and Andrew. Measuring harm is impossible to do. It's a guiding principle
... I think we're tripping up over terminology.

<Zakim> GreggVan, you wanted to say I agreed because it was just a general goal - not a requirement

JF: Anything and everything we do should not cause harm. I don't think it should be a requirement. It should be a guiding principle.

<JF> I think Gregg and I are in strong agreement

<Zakim> Lauriat, you wanted to ask clarification of the topic

Gregg: These are principles for us as guideline creators. It's not a requirement.

Shawn: In light of the design principles, is the topic specifically; do we add anything about this? Or is it for the requirements?

<Lauriat> As noted, we have Design Principles in our Requirements document explicitly for things that should guide us, but may prove unmeasurable or ongoing: https://www.w3.org/TR/wcag-3.0-requirements/#design_principles

<Chuck> -1 to requirements, +1 to principal

Rachael: The initial question is should it be a requirement. It sounds like the question should be if it's a principle.

Katie: If the design principles are going to be like the conformance requirements, then that makes sense.
... If not, have we answered if we're going to do conformance requirements?
... The WCAG 2 conformance requirements are whole pages. If we have something along those lines in WCAG 3, it would be a good place to have it.

<Zakim> alastairc, you wanted to suggest adding it to the Design Principles section

Alastair: Suggest we add something to the design principles. Something for someone to take away and wordsmith.

<Rachael> draft RESOLUTION add this principle to the Design Principles but not a Requirement

<Rachael> draft RESOLUTION add this principle to the Design Principles but not a Requirement, define harm as part of wording

<Rachael> akc Wilco_

<Chuck> Wilco: Prefer to see draft before we resolve.

<Rachael> Wilco_: I would prefer to see the draft first before.

<Rachael> draft RESOLUTION Draft this principle for addition the Design Principles but not a Requirement, define harm as part of wording

Rachael: Other suggestions to the wording?

<jeanne> +1

<Chuck> +1

+1

<Lauriat> +1

<Rachael> +1

<GreggVan> +1

<MarcJohlic> +1

<Rain> +1

<Detlev> +1

<JF> +1

<kirkwood> +1

<GreggVan> +1 and also say warn against trying to define Do no harm which is a general principle

<ShawnT> +1

<Ryladog> +1

<alastairc> Suggested starting point: (Accessibility guidelines should:) Not support one group of people with disabilities at the expense of another group.

Jake: In the functional needs group we've talked about harm, where we can to another principle, which we called distractions and inflictions.
... It's a user need, together with a functional need. It might also be a user need, together with some sensitivity to flashing, it ends up in the intersection of adding multiple outcomes.

Rachael: For clarity, we're talking about principles for writing WCAG 3
... Seeing no objections. Is someone willing to take on drafting this principle?

RESOLUTION Draft this principle for addition the Design Principles but not a Requirement, define harm as part of wording

<alastairc> I think "harm" was just mentioned because it was matching the doctor thing, we can use other terms!

Rachael: If someone changes their mind on time, please let us know. If not Jeanne will draft a proposal.

ACT New Rules https://www.w3.org/2002/09/wbs/35422/act_nov_10/results

<Fazio> Wilco: TF working on update to Note to include rules - 6 agreed on rules in TF

Common Input Aspects note

<Fazio> Wilco: Updates to existing rules coming

<Rachael> https://github.com/w3c/wcag-act/pull/520/files

<Rachael> https://github.com/w3c/wcag-act/pull/521/files

<Rachael> q

<Fazio> MG: Item needs more attention

<alastairc> This is a really good bookmark: https://www.w3.org/WAI/GL/wiki/Upcoming_agendas

<Rachael> Upcoming agendas are always at https://www.w3.org/WAI/GL/wiki/Upcoming_agendas

<alastairc> It is also the top link on the wiki page.

<Fazio> Gregg: would like evergreen page/link

<JF> no objections

WCAG 2.2 Focus appearance (1 new question added) https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results

Use of the word “state” is not sufficiently consistent #2049

<alastairc> https://www.w3.org/2002/09/wbs/35422/wcag22-target-size-min/

WCAG 2.2 Target size https://www.w3.org/2002/09/wbs/35422/wcag22-target-size-min/results

Target Size addition of user agent and equivalent exceptions #1993

<Rachael> PR: https://github.com/w3c/wcag/pull/1993/files

<Fazio> AC: some d8 agree 2 want something else

<Fazio> Wilco: not modified by author too vague

<alastairc> How about "The size of the target is determined by the user agent and cannot be modified by the author;"

<Fazio> Gregg: having inaccessible control is ok as long as another one exists that is accessible, but it doesn't clarify

<Fazio> AC: browser generated components exist- author would have to recreate

<Detlev> think "cannot" is the right approach

<Zakim> mbgower, you wanted to say the user agent control is taken near verbatim from the existing language of the enhance version of target size

<Jemma> wonder about "I" in wilco's point, "If I adjust the default font-size of the page, did I inadvertently change the size of all my components, so now I'm responsible? "

<Fazio> MG: language is verbatim 2.5.5

<Jemma> above scenario of "I" seems to be individual/customization case.

<mbgower> as well, it is the same language used in 1.4.13

<Rachael> remove the essential point nad come back to it with the appropriate issue.

<Zakim> Chuck, you wanted to respectfully disagree with Wilco

<Zakim> mbgower, you wanted to say the language is also in 1.4.13

<Fazio> chuck: language is prevalent throughout wcag. adding definition now would impact other SC's

<mbgower> 1.4.13 is AA

<alastairc> Does anyone object to 'cannot be modified' to address the browser-based controls.

<Fazio> Wilco: what fits into category of adjustments

<Zakim> mbgower, you wanted to say I can provide an example

<Fazio> AC: "cannot be modified by author" could address more complex controls

<Fazio> MG:"cannot" subjects author to implementation of bad user agent

<alastairc> So you're saying we should not exempt the authors from bad user-agents?

<ShawnT> +1 mbgower

<Jemma> +1

<Jemma> to mbgower

<JF> +1 to Wilco

<Fazio> MG:Wilco: text is really open to bad faith interpretations

<Fazio> Wilco: AC suggestion helps a little bit, maybe not enough

<Jemma> +1 detlev

<Fazio> Detlev: limiting it to what authors don't have control over is fine

<Chuck> let's get a temperature of the group

<Jemma> Rachael, that was a good rephase of the dicussion topic.

<Fazio> Rachael: thoughts on next steps?

<Fazio> AC: not sure about MG's argument on impact of AC's suggestion

<Fazio> MG: need to think about when user agent would effect target size

<Chuck> +1 mgower

<Fazio> MG: known browser implementation problems already exist. "cannot" forces authors to reinvent

<SuzanneTaylor> +1 mgower (there aren't really any cannot cases)

<Detlev> but that is not change, that is rebuilt (things like calendar)!

<Zakim> alastairc, you wanted to talk to impact, e.g. browser-based error messages and timing-adjustable.

<Fazio> MG: more chance of bad ux by authors trying to correct

<laura> In principle it parallels HTML title attribute exception in 1.4.13

<Fazio> AC: if "cannot" not included it won't get replaced

<Detlev> +1 to Alastair

<Fazio> AC: sees it in reverse

<Jemma> I think mgower and alastair are in the same page about having this exception.

<Jemma> the discussion is more about what "not modified by the author"

<Fazio> MG: doesn't want to include "cannot be altered by authors"

<Rachael> straw poll: 1. Accept wording as is 2. Better define "not modified by author" across WCAG 2.2 3. Explain in understanding document 4. revise wording

<Jemma> 1

<Chuck> 1

<ShawnT> 2

2

<mbgower> 1

<SuzanneTaylor> 1 & 3

<laura> 1

<mbgower> 1& 3

<JF> 1 and possibly 3

<Rain> 2 or 1 & 3

<Jemma> for your info, "not modified by author" across many spec

<mbgower> (and I'm okay to also better define "not modified by author" too)

<Rachael> scribe: Jemma

<alastairc> 1 & 3

s/for your info, "not modified by author" across many spec /for your info, "not modified by author" used used a lot across many spec

<JakeAbma> 2

<Chuck> 8 for 1 or 1&3...

<Zakim> SuzanneTaylor, you wanted to suggest keeping the original language, and handling Wilco's concern using the Understanding document

<Detlev> 4

suzanne: I support Wilco's point of defining

"not modified by the author"

scribe: also indicate what to do from the phrase

<Zakim> mbgower, you wanted to say I think we want user agent wording in here. i suggest incorporating and addressing language

detlev: it would be difficult to draw lines as wilco pointed. ex. browser calendar example - author can change some component

<Rachael> draft RESOLUTION: Use current wording, add to understanding, and create an issue to explore the use of "not modified by author"

mbgower: to clear our confusion. adopt this and work on making more clarification later.

<Zakim> Chuck, you wanted to ask for clarity on that proposal?

+1

<Chuck> +1

<mbgower> "proposed" not "current"?

<SuzanneTaylor> +1

<Rachael> draft RESOLUTION: Use proposed wording, add to understanding, and create an issue to explore the use of "not modified by author"

<mbgower> +1

<alastairc> +1

<Rain> +1

<ShawnT> +1

<Ryladog> +1

<laura> +1

<JF> +1 (with "proposed")

<JakeAbma> +1

<Detlev> +0 can accept that but would prefer "cannot be changed" (not the same as re-done)

group will move forward with resolution and do follow up with email

<alastairc> I think it we work through the issue, we might work out that it needs to be 'cannot' (or not)

RESOLUTION: Use proposed wording, add to understanding, and create an issue to explore the use of "not modified by author"

<Detlev> fine

detleve, we will include you to the broader dicussion to reflect your point.

mbgower: explaining the context of this sc. - preemble

Issue 1976 and same PR

alastairc: PR 1976 is related to this.

<Rachael> https://github.com/w3c/wcag/pull/1993/files

<Rachael> https://github.com/w3c/wcag/pull/1993/files

https://github.com/w3c/wcag/issues/1976

<Rachael> https://github.com/w3c/wcag/issues/1976

<Zakim> alastairc, you wanted to talk about alternatives

david: date picker case
... greg's point is different for this case
... I can talk about date picker case rather
... there is a challenge for date picker accessibility

<Zakim> mbgower, you wanted to say the date picker text input discussion is IMO orthogonal

david: trend is ..??

mbgower: date picker text box - target size issue
... function can be acheive by appropriate target size

<Zakim> Rachael, you wanted to say that 2.5.5 has additional clarification

<Rachael> The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;

mbgower: the focus is available with target size, rather than "essential" topic

rachael agree with greg's point of "findable"

<alastairc> I'd like to avoid another wide review, I think lining up with the AAA version is useful

david: looking at more common example case, rather than target size(?)

<Zakim> Rachael, you wanted to give an example

<Zakim> mbgower, you wanted to say the location is too hard to put down and to say the location is too hard to pin down

<david-macdonald> @rachel (good example)

mbgower: picking example of color picker

<alastairc> propose that we use the same exception as the AAA version: "The target is available through an equivalent link or control on the same page that has an area of at least 24 by 24 CSS pixels;"

mbgower: it is very difficult to contain location info or consider not so good design example

greg: so many problem with target size, using manigfier, mobile phone so on..

<mbgower> I can live with adding the "on the same page" language if it gets better traction

<mbgower> but it has to be "function" not target, I think

<Zakim> alastairc, you wanted to propose aligning with the AAA version

greg: if the button is somewhere else, not ajacent, it would be problematic.

alastairc: we can use exisiting language regarding "equivalent"

mbgower: fine with putting "the same page" language

<alastairc> The function is available through a different control on the same page that has an area of at least 24 by 24 CSS pixels;

<alastairc> The function can be acheived through a different control on the same page that has an area of at least 24 by 24 CSS pixels;

mbgower: we would like to focus on function achivement, not necessarily want to focus on target size

alastairc: before and after are tricky from "consistent help" sc example.

<Chuck> +1 to Alastair's second proposal

mbgower: this sc is focus on visual presentation

<Rachael> draft RESOLUTION: The function can be acheived through a different control on the same page that has an area of at least 24 by 24 CSS pixels;

<Chuck> +1

mbgower: bringing it magnifier and Dom order so on, it is hard to lineate the before and after

+1

<mbgower> +1

<Detlev> +1

<JF> +1

<ShawnT> +1

<laura> +1

<alastairc> +1

<Rain> +1

<Ryladog> +1

<SuzanneTaylor> +1

<GreggVan> +1

<david-macdonald> +1

<kirkwood> +1

<Rachael> 0 I woudl like to explore the idea of before a bit more but can do so outside this agreement and can live with the wording

RESOLUTION: The function can be acheived through a different control on the same page that has an area of at least 24 by 24 CSS pixels;

<JF> bye all

<GreggVan> +1 to Rachael's approach

<alastairc> (It did arrive in the silver list!)

s/ to lineate the before and after / to lineate the "before" and "after"

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/IN FPWD, we mapped out what we hope to achieve/IN Requirements for WCAG 3.0 (https://www.w3.org/TR/wcag-3.0-requirements/#wcag-3-0-scope), we mapped out what we hope to achieve/
FAILED: s/for your info, "not modified by author" across many spec /for your info, "not modified by author" used used a lot across many spec/
FAILED: s/ to lineate the before and after / to lineate the "before" and "after"/
Default Present: Rachael, azlan, shadi, kirkwood, ShawnT, Chuck, jeanne, Lauriat, Fazio, alastairc, Léonie, (tink), Detlev, Judy, JF, Rain, Laura_Carlson, JakeAbma, GreggVan, MarcJohlic, MichaelC, Jemma, Wilco_, mbgower, garrison__, Nicaise, AWK, Katie_Haritos-Shea, david-macdonald, Francis_Storr
Present: Rachael, azlan, shadi, kirkwood, ShawnT, Chuck, jeanne, Lauriat, Fazio, alastairc, Léonie, (tink), Detlev, Judy, JF, Rain, Laura_Carlson, JakeAbma, GreggVan, MarcJohlic, MichaelC, Jemma, Wilco_, mbgower, garrison__, Nicaise, AWK, Katie_Haritos-Shea, david-macdonald, Francis_Storr, Léonie (tink)
Found Scribe: jeanne
Inferring ScribeNick: jeanne
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Found Scribe: Wilco_
Inferring ScribeNick: Wilco_
Found Scribe: Wilco
Found Scribe: Jemma
Inferring ScribeNick: Jemma
Scribes: jeanne, Rachael, Wilco_, Wilco, Jemma
ScribeNicks: jeanne, Rachael, Wilco_, Jemma

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


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