Accessibility Guidelines Working Group Teleconference -- 30 Apr 2019

<laura> Scribe: Laura

<Deltev> My colleague Sonja is lurking once more, hope that is OK

<AWK> +AWK

Starting work on the WCAG 2.2 SC

ac: we had a survey on 2.2 SCs.
... will be having a CFC
... made some edis to the doc.
... looking for small groups of people to work on 2.2 scs

<alastairc> Spreadsheet https://docs.google.com/spreadsheets/d/1yjrfIP9KLqTn_Jlq6-T1JvsqY924R_5z1WI2YLv3obc/edit?usp=sharing

ac: will share spreadsheet.
... dropped one. Make it easy to find help.

<stevelee_> Cell B2 should be COGA or at least partially

<stevelee_> thanks - could not edit

ac: anyone else whant to help with that?

Joanne: I would.

MG: we still haven’t had a discussion of 2.1

ac: 2.1 is still on the agenda.
... we are not completley focosing in 2.2.

Mike E: I would help with easy to find help.

AC: awk signed up for almost everything.
... PL has added an update for one.

(people signing up to work on SCs)

https://docs.google.com/spreadsheets/d/1yjrfIP9KLqTn_Jlq6-T1JvsqY924R_5z1WI2YLv3obc/edit?usp=sharing

ac: let us know if you want any changes to assignments.
... email chairs.

<alastairc> Template: https://docs.google.com/document/d/1YFo6zgmMkGF__Q4_bDmuuvp1j5n-omLlgBGKJOz5aLI/edit?usp=sharing

ac: sharing a template
... outine to get started.
... example using reflow.

<alastairc> Example of filled in example: https://docs.google.com/document/d/1nqJd_gLP59UU67_DZ0A0kuyP3Y3ujNIbexIOhoaw0Bk/edit#

ac: down load template and start filling it in
... then email the others in your small group and set up a meeting.

JF: Primary person kicks it off?

ac: yes.
... next week will not go into details but will have Q&A session

ME: find help is in a different format. Would we edit it to the template form?

AC: yes.

Issues https://www.w3.org/2002/09/wbs/35422/Tech_Und_survey/

<alastairc> https://www.w3.org/2002/09/wbs/35422/Tech_Und_survey/results

522: Pointer Gestures: clarity on path-based language in Understanding document

MG: exception for drag and drop.
... same principle appies to a slider
... want a consistent rationale

<Detlev> SC was meant to remove dragging

MG: want it explainable and understandable

awk: don't think that dragging a slider should be excluded.
... not excluded from keyboard requirement.
... you need to meet pointer gestures.

MG: that is the opposite.
... not dependent on the path.

<jon_avila> Drag and drop is not excluded from keyboard -- but it was excluded from Pointer Gestures

awk: drag and drop shouldn’t apply here.

<jon_avila> Some sliders you can just touch and it moves the thumb to that point

detlev: drag and drop maybe should not be included in pointer gestures.
... may be push back from developers.
... could make a distiction form swipe gestures.
... would like to keep dragging sliders etc. in scope.
... might would distinguish them from free-form drag-n-drop by saying dragging of elements that are constrained (e.g. on a track or similar).

awk: in understanding doc we were thinking about sliders
... “path based gesture" is an undefined term.
... at one time this was called single pointer.
... how do we rationalize?

MG: there is no path where it made any difference.
... exactly the same as drag and drop
... never got addressed.

detlev: dragging was always part of path based gestures.
... fine grained motor control.
... I’m all for keeping it in

ac: nobody no strong opinions.

mg: sc is not dependent on paths

<Detlev> AWK disagree...

awk: would apply to sliders?

mg: usually path doesn’t matter.

awk: in drawing program path would matter.

mg: we are stuck with the sc language.

awk: can’t respond to this right now. reponse is a trial.

ac: would be useful to cover sliders and drag and drop.

detlev: do have to follow a path. It is not free form.

<AWK> "except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints"

detlev: find it artificial argument..

MG: dependent on path.
... hard without motor control. not covered by SC.

awk: more clear with 2.1.1

<Detlev> Well I can live with option C (removing dragging) and prepare a pull request - if the group wants that

seem Like a reasonable approach?

<Ryladog> +1

<JakeAbma> +1

<Chuck> +1

<AWK> +1 to option C

ac: For C (limit the scope to path-based gestures without specific end points), we'll also have to remove the 'dependent on path' language and come up with new language and rationale

<jon_avila> +1

ag: happy to do PR

MG: Happy to do PR

<Detlev> Happy if you do the PR

RESOLUTION: Except respons and create PR

<Detlev> accept resonce C that should be!

605: 1.4.13 Content on Hover or Focus - need some clarifications on two points

ac: kantoche’s issue

awk: not in understanding doc or SC.

<AWK> "Dismissable A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;"

ac: is very close.

<steverep> Please refresh answers :)

SR: agree with dismissible part.
... related to another issue.
... trigger would have to be the entire close button.
... (not just inside it). More importantly, focus must be changed in order to activate the button which violates the SC.

