W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

09 Jul 2019

Attendees

Present
alastairc, helixopp, Jennie, Laura, MichaelC, JakeAbma, johnkirk_, MarcJohlic, JF, Glenda, stevelee, Katie_Haritos-Shea, SteveRepsher, mbgower, Rachael, bruce_bailey
Regrets
Detlev, Chuck, Justine, Rafal
Chair
AWK
Scribe
Jennie, Rachael

Contents


<AWK> +AWK

<Jennie> scribe: Jennie

Technique reviews, https://www.w3.org/2002/09/wbs/35422/Techniques-June-2019/

Technique - Content on focus or hover

Andrew: 4 approved as proposed. 2 with changes.

David M: when you put your mouse over it you cannot read what is underneath.

Andrew: this conflicts with one of the other comments: having a paragraph before it.

Alastair: this was Detlev's

Andrew: the point is above but that is not the same for every mouse pointer.

David M: some mouse pointers are larger, and it can be hard to read the text.

David F: +1 to David M's point re pointer size.

David M: I would just position it above, by changing the CSS.

David F: it is especially difficult on Google when looking at images. Makes navigation difficult.

Andrew: Alastair, Detlev is that a manageable change?

Alastair: yes

Andrew: add the Oxford comma after dismissible.
... I am concerns about "Content that is displayed in a popup when a user moves the pointer over a trigger, or moves the keyboard focus to the trigger must stay visible and remain visible when the user moves the pointer over the popup content."

<david-macdonald> @alastair top:-30px should do it.

Andrew: what does this actually mean?
... I suggest "Content that is displayed in a popup when a user moves the pointer over a trigger or moves the keyboard focus to the trigger must remain visible to allow users time to read and interact with the content and must allow the user to move the pointer over the popup content."
... I am confused about the procedure with autoclosing.
... In the examples when you roll off the popup content, one might say it auto closes.
... does this mean it physically times out and closes after a period of time?
... if I hit the escape key, this is different than moving a mouse off of it, but we could be more clear.

Alastair: how about popup stays visible automatically on a timer?

Andrew: Popup content stays visible. Or popup content does not close on a timer.
... do others think that is helpful?

<alastairc> Updated to: The popup content stays visible and does not automatically close after a time.

Katie: +1

<david-macdonald> @alastair role="tooltip" Class top="-70px " will fix it.

Andrew: if there is a menu - do you press it again to close it?

Alastair: yes.

Andrew: by activating it?

Alastair: if you click the trigger to close the popup, which might not be usable, but it is an option.

Andrew: ok.

Alastair: there is a comment about mobile but I am not sure how it would apply.

Andrew: fair enough.
... that resolves all comments in at the time of the survey.
... any objections to accepting this technique as amended?

<david-macdonald2> [role="tooltip"] { position: absolute; left:0; top: -70px; }

Mike G: popups - this is not a term used in the understanding documents.

Mike G: I don't have a large issue with it, but it is not a defined term, and is not in the SC documents.

<AWK> "Additional content that appears and disappears"

Mike G: whatever is used in the standing documents should be used in the techniques.

Alastair: mostly in the additional content.

Mike G: yes

Andrew: you would use the term popup in the understanding document in the examples.

Mike G: popup is used all over, but is not really described.

Katie: +1

Mike G: my other comment: I was surprised by the first paragraph. I will send the information to Alastair.

Andrew: 8 instances of "popup" and some in the examples in code
... Alastair - can you make those changes?

Alastair: yes

Andrew: with the assumption this is happening, any objections to accept this technique pending those changes?

RESOLUTION: accepted as amended pending changes to use of popup.

Technique - Failure of character key shortcuts

Andrew: 4 approve as proposed, 2 with following changes.
... Jake has German translation comments.
... Jake if you don't know there are any shortcuts, you might not fail, right?
... if 5 is false, but 4 is also false, then you wouldn't fail.

Jake: exactly.
... or rethink the procedure. You can also put it as a condition first.
... check if true...if false, do the following procedure.

<JF> +1 to the conditional idea

Andrew: right
... I'm not sure if we have done those. I'm not sure how we would do it, but I like the logical path.
... it would shorten testing if possible.

