W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

22 Jan 2019

Attendees

Present
AWK, alastairc, stevelee, JakeAbma, MarcJohlic, Chuck, Raf, Makoto, SteveRepsher, Brooks, Laura, MichaelC, Kathy, kirkwood, Katie_Haritos-Shea, Rachael, Mike_Elledge, gowerm
Regrets
Jon_Avila
Chair
SV_MEETING_CHAIR
Scribe
JakeAbma, Chuck

Contents


<JakeAbma> scribe: JakeAbma

<AWK> https://www.w3.org/WAI/GL/wiki/Scribe_List

CSUN registration https://www.w3.org/2002/09/wbs/35422/2019-03_FtF/

AWK: reminder for CSUN, please fill in the survey

<Chuck> Jake: We suggested a possibility of a design sprint with silver task force. What's the status?

<MichaelC> Silver CSUN FtF page

<Chuck> Jake - I'm not scribing yet, but I will jump in when you are a participant.

MC: joined discussion will take place, + solid editor draft, no design sprint needed at this moment
... Silver is busy with structure and WG members can help out / add to the work

Potential WCAG 2.2 success criteria https://www.w3.org/2002/09/wbs/35422/wcag22-possibles/results

happy birthday Jim

Issue resolutions survey https://www.w3.org/2002/09/wbs/35422/issue-responses-jan19/results

Issue 567 - Labels of inactive inputs

RESOLUTION: accepted as proposed

Issue 538 - modal on load failure

<AWK> Jake: alastair's response started with "new window" information but question was about a dialog on page load

<Chuck> Jake: First, the response of Alastair, he started with a new window part. I thought the main question was... if modal dialog opens immediately on page load is a failure of 3.2.1 or 3.2.5...

<Chuck> Jake: 3.2.1 is about context trigger, which is not the case here. We don't need to discuss it. Not part of the question.

<Chuck> Jake: 3.2.5 opening a dialog and moving focus is a change of context by definition. Major changes of context of the web page... it is a change of context, and it is moving focus to a different component.

<Chuck> Jake: Opening a window is a different situation. I conclude that this is a failure of 3.2.1. They also bring up some cases where they think opening a modal dialog may be a good

<Chuck> Jake: may have solid reasons (use cases). Alert dialog. You can solve this in a different way. Secondly, according to normative text, it is still a failure. Even if we think we have solid reasons...

<Chuck> Jake: Move focus away and change context, that's not how the SC reads. Last point: My opinion is that F52 should not be a part of 3.2.1. It's about interface components not focus. This should

<Chuck> Jake: Be deleted. Why it's left there I have not clear. F52 must be deleted, it has nothing to do with on focus change.

<Chuck> Jake: Is that clear?

<Chuck> AWK: If a new page loads, and the first thing is that there is a dialog, and user focus in in dialog, this is a failure of 3.2.1 and not 3.2.5?

<Chuck> Jake: Opposite.

<Chuck> AWK: I missheard you. So it is a 3.2.5 failure.

<Chuck> Jake - back to you

AWK: it doesn't fail 2.3.1, wondering if it fails 3.2.5

Chuck: when directly opened a dialog on page load, there's no change of context

Brooks: agree with Chuck and AWK, no violation with 3.2.1 or 3.2.5

<Detlev> Do you want me to rewrite shorten to response to something short?

Detlev: probably not a failure, might be after opening a page and then to another element.

<AWK> F52: https://www.w3.org/TR/WCAG20-TECHS/F52.html

Detlev: have to discuss if F52 need to be kept at 3.2.1

<alastairc> In June 16 we couldn't get consensus to remove it (https://github.com/w3c/wcag/issues/170#issuecomment-224328983), but I think we should remove it from 3.2.1, keep on 3.2.5

<AWK> https://github.com/w3c/wcag/pull/175

<Chuck> Jake: The most interesting part ... two fold... when it happens on page load and look at technical details... one milisecond after page load... is the dialog the new truth? that's a different

<Chuck> Jake: Perspective, and I agree with it. There's another issue that's closely related. You are well aquainted with how the page should look (from past experience) and suddenly...

