Publishing Working Group Telco — Minutes

Date: 2018-12-03

See also the Agenda and the IRC Log

Attendees

Present: Matt Garrish, Wendy Reid, Rachel Comerford, Ric Wright, Tzviya Siegman, Wolfgang Schindler, Nick Ruffilo, Dave Cramer, George Kerscher, Zheng Xu (Jeff), Tim Cole, Avneesh Singh, Joshua Pyle, Deborah Kaplan, Benjamin Young, Franco Alvarado, Marisa DeMeglio, Garth Conboy, Brady Duga, Simon Collinson, Derek Jackson, Caitlin Gebhard, Gregorio Pellegrino, Teenya Franklin, Jun Gamou, Jasmine Mulliken, W3C

Regrets: Ivan Herman, Luc Audrain, Ric Wright, Bill Kasdorf, Romain Deltour, Evan Owens, Murata Makoto, Yu-Wei Chang (Yanni), Jeff Buehler, Mateus Teixeira, Caroline Hayes, Daniel Weck

Guests:

Chair: Wendy Reid

Scribe(s): Nick Ruffilo

Content:


Tzviya Siegman: Title: PWG Weekly Telco

Wendy Reid: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-11-26-pwg.html

Wendy Reid: 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 Collinson: 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.

1. MVP update

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

Joshua Pyle: https://w3c.github.io/dpub-pwp-ucr/#minimal

Joshua Pyle: (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…)

Deborah Kaplan: https://en.wikipedia.org/wiki/Handle_System

Franco Alvarado: 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…

Deborah Kaplan: https://en.wikipedia.org/wiki/Handle_System

Franco Alvarado: 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 Reid: 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.

Tim Cole: 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?

Joshua Pyle: 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 Alvarado: 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 Siegman: 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.

Avneesh Singh: 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.

Joshua Pyle: +100 to Avneesh

Dave Cramer: 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.

Joshua Pyle: 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.

Nick Ruffilo: I fully agree that anything in the MVP needs to have a11y and be accessible
… I’m not sure I agree with Dave in that there’s no value in an MVP
… once we have something out there that works for someone, we can iterate on it
… It might just be trade fiction, which is both exclusive and inclusive.
… we can build on it for other content types and builds momentum, an MVP that only hits one thing is still valuable
… I come from the startup world where you ship one small thing and build to make it a big thing, very different from standards
… but accessibility is core

Deborah Kaplan: Focusing on accessibility - 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…
… 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.

Joshua Pyle: Deborah - thank you for stating it. We want this document to be well received. 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 Siegman: 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 Kaplan: 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 Singh: 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.

Joshua Pyle: 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 Singh: 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 Reid: 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 modularize the spec? So have a WP accessibility - to let publishers and browser vendors to be the MVP.

Nick Ruffilo: 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
… 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 Kaplan: 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 non compliant. 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 Singh: 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 Siegman: 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.

Deborah Kaplan: tzviya++, Avneesh++

Tzviya Siegman: 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 Siegman: https://www.w3.org/TR/UAAG20/ -> UAAG

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 Reid: 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 Kerscher: 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 Reid: We discussed if the current conformance classes - should they be amended. Do we need something for offlining. That was the final question. Thoughts?

2. issue clean ups

Wendy Reid: 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.

2.1. Issue 342, page lists

Wendy Reid: https://github.com/w3c/wpub/issues/342

Wendy Reid: 342 - Opened to address some comments about more than 1 page list (339). No comments on this issue. No interest. can we close?

Avneesh Singh: 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 Comerford: 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

Nick Ruffilo: What is a pagelist and how is it different from a table of contents?

Tzviya Siegman: 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.

Dave Cramer: http://w3c.github.io/publ-epub-revision/epub32/spec/epub-packages.html#sec-nav-pagelist

Avneesh Singh: 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 Reid: Rachel, can you please comment on the issue with your use case…

2.2. 341 Page list targets

Wendy Reid: https://github.com/w3c/wpub/issues/341

Wendy Reid: 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 Singh: 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 Reid: We could close this and revisit when it comes up to sync media?

Matt Garrish: 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 (Jeff): +1

2.3. simplifying the WebIDL, #338

Wendy Reid: https://github.com/w3c/wpub/issues/338

Wendy Reid: 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 Garrish: 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.

2.4. Opaque origin #321

Wendy Reid: https://github.com/w3c/wpub/issues/321

Wendy Reid: 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 Siegman: https://github.com/w3c/wpub/pull/343

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

Wendy Reid: There was something referencing removing some of the references. 343 - it’s a pull request that was closed.

Wendy Reid: But it was not merged. Sorry.

Benjamin Young: It is unsolved…

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

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

Matt Garrish: 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.

Ric Wright: More info than you may want: https://github.com/w3c/wpub/issues/321

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

Matt Garrish: 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 Reid: 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 (Jeff): bye