<Detlev> Scribe: Detlev

can't find this weeks invite and agenda...

AC: Introductions, anyone?
... Changes to agenda?

Charter survey https://www.w3.org/2002/09/wbs/35422/one_or_two_groups/

AC: we had positive results on first questions - regarding direction to take in next charter
... decide now so we can get it through W3C process
... 4 answered with adjustments - JF wanted eval method in each category of testing
... Rachael is that a easonable thing to add?

Rachael: Yes

AC: Mike Gower comment (please see survey result=

<jeanne> preseent+

AC: MG mentioned that WCAG2ICT is listed under deliverables
... Shadi had minor edit. comments

<Zakim> bruce_bailey, you wanted to comment about wcag2ict too

Bruce Bailey: Wanted to call out WCAG2ICT activity more strongly

scribe: like Mike Gower

AC: If we are committing to deliverable but maybe not within charter period
... will be discussed with WCAG2ICT folks
... Laura was concerned about mention of 3rd party content

<bruce_bailey> i was hoping to see a commitment to completing wcag2ict update within charter period.

AC: good support for first question in survey to go through,
... any other comments on charter?

Gregg: In the past there was a requirement for implementations - does that still exist?
... Guidelines had to have 2 implementations in the real world

AC: That still exists
... 2 examples for each Guideline, and two sites for the entirety of requirements

Rachael: IS part of 1.2 Success Criteria in current charter
... shouldbe looked at if that is still missing in the new one

Janina: Some of the guidelines is not = must requirements

WCAG 3.0 Maturity Level Process https://www.w3.org/2002/09/wbs/35422/labeling_update_22/

AC: was not escaped for that reason though
... is a reformulation of the process applied to other content

<alastairc> https://www.w3.org/WAI/GL/wiki/Maturity_Labeling_Process#Overview_of_process

AC: generally positive comments

JF approved Mile Gower had a question about starting point and the location row

Rachael: Merlin location and starting point: they have different purposes, should be kept separate - but might be renamed
... the other points starting point when it goes into editor's draft - can be clarified
... also addresses rest of comments

Mike Gower: The process details row- can't see how that can lead to a PR

Rachael: Things may be moved to improve reading

AC: Bruce comment about terminology, editors' draft / working draft / sandbox (see survey)

Rachael: Currently sandbox is a filtered version of the editors' draft showing more mature content
... a bit unclear where the boundary is

Bruce: The working draft is more like previously - while sandbox is a filtered version - interesting

<Zakim> GreggVan, you wanted to say for any 'must' provisions there must be implementations before it moves to penultimate level of maturity

Rachael: Was decided rather than having completely separate draft

Gregg: You mean the filtered version of editors' draft filters out exploratory content
... approval to add to editors' draft - but nt the same thing for working draft? Ah no, sorry

<Rachael> Themes for discussion: 1) Should we rename Location to something like "Location public views content", 2) Should we move "Approval to add the Editor's Draft". 3) Change "The subgroup develops proposals for review by the working group. This is done using wikis, google docs or whatever the subgroup finds useful." to "The subgroup develops proposals for review by the working group. This is done using wikis, google docs or whatever the subgroup

<Rachael> finds useful to start with. It then becomes a PR to be added to the Editor’s draft."

Gregg: for must provisions there should be 2 implementations before it gets further
... before approval to add to working draft

<Rachael> 4) Adding a requirement to move to refining "and working examples of application."

Gregg: we should add requirements for working examples showing applicability

Janina: Greggs desire makes sense, but be need real world applications, it might change during work, so implementation in real sites may be too early - eternal problem of people picking up requirements too early

<jeanne> +1 to Janina that Gregg's suggestion is too early in the process. We should wait until Mature stage

<Zakim> alastairc, you wanted to ask if that's a W3C process, or something we've added.

<Ben_Tillyer> +1 to Janina's concerns

AC: familiar to WCAG 2.X process implementations were in CR stage of the process
... wasn't aware of a requirement to do this earlier - is that a process req?

<janina> qq+

