<alastairc> zakim start meeting

<AWK> +AWK

<Chuck> We are using zoom.

<bruce_bailey> scribe:bruce

<AWK> +AWK

<alastairc> scribe:bruce_bailey

<scribe> scribe:bruce_bailey

<alastairc> scribe: bruce_bailey

Starting in at 5 past the hour

AlasstairC: break in the middle

AC: review some Zoom UI controls

Custom interactions: https://www.w3.org/2002/09/wbs/35422/Custom_interactions/results

AC: extended meeting will be run as per usual meeting, just longer

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

<alastairc> https://docs.google.com/document/d/1ouVFq4w-i0rchNHtTAG_JoRwHfYm9mN2MkxFBct1JSI/edit#

<JakeAbma> example1: https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts

AC: started out as "standard interactions"

<JakeAbma> example2: https://support.microsoft.com/en-us/help/12445/windows-keyboard-shortcuts

<JakeAbma> example3: https://support.apple.com/en-us/HT201236

AC: basic idea is if you do something different than usual, that users are advised ahead of time

<JakeAbma> example4: https://support.microsoft.com/en-us/help/4531783/microsoft-edge-keyboard-shortcuts

AC: builds on autocomplete values (at end)

<LisaSeemanKest> can I have the link to the current text (sorry im late - couldnt find the link)

AC: questionnaire responses seem a bit dated. Jake?

Jake: We do not need to look at survey
... one challenge: How to define custom interaction
... too hard, so try and define "standard interaction instead"

<Chuck> Me too.

<ChrisLoiselle> lost zoom.

Jake pasted in four links

<Chuck> I didn't think that could happen with us being co-host.

break to reconnect

Jake review four example from MS / Apple / wikipedia

Jake: did not have time to finishing review in mobile TF
... look at what company's long list, they are pretty comprehensive, and a lot of possibilities
... only solution I see would be if this group comes up with a list that works cross-platform and cross-device
... Is that our purview?

<AWK> -1 to the idea of the WG coming up with the list of standard interactions. ARIA maybe.

Jake: Which ones would we decide are standard or not?
... Looking to group to ask if this is what we should be pursuing?
... even things like select -- can be enter or space -- things can be different

Lisa Seeman: Lots of operating systems define interaction for different types of devices, beyond html, apple , google, aria has custom controls for complicated interactions

scribe: Can we not say where the system has UI beyond what is defined by the platform?
... finite number of places where people need to check, maybe just three
... So we don't need to define and list, but can ask people for UI beyond those

Jake: Agreed, that is how we started this SC, but look at ARIA, they define user interaction pattern with arrow keys...
... but that is just a way it should work and not the only way it must work. For example, 3 taps could be hard, so PWD want an alternative to use tab key
... that is just a small example where the standard is just a should and not a must
... if look at larger group like browsers, they have lots of other standard interactions. Too many choices for people to implement.

AC: The core problem seems to be a customized interaction where people need instruction
... there are some very standard interaction, like tap a link
... others are odd, like swipe a tick, but lots of interactions in the middle
... for example, a dialog box, tapping outside the box closes the dialog. Is that to be expected? Is that a standard interaction?
... Non-standard interaction is a very difficult thing to define.
... Usability experts have examples of customized accelerators, but those might not be expected.

Jake agrees with AC characterization.

<alastairc> NN group article: https://www.nngroup.com/articles/ui-accelerators/

Lisa: Lots of people find the web unusable, so inclusion of this SC is still important and useful
... Could this SC be repurposed for long links and pop-ups?
... Maybe the three most common things people need. What needs to be done to make a doctors appointments?
... Avoid tabs and accordions and jigsaw puzzles... promotes a good design mindset
... We could do a quick survey of what controls three people encounter when making a doctors appointment.

AC: That would have been a good approach about 3-6 months ago.
... We need to get them into the draft, into the queue for review, and we only have a month or two now.
... Sounds like a common sense to do. But to achieve a reasonable benefit, need to regroup.
... Need to define "Unexpected Interaction."

Lisa: Can we add "link, buttons, options"?

AC: Not sure what that would look like.

Lisa: Use current wording, but limit it to custom interactions for, and list those those three things.

AC: What would be benefit if we cannot think of unexpected button behavior.

[noise sidebar]

AC: A lot of the unexpected had been around gestures and swipes, so hard to pin down to HTML elements

<AWK> zoom phone commands: https://support.zoom.us/hc/en-us/articles/201362663-Joining-a-meeting-by-phone

AC: links and buttons working in a standard way has not bee a focus of this criteria

Lisa: I see that it would take work.

AC: Anyone else to speak?

<alastairc> research needed? https://www.w3.org/WAI/GL/wiki/Research_needed

AC: Keep as a hook for future benefits. May be worth adding to research needed page
... this is about the 5th iteration.

RESOLUTION: Defer this SC

Dragging: https://www.w3.org/2002/09/wbs/35422/wcag22-dragging/results

https://www.w3.org/2002/09/wbs/35422/wcag22-dragging/results

<alastairc> Doc: https://docs.google.com/document/d/1LaVX-RTaLQL0tN4G3NhOTlmj16swt0VzC7ssaAjqIwg/edit#heading=h.mntlv4jvrc29

AC: Builds on pointer gestures from 2.1

<alastairc> SC text: All functionality that uses a dragging movement for operation can be operated by a single pointer without dragging, unless dragging is essential.

AC: Survey results mostly positive
... Chris McMeeking wanted mobile techniques, which have been added.

<alastairc> Implementations: https://docs.google.com/document/d/13QWLthBoEU6xuJQ4UrYOwuvJp0a42Z70JRjAsjtv1m4/edit#heading=h.uacsmsv3zr96

AC: I asked for more examples, which have been added.
... Good survey results which appear to have been addressed.
... This is AA which makes sense with single A version which is more narrow.
... Questions?

Jake: Detlev would like a response to his questions.

AC: Okay, Detlev would like a review of his techniques. Mike Gower at least has reviewed. Both techniques around the beginning of March.
... Seems like everyone comfortable so far. We don't need to review text on this call, but will before CFC.
... Please comment on understanding document and techniques.
... seeing no one on the queue?

<AWK> The failure technique would meet the existing SC, but that can be fixed.

AWK: Don't want to dwell on this, but title mentions dragging, but tests are not that narrow.

<alastairc> Agree to include SC in draft, pending understanding/technique updates?

AWK: needs clarification.

<JakeAbma> +1

