<alastairc> chair: alastairc

<AWK> +AWK

<Chuck> scribe: Chuck

alastairc: scribe review

<JustineP> Yes, I can scribe during the second half if you can walk me through wrap up/posting the minutes.

alastairc: Couple of things to announce and discuss.

Charter update

alastairc: Charter update
... We don't have a new charter yet. It went for AC review, there were some objections. Enough existed such that we had a slight charter extension to respond to those objections.
... We'll cycle through again and carry on. A few technicalities around when things can be published.
... From internal discussions we'd be looking at... we have an extension up to December, but we want things sorted out before that. The objections were around scoping and wanting it to be more explicitly set for web, particularly around silver.
... Discussions are ongoing.
... It may mean that our first public working draft (2.2 and silver) will be later.
... Now looking at early Dec.

mc: We've been approved for extension, hasn't been announced, but will be by end of month. People from AC who commented will receive responses. There will be minor changes that we'll share with wg.
... Don't think the changes will impact the charter.
... Complicated because it's in ac hands.
... We need to end up with something the wg will support. So we've a needle to thread.
... I don't know we'll overcome all objections. We have to figure our way through that.
... We are expecting to be in dialog with ac members for next couple of weeks. Hope to adopt charter late november, we have extension into december if needed.

alastairc: any q or comments?

dm: Can we find out about the concerns?

alastairc: Silver should have a name, more substantial one from larger organizations was on terminology used for silver.

mc: Mostlly around silver scope. Concerns about overlapping... how explicitly should we be restricted to web. There's so much blurring between web and non-web. Other comments about timeline for Silver and wcag 2.2 that need to be addressed.
... Silver name ... looks to me like we need to adopt the Silver name when we close out the charter.
... Several commenters don't want a placeholder name in the charter.

alastairc: Seems minor, but name should reflect the scope.

dm: That's a big one.

alastairc: Any other q?

ACT rules review update

alastairc: Handing over to Mary Jo or Wilco. We have approved and published the ACT spec, there's a wish/need to publish at least one rule.
... fairly soon.
... A rule will come around shortly.

mj: The ACT task force is about to publish the rules format spec as a recommendation. We want to have a rule to go with it as an example.
... We reviewed a rule that's html page has a title, is going to be the first rule to go through the process.
... as part of wcag materials. Will be a larger repository.
... We sent the first rule off to the chairs, they had some q.

<AWK> https://act-rules.github.io/rules/2779a5

alastairc: An example, we have some comments on it. We can show people the format.

Wilco: That's a link to the ACT rule on the website, there's some stuff around that. The main content is about what's in the page.
... We have this first rule as a trial for the process.
... AC task force reviewed the rule, it has several approvals from the community group, has several implementations for this rule.
... Implementation means that when they run the tests they get the same results.
... Has been reviewed by the task force. Our q for the task force and ag's is what we want the process to look like.
... Do we want to go into questions, or should we review process?

alastairc: Let's do an overview of the process. We had a look at that a while back in a github thread. has that changed?

Wilco: The process hasn't changed. The intent is for the task force to handle most of the work, do most of the reviewing. AG can rubber stamp it. That's our hope.
... AG probably wants to review the rules. To what extent? Should this be a survey? Should be on agenda and review separately? CFC?

alastairc: A pull request for this one exists. That would seem like a reasonable first pass to me.
... It would be worth having something in some sort of process around approval.

<alastairc> Example for the pull request: https://github.com/w3c/wcag-act-rules/pull/12

AWK: The q that I have is about ... these rules are non-normative? <yes> What sort of expectation should we have related to the stability to the rules over time? Example:
... The part that came up in here is where it talks about iframes. There is for example in one of the evaluation tools out there it will flag an error if there is not a title attribute on the iframe.
... This seems to be saying that this is not the case, or that there are other ways around that. When we have a review of a rule that we reconsider later on because of a comment, what expectation of "sorry, already implemented by vendors, we really can't change it"?
... Do you expect there will be? A casual review... we'll agree it's important. We want it to be right, or we'll be arguing with product teams and customers. We want to be able to fix things if our review is too casual. How locked in will we be?

