<Jennie> Scribe: Jennie

Alastair: Anyone willing to scribe 12/3?

<alastairc> https://www.w3.org/WAI/GL/wiki/Scribe_List

Charter update

Alastair: little updates at the moment.
... meetings are being arranged

Michael: We are still hoping to get it approved in December, but this is looking difficult.
... Silver is moved up to February
... hopefully the Charter will be done in time for this to happen.

Alastair: Any questions?

Conformance challenges doc update https://w3c.github.io/wcag/conformance-challenges/

Alastair: we are adjusting the agenda today because of things moving around for Silver.
... there has been some updates to the Conformance challenges document.
...Primarily: a lot more items being listed in the human testing needed part of it.
... other parts from Silver being added at the end.

Janina: additional content at the end is submissions Jeanne pulled together from the Silver research.
... it is the latest with everyone's submissions at the moment.

Alastair: section 5 will be integrated?

Janina: yes

Alastair: please have a look, everyone, if you are interested in that approach. Any questions?

Bruce: I'm scanning through the introduction to find the pull request

Alastair: it is in the main WCAG repository - there is a specific label you can use.

Bruce: OK. Thank you

Alastair: any other questions?
... ok.

WCAG 2.2 Essential controls (re-review) https://www.w3.org/2002/09/wbs/35422/essential-controls/

Alastair: this links through to the survey.

<alastairc> https://docs.google.com/document/d/1DPtCqWHjrhj3QZ4afsqzmWDd-zMSf39RsMqSpR2QGCg/edit#

Alastair: this is to the document.
... we have looked at this one before. It has some changes, and what is difficult to tell is which comments are from before, and which ones from after.
... the changes: in the main success criteria text it is talking about main navigation controls. Initiate has been taken out.
... anything to progress or complete it. Now has 3 bullets: 1st one has been rescoped.
... Rachael - is this to tackle comments about whether or not this is feasible? Or visible once the page is loaded?

Rachael: I think it was about a suggestion about when you open the page, and you are still doing something else...
... the intent was: the 1st time you open the page, it needs to be visible. Not always, just initially when you need it

Alastair: and from some of the comments: the main navigation needs to be visible but not all the content?

Rachael: the change to address that was a part of the control needs to be visible.
... looks like that got dropped at some point.

Alastair: we still have that they can be programmatically determined.

<bruce_bailey> http://www.w3.org/2002/09/wbs/35422/essential-controls/results

Alastair: the new one is that they are distinct from other controls on the page
... at the bottom of the page, need to be scrolled down to, but it is obvious that this is the next thing to do, like a submit button. This does give people another way to meet this.
... I think this addresses the comments.

<Zakim> david-macdonald, you wanted to ask about a definition of essential controls

David M: I'm wondering where we can find the definition of essential controls.

Alastair: it is in the success criteria text, which is not usual.

David M: main navigation - do we have a definition? yes, there it is

Alastair: people may not agree with that

Rachael: If we want to, we could say for main navigation, but I didn't do this essentially because it becomes a definition used throughout WCAG.
... it would be more consistent.

Alastair: OK.

<Zakim> bruce_bailey, you wanted to ask if essential controls

Bruce: Are essential controls the same as controls that meet the WCAG definition for essential?

Rachael: at 1 point in the process, that's why we picked that word.

Alastair: if removed, would change the functionality of the content...

<alastairc> if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform

Alastair: it probably would? If you have a next button or a submit button, you cannot remove it.

David M: I would say controls that are essential, and then underline essential

Alastair: In forming the bullet points, it was useful to have that so we can refer back to them.

Bruce: that is my concern - essential is being used differently than previously

Alastair: any suggestions on how not to have repetitive bullet points?

David M: a pronoun?

scribe: they?
... they can be programmatically determined.

Alastair: yes

John F: I am struggling with essential and who makes that determination.

scribe: bullet #2 - do we have a technique for doing this?

Alastair: yes - the personalization.

John F: Personalization is not ready yet - just in draft.

<Rachael> What about: For main navigation and controls needed to progress or complete a process, at least one of the following is true: 1) a mechanism is available to ensure the controls are visible without scrolling or hover interaction the first time it is possible to progress after page load, 2) the controls can be programmatically determined as being important, 3) the controls are visually distinct from all other content on the page.

Alastair: yes, it is lined up for 2.2. and is labeled risk.

John F: I am worried about timelines here.

scribe: if this is relying on this, I'm worried about dates lining up.

