<Joshue108> AGWG Work Items progress check in and sign-ups: https://github.com/w3c/wcag21/issues?q=is%3Aissue+is%3Aopen+label%3A%22AGWG+Work+item%22

<scribe> scribe: JakeAbma

<Mike_Elledge> I may be user 4...

<MichaelC> https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0138.html

Changes to Understanding document structure?

<bruce_bailey> AWK email wrt exit criteria: http://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0138.html

<bruce_bailey> subject line was: Update on Candidate Recommendation Exit Criteria

<JF> +1 to preserving Benefits, and promoting them to sibling of Intent

<Joshue108> Scribenick: JakeAbma

MC: 1. benefit promoted as sibling to intent. 2.Other option: benefit to be deleted as separate section

<laura> +1 to preserving Benefits, and promoting them to sibling of Intent

<bruce_bailey> +1 to what JF is saying about benefit being important to note

JF: strongly in favour for sibling of intent. This is what we want and this is why we want it

<Glenda> +1 benefits are critical to understanding why

Jason White: Benefits fundamental for SC

<Zakim> Joshue, you wanted to ask what is different from whats already there?

Bruce: Looking at 2.0 / 2.0, looks like benefit is already a child, so what’s the difference?

JF: make it siblings instead of child

MC: doesn’t look very different but does for editing. Make it complementary
... part is to not know what difference between intent and benefit is

JF: intent is, what do we want of you? Why do we want it? That’s the benefit. The order for presenting and relationship is clear

<Zakim> steverep, you wanted to say that I usually read the Benefits more as Beneficiaries

<Zakim> Joshue, you wanted to talk about the benefits of putting benefits first

Steve: same as JF, to expand SC, whether is goes before or after intent

Josh: Sees benefit as maybe better to add first, than intent. Makes it easier to parse

David: likes intent + bullets because reads faster. intent = what, benefits = why.
... benefits like a hit-list, easy focus

<Zakim> gowerm, you wanted to say Let's not make more work by causing a rewrite of all existing SCs.

<JF> +1 to Mike G

Mike Gower: concerns with re-ordering, doesn’t see the benefit

<Zakim> MichaelC, you wanted to comment editorial style

Josh: WE HAVE THE POWER!!!

<JF> we may have the power, but do we have the time and human resources?

<JF> +1 to M. Cooper's proposal.

<laura> +1 to Micheal

<Ryladog> +1 to MC

MC: promoting it to higher level and conceptually see where it goes

<Kathy> +1 to MC

+1

<Glenda> +1 to MC

<Detlev> +1

<jallan> +1

<marcjohlic> +1

<david-macdonald> +1

RESOLUTION: Benefits to now be a sibling of Intent

<bruce_bailey> Survey asked to get a head start on identifying potential implementation candidates.

<Zakim> bruce_bailey, you wanted to ask question about implementation process survey (before we go to next topic)

<Zakim> JF, you wanted to ask if we have asked EO to join us at TPAC for a chat

Survey https://www.w3.org/2002/09/wbs/35422/Oct_17th_agwg/

SC Orientation Text: Locking is not the accessibility problem #509

<Joshue108> https://github.com/w3c/wcag21/issues/509

<steverep> The text in the survey does not reflect the possible limitations of the user agent as discussed in the GitHub thread. The 2 options should be: Content is operable in all display orientations supported by the user agent, except where display orientation is essential. or A mechanism is available to view and operate content in all display orientations except where the display orientation is essential or not supported by the user agent. I prefer the latter,[CUT]

Steve Repsher: there needs to be clarification when not supported by UA. Other thing, want totally consistent…?

jameson: what benefit are we trying to solve?
... is there an accessibility need I miss here?

steverep: the user had mobility issues, have fixed device, can’t rotate. so orientation is forced

<Kathy> here is the understanding: https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html

jamesnur: what ever it starts in it needs to stay, or support where it started, not the change to rotate

<jallan> browser orientation must override author intended orientation

