– DRAFT –
AGWG Teleconference

<Rachael> regrets Bruce B, Charles H

<Rachael> Sign up for future scribing at: https://www.w3.org/WAI/GL/wiki/Scribe_List

<Rachael> We need a scribe

WAI documentation review for AV https://www.w3.org/WAI/media/av/changelog/, Issues at: https://github.com/w3c/wai-media-guide/issues/

<Rachael> https://www.w3.org/WAI/media/av/changelog/

rachael: a headsup and request for review. Docs for audio and video accessible has had some updates. Specifics in change log.

rachael: <pasted>

<Rachael> https://github.com/w3c/wai-media-guide/issues/

rachael: Issues are here <pasted>

rachael: Please take time and review.

rachael: q or further comments?

detlev: Is there an easy to read version?

alastair: last page of change log.

alastair: link that was pasted in.

Chuck: How should we report concerns?

<alastairc> Index of the media approach: https://www.w3.org/WAI/media/av/

alastair: As issues in github.

<Rachael> Rachael: Believe it is as issues using the issue list https://github.com/w3c/wai-media-guide/issues/

alastair: There are some reported already.

rachael: Any other q or comments?

WCAG 2.2 Focus-appearance https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates2/

rachael: Second agenda item...

<Rachael> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates2/results

rachael: We are going through results. we started the question last week. link <pasted>

Updating the size metric

rachael: Starting "updating the size metric".

rachael: Originally the sc minimum area stated <pasted>

<Rachael> Minimum area: The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control, or has a thickness of at least 8 CSS pixels along the shortest side of the element.

rachael: there's a proposed revision.

rachael: <pasted>

<Rachael> The area of the focus indicator is either: at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused control; at least as large as a 4 CSS pixels border along the shortest side, and no thinner than 2 CSS pixels.

rachael: Discussing change, talked about Gundula's comments. Any more to add?

gundula: We discussed that research shown a dotted focus is not as easy to spot. Seems to be the case that many agree. I can live with it here, adding dotted or dashed would be clumsy for the requirement.

rachael: Any other conversation people wanted to have on this?

<Rachael> Propsed resolution: Accept change to minimum area

<Fazio_> 0

<alastairc> +1

<Rachael> +1

<JakeAbma> 0

<sarahhorton_> +1

<Raf> 0

<Ben> 0

<mbgower> +1

<JF> 0

rachael: please +1 to agree, -1 if you object, and 0 if you have no strong opinion.

<JustineP> 0

<GN015> 0

<AWK> 0

<Detlev> -1

<MelanieP> +1

<Sukriti> +1

+1

rachael: Can you detlev speak to your concerns?

<laura> +1

detlev: I've not looked closely. Having problems making the link to 2 css pixels to the other things in requirements.

detlev: ...a general qualification for all options? Difficult to parse.

<Rachael> examples at: https://alastairc.uk/tests/wcag22-examples/focus-more-visible-5.html

rachael: Bulleted in the doc. couldn't paste.

rachael: Can anybody speak to clarifying?

alastair: It's a visibility aspect. Targeted where you have a more extreme rectangle or shape, not a square.

alastair: if you are putting focus on one side, it needs to be thicker.

alastair: prevents the worst examples.

detlev: The first option is to have one pixel around the control, doesn't apply to that...

alastair: Yes, it's bulleted, and these are sub bulleted. These will be different cases.

detlev: I'll withdraw my -1 to a +1

alastair: There's a better format on the link provided by Rachael.

Resolution: Accept change to minimum area

Must a focus indicator always be displayed? #1387

rachael: Next q...

rachael: what was presented is a trade off. "either" solves the sticky footer issue or it addresses focus indicators that fade. Q went out whether or not which of these 2 priorities were the highest.

rachael: 5 people prefer to solve the sticky footer problem, 2 what to solve the face, and 2 something else. gundula, you proposed something that bridged both.

gundula: both can be solved because they don't interfere with each other <reads>

gundula: We discussed the most often user action is triggering a tooltip. If a user scrolls away without using focus, focus is no longer visible. I think wording can cover both.