ac: relates to 4th issue in survey.

<mbgower> +1 to tackling the other issue first. i think it will add clarity

scribe change?

<Mike_Elledge> scribe: Mike Elledge

<alastairc> https://github.com/w3c/wcag/issues/687#issuecomment-486670874

<Mike_Elledge> ac: Will stick on topic, but issue 687

<AWK> scribe: Mike_Elledge

Issue 687: Non-text contrast - Adjacent colors and example clarifications.

ac: 687 is discussion on how trigger would work. My comment, an untested thing, so remove or make less prominent.
... PL happy with response. awk: what about close button as part of popup content.
... mg: Wording is "such as" ESC. Desired best solution, but other possibilities.

<Ryladog> It would give people weird ideas

ac: Best to remove.

<Zakim> AWK, you wanted to ask where the quoted text comes from in the question

awk: How do you meet this w/o ESC key.

mg: Detlev example. If something appears on hover, mobile device will also have to open on click.
... If you click on it again, should close.
... Menu open, has to be collapsible with pointer.

ac: Assumption that if triggered could add mouseopen button.

mg: Appear in opening content. Magnifier if new information covers up target, then have to remove focus, then can't activaet it.
... Can't just be in new content to be operable.

awk: Can't just be in popup content.

detlev: Not supposed to depend on focus. Would not move trigger so long as focus remains in place.

<mbgower> I agree it comes down to an interpretation of "without moving pointer hover"

detlev: If trigger mouse enter won't necessarily re-appear. But don't want only ESC to be only way to activate.
... Would be open to another approach.

<laura> s/distinction /distinction /

katie: Providing other optiosn in Understanding is good, leave as it is with ESC, then can add others. Don't remove it, gives ppl another rationale for ESC to be used to close.

<mbgower> +1 to Katie. Remove " or selecting a close button"

ac: Happy with "such as" .

<laura> s/response is a trial. /response is a trial. /

sr: Happy with just removing it. Anything involving button isn't going to work, have to move focus, which would violate SC. Should have ESC, bec user expectation. Other keybaord short cuts, or click of middle mouse, possible, but would be complex.

<laura> s/Except respons and create PR /Except response C and create PR /

<mbgower> Remember that this doesn't prevent someone from dismissing with loss of focus. It just can't be the _only_ way. And 99% of the time pressing ESC is going to be the keyboard way to dismiss.

ac: Keyboard is one aspect, ESC makes sense to dismiss. Using mouse it seemed to make sense that "thing" to click on to act as trigger could mouse over and click within trigger.
... Messy, but theoretically possible.

<mbgower> s/hove /hover

sr: Theoretically could do with minimal user impact, but still trying to look at something else by magnifying viewport, but covered what you want to click. Have to figure out how to close viewport. Could keep button close by, but not as easy as pressing ESC.

<Detlev> The question is whether moving a cursor INSIDE the trigger = moving the focus

ac: If using mouse, would also have keyboard action. But messy.

<mbgower> Sure :)

ac: Detlev: Could you move pointer hover within the pointer hover?

awk: Box 20 x 20, upper right hand corner has button to cancel?

ac: yes. Doesn't help with kb pov, but would work with hover.

awk: If keyboard focus goes back to where it was, would seem to be okay.

ac: Not common, or case to encourage.

<AWK> We need a failure for "Failure due to requiring moving pointer focus off target to dismiss popup content"

dm: Thinking that as we move forward could be a common of misconceptions. Like our list of myths. Treating as button in right hand corner be sufficient. Don't want to encourage that. Interesting to think about. Don't really want to have button in corder, not amodal, so shouldn't behave as one.

sr: Agree. Quick scenario, sometimes in maps, or large images, zooming in on certain part, have mouse over image, changes to soemthing else. If zoomed in and image is entire viewport, can't move away from it. Have to close viewport to use button.

md: Think it will lead to future myth...

ac: Need to change to "primary recommendation to use the ESC to leave content"

mg: Think Steve's comment is the solution.

awk: Response...

<alastairc> Steve's comment: https://github.com/w3c/wcag/issues/687#issuecomment-480419273

mg: From 25 days ago.

<Detlev> happy to go with that one...

mg: When we discover soemthing else that works, we can change it.

<AWK> We again here need a PR to implement changes to 605/687 (should be one PR to cover both)

<Detlev> yes

awk: Just suggest that we implement a pull request. Answer to 605/687 will be much easier with implemented changes in place. Remove a few words we'll have it.

ac: Some small removals from Understanding document.
... If another solution comes up would be more substantial. Leaving 605/687...

<Detlev> Go for it!

awk: If we have answers can close it out.

ac: Should revise public comments...based on discussion.

RESOLUTION: Remove " or selecting a close button" from the Understanding document, create a PR and then post the official response

ac: Can move onto question 3.

Pull request 658

<alastairc> https://github.com/w3c/wcag/issues/658

<AWK> I just implemented the change for Understanding Content on Hover or Focus.