<laura> From Understanding doc: “Benefits: Users with dexterity impairments, who have a mounted mobile device will be able to use the content in their fixed orientation” https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html

jamesnur: we’re tackling low hanging fruit instead of the meat

jasonwhite: was an issue about whether content should stay in orientation. we have to adres this as well

<Greg> How about "Content is operable in all display orientations supported by the user agent, except where restricting the orientation is essential."?

jasonwhite: I think the question is what requirement should be. we’re using same terms as APIs which may cause confusion

<Greg> I liked the steverep's wording "Content is operable in all display orientations supported by the user agent, except where display orientation is essential", but I agree with others that we need something between "where" and "display". However, we shouldn't say "one orientation" or because an app could limit itself to a range of angles or several orientations. (We cannot assume the semantics...

<Greg> ...of the HTML5 Screen Orientation API, in which "portrait-primary" and "portrait" (which includes both "portrait-primary" and "portrait-secondary") are each counted as single orientation value.)

GregL: proposal a single / a specific not exactly correct
... put a more general restriction on it

<Joshue108> ack

David: do it on page load, but there was rejection, not hard rejection but a … let’s see one…

MarcJohlic: have seen locking when wanted to switch orientation but could’t
... for bigger fonts

<Zakim> steverep, you wanted to interpret in a way that addressses the on load issue

SteveRep: refresh button could be seen as “mechanism”

<Zakim> Joshue, you wanted to ask if the term 'not locked' will just use the default on an UA

<kirkwood> are we not really talking about responsive design here?

Josh: first one didn’t says how, when using the “mechanism” it does
... prefers the former

<steverep> Content is operable in all display orientations supported by the user agent, except where display orientation is essential.

<steverep> or

<steverep> A mechanism is available to view and operate content in all display orientations except where the display orientation is essential or not supported by the user agent.

<steverep> straw poll? I'm happy with either

<Joshue108> +1 to content

<laura> +1 content

<Ryladog> +1 to content

+1 to content

<Mike_Elledge> +1 to content

<Ryladog> +1 to mechanism

<david-macdonald> +1 to mechanism, but wat to visit on page load at some point...

<Brooks> +1 to content

<gowerm> either

<jamesn> of these +1 to mechanism

<marcjohlic> +1 to either of these

<Ryladog> point to definition

<KimD> +1 to mechanism, but the wording is clunky and probably unclear to those outside our group

<Ryladog> +1 to David's suggestion

Josh: mechanism causes confusion often

<kirkwood> “mechanism” iss too confusing to approve

<gowerm> +1 to content; changed my mind

<laura> “mechanism" has been very problematic in explaining SCs. we removed it from adapting text just for that reason.

<david-macdonald> Ask people what they can live with

<laura> can anyone not live with using the content wording?

<steverep> Solving the actual problem is more important... anyone who can't live with one or the other?

<KimD> I can live with "content"

<Detlev> I would opt for content and treat it as implicit that the SC migh be met via a mechanism (and explain that in the Understanding)

<Ryladog> I can live with either

<bruce_bailey> I can live with either

<Ryladog> I can live with content

<bruce_bailey> I appreciate breaking up the questions though!

<Mike_Elledge> Yay!

RESOLUTION: Accepted Content is operable in all display orientations supported by the user agent, except where display orientation is essential.

<laura> Scribe: Laura

<steverep> I will create a pull request.

Response to comment on Mitsue-Links Accessibility Dept. C 3.2.7 Change of Content: Avoid using the term "control" #506

<Joshue108> https://github.com/w3c/wcag21/issues/506

Josh: proposed response to 506.
... SC 3.2.7
... 8 Accept response as proposed

2: Accept response with the following changes

3: Do not accept response / needs more discussion

<Ryladog> +1 to this change

David: people didn’t like the word “control”.
... FROM:

There is a programmatically determined relationship between the new content and the control that triggers it;

scribe: To There is a programmatically determined relationship between the new content and the triggering mechanism;

<bruce_bailey> I think “triggering mechanism” is not as hard to parse as “a mechanism is available”