alastair: I think... hoping Michael G can speak to this. It was done by user action and how we scope that seems tricky. When moving focus is a user action. Seems a gray area.

alastair: On an already gray area bullet. Seems difficult to do. Has potential to give it a wide a hole in the sc.

alastair: I'd like there to be another option, just struggling to see it.

rachael: mg, any points to add to that or thoughts?

mg: I think the sticky footer issue is wide spread. I don't have a sense of the fading focus issue. I think that it will have to meet focus visible and non text contrast.

<Jemma> can we have a link to the issue by any chance?

mg: Won't fade into obscurity.

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

mg: The reason why it got brought up is that someone was concerned with focus indicator fading. By judging when it receives keyboard focus you can have a specific instance in time that you are assessing.

mg: w/o then the argument can be made that user can page up or move box aside, which is not what we are trying to achieve. Having component receive focus allows us to evaluate.

mg: This fading thing... unless someone has examples, it still must meet focus visible and non text contrast.

detlev: from a testing perspective this will be tricky. There are many situations where there are different results and different break points. One option is to specific a specific viewpoint.

<alastairc> I've not seen an example of fading focus indicator, and it is something people could get away with now.

detlev: not inline with the concept that it should apply to all breakpoints.

<JF> +1 to Gundula

<Zakim> JF, you wanted to note that "fade" is a function of time

gundula: focus still needs to meet focus visible and non text contrast. would users understand that it would be sufficient to meet before fading? User might still look for it and miss if it faded away or reduced contrast. May not be clear that after fading it needs to meet requirements.

jf: I agree with gundula, the whole point of fading is that it introduces a time factor. The focus indicator is not persistent. All form labels must be persistent, so we have precident.

<jon_avila> I agree with John and GN

<Zakim> alastairc, you wanted to talk about timing for SCs, and that unobscured brought that in

jf: This is a unique scenario, I agree with gundula.

alastair: Our sc apply regardless of time unless stated otherwise. It was really the unobscured bullet that brought in the concept.

alastair: When control has keyboard focus, time wouldn't be a factor, it would be a case of if the control has the focus. When we bring in the unobscured bullet, now we have the concept of time. When it receives focus, shouldn't be unobscured. It's trying to deal with sticky footers.

alastair: Needing to worry about time and other actions that impact. I'm struggling to see how we can cover it from point of view of sticky footer with unobscured and not open up a big hole by saying any user action can solve the problem.

alastair: That means a user action like scrolling solves the issue, and we don't need the sc. I'm struggling to see how to solve at the same time.

rachael: put in persistence in the understanding document.

rachael: there would be a relationship that would have to be clarified.

jf: want to test something alastair said. sc applies regardless of timing... when we introduce fading, we introduce the time factor.

alastair: I think we are making same point.

jf: From different angles. That focus indication needs to be persistent. Putting it in understanding is not normative.

mg: John, q becomes, would you pass a fading item that fades right now w/o this sc in place?

<AWK> +AWK

jf: I'll answer by saying, I couldn't fail it in 2.1 because there's no specific language. I wouldn't be able to fail because I wouldn't be able to identify the standard being violated.

<AWK> 2.4.7: "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible."

<AWK> Agreeing with mike

mg: If you look at the other sc, you have grounds to fail a fading focus indicator. right now. I bring this up because those criteria continue. This is a different criteria. It doesn't exclude the existing criteria?

jf: I don't disagree, if you read the other sc, here's how I gotten there. I agree with the logic. But there's no normative language that specifically says that. I'm hoping to cover that.

<Rachael> Intent of focus visible includes "The focus indicator must not be time limited, when the keyboard focus is shown it must remain."

jf: I would recommend it now, but I can't point to explicit wcag language. We agree with what you are saying, but haven't written it down.

rachael: current intent is that focus indicator is not time limited.

<Zakim> alastairc, you wanted to talk about the stacked criteria

alastair: Focus appearance, something must be visible, and non text contrast, should have 3:1.

alastair: Focus appearance, which started purely on the attributes of the focus indicator. No user action, no timing.