Jake: it seems strange, but if you are looking for failures, opening all pages, pressing all keys...sounds like a weird thing to do.
... or you just know there are certain characters used.

Andrew: Michael are there any other techniques where we have used a conditional type thing?

Michael: none come to mind

John F: would about multimedia?

Andrew: in most cases, like in the procedure we say "on pages with video"

John F: there is a conditional there, but we put it higher

John F: if no video there, no test to be run.

Andrew: I'm happy to investigate how to do this.

<alastairc> How about starting with: "If the site does not provide settings to disable keyboard shortcuts using single character keys or map them to keyboard shortcuts that use a modifier key."

Andrew: I am hearing make 5 the first thing, and then if 5 is true, then you can escape the rest of the procedure.

<alastairc> (or something like that)

Andrew: Alastair's comment seems another way to do it.
... any issues with making a change that makes that happen?
... ok, let's look at the rest of the comments.
...editorial: do we capitalize failure, like in the note under the description?

<bruce_bailey> IMHO we should avoid ALL CAPS for emphasis, so no to capitalization
...editorial: can we clarify #2? If you acknowledge from the auther that they use the F key as a shortcut, you are not going to press every key.
... you would test the F key, the SHIFT + F key, or if the information is not available...
... what do people think about that?

Andrew: any objections?
... what it says now is press every character, which means hit all of them. But, if you developed the site and only used the q key...

John F: you are making that a new requirement then.

scribe: if the site is using quick keys, that should be communicated to users up front.

Andrew: no, I'm saying if you are testing it you go ask the person and say "use any shortcut keys?" and then if you don't know, you have to go and press all the keys.

John F: I don't see this as a scalable test technique.

John F: what if there are 100 people writing code - who do I go ask?

Andrew: you may not know, which is why the rest of the procedure is there.
... if you know that there is only one key, you shouldn't have to go and test every single key.

John F: how do we actually implement these keyboard shortcuts today?

John F: while we want to test the functionality, perhaps it may be looking at the techniques.

John F: access keys can be done with a tool.

Andrew: I don't think using an access key would be a failure of this.

Mike G: Andrew, what you have introduced is similar to what we did at IBM.

scribe: you go back to the dev team, and if no shortcuts established, then you don't test it, since nobody would go and create single key shortcuts if not in the spec.
... you see what the developers did, and if you don't have any information, you go on through the process.

<Zakim> alastairc, you wanted to ask where that note went about this topic

Andrew: I am trying to make it so it doesn't require onerous testing.

<JakeAbma> if you ask devs, you can also ask if nr. 5 is pesent. Don't have to look for it.

Mike G: is there a way of specify to a listener a way that communicates an upper or lower case character?

Alastair: I believe it is possible.
... I have a memory that we used to have something that says if you can access someone how it was implemented, then you can change the way you test it.

<david-macdonald> JavaScript Keycode d=68 capital d=68

John F: to Alastair's point, that is great if you have access to the owners, the developers, but not all test scenarios are like that.

<AWK> There is no requirement in the test procedure to know what the shortcuts are

scribe: we have done evaluations on stuff that has been purchased, and they want us to test what they purchased.

John F: that feels like a weak step.

<david-macdonald> So there is no distinction in JavaScript between caps keycode and the corresponding small keycode

Alastair: I'm not saying we change the test procedure, but if you have another way to achieve this

Andrew: are you saying it feels like you have to know?
... I'm trying to say press the keys identified by the author, or press all the keys.

John F: ok. I would be concerned that if I spoke to Joe the developer and he says no, he may not be aware of what others did.

<david-macdonald> However, there are ways to distiguish is to detect the shift with 16

David M: he pointed out it is the same as lower and capital D

David M: you can sniff for both.

Andrew: and the SC test specifies both upper and lower case.

<AWK> Jennie: curious b/c had one test situation with a vendor

<AWK> ... before buying a piece of software

<AWK> ... vendor said that they were using JAWS but they were using a mouse with JAWS

<AWK> ... how to deal with misrepresentation

Andrew: if you talk to a vendor, or you read a compliance document that says we passed this because we didn't use any shortcuts.
... if it warrantied by the company, and they will fix it because it is covered.
... or you would test it if you didn't trust them you would test every key.