<Chuck> Jake: same page shows new dialog. So this still feels awkward. but if it happens so fast that you don't know the original page, then I can agree.

<Detlev> Mike, would that fail mean we fail *all* content that opens after page load for SC Interruptions?

AC: other people saying F52 must be deleted from 3.2.5.

<Chuck> Jake: one small more question. If a page loads, pure technically, by default the focus is set on the body. In a slow connection, it starts reading the page, and the focus moves to a dialog...

<Chuck> Jake: That is a change of context. Parts of the example message also fits. If that happens with a screen reader which may cause confusion, we can say it happens so fast that it's not

<alastairc> So if the original question is: Does "having a modal dialog open immediately on page load constitutes a failure of SC 3.2.1 and/or 3.2.5." Yes to 3.2.5, and F52 is a close match to the failure.

<Chuck> Jake: a failure for 3.2.1 but pure technically with what happens with the focus it does fit the text according to my view. Specifically the example Michael Gower mentions.

<Chuck> Jake: Or do I read the normative text wrong?

<Chuck> +1 with Detlev, we can't control internet delays.

Detlev: if it loads immidiately, I don't see a problem

<Chuck> Jake: Just popped up in mind, I post on a regular basis. Often they show the modal after some seconds... Read page... they often show the popup not directly but half second later. Because if we dont...

<Detlev> difficult to quantify...that time delay

<Chuck> Jake: It's still not a failure. An automated change of context without user action...

<Zakim> Brooks, you wanted to say yes, it does matter if there's a delay

Brooks: if there's a delay, it would be a failure

<AWK> zck g

AC: there are companies with legal reason to do show the dialogs as they say

MG: a scripted time delay will be a good one to do make it a failure

<Zakim> AWK, you wanted to ask alastair what is the change of context that triggers the 3.2.5 failure?

<Chuck> ack Chuck. AWK made my point.

AWK: is context set at page load?

Raf: from screen reader point of view, SR start with mentioning the page, if focus / context is moved quick, it won't be a problem
... otherwise I agree it is a possibl;e issue

Check: never experienced a delay in a dialog pop up when page is loaded

<Detlev> Will try to redraft shorter yes

RESOLUTION: Leave open

Potential WCAG 2.2 success criteria https://www.w3.org/2002/09/wbs/35422/wcag22-possibles/results

Issue resolutions survey https://www.w3.org/2002/09/wbs/35422/issue-responses-jan19/results

<alastairc> Response: https://github.com/w3c/wcag/issues/400#issuecomment-455197825

Issue 400 - SC 1.4.11 contrast on hover included or not

RESOLUTION: accepted a proposed

Potential WCAG 2.2 success criteria https://www.w3.org/2002/09/wbs/35422/wcag22-possibles/results

?me plese

<Detlev> added results

AWK: are there no brainers?
... or some to not do?

AC: Accessible Authentication, non-text contrast are no brainers, 3 or 4 very solid

<Chuck> Scribe: Chuck

<JakeAbma> Chuck: what is urgent for the next thing

Jake: Before weekend, spoke with ... about one of our suggestions. Custom gestures not preserving defaults are breaking touch. Outcome was from his perspective that this is a very needed sc.
... It is possible to break touch in two different ways. Or at least in 2 different operating systems. Android there is a way to break touch with signature fields where two fingers are required.
... Or ball mouse, where you cant use swipe gestures. iOS allow ... volume button but you don't know how to use with VoiceOver. Developers can pass by VoiceOver and directly set
... one finger touch to volume button but screen reader users can't use it anymore and won't be read. If I may speak for Chris and myself, there is a real world problem for breaking touch.
... This is urgent for the next release. And it does happen in the real world.

Brooks: Had a question about adding to this list. Things that we individually bring up outside of the task force. Is that a possibility in the future? How does that stand?

AWK: I don't know that the answer is known right now. Key question is... do we have a sufficient critical mass that makes sense to do in a 2.2 timeframe. We are also...
... unlikely to have new criteria for all of these. Particularly if we keep a short timeline (another question) we are unlikely to add 10 new sc during the next phase.
... If we start out with 10-12, that may be some additional idea may be fantastic. We do want to be careful and not start out with 70 and spend time culling it down.