<Chuck> +1

<Rachael> +1

AC: Do we agree to include, pending some examples?

<alastairc> +1

<AWK> +1 as long as the techniques are actually reviewed and updated

<ChrisLoiselle> +1.

AC: looking good
... Agreed, we need to get those reviewed.
... we will come back to this for follow up.

RESOLUTION: Include in the WCAG 2.2 draft, after understanding & techniques reviewed

Touch target spacing: https://www.w3.org/2002/09/wbs/35422/target-spacing/results

https://www.w3.org/2002/09/wbs/35422/target-spacing/results

<alastairc> Doc: https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit#

AC: This one has been updated a few time, David had a go at it and that inspired others

<alastairc> SC text: For each target that has a width or height of less than 44 CSS pixels, any dimension that is less than 44 CSS pixels has a minimum overall size (target size plus spacing between targets) of 44 CSS pixels except when

AC: has been somewhat simplified
... reads exceptions
... survey has 8 positive, 3 concerns
... Jake had question about layers. What that discussed?

Jake: Not resolved. And it is an important point for automated testing.

AC: Was it explained away?

Jake: No, and it need to be in SC. Only having it in Understanding is not clear enough.

<alastairc> Layers: If the target is part of additinal content (e.g. a drop-down), the targets from the lower layer are not in scope.

AC: Describes problems with overlays: on-screen content floats over other button content
... had same text, so if target is covered up, and not active, it could be an exception.

Jake: Think we we address this situation with new exception.

<alastairc> Re: Long List of Menu Items

Jake: Other bigger issue is longest menu items issue
... we want to add extra 8 pixel from where you start

<JakeAbma> https://www.amazon.com/

Jake: often touch wrong menu choice, we had long discussion as to what would be exceptable
... even w3c site has example with not enough space
... with Amazon example has list of links, like 20+, which fit on the screen on desktop...
... this is problem we are trying to fix. As Detlev described, the menus are available in the default desktop view...
... they fit all the links to fit on the screen at once without scrolling, but if we make bigger, will not all fit on a single screen.
... competing needs, users who need larger size and space, and users who want all the choice in one view port.
... Mostly problem with tapping wrong link is when there is a long list of choices like this.

AWK: Struggling with phrasing to understand what SC is asking for.
... okay, so requirement is 44 for short dimention

AC: Yes, previous version might encourage making original target size smaller. We settled for absolute size.
... Agree with trade-off Jake outline: having all choices available very important for many users.

<alastairc> "Menu Items: A list of more than 5 items in a navigation or toolbar;"

AC: Might be a bit arbitrary, but makes it more testable.

Chuck: The way I am reading how to test this: 1st step -- what controls are adjacent?
... So non-adjacent controls do not need minimum target size?
... Which way is this suppose to go?
... No minimum target size for buttons which are not near other controls?

AC: Correct, because small target without nearby controls are easy to hit

Rachael: This is important, since assuption was only adjacent controls.
... Is there a requirement for minimum size?

AC: At AAA we have 44 px requirement
... would allow 1 px target -- so long as 43 px to next target

Chuck: Intent was to get 44 px target size, so seems like there is disconnect between opening SC text and test procedure

AC: test has not been updated since SC was refreshed

<alastairc> AC: Could have a 1px by 1px link so long as it it more than 43px away from other targets.

Jake: Think it is okay, since by definition, there will still be 44 px spacing
... follows from margin, padding, clickable area

AC: If you have one tiny target not near anything else, it is clickable
... We asked for feed back from touch-screen manufacturers
... that is why this can be AA rather than AAA, because it is not an absolute size
... We will be asking for public feedback.

<AWK> Scribe: AWK

<bruce_bailey> [taking a break]

<alastairc> Please be back for 20 past the hour (12 minutes)

<ChrisLoiselle> One quick suggestion on the plain language definition is to describe what a touch target is , perhaps pointing to touch target vs. target definition in a glossary of the SC or main WCAG 2.2 glossary, currently talks to target :region of the display that will accept a pointer action, such as the interactive area of a https://www.w3.org/TR/WCAG21/#glossary

<ChrisLoiselle> but not specifically touch targets in the glossary definition, which is what is used in the SC name, and explanation etc.

/me I'm not

AC: Still on Touch targets
... talking about long menu items bit
... made sure that people understood that it isn't about size but/me I'm notspacing

<alastairc> q/

AC: Seems to be an issue around length of list
... making it testable

Jake: and do we want that exception
... companies with a particular info architecture that add space may find that the IA doesn't fit on the screen any more
... do we want to exclude these? Might be 80-90% of total use cases

AC: things like toolbars are most difficult is seems

Rachael: worth considering an exemption for items that have a redundant link that does have the spacing?