Gregg: When we did the original 2.0 we did not put anything in that had not been done before -

<alastairc> q/

Gregg: we are talking about moving things into the mature level, we should not do that before there are any examples of doing that anywhere at all

<Zakim> janina, you wanted to react to GreggVan

Gregg: so we should not ask people to adopt things that are not done anywhere

Janina: We should mark it up but we may not be able to point to full implementations

Gregg: Agree, it can be a mock-up, we may do it ourselved

<Zakim> Rachael, you wanted to point out refining would be too early

Janina: We may be seen as not publishing often enough

<Chuck> +1 to moving into "mature"

Rachael: Refining, then we are looking at mature content, we then look at examples because we are no longer changing it around

Gregg: Nothing should get into a working draft that has never been implemented
... nto even on their own site

Mike Gower: Before anything makes it into WD it will have a lot of examples and discussions, implementations in the wild...

<GreggVan> +1

DF Input purpose??

Janina: We need feedback from the wild - how do we get comments before working draft?

<Zakim> alastairc, you wanted to say, include "examples" in the approval for WD cell?

Janina: editors' draft is updated frequently - unlikely to get comments on that from the ouside

AC: We agree we need some for of example implementations prior to the WD stage

<Zakim> GreggVan, you wanted to say we arent talking about feedback from the wild -- we are talking about some proof of concept before we move it to workign draf

AC: should we add that?

<shadi> +1 to proof-of-concept/examples

Gregg: Agree - it's just a proof of concept

<Rachael> +1 to proof of concept

Gregg: maybe a better way of putting it rather than 'implementations'

<Chuck> +1

<laura> +1 to proof of concept

Should we rename Location to something like "Location public views content"

AC: Anyone disagrees about additional it?
... adding it?
... Should we rename that - any disagreement to that change?

<GreggVan> +1 award to Alastair for wordsmithing

2) Should we move "Approval to add the Editor's Draft"

<GreggVan> +1

<Chuck> +1

<jeanne> +1

3) Change "The subgroup develops proposals for review by the working group. This is done using wikis, google docs or whatever the subgroup finds useful." to "The subgroup develops proposals for review by the working group. This is done using wikis, google docs or whatever the subgroup finds useful to start with. It then becomes a PR to be added to the Editor’s draft."

<jeanne> +1

<Chuck> +1

<GreggVan> +1

AC: any disagreement?

<Ben_Tillyer> +1

<Makoto> +1

Rachael: making changes on the fly

<Rachael> https://www.w3.org/WAI/GL/wiki/Maturity_Labeling_Process#Overview_of_process

Bruce: Are losing Michael's comments?

AC: mainly editorial

Gregg: When we put in initial placeholder text we also put in questions and concerns / challenges - should be added

<laura> +1 to Gregg

Gregg: we do that to get extra input

<jeanne> -1 to Gregg -- Placeholder is earlier than concerns

Rachael: We have it in exploratory , easy to add

AC: There is not enough in a placeholder to have concerns...

Gregg: If there are any, that should be an option - such as how do we measure: anything should be in plain text

Rachael: Placeholders is just an indicator that we will work on something
... we could put in a link to an issue
... feels heavy for what's meant to be a quick thing

<Jennie> +1 to linking to definition

<Rachael> +1 to adding an acronym table

Ben: Would it be worth explaining what PR is - not anyone knows that - is it in acronym list?

AC: good point - we will deal with that

JF: 2 related off-center comments.
... now in the draft exploratory / placeholder - does not show the status right now - can we always sho the status regardless whether content is hidden or revealed

Rachael: We are working towards a new draft but we can take it on board

JF: Would make reading it easier

<Wilco_> Not a bug, we'd have to show the headings of exploratory content, which I thought we didn't want.

AC: Is the compromise position is that we can add concerns to placeholder but they would have to be very high level?

Gregg: If people have questions/comments having those to come though may gum up work - but everything going right in is all not a good option

<Zakim> Rachael, you wanted to answer

Gregg: so questions should be able to be submitted and editors can evaluate it to go into the draft as a question - avoiding inflammatory comments, for example