<Zakim> alastairc, you wanted to say that we need to commit to a 2.2, then we'd process the SCs in the way we discussed at TPAC. If we don't commit to a 2.2, we can work on them for silver

ac: That's how I would answer the question. We are at the stage of deciding if we should commit to a 2.2, then we would process the sc. this isn't to say this is a final list. We hope more comes
... from COGA. We will try to process it like a backlog, prioritize, set a number to start with. Try and keep work focused.

Brooks: if there is carry-over in the charter. I've som ideas. What is going to go in?

ac: We did have 2 criteria in 2.1 that weren't from task forces.

AWK: Certainly task forces cover a lot of ground. You can shop an idea around to the tf. They may have already thought about or aren't as focused on. Not impossible the idea would make it...
... Anything that would become a sc needs people doing work on it and believing it. Many hands make light work.
... There are ones I put "no opinion" on. I don't know if people had any questions on these. May have people on the call that can answer. For example, #8 on biometrics.
... may already be covered by 1.1.1. Not sure what to think about this one, didn't understand it.

Katie: You don't understand the question?
... You are familiar with one from 508. I don't think it comes under 1.1.1. The one from 508 has to be in text. An alternative of some kind. Understanding what... Just don't know how we word it?

AWK: May have been confused by mentioning 1.1.1. When I think biometrics I think retinal scan or fingerprint to authenticate.

Katie: Someone may not have a finger or eyeball. You cannot rely solely on the biometric because someone may not have the necessary characteristic.

AWK: yes. That's what this one is about.

