<scribe> Scribe: Laura

Understanding docs survey https://www.w3.org/2002/09/wbs/35422/understanding_changes4/

ac: looks like people have responded to the survey

Understanding Orientation

ac: building from the last meeting.
... reviewed the gihub thead.
... not restict was the original intent.
... 4 people happy with the pull request.
... David’s changes.
... see github thread 496.

MG: line 34. not sure it covers all of it.

JF: maybe successfully view or consume.

<Greg> "start, control, and view"?

<gowerm> A video is shown in either portrait or in landscape orientation based on the user's chosen orientation.

<gowerm> A video is shown in either portrait or in landscape based on the user's chosen orientation.

MG: maybe: A video is shown in either portrait or in landscape orientation based on the user's chosen orientation.

David: that’s fine.

Greg: maybe: start control and view

david: it is not restricting.

AC: seem resonable.

<alastairc> AWK commented for top line: I know that we discussed whether this is "locking orientation" or "not enabling awareness of changes in orientation". I think that the paragraph is clear without the "and lock" and the "not locking the" (below), as it says that both need to be supported. But I don't care that much, so whatever people decide

MG: maybe “or lock”

<Zakim> Greg, you wanted to say that this sentence has a common problem of not being clear as to whether the behavior described is good or bad.

david: not going to fall on my sword over it.

greg: not sure if it a positive or negative example.

<Greg> This sentence has a common problem of not being clear as to whether the behavior described is good or bad.

greg: unnecessary cognitive load.

<Greg> Could rewrite very slightly to fix that.

<gowerm> "...their device to match, but this can create problems. Some users..."

ac: happy with line 18.

<Zakim> gowerm, you wanted to say that "set or lock" covers two different scenarios

<Zakim> Brooks, you wanted to say I think we need both set and lock. If we are going to use only one, I say go with "lock"

Brooks: I think we need both set and lock.

<gowerm> Some websites and applications automatically lock the screen to a particular display orientation and expect that users will respond by rotating their device to match, but this creates a problem. Some users have their devices mounted..

<alastairc> ..., but this creates a problem for some users who...

<Greg> However, some users have their devices mounted in a fixed orientation (e.g. on the arm of a power wheelchair).

<Brooks> OK - I now agree with Andrew. I think the site wouldn't necessarily have to "lock," because setting orientation in a mode that is different than what the user requires is enough to create a block to access.

MG: proposal “Some websites and applications automatically lock the screen to a particular display orientation and expect that users will respond by rotating their device to match, but this creates a problem. Some users have their devices mounted.”

greg: concern if they set and not lock could be a problem.

david: never seen that.

AC: in web content seems like th other way around.

<gowerm> Do we need language about "lock"?

david: we can’t do anything about the OS.

<gowerm> If we cover lock as a separate paragraph and talk about how this doesn't apply to phyiscally locking at the OS level as a user preference, then maybe we solve this dilemna

greg: not clear on the difference between set and lock.

ac: struggling to come up with a difference..

mg: maybe a note talking about locking.

david: can we all live with “set or lock”?

mg: worried we have no info on OS level.
... people will misread it.
... will write something.

ac: added as a comment.

brooks: does this apply to native apps?

david: can be applied to WCAGITC

<gowerm> https://github.com/w3c/wcag21/issues/928

<gowerm> I opened this new issue for "lock" and assigne dto myself.

ac: may need to kick this one to next week.
... large CFC next week.
... still need to do personas and techniques.
... any opjections to publishing davids changes?

RESOLUTION: Accepted PR 922 as ammended by the comments

Understanding non text contrast

ac: confused by long desccription comment.
... wasn’t trying to use long descriptions.
... intent is split into 2.
... hopefully it works as it should.

MG: like the extra graphics
... I'm worried about the statement "(hover and focus are styled in the the same way)." which while maybe true, isn't best practice
... The submit button focus indicator fails contrast.

ac: hard to find examples.

MC: maybe better to get a submit button.

ac: could update.

mg: sad to see relative luminence info was removed, as it is highly relevant to how certain SCs interact.
... need to capture it somewhere. maybe another document.
... with 2.1 it states visual info for states and boundaries. and color alone.

ac: would fail use of color. not this SC.
... maybe put it in 141

brook: may be both for comparative differentiation.
... example: cancel and submit buttons

ac: don’t want to get ingto borders in 2 different states

mg: could use border thichness.

ac: maybe create a new issue for this.

<gowerm> I'm okay to shove the existing language over into the 1.4.1 Understanding document, and cross referencing it, but it HAS to be put in.

david: alot going on about the focus indicator

mg: I'm okay to putting the existing language over into the 1.4.1 Understanding document.
... concerned about this being lost.

<alastairc> PRevious version: https://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html

mg: read the existing language.

ac: design of buttons is getting tricky
... 141 doesn’t talk about states.

<Brooks> I don't think that by providing a 3.0:1 color contrast (luminance) between buttonrectangle colors (focus vs. non-focus) works to create an exception to SC 1.4.1. Both colors aren't available at once (with one button) to enable users to compare the two and discern the difference, via their differences in relative luminosity.

david: huge issue.
... need to provide a focus ring.

jf: concerned about backwards compatability.

ac: need more examples.

<JF> Gotta drop, hard stop at the top of the hour. later all

david: big SC.

ac: lets not resolve this one now. will come back to it on tuesday.

you’re welcome

<alastairc> are you ok to email the minutes?

<alastairc> I'm going to leg it for my train...

<alastairc> np, worth discussing, will try to find examples

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/concereded about backwards compatability./concerned about backwards compatability./
Succeeded: s/butttons is getting tricky/buttons is getting tricky/
Default Present: alastairc, gowerm, Brooks, Greg_Lowney, Laura, JF
Present: alastairc gowerm Brooks Greg_Lowney Laura JF
Regrets: Chuck Detlev AWK Josh
Found Scribe: Laura
Inferring ScribeNick: laura
Found Date: 17 May 2018
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.)