<tzviya> Title: PWG Weekly Telco

<scribe> ScribeNick: NickRuffilo

<wendyreid> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-11-26-pwg.html

Wendy: Agenda items 1 - lets approve the minutes from the last meeting. Comments questions or suggestions?
...: Minutes approved. We have a new member who is not on IRC, but is in the room with me. Simon...

Simon: I've been involved in ebooks for a while, but new to W3C. I'm at Kobo. I'm new to the w3c and getting my bearings and hopefully my experience can help.

Wendy: First thing we have was and update on the MVP that Josh and Franco were able to make updates to the minimum conformance requirement an a few other refinements.

<josh> https://w3c.github.io/dpub-pwp-ucr/#minimal

Josh: (link pasted above) If you look at the link posted, since we last spoke there is a new TOC, minimal requirement that was written by Franco. The other changes made were that "identify" and a unique identifier, that language was changed to a unique URL or handle. A handle was then explained.
...: I'm referring to the DOI implementation handle system. I have a commit to add that one in there. For the most part, those are the minimal requirements. Requirement #10 (was read aloud...)

<dkaplan3> https://en.wikipedia.org/wiki/Handle_System

Franco: I am also working on some of - integrating some of Wendy's statements to be incorporated into audio books and making a pull request on that. As far as the minimal viable product, I'm not sure the best way to go about it, but we could go through each requirement and discuss them...

<dkaplan3> https://en.wikipedia.org/wiki/Handle_System
...: That's what we have so far - on the Table of Contents, adding something on audiobooks might be worthwhile, but that's what I've been thinking...

Wendy: As part of the explainer, there are a couple of points - if the minimum requirements represent the MVP, and if the MVP as defined offers viability. And if the current conformance classes need to be amended.

<derekjackson> +present

<caitlingebhard> +present

Tim: Quick question - the UCR includes a section on accessibility. Where do those fit into the hierarchy? In section C. Where do those live in the MVP?

Josh: Requirement 2 - the horizontal dependencies include accessibility. There is a section on accessibility, but there are new accessibility requirements we need to update. The Accessibility requirements have not been kept current.
...: Franco did a review of all the requirements and he determined which ones were and were not accessibility related - and you raise a good question, where do they all fit within the conformance classes and I don't have a good answer.
... Just looking at the current, some of them are in different classes - such as personalizing. That is not a minimum requirement. To answer quickly, I don't think all accessibility are a minimum.

Franco: I would say that if it falls under the extended list of requirements - or other that aren't in the minimal list... If the user agent provides something under the requirements beyond minimal, we want those requirements also to be accessible.

Tzviya: I think - like Josh said - we haven't done a great job looking at the accessibility list and how it fits to the other items. Perhaps we have to clean up the list of accessibility requirements. When we first created the list, we wanted to call them out to see if there were ones unique to publications.
...: They weren't a unique list, they were items pulled from other parts of the document - so the list duplicates from there.

<josh> +100 to Avneesh

Avneesh: The initial objective was to list the main requirements. There was some overlap, and there were items more specific to publications. Our perspective is accessibility is horizontal, so all requirements should have accessibility in it. the TOC itself is an accessible feature. When we work on MVP we have to make sure that they are all accessible.

Dave: This illustrates why I have trouble with a minimal viable publication. For many users, accessibility is fundamental and the only thing that will let them access the publication. For other authors, if I'm doing math, I have to include math. So defining a minimum subset doesn't mean the requirements of publications. I'm not sure the value of defining the subset of requirements.

Josh: I agree completely with Avneesh and Dave. I don't see the value in listing the requirements that are accessibility related. Everything we implement should be done so in an accessible way. There are functional requirements, but they should be done so in an accessible way. I'll defer to those who wrote to recall intention. Every requirement should be done in an accessible way.

<wendyreid> NickRuffilo: I fully agree that anything in the MVP needs to have a11y and be accessible

<wendyreid> ... I'm not sure I agree with Dave in that there's no value in an MVP

