See also: IRC log
mgylling: discussing alterations to agenda
... any objections to move a11y notes status to the end of the meeting?
(silence)
scribe: let's get going
<mgylling> https://www.w3.org/2016/02/29-dpub-minutes.html
mgylling: any objections?
(silence=consent)
scribe: minutes approved
mgylling: we mentioned this a month ago
... we wouldn't be able have a physical f2f this "semester"
... we are meeting at TPAC
<lrosenth> Do you have the details on the fall F2F?
mgylling: instead of a virtual version of a
normal f2f
... the idea is to have 4 hr meetings which focus on one or two topics
... I think we should try this; see if it works for us
... could also work for task forces as well as entire group
... we have a proposed date and proposed topics
... may 25, from 12UTC to 16UTC
... we acknowledge it's not an ideal time for everyone
... the topics are twofold
... first, is to work on use cases
... second, to work on the notes in our pipeline
... not sure where they will be in the process
... but we want to help note editors to speed their progress
... any questions?
lrosenth: are you suggesting that 4-hr block on the 25th is just for those two topics?
mgylling: yes
... both of these sessions are intended to be different than the Monday
calls
... we want to do work, not just plan and track
... edit docs, produce new use cases
lrosenth: is the expectation that we'd use same communication as current meetings? Webex and IRC?
mgylling: perfect question.
... if we want safe and simple stay with IRC and webex
... we can't expect to have working videoconference via webex
ivan: we can try
... we've used webex with video with 7-8 people and it works
<pkra> hangouts-on-air does 10 ppl, plain hangouts 15 ppl.
ivan: and I don't know of alternative tech available to us
mgylling: that sounds good
... let's try it.
ivan: I'll continue to be on video for the rest of this meeting
mgylling: cool
lrosenth: i'll be in Europe that week; we could get together in an Adobe office
ivan: where?
lrosenth: Berlin, but it could be elsewhere
mgylling: there's nothing preventing such
gatherings
... in terms of the topics
... these are two topics we thought would be a good thing to work on
... if you think we missed something, speak up now
... we may modify as the date comes closer
... ivan, anything else?
... there's not a lot of admin involved
ivan: nope
... I can set up a webex
... I'll wait a few weeks before arranging
mgylling: we'll make an announcement ASAP
... charles, are you here?
... OK if we do a11y note now?
... we know y'all are close
<HeatherF> I thought we wanted a11y in the second half?
<clapierre3> http://w3c.github.io/dpub-accessibility/
mgylling: we want to help
clapierre3: just pasted a link to the
current note
... there's been a lot of discussion, presented at IDPF meetings
... we asked w3c to informally take a look
... Michael Cooper reviewed our note and made some suggestions
... and suggested a joint meeting with WCAG
... to bring common understanding of the needs and how to meet the needs
... also a review from Alistair Campbell
... our current plan is to rewrite the suggestions, to do gap analysis
... change the ordering
... rewrite the abstract
... have to go through lots of line item suggestions
... and bring them here or to a11y group
... and will convert our google doc to wiki table
... reach out to Avneesh and Matt Garish
... harmony between EPUB a11y profile and our note
... and want help from Matt on wording etc
... we hope to have all of these changes by March 25
... then we'll reach out to WCAG for a joint meeting
... the missing thing is metadata and packaging
... some of that could be a formal extension to WCAG
mgylling: the meeting with WCAG after march 25, the purpose is?
clapierre3: potentially... we want to give
the note to them for their suggestions
... we had a lot of "WCAG should do this"
... and they suggested that we shouldn't be that blatant
... and should change the wording
... and could better harmonize with other groups
lrosenth: the purpose of the note?
... I understand finding gaps in WCAG
... and that's very clear
... I'm unclear on other goals of the committee
clapierre3: that is the main goal--identify
gaps in WCAG and fill those gaps
... and that work will continue in our task force
... possibly writing a WCAG extension...
... the note is a first step to bring these issues to light
... then work on next steps
ivan: purely on timing
... between April 5 and April 18 I will be unavailable
... there's an IDPF F2F, EPUB Summit in Bordeaux, Then Web Conference in
Montreal
... for the last round on a practical level you'll need me for
publication stuff
... and that can't be done before late April
... keeping in mind publication dates are Tuesdays and Thursdays
clapierre3: I'm sure there will be some
tweaks after we bring it to WCAG
... so we might be able to do that during April
... we have to schedule meeting after March 25; don't know when meeting
will be, and then make
changes
ivan: so my timing is OK?
clapierre3: absolutely!
mgylling: in terms of feedback from beyond
the IG
... you mentioned Michael Cooper, etc
... is there any patterns in the feedback that are interesting? Or are
they just random?
... can we see a tendency?
clapierre3: Alistair's comments were
insightful
... he suggested rewriting the abstract, as it didn't match
... he thought overall the note was very good on gaps
... lots of nitpickly things
... I haven't had a chance to dig into it
mgylling: cool
... one comment I heard a few times
... was the entry about dropcaps
clapierre3: we're thinking it's not really
an issue
... we just need to work with CSS on styling of dropcaps
... so publishers know what to do
... the CSS does exactly what you want
... don't know if we'll take it out
... because this is aimed at w3c... still up for discussion
... what is your recommendation?
... since it's already covered we don't need to bring it up?
... EPUB 3.1 will reference this note, so publishers will see it
... it will be public, right?
mgylling: we can discuss it
... from my point of view, that thing is on a different level
... it's just one example of an uniformed authoring practice
... we don't want this to be a technique doc
... we want to stay on a high level like WCAG
... this feels like it's drifting into technique
... maybe this is a different issue to go into details
clapierre3: it's a slippery slope
... something like dropcaps is fundamental for a11y. if the markup is
wrong the word will be mispronounced
... maybe an appendix?
... and this note can evolve.
pkra: quick question on math
... I filed a bug report on IDPF tracker
... trying to figure out if I should file a bug on ARIA
... will you put in something on math?
clapierre3: I've reached out to some
groups... potentially we could do an ARIA module with math terms
... you're starting a CG
... there's a gap there.
pkra: on the IDPF, the current suggestion
is to use MathML and then use MathML's @alt-text. But that doesn't work
if AT doesn't support math
... and aria-label isn't in the rec
... short-term things
mgylling: I'd love to talk to you more about that
<pkra> that was my question :)
mgylling: is that really in scope for this
document?
... the original scope was gaps in WCAG, etc
<pkra> I'm obviously fine if it's not
mgylling: are we saying they are not dealing with match sufficiently?
<pkra> who are you asking?
mgylling: if so, in what respect?
clapierre3: I know there are issues
... the browsers are supposed to support, and they don't
mgylling: and your paper isn't scoped to point out all issues with browsers
pkra: my bug wasn't about people expecting
to render MathML,
... it's just odd to point out unsupported tech as recommendation
ivan: we have to be careful on focus
... handling math properly would mean working with and on ARIA, and
that's not WCAG
... and this doc is on WCAG things
... there can be a different doc on things other than WCAG... here are
the general a11y issues
... along with chemistry, music...
... that's a different set of problems
... putting that on the WCAG doc seems to be over the top
... let's do one thing at a time
... once this is published
... we could look at more general issues
... that are currently not handled by a11y techniques
clapierre3: I agree. That's a good idea,
and a good direction for the task force
... there's a future work section in our doc, pkra can help us with a
note
<pkra> +1
<pkra> Happy to.
ivan: I can get people from
MusicML
... and tzviya has contact with people in ChemML, etc
... none of these have proper a11y mapping
<mgylling> ACTION pkra to help the A11Y note group with prose on MathML and STEM
<trackbot> Created ACTION-55 - Help the a11y note group with prose on MathML [on Peter Krautzberger - due 2016-03-14].
ivan: the stem area is not properly handled
clapierre3: thanks for your help, pkra
mgylling: it's good to establish it here, so we have a clear way ahead
rdeltour: based on the discussion on EPUB
ml
... about specialized publications, and thus don't conform to
WCAG
... like an audio book which doesnt' have text equiv
... given that DPUB has relationships with WCAG
... should we add this issue on the plate of the DPUB a11y task force
mgylling: should it go in the note
rdeltour: the need to identify restrictions of WCAG for specialized publication
clapierre3: for audio only books, that's just a specific rendition
mgylling: at this time there is not
rdeltour: wcag was created for the web, so
content should be universal
... but some publications have limited target audience
... if there is accurate metadata, it would make sense to limit the wcag
levels
lrosenth: i think there's some confusion
here
... rdeltour seems to be imply there will be a11y requirements on any
PWP
... the group is identifying issues not covered by WCAG
... but we're not saying every PWP has to be accessible
... like having an archiving profile
... but we haven't said there's a requirement
rdeltour: I don't think that's the issue
... WCAG is just not applicable on some digital publications which are
otherwise accessible to the target audience
lrosenth: that doesn't apply to pwp, because it does not have a requirement
mgylling: but the note is not about PWP,
but about digital publishing in general
... wcag doesn't work well for a braille ebook or audio-only ebook
... this was discussed on the EPUB list
... it's a good problem to mention in the note
clapierre3: a publication is one of the
gaps
... wcag doesn't handle multiple file
<ivan> b.t.w. the PWP document says "A Web Publication should provide accessible access to content.", see https://w3c.github.io/dpub-pwp/#pwp_definition
clapierre3: metadata is missing in WCAG too
... "this is an audio-only rendition" put that in the metadata
... so you might have to add a text rendition to get WCAG compliance
<lrosenth> @ivan - yes, SHOULD (as in a recommendation, not a requirement)
mgylling: rdeltour, what do you think?
rdeltour: I'll think about it
clapierre3: the more help the better!
<mgylling> ACTION rdeltour to propose prose re DPUB audio and braille type issues with WACG
<trackbot> Created ACTION-56 - Propose prose re DPUB audio and braille type issues with WCAG [on Romain Deltour - due 2016-03-14].
mgylling: we have one more major agenda item
ivan: can we move to next week?
clapierre3: sorry that Deborah and Tzviya couldn't participate
mgylling: let's move on
mgylling: how should we spend 16 minutes
... this is one of the most important things we do this year
... bringing order to our use case collection
<ivan> Romain's writeup on the use cases: https://github.com/w3c/dpub-pwp-ucr/wiki/Use-Cases-Overview
mgylling: it's important because it will be
good fodder for a future PWP working group
... and the current state of our wiki is... sub-optimal
... rdeltour, you have been officially leading the work on the tracker
... going through existing stuff
... and we have stuff incoming from subgroups
... let's start with Romain
... you sent a pointer to a wiki page
rdeltour: in the issues, we reviewed all
the existing use cases
... many are out of scope
... the rest need to be reworked and rephrased
... we need to almost start from scratch
... so in the wiki I listed the identified areas where we need more use
cases
... all the first-level bullets are what we had in the previous wiki
... the 2nd level bullets are the use cases
... for some, we can elaborate on existing cases
... for some others, we have to start from scratch
... or we can work from discussions on the emailing list
... and there are areas where we lack discussion, like packaging and
security
... and then we're waiting for input from other task forces, like a11y
and archiving
... that's the overview
mgylling: thanks, that's a great start
... having a list of work that needs to be done
... you said, wipe it clean and start from scratch
rdeltour: it's editorial work
clapierre3: I was looking at use cases
... we can help with audiobooks in HTML5 as a use case
mgylling: the problem we're having is that
we need to figure out how to best go about this with limited resources
... in the early stages we organized ourselves in these categories and
worked only on use cases, and that trickled away
ivan: yes, that's what happened
mgylling: so we tried before, and it didn't work so well
rdeltour: one issue was fragmentation
... the existing use cases... some were just one-liners, not very
developed
... we need more-encompassing use cases
mgylling: one use case from which multiple requirements can be derived
TimCole: for the archival TF, scope is a
question.
... what kinds of use cases are of interest
... we talked about how LOCKKS tries to preserve digital content
... are there implications from stuff like that?
... how might this inform the PWP development?
... LOCKKS tries to cache/ proxy cache... it looks at the accept header,
looks at the wire
... checks to see if my copy is out of date
... given that pwp can be packaged or unpackaged on the web
... this may mean that the lockks archive might not capture the whole
package
... but this doesn't fall into your categories right now
... so what is the scope?
mgylling: maybe ivan wants to answer
... the categories are not locked in stone, and were just inherited from
wiki
rdeltour: and that's not expected to be the final outline
mgylling: when in doubt, write it down and
submit it. That's much better than keeping it out
... we can prune later
TimCole: for the next couple of months, the
archival group will have its own page on github
... we can filter later
ivan: so we should not forget that the list
of use cases on the wiki
... came in the very early days of the group
... where this whole idea of PWP was not even clear
... in some sense now what we have is a bifurcation
... we have use cases from the digital publishing community at large,
largely about CSS
... we must continue to collect these and push to CSSWG
... the use cases in Romain's doc should not include the
typesetting/CSS/rendering use cases
<rdeltour> +1
ivan: this is the doc for use cases bound
to the vision of the PWP document
... what are the features raised by this vision
... even a11y
... I would not be sure
... the a11y issues are largely general DP issues that this group is
taking care of
... there may be some issues which are bound to and relevant to PWP
... the same filter should be applied to all use cases
mgylling: we'll have to weigh all of these
individually
... like audiobooks
... it's a functional requirement for PWP to have an audio-only
manifestation
<clapierre3> 1+
ivan: and maybe beyond that
... there may need to be many renditions
mgylling: that's one thing... use cases for
multiple renditions
... we've run out of time; we need to get back to this
... look at resources and a plan to move ahead
... beyond the subgroups, which are doing stuff on their own
... we need to do more
... anything else?
... thanks everyone. see you next week