Alastair: I think we have a decision tree. 1 of them is a question around whether the SC should include the visual interface aspect.
... there are 2 parts: 1 is visual, the other is programmatic.
... it would be most useful to make that decision 1st.
... If only the programmatic version, that would be a cleaner thing to have at risk. If all mixed together, it is messier to pull out at a later stage.
... It is a worry if that wasn't there in time.

<david-macdonald> We could put bullet 2 at risk

Jake: About the fall back for programmatically determined - was this added to the SC because there was some push back on the official part, and not that because it was one of the core reasons we wanted it
... (quotes the cognitive - executive function text)
... and there is not a way for some AT to have things happening on the screen that help people see it.
... another plug in? The learning curve for all people to have all those plug ins installed, and use them?
... I'm not sure if this is the way we want to have success criteria.
... if we have five success criteria requiring these, and whatever else we come up with, I'm not sure we want this
... It may be useful for people that need screen readers. Using it as a fall back - I'm not sure this is the way we want to go.
... There is another important thing: the input purpose - when you have the essential attribute on the wrong one...
... you will need to figure out which one is the really, really, important one.

Alastair: the 1st one: is it a useful thing compared to the rest of the SC
... I think the intent is there would be another assistive technology for people with cognitive disabilities.
... That is definitely a concern if the personalization spec is released close to 2.2...
... Which leads to your 2nd point - how else will people use this attribute? This is a question I have as well.

John F: can you recap the attribute?

Rachael: simplification = critical.

John F: where does this come from? It is not in the Personalization task force.

scribe: the others are in the first module. In the 2nd module: it is not there either.

<alastairc> https://www.w3.org/TR/personalization-semantics-content-1.0/#simplification-explanation

scribe: when I look at the tools - I don't have something that can specifically say this group of controls is actually essential.

Alastair: I dropped the link in

John F: simplification is different than essential

Rachael: the simplification used to be important. This is done to reduce the non-important information. I'm not sure I see a mismatch here.

John F: Essential controls can be programmatically determined as being important...then we have terms of simplification

scribe: Myself personally, if the intent is to use the simplification attribute with the values of critical, medium, and low, then in the draft text we should use the term critical.
... then if we want it "critical" as opposed to "important" - then we are using the same term in both places.
... We need to make sure it is programmatically doable. It doesn't mean it will be interpreted properly even if we tagged it.
... Right now, Jake's right, if our dependence is on plug-ins that don't exist yet, we are putting the cart before the horse.

Rachael: I agree this SC is at risk, it is worth putting it through. I believe the COGA be an "And" not an "Or" but we don't think that will get the SC through.
... do you feel the other 2 are functional and workable?

John F: we have 3 terms: essential, important, critical - they are all similar.

<johnkirkwood> essential=critical

scribe: 1 technique we are working on in Personalization is called critical

<KimD> +1 to JF's concern about relying on plug-ins that don't exist today

<Rachael> So if we change the text to this: For main navigation and controls needed to progress or complete a process, at least one of the following is true: 1) a mechanism is available to ensure the controls are visible without scrolling or hover interaction the first time it is possible to progress after page load, 2) the controls can be programmatically determined as being critical, 3) the controls are visually distinct from all other content on the page.

John F: we have 3 terms trying to describe the same thing. It is about consistency.

scribe: if the primary technique we are relying on is critical, medium and low - then if critical is the term we will use in the personalization thing,
... then let's use the term critical to eliminate the wiggle word.
... then we can link back to that value in the spec.
... I think it makes it cleaner and tigher.

<johnkirkwood> +1 to JF

<Brooks> +1 to JF

Rachael: I think that makes sense. I pasted in some text.

<Rachael> For main navigation and controls needed to progress or complete a process, at least one of the following is true: 1) a mechanism is available to ensure the controls are visible without scrolling or hover interaction the first time it is possible to progress after page load, 2) the controls can be programmatically determined as being important, 3) the controls are visually distinct from all other content on the page.

Rachael: I just repasted it.

Alastair: I'm uncertain if it makes sense to use the same technique on the main navigation. Could this be derived in a different way?

John F: Alastair, I didn't understand what you said.

Alastair: adding the attribute makes sense to me, but would it make sense to add to the navigation, which is more of a container than an individual control?

John F: in the example that we have for simplification, yes, you are right. It is being added to the input. You are saying you want to add it to a block.

John F: I don't see why not. I don't recall us constraining the attribute to a specific element. I think this is a good conversation to have.

Alastair: if people use that same attribute on other elements in the interface, is that a negative thing? Or, it doesn't matter to us.

John F: this comes back to my concern of this SC coming back to a spec which is still under discussion