alastair: When somebody raised issue like sticky footers, just focusing on attributes doesn't mean it's visible.

alastair: While browsers will do things to bring focused objects into viewports, but doesn't account for sticky footers and non modal dialogs.

alastair: Which has impacted these. 3rd issue is if an indicator can fade. I bring up the stacked ones, you could have a fading one now, as long as it's perceivable.

alastair: And if around the outside needs to meet non text contrast.

alastair: You could have something that fades as long as it passes the other 2 sc.

alastair: ...unobscured bullet would be unworkable, and potentially browser won't show whole indicator. It's a mine field. I don't see how allowing user action improves the situation.

alastair: I haven't seen anyone do focus fade outs.

alastair: Unless we raise it in understanding, I don't think it will occur to most people.

rachael: We are leaning towards current wording. Does anyone want to argue against or present options?

<Rachael> Proposed RESOLUTION: Continue with wording in Focus Appearance that addresses sticky footer

<kaherr> +1

<AWK> +1

<Rachael> +1

<Ben> +1

<Rachael> +1 mbgower

<JF> 0

<Sukriti> +1

<Detlev> +1

0

<alastairc> +1, suggest anyone wanting to continue attacking the fade issue propose some text.

<Francis_Storr> +1

<sarahhorton_> +1

<juliette_mcshane> +1

<MelanieP> +1

<laura> +1

Resolution: Continue with wording in Focus Appearance that addresses sticky footer

<Raf> 0

2.4.11 Unobscured bullet will fail the common chatboxes widgets #1502

rachael: Q 3.

Understanding 2.4.11 minimum area - focused/unfocused? #1552

<Rachael> https://github.com/w3c/wcag/pull/1577/files

rachael: We are looking at minimum area. There was a q that asked if we dealt with size when the indicator was focused or unfocused. There is a PR to address that to specify that we are basing on unfocused state.

rachael: 7 agree with change, 2 that want a different recommendation.

gundula: When we last discussed, unfocused might be smaller than focused. I argue it might go either way.

gundula: Is the issue reported in 1552, can happen the other way around in the same way?

gundula: Should refer to whichever is smaller.

rachael: You suggest focused or unfocused, picking the smaller.

awk: I didn't see where it makes the computation any more complicated. I think gundula's point is very good. If we switch to make the calculation based on the focused size, that COULD be smaller, not too often.

awk: It seems we are doing a comparison from end user perspective. Delta is what you see most of the time, and what you see when focused. If you had a giant change, you could have a button that increases in size, has a one pixel perimeter that is not complete around a much larger control.

<alastairc> Noting the text: "The area of the focus indicator is at least as large as the area of a 1 CSS pixel thick perimeter of the (un)focused control"

awk: That would be more than sufficient to see. That might not count. I feel like we need to do the comparison relative to the thing we are comparing it to.

awk: That simplifies it. We aren't asking people to figure out which is bigger. Measure, measure, compare, done.

alastair: Currently the text says that the perimiter of the focused control, not the unfocused control. We should compare pre-focused state to focused state.

<alastairc> https://w3c.github.io/wcag/guidelines/22/#focus-appearance-minimum

awk: One of us is confused.

alastair: I pasted in the text...

awk: We are looking at minimum area...

awk: I was looking at the change in the understanding doc, which is part of this.

alastair: ok.

<Rachael> https://github.com/w3c/wcag/pull/1577/files

awk: In the pr, it changes to...

alastair: 2 parts, the sc text, and a small change in the understanding doc.

<Rachael> Proposed RESOLUTION: Accept PR 1577

<laura> +1

<AWK> +1

<Sukriti> +1

<sarahhorton_> +1

+1

<Rachael> +1

<kaherr> +1

<JF> +1

<Francis_Storr> +1

<juliette_mcshane> +1

<Ben> +1

<MelanieP> +1

<Detlev> +1

gundula: We should talk, focus might be painted inside, such as list items, painted in boxes. focus could be inside. Whole list or entry? If you measure focus or unfocused, measuring inside or outside?

