-
Notifications
You must be signed in to change notification settings - Fork 6
Accessibility Task Force
Please scroll down or jump to next heading for meeting minutes.
- Avneesh Singh - Chair (DAISY Consortium)
- Peter Krautzberger
- Rachel Comerford (Macmillan)
- Jason White (ETS)
- Matt Garrish (DAISY)
- George Kerscher (DAISY)
- Charles LaPierre (Benetech)
- Jon McGlone (University of Michigan)
- Ben Schroeter (Pearson)
- Luc Audrain (Hachette)
- Bill Kasdorf (Apex)
- Daniel Weck (DAISY)
- Cristina mussineli (LIA)
- Rick Johnson (Vital Source)
- Marisa DeMeglio (DAISY)
- Romain Deltour (DAISY)
- Bernhard Heinser (Access For All, Zurich)
- Makoto Murata (JEPA)
- Fernando Pinto
- Deborah Kaplan (Invited Expert)
Present: Avneesh, dkaplan3, rdeltour, Luc, Charles , mattg, tzviya, Bill_Kasdorf, g_pellegrino, Jason.
Chair: Avneesh
Scribe: rdeltour
Topic 1: Requirements for aria 2.0, and possibly HTML. (E.g. new roles, List-Head, non-structural headings etc.).
Avneesh: what have we required in the past, what’s the way forward
mattg: not sure what we want for 2.0 Tzviya: https://github.com/w3c/dpub-aria/issues/8
mattg: we have issue #8 in GitHub ... are there any pressing, obvious semantics we missed out in 1.0, if so, what are they? ... we had discussion about frontmatter, bodymatter and backmatter ... the other question that was raised earlier on (by Leonard?) was how to get to title page ... then also requirements for poetry ... that’s all that came up in open issues for added semantics
clapierre: Was there any comments against any of the existing vocabulary semantics in the original version?
mattg: those are the open items we have ... also the question of follow in on the heels of 1.0, is should our focus be on promoting 1.0 rather than add even more to 1.0? ... maybe deal with errata first, and clean up the spec ... I don’t know which direction we want to go
Avneesh: we already made the decision in the PWG call that we mainly want an errata ... additional things depend on pressing issues and the timeline
dkaplan3: there's a couple of things/reasons why I don’t think we need to spend time on new terms, maybe not even too much on errata ... one reason is that right now there's no functionality to it ... AT parses it, but RS won't do anything with that ... adding more terms isn’t needed ... the other thing, is we need to take a step back and think about what is DPUB ARIA ... are we trying to recreate TEI? ... a lot of the terms shouldn’t be invisible to anyone not using AT ... maybe not belong to ARIA ... ARIA is for those things which are AT only ... we need to remember that ... maybe semantics should be added, but ARIA by design isn't going to be available by non AT users ... we may be doing bad decisions ... as far as I know there is no plan by Reading Systems to implement them ... we are adding semantics to the a11y tree only, people forget that ... every single thing needs only be usable by AT ... our focus on the errata should be brisk
bill_kasdorf: in my work, the very fact that ARIA is only for a11y makes it harder for me to convince publishers to use that markup ... they want things to describe structural features ... more of this should be part of HTML ... I’d like that only ebooks are born accessible, but the markup is ... I don’t think we should say that if we're adding things they're only for a11y
Tzviya: it's true that ARIA is only used by the a11y tree, but publishers can use it in other ways ... we have to be careful with role and epub:type ... Matt started to write a guide on how to convert epub:type to ARIA roles
dkaplan3: But the publishers would be working against the ARIA spec if they used it in other ways, tzviya.
dkaplan3: Which is related to my biggest W3C soapbox.
tzviya: one of the things that cause confusion is wishes to what should exist in HTML vs what is in ARIA ... almost none will get to HTML ... if we want things to go to HTML, we need to open issues to WICG, on discourse
tzviya: https://discourse.wicg.io/t/proposal-list-head-caption-title/1832
tzviya: for instance what I did for list title and caption title ... few people commented ... if we want to get traction, we need people to comment and contribute ... via the WICG ... explain how we would use them with solid real-world examples, and back them up
avneesh: do we know the timeline for ARIA 2.0?
Tzviya: I will search link for aria roadmap.
mattg: errata is important because some things are obvious errors, like in examples themselves ... we based at some point in ARIA 1.1, and things changed (like dl/dt) ... that's why I want to push on getting the errata done quickly ... otherwise fully agree with Deborah on semantics
tzviya: DPUB-ARIA 2.0 (or 1.1) FPWD is supposed to publish in Q1 2018. We have a little wiggle room
mattg: but even if it's only for AT, there are important holes that can be filled ... even beyond EPUB and its implementation. it's not just for ebooks ... e.g. in poetry there's a disconnect between what a visual reader can get from layout and what's described by AT ... I understand Bill's perspective too, it would be great to have one attribute for everything ... when we came with DPUB ARIA 1.0, it was the impression of some people that we wanted to introduce semantics through the backdoor ... as Tzviya said, not all need to be solved here
clapierre: some of these issues with semantics is also what we've been struggling over in the personalization TF ... some people said that adding semantics to ARIA is missing the boat of adding to HTML ... we have the same issues
laudrain: we are lucky that we decided to have epub:type mandatory in our publications ... it was in the scope of a11y, but now we realize it isn't used for a11y ... now we benefit from it to map to ARIA roles. It makes it easier for our suppliers ... I understand it's difficult to add semantics to HTML. It lacks semantics, it lacks ambition from publishers to move to more HTML semantics ... in the EPUB ecosystem we have epub:type, which use was positive for us
Jason: one of the question is that if you want to add additional semantics, what's the best solution to add to the web techs? ... ARIA is used for AT, but doesn't prevent other people from using it ... one could use ARIA to control visual aspects of the presentation ... the primary use of ARIA is to be used to inform a11y support ... but doesn't mean it can't be extended ... what are the use for additional information? ... extending HTML itself, web components, etc ... not sure what approach is best in which context, but we have solutions available ... I'm not sure what's the appropriate extension mechanism, we have options on the table, the question is what to use? ... one question is the syntax and the format, the other is the semantics themselves
dkaplan3: I was about to make a proposal ... we're all on the same page ... the proposal is to focus on addressing the errata, not focus on adding terms or getting RS to implement what we have ... close all the open issues
clapierre: Ace produces warnings when there's an epub:type and no matching ARIA role ... it will entice publishers to adding them
avneesh: publishing industry may need more semantics, Tzviya and Ivan also talked about having a place for it, may be a task force or CG. From these semantics we can select what is important for accessibility and propose it to aria. but it is longer term work. ... for now, it's a good approach to have an errata and focus more on getting things implemented in reading systems/browsers and AT. ... then lets see how this is received in the industry. If aria remains accessibility specific or industry starts using aria for non-accessibility related use also. ... the parallel thing is the addition(s) to HTML, which is a long way ... there are complexities that we need to talk about. One way was suggested by Ivan, to create web components. The other way is putting pressure through our comments. As Tzviya mentioned. We need to plan the appropriate strategy for HTML elements.
tzviya: I am not suggesting a new CG, just adding to https://discourse.wicg.io/c/dpub
avneesh: maybe focus on HTML strategy in the next call. We should make a plan for all of us to participate in moving proposals for HTML forward.
Topic 2: Silver taskforce design sprint at CSUN. (George will be representing us) Silver research presentation is at: https://docs.google.com/a/google.com/presentation/d/1POs7orJ4ALB0bq5_vyo4v8RxDcr-5ctwD1noVgpXuJc/htmlpresent
Publishing specific requirements for Silver are at: https://github.com/w3c/publ-a11y/wiki/Publishing-issues-for-Silver
avneesh: George is attending the Silver design workshop, what do you need from our group?
[crickets]
Jason: based on a recent update, my understanding is that the Silver TF conducted various research, looking at the use and challenges enocunted in the use of WCAG ... in particular by interviewing various stakeholders ... they intend to publish their results ... they're looking at a redesign ... important process, a publishing standpoint, represents a backward-incompatible shift from WCAG 2.0 ... rethink the fundamentals ... for instance, what EPUB Accessibility says with metadata, not necessarily related to content-level conformance, can be put forward in the considerations of the Silver process
Avneesh: it's a major design meeting ... we had already provided them the link to the publishing requirements ... we have to discuss with George what he needs specifically from us, maybe via email ... Jason, being an insider in WCAG, any suggestion from you?
Jason: the way in which metadata are treated would be one consideration ... can have other use like specialized website, not necessarily achieving general a11y conformance ... that concept could be considered ... some discussion of having more fine-grained technology-specific requirements, but not sure where that discussion is moving forward ... have a core set of principle + more specific guidelines, for instance a publishing-specific module
Topic 3: AOB?
https://github.com/w3c/html-aria/issues/92#issuecomment-364670701
https://github.com/w3c/html-aria/issues/92#issuecomment-364670701
rdeltour: we should spend time to review ARIA in HTML, which will go to CR soon
avneesh: About errata, haven't we decided what goes in?
tzviya: I think we have, some of it was contingent to ARIA 1.1
mattg: errata is rather straightforward
tzviya: wrt HTML semantics, I have a call with Ivan and Garth, I wonder if this is an a11y concern or one for the larger group
avneesh: right
mattg: the errata is really small, could be done quickly. we didn't do it because we wanted to wait on ARIA 1.1
Tzviya: I want to talk to Ivan and Garth first
Topic 4: Time for next call.
Avneesh: Should we decide time for next call. Or should we wait for more developments?
dkaplan3: Is there homework to do. If yes then we should decide.
Avneesh: Not eally. There are just 8 issues for aria errata, and it is mostly figured out. So, lets decide the next call based on the requirement.
Action Items:
- Tzviya: Discuss plan for proposing new HTML elements with Garth and Ivan, It is not only accessibility requirement, but is useful for PWG as a whole.
Original uncleaned minutes are at: https://www.w3.org/2018/03/14-pwg-a11y-minutes.html
Present: Avneesh, dkaplan3, rdeltour, George, Luc, DanielWeck, mattg, tzviya
Chair: Avneesh
Scribe: rdeltour
Topic 1: Update on meeting with Silver TF and APA at TPAC
avneesh: Matt compiled the requirements at https://github.com/w3c/publ-a11y/wiki/Publishing-issues-for-Silver ... the objective is to figure out what's the best way to incorporate these requirements in future versions of WCAG. ... requirements were well accepted ... issue of page numbers was discussed quite deeply
avneesh: Janina said pages are not specific to accessibility, but essential general requirement, it would be helpful in reading on small screens like mobile phones. ... she wants to propose that concept to the HTML WG ... she's ready to go forward with it ... the main difference is that when we talk about screen sizes, it's more about reflowable page numbers ... in publishing, we also need a concept for print page markers along with refloable pages. ... a11y metadata was also discussed in great details ... as we know, it is included in public working draft of WCAG 2.1 ... the architecture of WCAG doesn't allow it to be a success criteria as in EPUB A11y ... Silver TF is happy to work on design that addresses all this There was good support from the COGA TF for accessibility metadata ... and there was also support to have stricter requirements for accessibility metadata in future WCAG ... people also like the approach: even if it isn't conformant to WCAG, we're able to know the a11y features ... the concept of optimized publications was also discussed and acknowledged. ... overall, Silver was thankful for the requirements. ... about the timeline, Silver leads said that they need 1 year to work on the search and design aspect ... George, Matt, Daniel, want to chime in?
George: my feel is we have been successful in integrating ourselves in this WG. we're part of them now. ... confident that we can engage with them on the things important to us ... we can have a meaningful dialog ... I think in relation to publishing, the 2 checking tools (EpubCheck and Ace) are an opportunity for us to emphasize some features and functions deemed important ... it may not be a AA requirement, but if we can emphasize it in the tools we can highlight it without needing it to be a WCAG requirement
Avneesh: a kind of reinforcement through the tools, even if it takes long for Silver ... the COGA TF also asked if metadata requirement work of publishing can be synchronized with their metadata work. ... it's one of the other things to explore
Topic 2: Synchronized multimedia (MO)
Avneesh: MO were presented by Marisa, she explained what it means and concepts of skippability and escapability
Avneesh: https://www.w3.org/WAI/PF/media-a11y-reqs/
Avneesh: APA said they worked on similar reqs a few years ago ... many of these things are on their radar already ... the text/audio sync isn't there though. ... they sync requirements for text/video, audio/video, but not text/audio ... they suggested to look into TTML and WebVTT ... the problem with these technologies is that there the media is the master, but in our case text is the master ... APA also suggested to look at second screen work.
Avneesh: the consensus was that we should be leading a CG where different groups can collaborate ... this topic was also discussed in the Pub WG meeting, where the concept of audio-only books was also discussed ... in EPUB 3, we are doing kind of a hack of Media Overlays for audio books, but would be great to support it better in Web Pub ... also there was some good discussion between Marisa and Benjamin about using Annotations
Avneesh: George, Marisa and Daniel also joined the breakout session on the Media entertainment IG (formerly Web & TV) ... media synchronization can be a major piece there, our requirements were well received
George: Fwd: MPEG container media tracks synchronization George: I put above the subject line from an email they sent me ... they clearly saw the need for sync of text to media ... we talked about movie and screenplay, audio and text book being synchronized ... they're also looking into compression and packaging ... like the PWG ... we didn't bring this up, but they were talking about URL as the origin for Media "publications" (not their terminology) ... they need packaging and a way for the Web to start using these things ... quite a bit of synergy ... I will forward the doc that Daniel sent me
laudrain: I had a discussion with Cyril Concolato at TPAC, who is in this group ... it's a good group to follow ... Cyril is French, working at Netflix
Avneesh: Daniel, anything to add?
Danielweck: I am not on WebEx ... still trying to log in
Avneesh: Till Daniel join, Matt, one question re WCAG 2.1 ... any question re metadata or is it going fine?
mattg: going fine, chugging along
Avneesh: anything on the page number technique you submitted on Github?
mattg: no, they haven't brought up the techniques yet, still working on SC ... so haven't heard anything specific at this time
laudrain: I understand that Silver will be more aware of ebooks as collection of web pages as it is today?
Avneesh: yes, it's integrating everything ... the Silver TF is based on the principle of "Web for everything" ... in WCAG 2.1, we already mentioned web publications as an example of collection of web pages
George: I'm pretty confident that they're aware of collection of pages ... they're having problems right know about e.g. payments spanning 3 pages ... they're aware of this notion, even there ... the MPEG-type work was also the same kind of thing, a product that wasn't just a web page
Avneesh: yes, half of this is already complete, already in definition of webpage if publication is on the web, but it yet does not address the condition in which publication is on local drive.
Topic 3: CG on synchronized multimedia
Avneesh: one way is to start a CG ... Marisa said that there is a possibility that TTML/ WebVTT, or Media Entertainment can get us what we want ... if this is the case, she asked, is it worth creating a CG? ... my thinking was that if these technologies work well, we can just provide a note for the WG
George: Ivan was the one who thought that the CG should be formed to provide a focal point for the development of the use cases and requirements ... and then shopping around for the technologies that may be used ... if we're talking to MPEG people, or TTML, or whatever, we can point to this document from the CG ... I think that was what he thought about ... there might be some overhead, since we might need to integrate with another WG
Avneesh: when we made the decision of the CG, we were not aware that the Media Entertainment may take it as a serious issue
George: is TTML and WebVTT inside ME?
Avneesh: no, ME (Media Entertainment) is an Interest Group ... if these technologies are not applicable, the right way to go is to create a CG ... there's nothing right or wrong, we just need to make a choice
George: we want to bring in audio book publishers into the discussion ... a CG could facilitate that ... I don't know if audio book people would feel comfortable going in the ME IG discussions
Danielweck: there's 2 sides to this ... what Reading System implementers can do with the current tech (Web Platform) ... we can do Media Overlays, probably can use newer tech provided by browsers for WebVTT and TTML to improve our implementations ... when we talked to ME IG, I think that was their perspective too, that the Web already had the tech ... however, from the point of view of content producers, we want to make sure there's a proper declarative syntax (à la SMIL) ... being part of the ME IG, our voice would probably be drowned ... there's a bit of a shift in technical culture, when we talk about books, text/audio and beyond ... with regards to creating a separate CG, to dedicate efforts specifically for our requirements would give us some visibility ... just to complement various bits of info, I think Marisa and me are not convinced that WebVTT / TTML / MPEG-4 as a container, etc, is a way to go for us ... but we'd need to put forward a case "against" these technologies in our own use case ... we need to formalize this to explain how it's not suitable, provide a gap analysis ... we can use Readium 2 as an example ... replacement of SMIL there is just an experiment, a kind of 1-1 translation of SMIL in JSON ... works with audio but not so much with video
tzviya: just wanted to add that aside all the things Daniel just mentioned ... it's possible to redo the charter, but otherwise might be out of scope for the WG ... the point of a CG is to gather more people, not in the W3C ... starting a CG would be a good way to go (and inform people that you do that)
Avneesh: the only question here is whether we should create a CG immediately, or ask Daniel and Marisa to explore the existing technologies further?
tzviya: in my opinion we can start already, it gives visibility. but it also requires some work (meetings)
Avneesh: let's wait for Marisa's opinion, she is not here. ... we can give them a couple weeks, then create the CG
George: I do think that a CG focused on audio books could be very helpful to bringing that community together ... it's very active, a popular media, and no real standard behind it ... I think it could be very useful
Avneesh: ok, let's go for it then ... these publishers may not be in W3C, so a CG would allow them to join ... I'll get in touch with Marisa and Daniel and see when they have the time to start it
George: we shouldn't underestimate the amount of work required ... starting a CG is easy, driving it isn't
Avneesh: if the point is only to investigate the technologies then it's a time-bound CG.
dkaplan3: expanding on that, if a CG is found, it should have a goal on a very specific product ... if the goal is exploration, the WG should know this is coming and expecting this work ... we should have an actionable goal
Avneesh: sure ... Marisa, Dan, and I have an action item to figure out the way to creating a CG. ... questions?
Avneesh: one question for Tzviya: is it OK to post info on Ace releases in the WG list, or is it out of scope?
tzviya: I think it's OK
Avneesh: also, we'll have a FPWD soon, we are not dealing with user side issues, so there is no urgency for the a11y TF to jump in. ... but once it's published, we need to discuss what should be our role for the next set of milestones?
tzviya: my opinion is that until we have more to the Working Draft, this TF doesn't really have a role to the documentation
danielweck: (I've got to move onto another con call, sorry! I think I am not needed in the remainder of this concall)
tzviya: until January, I don't think there's much to do
Avneesh: then next question, when should be our next call? ... do we need one for CG, or wait for early 2018?
tzviya: wait for Daniel and Marisa's input, maybe better to wait until January. Month of December would be having many holidays.
danielweck: okay by me. makes sense
Avneesh: OK, then let's decide on scheduling calls in January. And maybe decide an ad hoc call for CG, if required.
Action Items:
- Marisa, Daniel and Avneesh: Come up the plan for synchronized multimedia (Media Overlays) CG.
Original uncleaned minutes are at: https://www.w3.org/2017/11/22-pwg-a11y-minutes.html
Attendees:
Avneesh, tzviya, dkaplan3, George, mattg, clapierre, Daniel, Bill K, Ben.
Chair Avneesh
Scribe Clapierre
Preparation for joint session with Silver and APA scheduled on November 6 (Monday), 4:30 to 6:00 PM in TPAC.
Topic: Review of accessibility requirements specific to publishing. The objective is to discuss the road map for incorporating these requirements in WCAG.
Avneesh: In TPAC, we have setup combined meetings with Silver task force and APA so that we can determine which issues can be taken up in which groups. .. The first topic in today’s agenda is Silver requirements. We discussed these issues in previous Accessibility TF call, and Matt has created the wiki page on its basis.
https://github.com/w3c/publ-a11y/wiki/Publishing-issues-for-Silver
Avneesh: Looking forward to comments.
Tzviya: we need to be careful about using "EPUB" a11ymetadata support in the EPUB ecosystem as a reason to put this in now. The W3C groups will resonate better wif we do not be too specific to EPUB eco system. We should talk in W3C context and mention that this work is done in schema.org, and is already included in it.
+1 what tzviya said
Avneesh: yes we are not sticking to the old world that we are now in the W3C
Charles: The same thing in URL section, EPUB is mentioned.
Tzviya: Another thing, in the context with URLs may be problematic. We want to have 1 URL for the whole publication, not separate URLs. This is the direction PWG is heading.
Avneesh: If WP/PWP are heading towards single URL then publication on web may already fall under definition of webpage as per WCAG. But it still does not address the concept of publication on local drive. The mobile task force under AG also had similar requirement.
Tzviya: so this is offline requirements.
Bill: we should use just "publications" that they consist of multiple resources multiple pages not focus on epub. ... , Matt does this in #3 actually
George: so the section #2 URL based conformance as being a problem needs to be reworded to be harmonized with the publishing WG single URL that personifies the publication.
<Bill_Kasdorf> +1 to Tzviya's suggestion
Tzviya: suggests reorganize this. We may want to start with modularization and online/offline reading which is where the problems come from. ... , then go into the details.
George: 3rd party content thing, would it be intrinsic to the publication?
Avneesh: The issue of packaged or portable publication makes it complex. If you are on web then 3rd party content pulled in some Iframe is exempted from conformance but what if you package the publication and include the snap short of the 3rd party content in your package? Will the author be responsible for ensuring accessibility of this 3rd party content?
George: you will ref. lots of things that is not part of the publication. Just because there is a link this is not part of the publication.
Tzviya: we don't need to define linking as that is already part of the web. The issue is 3rd party content that is pulled in.
Avneesh: if you have some live feed that is pulled in during the packaging will this have to be accessible? Will the author be responsible for such 3rd party content?
Tzviya: how can I have control over something I don't write.
George: you can choose what 3rd party content you choose to link to.
Avneesh: We do not need to resolve it now, we need to decide if we should have this as a question for the Silver TF?
Deborah: portability if something is external does it come into the package, from a11y if something is external but is intrinsic to the publication that others have dealt with this like security etc. If something is required for key functionality and you don't control it, it needs some schema.org outside resource or a local copy needs to be made / verified or your own a11y metadata that outside resources do not meet your a11y claims.
Avneesh: This means that we should keep this as a question for discussion with Silver TF.
George: What does no.6 mean. It is user interface functionality.
Avneesh: As per my understanding this is related to additional WP specific functionality. If browsers support additional WP/PWP related functionality like navigation natively. And Readium provides support for this functionality at the same time underlying browser also supports this.
Tzviya: this is not accessibility specific issue. This is a PWG with / UX issue. We have already allocated slot for it in TPAC.
George: you must have a good UI so this is really main stream.
Tzviya: Chrome vs. Content. Reading systems that the app I develop that works well with the native gestures for example. Definitely not a WCAG issue.
George: so media overlays is next question.
Avneesh: Support for MO which was never ever covered by WCAG
George: should we just leave it as a place holder.
Avneesh: we should have open discussion with Silver, a 2 way discussion.
George: so an Audio or Sync text/audio book would be a main stream product. I think it should/must be main stream publication.
Avneesh: these kinds of publications is both mainstream and specialized.. If we are talking specifically about audio publications then it does not fall in WCAG because it is accessible for some specific user groups but it does not conform to universal accessibility approach of WCAG. E.g. audio books are accessible for visually impaired and not for hearing impaired. So, audio books are optimized for specific user groups.
Tzviya: to explain what the issue is, the basic audio book, a deaf blind user could not use the controls etc.
Deborah: We can explain it further by doing some user stories, and have a speculative user story for deaf / deafblind if they only had x they would be able to access this.
George: Sync media piece, there is also the issue of audio book which does not have native accessibility features, text can be turned into audio, but audio can not really be turned into text at least at this time,looking at multiple language issues. So either text has to be synchronized or the audio should link to a text transcript. We should bring both issues forward.
Avneesh: yes, we can add sub headings under Media Overlays section.
George: will we get with Matt to make these changes.
Avneesh: Yes we will email/call tomorrow.
Topic: Media overlays discussions at TPAC.
Avneesh: MediaOverlays - Daniel can you copy/paste the requirements.
daniel-weck https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia
Daniel: high level requirements, bottom page have notes design challenges and other groups we should look into. ... , blocks from Open web platform, OWP contains enough of the tools to meet our req. ... , How do we transition from SMILE meets the requirements from previous MO to the future sign language etc. ... , stable for now not a lot of feedback, Marisa and I looking for other groups sync Multimedia group, web VTT title and captioning. Multi-device timing, cloud architecture is just a Note, but what does it mean to have clients/servers ... , we will finalize a draft for our meetings next week. Readium2 has a proposal JSON syntax combined with clip begin/end and text from the OWP fragments work. we haven't yet been able to dig into this, we have some prototypes. ... , desktop reading systems based on Electron and will do some tests on this, we haven't been able to test our theories if this JSON based successor or SMILE, but we will have some things to discuss a TPAC hopefully. ... , we have to figure out who we will need to meet with.
Avneesh: Objective of meeting with Silver and APA is to get their help , Janina could help us in identifying the technologies and groups we should connect with. ... , But for the PWG presentation what is the main objective there?
Daniel: we want to, some may be familiar with EPUB 3 MO, and the function it fulfills, and then identify the technical gap / guideline for creators to use, so we can have an interoperable format. It is possible to create media overlay like content, but we need an easy to implement syntax. It would also prevent people from doing their own stuff which may not be standardized.
Avneesh: We should also have audio books concept in the meeting because it captured good interest in PWG.
Tzviya: we don't need to come up with solutions immediately, but excellent that Daniel and Marisa has started. ... , we hope to accomplish MO into publications and packages publications in a standard manner and audio books would be a part of this. Charter we need to include this. What is not part of the charter is not to create the successor to SMILE ... , remember this is not only the Publishing WG to observe. Chaals, Ralph swick, etc. would be there. We can't call this SMILE2 or anything like that. ... , don't assume everyone knows what you are talking about but audio books need to be part of this. we are trying to recruit people to be part of this work.
George: one of the issues Janina said why is Web VTT and TML what is lacking for synchronized media? when one media is embedded in another media, ... , or linked to a text file. ... , one being text/audio or video, and they are stand alone products in their own right, and how to bring them together via synchronization and may not be embedding them into each other directly.
Avneesh: Marisa and I talked a little about it in ICT session, she said she will be working on the document why TTML / Web VTT cannot meet our needs, or what are the points where these technologies can help us. It should be ready before TPAC.
George: where you have video and video transcripts and if you have a screen play which exists outside of the video, is a good example.
Avneesh: Another topic, Janina requested to have some informal discussions on Music xml. Should we try to have informal discussion with her in TPAC or continue on emails.
Tzviya: this will have to be in email Ivan has responded to her. Topic: Next call
Avneesh: Lets book next call on November 15th The time will be at 15:UTC and 10am Eastern / 7am Pacific / 4 PM Paris.
Thank you and looking forward to TPAC.
Topic: Action Items:
- Mat, George, Avneesh & Refine the wiki page for requirements for Silver.
- Marisa & Daniel: Prepare for Media Overlays meetings.
Original uncleaned minutes are at: http://www.w3.org/2017/11/01-pwg-a11y-minutes.html
Attendees Avneesh, George, BenSchroeter, Fernando, jasonjgw, clapierre, Fernando Regrets
Chair: Avneesh
Scribe: George
Topic 1: Preparation of List of publishing requirements for Silver (WCAG 3.0):
Avneesh: It is tricky because WP/PWP are at the conceptual stage, and it is difficult to provide precise requirements to Silver. But if we get the publishing requirements to them, it will help in influencing the design of Silver at early stage. e.g. The accessibility metadata ended up in optional conformance reporting because of current design of WCAG.
Matt: We need to introduce ourselves, but it is difficult at this time to give specific requirements. Sets of pages is a big issue, but they are aware of these issues already. The accessibility needs to be applied to a web publication as a whole. Publications as aps or as web pages. Perhaps we should establish an open dialog with them .. What do they need from us and what role should we play.
George: Agree to have open dialog, and if we can flag the requirements from our side in advance, it would be good. It may include:
- Set of pages,
- Navigation,
- Aps or web pages,
- Packaged publications?
Avneesh: packaged publications need to be included in Silver, right now definition of webpage includes a publication that is available online, but does not include publication on your local drive. and conformance reporting must be strong in PWG. I think that we should provide high level requirements and then start the open discussion.
Matt: We should also consider the scope. What is the extent of publication accessibility. We don't want to solve other document problems. If there is a way to come up with a scope statement, that would be good e.g. does it include EPUB, kindle etc..
George: do we flag about inaccessible documents inside the publication? WP consists of resources, what if one of the resource is inaccessible.
Avneesh: IF we are talking about an accessible WP, then it must be accessible in its entirety. i.e. everything in it must be accessible. If we see the current definition also, a publication on web falls in definition of web page as per WCAG, and a webpage is accessible if everything in it is accessible.
Ben: I agree, all resources of an accessible publication should be accessible.
Avneesh: One exception to this case is parts of webpage that are in control of 3rd parties e.g. a website is fully accessible but it displays a 3rd party webpage in IFrames. WCAG provides an exception in such a case.
George: there must be a way to flag external resources that are not accessible.
Avneesh: I think that resource in the scope of WP will be defined by manifest.
Matt: accessibilitySummary must alert to known problems.
Jason: it is difficult to make claims about external resources. But, if you incorporate and package it up, then they are part of your content and would fall under accessibility of your publication.
George: What about media overlays, APA asked for why cannot TTML and WebVT is not sufficient.
Matt: It is not specified yet. For incorporation in Silver, the technologies would need to be there. This is the domain of APA to get standards updated.
Jason: improvements to TTML is an APA domain item. Conformance is the domain of AG. And publishing is not the only area where the conformance is an issue, it is important for others also
Avneesh: Regarding Media Overlays, does it effect the design of Silver? If yes then then we should inform them about the concept.
George: I think that we should try to setup a joint session with Silver task force and APA.
Avneesh: Sure.
Next Steps
- We will have a wiki page for listing high level requirements.
- We will get into open discussion with Silver task force and APA at TPAC.
- George will propose joint session with Silver TF and APA at TPAC.
Topic 2: Issue # 78: Audio books and WP. It is an interesting topic from accessibility perspective, therefore bringing it to the notice of the task force https://github.com/w3c/wpub/issues/78
Avneesh: This is an opportunity for bringing main stream audio book production and audio books produced by libraries for the blind closer to each other.
George: I am collecting a list of contacts in the audio book industry that are also part of W3C. I envision audio people having difficulty participating in W3C.
Avneesh: I think that the priority right now is first public draft. But we should contact audio book publishers and try to form a group. We may propose this topic on Monday's main group call at the right time.
Topic 3: Next call:
November 1, 2017. Time: 14:00 UTC
Action Items:
- Matt: Start creating wiki page for listing high level accessibility requirements for publishing.
- George: In chairs call, propose joint session with Silver TF and APA at TPAC.
Original uncleaned minutes are at: http://www.w3.org/2017/10/11-pwg-a11y-minutes.html
Attendees Avneesh, Tzviya, George, Bill_Kasdorf, Luc, dkaplan3, BenSchroeter, Daniel_Weck, jasonjgw, clapier
Chair: Avneesh Scribe: George
Topic 1: Navigation: https://github.com/w3c/publ-a11y/wiki/Description-of-Accessibility-Requirements-for-WP Navigation requirements is the first topic The wiki page explains the requirements from user point of view, these are requirements from high level, without getting into details of browsers or reading system implementation. And this wiki also clarifies the default reading order and navigation. On issue tracker I observed that some people were confused about it.
So, question for Tzviya, what is required for first draft? If we point to these requirements and provide the candidate approaches, is it fine?
Tzviya, I think that we need to do nothing in first draft. We can just put a placeholder for first draft and it is fine to point to the wiki. Alternatively we can open an issue or point to an existing. It is too soon to get into this level of detail. We should wait.
Avneesh: Looks good. We can have an issue pointing to the requirements page, so that it is in records. The next item was about various options for achieving navigation. Should we skip it also?
Tzviya: Yes, we should wait.
Rdeltour +1 on waiting
The group agrees that we should wait rather than go into detail.
Action item is to create an issue in the tracker and point to the issue tracker to keep a place holder.
Topic 2: CSUN presentations:
George: presentations need to be in by 3rd October. I have not seen an extension yet. Rachel has sent us a proposal that we could do on Publishing @W3C. Judy has not responded yet, but we have Call with her later today. CSUN presentation is on agenda.
In the main presentation, we are talking about overview of publishing at W3C including merger of IDPF and W3C. It is more focused on EPUB because WP/PWP is future thing. We will recommend that this session be given early in the conference, to provide base for other sessions.
Other sessions may be on reading systems (epubtest.org) and we may see individual companies like Dolphin and VitalSource present.
VitalSource might present on ecosystem.
Also theme of conformance and DAISY ACE accessibility checker, which will be released by that time.
Benetech will likely present on accessibility certification.
We need a presentation for DSS offices to become advocate for EPUB instead of getting afraid of it. DSS offices should encourage EPUB and become familiar with reading systems that support it.
But, we have short window to put this stuff together.
Avneesh: the publishing at W3C is the first session that sets the stage. The sub group that is working on it includes George, myself, Rick Johnson, Rachel, Amy S, Bill K, Fernando. We will put together the draft and it will be sent to task force for feedback.
Topic 3: Any accessibility related topic to propose for TPAC?
Avneesh: We have proposed 1 session with Accessibility Guidelines WG for the road map ahead. One requirement regarding accessibility metadata could get in WCAG 2.1 as optional requirement. There are more requirements and we need to talk about the road map for getting these requirements in Silver or WCAG 2.2 if it happens.
What about discussion on synchronized multimedia? The primary purpose of bringing up the topic is to gain interest of other groups who may be working on it.
George: What group do we go to for that?
Avneesh: Ivan suggested animations.
Romain: It is good to borrow brains. The difficult part is who to engage with.
Avneesh: On Wednesday there are short sessions for new concepts, is it a good way to raise interest?
Romain: Yes, it can generate interest.
George: What about TV? IP TV.
Avneesh: Is there a group in W3C which is working on this topic? May be we can ask Ivan.
Summary: Concept sessions may be a good way and we should connect with Ivan to explore groups like IP TV and finding out the right approach.
Daniel: the technology we envision for synchronized media is probably going to enable audio books.
Avneesh: There were questions about metadata for the chapters of audio books, on the mailing list. It is not specifically about chapters, metadata may be required to describe any part of a book, it may be a section, paragraph or some other part.
Deborah: step from the word chapter. All publications have two types of segmentation. There are files and there parts of the publication. All publications are subject to segmentation. This is different from the files.
clapierre +1 to Deborah's comments
The metadata describes the logical parts of a publication.
Avneesh: Daniel, it looks that we should list it as a requirement in the sync multimedia requirements wiki, and later on we can figure out if it is to be done by Synchronized multimedia group, or by metadata group, or maybe we do not have to do it and it may come from web.
Daniel: Yes, I am happy to go back to requirements page and add this to it.
Topic 4: Next call.
October 11 (Wednesday), 14 UTC.
Avneesh: We should keep this date in calendar for now. Lets see how many issues we need to resolve till then.
Action Items:
- Avneesh: create an issue in the tracker so that navigation section of first draft can point to the issue tracker.
- Avneesh: Connect with Ivan to explore groups like IP TV and finding out the right approach to raise interest for synchronized multimedia.
Original uncleaned minutes are at: http://www.w3.org/2017/09/27-pwg-a11y-minutes.html
Attendees Present Avneesh, Debra, Rachel_, Bill_Kasdorf, rdeltour, clapierre, Judy, George, mattg, jasonjgw, DanielWeck, BenSchroeter
Chair Avneesh
Scribe clapierre
Topic 1: Possibility of presentation in CSUN for accessibility in publishing at W3C.
avneesh: CSUN is coming up in March, and we may want to have a presentation for accessibility in publishing @ W3C
George: Judy with WAI has been very public at CSUN in the past and so had DAISY. ... , landscape has changed now and what should be the combined approach now that the IDPF/w3c had joined
Judy: I haven't seen the call for papers yet
http://www.csun.edu/cod/general-call-papers
Judy: , It opens on Sept 14, and closes on Oct 3rd. calls for papers ... , they are trying to shift the focus of the conference but everyone may ignore that ... , DAISY has had their own track, we haven't done that with WAI. ... , Web accessibility related tracks, and we can try to have something more planned, and open for ideas
Rachel: to me it seems challenges from publishers is convincing DSS offices that they want EPUB not PDF. ... , so maybe we need to focus on why EPUB is valuable and accessible EPUB can meet their needs, and why they should be asking for it.
Avneesh: Are publishers in the audience there?
Rachel: I see Universities mostly during my presentations.
Avneesh: Ok, it is the market.
George: I agree that the audience is higher ed, and barrier for epub is that DSS offices don't know how to use it, if they need to modify something to enhance it which they are used to with chop/scan or with PDF and we have something new so they are rejecting it, so this is why they are not encouraging students to use it.
Avneesh: George, I think you are talking about accessible epub and not EPUB in general?
George: Yes, accessible EPUB. There are a lot of turnover with DSS offices. ... , not sure what approach to take. Other issue, is we want to see customers of epub demanding accessible EPUB, but if DSS offices are not supporting it we have 2 barriers. ... another issue is how EPUB and other publications are integrated with learning management systems (LMS) and accessibility of that content and interfaces ... , you still have the issues of getting the content into those systems.
Avneesh: this is good for existing EPUB but what about the future of publishing with PWP/WP. Do we need to publicize anything about it?
Charles: may be too early to talk about PWP / WP at this point
Bill K: I think the emphasis should be to do this now, lets not give them the excuse to wait for WP / PWP. we should just use EPUB no # with it ... , This is the format that is the first class citizen of the web and is accessibility and should be pushed as such. ... , we want you to be certified accessibility
Rachel: giving them a simple understanding of what they should be looking for … something like a checklist
Charles: BISG is going to be making such a checklist
Bill K: if you are interested in this work, that you can contact Robin at Benetech that will be expanding the QuickStart guide and making this checklist. ... , we will update that Quickstart to have split it in two, to have a quickstart checklist and an accompanying accessibility guide. the plan is to have this work done by November, but the full guide may be ready for CSUN but that is still yet to be determined.
<Rachel_> +1 dkaplan3
Debra: about encouraging EPUB, 100% encouraging EPUB for accessibility epub, PDF if we are lucky from accessibility that teachers get these from licensed databases. When we talk about accessibility EPUB as a preferred format, but we need to talk about this from academia.
George: these DSS offices are in the trenches and they have to make it accessible to the students, and until MS Word supports EPUB natively unless there is a tool that integrates with MS Word, and Word is going to add even more accessibility features.
True, there's a difference between the different ways documents are produced: what faculty produce, what DSS offices produce, what come from licensed databases, what students can read.
(Also, a nice selling point for epub over PDF to non-disabled end users is that epub reflows easily on mobile!)
Judy: Deborah raised is a good point, and EPUB now in W3C, and if you ask majority of team members, what format people should use, the default would be HTML and other things and in some situations where EPUB would be the right thing to recommend. I would love to have talking points to that fact. Good to hear to have this discussion prior to call for papers, and I will be happy to help a coordinated approach to having a presentation.
Bill K: In EPUB, Content documents are xhtml, and metadata for accessibility, and to Deborah's point, DSS don't get EPUB, but they probably do know HTML and they probably do know but are unaware of the similarities and could possibly get the data in a format they know and get into a LMS system.
George: Benetech will also be there. ... , maybe we need to figure out an approach to make stuff for your students but getting acquisition of content you want great HTML and great EPUB.
Bill K: they should not have to make the epubs but only get the EPUBs.
Avneesh: I think that we have good points. Lets continue the discussion on emails. The consensus is that we should be having presentation for raising awareness about accessible EPUB, with backing of W3C, and we don't want to go into WP/PWP at this point of time, because these are in conceptual stages, and audience may ignore futuristic things. George, would you like to take a lead on this presentation, and invite people in a sub group that will be working on it?
George: should we have this with a smaller group or larger group. ... I will identify the core group and send out the invitation so not everyone will get the emails
Avneesh: We should do preparation in smaller group. We can start from George, Judie, Bill K, Rachael, Debra, Charles and myself. If anyone else want to join, please email George.
Avneesh: There is another presentation forwarded by Bill M. It is for Book Business webinar on September 26, 12pm ET, Objective is book & journal publishers can ensure that their digital content — ebooks, websites, online courses — are accessible to all types of readers. It is better if the presenter is oriented towards North-American-market-and is non-educational publisher. they already have Mc Graw and Pearson in the panel, and they need another presenter.
If anyone is interested then please send email to Bill M.
topic 2: Discussion & decision: Updated Navigation requirements. https://github.com/w3c/publ-accessibility/wiki/Description-of-Accessibility-Requirements-for-WP
scribe: , are we ready to take this to the main group?
Romain: there are a few things that could be improved: the Requirements are talking about accessibility to readers or be machine readable. Being machine Readable may make it accessibility to user agents ... , accessible to readers and machine readable may be somewhat the same
George: when you say the phrasing like that, I agree could make things confusing, so we should tighten that up before bringing it to the main group.
Romain: Yes I am trying to be proactive in this. We should not bikeshed on some of these issues are best to sort out with a smaller group. ... , next comment: about essential navigation says :The navigation to sections/headings in right hierarchical order is essential. The information about hierarchy of sections must be preserved in WP and must be machine readable and accessible to the readers. ... , we have an understanding for a single HTML document but it is not even defined in Web document, but what is meant by hierarchy of sections. req. is to define what that is for Web Publication.
Avneesh: Here the hierarchy is across the files in the publication.
Romain: First thing would be to define this.
Jason: distinction higher level and lower level navigation, that is defined in the file/resource boundaries within the publication, but define it in terms of accessibility. approach to treat each file/resource as its own document where the reading system provides navigation between these files toc/prev/next. other option to load the entire publication into the DOM as a single page, and use the built in technology of the browser for navigation. Navigate this way so there can be a TOC and Headings which could still be used to navigate within the entire document.
scribe: , second comment: brief description what can be done with a publication can be qualified what can be done visually is only what can be seen at a particular time ie. zoomed in etc. difference between those who can see the entire page vs. those who use enlargement and can only see a portion of the page.
Matt: the word "Preserve" this may be a content issue not TOC issue. ... , WP needs to express the hierarchy of the presentation ... , this is just for clarity perspective
Avneesh: expressing it to the user is better way. Preserve goes into storage etc.
George: Jason, loading all documents into the DOM which would provide a natural process, but we want to achieve the same results but may be impractical to load them all together.
Jason: my concern was not to recommend this but the way in which the draft seems to discourage this implementation option, but would rather see that the document could be loaded all together, but didn't want to recommend one way or the other
Romain: not only to express the hierarchy to the user, concat of all pages, but how the UA treats the content, but as a group maybe we want to add to the browsers JS API to load other pages when you are on a page within a document being part of a larger group.
Avneesh: we don't want to get into specifics at this point. Many things in WP are not decided, even the terms are not finalized. So we should remain at higher level, conceptual level and focus on expectations from users point of view.
George: I think this concept of an entire view of the publication is not just an accessibility issue, but is needed for everyone but is essential for accessibility.
Avneesh: Romain I think you had more comments. We are near the end of call, so we can discuss on email, or may be book a Skype call.
Romain: ok. Which ever way you prefer.
Topic 3. Discussion & Decision: Synchronized multimedia proposal is ready to go to main group? https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia
Avneesh: Marrisa and Daniel wrote this document, was there any feedback.
Daniel: no feedback, an nothing yet from Marrisa.
Avneesh: I will ask Marrisa if there is any feedback and then will talk to Tzviya to see what are the next steps.
- Next call. Avneesh: next call will be in 2 weeks. ... , if we need to take up any issue meanwhile, we can discuss on emails and Github.
George: And Call for CSUN Papers will be out next week.
Action Items:
George: Take lead on presentation for CSUN.
Avneesh: Incorporate the suggestions in the navigation wiki.
Avneesh: Discuss the next steps for synchronized multimedia requirements withWG chairs.
The uncleaned original minutes are at: http://www.w3.org/2017/09/06-pwg-a11y-minutes.html
Attendees Present Avneesh, Luc, George, Bill_Kasdorf, DanielWeck, pkra, Charles_LaPierre, jasonjgw, tzviya Regrets
Chair Avneesh
Scribe clapierre
Topic 1: Update: Accessibility metadata proposal sailed through WCAG 2.1 call for Consensus. Avneesh: We proposed Accessibility metadata in optional conformance claim in WCAG 2.1, and last week there was a con-call in which it passed through. The only comment we heard was that coga metadata is AAA, while publishing metadata is in optional conformance claim, so understanding metadata section should explain it. All other comments were positive. So, now we have to polish it, for candidate recommendation, so that it can go into WCAG 2.1.
George: so its optional in metadata is it under AAA?
Avneesh: it doesn't have A / AA / AAA rating, its not a success criteria. it is optional conformance. This is because conformance claim is optional in WCAG 2.0, so, it went into the same structure.
George: metadata does not contribute to the a11y of the page, it helps with discovery. ... Does not help to consume the webpage.
Avneesh: it could either go as AAA or as optional conformance. Andrew suggested optional conformance because most of the AAA is ignored. But if it remains in the conformance metadata then it can be enforced by agencies. e.g. university can mandate that they need AA + conformance metadata. ... Also, there was resistance as a SC. The argument was that it does not add to accessibility, instead it tells that the content is accessible. So we think this is our best option to get this into WCAG 2.1, when August 22 deadline is so close.
luc: discovery metadata, we use discovery ONIX to distribution channels and there is a good a11y list in ONIX. I had discussions with Avneesh and Graham, and it looks to me it is not easy to sync information between metadata inside the publication and onix metadata, and I don't know where we are on this, and what this means in WCAG 2.1.
Avneesh: 2.1 does not go into such details, it recommends metadata like schema.org, double core etc., but WCAG is at the abstract level. The sync between the ONIX and schema.org accessibility metadata should be in the community group, it is more related to the EPUB 3 and EPUB accessibility specifications.
Jason: EPUB accessibility specifications innovates in area of discovery requirements. distinct from conformance requirements to be met in publications that don't meet accessibility requirements. It is inappropriate that web developers make an a11y claim in machine readable form, but we may consider the epub approach in WCAG guidelines how the reporting requirements and discoverability are reported.
Avneesh: Yes, we should have this in silver technically.
Bill: ONIX issue is really important. in other direction, I recall updating onix codelist to exactly align with schema.org and w3c and not sure where that went? would this be useful the way the metadata is expressed is the same in ONIX, Schema, or embedded in a publication. is there any potential on EDItEUR side?
Luc: ONIX is very important for us in publications. Schema.org metadata is inserted in files, but it should be known to the public which is why we need ONIX. I am not aware / comfortable that ONIX has been aligned with this information with the epub inside, but I think I will touch base with Graham on his side ONIX this sync is OK, he doesn't see that he has to do on his side, I think this should be re-touched, I will try to talk to Graham.
Bill: I know he has done a lot on ONIX / schema.org. and all that existing ONIX out there.
Luc: we should raise this in the CG Right?
Avneesh: Yes
Luc: I will mail to Dave C.
Topic 2: Discussion: Navigation requirements described at the wiki page.
https://github.com/w3c/publ-a11y/wiki/Description-of-Accessibility-Requirements-for-WP
There were many interesting questions raised on issue tracker, the document answers many of the questions. Lets discuss it further.
George: did you add that paragraph to wiki?
Avneesh: Yes it is in introduction.
George: Many of working group people may not be aware of accessibility details, so the idea is that Reading order is important the correct reading order in an article / section is important / consistent. e.g: caution in the side bar is a good example.
Bill: wiki pros are good to have. I think that there is some confusion on traditional coding/tagging when people think of navigation they think of a navdoc. but once you are in a document it is HTML markup. Just working with HTML structural semantics, with the EPUB accessibility spec it just states it must use the HTML semantics correctly. ... , typically in an HTML the aside would come before the paragraph so that should be covered, but what we don't have is navigation between documents.
Avneesh: Yes, navigation between multiple files is the main issue. Should we specify more clearly in the wiki?
Bill: we need to spell it out. ... , I have see EPUBS with everything as a div and there were no sections, this was a major publisher, so we need to really spell it out what it means to have good semantic structure.
George: many of us are thinking HTML but there are others thinking about SVG, etc… ... , that does not have inherently have good structure.
Avneesh: Good points. The wiki should more clearly state about navigation across multiple files.
Next topic is issue #39
https://github.com/w3c/wpub/issues/39 Issue #39
avneesh: I believe that the wiki page and the comments answer this issue #39 Avneesh: , do all the documents in the reading order must be accessed from the TOC
George: conclusion there was that they do not.
avneesh: And the wiki states that if there is default reading order then there is no need that TOC must point to all the resources.
George: long chapter broken up into 3 pieces, and the next two pieces may not be referenced in the TOC Only the initial page would be referenced.
Jason: standard practice, do people want something outside the TOC not from the author, reading system could scan for them for every page etc. Just trying to know what the expectation and what the requirements are. Those things are normal
Luc: we have some comments in the issues, that even for simple publication that this should be optional or unique concept, TOC to default reading order, manifest etc. as we describe the goals of these, the wiki clarifies that these 2 are different items.
George: end of part of a publication I am at the end of the DOM, and I want to go to the next chunk, and in Vital Source Bookshelf it is CTRL + PD, I think that functionality is important, I don't want to have to go back to the TOC and remember where I am and go to the next element.
Avneesh: yes this is important.
Avneesh: next is issue #40
https://github.com/w3c/wpub/issues/40
Avneesh: are we happy with this conclusion? ... , what is the relationship WCAG multiple pages and WP? reply was that multiple pages doesn't represent WP fully but this is the nearest thing in WCAG which maps. but as we move to silver we will add more requirements.
Tzviya: that issue and others I raised were not needed to resolve now, but we would just add these different sections ... , we should add a "relationship to WCAG" this is why I raised this issue to have this as a placeholder. ... , if we add accessibility requirements beyond WCAG this is where we would raise this.
Avneesh: Sure, if we need to have accessibility requirements more than that covered by WCAG, we will work on an accessibility document.
Avneesh: next is issue #36.
https://github.com/w3c/wpub/issues/36 is TOC sufficient for default Reading Order?
Avneesh: This is also covered by the wiki page. If TOC need to provide the reading order, then the TOC must point to all primary resources. else we should have default reading order and a separate concept of TOC which may not point to all primary resources.
Tzviya: we should let the WG know about this wiki page
Topic 3: Synchronized Multi media
https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia
Daniel: Marisa wrote this document which we will review now ... , DAISY books / EPUB 3 media overlays ... , describe why this is useful to a broader audience and the a11y needs. ... , highlight why TTS is sometimes not sufficient and there is value to Human narration, and that it can be structured navigable and cam be synchronised with text. ... , essential requirements: 3 usecases - text with pre-recorded audio narration. ... , 2nd - pre-recorded audio but no text ... , audio only books, epub 3 MO is always sync with a html doc with/without text but only structure. ... , 3rd video with text transcript. video rendered on the page and the text… ... , we haven't decided on how we will do this ... , advance Requirements - didn't make it into 3.1 MO, support for multiple granularities, sync between audio / text (word, sentence, paragraph) we could have different granularities. ... , 2nd adv. req: sign language video ... , 3rd video with descriptive audio ... , we have a list of references of existing standards or standards to be, video captioning TTML v2. SMIL 3, in Readium, media fragment URIs for start/stop fragments of audio. ... , these are exploring a11y benefits and high level use cases at this stage.
George: text / audio sync we can provide a great publication. we have a screen play and the movie of that screen play do we envision that there is a sync between the screen play and the movie, next act next scene,
Avneesh: we are focused on a11y then this can go to the WG for broader discussion.
Tzviya: we should bring this to the large group. good that you have the requirements. how should we proceed since SMIL is a w3c. is this part of the WP but if this is a piece of WP then we need to figure out how to proceed and bring to large group.
Daniel: George's comment about video/screenplay, structure between back and forth, this would be video / text transcript, text transcript is the a11y, but could be useful in other scenarios, for Tzviya's question, we will decide if this is specific to WP, or web at large, but previous attempts to define this on the web has failed. ... , now publishing industry can push this more aggressively, we must use the Open Web platform: readiums own implementation is all using W3C standards. ... , the sync between audio/text that is where SMILE comes in. we must decide if we want to promote SMIL or depart from this, ... , this has yet not be explored fully, I don't want to miss-represent Marisa's views. ... , we can wait until she is able to discuss this herself.
avneesh: do we want to bring this up to the main group on monday?
George: much like HTML structure good HTML provides great a11y, not much else to add. so depending on multimedia audio, video, screen plays in WP will determine what a11y needs.
avneesh: how should we move this forward, it requires many working groups coordination to work on, not only publishing WG. Tzviya: I have a call with Garth / Ivan next but not sure this will make it in the agenda, but this may not be urgent to bring up yet.
Avneesh: So, lets give feedback to Daniel, Marisa.. And George as you point out that if done correctly there may be less accessibility requirements.
Topic 4: Next call?
Avneesh: If there is nothing pressing, then we can skip next Wednesday. ... , so no call next week, Till then we will work on: ... , Clarifications in navigation document, give feedback on synchronized multimedia to Daniel and Marisa. And keep eye on issue tracker, we need to respond for accessibility needs.
The original uncleaned minutes are: http://www.w3.org/2017/08/23-pwg-a11y-minutes.html
Present: Avneesh, George, Leonard, laudrain, Deborah_Kaplan, rdeltour, tzviya, mattg, Bill_Kasdorf, jasonjgw, DanielWeck, DanielWeck_ Regrets:
Chair: Avneesh Scribe: George
Topic: Proposal for accessibility metadata is now in WCAG 2.1 survey.
https://www.w3.org/2002/09/wbs/35422/Final_prelockdown_set/
Avneesh: As per current status 8 people responded to the accessibility metadata survey and till now there is no objection. Anybody on WCAG can respond.
George: Has jason changed his objection. Avneesh, it is a new proposal and he has not objected. As per discussion with Jason, he looked good with it. If there are members of this task force who are also on AG WG, please respond to the survey and help in getting it through.
Topic: Navigation There is Extensive discussion on github. I have provided links to relevant issues. Tzviya also provided a link to WICG, there is nav element in HTML and the group is discussing to use it in a way similar to Navigation Document.
Romain: There are 2 issues. One is if navigation is in minimum viable manifest (MVM) The second is how it can be done. By Nav Doc etc.
Leonard: Agree on separation of issues.
Debra: distinction of MVM and WP.. my take is MVM is not the same as a min WP.
Tzviya: https://github.com/w3c/wpub/issues/22#issuecomment-321218784
Tzviya: echo Debra, adding one the work is to get to a first public draft. We know we will have open issues, but we must have a draft in October. for a
Zakim: tzviya, you wanted to point out that many issues need not be addressed before FPWD
Avneesh: Navigation is essential for WP but at this time we do not have clarity if it should be in manifest or outside.
Leonard: I would like to know, what does it mean that nav is not in the manifest. Navigation is provided by author or we think that there should navigation other than that.
Avneesh: I pointed towards Two sections in WCAG, one is 2.4.5 which talks about more than one way to navigate to content, in multiple web pages. the other is 2.4.7, which talks about ability to inform user about his/her reading position in multiple web pages. Coming to specific question about author defined navigation. I would say that author should be able to provide navigation for convenience, for example list of pages, links to notes etc. it is for convenience so it can be optional. But the essential navigation comes from the structure of the publication. It is the hierarchy of the publication.
Debra: IS the MVM we are trying to define it https://w3c.github.io/wpub/#terminology
Romain: I have similar concern. Abstract versus concrete. We must be clear. ... Another question is about strategy; there specifications, guidelines, and we need to determine what is our strategy. ... Do we want to follow the web approach
Matt: Addressing the confusion. When we don't have a set of features it is difficult.. the accessibility may be shifted down to the content document. Hard to define what is required is it critical. We need more clarity to answer questions.
<DanielWeck_> (rejoined after crash)
tzviya, you wanted to ask what you need clarified in Monday's meeting
Tzviya: I hear a lot of confusion. Starting with manifest is perhaps the wrong approach.
Debra: We don't understand what a manifest is.
Romain:+1 to tzviya
Tzviya: What I am hearing is that we need clarity of the function of a MVM.
Debra: the def...is it all or a subset?
Jason: a TOC is normally provided by an author, but if not provided, can a reading system provide a synthesised nav approach. it could be two different items. Content through a TOC, or the UA providing a nav approach. Those two items are distinct.
Matt: Without a feature set, it is difficult define a MVM.
Debra: The best thing for us to do is identify the functional requirements ... we can bring issues of navigation to the larger group.
Avneesh: Perhaps a wiki can explain requirement of navigation for accessibility and we can point main group to it, but tzviya suggests it may be in discourse.
Leonard: I know you may want to screw me. We want to make sure that authors have what they need, but we do not want to mandate that a WP is accessible. Not mandatory, but facilitate accessibility.
Debra: Our goal should be to put forward the requirements. If the larger group would determine if accessibility is a must. It is not good use of the task force time to say that accessible is not required.
Leonard:@dkaplan3 - that's a reasonable point about the group's responsibilities. The only reason that I raised it is that with respect to a "minimal viable manifest", I don't see things related to a11y as part of that.
Matt: Our objective is to make sure pubs can be accessible, but we cannot mandate that
Avneesh: Nothing in WP specs should make publications inaccessible. This is the objective. The task force need to work with main group to meet requirements of existing WCAG and the additional publishing specific accessibility requirements.
Summary we should have a wiki page on navigation so that we can point the main group to it and it act as reference for specs development and discussions.
Debra: Meanwhile I have opened a new issue. https://github.com/w3c/wpub/issues/24
https://discourse.wicg.io/t/nav-type-attribute-proposal/2241/18 navType is a proposal.there is a discussion about using ARIA or new navtypes. It is worth reading. the more number of people comment the better it is.
Avneesh: we should participate in the discussions.
Topic Title https://github.com/w3c/wpub/issues/20
Debra: Issue 24 is a fork of title in manifest, but what are the requirements for a title in a WP, if it is needed at all.
https://github.com/w3c/wpub/issues/24
Debra: I believe a title should be in the WP.
Avneesh: from accessibility perspective a title must be there for publication, but not sure that it should be in manifest specifically.
Leonard: I would like feedback. How is the title used from an accessibility context. How is the title is expected to be used.
Tzviya: there are items from WCAG that address this. Leonard: thnks!
regardless of where the title is declared, is it a minimum accessibility requirement that the language of the title be defined?
Avneesh: title is important for discovery. It is also important for robustness. WCAG talks about it in section 2.4.2, WCAG 2.0 largely works with a single file model. We are helping to expand this to multiple documents. A title is very important for this.
Debra:The EPUB Accessibility doc addresses why an entire publication needs a single title: https://github.com/w3c/wpub/issues/20#issuecomment-320743037
Matt: If you create something, it should have a name. It is useful, but for accessibility we cannot answer that yet. It could be in the MVM or in the content.
Debra:+1 avneesh
laudrain: +1
Summary, the A11y wants to see a title in WP, but we don't have a recommendation at this time if it is in the MVM or the first primary resource.
Topic: Default reading order: Matt: this is the choose your own adventure.. there must be some order required, but it is dependent on the type of document.
Bill K: We are talking about publications and not books. What is the proper reading order for a magazine for example. I think that if manifest has first primary resource and from there on, there is navigation, it should be ok.
Daniel: Non liniar or auxiliary'. Requiring items in the spine has caused problems. ... in Readium 2, there are a sequence of primary docs. Anything outside the spine is an Auxiliary. ... Based on what I have seen primary docs are needed and secondary support the primary, e.g. CSS. auxiliary can also be primary.
Tzviya: much action on GitHub today about secondart resources https://github.com/w3c/wpub/issues/23
Debra: My problem with default reading order is we know primary documents are identified and the user must be able to find those primary. Navigation to get to those documents is sufficient. A reding order is not needed.
Debra: What is vital to accessibility in this topic?
Avneesh: I think that If everything is not listed in default reading order, but there is proper navigation, then it is good for accessibility. But the specs have to evolve more before we can take a position.
Tzviya: the conversation is ongoing. If you have questions or confusion regarding terms, please raise them on the mailing list.
Matt: let's get away from non-linear.
Topic: Next Call We will skip next week and allow WP spec to evolve a little. We will meet again on August 23, at 14 UTC. Meanwhile we should follow Github issues and provide comments, and will work on wiki for navigation.
The original uncleaned minutes are at: https://www.w3.org/2017/08/09-pwg-a11y-minutes.html
Present laudrain, mattg, Avneesh, clapierre, rdeltour, Bill_Kasdorf, tzviya, dkaplan3, BenSchroeter, George Chair: Avneesh Scribe: Romain
Topic 1: WCAG 2.1 status Matt: in a nutshell, the metadata issue hasn't come up on the WG's radar mattg: Andrew and Joshua are on vacation. it could come up next week https://github.com/w3c/wcag21/pull/308
mattg: the other issue is about reading order. lots of debate on the tracker ... about whether it's general UX or specific to a11y ... it w/b useful for people to take a look at that ... other proposals, being able to bypass repeated blocks in documents ... does it fall under multiple ways? or a new SC? ... it's definitely useful for people to look at it and chime in https://github.com/w3c/wcag21/pull/313
jason: it hasn't been established that content that would comply to WCAG 2.1 would fail to comply to this criteria ... the WG has to make decisions on a large number of proposals before the end of this month ... everything that hasn't a very strong rationale wouldn't be in 2.1
George: did David suggested that we actively comment in what we're proposing in order to raise the level of its presence in the group?
Avneesh: yes
jason: the WG would have to make difficult priority decisions, a lot of proposals won't make it in any form ... only a few proposal are possible in a 3 weeks timeframe ... it takes some time to go through each proposal and get them address
Avneesh: what's the opinion about the metadata proposal?
jason: some interesting discussion ... I proposed that if people want to strengthen that section, they would enhance the provision within WCAG
tzviya: I think the job of this group is not to decide what's a priority for WCAG, but what's a priority for our group ... it might sounds obnoxious, but not our problem if they have difficulties to discuss everything ... we can work with them to adjust the priorities ... there's lot of stuff that people want to put in 2.1, but these are our priorities ... we know it might get cut, but it's their problem
Avneesh: the question is if there's some anything we can do to help in getting it in?
George: we have to be there, to make sure that our proposal is still in line, and answer any questions.
mattg: the metadata proposal is still there ... the other one was more a proposed clarification to the Understanding document, but might be pushed as an SC ... if we want to push it as an SC, we need to clarify it ... maybe that's something we need to take offline again, and discuss how much of a priority it is (it = the "reading order" proposal)
Avneesh: about the metadata, if it can get it in 2.1 it's fine ... about the "reading order" issue, I don't think it makes a lot of difference
+1
mattg: is it a big enough problem and priority for 2.1?
+1 to metadata in 2.1
mattg: metadata is in a better shape for people to discuss it when brought up to the chairs
tzviya: might be a good idea to send an email to Andrew or Josh ... as far as reading order and packaged concept, WCAG Chairs stated that it's rather fragile and being stretched
tzviya, you wanted to suggest sending an email with priorities
tzviya: not sure we can push for it at this point ... but we can clarify things about what we need, what we want
mattg: I've been told trying to change that in 2.1 is too big a change
dkaplan: there's only so much 2nd guessing we can do ... we can say what are what our priorities, they'll tell us what we can do to help
jason: there's some outstanding issue about metadata ... it doesn't actually improve a11y ... there's view in WCAG that requiring somebody to declare sth about the content raises some objection on the basis of legal requirements ... it WCAG 2.0 they were concerned about organizations having difficulties to be required to declare sth
shouldn't this discussion happen on a WCAG call?
jason: I don't know how much an issue it is now
mattg: there's a new proposal we've been making ... just proposing adjustment to what's in conformance ... statements on the a11y + additional prose ... it's not the original proposal, we came up with a less contentious proposal for 2.1
Avneesh: we did this following your comment Jason, maybe you can go through the new proposal and help us getting it through?
https://github.com/w3c/wcag21/pull/308
jason: they'll have to bring it to the chairs, discuss the conformance language, then go through a call for consensus ... I've not seen the proposal yet, but I will go through it.
Avneesh: I've placed the link to the Pull Request, and will send a link to the proposal
https://github.com/daisy/epub-revision-a11y/wiki/WCAG-Discovery-Metadata-Proposal
tzviya: officially Katie was the person in charge, but she was offf soe David took it over
jason: something you might think is uncontroversial can turn out to be difficult...
Avneesh: ok. I'll send an email to the chair to explain them our priorities
Topic 2: Structure of the a11y requirement document
http://www.w3.org/TR/dpub-accessibility/
Avneesh: In last call Tzviya reminded us that the gap analysis IG note is not the output of the Publishing WG ... so we have to review it and incorporate the reqs in that note in the new WG ... And we discussed creating a new document in the WG ... initially a wiki page ... working on the principles now, then integrate techniques after ... we have to discuss the structure of this document, any input?
Digital Publishing and Accessibility in W3C Documents W3C Interest Group Note 03 May 2016
George: [question about the note]
Avneesh: we talked about creating a requirement document that will be used as input to the WG
tzviya: what are you hoping to accomplish with the note?
Avneesh: 1. when the WP/PWG specs are developed, the principles identified in this doc will help keep things on track wrt a11y ... 2. keep principles aligned when discussing Silver ... the principles should be at one place, then the issue tracker is a floating thing ... we match the specs with principles
tzviya: I would hesitate to create a document structure before we know what we're documenting
dkaplan3: you're referencing the doc from last year (IG), are we turning that in a new document for the WG or starting from scratch? ... is the goal the same as for the note from last year?
Avneesh: the note identified what are the gaps, now we need to identify some SCs
dkaplan3: it was just a note, would we be using that list of things we think would need to exist as an input for new SC?
Avneesh: And I've gone through the notes many times, some things also need clarification ... many things come from hard-core specific a11y background like skippability, escapability, optimizations etc. ... we need to make it understandable to the general public
dkaplan3: the EPUB a11y requirements are much more barebones ... the a11y reqs and the note are very different
clapierre: some of the requirements in the note were integrated in the EPUB a11y requirements ... as a starting point, we can look at what's currently incorporated in the 1.0 a11y spec ... and what still needs to happen ... is that what you were thinking about what needs to happen for the SC?
Avneesh: we know that all the reqs can't go to WCAG 2.1, many will go into Silver ... people in PWG are asking why we need to care about these things if it's not in WCAG ... so we need to document our requirements for acting as common guidelines for the group. ... we can reference the IG note and the a11y specification when documenting our reqs ... the a11y spec is more concrete, the note was less concrete but more gaps are described ... the wiki page can be a reference for PWG to follow, and for us for working with WCAG
mattg: trying to figure out what we want to solve in the PWG ... are we trying to ensure that what PWG is doing includes a11y? ... or start focusing on what our priorities need to be in Web Pub, then only start to focus on how content is produced accessibly ... it's difficult to say how to produce the document when we don't know what WP/PWP is
George: we want to identify the high level principles and techniques that are going to guide our work ... we can then go down to more specific issues ... trying to figure out what can be pushed to WCAG, or what fits in the PWG domain ... some things will be specific to publishing, other general things ... if we have these principles to promote in the PWG, or WCAG work, is that what we think we need?
Avneesh: yes, that's the main idea
tzviya: as a chair of the WG, we should discuss issues that affect the PWG ... if you're discussing WCAG matters, bringing the concerns of publishing matters, but our goal as a TF is to define a11y for publications
<Bill_Kasdorf> we are a subset of the PWG, not a WG
<Bill_Kasdorf> and not an IG
Avneesh: absolutely, WCAG is doing its work, we're just discussing issues that are relevant to publishing
tzviya: we have specs to write. this TF should focus on the concerns about these specs
tzviya, you wanted to respond to matt's question
tzviya: we might be looking at too large a scope right now, accomplishing 2 tasks ... yes there s/b representatives from this WG to express the concerns of publishing ... but the main priority of this TF is not to bring a11y to the Web
George: do you mean we should be looking at all the existing WCAG work and say these are the chunks that apply to Web Publications and let the WG know?
tzviya: that's kind of a default assumption
dkaplan3: there's a bunch of things being conflated ... we've talked a long time about should we be writing techniques, etc ... we don't need to duplicate any of the core a11y work ... technique for adding metadata is a good thing ... we need to say "there are some things that we really want to have in our publication but we cant. do we need to write some new SC?" ... aside from the high level spec (current EPUB a11y spec), are there places that have gaps? ... for the WG that Tzviya defined, that would be our job
jason: the WG is developing a new publishing specification. our priority is that all reqs for a11y are included in that specification, that's what the WG is about ... if there's liaison needed with WCAG WG to make sure that the specs coming out of this WG ... we can collaborate with both WG to get this things addressed
Avneesh: I think the common understanding is that we need to focus on the a11y issues that are the current state of WCAG ... we also know which are the main areas of publishing which are not covered by the Web a11y ... coming to Matt's comment, until WP get some shape, we can't know what's the structure of these requirements ... maybe we can wait with this document, and let the WG come with a FPWD ... there's also the possibility that Web Pub is close to the web and there's not a lot of new requirements ... have I interpreted the group well?
+1 to what avneesh said
clapierre: I agree with what you said ... it's sort of what we did in the a11y TF of the IG ... our job was to find any issue that could be an a11y issue and discuss in the TF separately ... that's our role here as well, I like the idea of continuing this here
mattg: yes, generally agree with what Avneesh said ... the nav doc issue that came up several times can be the kind of issue we need to discuss in this group ... we can have a position on why it's an a11y issue and why it is a priority ... maybe we should be building up a list of similar issues
Avneesh: good. We have the nav doc in next week's agenda
dkaplain: agree with everyone. If we need time, one of the things we can do is develop a list of gaps, and specific things we want to do and turn them to formal requests ... we don't need to do the work about why they're important
1+ Deborah
dkaplain: if we have time to kill while waiting for the whole group, it's a great thing to do
tzviya: you don't necessarily need to wait for the TF consensus to comment on issues ... it's a good idea to form a position, but everybody can form an opinion ... Avneesh, can you move the minutes into a sub page of the wiki?
Avneesh: any final comment?
jason: some of the a11y requirements can be addressed in the specs under development by the PWG ... if there are other things that publication-related software doesn't do, where does that belong?
uaag, jasonjgw? Except that's not live, is it?
jason: if it's related to a particular web technology that the PWG want to use ... it's difficult at the moment, there's no work on the way to address UA a11y requirements ... that might change in Silver
Avneesh: We have to close the call.. Thanks to everyone.
Summary of Action Items
- Avneesh: Send email to WCAG chairs, informing about the priorities of proposals of PWG.
Uncleaned minutes are at: http://www.w3.org/2017/08/02-pwg-a11y-minutes.html
Present Tzviya, Matt, Avneesh, Laudrain, Romain, CLapierre, George, Bill_Kasdorf, Mia, Jason, Daniel and Marisa.
scribenick: laudrain
Avneesh: 4 topics, equal time ... 1. Update on WCAG ... background WCAG 2.1 is incremental release. The vision is to get all the accessibility requirements of publishing in WCAG, but it may be possible in silver. In WCAG 2.1 we are trying to get as many things inside as possible, these may not be in the structure that we want, but it is for starting the process. The biggest thing is accessibility metadata. It would go into conformance section or AAA of WCAG 2.1. In publishing world it is a high priority item but WCAG 2.1 structure does not allow deeper acceptance. Then is logical reading order. Section 1.3.2 of WCAG address it in a way. Matt will be proposing some change in language. then multiple ways of navigation (section 2.4). It is for publishing requirement of page numbers. We will be proposing technique to WCAG.
Then we have other gaps that were identified by DPUB IG note, it includes issues like: deeply nested heading, skippability, escapability and pronunciation lexicons etc.. Some of these needs more work for example what does escapability and skippability mean for text only publications and what it means for audio sync text publications. George: we know what we can have in 2.1, and then continue in siliver. Tzviya: Regarding DPUB gap analysis note, it is not a document created by this group so we should sent it for review of people in this group. http://w3c.github.io/dpub-accessibility Tzviya: see note and review with the larger PWG https://lists.w3.org/Archives/Public/w3c-wai-ig/2017JulSep/0026.html Tzviya: headings and iFrame : WCAG doesn’t address heading requirements.
Avneesh: big picture is that we now know what can go in WCAG 2.1 and timeline of silver is out of sync, so we need to do some work in PWG. The question is how to do it.One way is to create a document for publishing specific accessibility requirement, which acts as reference for PWG and also for feeding the requirements in Silver.
Tzviya: You can do it on an informal document on wiki. final version of DPUB note: https://www.w3.org/TR/dpub-accessibility/ George: can't it be requirement in Publishing? ... If it cannot go to WCAG? Tzviya: We should not give an impression that we are doing something on our own. People may perceive things differently. Avneesh: this group write with the same structure as WCAG, higher level principles and techniques below it. And for the intergroup relationships, would it be good to have the taskforce under PWG, AG and APA. It will resolve such issues. The document can inform what we want to accomplish and add to WCAG in longer term. Tzviya: Such a combined task force will be difficult to manage.
George: nested heading is not a requirement in WCAG, should we put in Pub requirements? Can we have it More stringent in Pub than in general Web? Avneesh: It is possible in WCAG if it becomes modular, which does not look possible in 2.1. The main question is what is the scope of the document? Tzviya: not a formal document, on a wiki and refreshed regularly Avneesh: We can start from wiki and then see if it needs to mature as a working group note. Matt: make sure the WP is accessible, may feed technique for it. Avneesh: We should start immediately on this doc, and list the principles before November this year. +1
George: hard core requirements are difficult to put forward, but with SHOULD, as company accomplish the best as possible Avneesh: Lets discuss the structure of the document in next calls.
Charles: agree wiki approach ... list of SHOULD or MAY, tu MUST in the publishing side of it Avneesh: My understanding is to start from conceptual form (principles) and then develop techniques as the working group develops the specifications. BillK: recommendation differ from WP/PWP/EPUB4 ... more stringent for EPUB Tzviya: first draft as a structure, and fills gaps afterwards Avneesh: Bill, this is why we should start from principles because principles will be same for WP, PWP and EPUB 4, but techniques may differ. George: requirements are difficult to address in PWP, EPUB 4 etc. if it doesn’t exist in WP.
- Horizontal review Avneesh: APA has a checklist that should be used from first working draft and it should be again checked before reaching CR. Once we are done with checklist then the specifications are to be sent to APA group for review. http://w3c.github.io/apa/fast/checklist.html Tzviya: not only a formal horizontal review , we should keep an eye on ways to accomplish thing that are not accessible Avneesh: Yes it should start from design stage itself. Matt: need to be involved in discussions ... s/ ne / be /
Avneesh: Matt, for catching attention of the group can we put an a11y label in Github? Tzviya: Github is now chaos ... more smaller issues easier to understand ... the name of the issue should alert on a11y. However having a label would be good. Avneesh: For example, the Nav doc discussion that is happening, how accessibility piece comes in this discussion. Accessibility is user experience, we need navigation, but it does not matter if the navigation comes from JSON or from HTML navigation file. Matt: we need clarity on requirement for the UA Tzviya: philsophical questions should not be in Github , but in call
- Assign group members for acting as liaison with other W3C groups Avneesh: WCAG: we have Avneesh, Matt, Romain Tzviya: if you need me you can inform me. I can be on some of those calls. Matt: we may need to do a review in the group for 2.1 progression Romain: I am in ACT group but not in plenary calls. Avneesh: agenda is sent in advance. So, we can join the call when we have relevant topics. Charles: We can have some people monitoring, look agenda items, and alert others when larger group is required. George: let the group know when we need to join
Avneesh: APA ? George: Janina attends and chairs the APA Isn't Jason White also on APA? not sure if Jason is also active or participating with this group George: we should familiarise with their checklist Tzviya: Jason is also in APA. Jason: just join from the WCAG meeting, on metadata Tzviya: I do not think that we need to do much inside the APA group. Avneesh: It looks we have sufficient number of people there. ARIA? Jason: ARIA 1.1 goes to rec Avneesh: Tzviya and Charles already there George: relation between DPUB ARIA and ARIA? Avneesh: DPUB ARIA is a module of ARIA. Charles: co-chairing the personalization TF in ARIA Tzviya:Another task force is starting in ARIA, the CSS ARIA TF ... could someone join? Jason: need to be strategic in group involvement Tzviya: very helpful Avneesh: what is priority? Jason: new layout features and AT ... how screen reader engage that, box and grid layout, CSS doen’t reflex the DOM order ... how to make things available for the AT Avneesh: It may be interesting for main PWG group also.
Avneesh: Silver TF? Jason: WCAG may be incrementally adding requirements, or larger scale revision may happen with Silver: AG has not decided yet Avneesh: Is it right time to start our influence or wait? Jason: wait after 2.1 ... not possible to add in 2.1 ... AG mostly developing support to gather requirements. ... may be input in their survey process?
Avneesh: Task forces, Cognitiv TF? Tzviya: cogo has become the personalisation TF Jason: Not really. The coga is under WCAG, and personalization under ARIA. digital pub should be represented there Avneesh: WAI IG? Tzviya: Mainly emails and sharing of information. Jason: EO group EOWG charter https://www.w3.org/WAI/EO/2015/charter6-2015-09 Jason: AG request for review Avneesh: We should have liaison from this group or the business group? The business group has responsibility of communications. Tzviya: the BISG is involved with EO ... be more familiar with the work there BillK: As AC rep for BISG, would have more engagement with EO. I can be liaison with this group. Avneesh: any other groups? George: EO, training materiel an best practices, would be great to have it for publishing. ... EO meets at CSUN Mia: can join in for EO as well
- Work on audio sync text. Avneesh: Media Overlays is using smil which is outdated technology in W3C Marisa We should get away from SMIL, choice between flat list or something more structured Avneesh: We are in W3C, and we need to be clear about process that we used for making decisions. So, may be we should start from documenting requirements. What are the minimum user requirements, what are advance requirements, should it be designed for only browsers or is it designed for reading systems also. Marisa: ok Avneesh: Marisa, Daniel and I can start work on this document, we will first bring it to this group and then to main group. Daniel: in Readium2, working with a replacement of smile in JSON syntax ... clipping in and out, reusing existing Web technologies ... slightly ahead in Readium2 project Tzviya: great, but for the rec, we have to write. Daniel: This was to inform the group. I agree that we should start from requirements.
Avneesh: meeting every week? do we need a poll? ... poll tomorrow.
The raw minutes are at: http://www.w3.org/2017/07/20-pwg-a11y-minutes.html