Rachael: We could add something like that to the decision tree
... in the exploratory phase we should capture everything with theminimul amount of friction

<Rachael> +1 to that

Gregg: We don't want to bring the same things up in every meeting - that's why it should go through the editors

Editors Note process

AC: decision tree I new
... reading out survey comments Mike about tagging...
... Bruce asking for some adjustments to asynchronous concept

<Chuck> +1 to reviewing and circulating

Rachael: we can draft something and put it out, recirculate, let people comment

Removing guideline details and support materials

AC: 3 approe, 1 with adjustment -
... (going through comments (please refer to survey results)

<Rachael> +1 to either

<Chuck> +1

JF: wants o add placeholder, now it only says exploratory?

AC: Any other comments?
... overall general agreements, adjustments will be made, will be recirculated

Rachael: Should we have a resolution on that?

<alastairc> draft RESOLUTION: Approve, as amended today, the Maturity table, the editor's note process, and removing guideline details and support materials

<bruce_bailey> +1

<jeanne> +1

<Rachael> +1

<Ben_Tillyer> +1

<Chuck> +1

<Lauriat> +1

<Makoto> +1

<JakeAbma> +1

<GreggVan> +1

<kirkwood> +1

<Jennie> +1

<alastairc> +!

<alastairc> +1

<ToddL> +1

ESOLUTION: Approve, as amended today, the Maturity table, the editor's note process, and removing guideline details and support materials+1

<Nicaise> +1

<ShawnT> +1

RESOLUTION: Approve, as amended today, the Maturity table, the editor's note process, and removing guideline details and support materials

<JF> +1

<laura> +1

ACT Rules survey https://www.w3.org/2002/09/wbs/35422/all-act-agwg-may-2022/

ACT Test Tools & Methodology Matrix

AC: (checking survey results)

first 5 approve, 3 with adjustments

AC: (reading Shawn's comments)

Wilco: Working with Shawn separately to work through the issues

AC: (Mike Gower's comment about focus handling(?))

MikeG: When in that interface, hitting an example, difficult to get back to get to prior point of regard; should open in a new window which can the just be closed

Wilco: If you open it in a new window that would do it, but do not mind changing it

MikeG: it is a problem now

Wilco: Link to tools like trusted tester are still missing
... we should be able to do that

AC (reding mariJo's comment)

Wilco: :can be addressed

AC: will put Shawn's comment to one side - the others won't be blockers - can we leave that with wilco?

<alastairc> draft RESOLUTION: Approve the ACT Test Tools & Methodology Matrix, with some changes to be applied (links and focus-handling)

<Chuck> +1

<mbgower> +1

<JF> +1

<bruce_bailey> +1

<Wilco_> +1

<kirkwood> +1

<alastairc> +1

<Francis_Storr> +1

<ShawnT> +1

+1

<Zakim> Wilco_, you wanted to answer comments

Montalvo: can we add editorial?

<alastairc> draft RESOLUTION: Approve the ACT Test Tools & Methodology Matrix, with some editorial changes to be applied (links and focus-handling)

Someone should tale over scribing please

<Chuck> +1

<bruce_bailey> +1

<dmontalvo> +1

<Wilco_> +1

<dmontalvo> scribe: dmontalvo

WCAG 2.2 Focus appearance https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/

RESOLUTION: Approve the ACT Test Tools & Methodology Matrix, with some editorial changes to be applied (links and focus-handling)

Separate WCAG Rules from Other ACT Rules

Alastair: Redesign of the ACT rules + separation of WCAG 2 rules from other rules
... The request is that the existing heading needs to change to "ACT Rules" and there will be different tables for the different rules
... Shawn's comments are in the PR

[Going through survey comments]

Michael: It seemed like they were dividing them into different categories, but I am ont sure that they are exclusive

<alastairc> https://deploy-preview-103--wai-wcag-act-rules.netlify.app/standards-guidelines/act/rules/

Wilco: We will have rules that a re both for ARIA and WCAG, we do need at how to organize the rules from the rules pages
... I would like that discussion to be outside of what we are discussing today

Alastair: As long as we are ont missing rules, I don't think it's a blocker

Bruce: Hierarchy is a bit weird. ARIA is not the same as WCAG. Making ACT Rules the parent title is also not quite accurate. It's ont a whole set of conformance, it's algorythms if you will

John: The ARIA set ois closer to a linter rather than evaluating a condition, right?

<bruce_bailey> i also used "validator" as kind of concept for what ACT Rules are

Wilco: There might be other W3C specs for which we may write rules, including Personalization
... The principle that everything is under WCAG umbrela I don't think works well here
... We do want to capture these differences and point out to them

<bruce_bailey> agree that concept is "things that organizations test"

<Zakim> Wilco_, you wanted to respond

John: I get it, but are there differences as to the type of tests performed? Are you looking at a complete authoring pattern? Code versus editorial decissions?

Wilco: Yes, that is the kind of thing ARIA requires, it is currently more a validation thing. Are you using the correct roles, attributes, and values?

<Zakim> mbgower, you wanted to say I get the challenge just question preamble language

<JF> +1 to Mike

Michael: HTML gives you an implicit role that you can override explicitly with ARIA. That is not a proble but if someone inadvertently overrides that, it can be an accessibility issue, not necessarily a WCAG failure

<mbgower> "These ACT Rules are not required for conformance to WCAG. They are part of various other accessibility standards and best practices, such as WAI-ARIA and Techniques for WCAG 2 ."

Michael: the bit that these rules are not required for conformance could be phrased better

Wilco: Could you suggest an alternative text?

Alastair: My suggestion wouldd be that we approve the majority of this but that we can come back to the preamble

MJ: Should deprecated rules be put at the bottom?

Wilco: Yes, that is in my TODO list

<alastairc> draft RESOLUTION: Separate WCAG Rules from Other ACT Rules, we will come back to the pre-amble / text explanation.

<mbgower> +1

<bruce_bailey> +1

<Ben_Tillyer> +1

<Wilco_> +1

<ShawnT> +1

<laura> +1

<JakeAbma> +1

<Francis_Storr> +1

<Detlev> +1

<JF> +.5

<ToddL> +1

<JF> +1 to Daniel

<Chuck> +1

RESOLUTION: Separate WCAG Rules from Other ACT Rules, we will come back to the pre-amble / text explanations.

Daniel: +1

<alastairc> Update ACT Rules Common Input Aspects

Alastair reads survey comments

<Wilco_> https://www.w3.org/TR/act-rules-format/#input-aspects

Wilco: This term comes from the ACT Rules format
... Gladly put this on the list for 1.1 to consider a different work for this
... Happy to open an issue for this
... We have no rules related to haptic

John: I was thinking of sensory information. WE don't have anything related to physical
... Thinking of a VR AI context
... I think we should have rules for every output mode possible

Wilco: Sure, we can update this frequently, so as we have rules we can add the relevant aspects

<alastairc> draft RESOLUTION: Update ACT Rules Common Input Aspects

<Chuck> +1

<bruce_bailey> +1

<alastairc> +1

<Wilco_> https://github.com/w3c/wcag-act/

<Ben_Tillyer> +1

Wilco: It's probably better for Michael to open that issue

RESOLUTION: Update ACT Rules Common Input Aspects

+1

WCAG 2.2 Focus appearance https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/

Re-structure of bullets

Alastair: Restructure of bullets -- structure updates. We are aiming for the same requirements, it was just restructured to follow the same principle as the AAA version
... We had a couple suggestions in the comments

<bruce_bailey> Link to rendered version from survey is: https://raw.githack.com/w3c/wcag/focus-appearance-structure/understanding/22/focus-appearance.html

[Alastair reads survey comments]

<bruce_bailey> i understand lack of appeal to reconsider AAA version of this SC

Alastair: Some changes to be included

<mbgower> +1

<Ben_Tillyer> 0

<alastairc> Poll: Change "Except when" to "Exceptions"

<mbgower> +1

<bruce_bailey> +1

<alastairc> 0

<JakeAbma> +1

<Chuck> 0

<laura> 0

<JF> 0

<kirkwood> +1

<MelanieP> +1

<ShawnT> +1

<Detlev> +1

<ToddL> 0

<SuzanneTaylor> +1

<GreggVan> +1

Michael: The way it is currently written is like a continuation of a sentence and that is not the case. That's the reason for the change.

RESOLUTION: Change "Except when" to "Exceptions"

<Zakim> bruce_bailey, you wanted to reply

Michael: "It is an option for these requirements to be applied" Phrased that way, it poses more questions

Bruce: I am OK with this as-is, but I think it is the only SC where we are vague as to something being an option
... It leaves it open for an auditor who may not be correct to challenge the author's deliberate choice

<bruce_bailey> from survey: these requirements *can* be applied to the sub-component instead

Wilco: I am a bit lost as to what the proposal is

<alastairc> Where a user interface component has active sub-components, if a sub-component receives a focus indicator, these requirements can be applied to the sub-component instead.

<bruce_bailey> it is an option for these requirements to be applied to the sub-component instead

<alastairc> Poll Change "these requirements *can* be applied" to "it is an option for these requirements"

<mbgower> 0

<Wilco_> -1

<kirkwood> +1 to change

<SuzanneTaylor> +.5

<ShawnT> 0

<MelanieP> 0

<JF> -1

<mbgower> I prefer current, so I guess a soft -1

<Ben_Tillyer> -1

<bruce_bailey> +1 to change

<alastairc> +.5

<Raf> 0

<ToddL> 0

<Detlev> 0

<laura> 0

<JakeAbma> 0

<Detlev> there are more minuses

<bruce_bailey> i prefer "may" to "can"

John: Why don't we say "they may" instead of "it is an option"?

<mbgower> That works for me

Alastair: I think we did have "may" at some stage

<Zakim> GreggVan, you wanted to say that isnt what may means

<Chuck> 4 positives, 3 negatives, everyone else is '0'

<Wilco_> +1 to Gregg

<bruce_bailey> i think we discussed and decided *should* was not what we meant

Chuck: This is not the same as RFC

<Zakim> bruce_bailey, you wanted to say it already new and unique

Alastair: This would be a new way of doing things in our normative language.. Probably a bit late for 2.2, I don't think that is a useful option

Bruce: The use of the word "can" in this context is new and unique in this draft

<mbgower> I agree with that, looking at the wording of the SCs

Bruce: Other uses of "can" and "cannot" are like "it is allowed/permitted"

<kirkwood> +1 to Bruce

Bruce: This is more like "may". We have never used "may" like this before, this is why I am raising that question

Alastair: My concern with "may" is that you wouldd be bringing connotations of the RFC language, the way it is phrased at the moment does not raise those questions

<alastairc> https://raw.githack.com/w3c/wcag/focus-appearance-structure/understanding/22/focus-appearance.html

Greg: Can somebody point me to the exact sentence

<alastairc> "Where a user interface component has active sub-components, if a sub-component receives a focus indicator, these requirements can be applied to the sub-component instead."

<alastairc> current text ^

Bruce: We can try to make declarative statements and this is why previously uses of "can" and "cannot" are different
... I am trying to make this a declaration

<Zakim> mbgower, you wanted to say may is used

<Zakim> bruce_bailey, you wanted to say i have same concern for trigger word

<janina> https://tools.ietf.org/html/rfc2119

Michael: Can anybody supply a definition of "may" in RFC language?

<bruce_bailey> i agree that "may" in notes is fine

Michael: We use "may" in our language but it is only in notes

<JF> RFC 2119 langauge here: https://datatracker.ietf.org/doc/html/rfc2119

Michael: I think Bruce has a point

Alastair: Sounds like the potential change is from "can" to "may"

Greg: We are saying that you can do it if you want, right?

<Peter_Bossley> The only other option here is to construct an or statement as is done in other SCs. I like may better than can.

Alastair: For a custom dropdown, we would require the select to have a focus indicator, we wouldn't be applying that to the options inside

Greg: Is that a normative change?

<mbgower> right, so +1 to "may"

Greg: The way it is written is not what you just said. The ways it's written says it could be applied to the component, the sub component, or to both
... You could apply that to the bottom but you are still required to apply it to the top

Alastair: There are instances like grids where it is useful to have it in both but we don't want to require that
... Is it a +1 for "may"?

<GreggVan> yes +1

Greg: Yes, "may" would be a better word for "can", which is not defined

Michael: I agree

<alastairc> Poll: Change "can" to "may"

<mbgower> +1

<bruce_bailey> +1

<Chuck> +1

<JakeAbma> `+1

<Rachael> +1

<SuzanneTaylor> +1

<janina> +1 if you mean MAY

<Wilco_> -1

<jon_avila> +1

<ShawnT> +1

<laura> +1

<Ben_Tillyer> 0 I've become lost somewhere along the lines

<MelanieP> +1

Janina: If we are using RFC language we should indicate with caps

<Peter_Bossley> +1 for may

Greg: I don't think we used that in other parts of the spec

<JF> +1

<ToddL> +1

<kirkwood> +1

Wilco: We have used this olanguage in the conformance section, I am concerned about mixing styless and creating confusion. Why not use the word "could", "alternatively" or other ways to phrase it?

Greg: "May" is the correct term for what we are trying to do here. If we start putting differernt words it is not going to be clear what it means

<Zakim> mbgower, you wanted to say "may" is used a LOT in the definitions

Michael: The very word "may" is better than the word "can". It is all over the place in WCAG notes and definitions

<JF> https://www.w3.org/TR/WCAG21/#informative-references

John: At the bottom of WCAG 2.1 we reference RFC as one of the informative references. I don't know why the distinction was made

<bruce_bailey> in context we *mean* may -- so i am not clear why we would avoid the word

John: I am happy with using the term

<mbgower> right

Wilco: The way I read "may" is an optional thing. We are talking heree about an exception, that's why I think it's confusing

<Zakim> GreggVan, you wanted to say can is an ability word. may is a permission word

<bruce_bailey> @wilco -- i think it is confusing to avoid use of *may* when that is what we mean

Greg: "Can" is an ability word, "may" is a permission word
... "You must do this" versus "you may do this". "May" is used as an alternative, "must" is an absolute requirement
... I think the "may" is legal, appropriate, and understandable

<alastairc> draft RESOLUTION: Change "can" to "may" in the last sentence

Michael: it is more guidance on how a requirement can be applied. It is not under the exceptions, it is below the exceptions

Chuck: My understanding is that Wilco is opposed but would agree if the majority supports the change

<Chuck> +1

<kirkwood> +1

<mbgower> +1

<GreggVan> +1

<janina> +1

<alastairc> +1

<Wilco_> -1

<bruce_bailey> +1

<ToddL> +1

<JakeAbma> +1

<Peter_Bossley> +1

<Rachael> +1

<Ben_Tillyer> -1 Is it possible to take this away for a chance to wordsmith before a final poll?

<Raf> 1+

<laura> +1

<JF> +1

<ShawnT> +1

<ahackett_> +1

<SuzanneTaylor> +1

RESOLUTION: Change "can" to "may" in the last sentence

<alastairc> "Where a user interface component has active sub-components, if a sub-component receives a focus indicator, these requirements may be applied to the sub-component instead or both."

<GreggVan> as well as or instead

<alastairc> "Where a user interface component has active sub-components, if a sub-component receives a focus indicator, these requirements may be applied to the sub-component as well as, or instead."

Michael: Someone could achieve a completely clear focus indicator on the component and they can some detail in the sub component, but if we say "both" we give people chance to fail because it may not be as clear in both

<SuzanneTaylor> -1 to "both"

Ben: Are we saying that you could change the focus indicator on the parent component (custom dropdown), and when a subcomponent changes that would be sufficient to meet this?

<Zakim> mbgower, you wanted to respond

Ben: You then would have no visual indication that the sub component is changing

<alastairc> We have a whole section on this topic: https://raw.githack.com/w3c/wcag/focus-appearance-structure/understanding/22/focus-appearance.html#keyboard-focus

Michael: When it lands there and it is not open, you ahve to have sufficient focus indicator. When it opens and you are dealing with the options, focus indicator is ont needed there. As you arrow up and down as long as your selection state is 3:1, the user has a sufficient indication as to where they are working
... You can meet with select, with focus, the thing is there are alternative ways in which you can give users indication of where they are

<alastairc> draft RESOLUTION: Accept the structure update to focus appearance demonstrated in https://raw.githack.com/w3c/wcag/focus-appearance-structure/understanding/22/focus-appearance.html

<Ben_Tillyer> +1

<Chuck> +1

<mbgower> +1

<ToddL> +1

<alastairc> +1

<GreggVan> +1

<JF> +1 to "structure"

<ahackett_> +1

<Wilco_> -0.5

<laura> +1

<bruce_bailey> +1

<ShawnT> +1

RESOLUTION: Accept the structure update to focus appearance demonstrated in https://raw.githack.com/w3c/wcag/focus-appearance-structure/understanding/22/focus-appearance.html

<SuzanneTaylor> +1

<Zakim> mbgower, you wanted to say that moving the "where" statement up may be better use of time

Michael: Now that we have the exceptions column we could move the last paragraph above the exceptions

<jon_avila> +0 as I still think it's unclear that sub focused items need keyboard focus

<alastairc> Poll: Move the last paragraph to above the exceptions.

<bruce_bailey> +1 for anything makes it clear that "may" option is not part of exceptions

<mbgower> +1

<bruce_bailey> +1

<Ben_Tillyer> +1

<Rachael> 0

<JakeAbma> +1

<ToddL> 0

<Wilco_> 0

<laura> +1

<ahackett_> +1

RESOLUTION: Move the last paragraph to above the exceptions.

<Chuck> +1

<alastairc> "Where a user interface component has active sub-components, if a sub-component receives a focus indicator, these requirements can be applied to the sub-component instead."

<mbgower> may, not can

<alastairc> "Where a user interface component has active sub-components, if a sub-component receives a focus indicator, these requirements may be applied to the sub-component instead."

<bruce_bailey> +1 looks good

<mbgower> +1

<SuzanneTaylor> +1 as is

Alastair: What we mean is that focus indicators "may" be applied ot the sub components. Does anyone have a problem withhat?

<ToddL> +1

<alastairc> rssagent, make minutes

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/auswered/answered/
Succeeded: s/editors' daft/editors' draft/
Succeeded: s/Hierarchy is a bit weeird./Hierarchy is a bit weird./
Succeeded: s/Phrased that way,/"It is an option for these requirements to be applied" Phrased that way,/
Default Present: alastairc, Lauriat, JakeAbma, Detlev, Ben_Tillyer, Jennie, Makoto, bruce_bailey, ShawnT, ToddL, Daniel, Rachael, SuzanneTaylor, myasonik, mbgower, Peter_Bossley, Jen_G, jeanne, shadi, Laura_Carlson, Nicaise, sarahhorton, MelanieP, kirkwood, JF, Chuck, Wilco_, GreggVan, Francis_Storr, !, .5, jon_avila, janina
Present: alastairc, Lauriat, JakeAbma, Detlev, Ben_Tillyer, Jennie, Makoto, bruce_bailey, ShawnT, ToddL, Daniel, Rachael, SuzanneTaylor, myasonik, mbgower, Peter_Bossley, Jen_G, jeanne, shadi, Laura_Carlson, Nicaise, sarahhorton, MelanieP, kirkwood, JF, Chuck, Wilco_, GreggVan, Francis_Storr, jon_avila, janina
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Found Scribe: dmontalvo
Inferring ScribeNick: dmontalvo
Scribes: Detlev, dmontalvo
ScribeNicks: Detlev, dmontalvo

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