<bruce_bailey> http://www.w3.org/2002/09/wbs/35422/Oct_17th_agwg/results#xnew1

detlev: Not sure whether the the change of language from "control" to "triggering mechanism" really solves the problem. Not happy with change.
... control means activated by user.
... would be bad design.

James: rotation shouldn’t be covered. Needs to be made clear in understanding doc.
... considered edit to be a minor tilt.
... see need triggering mechanism. need to clarify in understanding

<david-macdonald> https://github.com/w3c/wcag21/issues/506

David: proposal should be adjusted to read triggering mechanism.

<Detlev> I have no fundamental objection to make this change..

David: probably larger issues on this SC.
... Should apply to next bullet.
... if people are confused we can come back to this,
... comment is that they don’t like the word “control”.

<Ryladog> I am fine with either, but I like triggering mechanism

David: I am fine either way.

josh: maybe come back to this.

david: maybe reassign to detlev.

josh: we have an objection form lisa

Mike E.: maybe explain in the undertanding doc.

scribe: provide an explanation where it does and doesn't apply

david: not attached to either

<Ryladog> +1 to this change

david: maybe reach out to lisa. Close to consensus.

JF: could defer to thursday.

<david-macdonald> are you hear lisa?

Josh: wish lisa had left a reason.

<Detlev> agree with Mike

WG: put it to a CFC and lisa can speak up

<Zakim> steverep, you wanted to offer using "action" instead

steve: maybe slightly adjust 1st sentence of the SC

Josh: can you update your proposal?

<Ryladog> +1 to action

Josh: triggering action or mechanism?

<Ryladog> +1 to triggering action

<Joshue108> We have created a pull request to replace "control that triggers it" with "triggering action"

David and Steve: wordsmithing new wording

<Detlev> Do you really "take" actions when you trigger something?

<david-macdonald> The user has been advised of the change of content before, or as a result of the user action

<david-macdonald> The user has been advised of the change of content before, or as a result of taking the action

Josh: overhead for CFC. Do we have to do that?

<steverep> I think we decided anytime there is an SC change we need a CFC?

MC: we had talked about bulk call for objections once a week

Josh doesn’t want us to do CFC for non normative changes.

steve: maybe take this to GitHub to work on wording.

david: we are close.

<Glenda> +1 I can live with triggering mechanism

<Ryladog> I can live with either

<david-macdonald> There is a programmatically determined relationship between the new content and triggering mechanism

Josh: Do we have text ?

<david-macdonald> The user has been advised of the change of content before, or as a result using the triggering mechnaism

Josh: what about using action?

<david-macdonald> The user has been advised of the change of content before, or as a result of taking the action

David: this last one takes in Steve’s suggestion.

Josh: we can ask the requestor.

David: they are okay with it?

RESOLUTION: Accept David’s 2 edits.

Josh: will put out CFC
... for normative changes.

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/This is what we want vs this is why we want it/This is what we want and this is why we want it/
Default Present: jallan, JakeAbma, interaccess, bruce_bailey, Roy, Laura, jamesn, jasonjgw, Kathy, MikeGower, kirkwood, Makoto, KimD, Greg_Lowney, Mike_Elledge, Brooks, steverep, JF, Katie_Haritos-Shea, Glenda, david-macdonald, marcjohlic, Detlev
Present: jallan JakeAbma interaccess bruce_bailey Roy Laura jamesn jasonjgw Kathy MikeGower kirkwood Makoto KimD Greg_Lowney Mike_Elledge Brooks steverep JF david-macdonald marcjohlic Detlev
Found Scribe: JakeAbma
Inferring ScribeNick: JakeAbma
Found ScribeNick: JakeAbma
Found Scribe: Laura
Inferring ScribeNick: laura
Scribes: JakeAbma, Laura
ScribeNicks: JakeAbma, laura
Found Date: 17 Oct 2017
Guessing minutes URL: http://www.w3.org/2017/10/17-ag-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.