<LisaSeemanKest> not finding the google doc again :(

<Rachael> https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit?pli=1#

<LisaSeemanKest> thanks :0

AC: on the Amazon example there is a hover menu with a lot of links that don't meet 44px but if you click through to the page for the top menu and the same links on that page do - would that count?

<Chuck> my same point

<alastairc> AWK: For whole concept of conforming alternative versions, for Rachael's case I would have assumed passed this. CAV is on the same page. For most other SC that is how it works, e.g. for captioned videos with alternative on the same page.

<Rachael> The text from 2.5.5 is: Equivalent The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;

AC: if you had two images, one with alt text and one without, would we not fail the one without?

<alastairc> AC: two identical images.

Jake: Seems like a weak option - users are expected to look elsewhere before clicking on links?

AC: we could remove the exception and put it out for wider review
... get public feedback

CA: you are proposing removing 2nd exception for long lists?

AC: yes
... There are likely some implementation problems

<Zakim> AWK, you wanted to ask about drop down lists

<Chuck> AWK: For dropdown list, how does that figure into this? Most drop down lists do not have spacing between items, most cases not 44 px, just a line of text.

<Chuck> AWK: If you use a standard combo box within a form?

<alastairc> "Layers: If the target is part of additional content (such as a menu drop-down), the targets from the lower layer are not in scope for the targets on additional content;"

AC: We discussed adding an exception related to layers (above)

<bruce_bailey> I agree that default use of combo box should be allowed

<Chuck> awk: Would that not apply to Amazon's drop down menu>?

Jake: the layers seems different that what AWK is talking about
... for a select element the options would need to be 44px currently, may be an issue that needs to be covered

Rachael: Likes the layers bit in understanding rather than normative exception

AC: Not sure how we explain the issue that it is trying to address away in Understanding document
... Default drop down is not a problem on mobile but is on desktop
... do we need an exception for that?
... default form controls, perhaps?

<bruce_bailey> +1 for exception for default form controls

<JakeAbma> +1

<Chuck> +0 thinking about it

<Chuck> awk: This is going to be similar to discussion we had about authors needing to change... we have exceptions in existing sc where you are exempt because you are using a standard control.

<Chuck> awk: But you changed the background, non text contrast. You can use the default control and size the options to be larger. You can achieve on desktop.

<Chuck> awk: That would be more consistent if we have evidence that it's needed. Do we have such evidence?

<Chuck> awk: ... or if it's needed everywhere.

AC: so maybe we leave it as it is pending feedback?

Rachael: been looking at major sites without exceptions for toolbars/menus -does anything pass?
... seeing lots of issues with the heights

AC: ponders a fix the WCAG 2.1 left hand menu
... will likely be a ReSpec issue broadly
... Wilco had a few concerns around Touch target definition
... think all of his other comments have been addressed by SC updates
... my (AC's) comments have been addressed
... broad comment about feasibility is the main one
... Agree about including in draft?

<alastairc> https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit#heading=h.6u4xclqrczua

<alastairc> ^ updated

AC: .needs techniques completed and Understanding content also
... current version is under "Editing" heading

<Rachael> I am struggling with approving this without addressing toolbars, menus, and drop downs.

AC: this is a core conundrum

CA: Is this configurable by the user?

AC: that's complicated

CA: perhaps this should be recast to allow the user to change sizes without loss of content

Jake: responding to Rachael first
... if we took a look at the WCAG techniques site - the main problem is the left nav
... so if we except them then we are not addressing the user need
... but to respond to Chuck, zooming in does address the user problem to make the targets larger

AC: how would one fail this?

Jake: not having the 44px at the 100% size

<Chuck> awk: It is an interesting point. One way of thinking about this is when the text is small or the spacing is small, it is harder to click.

<Chuck> awk: When small, it is harder for low vision users to read things. We say we are not expecting every site presents itself with large text.

<Chuck> awk: for low vision user, we say you have to be able to increase the text size. For analgous situation, we say it is not agreeable to say you have to zoom in to make things bigger...

<Chuck> awk: Because you want to read easier or operate easier. I guess that is something we should be aware of and think of in this.

<Chuck> awk: If we start having the default view be the view that has all the functionality, we will run into problems all the time.

AC: we are pushing at interface characteristics that involve trade offs

<Chuck> awk: This is the old... a mechanism exists.

AC: If tied to ability to zoom or increase size, when would it fail?

<Chuck> just trying to scribe for you when you talk.

<Chuck> awk: it would fail in those circumstances where the user can't get to the 44 pixels.

<Chuck> awk: But it's not requiring that's the default.

AC: but we would need to get away from the 44 CSS pixels since the pixel sizes don't change

Rachael: in physical spaces there are two levels of requirements
... is there a secondary size that is not ideal?
... or maybe something around the total dimensions?

<bruce_bailey> +1 to ADA reference!

<bruce_bailey> path of travel

AC: if we took a 2/3 proportion
... any ideas?
... It does seem to be that horizontal menus and vertical lists that are the trickiest

Jake: we can tweak this but need to solve the user need

<Zakim> AWK, you wanted to ask can we get a reminder of the data behind this user need?

<Chuck> awk: Is this qualitative or quantitative?

<Chuck> awk: Where did 44px come from? Android and iOS don't do this for everything. What do we know for sure, and how?

AC: recall research of 100px on each edge was needed for some users

<ChrisLoiselle> https://www.w3.org/TR/WCAG21/#target-size

AC: trying to draw a reasonable line

<ChrisLoiselle> https://www.w3.org/WAI/WCAG21/Understanding/target-size.html and related resources

Jake: the 100 px was from the COGA TF
... there was research about 8px spacing
... more of a best practice than a "must" for them
... the number of 44/48 CSS pixels and 8px spacing

CA: goes back to "why are we doing this?" or "do we need this?"
... trying to giving users better experience without needing to zoom because....?

AC: think that one of the aspects is that if you struggle to hit small targets that pinch zoom isn't easy to use
... some sites/apps prevent zooms

<bruce_bailey> I understood need to be for people with 20/20 vision but poor dexterity.

Rachael: want to qualify my position
... this is important, want to see it
... have concerns but won't object to moving forward. Just expect a lot of comments
... what if we provide a mechanism bit?

Jake: not sure if we have this already
... SC to adhere to OS settings
... allowing zoom/pinch/etc

<Zakim> AWK, you wanted to speak to OS adherance

<Chuck> awk: I think that what... my understanding of what we tried to do is say "these are the things you need to do", and depending on what's going on in the o/s

<Chuck> awk: you might be more readily supported or you might need to do things differently. When we were doing text resizing in wcag 2.0 not all browsers supported text resizing.

<Chuck> akw: The idea was that people could add a widget that enables a different view. That is partially enabled by the conforming alternate versions concept.

<Chuck> awk: The hope was that there would be improved support for it. We should figure out what is needed for the users, make sure it is well supported with research...

<Chuck> awk: And allow a variety of mechanisms to allow this to happen. If zooming works for the user, we have to figure out if that's ok. If the user need is solved...

<Chuck> awk: by copying url, pasting in url in another browser, we would not allow that.

<Chuck> awk: I think we've avoided saying meet the o/s requirements. maybe more in silver.

<Zakim> alastairc, you wanted to see if there's a personalisation version?

AC: Not so much allowing user OS settings
... was wondering if, building on Rachael's comment, around allowing zooming to make targets larger...
... zooming in, target sizes don't shrink (?)
... what we would really like is to say "have a mechanism to allow the users to view targets at a certain size"

<Chuck> yep

AC: We could make this into a "mechanism" SC and get difficult feedback
... or put it through as is and get difficult feedback

<Chuck> - 1/10 going wider review as it stands.

AC: Any one not comfy putting it out as stands?

<alastairc> Pointer target spacing: @@@A mechanism is available@@@ so that each target that has a width or height of less than 44 CSS pixels, any dimension that is less than 44 CSS pixels has a minimum overall size (target size plus spacing between targets) of 44 CSS pixels except when

<bruce_bailey> As proposed, requirement is pretty straightforward

<bruce_bailey> zoom not being acceptable, is pretty subtle

Of course, if we think that zooming is a way to meet the user need 1.4.4 Resize text covers most of the targets

GN: Doesn't think that zooming really addresses the user needs

<LisaSeemanKest> +1

<bruce_bailey> +1 to mechanism being an exception

<LisaSeemanKest> unless a mechanisim etc...

<bruce_bailey> i feel like CAV is different than "a mechanism is available"

<Rachael> In 2.1.4 we don't label it by mechanism but by what it does: Remap A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc);

Bruce: thinks that this version of mechanism is available isn't really about CAV

<Chuck> +1!

<alastairc> Resize: A mechanism is available to change the size of all targets so that the width and height is at least 44 CSS pixels;

<bruce_bailey> still disallows zoom

No, you can't use zoom

<bruce_bailey> this would be a requirement for the author to provide feature

Because zoom doesn't change the CSS pixel size/space

<Chuck> I won't object to going forward, but still not comfortable.

<Chuck> +0

AC: Are people happy with a wider review?

<bruce_bailey> doubling UI size seems less important to me if starting size is 44 px

<Rachael> I am comfortable with it in this form going out knowing it will get comments.

<Chuck> +0

+.5

<LisaSeemanKest> +1

-.3

<bruce_bailey> +0 think we should work on this a bit more

:)

AC: if not getting a positive response we are effectively deferring this one

<LisaSeemanKest> strong +1

<bruce_bailey> i think we are very close and could finish it

AC: suggest that we have a version that we can share with the group at 11am Boston time tomorrow

RESOLUTION: Leave open

<LisaSeemanKest> thank u

<JustineP> Talk to everyone in a bit.

<alastairc> NB: Leaving this meeting open to gather in the later meeting.

<Chuck> chair: Chuck

<PeterKorn> I think I'm not in the right WebEx room; I seem to be alone (other than Katie)

<alastairc> https://www.w3.org/2017/08/telecon-info_ag-ftf

<alastairc> Peter - link above

<Ryladog> problem geeting in to webex

using zoom, review/preview

<Chuck> https://support.zoom.us/hc/en-us/articles/205683899-Hot-Keys-and-Keyboard-Shortcuts-for-Zoom

<kirkwood> CharlesA: keboard shorcuts for zoom

<kirkwood> … might need to unmute to respond to questions

<kirkwood> CharlesA: second of two calls today, we did review of touch target spacing and interactions

<kirkwood> … this call focused on Silver

<bruce_bailey> Support page does not mention mute/unmute: Alt-A

<CharlesHall> webex failing to connect

It is in there

<kirkwood> … Jeanne will be talking about results of survey and norm vs informative

<kirkwood> … longer than an hour than 10-15 minute break

<kirkwood> … conformance questions might be saved for second session

<kirkwood> … tomorrow fist call wcag 2.2

Changes to ED draft in response to the pre-CSUN survey

<jeanne> https://raw.githack.com/w3c/silver/ED-VF2F-js/guidelines/

<kirkwood> Jeanne: sart with link to latest branch on editors draft

<kirkwood> Jeanne: went into f2face with useful comments, largely normnintive versus informative

<kirkwood> … reviewed changes in editors draft in response to pre csun survey

<kirkwood> … revised abstract and inroduction. scope taken directly from charter

<kirkwood> … in guideline added a table on how content maps from wcag 2 to wcag 3

<kirkwood> … the SC become guidelines the understanding becomes how to, techniques become mehtods which includes tests

<kirkwood> … guidelines are tech nuetral

<kirkwood> … added clarification on what is normnative and whats informative

<kirkwood> … reorganized conformance section

<kirkwood> .. made introduction more clear

<kirkwood> Jeanne: simplified scpe, confrmance claim, accessibility suppported

<kirkwood> Jeanne: simplified scope, conformance claim, and accessibility supported

<kirkwood> Jeanne: allowed to claim a scope that is a logical subsection

<kirkwood> … will see through scoring example tomorrow

<kirkwood> Jeanne: for sampling we are referencing WCAG EM rule

<kirkwood> … minor clarification to point some levels for scoring exmaple

<kirkwood> … those changes due to comments

<kirkwood> Jeanne: anyone who was at silver face to face already heard it

Results from VF2F

<jeanne> https://www.w3.org/WAI/GL/task-forces/silver/wiki/2020_March_F2F_Meeting_at_CSUN#Results:_Presentations.2C_Documents.2C_Minutes

<kirkwood> Jeanne: link to all of the minutes, wrote a summary of all days so don’t have to read all in detail

<kirkwood> … summary for each day

<kirkwood> … Monday reviewed scoring example

<kirkwood> … gave homwork to do real website

<kirkwood> … afternoon we individually look at pros and cons

<kirkwood> .. we will go through that exercise

<kirkwood> on tuesday we reviewed home work and alternative documentws

<kirkwood> … bruce wrote a scoring mechanism and we reviewed it link to proposal:

<kirkwood> Jeanne: talked about pros and cons and agreed we need to test

<bruce_bailey> https://docs.google.com/spreadsheets/d/1G0KLv1Nfvy5QWN7t9jPxyE6UEcTHE5A8tKYiDOhuZRY/edit#gid=1833982643

<bruce_bailey> Adjectival Rating strawman

<kirkwood> … Foliot wrote proposal about headings and how to give partial conformance scoring

<kirkwood> Jeanne: its been very useful and shows importance of testing

<kirkwood> JF: i’ve been working on those tests, trying to clean up presentation layer, trying to show contrast and hope to have done later on today

<kirkwood> Jeanne: wanted to review work done since, the face to face some done on friday, can see on editors draft i gave you

<kirkwood> Jeanne: screen sharing now

<kirkwood> Jeanne: for those looking at it go to editors draft in irc go to headings

<kirkwood> … you will see under guidleines you will see fucntional outcomes

<bruce_bailey> https://raw.githack.com/w3c/silver/ED-VF2F-js/guidelines/#headings

<kirkwood> … you will see three

<jeanne> Text is organized into logical chunks to make locating information easier and faster.

<jeanne> Semantic structure is provided to support reading -- headings are coded as headings.

<jeanne> Headings are visually distinct so sighted readers can determine the structure.

<kirkwood> … text organized into organized chunks… in irc here:

<kirkwood> … locating, support reading and determining structure

<Chuck> yes, I see it.

<kirkwood> … click on headings, go to evaluate, took testing and adapted to functional outcomes

<bruce_bailey> https://raw.githack.com/w3c/silver/ED-VF2F-js/guidelines/explainers/SectionHeading.html

<kirkwood> … it is how to and informative

<kirkwood> … ensure text logical chunks

<kirkwood> … semantic structure

<kirkwood> Jeanne: we started looking at headings and started looking at it limited perception etc.

<kirkwood> Jeanne: know there are flaws funtional needs list need to start that but not today

<kirkwood> JF: difference between adding to the list rather than changing, like to see those specific functional requirments added

<kirkwood> Jeanne: thats separate discussion

<bruce_bailey> FPC lists are the same for 7 of 9 categories

<kirkwood> AWK: normnitive or non nuormative?

<kirkwood> Jeanne: beige section is, the green sectiions is informative

<kirkwood> AWK: so pink is normative

<kirkwood> Jeanne: correct

<kirkwood> Jeanne: we are looking at evaluatetab

<kirkwood> Jeanne: ensuring semantic structure for limited vision, usage for limted vision. we need coga recommendation on more usable breakdown on needs

<kirkwood> Katy: whats cool about his this is like the context

<kirkwood> Katy: limited vision like bright sunlight can use the ocmbination of groups and context than its interesting

<kirkwood> Katy: this is looking so much better

<kirkwood> Jeanne: this becomes a feed into scoring system

<kirkwood> … gives abity to customize scoring

<kirkwood> Jeanne: based on example of basic method template

<kirkwood> … go to test tab

<kirkwood> … this is where we started to integrate ac test rules

<kirkwood> Jeanne: we link each one to an ACT rule where we had them

<alastairc> I think it's this one: https://raw.githack.com/w3c/silver/ED-VF2F-js/guidelines/methods/Headings-HTML.html

<kirkwood> Jeanne: next we took examples John gave, the first is coded correctly

<kirkwood> … at bottom gave exmple of e3ach of 7 fucntional requirments and whats in there

<kirkwood> … gave examples of different kinds of mistakes

<kirkwood> … showed impact of looking correct on functional requirements

<kirkwood> … he wene through each of them

<kirkwood> … now want to take John’s work and to give actual scoring

<kirkwood> … this is the work we did Friday

<kirkwood> … going to take this entire tab and make technology neutral and move to the How To

<kirkwood> … wanted to cover AI and long text such as insturcitons and legal. know there are going to be examples of non web included in WCAG 3. even if don’t have test for that technology yet

<kirkwood> … questions?

<kirkwood> JF: if you go to test heading i refreshed it

<kirkwood> JF: I’m putting in tables so we can do a visual review as well

<CharlesHall> @JF, this is awesome

<kirkwood> Wilco: how does the testing piece fit in?

<kirkwood> JEanne: devil is in the details

<kirkwood> Jeanne: we have tests, ACT rules under individual tests, if something passses ACT test it passes that functional outcome

<kirkwood> … scoring is based on how many functional outcomes ar met or how well the needs of people with disabilities are met

<kirkwood> … we are working on it now will talk in more detail tomorrow

<kirkwood> Wilco: back to scoring, has these five items what are these pieces

<kirkwood> Jeanne: work in progress

<kirkwood> Wilco: i get that

<kirkwood> Jeanne: JF gives us one goood and three bad. all h1s visula styling, 11 had aria role no level and other exmaples. we working on this on friday

<kirkwood> Wilco: trying to get scores from different results of tests?

<kirkwood> Jeanne: yes

<kirkwood> Jeanne: how you met each needs of people with disabilites when divide by groups , more comples that j

<Zakim> bruce_bailey, you wanted to ask if this example has scoring for not skipping levels, e.g., no H3 without an H2 ?

<kirkwood> Bruce: sounds like not just super strict heirarch

<kirkwood> Peter: do you have an idea of how to give credit for going above an beyond

<kirkwood> Jeanne: its a discussion to talk about tomorrow

<kirkwood> Jeanne: its hard to report with things not written down

<kirkwood> Peter: similar question will hold. understanding how much headings are needed to effectively use this page

<kirkwood> … look forward to that in scoring

<kirkwood> Brooks: thank you for sharing

<jon_avila_> I agree with Peter -- the context of the issue is important for impact on user

<kirkwood> … like what i see

<kirkwood> Brooks: if technolgy neutral might want to show labeling guidelines not so much rooted in html. such as heading and a vr map

<kirkwood> … other issue that comes to mind is the idea of coming to consensus of things going wrong with a particular guideline.

<kirkwood> … seeing how goes wrong based on technolgy and come to agreement on that

<CharlesHall> +1 to Brooks point on cautious terminology

<kirkwood> Jeanne: interesting idea

<kirkwood> Jeanne: we probably do want a broader term than headings. would be grateful if sent to list

<bruce_bailey> +1 for better word than "heading" !

<kirkwood> Jeanne: all the things that could go wrong talked about briefly and convert to technology neutral language. that was our goal to take list of mistakes generalize it and move to how to, to give score on all partial things can do

<kirkwood> … so this is score without understanding all underlying things take to give percentage to plug into tool on how to give soore

<kirkwood> … we need to look at ll details for everything that goes into it and show it so lawyers can see etc

<kirkwood> … we talk about it, want ot give simple table

<kirkwood> … and so tool manufactures can do it

<kirkwood> Lisa: not sure what type of feedback you are looking for, but headings and that s an important place to put plain language

<alastairc> I'd love a better word than "headings", but we'll may well end up with a more neutral (but less understandable) term.

<kirkwood> Lisa: and if can put a symbol for direction of cognitive accomodation perspective

<kirkwood> Lisa: semantic structure is not the same thing not seeing clear language under those three

<kirkwood> Lisa: functional oucomes form coga persopective could be more detailed

<kirkwood> Lisa: could you send functional requirments from coga perspective, language, attention etc really well worked out

<bruce_bailey> I think this is clear language criteria:

<bruce_bailey> https://docs.google.com/spreadsheets/d/1G0KLv1Nfvy5QWN7t9jPxyE6UEcTHE5A8tKYiDOhuZRY/edit#gid=1247728755

<kirkwood> Jeanne: my bad haven’t gotten to it yet will send a detailed list to you

<kirkwood> BB: jeanne can double check url put in

<kirkwood> … right now 508 and anl311 they have cognitive language in one bucket

<kirkwood> LS: funtional requirements can map to user needs if helpful, we hsould pass and see what would be a pin pointed action that would help

<kirkwood> Jeanne: instead of looking at ours, might be more useful from approach of regulator, here is the high level breakdown

<kirkwood> Jeanne: we can’t overwhelm the seven

<kirkwood> JEanne: we need to add vastibular disorders

<kirkwood> Jeanne: clearly needs gto be broken down may be to three

<kirkwood> LS: lets break down and merge it

<kirkwood> LS: lets not worry about number yet

<kirkwood> LS: lets get them and worry about how we merge

<kirkwood> JEanne: not easy task will send everything might find useful

<kirkwood> Jeanne: as you think about these tomorrow we will work through scoring example and hopefully you will see how its going

<kirkwood> … as you see in every part of conformance devil is in details

<Zakim> alastairc, you wanted to ask about the categorisation updates (compared to 2.x) and importance

<kirkwood> Alistair: vaious ways of categorizing guidelines

<kirkwood> … wondring if conscious level of granularity you are aiming for

<kirkwood> … could categorize by disability, was conscious decision?

<kirkwood> sorry could someone take over scribing??

<kirkwood> sorry

<Detlev> Sorry for being late and missing this morning's meeting

<kirkwood> Jeanne: this is overall plan

<kirkwood> … for each guideline we have a list of tags

<bruce_bailey> i think POUR become tags

<kirkwood> … we also have ones meta level, such as things related to plain language use of color etc. so can pull up in a variety ways rather than just tages of perceivable operabel robust

<kirkwood> Alistair: in some ways a primary way of doing

<kirkwood> … if thats on purpose to see what others can merge tin that way. taking the ones from2.x set and refining. thats sounds like working from current and refing rather than a set structure

<kirkwood> Jeanne: could you give an exmaple

<kirkwood> Alistair: primary such as heading, contrast, that structure is 2.x refined other way is by functional requirements

<bruce_bailey> we only have 3 GL atm, so org is less critical

<kirkwood> … you ve answered my question, ri thinkit is refinement approach

<kirkwood> Jeanne: a good idea

<alastairc> scribe: sajkaj

alastairc-web:

<scribe> scribe: sajkaj

ca: Resuming ... Alastair's continuing comments will end this topic and we'll move on to our remaining agenda ...

ac: Thinking about a better articulation ...
... The middle layer in our wire is rather arbitrary
... Considering expanding our approaches probably good -- we need to encompass more than 2.x allowed, like COGA

js: We've always thought in terms of two content buckets: 1.) Content we're migrating from WCAG 2.x; 2.) New Content
... So our exercise has been to try and take an even more global view