<wendyreid> ... once we have something out there that works for someone, we can iterate on it

<wendyreid> ... It might just be trade fiction, which is both exclusive and inclusive.

<wendyreid> ... we can build on it for other content types and builds momentum, an MVP that only hits one thing is still valuable

<wendyreid> ... I come from the startup world where you ship one small thing and build to make it a big thing, very different from standards

<wendyreid> ... but accessibility is core

Deborah: Focusing on accessibilty - this is a general thing. We can logic all we want about why you don't need to list requirements that are accessibility related. But every document we ever put out in draft or final form where we've logic'd ourselves into saying accessibility is addressed elsewhere - every single time we got negative feedback saying that we didn't note accessibility. Spec or requirements - we get negative feedback...

<wolfgang> s/accesibilty/accessibility/
...: our customers - in a university or a UA, our customers want specifically to know a list of things with accessibility. For buzz-word or legal reasons. We just need to do this.

Josh: Deborah - thank you for stating it. We want this document to be well recieved. I would ask that you suggest how we best go about this. From my way of thinking, functional requirements require that requirements are accessible. Should we just duplicate each requirement and say it needs to be done in an accessible way? We would appreciate your help in figuring how to note this.
...: We would call out certain (all) requirements as being accessible.

Tzviya: I think the section that exists now calls out really well the functionality needed to be accessible. But lets go back to the functional requirements.

Deborah: That seems reasonable. In answer to Josh - wherever we think things are duplicated. If the Accessibility section says "see this point" that would be good - we can hyperlink...

Avneesh: MVP - the objective is to indicate to the broader world, what is the minimum support required - so we can go to a browser and say "please implement this" Regarding the political reasons - with the Daisy and others - we mentioned some specific things about different countries. Where the MVP talks about metadata available we can just add "including accessibility metadata" so we just need to add a few lines to each requirements.

Josh: Requirement 2 is "a web publication should conform to all horizontal dependencies" The first of those is accessibility. Unfortunately, I made requirement 2 an extended requirement. Looking back, I think it should be a minimum requirement, then we're saying 'You're not a web publication unless you're accessible and has internationalization support' and all that entails.
...: We can quickly resolve this by agreeing/disagreeing to requirement 2 should be promoted to the minimal requirements.

Avneesh: I didn't go through the whole document - if this is the horizontal requirements, then it should be minimum. We shouldn't let a document go out unless it passes the review.

Wendy: Sounds like we have a few changes to make to minimum conformance.

Jeff: In terms of minimum requirement, I agree - if a WP is not accessible, should we prevent a user/creator to publish this book, or should we ask the browser/vendor to implement the accessibility requirements? I feel accessibility is important and a nice to have, but not a requirement for MVP of a WP
...: We want to define what is the focus for publishers and browser vendors - and the direction and feedback. We can then approve the next version of the document. I agree that accessibility is important, but not sure it should be included in MVP as it is a baby step moment. I have another thing. it's also important for accessibility to define what is the MVP for accessibility within a document. What is urgent and high priority for the system an[CUT]
... publication and modulize the spec? So have a WP accessibility - to let publishers and browser vendors to be the MVP.

<wendyreid> NickRuffilo: i think that accessibility needs to be an MVP requirement for the browsers, and I would love it if a validator warned about lack of accessibility within a document

<wendyreid> ... requiring the documents to be accessible, what would happen to them if they were not? Would the browser not render? How do we note that?

Deborah: There are a couple of questions - what are we talking about when we say MVP. For a decade, the trend in web has been permissive - things will open and render if they can. I do not believe, we have had conversations saying we are leaning against that...
... Which is, don't break if you see something noncompliant. The definition of Minimum Viable - something may not pass compliance checkers, but of course you'll render. If that's not what we're talking about - if we want enforced strictness, that's difficult. Perfect accessibility is nearly impossible. You can't enforce meaningful alt texts, for example...
... when people say accessibility is part of a base minimum, they don't mean WCAG AAA, but I will also say once you say anything is minimal viable, I will always dislike hearing that accessibility is a nice to have. You may not be able to enforce accessibility, but I've been in far too many meetings where when money or time runs out, all the 'nice to haves' drop off the list...
... if the only things that go into an MVP, most accessibility items don't make it in (you can only check for some things, such as missing alt) but if our accessibility statement is 'follow WCAG' then that's a reasonable ask...

