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

<AWK> Scribe: Wilco

Purpose of controls discussion

<AWK> http://rawgit.com/w3c/wcag21/master/guidelines/index.html#purpose-of-controls

JF: There have been comments. Need to look at the language. We have a list of names, we now need to attach purpose to the list of conventional names
... we have a list of links for example. We need triggers on other pages and tag those to apply a common purpose what happens when the user interacts with the control

<AWK> Current comments on purpose of controls: https://github.com/w3c/wcag21/issues?utf8=✓&q=is%3Aissue%20is%3Aopen%20label%3A~comment-purpose-of-controls%20

JF: I had a talk with Jan. I think we have a robust document to explain what we're trying to do.
... Originally the idea was this would be the ARIA purpose working draft. I don't believe it's stable in time for us.
... We can meet the requirements by using microdata annotation.
... I'm exploring using schema.org taxonomy. All of the pieces are in place. We need to discuss the number of input types / widgets.
... I've tried to put them into functional groups, for example different button types. We have clear definitions to attach to those buttons.
... I have a spreadsheet that I'd like to share, but am not sure how to share it with the group.
... There will be a final piece, some extension that can do something with the metadata. By using this scheme, what we can do is pattern matching. It's not perfect, but I believe we have enough to get it through to recommendation in time for 2.1

<Zakim> gowerm, you wanted to say there is only one piece of this that I think WCAG needs to cover

JF: I will get it shared.

MG: I don't think the WG has to tackle all three pillars what is required. We have to create the SC, the technologies can be resolved as they come along, much like with name-role-value
... the convention is established by the technology. I don't think we need a list.

JF: I agree in terms of exiting CR and move forward, but we need to show implementability and real value.
... We can have the criteria, but we need to show it can be done and there is a value here

<gowerm> In content implemented using markup languages, form fields, controls and links that serve a conventional purpose can be programmatically determined.

JF: I believe that personalisation semantics spec is not going to be ready in time, so I'm thinking about it from the techniques perspective and work backwards.
... We want to have it be doable at the launch of 2.1

MG: We have all that stuff in place now.

JF: What's really important is that this is a criteria we need to save. It feels rickety, but we really need to get this out the door. It is critical for starting to teach people about personalisation. A fixed list is a useful starting point.

<Zakim> AWK, you wanted to discuss concerns about small finite vs large finite

<Glenda> +1 that “Purpose of Controls” is a vital part of WCAG 2.1. Once I “got it”, I realized that this is not just going to help COGA…but it would help EVERYONE!

AWK: I'm a little concerned handling it in the same way as NRV. With roles there is a finite number of roles recognised.
... For role there is an accepted list. With this it feels there are a large number of options. I'm worried if we don't provide a list people won't know if it's done or not.

JF: There is a nuanced difference. It's not so much conveying role, we're conveying purpose, which is slightly different.
... The question is is the list too big. For example, autocomplete has a fixed list stored on the browser. The autocomplete list can be set and there is a fixed list that the browser can supply.

<AWK> AWK: My comment that we need a list was in response to Mike G's suggestion that we don't need a list

JF: What I'm trying to share adds conventional button types and links
... We're going to apply the meta data so that it can be presented in a different way.

<AWK> AWK: Yes, there isn't a fixed list of roles, but there is a small and finite list of possible roles so it isn't a huge problem for implemetnation

<gowerm> q to say lets look at HTML5 as an example

JF: The key is the list. Here is a list and here is the mapping
... This lets us overlay a bubble or something, being able to convert icons to known terms

<Zakim> Wilco, you wanted to ask about future compatibility

JF: The goal is setting up the page to have it be personalized. We start with a small subset that can be tagged

<AWK> Wilco: wanted to ask about the scenario where we make a fixed list now

<AWK> ... what happens in 2.2/silver/etc and the list gets expanded

<AWK> ...in ARIA 1.1 new roles added so current roles may need to be replaced

<AWK> ... does this cause problems moving forward?

JF: The W3C recognises that in TR space we need a repository for non-standard document that have more weight, so we can put there lookup lists. We've got a perfect use case here.
... in the TR space there could be this lookup list. One of the ways around this problem is to put the list there, so it can be updated.