<Brooks> q_

js: Spending some time on that kind of broad analysis would be valuable

Normative / Informative

<LisaSeemanKest> I am availible now and the first session tomorow,

<LisaSeemanKest> second session tomorow is a bit late....

js: Onconcern from the survey looked at what should be normative, and what informative

<jeanne> https://docs.google.com/document/d/1QF5Olq8880_OmP0Eyr7CmFti5O1VIFUXPhguA6DFzlE/edit#heading=h.i4oqd63l9ktf

<jeanne> https://docs.google.com/document/d/1QF5Olq8880_OmP0Eyr7CmFti5O1VIFUXPhguA6DFzlE/

js: Our approach has been to look at the several individual pieces making up the Silver wireframe in the attempt to determine which should be normative, and which informative
... We did not reach completion during the Silver F2F
... We found no official W3C definition of normative
... There's guidance that clearly noting which is what is important in a standards document
... We fall back on the IETF's RFC2119, and that's as far as we got
... Suspect we should set that aside for now

<alastairc> "required for conformance"

ac: Notes that WCAG has it's own definition

js: Yes, that's about all anyone ever says, it seems

<jeanne> Cons: Too difficult to maintain because it requires a dot-update for any changes

<jeanne> User needs are not required. They are what we are trying to address

<jeanne> If everything is normative, it excludes other user needs.