scribe: we don't have the answer to that question.
... Part 2: if the author thinks the contact us or the advertising block is critical, then they could add the attribute which would keep the ad block present all the time.
... maybe the criticallity could only be applied to inputs like buttons, data fields...otherwise it could be blocks of content.
... but this isn't essential controls anymore.

Alastair: ok. At the moment the SC text is only saying they need to be programmatically determined. We could look at another technique for that.

<Zakim> mbgower, you wanted to say what is stopping this from being introduced in existing SCs?

Rachael: I recognize it is a control that it will be used on more controls, but doesn't constrain us to use it on other controls. We are just providing the complimentary SC that these controls must have it.

Mike G: I am looking at the mechanism, programmatically determined, visually distinct.

scribe: I sometimes think we are reinventing the wheel here.
... 1.3.1 you could use this technique to encapsulate this. It says "through presentation" ..."available in text."
... if there is a technique that talks about controls that are programmatically indicated - if we are waiting for personalization we can hook it on.
... I see ways to do this without needing a new SC.
... I also want to flip back a second, visible without scrolling. I have a real concern about this.
... Forward/back on a survey are essential - unless you are going to have that survey confined to the viewpoint, those are going to require scrolling.

<david-macdonald> +1

<JF> 1

scribe: when you combine with magnification.

Alastair: I think Rachael has tried to deal with that.

<johnkirkwood> +1 visable without scrolling is an issue

<KimD> +1 to magnification and proximity is an issue (or could be)

Alastair: which I think means if you have your next and previous buttons, if you cannot progress until you have filled out the form, it doesn't matter if it is not there.

Mike G: I have 10 elements on a page, the required ones are early on. Then it is possible for me to continue, but there may be questions that are not required. I don't see how you can meet that.

Alastair: I think the visually distinct aspect will help with that. Maybe it is worth reconsidering that one. I see it as useful for the hover aspect.
... the interface where you have to hover to find out how to interact with.
... but the scrolling aspect is tricky.

<KimD> +1 to MG's examples are an issue

Alastair: in terms of 1.3.1 - I agree with this, however, we have struggled with adding requirements in that method.
... Under the principle that current sites would start failing without them having changed.
... for example if they didn't add the attribute - I struggle to see how we would progress with that one.

Jake: I have one question, and a comment for the visually distinct.
... the 3rd one is a new 1.

<JF> +1

Jake: I think there is an escape for almost anything.
... all previous and next buttons, no matter where they are on the page, if they are easily discoverable they are distinct.
... you have an escape for all the other intents. That is just a comment from my side.
... My question is for John F re programmatically determined. I know there was a moment in time where for input purpose we needed to rely on the HTML5 attributes because they are already supported.
... the new spec being just released - is that enough to rely on for programmtically determined?
... If that is the case, like with input purpose, then even if the draft of the COGA spec, it is not enough to rely on. This is not totally clear to me.

<Zakim> JF, you wanted to ask about visually distinct

John F: I will try to answer your question, then will get to my queue purpose.

scribe: in 2.1 we had to role back was because identifying critical links and critical buttons - which is the precursor to this
... we wanted to identify help, home; and buttons: undo, open
... we didn't have a robust mechanism to do this. This is why we needed a purpose for form inputs because we could use the autocomplete
... the personalization task force identified this gap
... potentially, yes, once the personalization work becomes a recommendation, which is easily 6 months out

<mbgower> e.g., of a technique that could fit under 1.3.1 for this COGA##: Using COGA simplification to identify controls necessary to complete a task

scribe: Potentially down the road there will be successful techniques for this, but I am less optimistic.

Alastair: when that happens there will be implementations.

John F: yes, we had in the past to show 2 implementations of everything, but we are not there yet.

scribe: Right now in the personalization space, Lisa is working with some developers doing some proof of concept work, but it is slow, and still early days.

<KimD> +1 to us getting ahead of what code supports - it's a problem

scribe: If we are depending on the personalization modules...
... I had also added myself to the queue because we are using the term visually distinct, which we do not have a definition for
... We had this issue with sufficient contrast.
... Does a link in bold show itself to be more important than the one that is not?
... How will we make things visually distinct? We need an example

Jake: I would like to add the material design, user test I did - for non-text contrast.
... we had 2 lists, and in that perspective, you can define this from all different angles.

Alastair: I agree, the understanding document will need lots of examples. The Google doc does have some. It might be a bit like art.
... I think Jeanne will speak to that later.

David M: I am wondering about a mechanism available without scrolling. This is truly dependent on which type of device is being used to monitor the content.