<Zakim> gowerm, you wanted to say let's look at HTML5 as an example of a 'list'

MG: I think there is a danger in normalising a list. If we introduce a requirement and bake it into the SC I'm concerned we can't keep control of it.

<AWK> Mike, is there a set of "safe" items that we can list?

MG: HTML5 offers input types associated with forms. It offers rel= for links. If you were to use HTML 5 you would be required to use rel=.

<JF> rel= is for link types only

MG: Second point. I want to look at the list, There is a W3C document on ... <inaudable> ... and we're defining spec for many different things that have no meaning in some societies.
... All these other names are not the family name, and have different associations with them. I don't know how we can adopt them without scrutiny.

JF: The token list in HTML5 is not mandating anything. It just means if you have a form that uses this you can add a token.
... What this comes down to is the main driver of this SC, starting with a subset that can be personalised.
... We have to start somewhere. Even though family name is different in cultures. It's not a stretch to say that if someone uses any of these, you must use it.

<gowerm> https://www.w3.org/International/questions/qa-personal-names

JF: same with schema.org. It is infinitely extendable. By using microdata we have a technique where you can attach any term. It makes the list very flexible. It's comes down to what are common components on pages
... We can cull the list, and so starting with 100+ input types, you can work it down to about 80 / 90

DF: I'm strugling what the difference is between purpose of control and information.

JF: We were originally working on "support personalisation". The way to tackle this problem was to start with a fixed list.
... I think AA was about having a much smaller list so we can start explaining how this works. By saying you need to use the tokens, it works better for everyone.

DF: If those two are very similar, we could use a similar naming scheme like on other SCs like "no-exception"

<Glenda> +1 to detlev’s idea to name these two SC’s in a way that we easily know they are related…and one is the step up of the other. “Purpose of Controls” = step1, “Contextual Information” is step2

JF: The language needs polishing. That's what we need to do, get that ready, then go to understanding document and then techniques

<Zakim> gowerm, you wanted to say I pasted in a large document on personal names from w3c

<gowerm> https://www.w3.org/International/questions/qa-personal-names

<gowerm> In content implemented using markup languages, form fields, controls and links that serve a conventional purpose can be programmatically determined.

MG: I think we're not going to forsee all the ramifications of taking in all 85

JF: This one is really critical for us. People have been working really hard on it. I think we're on the same page. We have to get it fine tuned.
... I want to really avoid kicking it down to 2.2

<gowerm> I don't want to kick this down the road. I want a safer approach

https://www.w3.org/2002/09/wbs/35422/resolving_pointer_gestures/results

<JF> +1 gowerm

<kirkwood> think this could be a powerful potentially very powerful for COG user, would like to be on monday or tuesday call with purpose

AWK: There is a survey on this one for pointer gestures

<Detlev> There is a concern by James Nurthen which seems unadressed still: https://github.com/w3c/wcag21/issues/570

<AWK> Current: All functionality can be operated with a single untimed pointer gesture unless a multipoint or timed gesture is essential.

<AWK> Proposed: All functionality which uses multipoint or timed gestures for operation can be operated with an untimed single-pointer activation, unless a multipoint or timed gesture is essential.

AWK: The goal was to resolve comments that were raised in response to the WD.

<Detlev> See https://github.com/w3c/wcag21/issues/495

DF: James point was there seem to be controls Oracle uses a lot that uses a single click for one thing, and a longer press for another
... You could toggle with one control and open a menu with the other.
... His concern was this would be impossible.
... I'm not sure how we'd deal with that. We could either say bad luck, or possibly make an exception

AWK: We discussed this, James was part of that discussion. There is a note that we need to clarify that a pointer gesture can be long or short
... I think the agreement was that a short or long gesture would be okay.

DF: Untimed sounds like immediate, not a long click

GS: Is double-click allowed? Than short/long press should be allowed.
... ACAA I've seen use of long press. I too had those concerns but it seemed acceptable

<Zakim> gowerm, you wanted to say that double click is not allowed, and I have been getting push back from some IBM resources on this one.

MG: I think double-clicks are not allowed. I've gotten pushback, we are effectively outlawing techniques common on the web.
... basically the idea of timing.

