<JF> can I please get the correct WebEx dial-in info? The URL in Andrews Email claims the password is incorrect...
<Lisa_> what is the call in info?
<laura> Scribe: Laura
<AWK> Wiki page: https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-14
awk: We have wiki page and survey
<scribe> …new version that was discussed at TPAC in si tne Wiki page.
Current Draft SC text: https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-14
Proposed: changes it to: “When
pointer hover or keyboard focus triggers additional content to
become visible, the following are true: “
... Dismissable: The user can dismiss the additional content
without moving pointer hover or keyboard focus, unless the
additional content communicates an input error or does not
obscure other content;
Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved to hover the additional content;
Persistent: The additional
content remains visible until the hover or focus trigger is
removed, the user dismisses it, or its information is no longer
valid.
... Exception: The visual presentation of the additional
content is controlled by the user agent and is not modified by
the author.
WK: mixed bag of survey responses.
<Lisa_> now esc key in mobile
WK: David asks: Does that mean we require the ESC key to be bound to close it? Not sure how this helps, but I might be missing something.
<Lisa_> and it is a standard pattern that can change
<Lisa_> so enfoceing a key doesnt make sence
WK: no it doesn’t.
josh: wondering about ESC.
awk: steve has pull request.
steve: pull request is what is in
the wiki.
... mostly.
... The proposal is here:
http://rawgit.com/w3c/wcag21/hoverable-and-persistent/guidelines/#content-on-hover-or-focus
... ldded the following to the pull request:
* Address concerns for dismissal in Persistent bullet
* Sync use of "trigger" and "additional content"
* Correct subject of initial sentence to be the action and not the component
awk: walks through SR’s proposed
changes.
... no dispute on first 2.
... no specific action is needed for the 3rd.
... but content is going to stay visible.
... until I tab or kb shotrcut to close. Gives user
control.
alex: positioning is not
here
... popup must to cover/obsure something.
... where can you put the popup? the or condition can’t be
met.
steve: it can cover white space.
alex: If your screen has no white space where does it go?
awk: in a toolbar you can use esc
or shortcut.
... what is the rationale?
steve: did you read the undersrtanding?
alex: did you update it?
stve: not since tpac.
steve: repositioning by itself is not accessibile.
awk: is it a problem if we add in not obsureing within the tigger.
steve: no.
... think about a merga menu. Lots of tabbing. need to dismiss
it.
... esc key is easy to do. recommended in ARIA.
... former language was focuesed on trigger
jason: we have proposal for
expanding to distraction and obscuring content.
... not sure about white space. Need clarification for this
proposal.
MP: not sure we need the last
exception.
... don’t see the purpose.
lisa: 2nd bullet point.
... doesn’t the first bullet imply the second?
awk: yes.
<KimD> Re "Persistent" clause; I think it's so someone can move the hover or scroll the screen to see the whole pop-up.
user needs to be able to hover over and read content.
scribe: current draft is easier
to undersrtand than the second.
... current draft explains the scenario.
<steverep> See understanding: https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html
scribe: first half of the sentence is simiar to the second.
awk: I don’t know. not sure. Do you have language suggestions?
<Lisa_> If pointer hover can trigger the additional content, then the pointer can be moved to hover the additional content; so that the content remains visible when the pointer is moved over it;
<AWK> If pointer hover can trigger the additional content, then that content remains visible when the pointer is moved to hover the additional content;
josh: thinking how this could
help persistent menus
... asking steve if there is anything about persistance in
Undersrtanding.
<Lisa_> is this testable?
Steve. yes but can add to it.
Steve: yes but can add to it.
MP: have not heard reponse to my question.
MG: Josh, tiggering from hover or focus is an not a solution.
josh: take your point.
MG: blind user scenario. need to be able to dismiss via keyboard.
alex: agree with MP
... hoer over over then hit escape is out of the ordiary.
<Zakim> steverep, you wanted to offer a small example for not obscruing other content - open to language changes but making it trigger only negates the benefit for mega menus
alex: would confuse vart majority of users
steve: couple of senarios.
... staus bar. part of exception.
... last bullet was cahged to response to james.
... repsonding on focus.
awk: status bar covered by exception.
steve: not author created status bar.
awk: remove obsure phrase?
<KimD> I'm for removing the "obscuring" language
awk: anyone object?
<steverep> Sigh...
<Detlev> +1 fine with removing
awk: positioning is another issue that alex raised.
alex: very broken.
... still have to satisfy the first bullet.
... terribile for the user.
steve: you don’t fail the first
one.
... you don’t have to dismiss.
... does not change anything.
awk: need discuss positionngand what use experience is aceptable on list and github.
RESOLUTION: Leave open
awk: open CFC on this one.
... steve raised concerns on this one. He has new language.
<AWK> Current: A mechanism is available to view and operate content in portrait and landscape orientation, except where a specific display orientation is essential.
awk: email: https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0543.html
<AWK> New proposed: Content does not restrict its view and operation to only portrait or landscape orientation, unless a specific display orientation is essential.
<gowerm> +1 to new wording
awk: legitimate concern
<Joshue108> Nice
<Glenda> +1 to new wording (well done!)
awk: This would still make a tester working on airline seatback content think for a minute about how this would be tested, but we can document that it doesn’t matter in those situations, just like it doesn’t matter if you are delivering for a device that doesn’t support orientation changes at all – build the content correctly and it will work in places where it can work.
<Detlev> +1 Much better wording because it gets rid of the 'mechanism' language which invites misinterpretations!
jason: has an editorial change
sent to list.
... .change “only” to “either”
<AWK> New Jason's proposed: Content does not restrict its view and operation to either portrait or landscape orientation, unless a specific display orientation is essential.
<Alex> there are others for vr
<Alex> and ar
shadi: do we want to be that restrictive? may be better to leave it open.
<gowerm> Either works fine for me
shadi: maybe “such as” instead of “either”
<Detlev> such as is fine
alex: concerned applicability.
example: VR
... when viewing a presentation you don't tilt your head.
MP: spotted english problem.
<Zakim> gowerm, you wanted to say I think "either" and "only" is just editorial. The gist is there and it can be clarified in the Understanding doc
MP: needs “either” not “only”.
<marcjohlic> +1
<jasonjgw> Responding to Shadi "Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential."
MG: can address in understanding.
<Zakim> steverep, you wanted to say orientation is defined by the display relative to the hardware screen and nothing else
<kirkwood> portrait and lanscape is the language that should be used. shouldn’t the wording be aspect ratio rather than orientation?
<shadi> +1 to jasonjgw
<kirkwood> we are talking about “aspect rati” to me. grphic design words
steve: orientation has nothing to do with hope you are viewing it.
<kirkwood> correct what is being siad right now
<kirkwood> +1
MP: “only” is ambiguous.
<steverep> "either" is fine... I'm not married to "only"
JK: orientation of text would change rotation. Designers will be confused.
<AWK> Jason: Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.
Jason: proposal "Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.”
<kirkwood> think need to eliminate term “orientation”
<Mike_Pluke> +1
<kirkwood> switch too “aspect ratio”
awk: we are talking about display orentation. Can address in understanding.
<shadi> [[we have glossary term that can be updated as needed]]
awk: APIs can make it confusing.
scribe change?
<gowerm> scribe: gowerm
<laura> thanks mike.
<kirkwood> thats on the user agent side
Shadi: I want to echo what Andrew just said. We have a glossary term. It references this css orientation. It's what developers know. I don't think we should change the terminology at this stage.
AWK: Since it is web authors, and we want to make sure they don't alter the screen orientation, can you live with this if it is clarified in the Understanding doc?
John: If we're talking about it
staying this way due to an API, then I can't give input. But as
far as changing aspect ratios, which seems to be what we're
talking about, then I can.
... Specifically to see more, as with any iPad or devices.
AWK: Right now devices aren't
square, but if there were, it could have the same aspect ratio
in more than one orientation.
... Does anyone have objections to Jason's revisions?
<Zakim> KimD, you wanted to comment on "does not restrict"
Kim: I like the language
approach. We do want to say that if the OS/browser supports
something, then authors don't disrupt.
... THis is near the original language we had, and someone
objected to the way it was phrased. I want to flag that.
Personally I prefer it this way.
<steverep> +1 to amended
RESOLUTION: Accept SC language as amended.
<Brooks> +1 to amended
<Glenda> +1 to amended :)
<shadi> +1
<kirkwood> +1
<KimD> +1
<JakeAbma> +1
<Mike_Pluke> +1
AWK: This one also is one we
talked about. There were concerns that were raised, and we were
trying to address.
... Detlev, were you involved with this one?
Detlev: I sent a wording change
to the list, whick responds to John's concerns.
... John saw we didn't expressly say whether long presses and
double-clicks would be okay. I've taken out "untimed" in
single-pointer.
<Detlev> All functionality which uses multipoint or timed gestures for operation can be operated with a single-point activation, unless a multipoint or timed gesture is essential.
<Alex> can we simply to say "All functionality can be operated with a single-point activation, unless a multipoint or timed gesture is essential."
<Detlev> While it is preferable that authors use untimed input gestures, timed single-point gestures such as long press and double click count as single-point activation.
Detlev: This addresses some
scenarios James brought up.
... Jason argued this would remove much of the benefit, but I
think all the multi-touch and swipe/drags would still be
covered.
AWK: I put this back on the agenda because of the notes. One of the comments potentially we didn't really address.
Jason: It reduces the benefit by
excluding cases we have names for. The question is how much it
reduces the benefit.
... What we should do is consider whether in silver this should
be addressed properly
... A glossary definition could help.
Alex: I acknowledge this is a problem with people with hand-eye coordination issues, but absolutely the way to deal with this might be in Silver. I'm not sure there is much difference between swiping and drawing a line.
<AWK> Alex: All functionality can be operated with a single-point activation, unless a multipoint or timed gesture is essential.
Alex: So I think restricting to multi-point might be the way to go. I have pasted in a simplification of the language.
AWK: I think the two seem identifcal in terms of result.
<Zakim> steverep, you wanted to ask if Timing Adjustable can just apply to the "timed" gesture aspect
Steve: I'm wondering if the problems about timing can be covered under timing adjustable. Not 100% perfect fit, but maybe can apply.
AWK: Timing adjustable does say "for each time limit set by the content..."
<Alex> i doubt people think of using the timing adjustable in this way
AWK: I guess the question would whether double-clicks would be setting a time limit.
Steve: If they are not using ondoubleclick, they would have to use their own timing.
Detlev: The suggestion of using Timing Adjustable does not really fit, because it is not talking about time limit. Timing is just a way of saying You have a gesture that starts at one point and ends at another point.
<Zakim> gowerm, you wanted to say that timing and start and end points with a path are different considerations
Detlev: We started with wording
similar to Alex's, but then an argument was made that this
should only apply to content that uses multi-point or timed
gestures, and there should not be a requirement for all content
should be single-point activiations. There were concerns at
TPAC it would have to be scoped more narrowly
... A swipe could be anything. It could be a swipe anywhere on
the screen. It may be misleading.
AWK: So you are talking about changing time gestures to path based?
<Detlev> All functionality which uses multipoint or timed gestures for operation can be operated with a single-point activation, unless a multipoint or path-based gesture is essential.
AWK: you have "timed" in the first phrase
<Detlev> All functionality which uses multipoint or path-based gestures for operation can be operated with a single-point activation, unless a multipoint or timed gesture is essential.
Detlev: Now I've left it out in the second one
<Alex> it is too tricky to deal with time
AWK: Do people think we should
get timed out of there?
... The argument has been there are OS objects.
Detlev: Do we need a definition for path based, or can we use 2.1.1?
AWK: I think we can recycle that language.
<Detlev> 2.5.1 Pointer Gestures: All functionality which uses multipoint or path-based gestures for operation can be operated with a single-point activation, unless a multipoint or path-based gesture is essential.
AWK: Do people care about whether
we say multipoint or path-based gestures twice?
... Do we have a definition for single-point activation?
Jason: I'm assuming this is supposed to cover secondary actions as well. There may be a primary action, but a secondary action as well.
<Glenda> I like saying in twice…because I think understanding the exception clause is easier with the words “multipoint or path-based” words directly in that clause.
Jason: An author could define a path- or multi-point actions as a secondary.
Detlev: The idea was not to rule
out the use of gestures, but to ensure there is an
alternative.
... So a slider activated by sliding would need another method
of increasing/decreasing the slider setting.
<AWK> All functionality can be operated with a single-point activation, unless a multipoint gesture or a gesture that depends on the path of the user's movement is essential.
AWK: So here's an example that incorporates Alex and Jason's versions.
Detlev: We may get pushed back on that, I'm not sure
Jason: That version is good as far as I'm concerned.
Alex: Sorry, it took me a while
to find a mute button. I think this particular text about the
path of users movement is repeating a problem we already have
in our keyboard. SC. For example, if you need to use a
microphone to do something, how does it apply here? It has
nothing to do with the path. It has nothing to do with
pointing.
... I have problems with an exception this carved out only by
the users path.
AWK: If you are saying hey Siri, that is not covered.
Detlev: But we are talking about pointer gestures, not voice activation.
AWK: And that's why I think we need to put back the language that you suggested we remove.
Alex: Yes, I think you may be right. I just became overzealous.
<AWK> All functionality which uses multipoint or path-based gestures for operation can be operated with a single-point activation, unless a multipoint or path-based gesture is essential.
AWK: So that puts us back with language that is something like this.
<Zakim> steverep, you wanted to ask if the entire intent here would be covered by Motion Actuation?
AWK: I'm inclined to go with this and figure out if we get feedback that says this is confusing. We know what this is talking about, and we need to ensure its clarified in the understanding document.
Steve: I would not object to the
latest, but I'm wondering this cannot be combined by something
I proposed which was about motions activation
... We can put this in for now, and think about combining them
later.
Jason: I don't mind the language. I would suggest putting a glossary definition in for 'path based', because you are using the same phrase twice.
AWK: Input that depends on the
path of the user's movement and not just the endpoint?
... What do people think of this as a good glossary item? Is it
needed?
<laura> +1
<AWK> "Path-based gesture": User input that depends on the path of the user's movement and not just the endpoints.
AWK: That's my starting point for
this one
... Any thoughts/concerns/amendments?
<Detlev> 1+
<Glenda> +1 to a definition….so many people don’t know this…so a glossary definition would be great
Detlev: Looks good to me
<JakeAbma> +1
<laura> +1
<KimD> +1 to both having and using yours
<steverep> +1
<Brooks> +1
AWK: Let me find my latest version of the SC language.
<AWK> Proposed SC text: All functionality which uses multipoint or path-based gestures for operation can be operated with a single-point activation, unless a multipoint or path-based gesture is essential.
<KimD> +1
<AWK> And "Path-based gesture": User input that depends on the path of the user's movement and not just the endpoints.
<Glenda> +1 (love it!)
<Lisa_> +1 :)
<marcjohlic> +1 to both
<KimD> +1
<JakeAbma> +1
<Detlev> +1
AWK: Any objection to accepting this as amended?
<Lisa_> looking good
RESOLUTION: SC language accepted as amended.
AWK: We just resolved two CFCs entirely.
<Lisa_> brake?
<Glenda> I show we just have 14 mins left
AWK: According to our schedule, we have 15 minutes left in the call. Is that right, or is this a three hour call?
AWK: We were also going to talk
about target size. Let's talk about that with the expectation
were not going to complete it in the next 15 minutes
... Originally target size had six exceptions. The new version
gets rid of a bunch of exceptions, either by combining them or
by putting them in the lead in text.
The size of the target for pointer inputs is at least 44 by 22 CSS pixels except when:* Essential - A particular presentation of target is essential to the information being conveyed;* Text Links - The target is a text link with a size that is at least 22 pixels in width or height;* User Agent Control - The appearance of the target is determined by the user agent and is not modified by the...
scribe: author.
AWK: There were comments and concerns brought in about very short link lengths, such as footnotes and endnotes.
<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1/targets
AWK: How people feel about this according to the survey is 4 agree, 3 have some comments.
Jason: The exception where
mechanisms are available on the user agent side to enlarge
targets (without magnification) has been lost and should be
restored.
... Plug-ins and user agent extensions should be allowed to
satisfy this.
AWK: Let's look at the rest of
the comments here.
... Jake said he understands that a link that is at least 22
pixels in width or height is acceptable.
Jake: It seemed to me that we are
losing the fact that is needs to be 22 pixels in one
dimension.
... If we are talking about alphabet links at the top of the
page, wouldn't it be more clear if we said at least 22x22
pixels instead of saying either?
... It doesn't say here specifically 'in a block of text or
paragraph'. It just caught my eye when I saw the new
wording.
<Zakim> KimD, you wanted to ask about text links
KIm: I know we've had a lot of conversation about this. We might have citations where there are multiple citations right next to each other. Is this covered?
AWK: Right now it is saying that if you have a text link, it must be 22 pixels, either by width or height. If you have links that were single characters, you need to make sure that they would probably be tall enough (that would be easier than wide enough).
Jake: Previously we had the problem where if text was re-flowing there could be some kind of overlap between two links' activation area.
<kirkwood> So in the end would a link 22pixels x 1 pixel pass ?
AWK: that's where we're going to have to leave it for today
RESOLUTION: Leave open.
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) Default Present: AWK, JakeAbma, shadi, SteveRepsher, AlexLi, Laura, jasonjgw, Detlev, Glenda, KimD, Brooks, kirkwood, MikeGower WARNING: Replacing previous Present list. (Old list: AWK, JakeAbma, Jan, Glenda, JF, kirkwood, Brooks, Wilco, Joshue108, Laura, KimD, MikeGower, Detlev, Katie_Haritos-Shea) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, JakeAbma WARNING: Replacing previous Present list. (Old list: AWK, JakeAbma, shadi, SteveRepsher, Alex) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, JakeAbma, shadi, SteveRepsher Present: AWK JakeAbma shadi SteveRepsher AlexLi Laura jasonjgw Detlev Glenda KimD Brooks kirkwood MikeGower Found Scribe: Laura Inferring ScribeNick: laura Found Scribe: gowerm Inferring ScribeNick: gowerm Scribes: Laura, gowerm ScribeNicks: laura, gowerm WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 20 Nov 2017 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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.)[End of scribe.perl diagnostic output]