scribe: If my phone is in landscape mode... How will we define the user's visual environment.

<johnkirkwood> +1 to David

scribe: I can't think of any other SC right now, but it is really dependent on the environment

<JF> +1

Alastair: Yes

<KimD> +1

<Zakim> jeanne, you wanted to suggest that "visually distinct" might work with the ATAG definition of "Prominence"

<jeanne> https://www.w3.org/TR/ATAG20/#def-Prominence

Jeanne: the authoring tool had to deal with this issue years ago. Visually distinct was considered and dealt with it using Prominence, and had "at least as prominent."
... this gave people the ability to compare against other controls.

Alastair: thank you.
... I think that is going to help.

<mbgower> COGA##: Using COGA simplification to identify controls needed to progress or complete a process

<Zakim> mbgower, you wanted to say I have added an example technique that could be fit into 1.3.1 to meet the goal.

<Ryladog> +1 to Jeannes

Mike G: this could be introduced as techniques as I pasted above.

scribe: it fits absolutely under 1.3.1
... it can be used as one of the methods of judging that. Alastair, you mentioned ARIA landmarks. We didn't have a problem adding in techniques for these.
... The reason I am going here now, is because those techniques could be created now, so that as technologies come onboard, there is a means for using them.

<JF> +1 to Mike

scribe: 1 of the challenges is that if we create a technique, there is no way to benefit for it right now.
... just putting that out there.

Alastair: That would help in the circumstance where you have a visually distinct control.

<JakeAbma> how to distinguish between a button and an IMPORTANT button

<JakeAbma> ?

Alastair: then you are marking it up appropriately.
... I'm just wondering if it works the other way around
... I wanted to ask: if we took out the programmatically determined bullet point.
... so it was visually prominent - which goes to a heuristic measure - would we be happy with it progressing?
... any objections?

John F: Yes

scribe: the concern about visually distinct - even using a heuristic analysis.
... if we are going to be using visual properties - is there a minimum difference in size, color and spacing?
... I'm not opposed to the definition, but it feels incomplete.
... and for people who cannot see, if someone has a cognitive disability and a vision disability, they will have no benefit.

Alastair: OK.

<KimD> +1 to JF's concerns

Jake: Re 1.3.1 - let's say you have a couple of buttons and a few buttons for progress. Or some links in a main menu
... my feeling is that this SC aims towards something which is more important.
... do we now have to do 2 checks on a button or link, to see if it is important in relationship?
... Is input purpose also needing to be considered?

<Brooks> +1 to JF's concerns regarding ambiguity of visual design guidance, and lack of current programmatic support related to the proposed SC

Jake: Where do you distinguish the importance?
... Again, looking at input purpose - if we had to redesign that one again, would you also suggest it go into 1.3.1?

Mike G: the difference is that on input purpose, there is no visual distinction.

scribe: unless someone has come along and styled the user inputs differently, there isn't a way to meet them

<Chuck> scribe: Chuck

Jake: If you have next and prev buttons, but there are 3 carts below, exactly same visual buttons..

MG: That would be very bad design. Designers are very technical. They won't have next and prev styled like that.

Jake: This specific case doesn't feel like a fit for 1.3.1. Because we... I understand the intent. It is not the way I've seen 1.3.1 until now.
... Creating more of a need to check for 1.3.1, for essential controls. If they are not visually distinct from other elements and how they are styled, based on position or text.
... Like prev or next you have to do a double check for 1.3.1, is it a "button"? Is it a prev or next? You could pass one and fail another one.

MG: I think other people would be better to respond. I do think there are lots of 1.3.1's which are very similar. Aria regions. There's lots of examples where it is equivalent.

Alastair: We need to keep moving.

Katie: The concerns about the styling or the explanation of guidance on styling, if we utilize the new language, I'm not as concerned that ... sure this is meant for people that can see.
... All of the sc's stand on their own. They need to meet the requirements of the other SC's. Yes it has to meet contrast, and others. That can be further identified in the understanding doc. But not a blocker.
... We have visual focus, I think it's worth giving this a try and getting feedback.

<Zakim> JF, you wanted to ask about media controls & full screen mode

John: I want to think about this in context of media controls. When you go to full screen mode on your device. In the full screen mode you're controls, all of these controls are hidden away in full screen.
... Use hover or on screen motion or keyboard input to bring up those menus. In the draft text we have some language that it's always visisable. How does that work with the full screen video patern?

Alastair: It's an interesting case. It doesn't say they have to be there all the time...
... They can disappear, that's allowed.

