Re: Some significant items for discussion on "What is a Web Publication?"

I agree with Avneesh here, we need to make it clear that accessibility can no longer take a back seat it must be designed up front at the beginning and it will take more effort from publishers / developers / content creators to make inaccessible publications than accessible ones.  If accessibility is built in then everyone will just use it and what gets created WILL be accessible.  This is where we need to get to and this is what we are pushing for.  As Deborah said in yesterdays call accessibility is a human right.

I would like each and every one of you put yourself in the shoes of someone disabled and think for a minute… You just purchased the latest blockbuster book which includes some awesome new technology that everyone is just raving about and you try to use it and all you get is “… sorry I am unable to access this content …”  Let make sure this doesn’t happen.

Thanks
EOM

Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
E-mail: charlesl@benetech.org<mailto:charlesl@benetech.org>
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301



On Jan 31, 2017, at 6:07 AM, Avneesh Singh <avneesh.sg@gmail.com<mailto:avneesh.sg@gmail.com>> wrote:


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.

Avneesh:
One way is to allow specs to meet WCAG. I think that this is mandatory.
More important is to design the specs in a way that it becomes nearly impossible to produce inaccessible content. This is the state that we will like to achieve.

With regards
Avneesh


Leonard

From: Avneesh Singh <avneesh.sg@gmail.com<mailto:avneesh.sg@gmail.com>>
Date: Tuesday, January 31, 2017 at 12:25 AM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, "kerscher@montana.com<mailto:kerscher@montana.com>" <k
erscher@montana.com<mailto:erscher@montana.com>>, 'DPUB mailing list' <public-digipub-ig@w3.org<mailto: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<mailto: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<mailto:avneesh.sg@gmail.com>>
Date: Monday, January 30, 2017 at 1:30 PM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, "kerscher@montana.com<mailto:kerscher@montana.com>" <k
erscher@montana.com<mailto:erscher@montana.com>>, 'DPUB mailing list' <public-digipub-ig@w3.org<mailto: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<mailto:kerscher@montana.com>" <kerscher@montana.com<mailto:kerscher@montana.com>>
Date: Sunday, January 22, 2017 at 12:10 PM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, 'DPUB mailing list' <publ
ic-digipub-ig@w3.org<mailto: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<mailto:public-digipub-ig@w3.org>) <public-digipub-ig@w
3.org<http://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