Katie: are we including the SHIFT key?

Andrew: yes

<AWK> "If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:"

katie: some languages do not have the feature, such as a lower case and upper case

Andrew: if a language doesn't have an upper and lower case, the issue solves itself.

Katie: ok

<alastairc> With Andrew's update, we could add a note such as: "The test procedure suggests asking the author (often the developer of the site) whether keyboard shortcuts are used. If that information is trusted then the procedure can be simpler than pressing all the keys."

Katie: we have it elsewhere. I'm just wondering what we do in terms of translations.

<Ryladog> Would the SHIFT key behavior be true of all language keyboards? I am not sure we should specify SHIFT - would use other languages.

Andrew: I would suggest that if there is a problem raised by someone doing a translation, we can revisit that question.

Alastair: I don't think it came up in the review.
... in terms of using the SHIFT key that may be less internationalized.

Katie: maybe add SHIFT key or equivalent.

Andrew: you suggest adding a note that clarifies the addition to the procedure.

Alastair: we have a section beneath the procedures. I would put it at the top of that.

Andrew: will people see the notes section?
... if it is important enough, we should put it up in the description.

Alastair: we could. It is such a complicated one to test.
... lots of ways to achieve it. Yes, we could move it to the description.

Katie: some people just copy and paste the test procedure.

Andrew: if they do that, they won't copy the notes, or the description.
... I'm thinking if we don't do notes below the procedures, then people will be less likely to look for it there.
... Alastair seems ok moving it to the description.

<mbgower> +1 for moving note info up into description

Andrew: Mike G wants the word "only" added

Mike G: if you look at the SC language, you see the word only. I think this should be added to at least the introduction.

Andrew: 1st line of the description
... ok, I think that is an easy modification.

<david-macdonald> sorry

Mike G: I believe the style WCAG tends to use is only using the stylized characters, it is just the first letter that is uppercase.

Andrew: space needs an upper case, etc.
... F1 to F12 is also not showing up with the code on it. We should probably add markup on that.

Mike G: should it be code?

Andrew: whatever is standard.

Mike G: this could also be implied for the last technique.

Andrew: ok.
... what remains for this technique is
... 1. to change the procedure so that #5 can be 1st and be conditional. And adjust the expected results to match the numbering.
... 2. move the information from the notes section to the description.

Alastair: all other changes are just about done.

Andrew: ok.
... any other comments for this one?
... any objections to accepting this as amended?

<JF> +1

<alastairc> updated: https://raw.githack.com/w3c/wcag/tech-failure-unmodifiable-single-key-shortcut/techniques/failures/unmodifiable-single-key-shortcut.html

RESOLUTION: accepted as amended

<laura> Need to drop off the call.

Andrew: Alastair it still needs DTRL in #2

Technique - Two color focus indicator #583

Andrew: 5 people say approve as proposed, 5 have changes.

Rachel: examples were not working last week, now resolved.

Andrew (reviewed some editorial edits) these are now fixed.

Andrew: "when to use" which changes to "applicability" when published.
... we should make this consistent.
... suggest changing to "all technologies that support CSS"

Michael: we don't have the consistencies I would like.
... the generator will put in some standard statement.
... we probably don't need to put anything in.

Andrew: "The objective of this technique is to create a two color focus indicator that is always visible and does not require multiple classes to ensure constant sufficient contrast of the focus indicator regardless of the color of the component it is focused on." suggest: "The objective of this technique is to create a two-color focus indicator that has sufficient contrast against any background color. This technique eliminates the need for multiple classes to ens
... ensure sufficient contrast of the focus indicator when viewed against different backgrounds."

<AWK> "However, if the focus indicator is two colors -- a light color and a dark color -- then it will always have sufficient contrast against any background color."

Andrew: broke another long sentence into 2
... in I.E. - we need a comment
... I didn't know if the intro to the examples was needed.

<Rachael> /me Jennie, would you like me to take scribe?

<Rachael> scribe: Rachael

Alastair: I've seen instances where well meaning developers set up a website that is then overwritten. These are such a low specificity in CSS terms, they get overwritten easily.