alastair: If on the inside, doesn't change calculation. If on the perimeter , I can't see it any easier changing from focused to unfocused, and we are measuring difference. It would make sense to start from unfocused state.

gundula: Might be different numbers.

alastair: Yes, it could.

gundula: Still inside the visual list item box, then its mathematically it's smaller than the original.

alastair: but if it's inside it doesn't change the size of the control.

gundula: the focus indicator might be too small.

alastair: Which has come up before, but doesn't relate to focused and unfocused.

gundula: Maybe this should be made clearer with examples in the understanding.

alastair: There's a note to take measure from visible boundary.

rachael: One action would be for you to review understanding and come back...

rachael: with alternatives.

gundula: Best way to address issue.

Action: Gundula to explore updates to the understanding and bring back to group

<trackbot> Created ACTION-348 - Explore updates to the understanding and bring back to group [on Gundula Niemann - due 2021-01-26].

Resolution: Accept PR 1577

2.4.11 Unobscured bullet will fail the common chatboxes widgets #1502

rachael: Q 4

<Rachael> Draft response is at: https://github.com/w3c/wcag/issues/1502#issuecomment-756256057

rachael: unobscured bullet will fail chatbots. It will cause some chatbot widgets to fail this sc. We have a draft response...

rachael: that says "yes", but those chatbots do cause issues, so we should leave the bullet.

rachael: Can anyone speak to that? 8 agree, 1 with something else. Andrew?

<alastairc> Noting that the issue-raiser accepted the response as well.

awk: I couldn't follow the issue, I wasn't seeing issues that highlighted the problem. I figured I could ask in the call.

rachael: Can someone provide a better explanation?

awk: I'm glad response was accepted, but I'd like to understand.

alastair: Open an ecommerce site, chat opens, there are links that go behind the box. David was worried that this was common.

alastair: Different screen sizes and viewports where you have less width, you'll go behind a lot. I struggled to find examples. Seemed to be more US based.

alastair: may or may not be common. May not be an automatic fail, but links in locations could cause failure to the unobscured bullet.

awk: got it.

rachael: unless there are any other concerns...

<Rachael> Proposed RESOLUTION: Accept the response for #1502

<sarahhorton_> +1

<Ben> +1

<laura> +1

<juliette_mcshane> +1

<GN015> +1

<kaherr> +1

<Sukriti> +1

<Rachael> +1

+1

<Detlev> +1

<JF> +1

<MelanieP> +1

<Raf> 0

Resolution: Accept the response for #1502

Adjacent contrast and unobscured clauses #1399

rachael: adjacent contrast and obscured clauses...

<Rachael> Draft response is available at https://github.com/w3c/wcag/issues/1399#issuecomment-755797318

rachael: there was a q raised on if adjacent contrast bullet is needed. There's a draft response.

rachael: basically ... 8 agree.

rachael: no disagreement. Any additional discussions?

alastair: This has come up a few times. People don't get change of contrast and adjacent contrast. If there's any suggestions, we are open to those ideas.

<Rachael> Draft RESOLUTION: Accept the response for #1339

Resolution: Accept the response for #1399

<Jemma> yes. I agree with Alastair, adjacent contrast concept is not grab me right away.

+0

<Rachael> +1

<laura_> +1

<david-macdonald> If we need to talk about fixed reference points I'm here now

<alastairc> Jemma - adjacent is what people are used to, it's the 'change of' that has been confusing I think.

<Sukriti> +1

<sarahhorton_> +1

<Ben> +1

<juliette_mcshane> +1

<alastairc> +1

<Nicaise> +1

<mbgower> +1

Resolution: Accept the response for #1399

WCAG 2.2 Fixed References Points https://www.w3.org/2002/09/wbs/35422/wcag22-fixed-ref-points-updates/

<Rachael> https://www.w3.org/2002/09/wbs/35422/wcag22-fixed-ref-points-updates/results

A point for the Understanding doc #1227

rachael: suggested adding a sentence saying that having a page locator required and described is not intended to discourage other forms of navigation.

<Rachael> pull request: https://github.com/w3c/wcag/pull/1579/files

