See also: IRC log
<AWK> +AWK
<Kim_D> +Kim_D
<bbailey> +1 for webex password
<bbailey> did not work for me
<jemma> thanks marcjohlic for meeting pw
<bbailey> ok, refreshed page
<jemma> thanks for the meeting pw, Jeanne
<scribe> scribe: Rachael
<Joshue108> https://github.com/w3c/wcag/issues/245#issuecomment-253671417
<Joshue108> https://github.com/w3c/wcag/issues/245
<Joshue108> https://github.com/w3c/wcag/pull/250/files?diff=split
Josh: Issue 245 has been accepted by and large with one proposed change. The new example was intended to be an addition not a replacement.
AWK: The pull request that
implements these changes is in pullrequest 250. I've just
placed them in 245
... This is an example that adds in the specific change. See
link.
Josh: Is any objection to adding this new code example?
RESOLUTION: Approve 245
<Joshue108> https://github.com/w3c/wcag/issues/244
This had a few proposed changes. A couple peope said they do not accept.
Joshue: The objections are that most users don't want to skip to the nav rather than over it.
David: I don't see the value. It is already solved using landmarks.
Bruce: Just thank David, because he changed my mind. I don't think its constructive.
Joshue: There is several supporting.
<Zakim> AWK, you wanted to say that the screen reader support I mentioned allows users to skip TO or PAST the nav element
AWK: Some screenreaders do have
the ability to jump to the next element type or same element
type so there is some functionality there for accessibility
support. That is just out for consideration. You can use it to
skip to or away from it.
... the aria landmarks provides more precise functionality. Do
we think this would satisfy 2.4.1? Its not about whether we
have an alternate technique it is whether we think it is a
sufficient technique.
Marc: The objections seemed to be that we already have a way to address the criteria but this seems another sufficient way.
James: I feel the nav elements
are already covered by landmarks. If we are going to add
anything, I think we should add in something grouping main
elements in a page vs an example that is specifically for nav
elements. Also, what we have already is focused more on
screenreader users rather than keyboard users.
... I would rather see us add more examples that support
keyboard users.
... Landmarks are supported across all browsers except all
versions of IE (Edge is unknown). We don't know how well this
is supported, likely less than landmarks. I'd support it being
advisory vs sufficient technique.
David: I don't believe this alone is sufficient. You don't have to do headings or landmarks or other elements.
<Ryladog> Most normal SR use headings over landmarks. Landmark today is more used by superusers. However adding more advisory is OK.
Michael: What James and David last said is important. I think this is part of meeting the success criteria but not the entire thing so we either need to group it with other techniques.
Joshue: I agree with James that advisory would be better than sufficient.
<marcjohlic> +1 to advisory
<Makoto> +1 to advisory
<Joshue108> +1 to advisory
Joshue: There are a couple substantial reasons to not add it to 2.4.1. Is anyone feeling strongly that this should be sufficient?
<gowerm> +1 advisory is fine
+1 advisory
<laura> +1 to advisory
<AWK> +1 Advisory
<jamesn> +1 tp advisory
<bbailey> +1 to advisory
miker: I think that it is worth revisiting. As written it implies that it stands alone. It may be worth rewording.
<Zakim> bbailey, you wanted to say it is not a problem to have multiple sufficient techniques
I'm fine with it being advisory but think ARIA 11 and H69 also need to be looked at.
bb: do we want to write this up as skipping to main vs skipping over nav? Also we should look at techniques to ensure that we are being consistent in how we designate sufficient techniques.
<Joshue108> https://www.w3.org/WAI/GL/wiki/Using_HTML5_section_elements
If we create a technique on all html5 sectioning elements, it would be comparable to the aria technique. Just this small subsection isn't likely good but a broad one would be helpful.
<bbailey> +1 on html sectioning elements
Joshue: There may be a piece of work to look at the sectioning elements. There seems to be support for this to be advisory.
Is there any objection to accepting this as advisory?
RESOLUTION: Accept 244 as advisory technique
<Ryladog> +1 on html sectioning elements
<Ryladog> wasnt that 245?
<gowerm> I'll take on sectioning elements
<bbailey> FWIW, i just relooked at ARIA 11 and H69 and IMHO both are significantly stronger for 2.4.1 than H97
<Joshue108> https://www.w3.org/2002/09/wbs/35422/SilverTFWorkStatement/results
Joshue: The response to this was very positive and most agree. One comment was the 8 hours a week participation may be a barrier because its a large amount of time.
In terms of the time committment, there are not a lot of hard and fast rules of this. AWK or Michael: Any comments on this time requirement?
Michael: I woudl like the subgroup participants to speak to it. This came up a week ago. The comments at the time was that this is meant to be a focused group. They need the focus and we don't expect that everyone can provide that. There are many ways for people to help without joining the task force and making the time committment.
<Ryladog> Cannot mandate 8 hours
Judy also raised that she'd like to see more structured participation between the task force and working group and some peope might use their time in the task force as a working group liason. That may help some people.
I think subgroup people would have something to say.
Sean: I think Michael covered it. We do need to get things done and have focus. There is some flexibility because we won't be checking time sheets but there are other more temporary or project based opportunities.
Joshue: Does that addres it?
David: Not really. In WCAG there are always a few core people who really hit it hard. Then there are a lot of people who comment and provide feedback. I am concerned that the way its going right now, the silver group is responsible for takign it from 0 to the first public working draft.
Once you get to first public working draft, you've locked it into a series of decisions. It sets the tone. Its the second most important taks. The silver task force are the key authors but with the 8 hour a week barrier.
Joshue: You just heard that its not a hard time estimate.
<Zakim> MichaelC, you wanted to say we also said last week the TF will do a preliminary draft for the WG but will not be the author of FPWD
Sean: There are 4 phases that the taskforce will welcome input and participation.
AWK: The task force is responsible for first draft only. Then the working group takes over. The task force provides an initial draft but the working group provides the first working draft.
Joshue: The 8 hours isn't a strick requirement. David, what are your thoughts?
David: I'm not sure specifying a number of hours is needed. It shoudl be more like a taskforce. If folks get involved, they will devote more hours. What is the current requirement for task forces?
Michael: Typically we ask for 4 hours for working groups and that is implied for task forces. This task force is looking for a sustained committment and focus recognizing that not everyone can do it. The working group can say that it isn't appropriate but I think it can be appropriate if there is a lot of coordination with the working group.
<Ryladog> +1 to David. Cannot mandate 8 hours
We don't want the task force to be its own working group but there are many ways to set it up to allow a focused task force and still ensure participation from the overall working group.
Joshue: I propose we split the difference and write 6 hours with the understanding that there may be a bit more.
James: I have another idea. We already have a 4 hour requirement for the WCAG working group so can this 8 hours incorporate the 4 hours for the WCAG group?
<gowerm> "Minimum 8 hours per week of task force work (this time also counts towards the individual's participation requirement in the WCAG WG);"
<bbailey> queue please
Joshue: It already includes the 4 hours for WCAG.
David: I am still concerned about potential conflicting time
bb: I think you need to scope out the work that is needed before putting in a time requirement.
<gowerm> +timebox TF
I've worked on task forces that require 8 hours. I'd like to see a 6 month or shorter work plan that ties to the time requirement. It read to me that its aiming for a working draft. That isn't going to get done in 6 months.
JF: I think everyone here volunteers its time. I think that 8 hours is unreasonable based on the work. I think that we have really good people who already dedicate that time. Without attaching specific dates, I think that's what we said. We have an 18 month-24 month goal of writing the working draft. The task force will absolutely bring it back to the working group.
Bb: I don't think we should be asking for 8 hours unless you mean 8 hours.
<Zakim> MichaelC, you wanted to say I don´t plan to put in 8 hours per week ;) but I do plan to have consistent participation
<Ryladog> Continue to be concerned about 8 hours, no matter if it is shared with WCAG. This is a barrier to participation - which should be discouraged.
John: Asking doesn't mean we're going to get it. We are asking for volunteers and we are saying that you shoudl expect ~8 hours. Its not about turning someone down if they can only commit 5 hours a week.
Michael: I think the key is identifying a core who can put 8 hours a week in. The consistency of participation is more core than the raw number of hours. I don't know how to reflect that in a work statement but perhaps that is what we can get at.
<bbailey> Glad to hear nominal 18 month expectation, that seem realistic to me.\
<Ryladog> +1 to Bruce
Jeanne: The 8 hours came from the time that the group has already been putting in for the last 5 months. We meet twice a week and we have homework assignements. Its based on what we have been doing and what we see going forward. The first part of the work we'll be doing is organizing research. The WCAG working group has a lot to contribute. We're trying to make it as easy as possibel for working group to be involved and give input.
The 8 hours is more of the coordination of the reasearch and that will be the first 12 months.
After the research, when we start writing the first public working draft, I would certainly see this being reexamined to see whether it is time to merge back into the main working group. I don't think anyone is set on how this looks a year from now. We're focused on getting the research started. Finding out what works, what doesn't work. How are we going to structure this?
We'll be focusing on structure before we start working on the content. I think there is a lot of time before we get to the point that David is concerned about. I think we can reevaluate things a year from now to see where we are, how 2.1 is going, where the working group is, and then see if it makes sense to leave the working draft in the task force or move it to the group as a whole.
I hope there are a lot of people on the working group that want to participate in Silver. As the subgroup, we are trying to figure out how to make the coordination happen and the getting the working group involved. We're trying to make ti easy to participate with all the other things the WCAG working group is doing.
Joshue: Chair hat off, I think 8 hours is reasonable based on the amount of work that is needed.
David: This early positioning is a critical time. The language that Michael said is different than what Jeanne said. I like the general overview. I'm concerned that the task force is going to do the work with comment from the working group vs. the working group doing the work iwth the task force informing. Its a subtle difference but it can lead to big differences.
I want to see all hands on deck for Silver for the working draft vs. a standard approval. That's my thoughts.
Jeanne: What I was saying that we should not return it to the working group after the working draft is done but rather that before the working draft is started, we should look at whether it should be merged back in.
Joshue: We are not handing this over to separate group. All the people involved in the work are long standing working group members.
David: Its a subtle distinction that I think is important.
Joshue: What I am hearing is that this is not a hard barrier but rather an advisement on the amount of time that is expected and I think its reasonable. The understanding is that this work is that the work will ultimately be the responsibility of the working group. The question is that those who don't agree with it, can you live with the 8 hours?
Bruce: Why is this activity being chartered as a task force?
also I think that 8 hours is not unrealistic.
<AWK> How about: "Expected committment of 8 hours per week of task force work (this time also counts towards the individual's participation requirement in the WCAG WG);"
Joshue: If there are issues, please let the TF know. The reason its being formed is that the main group is focused on finishing 2.1. But we still need to be planning for Silver. So the TF is getting the research, etc done and then when 2.1 is out the work will be folded back into the main working group.
<Zakim> bbailey, you wanted to ask why this work is being done as TF and not WG ?
Michael: One of Judy's thoughts is that some of the time would be expected to be coordinating with the working group. Would that ease or exacerbate peoples concerns if we add it to the document?
Change web content to content and functionality. Make sure that scope is not just the web. We are not 100% sure that is the right words but we want to have something that scopes it to everything we touch, not just the web. We want to change language to Silver vs 3.0
We added two liason statements to the two other groups. They are coordination not gate points.
<Zakim> AWK, you wanted to speak against "content and functionality"
<AWK> content (Web content): information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions
AWK: Changing web content to content and functionality. I suggest we just use content since we already define content to include interactions.
<Joshue108> is functionality defined?
Joshue: Is functionality defnied?
<AWK> functionality: processes and outcomes achievable through user action
<DavidMacDonald> content, user agents and authoring tools?..
Greg: Is silver supposed to be including guidelines for user agents?
Michael: I don't think we have clear plans for whether it will have guidelines that go beyond what is needed to make content accessible. I think the wording is open ended.
Greg: The functionality in UAAG that is in the browser is distinct from the functionality built into the content.
John: What do we call a web app constructed by the author. We want to keep it as open ended as possible
<Ryladog> I would prefer there not be a defined time commitment stated
Joshue: For the time committment, the task force wants to have people really committed to this that are committment. Michael has suggested we simply state that people will have to commit a substantial amount of time. We could state that the 4 hours of time that is already committed to the WCAG working group will go towards the task force time committment. Should we bring it into the area that we state its a time committment without being explicit or low[CUT]
of time specified?
Michael: I am an advocate for leaving things undefined. Since there is concern about the 8 hours, I suggest we leave it as substantial. I think sporatic is an issue but I'm not sure how to word it.
John: I agree that getting caught up on a number is an issue. If folks are going to be there consistently we aren't going to turn them away. I think that consistency is important. I think current members want more people involved and want to let people know the amount of work that is likely.
This is a group. Its not one individual showing up.
Mike: The text I quoted calling for a substantial amount of time is already in the work statement.
We could soften the language to recommended 8 hours.
Joshue: I think we'll move away from the 8 hours since it seems like a blocker.
Mike: I don't have a problem with the 8 hours.
<Zakim> bbailey, you wanted to ask who on Silver TF worked on WCAG 1.0 ?
Bruce: I am worried about anything about anything that inhibits Katie and David from participating. Who on the task force brings the long term perspective?
Joshue: Judy and Jeanne are both on the task force.
John: I get concerned about naming specific individuals.
Joshue: I think asking who has historical knowledge is reasonable.
<Ryladog> +1 to David
<AWK> I have been joining the silver sub-group meetings
David: Its about ensuring everyone has a voice.
<Zakim> MichaelC, you wanted to wrap up edits
<jeanne> +1 to David, everyone has a voice.
MC: Just to wrap up edits. I think that if we change the minimum 8 hours a week to substantial and consistent task force participation in that bullet. Are those changes acceptable?
AWK: Also changing content and functionality to content
Joshue: I'd rather not because I am concerned that Silver's work would be limited to content only.
Michael: Are you ok with the potential duplication?
<Ryladog> +1 to MC suggestions
AWK: Sure. Silver will define what content means. It may be explicitly redundant at that point but this is a work statement but not a big deal.
<Kim_D> +1 to "substantial" and keeping functionality
Jeanne: I thought functionality addressed Greg's concern.
Joshue: For those who raised the 8 hour issue, are your concerns addressed?
<gowerm> +1 on edits
<Joshue108> https://www.w3.org/WAI/GL/task-forces/silver/work-statement
<Joshue108> +1
<laura> +1
<marcjohlic> +1
<Makoto> +1
<Kim_D> +1
David: Should we add a statement saying we should merge it back in before the first public working draft?
Jeanne: The working group controls this so I'd prefer we leave it open.
<AWK> The WG can change the Work Statement down the road also
Michael: Last statement says "The task force will coordinate regularly with the Accessibility Guidelines Working Group to keep the larger base of participants informed and receive guidance from the WG."
<DavidMacDonald> +1
<JF> +1
<Kathy> +`1
John: Suggest breaking it into its own paragraph to highlight that.
<AWK> +1
<jeanne> + 1
<bbailey> +1
+1
<kirkwood> +1
<Ryladog> +1 again..:-)
<Greg> +1
<Ryladog> thanks!
Joshue: Does anyone object to the revised work statement?
RESOLUTION: Accept Silver Work Statement
Michael: Ready for CFC
Joshue: we'll send that out after the call
<AWK> https://www.w3.org/2002/09/wbs/35422/GithubIssuesNov12016/results
Joshue: We have a few github issues we may be able to get through while we're on the call.
<Joshue108> https://github.com/w3c/wcag/issues/239
Does the working group agree that C29 should be listed?
All responders said yes. Is there any objections?
AWK: Yes. This technique is to meet a conformance requirements. You can't provide an alternate conformance requirement for just 1.4.3. It needs to relate to all success criteria.
Joshue: It seems reasonable. Mike or Gary do you want to comment?
<gowerm> sorry lost audio input
So there are two parts to this. Perhaps we should put this in as a related technique for G174.
Joshue: I am fine adding it as a related technique.
James: I am really confused about what we are being asked. Understanding documents don't really have related techniques.
Mike: There are two parts. Include it as a related technique for G174. Put C29 into a related technique for 1.4.3. It sounds like the first is ok but there are concerns for the second.
AWK: It would need to be a related technique to everything so at that point, I'm not sure its helpful.
Joshue: What is the net benefit for doing this? My gut now is to leave it as it is.
Mike: I do think there is a benefit for adding it as a related technique to G174 but I take Andrew's point.
Joshue: I think that adding it to G174. It is about color contrast. It could hit a lot of other things too. But would we take out the note in the description and just add it as a technique in related techniques?
AWK: I don't know what the note was added in the 174 technique but at least that is talkign about contrast. I think its fine as a desriptive note but as soon as we add it as a related technique we will start getting questions about why its not a related technique for other areas. Unless something seems wrong, I suggest a stance of less aggressive change making so we can focus on WCAG 2.1
<JF> +1 to AWK
Joshue: Mike, can you live with this being as it is and look at it for 2.1? My feelings is that it is already mentioned as a note. Is that OK with you?
Mike: Absolutely. I will take Andrew's guidance for things being wrong and take that into account.
Joshue: Your input is good. You
are catching some interesting things.
... We'll leave it there.
trackbot, end meeting
<laura> bye.
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/there any example/any objection/ Succeeded: s/??/Greg/ Succeeded: s/UAG/UAAG/ Succeeded: s/funcationality/functionality/ Succeeded: s/prohibits/inhibits/ Succeeded: s/inhibits/inhibits/ Succeeded: s/ AWK: Just to/ MC: Just to/ Succeeded: s/Gregg/Greg/ Found Scribe: Rachael Inferring ScribeNick: Rachael Default Present: AWK, marcjohlic, JaEunJemma, Kathy, Kim_D, Makoto, Katie_Haritos-Shea, Rachael, Greg_Lowney, DavidMacDonald, Lauriat, jeanne, Laura, Joshue108, bbailey, Mike, Gower, Bruce, Bailey, Mike_Gower, Bruce_Bailey, JF, `1, 1 WARNING: Replacing previous Present list. (Old list: (no, one), marcjohlic, JaEunJemma, Kathy, Makoto, Katie_Haritos-Shea, Rachael, Greg_Lowney, DavidMacDonald) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, marcjohlic, JaEunJemma, Kathy, Kim_D, Makoto, Katie_Haritos-Shea, Rachael, Greg_Lowney, DavidMacDonald WARNING: Replacing previous Present list. (Old list: AWK, marcjohlic, JaEunJemma, Kathy, Kim_D, Makoto, Katie_Haritos-Shea, Rachael, Greg_Lowney, DavidMacDonald, Lauriat, jeanne, Laura, Joshue108, bbailey, Mike, Gower, Bruce, Bailey) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, marcjohlic, JaEunJemma, Kathy, Kim_D, Makoto, Katie_Haritos-Shea, Rachael, Greg_Lowney, DavidMacDonald, Lauriat, jeanne, Laura, Joshue108, bbailey, Mike, Gower WARNING: Replacing previous Present list. (Old list: AWK, DavidMacDonald, Greg_Lowney, JaEunJemma, Joshue108, Kathy, Katie_Haritos-Shea, Kim_D, Laura, Lauriat, Makoto, Rachael, bbailey, jeanne, marcjohlic, Mike_Gower) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, marcjohlic, JaEunJemma, Kathy, Kim_D, Makoto, Katie_Haritos-Shea, Rachael, Greg_Lowney, DavidMacDonald, Lauriat, jeanne, Laura, Joshue108, bbailey, Bruce, Bailey WARNING: Replacing previous Present list. (Old list: AWK, DavidMacDonald, Greg_Lowney, JaEunJemma, Joshue108, Kathy, Katie_Haritos-Shea, Kim_D, Laura, Lauriat, Makoto, Rachael, bbailey, jeanne, marcjohlic, Bruce_Bailey) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, marcjohlic, JaEunJemma, Kathy, Kim_D, Makoto, Katie_Haritos-Shea, Rachael, Greg_Lowney, DavidMacDonald, Lauriat, jeanne, Laura, Joshue108, bbailey, Mike_Gower Present: AWK DavidMacDonald Greg_Lowney JF JaEunJemma Joshue108 Kathy Katie_Haritos-Shea Kim_D Laura Lauriat Makoto Mike_Gower Rachael bbailey jeanne marcjohlic Regrets: Wilco alastairc Moe_Kraft Agenda: https://lists.w3.org/Archives/Public/w3c-wai-gl/2016OctDec/0317.html Found Date: 01 Nov 2016 Guessing minutes URL: http://www.w3.org/2016/11/01-wai-wcag-minutes.html People with action items:[End of scribe.perl diagnostic output]