Avneesh: We are in W3C - as part of that, going through the horizontals are requirement and accessibility needs are fundamental. We will not escape, so there's no need to debate on it and just make it essential.

Tzviya: I wanted to build on what Deborah said. Some are talking about content accessibility and some are talking about platform accessibility. That comes back to what MVP is. If we're defining what the user agent is, then we do need to talk about the accessibility of the UA. If we're talking about content, it's going to be unavoidable.

<dkaplan3> tzviya++, Avneesh++
...: If we're talking about the accessibility guidelines, then lets make sure we're in line with that. We have to recognize that accessibility is a requirement, and there will be a thorough review of this document by them. Lets make sure the requirements are there and we need to figure out what we're talking about when we say minimum...
... and lets make sure that we're addressing the other items around accessibility.

<tzviya> UAAG https://www.w3.org/TR/UAAG20/

Jeff: From my understanding, the first thing we wanted to define with MVP is the reading system and UA for the WP. If we want a feature and the web browser does not, that's a gap, but for accessibility, we do not have a list of what features need to be supported. The WP will not move on to the next step. Eventually we will have to fix WP content in the market.
...: We want to define MVP and move on the spec, and ask the vendors to implement - but until then we can't have content published. Towards that goal, the content or RS system needs to be accessible might be difficult. What the browser vendor should do to meet this spec? What accessibility feature would WP want?

Wendy: Lets end discussion on this here. Deborah and Avneesh, can you help Franco review the documentation for accessibility. As we noted, some of the accessibility documentation is out of date, so please review and make sure we're not missing anything.

George: When we do our testing of systems for features. Such as the ability to click a link. If the application does not allow the person with a disability to click a link but everyone else can click it, that feature fails. Once we do testing, including the accessibility piece, that will help us. That has not necessarily been done in previous testing/specifications.

Wendy: We discussed if the current conformance classes - should they be amended. Do we need something for offlining. That was the final question. Thoughts?

<wendyreid> https://github.com/w3c/wpub/issues/342

Wendy: In our last 20 minutes, I wanted to talk about open issues in the queue. Lets clean things up a bit. Hopefully close some issues.
...: 342 - Opened to address some comments about more than 1 page list (339). No comments on this issue. No interest. can we close?

Avneesh: To give background - normally we have one page list, but there were thoughts of having multiple page lists if the publication is mapping to different kinds of formatting. But then we decided to move on to the page list pros. If someone has a strong desire... but if someone wants multiple, we needed requirements. We never received strong requirements. I don't think there is interest.

Rachel: Avneesh reminded me why this is there. This is usually an educational need. When we have a textbook - say an economics text - we break it off into splits. In ebooks, we have a pagelist - and we have different instances of the book. The full book, the micro and macro...
... for an american history, we'll have the american history, early, later, etc... It's a necessity for educational publishing

<wendyreid> NickRuffilo: What is a pagelist and how is it different from a table of contents?

Tzviya: it's just the page mapping that goes along with page mapping to print...
... I can envision others - such as large print books - so it would have different page numbering.

<dauwhe> http://w3c.github.io/publ-epub-revision/epub32/spec/epub-packages.html#sec-nav-pagelist

Avneesh: Then I would recommend someone to provide the specification, and there is metadata for the print source. If it takes multiple sources, then it fits. But we need more information so we can correctly identify what is needed.

Wendy: Rachel, can you please comment on the issue with your use case...

<wendyreid> https://github.com/w3c/wpub/issues/341

Wendy: Next one - also about pagelists - 341 - There was discussion about identifying page list targets within the spec. The general consensus is that what is in the proposal wasn't spec-able, but more just guidelines.
... this is something that needs to be in an authoring guideline, but not spec.