<Joshue108> I was working with a Dragon user recently who would double click links a lot, even if not needed.

MG: If you think about it from iOS perspective. It has support built in, if the OS has standard gestures, why are those not allowed for someone writing web content

<AWK> I think I hear "a mechanism is available" coming!

<Joshue108> we should have 'a mech is avail' bingo?

GS: I'm also unsure about long-press, but it seemed to be the airline community that longpress was okay. They don't make that decision lightly.

<Glenda> IATA?

Alex: We talked about how touch interface is different. So it's quite essential for basic test. How do we deal with the whole timing in this case?

AWK: So if writing is included in here there are a bunch of issues. With chinese characters this is a substantial problem.

DF: These are author requirements. I don't see the point in looking at OS gestures. As an author I'd have to make sure there are alternatives for it. I don't disallow it. Just make sure there's another way.
... I would for instance with writing T, there could be a virtual keyboard. That would meet the criteria.
... I don't see how OS requirements would interfere.

<Zakim> gowerm, you wanted to say that until now the ability to use a keyboard has been the litmus test. We are expanding the litmus test

MG: I think the difference is that until know, if you have a gesture the OS can accomodate. The a11y consideration until know is if there's a keyboard equivalent. We're now not only asking for keyboard, we're also asking for touch equivalent.

AWK: So what are the cases we're hoping to address with this SC?
... With the question of preferences in the OS, I was thinking of "mechanisms available". If you're doing something with pointer gestures that the OS doesn't do, you need to do something yourself.

<Alex> what do you mean OS don't do anything about it?

DF: What happens often is a new website with a horizontal slider of teasers. The only way to get to the next one is to drag the slider across. This SC would require that there is also a control.
... This might require an arrow or something to move the slider along.

<gowerm> Scribe: MikeGower

<gowerm> scribe: gowerm

AWK: for Detlev's example are there supports for that?

Brooks: I want to bring up a couple of issues

Brook: Do we want to count on OS support to accommodate this issue, when they won't be bound by the rules?

AWK: You said a couple of issues?

Brook: Is the intention of the SC to make the touch interface accessible by itself?

<Glenda> I wonder if the AT switch control tools could solve this. I’m looking at https://www.apple.com/shop/product/HJ2W2LL/A/ablenet-blue2-bluetooth-switch?fnode=7658879e2ddb3324df2c67835f80d1d1fb99c540974d6dd4b897a5f1a26377bb32872e7cd37cb2d466efc376076cb059e84d2b9b0abdd07f2a09bace83d9e54eafa76f8cdb5dd12be0313923b8bcc7d7b98b77fd4a893314e59ad81ed19ccac68a26ce65b4a82dd3905b923b2709a684

David: A bit of context for this. I was on the mobile committee
... We are trying to give people who are using mobile devices and limited dexterity the ability to use it. We didn't want to rely on keyboard accessibility. That's what the thrust of it was.

Detlev: The slider example... If the slider has no extra controls to move to left or right, you could say it is keyboard accessible, but if you don't have the keyboard you are out of luck.

<Glenda> I wonder if the Blue2 Bluetooth Switch https://www.ablenetinc.com/blue2-bluetooth-switch feature to allow you to program one to four custom keystrokes for use with any app or software

<Zakim> gowerm, you wanted to say Does this outlaw swipe?!

<Glenda> Check this out, documentation for the AT Blue2 Bluetooth Switch talks about Long Press. Here is a quote from their user manual “Your switch is now configured. If you want, you can add a second action to this switch by selecting Long Press. If you

<Glenda> add a Long Press action, the user will hold activate the switch for a predetermined amount of seconds to access the

<Glenda> second action.”

Detlev: Swipe as the only means of completing an activity would not be valid

Gower: I'd be concerned that flick up/down, swipe, etc would effectively be considered unsupported. There are a lot of functions dependent on those.

Detlev: The OS-level interaction is not included. This is only about web content

AWK: We can explain these things in the understanding, but we need to make sure we're clear on the same thing.

Detlev: We are clear that it is authored content

<Glenda> I see evidence in the manual for AT Switch devices for touch screens…that “Long Press” is a common way for people with mobile disabilities to communicate with their AT Switch device.