<jeanne> Editorially, it would be extremely time-consuming to write that much normative text.

wilco: What does 'user needs' mean?

js: I should probably explain our process ...
... For every guideline, whethe rmigrated from WCAG or new in Silver, our starting point was to analyze the user needs of pwds
... Those user needs then took us to tests, and to the howto's, the methods of meeting them
... The activities by role, plan design, etc
... Then our last step was drafting the actual guideline -- which is why they're still so rough. They're the last thing we did
... Going back to normative/informative ...
... Suspecting making everything normative would not work, and that people would easily agree on that
... Making user needs informative seemed obvious; as new needs were identified our spec would then need upversioning

<Zakim> Just, you wanted to note the definition from WCAG https://www.w3.org/TR/WCAG21/#dfn-normative

<LisaSeemanKest> https://raw.githack.com/w3c/coga/master/content-usable/index.html#user_needs

ls: Want to check that Silver has been evaluating COGA's user needs?

<Zakim> LisaSeemanKest, you wanted to say look at https://raw.githack.com/w3c/coga/master/content-usable/index.html#user_needs

<LisaSeemanKest> https://raw.githack.com/w3c/coga/master/content-usable/index.html#user_needs

js: I know Rachael has kept us informed, but I don't recall we walked through them systematically
... Our focus has been getting to FPWD before doing these in more detail

ca: Looking at Wilco's comment that making everything normative would just be too slow ...
... Any update would require intensive work to update the standards guidance

jd: Other reason it would slow things down is that the government policies depending on WCAG would be slowed down

ls: Notes that COGA has been working hard to cross collect across etc, other orgs

<LisaSeemanKest> https://raw.githack.com/w3c/coga/master/content-usable/index.html#user_needs

<LisaSeemanKest> trying to push it to tr as a itrative working draft...

<LisaSeemanKest> sorry it takes so long

js: So we started with pros and cons of making user needs normative ...

<jeanne> Pros

<jeanne> Meeting the needs is what we are trying to do, so meeting the need should be normative. More of a functional outcome. individual needs should not be normative, but the collection of needs - the functional outcome - should.

<LisaSeemanKest> +1 to normative needs

js: If normative, some need that was ommited -- it would be too hard to add it in

<jeanne> Cons

<jeanne> Some user needs would be left out, and therefore it would formalize that some user needs would be left out.

<jeanne> what the user needs to experience or what they would need to do... we had trouble defining how the user would experience it.. that info is too broad to list.

<jeanne> More difficult to maintain. We want to keep Silver maintenance achievable.

<jeanne> Editorially, it would be extremely time-consuming to write that much normative text.

gn: Believe it is logical to make normative that which is used for measuring
... User needs aren't that

ac: Not sure what a measure would be on a user need

gn: Yes, I meant this is a con
... User need explains, motivates, but does not measure and shouldn't be normative

