<scribe> scribe: Wilco Fiers

<AWK_> +AWK

Orientation: https://www.w3.org/2002/09/wbs/35422/MATF_orientation/

Marc: Remaining issue was orientation vs dispaly orientation. Went with the latter

<Joshue108> Updated: https://rawgit.com/w3c/wcag21/orientation_ISSUE-70/guidelines/#orientation

Marc: other addition. Alex was adding an example to the definition for Essential

<Joshue108> Great that definintions have been updated etc Marc.

Marc: Reminder to people, what happens if people want locked orientation. This is telling authors not to lock the orientation on the users
... it should be opperable in all orientations, except when it is essential for the application.

<AWK_> AWK - for definition of "essential" recommend removing "in binary fashion"

Marc: Remaining question, is this at launch time, or at any point. I think not at any point. Couldn't figure out why you would lock it later on unless it was essential.

Josh: Don't know what "binary fashion" means

Lisa: Use case I'm concerned about, had a criteria that was almost the opposite: Orientation doesn't change without the user's concent.

<Detlev> orientation changes precisely *becaue* users rotate the device...

Lisa: some people rely on GPS or something like that. When orientation changes automatically, they have to start again figuring out where they are / going

Marc: We're not saying to change orientation on the user. It is about not stoping it if the user wants to do it

Lisa: Can we add the reverse: "Or allowing the user to cancel it"?

Marc: I think we are saying that, when we say that content is not locked in a specific orientation.

Lisa: Would it be a failure technique?

Marc: Not if it is essential. It is more of a navigation. The display might change directionally, not the display orientation.

<Zakim> AWK_, you wanted to say that all devices allow locking of the orientation

AWK: All devices allow users to lock orientation. If I would find that disorienting, I can lock it, that's fine. This SC doesn't speak to this specifically.
... if I need to turn my device for one reason or another, content should adapt to that.
... I think what Lisa is talking about is available in the OS.

Lisa: No there isn't
... if you have GPS, if you don't want orientation to change when you turn.

AWK: This sounds like a different use case

Josh: We don't want authors to lock orientation

Mike: This SC addresses the scenario you're talking about. If a user has the device locked in portrait, this SC doesn't allow you to prevent that.

Jason: Related to how this is managed between content, OS and browser
... It isn't clear how the responsibility is distributed. AWK refered about adapting to orientation change.
... Non-specific about what content is doing that is excluded by this proposal
... adapts or responds to an orientation change. We need to take into account how different technologies handle this.

Marc: We're not telling authors to lock things. We're telling not to

Josh: Lock is restrict, limit

<marcjohlic> That would go into the Understanding doc IMO

<MichaelC> https://www.w3.org/TR/screen-orientation/#locking-the-screen-orientation

Josh: There's a meta viewport attribute you can add to do this kind of stuff

<marcjohlic> defining what it means "not to lock" - what the OS does etc - that would all go into the Understanding

Josh: the core is that you don't want authors to restrict it to something a user may need.

Chris: The only thing the device can do on behalf of the user is tell the current orientation.
... because the OS has this responsibility it could change at inappropriate times.
... It's the OS responsibility to decide where to go. It's the content author responsibility to provide views that can be rotated / adjusted

<lisa> how is this testable?

MC: The APA WG reviewed screen orientation API said that orientation lock is a critical feature

<chriscm> Define "this". Does "this" = the presence of content that can be rendered on multiple screen orientations.

<AWK_> Testing: turn the device, observe whether content remains fixed or not.

MC: the ability to lock orientation is critical. Not having a change underneath you is what the SC is trying to get at.

Marc: Correct, we don't want to interfere with the user

MJ: we want to address this in the understanding document

<Joshue108> +1 to keeping the SC text simple

Jason: It hasn't addressed my issues
... If it allows interface option that would change the response, then it's the application / content which is determining the response. That there would be no response.
... that would look like a failure, even if it's in response to a user's request.
... If it's the web app that's receiving an event from the UI to fix the orientation.

<Joshue108> Definition of Display Orientation https://rawgit.com/w3c/wcag21/orientation_ISSUE-70/guidelines/terms/21/display-orientation.html

Jason: I'm not comfortable having it handled by understanding docs. "Locking" doesn't do it for me. Need something in the normative text.

MC: I don't want to redefine terms that Orientation API defined

Josh: Concensus seems to be that this is good to go.

<gowerm> +1

<Detlev> +1

<marcjohlic> +1

<Kathy> +1

<AWK_> +1

<Joshue108> +1

<JF> +1

David: Which did we settle with, on a download or on a process.

AWK: Not specified in the current text

<Glenda> +1

<KimDirks> +1 - good to go and I'm in favor of the orientation not being restricted to on load - "never locked"

Marc: At launched or througout. My oppinion is that content is never locked, unless it's essential. Whether it be at launch or while running

<ChrisLoiselle> +1