AWK: For things that are allowable in content like double-taps, we need to be clear on whether we need to support an alternative

<kirkwood> never with a web client

AWK: What do people think? I'm hearing some questions. Can we resolve this?

<Glenda> more specific references to “Long Press” being a regularly expected user interactive when using a Switch AT device. Quote from Switch Control documentation for Blue2 LONG PRESS

<Glenda> If you added a second Long Press action to your switch, this is how you set the number of seconds a switch must be

<Glenda> activated to trigger the Long Press action.

Brooks: We know the guidelines in previoius iterations have been applied to other contexts than pure web. Do we keep this in mind as we author these new web guidelines?

AWK: That is a tough question. We know that WCAG gets adapted to apply to software and native mobile apps. Our primary focus is web content, but we know that's not what it's restricted to

Alex: No one can use the web content unless they can operate the operating system. So if there are any gestures needed to operate the OS, you should be able to carry forward that in the web content. So anything dependent on the OS should be accepted. Like long-holds, etc
... So perhaps the way to split this up is to look at things that are not in the operating system. Does that make sense?

AWK: Which things are you thinking about?

<kirkwood> +1 to Alex. The operating system to handle a double click.

Alex: You would have to go beyond what the OS provides. Any complex gestures custom to your app that are not specified in the OS.
... Otherwise it seems too much of a restriction

Detlev: Would you consider text input by drawing in the OS to be exempt?

Alex: Yes. Web apps are 99.99 relying on the OS for character recognition

Detlev: if you could only write a T with a finger was via the web page, as opposed to using the native keyboard, that should be a failure

Alex: Let me ask you a question. If you get to a text input field and you are using a language which accepts drawing based on the OS function, would that be allowed?

Detlev: That would not be an author-provided control.
... All the things provided by an OS would be exempt, since they are not provided by the author.

Alex: Can we focus on things that are only created by the author and not provided by the functionality of the OS

<AWK> "All author-provided functionality which uses multipoint or timed gestures for operation can be operated with an untimed single-pointer activation, unless a multipoint or timed gesture is essential."

Katie: can we just cover that in the Understanding document?
... We can take the feedback from comments and incorporate that into the Understanding?

AWK: We can also do what I've just pasted in by adding 'author-provided'

Katie: I like that

Detlev: I think that's a good solution

<Alex> what about "author-created"

AWK: So Detlev, if I use a swipe, a single-finger gesture, is that covered by this?
... What counts as a single point?

Detlev: Swipe would be alright if it is a user agent provided gesture.
... If you have a widget that you swipe that activates the widget, then that's author provided. You would need to listen for events, etc.

AWK: So an author-provided swipe would be covered and you would need to provided an additional mechnism

David: This conversation about author versus OS created gestures... I think we need to cover this with language. I think we have confusion even amongst ourselves

Detlev: IN my opinion, 'author-provided' would do it and we'd cover in teh Understanding document

David: I can live with that

"All author-provided functionality which uses multipoint or timed gestures for operation can be operated with an untimed single-pointer activation, unless a multipoint or timed gesture is essential."

David: You might want to add "custom" as well.

AWK: I think we can clarify that in Understanding
... Do we need to define multi-point? Is that three synchronized touches, or me doing multiple single points?

Detlev: It could be both

<laura> definition would be helpful.

Alex: Multipoint gesture is considered multipoint simulataneously. You are going to confuse a lot of people

AWK: Okay, so a swipe is timed then?

Alex: That is a milliondollar question.
... the difference between a swipe and a line you're trying to draw across is defined by timing.

Detlev: it is more complex than a simple tap.

AWK: So if our understanding is that multipoint timed gestures include all of those things and the goal is to make the author doing something beyond the OS responsible. So, I make a custom slide to swipe to the right to increment up, I need to provide an alternative, unless there is an existing OS mechanism?

<AWK> https://www.w3.org/WAI/WCAG21/Understanding/21/pointer-gestures.html

AWK: Do people feel like it's ready to go?

<Ryladog> Ready to go

Alex: How about a note to explain the whole OS thing?

John: Are you prepared to draft the note?