Katie: I don't relate this at all to 1.1.1. Doesn't necessarily have to be text (that's a possibility). But doesn't necesarily make it workable for another biometric.

ac: is it for authentication?

Katie: Yes.
... We can have an authentication guideline.

AWK: ok. That's one that I now know more about. I can change my response on that one. And then proximity of related information. This one came from low vision.
... I guess I'm trying to understand what this actually means in practice for a user? What's the user experience that this is trying to address?

Jim:

Happy Birthday Jim!!!!!

<alastairc> http://w3c.github.io/low-vision-a11y-tf/requirements.html#proximity-of-related-information

Jim: We haven't had a talk with coga yet. some of this is related where you have a large form field and on one side a text input area and name on one side and way over on the other side says
... Required. In zoom you'll see the name and field, but you might miss the "required". Some of those sorts of things where things are related but are separated far.
... Another instance where a menu that you could click on and take you some place but on modal interface was way over on the other side, where a down arrow gave you a different
... Set of options. Didn't always see that there was a down arrow on the far right side. No horizontal banding to let you know where to follow. If you did follow you found
... three or four down arrows. Really poor design practices. Coga may have some different issues.

AWK: There's a user problem there, got it.

<Detlev> It is an issue that has come up frequently in LV user testing here

AWK: Do you have hope that there's a way to identify a metric around how close is close enough? Or is there a way to adapt content to make things as close as necessary?

Jim: We haven't gone past "that's an issue". We'll explore what the actual parameters are.

<Ryladog> Close Proximity for Instructions and Labels

<alastairc> Probably two things, partly filled by status updates + user agent, and partly a new SC around the visuals.

Katie: I look at this as different from the coga needs where we logically put things together.
... I think that clarifies a little bit. maybe we have to have a measurement, maybe we don't. I think theres a better name for that. That's different than having like content to be located
... In a similar section of the page. I want to keep those requirements distinct.

Jim: Slightly different from programatically determinable. That only is useful if you have AT running.
... We are focusing on non AT.

AWK: Any questions on any other ones where they want some clarity?

Katie: What will we do about page refresh?

AWK: Low vision. Jim want to speak to that one?

Jim: This is one where the user issue is some in page update that happens to some information. When you try to tab to it your cursor is back on top of the screen. Now you are lost and have to
... find your way again. With keyboard you are hosed. Have to navigate all the way back.

Katie: OK, got it.

Jim: Ways to do that without a whole page refresh.

Brooks: Appreciate what Jim and Katie are discussing. I'm seeing a gap in current SC's and some items are listed here... visual affordance.... <noise>

Jim: ... how maybe a complex control works. Maybe an AT user can be provided distinct instructions on the structures and relationships. But if you don't have AT, how can we close that gap?

Brooks: how do we provide that, like a reverse 1.3.1. How do we make content accessible...

<Zakim> alastairc, you wanted to ask about focus management guideance, overlaps with Page refresh?

ac: On the page refresh one. When I'm running training, I can describe focus management issues with dynamic content. If there is some best practices on focus management as part of
... Page refresh if it fits in and if a sc or two can do on how focus should be managed.

<Detlev> I would see this behaviour already as a failure if 2.4.3

AWK: There's comonalities. We are going to need to figure out is if it's better to have something that is narrowly scoped or try a broader impact. 1.4.11 we made broader and it drifted away...
... Maybe is why we have a gap now. What I'm hearing from people is that there are good ideas on this list.
... Any other clarifications, comments, questions?

<alastairc> Detlev - I'd see that as a stretch for some of the aspects I was talking about

<AWK> Survey open at least another week

detlev: wondering ... we don't want to add sc for the sake of adding them. tests take longer and longer. If something is already covered or argued that it fits under an existing sc...
... I prefer to create a failure. Could be considered under focus order. If there is already a good place to put things...

mike: Wonder if we can handle these through some techniques.
... biometrics especially.

AWK: A valid question, and one we will include in evaluation... "is this already covered?". I know that mobile task force had a number of things that they heard were covered already in the past.
... We are looking at a list that has already removed many of those things. Most of these are probably not well covered and need to id the gap, while recognizing that there may not be a gap.
... Part of the process. We have 50 level AA criteria. We don't want to increase that to 60 only because more is better, unless we are really benefiting users. Which is what I think...
... All these potential sc do. Hopefully we are on right track.
... Couple of comments in survey. "We need to work on techniques in 2.1 rather than consider 2.2..." for example.

mark: The only thing I'd add to that... the date for silver is extremely ambitious. The whole revamping of everything, looking at 2 years seems aggressive. Maybe we focus just on 2.1.

<Detlev> +1 to Marc

mark: issue on lable and name, ... focus on understanding documents. 2.2 AND Silver.... Does anybody know if those dates are realistic or just pie in the sky? Seems like a lot to do.

AWK: Right. That's part of the question. Related to "2.2 or silver", are there things that need to be done, are we willing to wait for silver to be done to have those?
... We know how to get an update out for 2.1. We can be accurate on when that happens. That may be the way to maintain progress.

Mark: If we get 2.2 out in summer of 2020, and get Silver out in 2021. Maybe having everything go in silver in 2021. But if silver slips and slips...

Katie: I'm concerned that we have this feeling that someone will hand us silver. We have to make silver. The longer we wait to jump in the worse it gets. We have to shore up 2.1.
... Then jump into silver to get these new things.

chuck +1 to Katie.

Katie: Supposedly a different thing.

AWK: What does shore up 2.1 mean?

Katie: Techniques and understanding. We want to have good techniques. Part of this concent is what we'll be untilizing in silver. We need some extremely solid content.
... I feel like we are pushing out silver, expecting someone to hand it to us. We are not making it happen, we need to.

Rachael: The question at this point: Is there anything on this list that cannot wait for silver? Silver is in the next 2 year timeline, if it takes 4 years then 2.2 makes sense.
... I don't see how we do all three.

Mark: Just wondering if we know from w3c standpoint. If we just focus on silver and shore up 2.1, start working new sc with goal of having in silver, fast forward a year from now...
... we find out that silver slips. If we have all 6 of these ready, and sillver slips, can we just include in a 2.2?

Michael: If we have multiple working possibilities... they may not approve the charter if we don't appear to know what we are doing. We may be seen as having failed to deliver a promise. Safest thing

AWK: Hearing from some it would make a difference if we had a crystal ball if we knew how long it would take to get silver published, might inform the decision.
... People on this call are likely going to want to be in ongoing development of silver. The reason we haven't moved to that is because we are focused on other pieces.
... If we introduce another project has impacts on that as well.

<Zakim> alastairc, you wanted to say techniques are either drafted, published, or stalled, and not many stalled.

ac: Mostly there on techniques for 2.1. Not all done, but got good coverage for A and AA. Some few stalled with some people. Looking ahead for this year, we do need to be doing something else.

Jake: What I miss in discussion is the 18 months release period. Michael Cooper was telling about promises we make or made. What is the 18 month milestone?
... Also the promises we even made to task force (like COGA) that it will not be 4-6 years before we have another release. We will release fast and often. I haven't heard of a process.
... Not sure of status of those promises. And what we told different people in groups.

<AWK> https://www.w3.org/2017/01/ag-charter

Michael: We didn't actually promise a particular release schedule. We said we were exploring a schedule. We likewise told the task forces, we didn't make any commitments. Now we are trying

<alastairc> Public timeline: https://www.w3.org/WAI/GL/project (note the status for some is 'incubation')

<AWK> "The Working Group intends to produce updated guidance for accessibility on a regular interval, starting with WCAG 2.1. Depending on the outcome of the requirements development for the next major update to WCAG, it may be necessary to pursue further dot-releases of WCAG until a major release is ready to be completed in time for a scheduled release date."

Michael: To decide if we want to make a commitment. The wording is short of a promise. It's a commitment to explore.

Detlev: Might be ok to do 2.2 if we try to keep it small, so we have time to complete 2.1 work. Not make it too demanding. On other hand carry on discussions on silver.
... I find it strange that not more discussion on proposals from sean and jean. There have been only one longer response on the mailing list.
... Seems to be dead silence on silver. These are hard and difficult and challenging issues. I would have expected discussion. Do we not know what to say? What is it?

Michael: We've been stearing for a big discussion at CSUN. Task force it taking into account TPAC feedback. Nothing to discuss now, but in conversation.

ac: Conformance document went up recently. Stoked conversation.
... After TPAC we did commit to start ramping up and have more overlap between agwg and silver groups.

detlev: maybe I missed it?

ac: They sent a document. Just after xmas.

Michael: Silver task force does a lot of work, even if discussion is not visible.

ac: Anyone on call that is working more on or with the silver task force? Can anyone report back now? Or ask jean and sean to make progress more visible?
... We will start having more overlap.

<kirkwood> my recomendation would be to have Jean and/or Shawn give feedback

AWK: Any other questions or thoughts? There are things to do. There's a big thing in "silver" on the horizon. Hard to tell when we can expect it to arrive. What do we do about it?

<alastairc> Kirkwood - I'll just check there isn't something they've made available to prevent an RTMF response, but yes that would be next :-)

AWK: Detlev suggests that if 2.2 is small, or improve on techniques in 2.1. I envision as well. Chances are 2.2 would have a smaller additional sc than 2.1. But a bunch of questions exist.
... ac and I can talk about getting an update from silver so we can try to encorporate that in our thinking about timelines and events.

Brooks: Add on to what Rachael said... is there anything we can't live without? Must haves. Another factor is to figure out if we have techniques in mind for these potential sc's.
... Retro on 2.1 ... we wish we had figured out techniques simultaneously. Pairing up techniques with sc would be a way of filtering next iteration of work.

AWK: for new set of 10?

Brooks: When we are trying to determine if we have enough. Not only do we have pressing issue, but also do we know that we have the techniques as well.

AWK: Task force ... may be able to speak to techniques. Question comes up, are there additional techniques or is there just one? I'm sure answer is yes for some but not enough for any of them.

ac: Chicken and egg. People won't take time to create techniques until they know that they are working on an accepted sc.

Mike: Some kind of quadrant analysis of proposed sc topics. Measure them on impact, difficulty, least difficult higest impact.

AWK: Great point. Difficulty in defining sc, implementing it for people, multiple ways to look at it.
... Might be a 3d analysis, not just a 2d one.

Mike: If there are obvious techniques in existence, that's one way of analzying things.

AWK: We've got some additional thoughts. It sounds like there are good ideas. We want to know more about timelines, which means using crystal ball. We have to make a decision on the best

<alastairc> gowerm - probably better for next week, we'll put it on the agenda so people are ready.

AWK: Data available. Brooks mentioned additonal criteria. Sooner we hear and compile a list the better. Raise new potential sc. Mike want to introduce your label and name thing?

Mike Gower's Label in Name email

<alastairc> https://lists.w3.org/Archives/Public/w3c-wai-gl/2019JanMar/0096.html

Mike: Sent out email to list yesterday. Reviewing label and name, what are some of the pain points? I took out three key problems, listed 5 examples.
... First problem is if we ignore programatic definition of label, it's hared to define what is a label of component. By convention to the left and/or above.
... Second one accessible name, clear on what it is, limited to one thing. That's not obvious to end user what the rules are. Some things help. Group role and legend fields sets are not part of calculation.
... On other hand, some invisible things (aria-label) take significant priority in calculation. Other things take precident.
... third thing, slightly more complex interactions. What are decent mature solutions for navigation for richer components are at risk of being altered by requirements for this sc in that
... It's visual and programatic label are the same. Sometimes have different biases on what the screen reader wants to use.
... If you don't have speach input, you don't understand navigating using speach input.

<alastairc> https://lists.w3.org/Archives/Public/w3c-wai-gl/2019JanMar/att-0096/01-part

<alastairc> 2nd example: https://lists.w3.org/Archives/Public/w3c-wai-gl/2019JanMar/att-0096/02-part

Mike: On first one, I have a label "work phone" and three inputs. What of those inputs is actually labeled? Are all three labelled? Is the first one labelled and the next 2 unabelled?
... Second one simple radio group. Each radio button yes/no. Is "yes/no" the label? Or is the preceding text string part of the label?

<alastairc> 3rd example: https://lists.w3.org/Archives/Public/w3c-wai-gl/2019JanMar/att-0096/03-part

Mike: In 3... there are 4 checkboxes, each with their own label. If you do infer that the preceding description is part of the label, will be very verbose.

<alastairc> 4th example: https://lists.w3.org/Archives/Public/w3c-wai-gl/2019JanMar/att-0096/04-part

In 4... the inputs have richer information. "In the past 12 months, have you had treatment for...", then description followed by "yes/no". Kind of need all those pieces of information to have context.

<alastairc> 5th example: https://lists.w3.org/Archives/Public/w3c-wai-gl/2019JanMar/att-0096/05-part

Mike: Last one, overarching ... "how satisfied or disatisfied"... then ranking of high satisfaction to no satisfaction, then row headers with different specific topics.
... Rest of matrix is unabeled radio buttons that you infer context from the row and column headers.
... Proximity rules are not well defined. The more confined we can define the label, the better accuracy we'll have with at.

AWK: we'll use that as an intro, people can take a look at the email and provide feedback.

<Detlev> turn that into a github issue, Mike?

Mike: I do have an understaning document which tries to tackle some of this, but getting dense. If we can get agreement on a strict interpretation, will be easier to test and not mock up.

<alastairc> gowerm - good to review Kim's reply before next week https://lists.w3.org/Archives/Public/w3c-wai-gl/2019JanMar/0100.html and how that maps.

Mike: If we used all the data, would be extremely verbose.

<Brooks> Seems to me that input grouping (and the names associated with those groupings) play an important role in speech recognition, that isn't captured in the accessible name calculation

AWK: Out of time.

<laura> bye

yes, looking up my prior notes on "how to".

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. accepted as proposed
  2. Leave open
  3. accepted a proposed
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/01/22 18:01:52 $

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)

Default Present: AWK, alastairc, stevelee, JakeAbma, MarcJohlic, Chuck, Raf, Makoto, SteveRepsher, Brooks, Laura, MichaelC, Kathy, kirkwood, Katie_Haritos-Shea, Rachael, Mike_Elledge, gowerm
Present: AWK alastairc stevelee JakeAbma MarcJohlic Chuck Raf Makoto SteveRepsher Brooks Laura MichaelC Kathy kirkwood Katie_Haritos-Shea Rachael Mike_Elledge gowerm
Regrets: Jon_Avila
Found Scribe: JakeAbma
Inferring ScribeNick: JakeAbma
Found Scribe: Chuck
Inferring ScribeNick: Chuck
Scribes: JakeAbma, Chuck
ScribeNicks: JakeAbma, Chuck

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

Found Date: 22 Jan 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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]