Web Content Accessibility Guidelines Working Group Teleconference

17 May 2016

See also: IRC log


AWK, Kathy, Laura, jeanne, KimD, alastairc, JF, Joshue108, SarahH, Makoto, David_MacDonald, Mike_Elledge, Greg_Lowney, kirkwood, MichaelC, Katie, Haritos-Shea, [Steve, Repsher], JamesNurthen


<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/


<alastairc> +alastairc

<Joshue108> +Joshue108

<AWK> Scribe: Mike_Elledge

<AWK> Chair: Joshue

<KimD> +KimD

new introductions

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.

TPAC Registration https://www.w3.org/2016/09/TPAC/

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> -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.

TPAC Registration https://www.w3.org/2016/09/TPAC/

<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

Github issues questions (Survey) https://www.w3.org/2002/09/wbs/35422/17thMay2016/

Proposal Should G83: "Providing text descriptions to identify required fields that were not completed" reference 3.3.2

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.

<Joshue108> TOPIC: F38 and 4.1.1 conflict ? #186

Josh: Conflict between f38 and 4.1.1. Thumbs up from group. David comment.

RESOLUTION: Proposed response is accepted.

Josh: Large text using pixels.

"Large text" - using px rather than pt as unit #181

<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?


<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.

Does WCAG 2.0 SC 1.3.1 mean that headings areas, footer areas are required to be identified programatically or in text

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.

Summary of Action Items

Summary of Resolutions

  1. Josh to ping the list to ask the group if it likes the idea of using Date reviewed.
  2. Do not accept for being unclear.
  3. Proposed response is accepted.
  4. Work on this will continue in the understanding document and be flagged for 2.1.
  5. Will be addressed next week.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/05/17 16:32:43 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]