AWK: Nothing incorrect about it. If people are happy, I am. Examples 1 and 2, I've fixed it. For the procedure, do we want to start this with "For each focusable user interface component..."?
... to apply this technique to the site, you might not want to have it so that every component does this. The menus might do this differently.

<mbgower> Also in the note, 'programattically' should be programmatically

Katie: It's per page, right? So you may want to add language that takes the template into account but I think this is OK.

AWK: If you have a page with a menu system that uses a different technique, we are saying that you can't use this technique and pass it on that page. I don't think that's what we're saying. Its a technique but not the only technique.

David: I'm fine if you want to drop off the first part of the sentence.

Katie: You can add the focusable ui element to check 1.

David: I'm fine if we change the intro to "Choose an input that has this class applied to it". That would be step 1. Step 2 would then go on.
... "Choose a component that has this class applied to it."

Alastair: That undermines the introduction some.

David: Choose a dark one, choose a light one. Choose inputs with varying colors.

Alastair: We aren't saying that you have to use this. We are saying if you are using this, this is how to test it.

<AWK> "For each User Interface Component that the two-color focus class is applied to"

David: That could be one long test.

AWK: It's shorter than every user interface element.

Katie: I think the way you just said it is easier for tools to test.

AWK: Anyone else? Thoughts?

Alastair: I don't mind that. I am just less enthusiastic because the idea of the technique was to create a blanket mechanism to create a strong focus indicator. Its testing you've done it properly rather than that you have a good focus indicator.

John: +1 to that

+1 to that from me as well

AWK: We have spent time on this technique saying you don't have to use it so it might cause some confusion.

JF: What was the specified goal of the SC? Are we testing against that?
... this is a technique, not THE technique.

Andy: Are we talking about the focus indicator?

<AWK> "For each focusable user interface element with a two-color focus indicator:" ??

Andy: There is a difference between focus of an object by itself rather than in a column or row where it is one of several. Knowing something is in focus that is by itself it needs a greater visual indication. I don't think I really saw that....

Another point is speed of change of stimuli. Last year I was working on perception in terms of speed. One of the things I've been looking into is very rapid change. Sometimes the change happens so fast we don't see the change happen. A lot of the interfaces I've been designing lately have animation that slows the change down.

scribe: doing so makes the change more obvious.
... a gradual change or a delay seems to be more noticable.

AWK: Those are important aspects we don't deal with in WCAG right now so would likely roll up to a new SC rather than applying to this. This one is trying to solve the problem of color contrast of focus. I know that is another discussion we're having. A one stop shop for focus alert specification.

<Zakim> JF, you wanted to suggest that the "slowing down" change is a potential NEW SC

JF: Andy, if you have more concrete thoughts or written down, sharing that with the Silver taskforce sooner rather than later would be good. I agree there is something there so the taskforce could use that. They are trying to migrate concepts to a different template so adding that would be good.

Andy: Everything I'm doing is for Silver so I will reach out to them. Its all aimed at Silver because some of it is such a huge change it won't fit into 2.2.

JF: You can join the taskforce meetings. They are every Tuesday before this call. Ping me for details.

AWK: We could say "For each user interface element that has a two color focus indicator..." That may give us some wiggle room. It would apply if a website uses this technique for some or all of the focusable elements. Thoughts?

Katie: I think its good.

AWK: My last comment is that we may want to move the note to the description. Mike G said we should change the procedure to check for code.

MikeG: My comment is old. There is now a note about that underneath.
... I also pointed out some typos in the chat here. Several items are spelled wrong.

AWK: I think I've fixed those typos.

MikeG: Programmatically has two Ms. Text shadow may have an extra space.

AWK: Any objections to accepting this technique as amended?

RESOLUTION: Accepted as amended

Issues resolution https://www.w3.org/2002/09/wbs/35422/issues-2019-07/

AWK: Thank you to all who are working on 2.1 techniques because we want to getting techniques.
... for this topic, we have 5 items. 3 are unanimous. # 1, 2, and 4 are unanimous. Any objections to accepting 1, 2, and 4 as approved?

RESOLUTION: Accept numbers 1, 2, and 4 as proposed.

Is H33 still valid #305