John: As long as they can be made visible again.

Alastair: Generally controls fade after a few seconds once in full screen mode.

John: Depends on user agent. For most users, the majority are going to interact with mouse or touch input. The controls become visible.
... I'm like everybody else on the call, we all understand the value of this. It's like in the cockpit of an airplane. If you need oxygen, the oxygen button is the one you want to use.
... ... that's not ready yet.

<Zakim> alastairc, you wanted to ask whether 'visual' accessibility is subsumbed?

Alastair: To support Katie's point. Other sc must be met. This one isn't a matrix one like we had with reflow. It's more of a case that you can make it visually distinct.
... Wouldn't necessarily combine with other sc.
... Finding a way forward on this, we have a few options. We need to set asside the programmatically determinable (as a standalone), or cover it under 1.3.1.
... Looking at the other aspects of it. If we are looking at prominance or is it worth spending time going down that route, maybe we remove the scrolling aspect.
... Maybe have an exception. If you were looking at things need to be available the first time it's possible to progress, or visually distinct, is that a worthwhile route to pursue?

<Ryladog> +1

Alastair: Asking for any plus 1's.

<Rachael> +1

Alastair: Is it worth progressing with the visual aspects of this sc? Anybody against that?
... Remove #2. And visually distinct we will work on with the ATAC definition of prominant.

Jake: Purely about visually distinct, or specifically about page load above the fold without scrolling?

Alastair: Use bullet 3, take bullet 2.

Jake: Isn't #1 the whole intent of this sc?

<mbgower> Is this roughtly it: Main navigation controls and those needed to progress or complete a process are visually prominent?

<johnkirkwood> what about "visually prioritized"

Jake: The intent is that when the page is loaded, you see it on the screen, not that it is visually distinct. Should we be cautious about going the route of visually distinct when intent was about page load?
... If you hover over them, they are visually distinct, is that what we want? Or are we wandering away from the original intent.

<mbgower> Is this roughtly it: Main navigation controls and those needed to progress or complete a process are visually prominent and persistent

Alastair: I would add without interaction.... not needing to hover. If you look through examples, the very bottom one is very simple but slightly long with mobile, with next button that is prominent.

<JF> Quoting from the Draft: Intent - The intent of this SC is to ensure that buttons, menu items, and other essential controls can be easily found by people with cognitive disabilities when they are needed.

Alastair: Seems that should fulfill it. Where square space example, you can't find next thing to do unless you hover over a specific part of the page.

<mbgower> Main navigation controls and those needed to progress or complete a process are visually persistent and prominent.

Alastair: The good examples that Rachael found are there when you open the page. I'm wondering if we can refine or improve on examples.
... Would that be good stand-alone?

<JakeAbma> Next intent sentence: "People with low executive function, impaired memory, and other cognitive and learning disabilities may not be able to find features that are not immediately visible on the screen, either because they are “below the fold” and require the use of the scroll bar or because they are hidden until a pointer hovers over them."

JF: If we had metrics in the definition defined, I could support this. If we can get the prominance tightly scoped... Spacing, if our definition mentions size, spacing and color, and we can measure it...
... define minimum size, spacing, color contrast... if our definition of prominance where we can use those specific metrics, possibly.

<Zakim> mbgower, you wanted to say I reversed to make _persistent_ first

JF: Just to leave this as "prominance" that's vaguely defined, it's a wild goose chase.

<JF> Nor I Mike]\

<mbgower> Provide consistent results from different testers (e.g. 8/10 testers agree). This can be assessed through inherent logic or proven through examples.

MG: In the last one, I reverse it to make visually persistant and prominant. I think it's easier to measure persistance. I agree with John that the prominance is hard. Not a reason to reject, but to be cautious.
... 3rd one is real kicker.

<Ryladog> +1 to visially persistant

MG: It should be easy to show the visual persistant one, the prominance one could go underneath that test. Is it possible to have 80% of testers come up with same result? If so, then achievable.

Alastair: Visually persistant is easier to test, I'm sure there are exceptions.

JF: Video controls as example.

MG: Don't forget, visually persistant doesn't mean always visible. Something can be off the viewport and still be persistant. As opposed to something that only appears on hover.

JF: I'd push back on that one.

MG: We will have to define persistant.
... Doesn't go way based on user actions, it's still on page.

JF: If I'm to understand Mike, we need to get better definitions. In context of this sc, the feedback is needs more work, needs more definition, not dead yet.

Alastair: Just create more work for Rachael. We could say that it would be easier to define under task based. Is it easier to do under that model? Would it work better? Rather than spending effort now?