rachael: there's a pr that adds that sentence.

<david-macdonald> +1

rachael: 4 agree.

+1

<Rachael> Draft RESOLUTION: Accept PR 1579

<sarahhorton_> +1

<Nicaise> +1

<Rachael> +1

<Raf> +1

<laura> +1

<juliette_mcshane> +1

<GN015> +1

+1

<alastairc> +1

<Sukriti> +1

Resolution: Accept PR 1579

rachael: need a scribe for 2nd hour.

<Sukriti> I can

Clarification on the definition of electronic publication #1299

rachael: We have a couple of these questions.

<Rachael> https://github.com/w3c/wcag/issues/1299

rachael: there is a response provided. The q is asking for clarification about when the sc applies.

<Rachael> draft response: https://github.com/w3c/wcag/issues/1422#issuecomment-756736090

rachael: from a survey perspective, 2 agree, 1 with a change. Gundula?

gundula: An understanding q. I ask myself, we look for example of presentation of wcag 2.1, is this an electronic publication based on this definition?

dm: It's a great question. It's an e publication, I don't know... if we go back to epub wg, my understanding, the very fact is that a PDF, wouldn't say those pages are explicit. I don't think that's what we are trying to accomplish. Huge burden on web.

Gundula: If the requirement is for page locators to be present, they should be persistent
… if there are no page locators, SC might not be applicable
… definition should be enhanced

David M: in the pdf, if there are page numbers on ebook, which supports navigation
… the whole point is to be able to locate a page for example in a classroom setting

<Zakim> alastairc, you wanted to say that yes, but no page break locators.

Alastair: Doesn't have page break locators so wouldn't fall into SC. pdfs do have page numbers and mechanism is available
… not the case for epubs

Awk: Definition of a digital publication, which of those specs does wcag align with
… when we say digital version, are we presuming a physical version it's being compared to?

DavidM: historically, this SC assumed there was a physical version
… hope was to e-version of the book would have the same page numbers
… lots of problems with that

<alastairc> ok, maybe WCAG 2.1 wouldn't be, although I think the techniques documents could be?

DavidM: versions, and scope of wcag beyond the web

awk: are we going to be able to test and verify this?
… in the SC text, even if the formatting or platform change
… let's say there's a book with no physical version
… publish pdf and epub version where pages don't align
… which version fails?

<GN015> I feel both fail

DavidM: the platform would be different device, not different version of the content

<Jemma> .

<Jemma> I don't think it does fail

awk: we don't have anything else in wcag wrt platforms
… comes to what you compare it to
… need to have a correct one
… wouldn't know how to evaluate this

<JF> +1 to AWKs concern - what is "The Mater" reference?

<JF> *Master

DavidM: would look at the page on different platforms, not on the platform

<Jemma> +1 for not distinguishing the page numbers by platform

awk: core suggestion is to identify within the SC for an evaluator, what is correct
… digital version of a physical document as reference, vs different digital documents

DavidM: if it's in a pdf, it's a different webpage

<Zakim> Rachael, you wanted to note we have issue 1461 that also looks at dropping platform

<GN015> I agree: If they are not consistent, they fail both.

<Rachael> What is the scope of "platform", as there's no definition of what is a platform where electronic documents on the web are concerned. Concern is that this SC my be scoping in that the web-based document author is somehow responsible for how the pagination compares to non-web platforms (that may be marked up using a different language, such as MOBI) or even printed documents. The understanding didn't clarify the scope.

Rachael: In issue 1461 there was a request for clarification

<david-macdonald> we could drop "even went the formatting or platform change"

JohnF: concern is, platform to me is iOS vs Android for example
… seems you're speaking about formats
… printed on different size of papers can mean different numbering

MichaelG: 2.5 years ago, we tried tackling this. Making this more like a universal locator
… this is a problem. Locator changes depending on the format. I'm not sure we can solve it

<Jemma> Is fixed reference points and univeral locator the same concept here in SC?

MichaelG: potential path forward. Where you have a locator, timestamp might be a better way to think about it
… recollection, it came from the epub group

