<alastairc> Technique approval survey: https://www.w3.org/2002/09/wbs/35422/technique-approvals1/

<jallan> scribe: jallan

TPAC reminder: https://www.w3.org/2002/09/wbs/35125/TPAC2018/

ac: register for TPAC asap

mc: only 4 registered ;(

Silver requirements: https://w3c.github.io/silver/requirements/

ac: have discussed, surveyed, discussed more... new version available.

<jeanne> https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JulSep/0013.html

js: overview ^^^
... comments from discussion and survey were helpful.
... Note: added section Comparison between Silver and WCAG 1 & 2
... Changed problem statement section. thought of using use cases... but decided it was too early
... took opportunity section and move to introduction
... most interesting changes in intro
... edited requirements section, 3.1 in respec - things being measurable vs testable
... research - disadvantage to technology agnostic.... add another layer of abstraction, difficult to understand
... there is a change log at bottom of document

awk: technology neutral ... substantial concern. All guidance on 2.0 is tech neutral. it was a driver for the change from WCAG 1 to WCAG 2
... seem wishy-washy. wants a stronger statement.
... if not tech neutral, then what is Silver targeting

js: looking at a different solution, may not find one
... perhaps use the CSS model... core document (tech neutral), with additional docs that are tech specific

<alastairc> https://w3c.github.io/silver/prototypes/FlavorPrototype/staticWeb.html

js: prototype available... as a way to use tech neutral with different implementation
... just one example.
... will address 'tech neutral' but not sure how we will handle it

ac: what are we saying about things that are greyed out, pdf vs html?
... technology isn't accessible if it doesn't meet the requirement... not always the case
... 'measurable' not everything is measurable. perhaps use ISO model... did you follow a process. concern about meeting COGA needs

brooks: WCAG20 is tech neutral ... good and bad. is there the intent to make Silver be focused on content makers, or will it add browsers and tools

js: mandate is to include authoring tools and user agents. Planning on more than just content creators.
... also looking at future tech, and perhaps guidance for AT, UA etc.

<Zakim> AWK, you wanted to say isn't putting something in as a requirement part of what drives figuring out how to meet the requirement?

brooks: burden has been on the author. has to be some support from software to make a good UX

awk: requirement about tech neutral not being in doc. should be a requirement. not sure what solution looks like, but it should be a requirement. thought working group was clear about this.

js: don't want to tie hands, would rather innovate.

sl: not sure what scope will be yet. moving slowly... trying to stay more general... have a problem want to look at it, but not get too specific, not sure how to solve... vis a vis tech neutral.

awk: working group... Do we want to make tech neutral more prominent. should be a requirement. sounds like its not important

sl: disagree with the statement

<Greg> I would support the broader goal that content using new technologies can pass even if it predates updated to Silver, but if the term “technology neutral” is interpreted as prohibiting referencing or addressing specific technologies that may be stricter than we need.

<Zakim> Greg, you wanted to say that I would support the broader goal that content using new technologies can pass even if it predates updated to Silver, but if the term “technology

gl: part of discussion is about terminology. tech neutral as a term ... cannot address specific technology by name is problematic.
... perhaps break out terms - things can pass if a new technology, useful to address specific technologies

sl: agree. called this out

<Greg> I have strong concerns with a process-oriented approach because of the failures of things to VPAT used by Section 508, which focused on process and disclosure over actual accessibility for users.

gl: strong reservations about only being based on process. need accessibility to end users.

ac: not all process, just some.

khs: change is hard. should not be married to tech neutral. matrix of interaction paradigms and channels is only going to grow. must be open to unknown tech.
... have a core, then expand for new or specific tech
... very attached to some terms, but things need to change.

<Zakim> alastairc, you wanted to say that I think a layer will be tech-neutral, but the next layer (perhaps) will be tech-specific

khs: need completeness and quality

ac: a layer of silver should be tech neutral. upper layer. What is underneath is critical. In wcag have tech neutral with SC working across tech. needs more discussion

<Glenda> Hi Ho Silver!

dm: what is silver thought on agwg working on silver next vs wcag2.2

ac: abject terror??

sl: we are still prototyping, experimenting - information architecture. WCAG changes is a much larger discussion

ac: need the group to have a deeper view of the document before more discussion

mg: is it ok to add issue comments?

js: just transitioning to github. working into personal workflow. good comments, thank you

mg: in process of responding to TPAC. if tandem meetings WCAG and Silver--- conflict?

ac: may be working together... still in discussion.

js: meeting on same days...possibility of working together.

mg: personal time and location constraints (needs a time turner)

awk: so comments are being give... then what?

ac: document is community report.

js: can publish as TR or community group report

mc: could be TR NOTE, but it is constraining

sl: main goal... that AGWG has input on content, direction, and goal.
... these discussions are sanity checks... did we missing anything, regardless of where published

Technique approval survey: https://www.w3.org/2002/09/wbs/35422/technique-approvals1/

ac: will have a survey soonish... keep watching for it

<alastairc> https://www.w3.org/2002/09/wbs/35422/technique-approvals1/results

ac: 1 technique for group approval after 5 folks review
... if we can address them today could publish tomorrow. otherwise .... next week
... technique for testing

awk: technique should not restate success criteria. what does author need to do to meet SC
... technique -- make sure containers are flexible using html and css
... basically saying don't cause problems. it is not enough, restates SC.
... things the author needs to do to not cause problems should be focus of technique.

ac: no specific CSS to point to, other that have space inside containers for text to expand

awk: if we can find one thing that will meet the SC, then that is the technique. needs to be more than how you test it.

mc: if no specific CSS then it is a general technique.

ac: improve testing.

<Ryladog> +1 to Alastair

ac: need a step 4 look for text overlap

mg: CSS techniques seem to have a specific format and language. will review more. this is a combo technique. CSS cannot be method of testing if not using CSS

awk: many ways to meet SC

brooks: vertical container is not set in fixed units. use relative measurements...

ac: not that straight forward. if you have a fixed height then text will not wrap properly. basic principle - no fixed height with horizontal buffer for text expansion.

awk: don't constrain height and width of containers is basic technique.

<alastairc> height needs to be un-restricted, and width needs be have sufficient to allow for the largest word(s) with extra spacing.

awk: many techniques with a similar test procedure.

lc: general technique with 2 specific techniques?

awk: not sure what general technique is. what is the heart of the technique

lc: a test procedure

awk: but need to answer when developer says "i failed test" what do I do to fix it

ac: 2 techniques, CSS example with small box with fixed width, then with flexible box

<kirkwood> No

awk: is there a way to meet the SC without CSS?

<kirkwood> Agree with Andrew. Don’t think you could do without CSS

<jon_avila> what does that mean to not use containers?

awk: not use css at all, then everything reflows. Need to make specific CSS techniques

mg: what causes a failure? describe those failures, then how to fix it - lots of css in combination

ac: in testing - issues were fixed height, etc. easier to find failure techniques.

mg: is there a way constrain containers and still pass?

ac: use passing and failing examples
... come full circle. starting again.

<gowerm> scribe: gowerm

Review technique queue: https://github.com/w3c/wcag/pulls?q=is%3Apr+is%3Aopen+label%3A%22Ready+for+initial+review%22

AC: We have a queue. There are 4 not quite ready to go to the survey. If it arrives here we are looking for 4 other people to give it a thumbs up. It if passes that, then it can go to a Tuesday review.

<alastairc> https://github.com/w3c/wcag/pull/417

AC: We just need one more review on our Failure of viewport units.
... Any comments or questions?

Gestures issue review: https://github.com/w3c/wcag/issues/403#issuecomment-401413996

AC: This is around the 2.5.1 Pointer Gestures. It comes down to drag-and-drop scoping.

<alastairc> https://www.w3.org/TR/WCAG21/#pointer-gestures

AC There are some good examples. Detlev's proposed answer (to himself) is that drag and drop is not covered. While it involves a path, it is not a predefined gesture.

AC: Any objections or questions?

Detlev: Where a user does a lot of effort into making drag-and-drop keyboard accessible, there was a potential that the drag and drop would also need to provide extra pointer controls to allow for single pointer activations

DM: I wouldn't agree that drag and drop is dependent on path.

<jon_avila> With David's definition it would say swipes aren't paths and it's ok to use swipes without equivalents

Detlev: If you put your finger down and drag it to another location, there is a path. Drag and drop can be seen to fall in within this phrase

<Greg> It may involve a path but I would not call it path-based, as the path is not important to the process.

AC: jon do you want to speak to your comment?

<jon_avila> sorry I can't unmute

AWK: Part of the reason this is there is because of mobile
... On an iPad, you would click on the move button, then click on some other point.
... Our focus was to have things work with someone who just has a single pointer. This seems doable. It's hard, but...

Detlev: I agree there are ways to do it, but that they are also hard.

AWK: Someone's way of dealing with this might be to do drag and drop however they want, but add in another method.

AC: You might need some kind of mode

Jon: What I think I heard David say is that DnD is not a path-based gesture
... By the same reasoning, you could allow swipe gestures

DM: I was trying to recall our historical discussion.

Jon: But if we restrict it that far, then we are potentially affecting swipes

<Zakim> Greg, you wanted to say drag-and-drop may potentially trace a path but I would not call it path-based, as the path is not important to the process.

<Greg> Drag-and-drop may potentially trace a path but I would not call it path-based, as the path is not important to the process. (Also important to note that it may not use one at all, e.g. when accessibility aids are involved that let the user move the pointer from point A to point B without necessarily tracing the path between.) The SC only applies to functionality that uses “path-based...

<Greg> ...geestures”, not those that happen to trace paths. I would simply explain the difference.

Greg: We should clarify the difference between path based and something that may or may not involve a path.

Detlev: I'm not sure what you said.

Greg: It comes down to how one defines drag and drop.

<jon_avila> Drag and drop is more concerned with start and end points and not how you get there. A path is more about falling a specific route

<david-macdonald> 2.1 ... except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Greg: That is a clear point of ambiguity

<david-macdonald> 2.5.1 uses "Path based gesture" 2.1.1 uses "depends on the path"

Greg: When I used that term, it was whether a specific path was involved

AC: I think there is some scope for us to make a choice.

<Greg> We should clarify our definitions of drag-and-drop and gesture-based, and perhaps multipoint.

AWK: Where the whole path dependent phrase came from is from Keyboard.
... I have a harder time seeing how drag and drop fits into the new SC.

DM: I think we're okay. I pasted in the text from keyboard.
... As well, drag and drop is not a gesture.

Any other business

DM: What do we do about decisions on direction, regarding silver?

AC: We currently have plenty to do on the 2.1 documentation. We have a decision on 2.2, but that won't be included in the charter until the end of next year.

DM: And we have no charter to work on silver?

AC: Not officially. That doesn't mean we can't participate as we are.
... AWK, do you have a clearer vision?

AWK: I don't think I do. We have a lengthy chair call for Friday to cover this.

AC: I think we could cherry pick a dozen or half dozen to include in 2.2. That's my personal opinion.
... We haven't decided how much time we will spend on Silver at TPAC. Much may happen before then.

<alastairc> MG: At TPAC, we have WCAG & Silver on the first 2 days. Wondering about the degree of overlap, is that an opportunity.

<alastairc> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/definition/definitions/
Default Present: Laura, alastairc, Makoto, Glenda, Kathy, Brooks, Greg_Lowney, JF, marcjohlic, MichaelC, bruce_bailey, AWK, Katie_Haritos-Shea, Detlev, gowerm, Chuck, jeanne, JakeAbma, jallan, KimD, Lauriat, jon_avila, kirkwood, Mike_Elledge, 1
Present: Laura alastairc Makoto Glenda Kathy Brooks Greg_Lowney JF marcjohlic MichaelC bruce_bailey AWK Katie_Haritos-Shea Detlev gowerm Chuck jeanne JakeAbma jallan KimD Lauriat jon_avila kirkwood Mike_Elledge 1
Found Scribe: jallan
Inferring ScribeNick: jallan
Found Scribe: gowerm
Inferring ScribeNick: gowerm
Scribes: jallan, gowerm
ScribeNicks: jallan, gowerm
Found Date: 10 Jul 2018
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.)