JF: Do we have silver conformance model? How will a new conformance model solve these issues?

Alastair: Would allow for task based procedure. When defining the next step of task, it's easier to define the button that gets you there.
... This might be a good example for silver task force.

JF: Even if defined as task based, we still need the terms defined. I look at the 3 that are in the prominance definition, size spacing and color, I think that's a good starting point. WCAG defines those terms.
... I'd like to see that better defined. When you are doing the task, you can evaluate if the controls are sufficient size, spacing, color contrast. Which therefore the sum of those 3 makes them essential controls.

Rachael: 2 q. Reframe what Alastair asked... is there >50% chance of this making it through, or are we just spinning? If we have a reasonable shot, then worth pursuing.

<bruce_bailey> +1 to keep pushing, since it is coga

<Ryladog> We should make a reasonable shot

<Ryladog> +1

<Detlev> -1

Alastair: +1 if you think that there's a >50% chance of this making 2.2 sc.

<JF> +0

<Brooks> -1

<david-macdonald> -1

<bruce_bailey> -1 because less than %50

<laura> +0

+0 unsure

<mbgower> unsure

<JakeAbma> -1 a bit too sunjective

<mbgower> Visually persistent: content that remains visually present in the UI once a page has loaded

<JakeAbma> subjective

<KimD> -1 because a lot to overcome

Alastair: It's tricky around the definitions. Exceptions, would it be watered down?
... Not looking great.

<Detlev> I like Mike's proposal for the path via 1.3.1 technique

Alastair: To clarify, this isn't about agreement, it's strictly about prognosticating success of making into 2.2.

<bruce_bailey> i am happy to keep working on it, but i remain skeptical

<bruce_bailey> the work will not go to waste

Alastair: Process would be to work on definitions, put asside "programmatic", work through examples. Can we agree that "these" controls would pass?
... If anybody can, get in touch with myself or Rachael.

JF: one final question. Responsive web design, flyout to hamburger menus, where does that fit?

<mbgower> I am also happy to contribute to this, but have limited cycles through to EOY

Alastair: For things like menus it's fine, hamburger menu is visible to start with, not the content in the menu. Others can get more difficult with scrolling.
... Bruce and Michael. Rachael can work with these fine folk.

WCAG 2.2 Information in steps https://www.w3.org/2002/09/wbs/35422/info-in-steps/

Alastair: This is a new one this week. Looks like only I have filled it in, wait, there's Jake!
... This is the other part of sc that got split, that DF was working on. Not here today.
... Basically asking for if you are in a multi-step process, you have access to info from previous steps. If it asks for prior info, that auto-fills.
... I've wrote a new version, put it in survey result, and it's not come through.
... Jake put in lots of comments which I haven't scanned through. Can you summarize?

Jake: Need to refresh memory.
... Not sure before I get a resonse if it's worth reading them all out loud.
... The intent of the sc is clear.
... At the moment there are certain wording issues which are not clear. Wait for response on those. A couple of things in the doc, the example was not really ... the example says something like...
... There's a portal, you need to provide #'s from another portal, you need to fill them in rather than navigate back. They are implemented in the portal they need to be filled in.
... This isn't about recalling info and filling in the second step. Probably for another sc.
... Lots of examples that people encounter, but needs more benefits.
... There's something else... mitigates the probability of triggering a variety of undesired conditions. I don't have info on if recalling data can trigger PTSD. Is this based on actual use cases?
... more of those comments on this doc. Felt that this doc could be redone a bit on wording.

Alastair: Some of the way it's structured is not how we generally do understanding docs.

Jake: Felt like more of a draft of a draft.

Alastair: David is just starting, and would appreciate help.
... I made a suggestion in the doc, where I simplified the current formulation is talking about components, and whether the user can do something, not content oriented. I tried to reformulate...

<alastairc> For steps in a process the following are true:

<alastairc> Information entered by the user in a previous step remains available to the user in subsequent steps.

Alastair: <pasting in content>

<alastairc> Information entered by the user in a previous step that is re-requested is auto-populated, unless re-entry is essential.

Alastair: That can be more refined as well.
... That seemed to not lose anything. Hopefully be a bit simpler.
... Wilco has some comments which align with what I was suggesting in the sc text.
... We can take on board that the understanding doc needs some work, but in terms of the sc. Does anybody see any issues? Things that need improvement in the sc?

dm: Wondering I think it's accomplishable and measurable. Wondering if we are proceeding with language in there or suggested language?

Alastair: Hopefully is saying the same thing. I'll check with David. Assuming it's not dropping anything, use new text.

