See also: IRC log
<scribe> Scribe: Glenda
AWK: We need scribes for next Tuesday. Please volunteer.
<AWK> Please sign up: https://www.w3.org/WAI/GL/wiki/Scribe_List#2017_Scribe_History
AWK: reviewing survey results. Steve what are your concerns?
<AWK> Current SC text: Functionality requiring a custom complex gesture can also be operated with single point gestures unless the use of a complex gesture is essential.
<AWK> defintion text: A timed or multi-point gesture. Examples of a multi-pointer gesture include two-finger pinch/zoom
<AWK> (Complex gestures)
Steve: see my comments, needs to be clearer. “I think the note saying this doesn't apply to user agents needs to be moved into the criterion itself for future-proofing and to align with other criteria.”
Detlev: timed single point gesture would be a complex gesture by the definition. Also, this is a bit touch centric. Could add a second example, like mouse drop and drag. We could replace single point gesture with “tap”.
<alastairc> is it a case of simple = single, complex = multi-pointer?
Alex: Unsure about Steve’s concern. Complex is multipoint and timed. LIke a capital T (horizontal and vertical) time and multipoint.
Steve: a singlepoint gesture is just a tap or a click.
Alex: It also includes a swipe.
... You could draw a number 2 with a single stroke. Hard to draw a T with a single stroke…tend to do two strokes.
<Kathy> Single Point Gesture - a single stroke, tap or click action to perform an action
Steve: would touch and hold be timed? And complex?
Detlev: Yes. touch and hold would be timed and therefore it would be complex.
Kathy: all functionality could be accomplished with “single point gesture” see definition above. (with exceptions)
<alastairc> E.g. Functionality can also be operated with single point gestures unless the use of a complex gesture is essential.
Kathy: need exception about complex gestures.
Steve: easier to have just 1 definition for simple point gesture, for clairty.
<Kathy> All functionality can be operated with single point gesture except where ...
<alastairc> oops, pasted wrong bit, I meant: "Functionality can be operated without complex gestures unless the use of a complex gesture is essential."
<Kathy> All functionality can be operated with single point gestures unless a timed or multi-point gesture is essential.
<Kathy> All functionality can be operated with custom single point gestures unless a timed or multi-point gesture is essential.
Alex: this SC does not intend to imply that the user agent or OS rely on complex gestures at the OS level.
<alastairc> Isn't that already there? "This requirement applies to web content which interprets pointer gestures (i.e. this does not apply to gestures that are required to operate the user agent or assistive technology)"
<Kathy> All functionality can be operated with single point gestures unless a custom timed or multi-point gesture is essential.
Alex: simple vs complex - only use a single point gesture unless a more complex gesture is essential.
<Ryladog> OK
<Zakim> AWK, you wanted to say that the double-tap isn't implemented by the author but by the AT
AWK: I think the double tap is based on OS. Note to clarity would be good.
<AWK> Proposed: All functionality can be operated with single point gestures unless a custom timed or multi-point gesture is essential.
Kathy: what about this: “All functionality can be operated with single point gestures unless a custom timed or multi-point gesture is essential.” don’t need definition of complex…because we describe it in the exception.
<Kathy> Single Point Gesture - a single stroke, tap or click to perform an action
<Alex> please remove custom
Kathy: add definition of single point gesture.
<Kathy> All functionality can be operated with single point gestures unless a timed or multi-point gesture is essential.
<alastairc> Should it be "Single pointer-gesture"? what's a "point" here?
<Detlev> +1 to Kathy's rewording
<Kathy> All functionality can be operated with single pointer gestures unless a timed multi-point gesture is essential.
Alex: All functionality can be operated with single point gestures. Do we need to add “untimed” to this part of the requirement? Or removing timing from exception.
<Kathy> All functionality can be operated with single pointer gestures unless a multi-point gesture is essential.
Jason: problem is single point gesture does not specify if it is timed or untimed.
<Kathy> Single Point Gesture - a single untimed stroke action to perform an action
<Kathy> All functionality can be operated with single pointer gestures unless a multi-point or timed gesture is essential.
<marcjohlic> +1 ^
Alex: add note about gesture related to content, not user agent or OS
Detlev: that note is already present
<Kathy> All functionality can be operated with single untimed pointer gestures unless a multi-point or timed gesture is essential.
+1
<Kathy> All functionality can be operated with single untimed pointer gesture unless a multi-point or timed gesture is essential.
<Detlev> +1 - thanks for this stroke of genius!
<Kathy> +1
<marcjohlic> +1
<Kim> +1
<chriscm> +1
<kirkwood> +1
AWK: what do people think? Ready to put in editor’s draft, and request comments from the public?
<steverep> The note needs to be in the normative text like many other SC
Steve: concern about time not being an option. 2.2.1 timing adjustable
<alastairc> +1, with a minor thing, would like a hyphenation added: All functionality can be operated with single untimed pointer-gestures unless a multi-point or timed gesture is essential.
<Rachael> +1
AWK: 2.2.1 is time limit. That is different than your double tap didn’t count because you didn’t tap quickly enough.
Detlev: this would not prevent authors from using complex gestures, you just also need a simplier gesture.
AWK: or if the complex gesture was essential
<Kathy> We have this note: This requirement applies to web content which interprets pointer gestures (i.e. this does not apply to gestures that are required to operate the user agent or assistive technology).
<AWK> Note: NOTE This requirement applies to web content which interprets pointer gestures (i.e. this does not apply to gestures that are required to operate the user agent or assistive technology)
AWK: Any objection to accepting as amended
<JF> +1 to the amended text
RESOLUTION: accepted as amended
<david-macdonald> zakim make minutes
AWK: reviewing survey results
<AWK> https://rawgit.com/w3c/wcag21/ePub-metadata/guidelines/#conformance-optional
<AWK> A list of specific accessibility characteristics of the content, provided in machine-readable metadata.
AWK: not realistic for all web pages to include this. Is optional for a WCAG conformance claim. But may be specifically request for ePub.
JF: There are SC in WCAG 2.1 proposal that are dependent on metadata, related to some COGA SC Concerned about a disconnect
David: meta data in triple A is about controls and identify them. This is more a global metadata about the content.
JF: worried that the wider audience may not clearly understand this nuanced difference.
... can we be stronger and require this metadata for the ePub.
<alastairc> Isn't this coming back to the issue about the unit of conformance in WCAG being a page? This applies across pages.
<AWK> \invite RRSAgent
Avneesh: we support making it stronger, but with such little time left between now and Aug 22, we were willing to compromise
<alastairc> I can hear everyone
<Alex> no audio
<david-macdonald> we hear youy awk
<Avneesh> not able to hear
<kirkwood> audio gone
<Alex> dialing back in
<George> I will caall back in.
<david-macdonald> looks like phone is gone
<chriscm> #disaster
<david-macdonald> If you called in on phone we lost you
<david-macdonald> looks like it will be ok if you call back
<alastairc> JF: I wasn't sure if I was missing something that's all.
Lisa: in appendix it says “understanding metadata”…I think that needs to be changed to “understanding metadata for conformance claims”
<david-macdonald> +1 simple change
<JF> +1 to Lisa's point - which is related to my concern/comment
Jason: improves discoverability, doesn’t improve accessibilty. Clearly stated as a way of declaring conformance.
AWK: Vote in favor of it being in the conformance section?
<Zakim> JF, you wanted to respond to Alastair
Jason and David agree.
JF: may not be making content accessible today, but it could make it accessible tomorrow. Want to echo Lisa’s concern that we are talking about two different types of metadata here. This is likely to cause confusion.
AWK: Can JF or Lisa open an issue in github around understanding metadata
<lisa> ACTION: Lisa add issue that we need to update metadata section [recorded in http://www.w3.org/2017/08/17-ag-minutes#action01]
<trackbot> Created ACTION-339 - Add issue that we need to update metadata section [on Lisa Seeman-Kestenbaum - due 2017-08-24].
<JF> +1 to Katie - GPII will depend heavily on metadata
ryladog: understanding metadata needs to be updated. can be done after we get this off the ground. prefer it to be in the conformance section.
<david-macdonald> Here's the undersand metadata proposals https://github.com/daisy/epub-revision-a11y/wiki/WCAG-Discovery-Metadata-Proposal
AWK: support for having in conformance section and being clear about comparing and contrasting metadata related to conformance and metadata related to things like coga. Do people think this is ready for editor’s draft (to receive public comment).
<david-macdonald> yes
Alex: just to confirm, this is still optional.
AWK: yes. optional
<Rachael> +1 to including in conformance claims
<Ryladog> Understanding Metadata section needs to be updated to talk about the two things that metadata is designed to do. 1. Information about additional resources related to the content AND, 2. information about the resources irself.
<JF> +1 to including in conformance claims
RESOLUTION: Accepted as proposed.
<david-macdonald> can someone let me know what happened with PointerGestures (missed fist 30 min)
AWK: reviewing survey results
<AWK> Current SC text: All pointer functionality can be operated using screen coordinate information, without requiring additional pointer sensor information except when the underlying function requires input beyond x/y coordinates.
Steve: taking a valid user problem and scoping it out so all "additional pointer sensor information" is inaccessible and how does timing fit in?
<Kathy> Additional Pointer sensor information: pointer information beyond position, such as pointer pressure (for instance on pressure-sensitive touch screens), pointer tilt or/and pointer twist (for instance on advanced pen/stylus digitizers)
<Zakim> JF, you wanted to ask what is screen coordinate information, and what is the content author being asked to ensure?
JF: what is screen coordinate information. What are we asking content author to do here?
Detlev: not covering real cases right now, idea is content author having access to tilt of a pen, or pressure of a pen…that this would not be good to allow.
... it seems to go in circles. Not sure if we should wait until the next iteration of WCAG
Kathy: yeah, I would fine too with detlev’s proposal to leave this for later. Cover scenario of pen or stylus on a touchpad, with additional sensor information of tilt, pressure, twisting…
<david-macdonald> thx Alastair
<Kathy> https://github.com/w3c/wcag21/issues/66
JF: +1 to holding back on this (also showing as “A”…needs to wait and not be single “A”
Steve: if holding until next round, let’s punt it to 2.2
<alastairc> I see the theoretical need, I haven't come across an instance yet.
David: this deals with something other that x and y axis. like tilt and pressure. Okay to wait if everyone understands what this is referring to.
<JF> I can "understand" this, but if this is about digital pens and other stylus events, then we should be calling that out in the SC
<steverep> +1, defer not ignore
<Detlev> We need to collect some tangible use cases, then take up for WCAG 2.2
<JF> +1 to Defer to post 2.1
<alastairc> +1 to defer
Michael: we should have a parking lot for this so we don’t forget it
RESOLUTION: Defer for later consideration in WCAG 2.2 or later
Jim: posted updates in the survey as a response recently
<alastairc> Jim's updated text: Where a page can be printed, essential information can be printed with no loss of content and or adapted text properties.
<AWK> LVTF proposal: Where a page can be printed, essential information can be printed with no loss of content and or adapted text properties.
Jim: thing it does not include is zoom factor. We dropped zoom. The remaining part is important for low vision. Ability to print is valuable as a way to see the content.
AWK: what is definition of adapting text?
Jim: the adapting text proposed SC covers that
<allanj> https://rawgit.com/w3c/wcag21/adapting-text_ISSUE-74-78-79/guidelines/sc/21/adapting-text.html
jamesn: what is defined as content here? print stylesheets remove things in a printed form. Like buttons may be removed because they aren’t useful in a printed form.
Jim: yes, that is allowed
<allanj> https://rawgit.com/w3c/wcag21/adapting-text_ISSUE-74-78-79/guidelines/terms/21/adapt.html
JF: problem of determining what is essential. print stylesheet may remove button. Is that essential? Worried about consistency in interpretation.
<Alex> what's essential is up to the author to decide
<alastairc> "essential" as a term has been reasonably solid, but this is a different context (print) than we normally use it.
Shawn: essential is already defined
<alastairc> things which are essential as a web page are not essential on a printed page.
Lisa: there is stuff we can do after next week. These kind of things can be clarified in techniques.
<Ryladog> I agree with Lisa
<allanj> or add to understanding document. and technizues
<shawn> +1 to Lisa that tweaking can wait. Address main issue now.
I agree w Lisa
<allanj> https://rawgit.com/w3c/wcag21/adapting-text_ISSUE-74-78-79/guidelines/terms/21/style-properties.html
<shawn> https://www.w3.org/TR/WCAG21/#dfn-style-properties
Steve: look at adapting style properties
<Ryladog> Style Properties New properties whose values determine the presentation (e.g. font, color, size, location, padding, volume, synthesized speech prosody) of content elements as they are rendered (e.g. onscreen, via loudspeaker, via braille display) by user agents Style properties can have several origins: user agent default styles: The default style property values applied in the absence of any author or user styles. Some web content technologies specify a d[CUT]
AWK: do browsers do this today?
JIM: if a page is poorly written, the author can break -- and if the page and print CSS is well written, then then it can work well
Katie: Yes, it is supported by browsers
AWK: adober reader prints as author defined it. I dont know if other pdf readers do otherwise.
Katie: that is jus one user agent (Adober Reader). This is relevant to all web contnet and user agent. This is not just about PDFs.
AWK: I’m asking questions about feasibility. We need to ask, is this possible with mobile browsers, word documents. Just asking.
<shawn> yes, possible with Word docs.
David: implementability is difficult. I would suggest punt to later post WCAG 2.1
<JF> This is likely not the time or place, but what (if anything) does print layout have on this SC? i.e. Portrait versus Landscape?
Jim: not a browser issue, it is an author issue. Author can truncate text.
<shawn> agree, not primarily a browser issue
JF: how does content author know portrait, landscape, different paper sizes in different countries….lots of unanswered questions here.
Alastair: There is such a thing as responsive print design.
Lisa: it is harder on people with low vision
<shawn> s/responsive web design/responsive print design. If set things in screen, then browser will print well, albeit plain.
Lisa: need for people to print is higher for people with low vision
JF: is end game “ensure you provide an accessible print style sheet”?
Jim: that would be the technique. SC should not be prescriptive.
Shawn: Alaistair gave example of printing work fine if don't mess with print CSS. The thing we're saying is to avoid things that will mess it up, make sure you don’t mess up accessibility
<lisa> I just here one objection
RESOLUTION: leave open for more discussion