- From: Liam R. E. Quin <liam@w3.org>
- Date: Tue, 31 Jan 2017 08:51:00 -0500
- To: Leonard Rosenthol <lrosenth@adobe.com>, Avneesh Singh <avneesh.sg@gmail.com>, George Kerscher <kerscher@montana.com>, 'DPUB mailing list' <public-digipub-ig@w3.org>
On Tue, 2017-01-31 at 11:40 +0000, Leonard Rosenthol wrote: > I am perfectly fine with that wording, because it’s a should and not > a must. It’s the use of must that I am arguing against, since in a > standard, that is a mandated requirement. Should is a strong > recommendation, and I agree, that we want to give that type of > recommendation. > > So if you are fine with the wording “WP/PWP should be accessible to > the extent possible, and should conform to WCAG” – so am I. The spec itself will certainly conform to the content authoring guidelines or we won't publish it. But I think what you mean is that it MUST be possible to create WP/PWP instances that conform to WCAG, and that the specification must designed in ways to facilitate and encourage this. Best, Liam > > Leonard > > From: Avneesh Singh <avneesh.sg@gmail.com> > Date: Tuesday, January 31, 2017 at 12:25 AM > To: Leonard Rosenthol <lrosenth@adobe.com>, "kerscher@montana.com" <k > erscher@montana.com>, 'DPUB mailing list' <public-digipub-ig@w3.org> > Subject: Re: Some significant items for discussion on "What is a Web > Publication?" > > “WP/PWPs can be made accessible but need not be so” > Hi Leonard, this is exactly the statement that is troubling me. > Our approach is: WP/PWP should be accessible to the extent possible, > and should conform to WCAG. i.e. must for accessibility in general > and should for WCAG conformance. > This means that it is not mandatory to conform to WCAG, but > accessibility is a requirement. > > This will be in line with the world wide efforts for reinforcing > accessibility in publication's, while giving adequate flexibility to > new developments that may not conform to WCAG at early stage. > > With regards > Avneesh > From: Leonard Rosenthol<mailto:lrosenth@adobe.com> > Sent: Tuesday, January 31, 2017 00:45 > To: Avneesh Singh<mailto:avneesh.sg@gmail.com> ; George > Kerscher<mailto:kerscher@montana.com> ; 'DPUB mailing list'<mailto:pu > blic-digipub-ig@w3.org> > Subject: Re: Some significant items for discussion on "What is a Web > Publication?" > > Avneesh – as I mentioned on the call today, do not conflate the work > on Web Publications (and Portable Web Publications) with that of the > evolution of EPUB. These are two separate work items clearly spelled > out as such in the DRAFT Charter. > > I would expect that the evolution of EPUB does mandate accessibility > just as it does today. I don’t believe anyone has stated otherwise. > What I am have pushing back on is that WP/PWPs can be made accessible > but need not be so. > > Leonard > > From: Avneesh Singh <avneesh.sg@gmail.com> > Date: Monday, January 30, 2017 at 1:30 PM > To: Leonard Rosenthol <lrosenth@adobe.com>, "kerscher@montana.com" <k > erscher@montana.com>, 'DPUB mailing list' <public-digipub-ig@w3.org> > Subject: Re: Some significant items for discussion on "What is a Web > Publication?" > > It looks that my q+ command could not go through in today’s call. > Therefore I will like to add comments to the thread. > > Firstly it would be important to get some clarification on, is term > “Accessibility” equivalent to “WCAG”? > If it is not equivalent, and the term “accessibility” is more > flexible then it is easier to place it as a “must”. > > I heard argument of Ivan, that accessibility is “strong should” and > not a “must” in W3C. I completely understand it. > For publications accessibility we have 2 objectives. > 1. Accessibility should be a stronger force in publications than > other web technologies because education in many countries emphasize > accessibility. It was well stated by Luc, and was also recognized > during use case development. > 2. The new transformation of EPUB that comes from W3C WG should have > accessibility embedded in it from its birth. We should not repeat the > history of EPUB, where accessibility became a high priority only in > the version 3. > > I would suggest 2 actions for the charter: > 1. If the term “accessibility” is more flexible than “WCAG” then we > should state that web publication must be accessible to the extent > possible. > 2. We should increase the emphasis on our work with WCAG 2.1 and WCAG > 3. The objective of our work is to ensure that WCAG is applicable to > web publication's. > > With regards > Avneesh > From: Leonard Rosenthol<mailto:lrosenth@adobe.com> > Sent: Monday, January 23, 2017 00:10 > To: George Kerscher<mailto:kerscher@montana.com> ; 'DPUB mailing > list'<mailto:public-digipub-ig@w3.org> > Subject: Re: Some significant items for discussion on "What is a Web > Publication?" > > George, I completely agree with you about the need (or, as you said, > better – right!) for accessible documents. And I do want to make > sure that we take every step possible to make it as easy as possible > for authors to produce accessible WPs – and identify them as > such. I also expect that for profiles of WP focused on > “publications that are fit for public consumption and sale”, the > mandating of accessibility (such as is done today with EPUB) is > almost a given. > > But there are also use cases for WP’s where accessibility need not be > mandated (or, oddly enough, even necessary). And WP itself – as the > “baseline” for the various profiles described in the PWP document > (and the WG draft charter) – needs to be flexible enough to address > both those cases (and more). > > Leonard > > From: "kerscher@montana.com" <kerscher@montana.com> > Date: Sunday, January 22, 2017 at 12:10 PM > To: Leonard Rosenthol <lrosenth@adobe.com>, 'DPUB mailing list' <publ > ic-digipub-ig@w3.org> > Subject: RE: Some significant items for discussion on "What is a Web > Publication?" > > Dear Leonard, > Where you write: > Here’s the one where George, Charles and others are going to be > scream – but I believe it is an extremely important point – you can’t > mandate accessibility in a WP (ie. “A Web Publication must be > accessible to the broadest possible range of readers”). We should > make it a strong recommendation (a “should” vs. a “shall” in ISO > terminology) and do all we can to promote this direction. However, > given our goals to support not only curated publications but also ad- > hoc publications, it is not reasonable to expect them all to be > accessible. Just as not every page on the web is accessible, web > publications need not be either. > > You are correct about me objecting. It is said that, “Silence is > violence.” And I am not going to be silent on this > > Access to information is a civil right in many nations and the > “Convention on the Rights of Persons with Disabilities (CRPD) treaty > supports this, and as I have said, it is a human right. > > I am a very practical guy and understand that it is extremely > difficult to make all materials accessible to all people. In EPUB > 3.1, we have theEPUB Accessibility Conformance and Discovery > specification, which identifies a baseline for accessibility. Also, > in the WCAG 2.1 developments that are kicking off, digital publishing > is in scope. > > So, I think this will require significant discussion, but I feel that > metadata will be very important in the identification of publications > that are fit for public consumption and sale. > > Best > George > > > > > > From: Leonard Rosenthol [mailto:lrosenth@adobe.com] > Sent: Sunday, January 22, 2017 9:16 AM > To: DPUB mailing list (public-digipub-ig@w3.org) <public-digipub-ig@w > 3.org> > Subject: Some significant items for discussion on "What is a Web > Publication?" > Importance: High > > While working on the PWP document today, I can into a few things that > I’d like to raise for discussion (either via email or phone tomorrow, > or both). > > Let’s start right up front with the definition of a Web Publication > ☺. It currently reads “A Web Publication (WP) is a bounded > collection of resources, envisioned and created as a whole”. I would > like to review the second half of that sentence – about the > envisioned and created as a whole. In the world of documents, the > most popular feature of processing applications is the ability to > combine parts of other documents together to create a new one. In > that use case, the resources weren’t “envisioned and created as a > whole”. You could say that the author/publisher envisioned that > collection and intentionally collated those resources together – but > that’s different from what is here. I would also put forth that the > application of annotations to a WP can create a new WP that also was > not “envisioned and created as a whole”. > > > There is a requirement that “The package must include the unique > identifier of the manifestation—a Web Publication’s origin is > essential information if a PWP becomes portable”. Two paragraphs > later it goes into further detail about the origin inclusion and even > mentions trust. Unfortunately, that requirement seems to imply some > potential implementation considerations that the WebPackaging work is > proving to not be feasible – see https://github.com/dimich-g/webpacka > ge/issues/7. I would like to remove the second half of that sentence > (about the origin) and also remove the bit about trust from the > latest paragraph. Let’s just leave it open that we want a unique > identifier, but that’s it, and that the origin is not necessarily > related to the identifier. > > > Here’s the one where George, Charles and others are going to be > scream – but I believe it is an extremely important point – you can’t > mandate accessibility in a WP (ie. “A Web Publication must be > accessible to the broadest possible range of readers”). We should > make it a strong recommendation (a “should” vs. a “shall” in ISO > terminology) and do all we can to promote this direction. However, > given our goals to support not only curated publications but also ad- > hoc publications, it is not reasonable to expect them all to be > accessible. Just as not every page on the web is accessible, web > publications need not be either. > > > Another area that we cannot mandate – but should make a strong > recommendation – is that “A Web Publication must be available and > functional while the user is offline”. An author may produce a > publication that is only designed to be used online – for example, > one that connects to an online system. We don’t wish to prevent the > development of such a publication. > > > Finally, I think we say too much about the use of the manifest. It > says “We also introduce the abstract concept of a manifest, which > serves to carry information about the constituent resources of the > publication, their sequence, and presentation”. I think we should > only say that it carries the resources and not mention sequence and > presentation. This is consistent with our statement, earlier in the > same section, about how we aren’t going to define “manifest” (and > leave it in the generic FRBR sense). > > > Leonard
Received on Tuesday, 31 January 2017 13:51:13 UTC