dm: I wrote from David's first draft, the top one. Basically my text.
... I'm fine with working off of yours. We lose a few things that may or may not be important. I can work with either.

Alastair: Not like the previous one where we were worried about definitions.

dm: This is more about tweaking and wordsmithing. This is on the right path.

<mbgower> +1

Jake: q about first part. The information remains available... you are in step 5, you want to know what's in step 2, do you need a link to step 2? Or is it fine to have overview of info at the end that can be edited?

<mbgower> +1 to not defining mechanism. Lots of ways

Alastair: The mechanism is intentionally not defined. A couple of ways to do it. You can go back, or have a button that shows previous answers, lots of ways it can be accomplished.

mg: I think it is achievable. Seems to be ticked off on all of them. Doesn't have a level (a-aaa).

Alastair: It got split up from previous one.

mg: That's the only thing I see missing.

Alastair: What do people think of an appropriate level for this?

mg: A

<Rachael> +1 to A

Alastair: No usual factors that would bring it down.

<Ryladog> +1 to A

Alastair: I recall what I wrote before.
... I think we will take this refinement discussion offline.

<bruce_bailey> +1 to A

Alastair: We need another draft.
... Can anybody help over next week?

dm: I can follow up. I can reconcile.

Alastair: If you could align the structure with our usual for understanding doc, with examples and benefits and things.

dm: Sure.

Alastair: It's a case of if we bring it back next week, no point if it hasn't progressed, we could come back to it in a couple of weeks.
... I'll do before agenda goes out.

<bruce_bailey> I will try to review closely by 12/10 meeting

Jake: The last couple of weeks I've seen old versions of drafts and multiple id's are all in one doc, maybe a split even in one doc. If I'm not up to date, I have hard time which parts to check and which don't need.
... Can we have clean doc with maybe link to previous?

<JF> +1 to Jake

Jake: Anybody else agree?

Alastair: It was this one with persistant labels, I didn't ahve a chance before survey went out. We all agree. Just takes time.

<mbgower> I recommend doing "Make a copy" from File before undertaking updates

Alastair: David works with David about moving archived content down, one sc at top. We'll start with a clean doc.

<mbgower> The copy can be the point in time preservation. The existing doc is current

Alastair: Mike recommends making copy, just don't change the link, or we will all be confused.

<bruce_bailey> +1 for someone to accept all changes

mg: Make a copy before progressing. Then update current doc to current state.
... Old google flow for saving stuff.

dm: versioning noise.

mg: Going through version gets "thick". If you just save and label with date, and begin editing, one can go back and see.

dm: ok, I'll save a copy.

WCAG 2.2 Page breaks https://www.w3.org/2002/09/wbs/35422/page-break-nav/

Alastair: Not huge # of people, I got link wrong, Wilco corrected me.
... This is the sc from epub side. Fixed reference points. It's straight forward.

<alastairc> Where fixed reference points are present in the content, a mechanism is available to navigate to each reference point.

Alastair: <reads>
... Seems fine on the face. Wilco had some suggestions.
... Around what fixed locations means, there's no dictionary definition.

dm: We have a definition for fixed reference points.

Alastair: Yes. Maybe he's conflating with markers aspect.

dm: Maybe he's asking what structural markers are.
... Not sure how else to say it.
... visual or code based markers.

Alastair: My comments are would that include id's? I don't think we want to.

dm: Yes, concerned that we want to scope those out.
... ID could be fixed location...
... You'd want to go there...

Alastair: Could be a BAGILLION id's on the page.

dm: They want to have page breaks. So reference to "page 63" can be gotten to even in electronic version.
... We couldn't go forward with that via web, so next version is "if there's a page break that is used", that needs to be navigable.

<bruce_bailey> Being able to reference by hard copy page number is why PDFs are still a thing

dm: At TPAC Shawn mentioned that this is a concept that's going away. Concerns with "page break" rather than structural markers.

Alastair: have we lost something along the way?

<Zakim> mbgower, you wanted to say this is achievable

<Zakim> janina, you wanted to say that page will be important to W3C's Dpub

mg: I was the one that rewrote. It got tightened down. In some ways it expanded. It could refer to time stamps. Useful to navigate through. This does NOT apply to everything with a programmatic id.

Jake: No q from me.

Janina: Point out that this business of "what page you are on" may be important to w3c technologies, we have digital publishing group with huge interest. We solved this for ODF.
... Solved in scottland. Digital publishing will want this.

dm: Want to come back... on the team that brought this forward, I was liason. Matt Garrish and George Kursher. I'd love for you to be involved in this sc, if you are available.