David: Maybe things are optimized for a certain orientation. Relates to James' comment

Josh: Want to see if people can live with it going into the draft.
... this is a reasonably simple SC, but certain details can be worked out.

David: There is an outstanding comment.

<david-macdonald> +1 can live with it, prefer on download

Josh: Push it over the line unless there is a showstopper

Jason: With Screen orientation API, if that provides a mechanisme where the web app would lock the orientation.
... having a control that locks the orientation looks like a violation.
... Also defining what is meant here. If I'm a web developer and I use that API, letting users fix orientation within my application.
... I'm fine having it in a draft with notes.

Josh: We do not want developers to lock the orientation.

<lisa> note the time...

Jason: Not getting there. The idea with screen orientation. If the author uses that API, even if only done when the user selects it, that looks like a violation of the SC. Even though it's conditional.
... Even if they do that only on user request, it is still a violation of the proposal.

Josh: Maybe be clear about author locking vs user locking.

AWK: Jason, just like text size, if the user changes text size, the content doesn't fail. The API gives the author informationa about the orientation. This SC says to not fix the orientation.
... If I create an application that can adapt, but the user disables that, it's fine.

RESOLUTION: Put Orientation SC into the next editor's draft

Josh: Put out a CfC to the list

Help: https://www.w3.org/2002/09/wbs/35422/COGA_help/

<lisa> link for help text (revced)https://rawgit.com/w3c/wcag21/provide-support_ISSUE-32/guidelines/sc/21/provide-support.html

<chriscm> getting every 3rd word...

<Detlev> can't hear you well

<chriscm> Dial in?

Lisa: We got rid of long documents, changed to long blocks of text.
... they can be broken up, add headings, or a summary is provided
... made it much more universal and easier to test.
... We merged complex and simple numerical. You'll choose what makes sense, if something is complicated, a chart is better.
... we added exceptions, like Jason brought up. If you're making content for accountants you can ignore that point
... also excluded real numbers not required for math operations.
... We think we've addressed the bulk of the comments. Wondering if people still have issues.

JF: One of my concerns is about "comprehensive support is available". For numerical content, where should it be available?
... We need to have programatic linkage. I would like it programatically available. It makes it easier to test.

<chriscm> +1 to programatic association

Lisa: It would be problematic in some cases because people object to the semantics.

<Glenda> +1 to programmatic association

JF: I don't think we need new semantics.

Lisa: No objection to this

JF: Propose making a change to the draft to be explicit about programatic association.

MC: Wanted to ask who prefers programatic association.

<AWK_> I'd like to see what the new language looks like

<Detlev> +q

<alastairc> Relatively minor thing, but can we use a different word than "cardinal"? Not sure if it means 'fundamental' (1st in the thesaurus), or something about 2D co-ordinates?

Alex: Question about the structure. You have to provide comprehensive support. What if none of these exist?

Lisa: If none applied you pass

Alex: I think the SC is wrongly written if that's the case. If none apply, than you have to say "if applicable"

MC: If criteria don't apply you meet them

Alex: What if multiple conditions apply, and you do one of them?

Lisa: that's allowed

<JF> Suggested Draft Text: Comprehension support is programmatically associated via one or more of the following

Lisa: this is the whole pillar concept. Even though we're not addressing the full user need, we're getting them in.

Alex: The effect of having a positive impact was questionable.

MC: This is a known compromise, have to have it one way or another.

Lisa: If the group wants all, I'm very happy

MC: I'd rather have a compromise than nothing.

Alex: Why is the structure like it is?

Lisa: Basically, you have to do one of them. When we had it in one line we felt the user need would not be met.
... we can't require it. What document needs / what is too long is subjective. Wouldn't get it through.

<AWK_> should be 1 or 3 bullets

Lisa: were happy breaking it into two bullets, have it look like "when appropriate". This gives it more emphasise

Mike: I found it weird the way it's written. It looks like you have to do one even if you don't have any

<lisa> Comprehension support is available when appropriate for the following :

<lisa> +1

<gowerm> +1 for Alix's point

Lisa: I think this addresses Alex's point

+1

<marcjohlic> +1

David: Programatic association: In HTML we can do that. In other technologies that is difficult. All progamatic helps blind people. Users that don't have AT programatic doesn't help much.

<lisa> Comprehension support is available for the following :

<JF> +1 - "appropriate" is a subjective term

David: "Where appropriate" works cross porposes, there is disconnect about which you should do. What I think we should say is "When the following is present, only one"... something like this.

<gowerm> what does "appropriate" mean?

<gowerm> +1 for alastair's approach

<lisa> Comprehension support is available for the following:

<gowerm> +1 for Lisa's modification

<Alex> I have to go. But for the record, I can't agree to moving this SC forward yet.

<Wilco> Detlev: I think the either/or construct doesn't work.

<Wilco> Lisa: There is an 'and'

