<laudrain> Sorry, is there a web meeeting or only phone?

George can scribe.

<laudrain> Thank you Tzviya

<Avneesh> https://www.w3.org/2002/09/wbs/35422/Final_prelockdown_set/

First topic metadata proposal on WCAG has no objections.

Anybody on WCAG can respond.

GK: Has jason changed his objection.

Avneesh, it is a new proposal and he has not object.

Avneesh new topic on navigation. Extensive discussion on github.

TS provided a link.

RD: There are several issues. Is nav in the MVM?

RM: A seperate is the format of the navigation.

LR: Agree on sepearation of issues.

DK: destinction of MVM and WP.
... my take is MVM is not the same as a min WP.

<tzviya> https://github.com/w3c/wpub/issues/22#issuecomment-321218784

<DanielWeck> WebEx says: the meeting has been cancelled

TS: echo DK, adding one the work is to get to a first public draft.

<DanielWeck> probably wrong WebEx link, please can somebody send me correct link + pass?

TS: We know we will have open issues, but we must have a draft in October.

<Zakim> tzviya, you wanted to point out that many issues need not be addressed before FPWD

for a AS: Nav is essential but we do not know where.

<DanielWeck> I'm in now, thank you!

LR: What does it mean that nav is not in the manifest. Dif between author provided versus a RS provided nav.

AS: Two sections in WCAG, two methods to navigate.
... Author can provide a convience in navigtion.

AS The structure can be provided through the structure of the doc.

.DK: IS the MVM we are trying to define it

<tzviya> https://w3c.github.io/wpub/#terminology

RD: I have simal concern. Abstract versus concrete. We must be clear.
... Another question is about strategy; there specifications, guidelines, and we need to determine what is our strategy.
... Do we want to follow the web approach

MG: Addressing the confustion. When we don't have a set of features it is difficult.
... the accessibility may be shifted down to the content document. Hard to define what is required is it critical. We need more clarity to answer questions.

<DanielWeck_> (rejoined after crash)

<Zakim> tzviya, you wanted to ask what you need clarified in monday's meeting

AS Nav is importint.

TS: I hear a lot of confusion. Starting with manifest is perhaps the wrong approach.

DK: We don't understand what a manifest is.

<rdeltour> +1 to tzviya

DK: What is a manafest.

TS: we need clarity of the function of a MVM.

DK: the def...is it all or a subset?

TS: This TF needs to be concerned, but right now there are no concerns.

JW: a TOC is normally provided by an author, but if not provided, can a RS provides a synthesised nav approach.
... it could be two different items. Content through a TOC, or the UA providing a nav approach. Those two items are distinct.

MG: Without a feature set, it is difficuleto define a MVM.

DK: The best thing for us to do is identify the functional requirements.
... we can bring issues of navigation to the larger group.

AS: Perhaps a wicki, but TS suggests it may be in discourse.

LR: I know you want to screw me. We want to make sure that authors have what they need, but we do not want to mandiate that a WP is accessible. Not mandiatory, but faciliate accessibility.

DK: Our goal should be to put forward the requirements. If the larger group would determine if accessibility is a must. It is not good use of the TF to say that accessible is not required.

<leonardr> @dkaplan3 - that's a reasonable point about the groups responsibilities. The only reason that I raised it is that with respect to a "minimal viable manifest", I don't see things related to a11y as part of that.

MG: Our objective is to make sure pubs can be accessible, but we cannot mandate that

AS: Nothing in our specs will make pubs inaccessible. if there are additional requirements that informs the larger group.

Summary we should have a wicki page on navigation so that wehen we discuss we have a reference for that work.

<dkaplan3> https://github.com/w3c/wpub/issues/24

<tzviya> https://discourse.wicg.io/t/nav-type-attribute-proposal/2241/18

navType is a proposal.there is a discussion about using ARIA or new navtypes. It is worth reading. the more that comment the better.itle is the next topic

AS: we should particiapte in the discussions.

<dkaplan3> ack

Topic Title discussion

<Avneesh> https://github.com/w3c/wpub/issues/20

DK: Issue 24 is a fork of title in manifest, but what are the requirements for a title in a WP, if it is needed at all.

<tzviya> https://github.com/w3c/wpub/issues/24

DK: I believe a title should be in the WP.

AS: from an accessibility perspective a title must be there.

LR: I would like feedback. How is the title used from an acccessibility context. How is the title is expected to be used.

TS: there are items from WCAG that address this.

<leonardr> thnks!

<BenSchroeter> regardless of where the title is declared, is it a minimum accessibility requirement that the language of the title be defined?

AS: title is important for discovery. It is also important for robustness. WCAG currently works with a single file model. We are helping to expand this to multiple documents. A title is very important for this.

<dkaplan3> The EPUB Accessibility doc addresses why an entire publication needs a single title: https://github.com/w3c/wpub/issues/20#issuecomment-320743037

MG: If you create something, it should have a name. It is useful, but for accessibility we cannot answer that yet. It could be in the MVM or in the content.

<dkaplan3> +1 avneesh

<laudrain> +1

Summary, the A11y wants to see a title, but we don't have a rec if it is in the MVM or the content doc.

Topic Primary resources and reading order.

MG: this is the choose your own adventure.
... there must be some order required, but it is dependent on the type of document.

BK: We are talking about publications and not books. What is the proper reading order for a magazine for example.

DW: Non liniar or ancillary. Requiring items in the spine has caused problems.
... in Readium 2, there are a sequence of primary docs. Anything outside the spine is an anslery.
... Based on what I have seen primary docs are needed and secondary support the primary, e.g. CSS. Anselary can also be primary.

<tzviya> much action on GitHub today about secondart resources https://github.com/w3c/wpub/issues/23

BK: My prob with default reading order is we know primary documents are identified and the user must be able to find those primary. Navigation to get to those documents is sufficient. A reding order is not needed.

DK: What are the parts that are vital to accessibility?

AS: There should be proper navigation in the publication.

TS: the conversation is ongoing. If you have questions raise them on the mailing list.

DW: non linary documents are anslery.

AS: next call?

MG: let's get away from non-linary.

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/scure/screw/
Succeeded: s/anslery/ancillary/
Present: Avneesh George Leonard laudrain Deborah_Kaplan rdeltour tzviya mattg Bill_Kasdorf jasonjgw DanielWeck DanielWeck_
No ScribeNick specified.  Guessing ScribeNick: George
Inferring Scribes: George

WARNING: No "Topic:" lines found.


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


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

Got date from IRC log name: 09 Aug 2017
Guessing minutes URL: http://www.w3.org/2017/08/09-pwg-a11y-minutes.html
People with action items: 

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


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report