-
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)
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