AWK: This comes from a comment from a while ago. Its around the title attribute. The debate around title vs alt tag. Laura thinks we should remove H33. Bruce and Andrew responded that we think its still valid.

<bruce_bailey> http://www.w3.org/WAI/WCAG21/Techniques/html/H33

AWK: Laura says that we should remove it if there are no longer valid use cases. Bruce says it may mean someone may need to write it up.

Katie: I wouldn't kill something that still works. I don't think removing this technique is necessary at this point.

<Zakim> alastairc, you wanted to ask what the use-cases are?

AWK: This is an HTML technique. It may be useful to have something in SVG.

Alastair: This is quite specific to links in HTML. I assume historically there have been use cases. I am struggling to think of use cases within modern context. Does anyone know what the previous use cases would be?

AWK: Think about H33 about clarifying the purpose of the link by providing additional information in the title. This isn't the best way to do this today but is it still a valid way of doing it?

<JF> +1 to katie - it's not whether it's "valid", but rather, is there any harm in using this technique?

Katie: Whether this is the best way to do it today or not, there are still people building sites today that have been doing this. Sometimes this type of approach keeps from breaking something. It allows you an option to keep a shorter name by functioning almost like a long description. Not everyone developing sites is using the latest techniques.

Alastair: When this technique is there with this example. I am questioning whether I think this is good.

I came across the example where someone added a description in the title attribute and when someone with low vision hovered over the link, the description blocked the content.

Katie: Not quite what I'm talking about.

<Zakim> bruce_bailey, you wanted to ask on the call: Is it okay if TITLE as the ONLY way to distinguish READ MORE style links?

Alastair: H33 references H30.

Bruce: Just wanted to get a sense on the call, if an author only put the difference in title attributes, I would pass it.

Katie: I think we should add a new technique that we would prefer people use. But not kill this.

<AWK> https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA8.html

Mbgower: I am in the minority but I like the title attribute. This will work for anyone hovering or using a screen reader. Its not how I'd do it but its technically working fine.

AWK: We do have aria8 as an alternate technique. Its not a technique I put in front of Adobe's web team to do everywhere but if someone's doing it for a valid reason, I will agree its sufficient.

MichaelC: I think we want a category of depricated techniques that are still valid but not our first choice.

Mbgower: I think there is potential here. This URL is a play on words. Its extremely abstract but the title attribute is much more comprehensible. This might be a technique to offer simplification of names. Again there are other ways.

JF: Personalization may be better term than simplification.

Katie: If someone is hovering.

Mbgower: I meant comprehension.

AWK: Is Laura on the call?
... Is there anyone who feels this technique should be removed?

Alastair: If we get a depricated category, great. There is a lot of antipathy against the title attribute due to disuse. Is there any situation where this would be the preferred technique?

Katie: Where users want a shorter context.

Alastair: Touchscreens?

Katie: You can add device types but that would have to be kept up.

Alastair: I'm not recommending adding it to the technique, just using it in the reply to the comment.

AWK: Is that the bar?

Katie: Its not the best, just accepted.

Alastair: What would the situation be that this would be good to use? I assume there is some scenario with limitations where this makes sense.

AWK: I want the simplest set of code possible but I have to have a hover.

Mbgower: A situation where I am not allowed to touch the design. I can go in and add a title attribute to add programmatic information to the links that doesn't alter the appearance of the page.

Alastair: I can live with that.

Mbgower: I am interested in what problems it is causing that requires its removal.

Alastair: poorly implemented, various devices don't use it.

Mbgower: Its adding information for certain user groups (cognitive, screen reader) so even though its not sufficient for mobile, etc. there are advantages.

Katie: I agree.

<johnkirk_> +1

AWK: Part of the initial concern is implementation issues in different browsers. If you are using it and making a conformance claim, you are making it based on user agents so take responsibility for making sure it works.

Mbgower: I do think with accessible name and title being used, it may be adopted more.

Katie: By using it as an alternate for accessible name, it brings it back.

AWK: We are encroaching on the realm of beating this to death. Can we accept this one, agree with proposed response and leave H33 in place?
... does anyone object to that resolution?

RESOLUTION: Accept response to #305 and leave H33 in place

G131 Test Procedure #339