Wilco: Iframe titles, this rule is specifically about 2.4.2 page titles. The examples are specifically for this sc. Doesn't mean that everything else meets WCAG (no doc type, etc). Not necessarily saying that these examples are also completely passing other sc.
... There's no title on the iframes because not required for 2.4.2 (though may be required by something else)
... For stability, what we are looking for is a process by which the primary author is the organization or the team that submitted the rules. If changes are necessary, we send the proposal for changes back to the maintainer for that rule (in this case ACT, but could be someone else)
... They have a say. There's a level of indirection. AG can say that there's something wrong with the rule, and we may want to pull or deprecate.
... AG and ACT task force aren't directly editing the rule, that's owned by the submitter.

alastairc: Assuming they continue to do so.

Wilco: Stuff is defined for if they are not maintaining or not responsive. We have a way to move that on. We also could deprecate the rule (last resort).
... It's not forgotten, as these things do need to be updated.

<Zakim> AWK, you wanted to ask about rule stability

AWK: I know for example that some of our techniques are non-normative the wg has had reluctance... we've identified it's wrong or doesn't cover what we thought, the wg said we can't get rid of it until we can replace it. And we don't have that in all cases.

Wilco: It could ultimately get pulled.
... We'd like to fix it. Step 1 is fixing it. If it doesn't happen and nobody wants to, it should be pulled.

AWK: Great.

Wilco: We don't really have enough to pull at the moment.
... For this first one, do we want to walk through the feedback? Do we want to put it on a survey?

AWK: We should put it on a survey.
... We had q, hoping we can have a survey ready for the wg.

Wilco: Will review questions today.

AWK: We are trying to send out surveys earlier.

Wilco: The wcag 2.0 link needs to be fixed. The rest we can explain.

<someone> How long will the survey be out there?

AWK: Hopefully by next week.

alastairc: As long as it's focused on "this is the first rule, are we happy with the first rule in context of the process"... as long as we scope it it can be swift.

Wilco: The rule has been thoroughly reviewed.

mj: Been signed off by 3 in the comunity group and then other reviews.

alastairc: Any of the q or comments from people about the rule? Otherwise we'll see it shortly.
... No additional q.

WCAG 2.2 Criteria review – Focus Visible (Enhanced) (2nd week) https://www.w3.org/2002/09/wbs/35422/focus-vis-enh-acceptance/results

alastairc: We have 3 wcag 2.2 sc up this week.
... hoping that either we can look at focus visible enhanced and talk through the updates, and decide it's ok for editors draft, or talk it through and discuss issues and put it back, but either way I'd like to get on to the other 2 today.
... As a heads up, I'll try and keep this one short.

<alastairc> https://www.w3.org/2002/09/wbs/35422/focus-vis-enh-acceptance/results

alastairc: The results questionaire is in link above.
... Google doc link as well...

<alastairc> https://docs.google.com/document/d/1g9_WBgfhViWAaRFIWWt10CP5rBsEVIWm3vT1vWqrHvI/edit

alastairc: Dealing ... I addressed the survey comments from last time. The things that changed from last time, detlev had a comment saying that the surface area requirement didn't seem to be enough.
... I experimented, tried 2 different methods. One was doubling the surface area requirement. In the first bullet it says time 2 pixels.
... That's the surface area minimum. There was also an adjustment of the wording of the last bullet point. 3:1 contrast ratio for entire surface area or has .... <pasted above>

<Fazio> The thicker the better in my opinion

alastairc: Should we make the contrast higher, surface area higher. I had a conversation with Andy Sommers (on low vision task force). Spacial frequency... conclusion was that increasing more surface area would be better than contrast.
... The other change to the sc text is an addition of a note. For a non rectulangular shape, draw the samlest around...
... around a bounding box. I found the terminology difficult. Possibly because I have previous associations.
... Didn't seem to explain it well enough. I hope the note addresses the idea.
... Also Jake's not here, I put in some examples of complicated shapes. A circle, how you calculate that, a style with a drop shadow. I think Jake was happy.

<Zakim> AWK, you wanted to speak to circumscribed rectangles/ bounding boxes

<Fazio> Is complicated shape official terminology?

awk: I added the comment to the google doc. It's nice if we can not do things in notes that specify important details that's specified in the sc, the note is not normative. We are trying to resolve "star shape" "star burst shape", lots of small lines.
... What constitutes a side. Basically having a containing rectangle around the control. It's the smallest possible rectangle around the shape and we use the longest edge. I mentioned that. In the draft sc text it says <reads>...
... We aren't definining what it means for non rectangular shapes. When I put in "circumscribed rectangle", that came up in talking about controls. I'm not bound to the bounding box terminology. Conceptually we are trying to put this thing in the smallest rectangle we can.
... Then we talk about the height and width of it. I prefer it be in normative text.