Janina: I'll try to track it.

<Zakim> bruce_bailey, you wanted to say that reference by hard copy page number will remain a thing

bruce: +1 to Janina, referencing hard copy remains a thing. Everyone works from electronic copies, but referece by page and paragraph is not going away.

Janina: You remind be being fed type. Those lines are numbered. Just like code.

bruce: In legal world too. They reference by line number. Is there a way to get a soft copy that doesn't say line numbers?

<Jennie> +1 to Bruce's request for legislative hearing docs!

<KimD> +1 legal docs have multiple page numbers (from multiple sources)

mg: Sounds like a technique. I changed the wording for "enumerated sections". Bruce what you said is a great technique, to turn on and off.

Janina: There is a filter on the command line. The cut command.

Alastair: One of my main comments was i almost don't feel qualified to judge this one, I don't understand the user agent side for these reference points, and how navigation would work.
... Would it be possible to invite Matt next week, and we can go over it?

dm: Maybe all 3. They come from different perspectives.

<bruce_bailey> +1 to hear from Matt Garish!

Janina: Here's how we thought about it. Consistant, not just what we did in ODF. Time offets and timestamps, the idea is that one reference metric is your master. Probably the standard print page.
... everything else you have a command for accessible equivalent. Requires user agent support.

Alastair: ODF... open document format?

Janina: Yes, everyone has the same. I presume Microsoft supports.

Alastair: That's a page based format. has concept of pages, even if you reflow. I wonder if there's a similar mechanism in epub.

dm: Major technique on this were asking for is a list of links to the pages.

Alastair: Embedded in the doc?

dm: Yes, part of the doc.

Alastair: A 200 page doc would have a list of 200 links.

dm: Yes, and there can be names on the links, or indices.
... It really was the page. We've moved off of that hopefully we haven't lost too much.

Alastair: I thought it must be a user agent mechanism.

dm: With lots of ebooks there are no pages. No page number. You can get a section. the pages are "screens" and that's changing based on the screen.

Janina: ask next week is what the path forward where the master doc is an e format as opposed to print.

Alastair: Just want to be sure we meet the goal. Any q or comments on this sc?

<Zakim> mbgower, you wanted to talk about forced alignment of video and audio

mg: A distinction between a tech solution and the sc. Janina's solution is technical. There's lots of ways that this can be achieved. There are existing solutions in the wild.
... My wife in govt has had both solutions, historical print run, archived. Master is literally a bound copy, and reference is to that. Now they have forced aligmnent. They align text, video and transcription.
... Are forced aligned. Timestamps, paragraphs are used. Lots of different ways to achieve. Requiring it is useful for situations where it exists. The flip, is the language tight enough ...
... Where we don't force people to tag stuff we don't want tagged, creating too much noise by overachieving?

Alastair: Yes.

<Ryladog> Do paragraphs make sense for CJK languages?

Janina: one of the groups active is looking at audio book as master, and coming up with text. There are a few publications that are first published as audio books.

Alastair: Any other q or comments?
... We'll invite folks to next weeks call. Any suggestion, leave comment on doc or in survey. I had technique didn't seem like a technique.

dm: I'll look at that.

mc: We had a problem with minutes last week. I don't want to replicate.
... Someone forgot to ask or needed to be re-asked. Be sure to make sure minutes are generated before dismissing the bot.

<alastairc> rsagent make minutes

<laura> bye.

<Rachael> Thank you. bye

<alastairc> https://www.w3.org/2019/11/26-ag-minutes.html

<bruce_bailey> https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info

<alastairc> trackbot end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/same as the WCAG defintion of controls that are essential/same as controls that meet the WCAG definition for essential/
Succeeded: s/reference by page/reference by hard copy page number/
Default Present: AlastairC, bruce_bailey, janina, JakeAbma, Jennie, Chuck, Rachael, KimD, Detlev, JF, Raf, MichaelC, Laura, Brooks, johnkirkwood, Jon_Avila, Katie_Haritos-Shea, mbgower
Present: AlastairC bruce_bailey janina JakeAbma Jennie Chuck Rachael KimD Detlev JF Raf MichaelC Laura Brooks johnkirkwood Jon_Avila Katie_Haritos-Shea mbgower
Found Scribe: Jennie
Inferring ScribeNick: Jennie
Found Scribe: Chuck
Inferring ScribeNick: Chuck
Scribes: Jennie, Chuck
ScribeNicks: Jennie, Chuck

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 26 Nov 2019
People with action items: 

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.)