js: Next section was activities, planning, designing, etc
... Certain parts might be normative ...

<jeanne> Pros

<jeanne> A generalized statement that evaluation is required could be normative

<jeanne> Certain parts could be normative if they were how you test the guideline. But that will vary by how you test it. For example, in Clear Language, the Write tab might be normative. In others, it might be the Evaluate tab. It could be repeated from elsewhere or another mechanism.

js: On a case by case basis we need to support alternative ways that content authors might meet the need
... We don't want to be overly perscriptive
... Only the outcome should be normative

<jeanne> Cons: Case by case activity is normative can be not-positive.

<jeanne> There could be many other ways that the author could meet the user need and that other way would not be conformant because it isn’t listed.

<jeanne> It could be interpreted that we are dictating what the activity life-cycle is supposed to be.

<jeanne> Not everyone will have these activities, or will have them in much greater detail.

<jeanne> Only the outcome should be normative.

<jeanne> Editorially, it would be extremely time-consuming to write that much normative text.

js: Notes we did cover pretty thoroughly in the Silver F2F
... Next we went to tests ...
... We quickly learned two types of tests ...
... There are task testws and conformance tests

<jeanne> Pros

<jeanne> W3C can now allow 18-24-month cycles, so that updating the tests would not lag far behind the technology

<jeanne> Technology-specific guidance is easier to understand.

<jeanne> Cons

<jeanne> Rapidly changing technology means we need to be able to add tests without having to make a dot release of WCAG 3.

<jeanne> Validation methods to normative would still be more time-consuming than normative.

<jeanne> We would have to review the tests and re-validate them each time, which would be very time-consuming

<jeanne> It would be less stable to have normative tests be removed.

<jeanne> In a WCAG 2.x technique, the steps of the test are required (for the technique), but the test itself is not normative (since the techniques are not normative).

<jeanne> Maintenance of a Rec Track Format is tedious for something that should stay light-weight and easy to update so that we can keep them up-to-date. It also puts a lot of responsibility on other member groups to review them before they become normative. Mistakes can be easily corrected. Many concerns about technology specific tests becoming normative.

<jeanne> We will need people with expertise in the technology to be able to update the test with a pull request. It cannot all be done by the Working Group.

<jeanne> Searching for something normative in normative language is a lot harder. Informative text is more understandable and searchable.

<davidmacdonald> Validation methods to normative would still be more time-consuming than <add>non</add>normative.

<Chuck> q/

df: Wondering whether something between is missing?
... Not sure why a level we already have would be missing

js: What's missing? I'm not understanding

df: Looks at task based and tech specific tests ... Conformance as it stands isn't tech specific
... Don't believe there's any good reason to change that

js: We can combine things in various ways

df: Perhaps I'm not understanding the approach

js: We're trying to cover everything systematically and decide item by item whether it should be normative
...

Certainly, imo, some are clearly informative

js: But things will get moe subtle as we move on in this analysis
... We're trying to think it through from the ground up

ca: We wanted to start explaining this to AGWG from the ones that are pretty obviously normative or informative just to get us going

<KimD> Pros:

<KimD> If there were a specific technology that was specifically weak (like Flash) it might make it easier to include or exclude that technology. (for example) We could have a (higher level) test that applies to Flash.

js: We also looked at higher level task tests ...

<KimD> Some guidelines (like avoid flashing [that can induce seizures]) could be written in a way that would be stable and could be normative.

js: Some tech tests build up to where the user need is met
... Some may expose poor coding

<KimD> Cons:

<KimD> If the spec doesn’t apply to the normative (but strictly narrow) technology, then it is easier for authors to say that it could never apply. If we have normative tests, then we could be restricting new technology or innovative solutions to address user needs. (Example: historical requirement to have a keyboard [in addition to touchscreen] -- would have precluded iOS approach of making touchscreen directly accessible.)

<KimD> You may have met the user-need, but you may not have used the normative test.

<KimD> Task Completion tests or higher level usability tests are not conducive to normative tests.

js: Making tests normative wouldn't allow technology to improve and meet user needs
... Task completion tests aren't conducive to normativity

dm: Are we still planning on tech specific methods?
... Worried we may not have enough for a meaningful standard if only the guidelines are normative
... Wondering how that conversation went

js: Important to know that guidelines are tech neutral and methods are tech specific

dm: Notes 2.x has techniques which aren't tech specific
... So I'm a bit confused

js: Next will be methods, can we hold?
... And you are correct.
... When we started writing clear language we came to some methods would be general and possibly normative

dm: Believe about 100 general techniques?

df: Want to understand "task based"
... Steps the user goes through? Is the flow of the form understandable? Can I reach my goal?

<davidmacdonald> 217 General techniques in WCAG 2.x https://www.w3.org/WAI/WCAG21/Techniques/

df: How does that relate to specific tech that's weak like flash

js: If we made user research testing normative it mightsupport gaming the system

<bruce_bailey> Maybe about 200 general techniques!

<bruce_bailey> https://www.w3.org/TR/WCAG20-TECHS/general

js: One might build tests that could show a weakly supported tech actually working

<bruce_bailey> (sorry, not sure what 2.1 url is)

df: wondering about separating guidelines and some of the rest around specific tech
... Is this decided?

js: No

<alastairc> 2.1 general techniques https://www.w3.org/WAI/WCAG21/Techniques/#general

js: It's a way to approach the discussion of what we need
... There are many parts to this, so we need to spend time discussing and considering
... After we analyze the different parts, it will give us a draft approach that we can then evaluate further
... We're in an exercise of evaluating each and every piece
... We added a piece to evaluate for functional outcomes, though we didn't actually get there

jf: This reminds me of something Bruce brought up ...
... The cognitive walk through
... testable, measurable, repeatable needs to be what is normative
... So that different people get the same results
... But we want to get away from pass fail, but it seems we're not clear on how that fits
... Keep thinking of how this contributes to scoring

js: They do come together, but it's probably useful to continue this walk through ...

jf: I'm starting to recognize a second category of requirements that may need to be scored differently

gn: I want to support only outcomes being normative
... Important to allow tech development to more easily meet user needs creatively

<Zakim> alastairc, you wanted to say that I'm the person who mentioned flash and...

ac: If we have a tech that doesn't provide something intrinsically important -- phps headings -- that should be reflected in the scoring
... I believe "normative" is what we ask people to do\
... Could be any of a number of things

ac; metrics, a procedure to follow, etc.,etc