<Wilco> Detlev: For forms you would have to do something, either A or B

<Wilco> ... the way I read it I find it difficult to understand what I'd have to test with content

<alastairc> How about: "When the following types of content are present then comprehension support is available for each:"

<Wilco> Lisa: Suggest new wording, or put it in understanding?

<Wilco> Detlev: I think this is too much in one SC. Please read my comments

<alastairc> And separate the 2nd bullet into 2: - Non-standard controls: have instructions - Multi-step forms: provide information about a user's position in the form.

<KimDirks> *I have comments in the survey too

<Detlev> I'm sorry I have to leave the meeting for another appointment...

<Wilco> Jason: Most of my comments on the survey. First about scope and rational on the exceptions. I think the logic is described questionably.

<lisa> strongly disagree with what jason is saying

<Wilco> ... programatic needs to be considered more careful. I'm concerned about automatic summary. The user may have better software than authors might have.

<Wilco> ... Forms are a concern. WCAG doesn't talk about forms but about processes. Should the same language be used?

<Wilco> Lisa: The pressure needs to be on the author. They can't pass it on to automatic summaries, they aren't fully reliable.

<Zakim> JF, you wanted to note that there are two types of issue here: "understanding meaning" and "where am I / How to operate" - if anything we could split this into two SC

<Wilco> ... This was rejected by the TF as an option.

<Joshue108> +1 to JF

<Wilco> JF: We're trying to address two things. What is on the screen, and where am I?

<Wilco> ... About association, it simply means they are linked. I'm concerned about "is available". The question is, where is it available and how does the user get to that content.

<Wilco> ... if we don't say how it is linked, the inference is that it's on the same page.

<Wilco> Lisa: We're happy to go with progamatic. I think this can be a technique, but having it next to it would also work.

<Wilco> ... having it next to it is better then a footnote.

<Wilco> JF: I don't want to force authors to do something, I want there to be a direct association, more then just "available".

<Wilco> ... Three could be a page in the footer "glossary page". I don't see how that benefits anybody.

<Wilco> Lisa: Pros and cons. I think it should be a technique, but it should go to what most people think should be done here.

<Wilco> David: It may be limiting if you put programatic association. May be less accessible.

<Zakim> AWK_, you wanted to say that starting this with "comprehension support" makes this very confusing

<Wilco> AWK: What i'm struggling with is the leading text. It's different from what other SCs are doing.

<Wilco> ... The SC about blocks of text is saying what should be done with blocks of text.

<Wilco> ... there is a lot in this. It feels we are putting understanding in the SC.

<Wilco> ... we say what you should do, and in understanding say why.

<Wilco> MC: I proposed comprehension support. If it seems better without it we can have a better hook.

<Wilco> Lisa: Alternatively, if we want these points to be separate criteria, then we can do that. But don't want it to take up 8 weeks.

<Wilco> +1 to putting it in and clean up later

<AWK_> -1 to including as it is

<KimDirks> -1 - my comments in the survey haven't been addressed, plus many have left

<Wilco> Josh: Anyone who can't live with this as is?

<JF> =1

<JF> -1

<david-macdonald> +1

<JF> I will continue to push-back on "available" as ill-defined and hard to test for

<Wilco> Josh: on the fence about this

<AWK_> Alex indicated a -1 before he left "<Alex> I have to go. But for the record, I can't agree to moving this SC forward yet."

<Wilco> Lisa: In the form, but with the top sentence changed.

<lisa> Comprehension support is available for the following:

<Wilco> ... we could break them up after August.

<Wilco> Josh: RIght now we see a no. I hear some strong points toward breaking it up.

<lisa> cute

<Wilco> Josh: We can ask this question again next week when there are more people in.

<Wilco> MC: I feel we are almost there.

<Wilco> ... it needs more discussion. But I think we are close.

<Wilco> ... as for breaking up. We can deal with that later.

<Wilco> ... We should lean more towards putting things in and getting comments.

<Wilco> Lisa: Can we put it in the list?

<AWK_> adding more items to the list of 3 for the week doesn't help streamline the process

<Wilco> Josh: We'll follow up next week.

<ChrisLoiselle> bye, thank you.

<Wilco> 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: MichaelC, ChrisLoiselle, Wilco_, AWK, jasonjgw, Kathy, lisa, Detlev, Joshue108, marcjohlic, JF, KimDirks, David-MacDonald, alastairc, chriscm, MikeGower, steverep
Present: MichaelC ChrisLoiselle Wilco_ AWK jasonjgw Kathy lisa Detlev Joshue108 marcjohlic JF KimDirks David-MacDonald alastairc chriscm MikeGower steverep Glenda
No ScribeNick specified.  Guessing ScribeNick: Wilco_
Found Scribe: Wilco Fiers
Found Date: 08 Jun 2017
Guessing minutes URL: http://www.w3.org/2017/06/08-ag-minutes.html
People with action items: