See also: IRC log
<AWK> +AWK
<AWK> +Mike_Elledge
<AWK> +Jeanne
<AWK> s/Shadi, your employer/
<scribe> Scribenick: Mike_Elledge
<AWK> Scribe: Mike_Elledge
AWK: Reminder: Register for TPAC!
... Will have a conference hook-up, but better if you can come in person.
awk: Has been published. Docs are available and have received few comments. Perhaps none. One question, hard to tell about release, or before. Encourage others to review them and give feedback.
... post goes out to WAI list, RSS feed and TWitter. Don't go out on W3C list.
MC: Don't think sent out to WGs this time.
<Rachael> +present Rachael
awk: May be that don't get as many comments if we have on 2 yr cycle.
... Task force proposal from Shadi and Judy. Testing for WCAG. Well-defined, automated tests, and clear methodology for people to use. Can be used for other groups doing testing.
... Looking into setting up task force. Deliverables, level of interest.
<AWK> Links for ACT proposal:
<AWK> https://www.w3.org/community/auto-wcag/wiki/Accessibility_Conformance_Testing_for_W3C
<AWK> https://www.w3.org/community/auto-wcag/wiki/ACT_Deliverables (proposed deliverables)
Judy Brewer: Will add to intro. Not on IRC. But feedback on charter updates last year was conflicting interpretations on how to get authoritative results. Hearing from japan, china, many different areas, small, large companies
JB: evaluation providers trying to understand correct interpretation for them to use. Multiple author rule sets are either open source or would be willing to contribute to that effort.
... Strong interest to incubate work under automated WCAG WG. Trying to broaden focus beyond automated tests.
Shadi: The use of WCAG is difficult for evaluation. Particularly success criteria. Several testing initiatives that went public, vendors that want more common understanding of SCs.
S: Virtually impossible to have rules for every item, but try for a common base. First link above is background (motivation), second is TF proposal where have pinned down deliverables and want to get feedback.
... Third is the test rules (ACT). Should not be exclusive to WCAG 2, could use in future as well. This is to define specifics for test rules. Want to become a recommendation.
<Ryladog> Rulesets should be versioned in general and that makes them easily updateable with new dates/versions
S: Test rules would be developed according to specification, from the automated WG. Open to people coming in for specific items or organizations taking on multiple ones (like Techniques).
... Benchmark method is to validate test rules. Make sure aligned. May be part of the framework, but for now a separate spec.
... Envision building benchmark tool, test rules on set of test cases. Not a validation tool. But to help validate rules themselves. Also build a repository of rules, perhaps github. Where people can search for rule status.
<shadi> https://www.w3.org/community/auto-wcag/wiki/ACT_project_plan
S: Propose to do within 3 years. Have a project schedule (see above).
... Questions?
awk: Questions?
jb: Want to evolve this with interaction from group.
<Ryladog> katie me
awk: DK who on call has been on community group.
Katie: Has been. but not active. 2 years ago.
S: Some overlapping participants. Jon has been following. Colleagues of Moe at IBM.
<jon_avila> we have just been monitoring but will be stepping up our participation
jb: Some ppl have said they would be involved if a TF, easier to get permission than community gorup.
Moe: Confirm Shadi comment. Colleagues on weekly meetings. Rules creation and implementation. Lots of good activity.
<davidmacdonald> http://tinyurl.com/ht2nnlx
<davidmacdonald> http://davidmacd.com/WCAG/review-of-ruleset-OAA.html
S: Not starting from scratch.
DM: Spent time looking at FAE functional testing. Biggest concern is that most of automated tools and rules are generally failures that committee agrees on. Difficulty getting acceptance on FAE. Even small failures get much resistance.
<jon_avila> Need to have advisory category
DM: Probably for good reason, but have introduced many and gotten resistance.
S: Maybe together get there better. Name of community group is unfortunate, thought would not be a good use of time. Really automated and semi-automated both. Initial phase focus on minimal set to get thngs going.
... Might be best appraoch, then types beyond automated. Also talked about separating critical conformance, best practice/warnings, items that are troublesome but not outright failures.
me: Existing tool inconsistancies?
S: Yes. Information we've gotten from organizations is there are problems, leading to conflicts, even contractual. Building up consensus would be useful.
<davidmacdonald> Color #777777 fails 5 tools passes 3
jb: Aware of one group that would want to contribute on manual side--AMAC out of Georgia Tech. Could get new batches of energy for different elements of work. Talking about updating charter. Looking forward to input.
<AWK> AWK to ask if people agree that this is needed and if people would anticipate being involved personally
Katie: I think wCAG is about technology and outcome. Techniques are about things that will and won't work for pass/fail. Have to align rules for failures and add more specific failures. What is a failure, what is a technology. What will/won't work with particular technology.
<MoeKraft> +1
awk: some people have been on community group, at various levels of participation. Anyone want to be part of this, bearing in mind that there are other TFs that ppl are working on. How many ppl have the bandwidth?
S: We expect there will ppl joining specifically for this--not to pull only from existing TF members.
... A new TF so additional overhead.
<davidmacdonald> @Shadi you are welcome to use any of my resources that I've worked on
awk: An opportunity for ppl to think about it.
... Non-conformance vs. conformance as outcome.
S: Picture this as decision-tree, most of leaves cannot tell, so limited, but some leaves may indicate Fail. So non-conformance. Unless very specific and simple cases. Hard to rule out all possibilites.
me: Perhaps focusing on contradictions instead of everything might help limit scope.
S: Will take back to group. Have talked about low-hanging fruit. Aria seems to be an area where there are numerous issues.
... Thanks everyone!
<AWK> https://www.w3.org/2002/09/wbs/35422/WCAG_comms/results
awk: Survey had 19 responses. Good number. Good news is that 3 not feeling overwhelmed by list traffic. Bad news many others are. Emails are coming through in multiples, rate of discussion too fast to formulate well-thought out answers.
... Everyone likes threading. Do ppl do that in their email clients, or are there tools that help? And new topics.
... Any comments from ppl not able to respond to survey? Don't have 40 hours to spend on WCAG. Could spend many hours on list, difficult to do anything else. Want to make sure it works for everyone. Hear how to make better.
... What would work best for most ppl?
MJ: A couple things make it tough for me. Repeated signatures > wall of text. Everyone seems to have a way to quote from previous text. Get lost with content.
<Ryladog_> You are not alone in this...:-)
<AWK> +1 to Marc's comments
MJ: Excess text, clean it up, consensus on how to structure comments.
<Ryladog_> Not your fault this issue David
DM: Quite a few threads have a list of things that needed vetting. That process is finished now. Dropped the conversatons without consensus or traction. Ppl had really good conversations, reminded me of jamming WCAG 2.0 days.
... From my perspective that the TF on success criteria is good timing. Think that his issues will slow down.
MK: noticed increase of traffic. Only seeing most recent part of thread.
ME: +1
<Ryladog_> +1
MK: Thread used to be tagged along. Does not seem to be the case anymore. Don't always know where thread comes from. Daily summary?
<Zakim> MichaelC, you wanted to say there are standards for text quoting, but not all clients use them and to say +1 to clean up and only include quotes needed for context and to say the
<alastairc> +1 to not copying entire thread in every email, that is what threads are for.
MC: Text quoting. There are stds, but not every client follows them. Sometimes just a config issue--should get clear text formatting. Remove parts of earlier message. Inilne vs. top-posting debate was never resolved.
... Document practices so when gets cluttered can remind ppl. For wiki edits can maintain threading. There are conventions. Involves working thorugh wiki context, which can be difficult.
<AWK> There are very general guidelines at https://www.w3.org/WAI/GL/#about
<jon_avila> You can also email to github so you need to make sure to pull extra content out of those before sending.
SR: In general email clients, hard to police. Wikis are automated for you. Comments fall into place. Emails can be very messy and confusing. Especially from screen reader perspective. Long email signatures especially troublesome.
<jon_avila> I personally find threaded emails hard to read.
<Zakim> MichaelC, you wanted to say GitHub issues work for issue-focused discussion, but not for exploratory discussions
WD: From sr point of view, want to skip around, see what author has to say. Very had to deal with it. Broken up.
MC: About github. Features in github very useful for exising issues. Not good for general exploration which we need to do a lot of.
awk: Interested--Jon thread emails hard to read.
<Lisa_Seeman> I am back
ja: Depends on how threads are done. Some have previous, next, can't see everything on one screen. Some delete other items. Other times save pieces of them.
<jon_avila> The github approach would be fine
awk: Interested in exploring whether can use github issues area for discussion. If Katie has question, all the comments there on one page. Can reply with email. But also opp'ty to say "done with this", answer in one place.
<jon_avila> My dislike are viewers that require you to use next or prior links or emails systems that hide portions
awk: Think it might work for initial discussion, should try.
sr: Completely agree with github comments. Can subscribe to particular issue. Won't get ones not interested in . Can go through one a time, rather than sorting through email threads.
... If you discussions about documents, will be more focused. But some things more appropriate for alpha level discussions.
awk: Don't want to take up too much time on this. Lisa is here for COGA success criteria discussion. Maybe try github, wiki. Need to define process. Additional input is welcome.
awk: Have talked about this, Lisa wanted to share some sc from cognitive.
<Lisa_Seeman> https://rawgit.com/w3c/coga/master/extension/index.html
<Lisa_Seeman> Provide a clear structure that includes:
<AWK> For reference: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria
ls: have a look at my sc and why they are not short. We used bullet points. Going to put on one: Provide a clear structure that includes:
<Lisa_Seeman> 3.3.1 Provide a clear structure that includes:§ (See COGA Techniques 2.1) Headings and labels are provided that describe the topic or purpose of each section and are easy to find. (COGA Techniques 2.1.2). Consistent styles are used for the same type of information (COGA Techniques 2.1.1). Maintain a consistent look and behavior for icons, navigational elements and controls across a set of pages. Structure and relationships ar[CUT]
ls: When you say pacsti, you can see what it means from bullets. So added the includes. Otherwise won't mean anything.
... Clear structure has a couple of things. If go to US govt there are clear isntructions to put in chunks. We have defined "chunks".
... Consistent styles for headings, for example. Consistent look and feel, quite a lot of bullet points. Defined "clear structure".
... Try to make it clear what is minimal for conformance.
awk: 15 bullet points--is each a sc.
ls: One sc, to meet must include the 15 things listed.
awk: Not suggesting just say "Provide a clear structure."
... Suggeting that all 15 might be sc.
<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria
awk: What we're trying to figure out. Trying to be constrained to how many bullets are acceptible. Not trying to stipulate the number, but as few as necessary.
ls: Why I brought this one up. There's nothing here that we felt was unnecessary. Adding bullet points to meet user needs. If you look at user needs table...
<Lisa_Seeman> https://rawgit.com/w3c/coga/master/gap-analysis/table.html
ls: ...there is a bullet point that relates to it. They all belong together. Can quickly scan list and see if it meets the criteria. If you break it up, it will take longer.
... Huge amount of work that's gone into it. Does the bullet point make ppl to meet the std. Each one is based on research and how to address the needs. No one wants superfluous bullet points.
awk: Some items are already are in there: headings, for example. Not sure why we would want it there as well.
... Maybe become a double A.
ls: Might take an edit and an upgrade. Can include somewhere else if it's an issues. Clear structure doesn't make any sense without headings. Could make it a AA. Not sure want feedback, more that want to make things clear but also covered.
awk: Point is not to critique, but to manage success criteria.
ls: would be happy to drop if it becomes AA
wd: Lisa has a point, a lot of the AAAs were icing on the top. Not worded in most useful way. Some AAA can now be made more extensive, now that TFs are using them.
GL: Nothing against limits to make less overwhelming. But itemss need a unique identifier if they are used for testing. So evaluations can reference.
<jon_avila> I have to jump off the call.
ls: Makes sense (to have #s instead of bullets). Have fewer sc. When things are AAA, ppl didn't bother making them testable, so dk when they are conforming. If have 90% agreement of what consitutes sc, must have all criteria.
awk: When guidance is aspirational, does not to be longer.
ls: Other concern is that ppl say they should be short. Goes against grain. Would like to be short. But trying to draft and have it testable. First draft wasn't accepted bec items weren't testable.
me: sorry other Greg. gl it will be. :^)
<Lisa_Seeman> 3.5.1 The success or failure of every action should be clearly indicated to the user and visual rapid feedback should be available. Spoken feedback should be a user selectable option.
ls: Hard to make some items less convoluted. "Provide rapid feedback". So when not sure look at more complex version. But have to be clear for testing.
gl: While agree taht short and simple is a goal, it often conflicts with clarity. In some cases too short. "Lists are used". Instead, "use lists when tehy are appropriate" which is then ambiguous.
awk: The guidance we're using (as short as possible) also means without sacrificing clarity or intent. If doesn't meet that critera, then have to adjust it. Don't want to set specific limits like "4 bullets"
ls: How about: As short as possible without loss of clarity or testability.
awk: We can be more clear in that regard.
... A little concerned about first example. Proposing a new structure for wcag. Putting existing wcag items under principle 3. Have to consider how to do this in WCAG 2.1 (as opposed to Silver where we can change sturcture).
ls: Seems to me that key is making sure these are met, not how they're presented.
awk: So have to put them into existing structure.
ls: In existing WCAG there is overlap. SC are repeated in some places, bec they are being looked at from different perspectives.
awk: Would anyone like to help put these sc into a more WCAG like format. Send an email and I'll follow-up.
<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria
awk: looking at 2.1 success criteria and then bring before group. BAsedon feedback we've received. Like taking out "only two bullets allowed".
<yatil> rrsagent, draft minutes
<AWK> trackbot, end meeting
Okay--should I keep my window open?
Okey dokey--bye!
<AWK> invite RRSAgent
<AWK> Chair: AWK