<AWK> NOTE This requirement applies to web content which interprets pointer gestures (i.e. this does not apply to gestures that are required to operate the user agent or assistive technology).

Detlev: there is a note in the SC.

Alex: That does not cover what we have been talking about.

<AWK> NOTE This requirement applies to web content which interprets pointer gestures (i.e. this does not apply to gestures that are provided by or required to operate the user agent or assistive technology).

<JF> +1

AWk: how about saying something like what I just pasted in

Alex: Add OS

<AWK> NOTE This requirement applies to web content which interprets pointer gestures (i.e. this does not apply to gestures that are provided by or required to operate the operating system, user agent, or assistive technology).

AWK: MIke Gower have we addressed your concern?

Gower: I think it goes a way to addressing what were other concerns than mine.

<AWK> https://www.w3.org/WAI/GL/wiki/Comment_Summary_2-5-1#Proposed_11.2F8

AWK: Are there objections to accepting this as ammended?

Detlev: The link you've put in is the template

AWK: The Understanding text is separate from the SC.

RESOLUTION: SC accepted as amended and put to CFC

https://www.w3.org/2002/09/wbs/35422/resoling_orientation/results

AWK: This is Orientation, which is 2.6.2... Sorry, we also need to get a resolution as to whether people are happy with the comment responses we have for pointer gestures.
... Does anyone object to accepting the comment responses to 2.5.1?

RESOLUTION: Accept comment responses to 2.5.1

Orientation SC

AWK: So, for Orientation, Steve are you on the call?
... Steve's comment is detailed.

<AWK> https://www.w3.org/WAI/GL/wiki/Comment_Summary_2-6-2

<AWK> proposed version in survey: A mechanism is available to view and operate content in portrait and landscape orientation, except where a specific display orientation is essential. (delete definition)

AWK: What do people think of Steve's suggestion.
... It is very similar to Steve's concern

<Alex> airplane entertainment system

<Alex> kiosk

<Zakim> gowerm, you wanted to say is it user agent?

<Joshue108> Understanding for an edge case like that IMO

Alex: Most of the airplane systems were customized but underneath you may well be running a browser. So the OS in and of itself is actually probably rotatable, but the device doesn't even have a sensor
... So it is locked.

<Zakim> gowerm, you wanted to say this seems like another SC where the language has abstracted the desired end result to the point it is difficult to understand

AWK: If it's a kiosk that is always viewed vertically, or in an airplane, the display orientation sounds essential.
... Would people agree with that?

Josh: I've been working on this in the airline industry, so I want to be careful that we do this one right.

AWK: If we make it clear what the exception covers -- kiosks, seat-back displays, etc -- does that address it?
... I think the SC text is fairly clear now

<Glenda> I was just looking at Self Contained, Closed Products (1194.25) at https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/guide-to-the-section-508-standards/self-contained,-closed-products-1194-25

AWK: If a user agent allows re-orientation, then I think you've shown you've met the SC.

David: I like the closed funcitonality Glenda pasted in. I think we can leverage that.
... Otherwise, I think it's ready to go

<Glenda> Look at (j) (j) Products which are freestanding, non-portable, and intended to be used in one location and which have operable controls shall comply with the following:

<Alex> hard to hear you, David

David: I think we are mainly concerned with "on load"

AWK: And do we need language about this?

David: Do people think we are requiring language that it can work anytime?

<Joshue108> +1 to Glenda

Glenda: I think for everyone that's been distinguishing between the web author and closed platform.... Closed regulations include considerations for height restrictions and reach. We're not hardware

<KimD> *I thought we'd talked about it reorienting at any time, not just on load.

AWK: I think David was saying that if you didn't support those changes dynamically

<Detlev> Side note to Pointer gestures: I found the link to my draft Understanding text but I don't know fromwe where it is linked... https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html

AWK: would you be out of conformance?

<Zakim> Joshue, you wanted to ask are we saying that with a plane monitor that its landscape mode is essential

Josh: Just a question about the exception...
... So what are we saying about on a plane?

<kirkwood> supporting dynamic changes in page aspect ratio. I don’t like the rotation terminology. We are never rotating content. This is landscape vs portrait aspect ratio