<AWK> (https://github.com/w3c/wcag/commit/30c56898fc0b0553d01c793493966fa46e1aad8c)

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

ac: dm found text hard to parse.
... detlev put in pull request.
... If someone uses media query to change text size...

mg: If go to w3c page, narrow screen text will flow. But if I zoom text size continues to grow. Wayne's concern is that the text size would become smaller. Don't see that. Body text is generally not reduced.

ac: In most scenarios ppl wouldn't do this. Maintain the std text size.

mg: Think Wayne's comment is that it reads like we're stating this as the norm, so should re-state it.

ac: In first paragraph, after first sentence, "if text is reduced in size" add phrase in front of that.

<alastairc> Phrase needed in front of: "If text is reduced in size when people zoom in"

mg: Using that as specific example makes it seem like it's the recommendation.

ac: Changing text will satisfy everyone.

awk: Pull request over 672.
... do we have the specific text yet?

ac: Would take a couple of minutes. Second paragraph, where "changing text to 10 px"...make a different size?

mg: Adopt pull request as given, definitely better than it was.

RESOLUTION: Accept pull request 672
... Accept pull request 702

<AWK> 702 merged.

awk: Suggest we switch to 2.1 discussion before going into 2.2. Work on survey next week.

WCAG 2.1 Techs and Understanding

<mbgower> LOL

<AWK> https://docs.google.com/spreadsheets/d/15idlBl1qQTNr2SIi4Drzk1Q1vnWAi5L26GCCv6mjD2g/edit#gid=2133852864

awk: Google doc, made overview as simple as possible for where we are. ST sufficient technique, FT failure technique, AT accepted technique.
... 1.3.4. Rated as high priority, since no sufficient techniques shown. Sufficient + failure technique, then is good enough.
... Pointer cancellation will need more. 1.3.5 No FT, so medium.
... We need to do better on High priorities. A lens for looking for proposals for new techniques. If there's an SC proposal, wg would give it high priority to work on it.
... High Priority: Orientation, character shortcuts, pointer gestures, motion activation.
... Talked about it at TPAC, need to get more techniques done and approved. Baseline for 2.2, one ST + 1 FT, or two ST, would be okay.
... Have a list of who is working on which, identify where work is nearly ready to go. Feel like there are so many github messages to keep up.
... Does this high, medium, low make sense.

racheal: Makes sense. But not quite sure where to go.
... Have motion actuation.

awk: High priority bec of shortage of techniques.

dm: Will take activation events 2.5.2, pointer cancellation.

<JakeAbma> write me up for orientation

awk: My interpretation of h/m/l if got high and mediums taken care of. Low would just trickle in.
... Do think that diff between high and medium is just which to work on first.
... Mg, squares with your thinking?

mg: Don't have same rankings as you for some, but putting attention on this is good. Contrast still a priority, because it's so intense to test.

awk: That type of image...only one with "done". If all done, still need for techniques. Always room for adding more.
... If person wanted to add (like 2.1) a particular one, then need to get attention on other items.

mg: Pointer cancellation okay (steve and detlev).

awk: Orientation. One from Kathy, awk will follow-up.

mg: JS techniques that could be used to restrict orientation.

ac: Possible, not sure how detectable.

mg: If we know of js method to restrict orientation, could list as failure.

ac: Do we need sc when basically saying don't do this.

mg: Turn device, if doesn't re-orient, fails. Simple.

ac: An easy technique to write.

<david-macdonald2> https://stackoverflow.com/questions/14360581/force-landscape-orientation-mode

mg: Hoping that script writers would be able to address.

Katie: 2.2.6 with Glenda. Still working on that.

awk: Reflected on sheet one?

Katie: No did not get to at our meeting.

awk: Now says Katie.

Katie: Okay.

awk: 2.1.4 Single character short cuts. No ST, have one drafted by Mobile TF. Has this been accepted?

detlev: DK what status it is. Hoped for easier way to test this. Have someone writing bookmarklet. Not very satisfactory. Wouldn't be noticeable until after leave page. Would put as failure technique if everyone wants.

awk: Could have single key as failure technique, if no way to change or disable would be a failure.
... Press all printing characters...feels like sufficient technique

detlev: Not an SC bec it doesn't suggest for someone to do something. Would have to hit all keys to trigger shortcuts.

awk: Do we need a technique which is an example of a failure, using the q key to do something specific. Pressing key that's been identified, then find some way to turn it off, and verify it does turn it off.

detlev: Could refer to that technique, but not useful for site you didn't know.

awk: Blackbox that can serve as failure

<Zakim> mbgower, you wanted to say that we elected to have dev identify when they have introduced a keyboard shortcut

mg: What detlev came up with is what we decided at IBM. Go back to dev team and ask if any shortcut keys created, then test them. Impossible to test all keys.

<Detlev> fine

awk: out of time. Technique for 2.1.4, shortcut keys. 2.5.1, 2.5.4 have people. Need technique for turning off shortcut keys.
... If you can, pick some up!

mg: Can send some that are not listed here.

<alastairc> trackbot end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

30 Apr 2019

Attendees

Contents