DavidM: originally 2 SCs
… most of the current language, and then one for AAA. If you have a book and the electronic version, then page numbers match

<Jemma> s/is fixed/are fixed

DavidM: maybe can do a fallback. There's a page break locator and what they're saying is these exist but not as links
… in epubs

<alastairc> Suggested big update: "For web content with <a>pagebreak locators</a>, a mechanism is available to navigate to each locator and each locator maintains its place in the flow of content."

DavidM: we maybe able to drop platform change
… and have what we need
… even with the formatting change

<Jemma> +1 to Alastairc's suggestion

JohnF: It's more than just platform
… what's a page in a pdf, arbitrary break
… even in the same document, landscape vs portrait, font size changes
… apples to oranges request
… specify page identifiers remain consistent but pagination might be difficult

MichaelG: what could we lose by going back to just the web version
… example would be table of contents, or pagination mechanism, if offered and there's a way to jump to that, it should go to the same location regardless of format

DavidM: If there are page break locators, should be a way to get to it

<Jemma> -1 I prefer to include e- document. how about working on this part with scope, "pagebreak locators" instead? https://www.w3.org/WAI/WCAG22/Understanding/fixed-reference-points.html#dfn-pagebreak-locators

<Zakim> alastairc, you wanted to suggest a bigger change

Alastair: What if it started with "for web content, with page break locators" to define scope
… maybe doesn't need the last bit about maintaining location

DavidM: we do want to limit to electronic publications
… someone was concerned about google docs

Alastair: might be a way. Page links could be locators
… let's try this and go back to commenters

<Zakim> KimD, you wanted to ask about scope

KimD: In our legal products, we have page breaks. Each book has its own citation. We publish cases, and within them, notations where page # starts in another location.
… is that in scope

DavidM: this is more of a reference or footnote

<Jemma> we may need to change SC name, in particular, "fixed" part

KimD: when you're citing a case, you need to give the quote cited
… if you're using a reporter publication, it's critical to know where the site lives and where to locate

DavidM: Same text in different publications and you want to make sure it can be found?

<Jemma> how about us deciding first whether this SC include discussion about "universal page locator" or not?

<alastairc> Preview of simplified version: https://raw.githack.com/w3c/wcag/wcag22-fixed-ref-points-updates-2021-jan/understanding/22/fixed-reference-points.html

KimD: ideally, you sign into a legal database, and would be able to go to a specific location

DavidM: would apply if they conform to WCAG and use page break locators
… visual or programmatic

<Zakim> JF, you wanted to ensure that if we go Alistair's route we include CSS Page-break-after

JohnF: what about not visual page breaks such as css page breaks
… with that technique, pagination doesn't work as soon as font size changes etc.
… might not apply to web pages
… example, wcag 2.1 is one single web page

<Jemma> https://raw.githack.com/w3c/wcag/wcag22-fixed-ref-points-updates-2021-jan/understanding/22/fixed-reference-points.html

<Rachael> Preview of simplified version: https://raw.githack.com/w3c/wcag/wcag22-fixed-ref-points-updates-2021-jan/understanding/22/fixed-reference-points.html

Alastair: would default to visual page break locators, that would be a wide scope
… but if programmatic, more controllable scope
… this isn't really aimed at web pages but documents that can be pages
… pdfs generally would meet by default

<Jemma> I prefer to have e document be included in this SC.

Alastair: page navigation built in
… epub doesn't have that and that's what it's trying to address

MichaelG: we're saying if there's a link it should keep on working
… in situations where page locator is not a link, we're requiring it
… don't think this is ready

DavidM: in the epub world,the problem is that page break locators are put in the document when no way to get to them
… as soon as you magnify, can't get to them

<Zakim> JF, you wanted to say that it's not "Links", it's pagination indicators

DavidM: trying to solve for linked programmatic marker

JohnF: this is not links, they are arbitrary markers
… page number could be inserted by the authoring tool
… this required print like behavior in electronic documents

Alastair: if you have links, this SC isn't needed
… word has a mechanism built in, same for pdfs
… it's for epubs where they have page break locators with no way to access