<kirkwood> +1

AWK: You could limit your content to landscape if the environment you are always operating in only has landscape devices

<Zakim> gowerm, you wanted to say others have raised that concern -- that it should NOT just be on load

Brooks: Does the intent of this introduce another requirement for authors to introduce a breakpoint?

<Glenda> Confirming that we are still focused on this version of the SC language: proposed version in survey: A mechanism is available to view and operate content in portrait and landscape orientation, except where a specific display orientation is essential. (delete definition)

No, it we are not introducing another set of break points for authors

Kirkwood: I'm really confused about this one because of the idea we're controlling rotation of content in a browser.
... If we're talking about responsive design, a browser can handle, but for content rotating, that's very strange for authoring. I have a difficult time with terminology if we are talking about dynamic aspect ratios

AWK: There are APIs for authors to use or abuse. We're trying to introduce language to prevent that from happening. This is far more for mobile. You are going to pass this with a desktop unelss you go out of your way to fail it.

s/a desktop unless/unless

AWK: With the current SC proposed text and the additions posted in the wiki, are they any objections?

<Ryladog> A mechanism is available to view and operate content in portrait and landscape orientation, except where a specific display orientation is essential. ?

David: I interpreted this to be for page load, and Mike interpreted it the opposite.

<Glenda> +1 to accepting for next working draft “Orientation: A mechanism is available to view and operate content in portrait and landscape orientation, except where a specific display orientation is essential.”

<kirkwood> can we use “aspect ratio” instead of “orientation”?

David: Do we have a consensus on which side of the fence it falls on, and does it matter?

AWK: We cannot use aspect ratio. We're talking about sensors

<KimD> +1 to MG's interpretation

<Rachael> I agree with Mike. It should adjust

AWK: Does anyone disagree with Mike's interpretation?

<Glenda> Yes, I agree that is must adjust when you turn it (unless it meets the exception)

Detlev: Unless the user choses a control that prevents that.

<JF> +1 to detlev - user choice should always trump any other action

AWK: ANy objections to accepting?

<Glenda> +1 to accepting

<JF> +1

<Detlev> +1

<Ryladog> +1

<JakeAbma> +1

RESOLUTION: Accept SC text as proposed.

<Rachael> 0 I would prefer the exception in the SC, but won't object.

AWK: Any objections to the comment responses? I believe we're addressing his concerns with user agent language in the Understanding

RESOLUTION: Accept responses to issues.

<AWK> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/in ARIA 1.1/...in ARIA 1.1/
Succeeded: s/ACA/ACAA/
Succeeded: s/taht/that/
Succeeded: s/anyimte/anytime/
FAILED: s/a desktop unless/unless/
Default Present: AWK, JakeAbma, Jan, Glenda, JF, kirkwood, Brooks, Wilco, Joshue108, Laura, KimD, MikeGower, Detlev, Katie_Haritos-Shea

WARNING: Replacing previous Present list. (Old list: AWK, jasonjgw, SteveRepsher, Brooks, jallan, Glenda, Crystal, john_kirkwood, Pietro, Katie_Haritos-Shea, MikeGower, Laura, MichaelC, Jan, JF, KimD, Rachael)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK


WARNING: Replacing previous Present list. (Old list: AWK, JakeAbma, Jan, Glenda, JF, kirkwood, Brooks, Wilco, Joshue108, Laura, KimD, MikeGower, Detlev, Katie_Haritos-Shea, David-macdonald)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK, JakeAbma, Jan, Glenda, JF, kirkwood, Brooks, Wilco, Joshue108, Laura, KimD, MikeGower, Detlev, Katie_Haritos-Shea

Present: AWK JakeAbma Jan Glenda JF kirkwood Brooks Wilco Joshue108 Laura KimD MikeGower Detlev Katie_Haritos-Shea
Regrets: Bruce_Bailey Makoto
Found Scribe: Wilco
Inferring ScribeNick: Wilco
Found Scribe: MikeGower
Found Scribe: gowerm
Inferring ScribeNick: gowerm
Scribes: Wilco, MikeGower, gowerm
ScribeNicks: Wilco, gowerm
Found Date: 17 Nov 2017
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.)