Avneesh: For one piece, which is sync media - to provide background first. The page-break came from the notion that a person has the ability to skip the page numbers. The logical to page break shows that it's a skippable media. For media, this is important. When listening to audio, the playback may interrupt you, whereas when you're reading a text book, the announcement can be important. For media it's compulsory, but for text-only it could be o[CUT]
... I don't know if it should be in authoring only, or if it should be in spec as optional...

Wendy: We could close this and revisit when it comes up to sync media?

Matt: I think this specific issue was about enforcing a certain practice within the comments - such as page numbers must use a span or div. Avneesh was talking about whether or not it should be included. There are always cases for an against both methods, but it doesn't belong in spec. if there's another issue about recommendations about including page breaks in content, that's something we should include separately.

<zheng_xu> +1

<wendyreid> https://github.com/w3c/wpub/issues/338

Wendy: Next issues 338 - simplifying the web IDL. A quick review, there was a proposal to remove certain sections from the web IDL. I believe Ivan made some of these changes in a pull request, but just to clean up the web IDL and remove duplication.

Matt: I think we want to hold off, because there are changes that go with this are part of a future PR. The actual changes are sitting in an open pull request.

<wendyreid> https://github.com/w3c/wpub/issues/321

Wendy: 321 - opaque origin. The decision appears on the ticket that we've most of the references from the spec...
... Can we close this issue now that we've resolved it in the spec itself?

<tzviya> https://github.com/w3c/wpub/pull/343

Benjamin: Are there any commits to reference that point to how it was addressed in spec?

Wendy: There was something referencing removing some of the references. 343 - it's a pull request that was closed.
... But it was not merged. Sorry.

Benjamin: It is unsolved...

Dave: I think we need to review a bit more.

Tzviya: We've had lots of discussion but I don't think we're comfortable on it yet.

<wendyreid> /github.com/w3c/wpub/issues/321///github.com/w3c/wpub/issues/321

Matt: I thought with this one we were going to leave it as is because we weren't going to play with language that is already defined. While it may not be the most intuitive and clear term, it's understood by the UA and developers. We were going to leave it as it's part of the web-app-manifest prose.
... my understanding is that we were going to leave it alone for now.

<rkwright> More info than you may want: https://github.com/w3c/wpub/issues/321

Dave: Doesn't this prevent some types of web publications, doesn't it?

Matt: I don't think it prevents them, it just is about understanding cross-origin. But that's something done by the user agent. It's not something we're solving specifically.

Wendy: I will send out the minutes when they are done. Next week's agenda was sent, but the explainer will go out later.

<zheng_xu> bye

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/and/an/
Succeeded: s/committ/commit/
Succeeded: s/ery/very/
FAILED: s/accesibilty/accessibility/
Succeeded: s/provoted/promoted/
Succeeded: s/AAA/WCAG AAA/
Succeeded: s/you can only really check for missing ALT tags/you can only check for some things, such as missing alt/
Succeeded: s/disibility/disability/
Succeeded: s/recieved/received/
Succeeded: s/htink/think/
Succeeded: s/https://github.com/w3c/wpub/issues/321//
Present: wendyreid Rachel tzviya wolfgang NickRuffilo dauwhe george Tim_Cole zheng_xu Avneesh josh dkaplan3 rkwright bigbluehat mgarrish franco marisa Garth duga gpellegrino Teenya JunGamo jasminemulliken W3C
Regrets: Ivan_Herman Luc_Audrain Ric_Wright Bill_Kasdorf Romain_Deltour Evan_Owens Murata_Makoto Yanni_Chang Jeff_Buehler Mateus_Teixeira Caroline_Hayes Daniel_Weck
Found ScribeNick: NickRuffilo
Inferring Scribes: NickRuffilo

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: Could not parse date.  Unknown month name "12": 2018-12-03
Format should be like "Date: 31 Jan 2004"

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

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


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