JohnF: isn't that a fault of the epub format?

Alastair: We do fix user agent issues with other SCs such as focus appearance

Rafal: much more useful is a very precise table of contents
… than pagination
… with ebooks being more and more popular
… table of content and search mechanism more useful

Gundula: word inserts numbers automatically. Once you enlarge fonts, page numbers change

<kirkwood> +1 Gundula

Gundula: two people have content on different pages

<alastairc> agree, but word has it's own mechanisms for navigating pages.

<Rachael> Option 1: Use simplified wording

Gundula: lots of time to get latest technology in schools and hence consider it very important

<Rachael> Option 2: Defer to WCAG 3

<Rachael> Option 3: Group to rework

Rachael: One option to use simplified version, another option to defer to WCAG 3
… option 3 to form a group and rework

MichaelG: What is the current timing for 2.2?

<alastairc> Option3 needs to be on a 2 week turn around...

Rachael: In the last steps before a second review
… group that tried to rework would need to come back in a week

<alastairc> Option 1, simplified and check with ePub folks

<Jemma> +1 option 1

<michael> 2

<Rachael> Straw poll: which option? Option 1: Use simplified wording, Option 2: Defer to future version, Option 3: Group to rework in 2 weeks

<sarahhorton_> 2

<Chuck> +1 option 1

<alastairc> https://raw.githack.com/w3c/wcag/wcag22-fixed-ref-points-updates-2021-jan/understanding/22/fixed-reference-points.html

<JF> Option 2

<JustineP> 2

<MelanieP> 2

<kaherr_> +1 Option 2

2

<GN015> +1 Option 3 (I feel it is already quite mature)

<Ben> 2

<kirkwood> option 2

<juliette_mcshane> 2

<Jemma> +1 option 3 too ;-)

<Wilco> option 2

<Jennie> 2

<JakeAbma> 2

<Francis_Storr> 2

<david-macdonald> Option 1t... but besides Alastair's suggestion

<Detlev> 2

<KimD> 2

<Raf> 2

<david-macdonald> 1

<laura> 2

<alastairc> 1, but would need to check with ePub folks anyway.

<Chuck> +1 no objections

Rachael: any objections to pursuing option 2?

DavidM: maybe there's a case of deferring. Can check with schools and see if it's still a problem. Can live with 1 or 2

Alastair: take this back to epub group
… if it is as simple as having navigation if page break locators exist

<Rachael> Proposed Resolution: Take the simplified vesrion back to Epub. If it is helpful, pursue otherwise defer

Alastair: we might be able to put something in

<michael> That works

JohnF: whose responsibility is it? author or agent

Alastair: A mechanism is available

JohnF: defining navigation and who is responsible
… is important

Alastair: we're making it very specific to epub documents

<Rachael> Proposed RESOLUTION: Circle back with EPUB. Let them know that the group prefers we defer but if the simplified version of the SC is still useful, we will revisit.

<AWK> I believe that the ability to navigate to a specific page in an electronic document and to have that be consistent with formatting changes is core to the EPUB group

<Jemma> +1

<Jemma> to proposed resolution.

+1

<sarahhorton_> +1

<juliette_mcshane> +1

<david-macdonald> +1

<Wilco> -0.5

<Ben> +1

<alastairc> +1

<Francis_Storr> +1

<kaherr_> +1

<Detlev> +1

<JustineP> +1

<JakeAbma> +1

<Chuck> +1

<laura> +1

<Rachael> +1

<kirkwood> +1

<MelanieP> 0

<GN015> +0.5

<AWK> +1

<michael> https://www.irccloud.com/pastebin/KFGL36Z1

<JF> -0.5

<Jennie> +1

<michael> +1

<Raf> 0

<michael> 0

<kirkwood> 0

<kaherr_> move to a 0

Wilco: it's a user agent problem
… should not be in WCAG

JohnF: going back to epub with this feedback and down the road do a workshop with them might help

DavidM: can send a draft of comms to epub

<Rachael> https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry-updates/

<Fazio_> good I can reply

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