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