See also: IRC log
<Joshue108> (Length: up to 90 minutes)
<Joshue108> Attendance survey: https://www.w3.org/2002/09/wbs/35422/WhenWCAG
<Joshue108> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List
<Joshue108> Github issues questions (Survey) https://www.w3.org/2002/09/wbs/35422/17thMay2016/
<AWK> +AWK
<alastairc> +alastairc
<Joshue108> +Joshue108
<AWK> Scribe: Mike_Elledge
<AWK> Chair: Joshue
<KimD> +KimD
AK: Sean new person, welcome, instructions to signon
sean: Run accessibility meetup in New York. Work on Google docs as engineer.
Rochelle: From Mitre.
SteveRep: Work for Boeing. Engineer, do programming. Understand accessibility as person who is vision impaired.
Josh: TPAC registration is open.
Get hotel rez soon, books fast.
... Remove extra "
ak: Last week shared proposal for moving ahead. Chartered to do taskforces and work toward extensions. Also future guidelines. Shift from publishing extensions separately to those that will become part of wcag 2.1.
<SarahHorton> https://www.w3.org/WAI/GL/wiki/Main_Page/WCAG_future_proposal
<Joshue108> https://www..w3.org/WAI/GL/wiki/Main_Page/WCAG_future_proposal
ak: put this out to list, had on last week call, so far agreement. No objections. Now need to build add'l support for re-chartering. Member process for review. Socialize the idea widely, also proceed on our work. Work will prove our point.
<Joshue108> s/https://www..w3.org/WAI/GL/wiki/Main_Page/WCAG_future_proposal/
ak: Doesn't mean much different today. Need to think about 2.1 success criteria. Task forces will continue (mobile, low vision) but also need to coordinate, so no overlap.
<Kathy> what are the dates again for that?
ak: TFs should harmonize their
work. Around September will have more info to work on,
conveniently in Portugal at TPAC. Our mtg there will be busy.
Come if you can, phone connection as well, but more
difficult.
... Josh and I have been collecting feedback, will start to
chart out more specific actions to do with group to
proceedd.
Sarah: Proposal sounds good. How to do harmonization. One of biggest challenges is ensuring that what we pub is coherent.
<AWK> -BM
<AWK> -Shawn
<AWK> -Lauriat
<AWK> +Shawn_Lauriat
Josh: Far greater coordination between TF: Bi-weekly meetings, sharing docs, so we don't duplicate.
Sarah: Each focused on own area. As a design activity may be another group that's not attached that is mutual that can coordiate.
Josh: Some coordination will be done by working group. Yep, agree, but conscious of the challenge.
<laura> Aren’t all working group members in a TF?
Josh: won't set up separate entity to coordiate. Chairs and WG will do.
<AWK> Laura, no not necessarily
Rachael: How is coordination handled logistically? How will we see everything.
Josh: Facilitators will give show and tell, presentations to larger group. Calls on the list, questions, feedback solicited, surveys as usual. TFs will handle work separately, but what's important is that their work will be shared.
David: Been pretty close to SC task force, looking over low vision and cognitition; don't see collisions.
<AWK> -Davidmacdonald
<AWK> https://github.com/w3c/wcag/issues/183
Josh: Issue 183. General discussion, not in survey. Get feedback from group about date approved field. David added originally.
<Zakim> Joshue, you wanted to say I'd be concerned that this may cause more problems than it fixes.
David: Originally introduced so that we'd know when item was added. Helps to identify old stuff, what needs new work.
Josh: Tending toward not a good idea. Would it create more problems than it would solve. Positives. Some things are classic still work, doesnt mean not relevant. Is there another way to do it?
ak: I'm in agreement with you.
Would like to keep wcag focused on technical side, not for
policy purposes. Worry that this is the intent. Giving you tool
to allow wcag to be something different. Part of frustration
with 7 year old spec, agree that it's a challenge
... but that's why we're looking at wcag next. Find myself
wondering if it's the best idea.
<jon_avila> my recommendation was to have it say "date documented"
David: Agree with most of it. One of issues is question of so few failures, and how hard it is to add them. Thinking went from there.
Josh: To what degree is to address relevancy?
David: Trying to address that site in 2008 wouldn't pass today because of new technologies. Wcag is made to be evergreen, but pwd aren't getting things out in the space that they should. Looked at it another way, offline with others,
<steverep> zakim present+ [Steve Repsher]
David: Failure is always a failure, but haven't treated them as such.
Josh: In terms of failure, don't
look at failures so much, but come up with new techniques. To
what extant should we be looking for new failures? If we decide
it is important to look at failures, maybe form a failure
tf.
... Closure: should this be something we should have or not do?
Great idea for date approved fields, or not?
jk: Personal opinion date is dangerous. Having to track when certain rules came into place. How to resolve when they were applied or not.
<SarahHorton> Is it possible to determine date approved on the existing techniques and failures?
Jon: My reco is to say date documented. Wouldn't imply if it is valid or not. Would be able for people to know when. How it is applied is crucial.
<davidmacdonald> +1
Josh: Makes things seem more evergreen, but watch out for unintended consequences.
Kathy: Not against, but worry about how ppl will use it. Will have similar issues. Is this still a failure, or is it obsolete. Would be good if could update failures, based on how ppl will use them. Avoid complexity and confusion. Also dates for techniques.
James: I like having a date. But not published date. Rather less reviewed date. "No one has reviewed this in ten years, should I ask about it?"
<Joshue108> ME: It seems like people are concerned about how this is applied.
<AWK> +Steve_Repsher
<AWK> brb
<Joshue108> ME: Might people say my site was compliant till date x.
<Zakim> MichaelC, you wanted to remind conformance is always as of a specific date
MC: Conformance claims are always up to a certain date. So ppl can't claim up to a certain date.
<jeanne> +1 for last reviewed date because it is useful for knowing the relevance of the information.
MC: One gain is that it's useful for ppl to know how stale something is, both failures and techniques. Just because old doesn't mean it's bad. Don't htink it will affect their conformance review.
<Makoto> +1 to MichaelC Japan is taking the same approach
Josh: Last reviewed would be how I would want to produce it. My concern is what ppl would do with black hat dates.
<Zakim> MichaelC, you wanted to note techniques don´t have to come from us, so people wanting to finesse conformance can document their own techniques and failures and to point out
Racheal: Wonder if would help ppl to understand that it is an evolving document. Think it would be useful.
MC: First of all, more general
techniques don't have to come from working group. Can document
own. Ppl don't, but can. So if someone is concerned about our
technique, would do their own. So from that perspective doesn't
matter.
... Date could be helpful, but administrative cost. Have
several hundred techniques. Publish date could be automated,
but review date would be problematic. Who would update 600?
<laura> +q
josh: Date reviewed seems to have some traction. DK if I have horse in race, but date reviewed would be my favorite, admin cost not withstanding. Could make case for doing this in 2.1 or 3.0. Think about for future.
Alastair: Put review date that would reduce overhead.
Laura: Don't we already do that. Just have a call for consensus. Couldn't we use that.
MC: Not meaningful on technique basis. Looking at mast head not helpful.
David: What would be easiest for you. Why not date last changed.
MC: Hopeful could do this in
future, adding date field.
... Automatd should be date of last commit into github. That
said, couldn't pull out from before github. Wouldn't be able to
filter important from unimportant commits: change of letter
cap, for example.
Josh: Need to ask the list. Come back to next week. Post a question to the list.
<jon_avila> date reviewed is fine
Josh: Date reviewed unless some way to do automatically.
David: DAte reviewed is okay.
Josh: See if we can get tacit approval. Then look into logistics.
RESOLUTION: Josh to ping the list to ask the group if it likes the idea of using Date reviewed.
Josh: Objections (post
post)?
... none
Josh: will go through one by one.
<Joshue108> Original proposal https://github.com/w3c/wcag/issues/164#issuecomment-205374107
<Joshue108> Rational https://github.com/w3c/wcag/issues/164#issuecomment-213075041
<Joshue108> Last survey https://www.w3.org/2002/09/wbs/35422/NewWCAGEditRec/results
Josh: Proposal that came from
Sailesh. Surveyed previously. Left open from las tmeeting
... One thumbs up. Most didn't understand or said no.
Jon: I think I understand it.
Right now SC332 refers to isntructions that take place of
label. Doesn't reguire you provide instructions for form
fields. Some ppl thought required fields had to be indicated,
doesn't say taht.
... Would not have brought change. But would support. If better
to be ambiguous, then don't change it. For consistency should
consider it.
Josh: Not sure change will be what's required.
Jon: Fine if we don't make change.
ak: Not rejecting with prejudice. Instead, not sure I understnad it. Not in acceptance ready form. Not necessarily wrong. Would need to be worked up more clearly.
Josh: Good point. Even though consensus not to accept it, it is not with prejudice. Some confusion. Will reject, but suggest that Sailesh comes back with clearer proposal.
ak: Resolution: Do not accept on basis of unclear proposal. I know that he's spent time on it. Seems to be going nowhere.
David: Can explain.
AK: Even with explanation, wont' have something to vote on.
David: Problem is word "or" ppl have label don't need instructions. Instructions can be helpful. Would rather see and/or in success criteria.
Ak: In that case would not accept. "or" is there to address form control.
Jon: Thinking that he's saying that that is not the case.
Josh: Overall, not sufficiently clear what is being proposed.
RESOLUTION: Do not accept for being
unclear.
... Do not accept for being unclear.
Josh: Conflict between f38 and 4.1.1. Thumbs up from group. David comment.
RESOLUTION: Proposed response is accepted.
Josh: Large text using pixels.
<Joshue108> https://github.com/w3c/wcag/issues/181
Josh: Thanks for patrick for bringing up. Great to see the expertise with alistair and patrick on this. Are pixels more natural than points.
A: Kind of a step one. Under the definiotn, 5 paragraphs of notes. Where change would be. Definition would remain same 14 or 18 Bold. Patrick long explanation, I did a concise version.
<Joshue108> Definition https://www.w3.org/TR/WCAG20/#larger-scaledef
Josh: Even those notes are part of normative document, can't touch them.
James: Why can't if we're clarifyiing.
Josh: Would go into errata.
James: Errata get published.
MC: Do not change base document. Two scenarios, squeeze in before publish, but opens up the process.
James: Don't mind if it takes two weeks or two months.
<davidmacdonald> e tat hole=errata
MC: How about 8 years?
<davidmacdonald> e rat hole=errata
Josh: Is this more substantive or editorial? More substantive.
<Zakim> AWK, you wanted to say that everything in WCAG 2.0 is normative.
AK: First question is does this make the success critier clearer, or a correction? If it's for clairty, then change understanding document. More straightforward. Perhaps this section is normative except for notes.
<Zakim> MichaelC, you wanted to say I think it´s better to address in Understanding
<steverep> /me Zakim, who is here?
MC: If it's important to publish errat for note, then begs question if it's normative. Ppl want to clarify based on change of definition since Wcag 2.0 was published. Makes me nervous.
James: Not sure it's a change in defition, just not defined before.
<alastairc> Comparing https://alastairc.ac/tmp/large-text-definition-ac.html to https://alastairc.ac/tmp/large-text-definition-ac.html
MC: At least a de facto definition that was different from current definition.
Josh: Original suggestion from
Patrick...designers don't think in pts. Think in px. Whole
issue brings up need for clarification. Original question is
whether it was editorial or subastantial. Should address, but
dont' see getting this into current wcag.
... perhaps Wcag 2.1.
<Zakim> MichaelC, you wanted to say designers *used* to think in points very much
R: hve this conversation many times with develoerps. But is substantial.
<SarahHorton> Agree that it's substantive
<Zakim> MichaelC, you wanted to say pixels *used* to be a specific property of a device, whose size *used* to roughly map to points, but devices always were variable and now literal pixels
MC: Pts were basic for print
publishing, But has changed since. So not an erratum. Always
understood taht pixels were thing on your device, but it is
relative based on size of device. When wcag 2 published they
were basically the same.
... But not anymore since devices come in many sizes.
Josh: Working group did not make an error. It was based on print design. What we fold-in should be errata.
<Joshue108> +1 to Alastair
A: In agreement that it's a change since wcag 2 was published. Work with designers who never worked in print, so not aware of difference. If we can't add something to the definition notes, then happy to come up with something for Understanding section.
<SarahHorton> +1 Alastair
Josh: Suggest we augment the Understanding document. Flag this for a TF to work on or 2.1.
James: Can make better changes than in discussion.
Josh: Absolutely.
<MoeKraft> +1
<Rachael> +1
<jeanne> +1
Josh: Agree or disagree with Josh?
+1
<Makoto> +1
<marcjohlic> +1
<laura> +1
<AWK> +1
<Greg> +1
RESOLUTION: Work on this will continue in the understanding document and be flagged for 2.1.
Josh: Dont' think we'll get through 4 this week.
Ak: Why not discuss.
<SarahHorton> Request clarification on "heading areas" versus "header areas"
Josh: Before we get into it. Need to clarify editorial vs. non-editorial changes in wcag.
<davidmacdonald> https://github.com/w3c/wcag/issues/173
Josh: General feeling is not sure. one yes, three no.
<Zakim> AWK, you wanted to ask if 1.3.1 requires that the main area of a page be identified
Josh: Content vs. navigation. In terms of requiring that we always markup, have reservations.
A: Without hat: 1.3.1 has a lot of ambiguity. Worry that there are a lot of things that would be part of the page visually, that must be marked up. Like when have a set of tabs before aria. Could make the argument that it should be marked up now.
A: But required? No. Either markup programmtically or in text. Not a good way to do this. Would be a headache for ppl. Will make only one way to meet success criteria.
David: Disagree with comparison
with tabs. Vigorous discussion among ppl. Would like a settled
situation here. There are multiple ways to establish markup.
Lots of exceptions if don't want to do it.
... Very reasonable failure. Many reviewers failing
organizations.
Josh: Actually called this out
separate from failures, because it was getting caught up in
other issues.
... Ak's comment is relevant, not as clear cut as may have
thought. Will continue on list. Group leaning toward no.
<laura> bye
RESOLUTION: Will be addressed next week.
trackbot, end meeting.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) WARNING: Bad s/// command: s/https://www..w3.org/WAI/GL/wiki/Main_Page/WCAG_future_proposal/ Found Scribe: Mike_Elledge Inferring ScribeNick: Mike_Elledge Default Present: AWK, EricE, Kathy, Laura, jeanne, KimD, alastairc, JF, Joshue108, John_Kirkpwood, SarahH, Makoto, David_MacDonald, Mike_Elledge, John_Kirkwood, Greg_Lowney, kirkwood, MichaelC, Katie, Haritos-Shea, patrick_h_lauke, Elledge, MacDonald, Katie_Haritos-Shea, wayne, jon_avila, marcjohlic, Rachael, BM, Shawn, Lauriat, adam_solomon, Davidmacdonald, Shawn_Lauriat, [Steve, Repsher], JamesNurthen, Steve_Repsher, steverep WARNING: Replacing previous Present list. (Old list: AWK, David_MacDonald, Greg_Lowney, Haritos-Shea, JF, Joshue108, Kathy, Katie, KimD, Laura, Makoto, MichaelC, Mike_Elledge, SarahH, alastairc, jeanne, kirkwood, Rachael, BM, marcjohlic, Mike, Elledge, Shawn, Lauriat, adam_solomon) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, Kathy, Laura, jeanne, KimD, alastairc, JF, Joshue108, SarahH, Makoto, David_MacDonald, Mike_Elledge, Greg_Lowney, kirkwood, MichaelC, Katie, Haritos-Shea WARNING: Replacing previous Present list. (Old list: AWK, Kathy, Laura, jeanne, KimD, alastairc, JF, Joshue108, SarahH, Makoto, David_MacDonald, Mike_Elledge, Greg_Lowney, kirkwood, MichaelC, Katie, Haritos-Shea, Davidmacdonald, jon_avila) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, Kathy, Laura, jeanne, KimD, alastairc, JF, Joshue108, SarahH, Makoto, David_MacDonald, Mike_Elledge, Greg_Lowney, kirkwood, MichaelC, Katie, Haritos-Shea Present: AWK Kathy Laura jeanne KimD alastairc JF Joshue108 SarahH Makoto David_MacDonald Mike_Elledge Greg_Lowney kirkwood MichaelC Katie Haritos-Shea [Steve Repsher] JamesNurthen Regrets: EricE Found Date: 17 May 2016 Guessing minutes URL: http://www.w3.org/2016/05/17-wai-wcag-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]