<Fazio> It shouldn’t smother the contents it contains eithervthough

<Fazio> That will make for visual perception difficulties

alastairc: My q is then, you might get different results. A bounding box in interactive systems will always be kind of horizontal, you would get a different result if you drew a box around a slant shape.

awk: If the item that you have is a line that is tilted on an angle, it would have a bounding box that is much larger than if it is verticale.

alastairc: Or if it's diagonal.

awk: I think of ... We see this in illustrator. The bonding box for it is going to have a vertical height and a horizontal width because it is a rectangle or square. It's not scewed.
... Not sure ... have to think if there's a way to reference that.

<Zakim> KimD, you wanted to ask about "longest side"

alastairc: I would also mention that 90ish% of controls I see are boxes. I'm not bothered either way. If we went with bonding box, horizontal and vertical, it would increase for odd shaped controls, and that may not be a bad thing.

kim: When we are talking about minimum area, if you use an underline, that's the first dash, that's an acceptable way to show focus, it doesn't have to be a box?

alastairc: Doesn't have to be a box. We suggested a surface area so it can be anything.

<AWK> https://www.mathopenref.com/coordbounds.html

kim: I have an issue that it says it has to be on the longest side. If you think of things that are stacked, it is clearer to show it on a short edge (along the left in most systems), then it's a unique line. If it's in between emails we don't know if its above or below.

alastairc: The longest edge is to define a proportional surface area. The only reason it mentions the longest edge is such that it's proportional to the size of the control.
... There is no limit on how you show the focus indicator as long as it meets the minimum surface area.

kim: Then the wording is confusing. It doesn't seem to really say that right in the language.

<Fazio> It’s definitely “wordy”

alastairc: Surface area is kind of the key thing.

<Fazio> Hard to understand

kim: We want to make sure there is an outline you can see, or one edge. It seems like this is...

alastairc: It's trying to be more flexible than that. You can reverse the color scheme, that's fine. Large surface area that's changing.

<alastairc> https://alastairc.uk/tests/wcag22-examples/focus-more-visible-2.html

alastairc: If you scroll down to example 15, it could be a line on one edge, a double thickness on the bottom, could be anything. Trying to say it needs a certain surface area for focus indication.
... I experimented with perimeter. I tried 1 pixel x perimeter. There would be some that are problematic.

awk: Some of the examples may appear in your link. Circular example is not just about having a focus on the under side or edge. In some cases it is around shadowed areas, thickened edge. That's part of the complexity we have with this language.

alastairc: Looking through some design guides, there are circular shapes in current usage.

<alastairc> Examples from the wild: https://alastairc.uk/tests/wcag22-examples/focus-visible-enh-examples.html

<AWK> https://docs.microsoft.com/en-us/dotnet/api/system.windows.automation.automationelement.boundingrectangleproperty?view=netframework-4.8

dm: I think it's ingenious to use the relative bottom edge. We could do something with the language, we just want you to measure the bottom edge, if you multiply it by 2 pixels, we don't care where you put it.