ac: So normative can still e quite flexible
... "must only" or "must and should"

<bruce_bailey> +1 that quote normative unquote can be flexible

<JF> +1 to MUST and SHOULD ;-)

<bruce_bailey> not that I think it would be a good idea !!!

ls: Wanted to say something similar actually ...

ac: So, it may be the process that defines conformance -- there are different ways

ls: in different industries there are different ways to meet user needs

<GN015> In fact, technologies might change. They might improve, they might have regressions. It is hard to keep track.

ls: in finance the outcome is the goal of the entire process -- so there it's more user needs

js: Want to clarify
... We should test outcomes?

ls: no, needs can be normative ...
... not getting hacked is key in finance as an example
... need to allow for hugely different ways of getting things done

js: Very helpful! Thanks

<Zakim> bruce_bailey, you wanted to give high level normative requirement from FCC on caption quality -- that is not very testible

bb: Like John's reliable, repeatable, it's beyond other normative reqs
... Have an example from FCC re captioning

<bruce_bailey> Legal requirement is accurate, synchronous, complete, properly placed.

bb: There are always lawsuites ...
... But all the reg says is quite simple, and no math test for the four criteria of captioning: accurate, properly placed ... ...
... What do we want normative to mean is the question for us

wilco: Feel we're missing a piece ...

<bruce_bailey> Here is the FCC example:

<bruce_bailey> https://www.fcc.gov/consumers/guides/closed-captioning-television

wilco: Normative is whatever is part of the standard, the thing we collectiviely agreed is part of the standard
... If 3 relies on methods; then methods must be normative; you need these to prove you comply
... See no other way

<LisaSeemanKest> +1 to wilco

<kirkwood> +1

wilco: Believe we're coming at this from the wrong direction
... What is required to prove something conforms, what ever that is, that has to be normative
... We can have issues over how flexible this is, ... that's the process ...
... but there's also the notion of a living standard to address this
... We need normative to reflect what we need in the standard; not on how hard something is to update

<kirkwood> ageed with Wilco’s point

<Zakim> alastairc, you wanted to say that I agree with having more than 'must' items, but would like to score differently.

<CharlesHall> i have a hard stop but do not object

ac: kind of agree of more than must items and binary, but if process oriented things to do; they might be scored differently or not considered part of the baseline
... agree it's a continuum

<Zakim> AWK, you wanted to say that the FCC rules also do specify very specific technical criteria for the ability to display captions. Speak to Bruce's point.

<bruce_bailey> Example: Accurate: Captions must match the spoken words in the dialogue and convey background noises and other sounds to the fullest extent possible.

awk: WCAG does the same for captioning as FCC
... we want to do as much as we can
... But a lot of qa is required on captioning
... we might set a normative standard that isn't auto testable, but objectively testable and needn't be 100% right all the time, though that's the goal

gn: looking atsc were sufficient but not needed to fulfill sc -- so shouldn't be normative

jf: Agree 2.x has some problems because of the binary
... disagree that rank scores makes the conformance even more important -- whatever the cutoff number
... Think we're going a bit off course
... Anything that is used to be said "I'm in cconformance" needs to be measuarable and require some minimal score

js: Happy with this discussion of the normative and look forward to continuing it
... We're obviously not at consensus yet, so will consider next steps with the Chairs
... Thanks, everyone!@

<JF> http://john.foliot.ca/demos/HeadingsTestStart.html

jf: Notes additional changes in this URL

js: Thanks John

ca: Thanks all, will meet againtomorrow!

<kirkwood> well done Chuck

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/hours/hour/
Succeeded: s/present + Gundula/present+ Gundula/
Succeeded: s/geasturs/gestures/
Succeeded: s/targe/target/
Succeeded: s/ //me I'm not/
Succeeded: s/AC: (volunteers to fix the WCAG 2.1 left hand menu)/AC: ponders a fix the WCAG 2.1 left hand menu/
Succeeded: s/shnages in editors draft i9n/changes in editors draft in/
Succeeded: s/base setion/beige section/
Succeeded: s/ tabe/tab/
Succeeded: s/fules/rules/
Succeeded: s/sympbol/symbol/
Succeeded: s/breqakdown/breakdown/
Succeeded: s/jsNo/js: No/
Succeeded: s/1005 right/100% right/
Default Present: alastairc, Chuck, MichaelC, AWK, bruce_bailey, JakeAbma, Rachael, ChrisLoiselle, LisaSeemanKest, JustineP, .5, stevelee, sajkaj, kirkwood, KimD, Brooks, jeanne, Jennie, Katie_Haritos-Shea, Laura, PeterKorn, CharlesHall, jon_avila, Detlev, GN

WARNING: Replacing previous Present list. (Old list: alastairc, Chuck, MichaelC, bruce_bailey, JakeAbma, Rachael, ChrisLoiselle, Gundula)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ alastairc, Chuck, MichaelC, AWK, bruce_bailey, JakeAbma, Rachael, ChrisLoiselle


WARNING: Replacing previous Present list. (Old list: alastairc, Chuck, MichaelC, AWK, bruce_bailey, JakeAbma, Rachael, ChrisLoiselle, LisaSeemanKest, JustineP, stevelee, sajkaj, kirkwood, KimD, Brooks, jeanne, Jennie, Katie_Haritos-Shea, Laura, PeterKorn, CharlesHall, jon_avila, Detlev)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ alastairc, Chuck, MichaelC, AWK, bruce_bailey, JakeAbma, Rachael, ChrisLoiselle, LisaSeemanKest, JustineP, stevelee, sajkaj, kirkwood, KimD, Brooks, jeanne, Jennie

Present: alastairc Chuck MichaelC AWK bruce_bailey JakeAbma Rachael ChrisLoiselle LisaSeemanKest JustineP stevelee sajkaj kirkwood KimD Brooks jeanne Jennie Katie_Haritos-Shea GN015
Found Scribe: bruce
Found Scribe: bruce_bailey
Inferring ScribeNick: bruce_bailey
Found Scribe: bruce_bailey
Found Scribe: bruce_bailey
Inferring ScribeNick: bruce_bailey
Found Scribe: AWK
Inferring ScribeNick: AWK
Found Scribe: sajkaj
Inferring ScribeNick: sajkaj
Found Scribe: sajkaj
Inferring ScribeNick: sajkaj
Scribes: bruce, bruce_bailey, AWK, sajkaj
ScribeNicks: bruce_bailey, AWK, sajkaj

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)