AWK: One agreed, one needs more discussion, one needs changes.
... I had a hard time tracking through this issue. Not sure if others had similar issues.
... Bruce, what was your thoughts?

Bruce: Summarize it, the problem is that the technique goes further than the SC because the technique requires the label. The trick is how to write it up so that it has the conditionality to it. As I commented, I found myself rewriting it.

<Zakim> alastairc, you wanted to ask in what scenario this is the best technique?

Alastair: That may not be a bad thing

JF: Just because the technique goes beyond the minimum bar, that isn't a bad thing.

AWK: In parsing, if you have fully valid code you meet parsing by exceeding it.
... Laura is not here and I don't really have a comment. Do we have enough to go on or leave this open?
... looks like Alastair put this forward in March. Seems like you still have some questions.

Alastair: It was around the fact that we don't require a visible label which makes the test procedure more tricky. Perhaps come back to it next week after folks have had a chance to look at it. May just be adding a note.
... it is adding to a few SC which adds overlap and complexity.

<mbgower> I also staggered over "required" in step two of the procedure

AWK: I propose we give this a week to have more time.
... does anyone object to that?

Bruce: A few techniques ago we were discussing notes and that we need to move them out of the test procedure.

AWK: Yes I think we are trying to move the notes out.

Bruce: If the precondition is clear, the test procedure can be simpler.

AWK: G131 had a precondition and we can make that more specific to be more focused.

Bruce: I think that is complicated in this case because this is also supposed to apply to instructions. That seems to be what is making this hard.

AWK: I think its good to give people more time to look at this and its unlikely we'll finish it in 8 minutes.

RESOLUTION: Leave G131 open

AWK: In the few remaining minutes here, does anyone have any techniques. Mike G, are yours progressing?

I may get the failure technique for motion actuation done.

mbgower: I haven't had a chance but should get to it today. There is also one for pointer gestures with Detlev that may be done.

Andy: Much of what I'm doing may be for Silver, but there is some work that could be done to the current understanding documents so that everything would not be different in Silver. Stepping stone changes. An extension possibly.
... how do I go about that?

mbgower: Without context, the pointer gesture technique is a best practice technique that exceeds the SC. That may be an approach.
... you can write a technique that allows you to meet an SC but goes beyond it. Redoing the SC may be more difficulty.

Andy: The current algorithm for contrast, the brightest color is no brighter than a certain setting. Based on human perception. That is something that may change for Silver but adding brightest color no darker than XXX as a best practice.

mbgower: We have non-text contrast. That could potentially be a technique for that.

Alastair: You'd describe what you are trying to do, examples, and a test procedure.

AWK: I would also say that there are edits to the understanding document you can create a pull request to add to understanding documents or you can create a wiki page and say you'd like to add the paragraph and why. Then someone can help create a pull request.
... changing the understanding documents. The first hard part is writing it down. The second hard part is getting everyone to agree with it.

trackbot end meeting

Summary of Action Items

Summary of Resolutions

  1. accepted as amended pending changes to use of popup.
  2. accepted as amended
  3. Accepted as amended
  4. Accept numbers 1, 2, and 4 as proposed.
  5. Accept response to #305 and leave H33 in place
  6. Leave G131 open
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/07/09 17:10:24 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/on one test/one long test/
Succeeded: s/...this is a technique, not the technique./...this is a technique, not THE technique./
Succeeded: s/AndieS/Andy/
Succeeded: s/AndyS/Andy/
Default Present: alastairc, AWK, helixopp, Jennie, Laura, MichaelC, JakeAbma, johnkirk_, MarcJohlic, JF, Glenda, stevelee, Katie_Haritos-Shea, SteveRepsher, mbgower, Rachael, bruce_bailey
Present: alastairc helixopp Jennie Laura MichaelC JakeAbma johnkirk_ MarcJohlic JF Glenda stevelee Katie_Haritos-Shea SteveRepsher mbgower Rachael bruce_bailey
Regrets: Detlev Chuck Justine Rafal
Found Scribe: Jennie
Inferring ScribeNick: Jennie
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Scribes: Jennie, Rachael
ScribeNicks: Jennie, Rachael
Found Date: 09 Jul 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.)


[End of scribe.perl diagnostic output]