<alastairc> (NB: That was using the longest edge times px for pass/fail

alastairc: There are easier ways to say it.

<Zakim> AWK, you wanted to talk about UIAutomation

awk: u/i automation for windows has a bounding rectangle propertly. Not a box, it's a bounding rectangle. It's a defined property within u/i automation which is used for accessibility testing.
... Might be worth trying to find out if that's replicated elsewhere.

alastairc: That would be a few extra words in the top bullet point.
... That's getting quite wordy.

<AWK> https://chromium.googlesource.com/chromium/src.git/+/master/docs/accessibility/overview.md

alastairc: But I get what you mean.
... Any other questions or comments on this?

justinep: q for those in the groups for the tests that refer to the color contrast 3:1 and how that's different from 1.4.11 and non-text contrast.

alastairc: They are different requirements. In the understanding doc there's a section on that. Relation to non-text color contrast. Works for controls in their default state and in different states to ensure controls have contrast. Doesn't work very well for focus indicator.
... We thought we could cover in non-text contrast, but the sc is about the change of contrast from one state to another, not whether .... secondary to change of contrast the focus indicator has.
... The answer is to have a different scope. One is for controls in their default state, the other is for focus state.

justinep: Thanks for clarifying.

alastairc: If people are in the survey and one of the q is on the understanding text. If you have q, you can ask your q in the survey and we can improve the understanding doc.

<AWK> https://developer.apple.com/documentation/uikit/nslayoutmanager/1403255-boundingrect

alastairc: Is there a simple update we can make to the first bullet point, around bounding box idea? Otherwise it will go on back burner.

awk: Based on finding links in documentation from google, microsoft and apple that talk about a bounding rectangle, I'm increasingly comfortable saying the focus indicator is >= the longest edge of the bounding rectangle of the focus control in css pixels x (1 or 2)

alastairc: For the purpose of editors draft, it would be better to start with 2, and reduce that if needed. Having done some testing on dashed lines, anti-aliasing, that reduces contrast as well. If we went with full perimeter, that may cause issues.

awk: I'm fine saying that as well. I think we should make... I don't think what we have yet in terms of determining some of these (1 or 2 css pixel), we should be seeking out additional confirmation of our instincts.

alastairc: We need to update the note. Or do we need the note? If we solve in understanding text.

awk: Fine in understanding.

alastairc: Small amendment, removed the 2nd note. Any objections going into editors draft for wcag 2.2?

awk: We've just talked about the draft sc text. Are all the issues for understanding doc addressed?

alastairc: I think so. G195 is a good technique for this. I've proposed a little update for the procedure for G195.
... We also have c40 that david did.
... I added another new technique, which is a variation.

awk: One the things also here is the one comment... by moving this into editors draft we are also saying we are changing 2.4.7 to single A.

alastairc: Yes, we did have a long meeting about that process. We focused entirely on this question, on what we should do with the current one.

awk: I don't remember our conclusion.

alastairc: We did come to a conclusion.
... I'll dig it up and included it somewhere.
... Any objections to adding this to the editors draft?

dm: Congrats on hard work.

<laura> +1 to include it.

RESOLUTION: Resolved to include in the WCAG 2.2 editors draft.

alastairc: will take a bit of time to process.

rachael: I'll be on computer in 3 minutes.

WCAG 2.2 Criteria review – Essential controls. (2nd week) https://www.w3.org/2002/09/wbs/35422/essential-controls/results

alastairc: this was one we discussed before. I don't think we had a huge response on survey.
... A couple more comments.

<alastairc> https://www.w3.org/2002/09/wbs/35422/essential-controls/results

<alastairc> https://docs.google.com/document/d/1DPtCqWHjrhj3QZ4afsqzmWDd-zMSf39RsMqSpR2QGCg/edit#heading=h.d52u50axuctf

<JustineP> scribe: JustineP

Alastairc: Going through examples made it difficult to work out what was in/out of scope.
... since then tentative new wording prepared
... could mark as dependent on personalization spec

Rachael: Would like to clarify that the importance of the control would be programmatically determined.

<Rachael> Alternate wording: The importance of main navigation, controls that progress or complete a process, and safety-related information can be programmatically determined.

Alastairc: Need someone to tackle examples that we've been gathering

Rachael: will be more achievable in Silver frame, in 2.2 would prefer to focus on "programmatically determinable"

AWK: Why is the first part easier under Silver?

Rachael: because Silver has the concept of a task-based model. Silver looks at things from task-based process or from a different perspective than WCAG 2.2
... sense is that it would fit better within Silver paradigm

AWK: The first part seems clear enough. The big question I have is not what you need to do but is it a reasonable thing to ask of web apps?
... in this case with the existing SC, you can do this so that "Next" button floats in righthand margin in line with current focused item or you can programmatically set importance of control
... when I reviewed I felt like it meets requirements but other feedback is expected about feasibility

AlastairC: in an e-commerce listing with items that each have a "buy now" button that initiate a process, 14 buttons could appear on one page
... in some cases "Next" button will be at the bottom of the screen but its obvious what the button is/does. Within that context, topic search can provide a list of 10 things that are a next step...quite a few scenarios in which more than one control would be available to progress a process
... container might be important rather than individual controls

AWK: My interpretation is that for "buy now" button--it is visible at the time that you need it
... if Next button is off-screen when you need it, that would be a problem

<Fazio> Is there a persistent conformance requirement that the same method is used throughout a site?

AWK: doesn't mean that all actions from a page need to be visible at every moment. Controls you need are available at the time you need them.
... are we defining what a process is in a way that supports this?

<AWK> process: series of user actions where each action is required in order to complete an activity

<alastairc> Fazio - in general things are page by page, but we do have the concept of a process.

AWK: this is where implementation challenges exist. I think this needs to be scoped clearly

Alastairc: If tester of site is defining task, it becomes more straightforward

<alastairc> Fazio - and sets of pages in https://www.w3.org/TR/WCAG21/#multiple-ways

Rachael: We could look at examples which contains an example of a failure

<Rachael> https://docs.google.com/document/d/1lUh2ZsQXRlC_S2gtJE5mMSIHEwB1K2gBBc0VL3hL4Yk/edit#

Rachael: we could take out process and focus on progressing

Alastairc: still at a stage where we are struggling with defining "progressing". Does anyone else want to progress with it? Can pause this for a couple of weeks if someone wants to work on it.

David-macdonald: you could progress with an "at risk" on the first bullet

Alastair: Second bullet is at risk dependent on personalization spec

AWK: Second bullet faces same problem. I wonder what happens when you mark something as important.

<Jennie> +1

AWK: if I have a search result, am I going to have 10-100 things all marked as important? What if someone marks everything on a page as important to cover themselves?

AlastairC: can have a user plug-in that blanks out everything that's not important. Keep a navigation/buttons marked as important and get rid of all else

<AWK> Jennie: responding to ANdrew's point about overuse of importance markup

Jennie: Want to respond to Andrew's point about use of importance markup. Can be equated to people learning about structural importance of heading order?

<AWK> ... may be equated to overuse of headings/H1 for more things than needed

<AWK> ... people's skills would improve over time

Jennie: need to understand impact on end user. People need to understand impact on markup.

Rachael: If we added exception on search results, or exception where multiple actions result in same result, could this be an essential exception?

AlastairC: Possibly. Is it the other way around where we'd want to put a limit on the number of things that can be marked as important?

Rachael: I see as a staged series of actions, in some way progressing from one stage to another it seems that search function is not related
... a little nervous about upper limit

Jennie: Question about test procedure. Wouldn't it already have person doing the testing see that a large number of items have been identified as important?

Rachael: potentially. Not sure how to articulate.

Jennie: To me, that might take care of itself through testing process. I like idea of identifying exceptions to start

no problem AWK!

Jennie: I understand about deferring to Silver.

Rachael: Going back to examples, where is boundary when it is too much? Is there research that we can leverage?

Alastairc: Alternate wording, focusing on programmatically determined, looks to me to be more straightforward. Rachael, if you were charged with moving this forward would that be easier?

Rachael: I can continue to move it forward by providing additional examples and revisit

Alastairc: Is there anyone that wants to try different examples/wording? Not in COGA so a fresh pair of eyes...
... if not, I would propose to put this on hold and email to group for assistance
... if successful, can bring back to the team in a few weeks. If not, bring back programmatic version.

Rachael: Seems reasonable

RESOLUTION: put on hold

WCAG 2.2 Criteria review – Icon Description (1st week, if we get to it) https://www.w3.org/2002/09/wbs/35422/icon-desc-acceptance/results

Alastairc: This is our first review of Icon Description

<alastairc> https://docs.google.com/document/d/1HzSsCGelWfz_Z-M7NyUzJOvl1A1kAStyl8epYdpZhoA/edit#heading=h.oxvoi19ymue6

Alastairc: couple of people have responded, seem fairly happy. My main comment is regarding static wording.

David-macdonald: Comment from Carolyn -- concern about an icon that is actionable. When you tab to icon, need to consider native action of that button.
... tried to address by referring to static icons

Alastairc: seems to count out main use case such as tool bars

David-macdonald: Maybe we should pull out "static" and find a solution
... interested in thoughts on the solution. If a button opens up a calendar, for example, and you tab to it on focus and take action calendar opens

Alastairc: In Google docs, need to use arrows when you get to the toolbar

<alastairc> https://codepen.io/Moiety/pen/LaPvWy

David-macdonald: example provides for hover action. Nervous about hover regarding mobile.

Alastairc: mobile is a gap

David-macdonald: maybe it will be acknowledged that hovering is problematic in mobile

Alastairc: does a mechanism need to be possible on every platform?
... in settings of Safari you can now specify zoom level. If you have a large device you can set screen to 300% and have same sort of effect as on a desktop
... will have horizontal scrolling though

<alastairc> https://www.w3.org/2002/09/wbs/35422/icon-desc-acceptance/results

Alastairc: alternative text or a mechanism is available...

David-macdonald: For DOB with three boxes, sometimes no visible label is present per box

AWK: If you have a trash can icon, and you're clicking to discard, that would not be covered as "static"

David-macdonald: I think Andrew is right, delete "static" and place upper limit on text
... b/c you don't have a choice to ignore if you're a blind user

<Zakim> AWK, you wanted to ask harder question. If this can't be done on mobile and people are expected to be ok with that, it is this really needed on desktop?

AWK: David mentioned what we do related to mobile. My question is if people will be okay with not having it apply to mobile? Will they be happy to access to the UI even if not used on mobile. How do we know this is needed on desktop if people are okay with it not applying to mobile?

David-macdonald: There are a lot of things that are harder to do on mobile. Blind community seems to not get annoyed as quickly with problems on mobile as on desktops where author should/can know what to do.
... more difficult without hover capability on mobile
... may need more tolerance in that area to get needed function through on desktop

<Zakim> alastairc, you wanted to ask if it is a benefit, why shouldn't it be available where it can be available?

Alastairc: I think its needed on mobile too. If there is no resolution does that mean we don't include it?

David-macdonald: WCAG is a practical standard. Need to understand limitations of technology

Alastairc: Sometimes on mobile you need to double tap in place of hover which is not desirable. Does seem that a mobile browser solution is needed.

David-macdonald: users understand that there are not solutions for some things
... basic accessibility missing from mobile. You hear double-speak as you move through on mobile.
... some people are willing to trade off experience for mobile convenience

Alastairc: is a common scenario

David-macdonald: tradeoff is that you drop interactive control or use static for mobile
... could say if you're on mobile with static icon, can activate with enter key

AWK: If you hit enter its no longer static

Jennie: Maybe I missed it. Question -- will text equivalent be magnifiable?

David-macdonald: Can't rely on a title attribute to do this. I filed a bug with Chrome years ago, no response received.

Jennie: Initial SC text talks about aiding people with low vision. In Benefits section. If text equivalent displays in small size font, it may not assist them

David-macdonald: Almost every browser will allow for increase. Title attribute will stay small.

Jennie: phrasing around "custom control" needs to be in understanding doc regarding title attribute function

Alastairc: can we add something to the SC text, a parameter that would scope out custom controls
... consider how this interacts with focus/hover

trouble hearing the conversation around 1.4.4, can you restate?

<alastairc> Conversation about clashing with "On focus or hover" SC

David mac-donald: pull out "static" and create language around user interface control

Alastairc: a few other comments in survey around fleshing out text
... assuming we proceed as 'AA', are there any reservations?
... David can flesh out understanding/techniques

<Jennie> +1

<laura> +1

<bruce_bailey> +1

<AWK> +.95

<Chuck> +1.05

Alastairc: same survey will be up again. David please sent notification when updates have been made.

<Chuck> :-)

Alastairc: work needed but its looking good. I'd rather a wide scope and if pushback look at AAA
... comments/questions please update survey

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

<alastairc> agendaq?

Reminder to review conformance issues for large and dynamic sites and applications

<alastairc> https://docs.google.com/document/d/17ByXEqqXuqWtDzxq2J6Vch27n4RWMZig7P426aPiIto/edit

Alastairc: we had a good discussion on this document last week. Will soon be transferred into Github.
... plenty to review and think about!

Bruce-bailey: do we have a sense of the home for the document? Standalone note?

Alastairc: at the moment thinking of a standalone note

Bruce-bailey: would be better to keep EM alive rather than as a separate note

MichaelC: want to understand scope and will come up with recommendation

AWK: will not replace EM document. Might inform but we have more to discuss.

<bruce_bailey> I have flagged to DHS OAST and GSA

<laura> bye

<alastairc> trackbot end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/alastairc/AWK/
Succeeded: s/thnings/things/
Default Present: AlastairC, Chuck, Fazio, MichaelC, JustineP, AWK, Raf, MarcJohlic, maryjom, Laura, Jennie, johnkirkwood, KimD, Rachael, .95, bruce_bailey
Present: AlastairC Chuck Fazio MichaelC JustineP Raf MarcJohlic maryjom Laura Jennie johnkirkwood KimD Rachael bruce_bailey
Regrets: JakeA Detlev Nicolas
Found Scribe: Chuck
Inferring ScribeNick: Chuck
Found Scribe: JustineP
Inferring ScribeNick: JustineP
Scribes: Chuck, JustineP
ScribeNicks: Chuck, JustineP
Found Date: 22 Oct 2019
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.)